Защита от XSS

Question

[Степан Зубашев]

Доброго времени суток. Написав систему комментариев, я всерьёз задумался о защите от XSS. Немного погуглив на эту тему мои глаза приняли такой вид «О_О». Что есть на данный момент:

1. Пишу на javascript, используя nodeJS
2. Текст полученный от браузера проходит следующие метаморфозы:

а) формируется DOM-древо (jsdom)
б) подключается jQuery
в) пробегаю $( '*' ) по каждому тегу и провожу его сквозь парсер. Повторяю пробеги до тех пор пока не искоренятся все проблемы, либо число пробегов превысит разумные нормы (в этом случае выкидываю ошибку).

Парсер тега работает примерно по такому принципу:

1) если тег не входит в список доступных пользователю тегов (i, b, s, strong, em, ul, ol, li, p, pre, span, br, img, a), заменяю его SPAN-тегом
2) пробегаюсь по всем атрибутам тега, удаляя все не доступные (оставил только width, height, src для image и href для a).
3) в годных атрибутах прохожусь регуляркой по значению ( .replace( /[^\d]+/, '' ) для width, height ).

Остаются такие аттрибуты как src и href. Я думал в них достаточно срезать начальную 'javasript:', но почитав эту статью, я понял, что нужно как то очень хитро подойти к этому вопросу.

Собственно вопросы:

1. Какие у описанной выше схемы есть изъяны? Что стоило бы добавить?
2. Каким образом фильтровать атрибуты вроде href и src

Интересует именно HTML, а не BB коды или другая разметка. + планирую эту наработку использовать не только в системе комментариев.

Comments

[Степан Зубашев]

Большая просьба: перед тем как ответить «я использую эти 3 строчки кода» или «используй силу, Люкбелый список», или «нельзя парсить на javascript-е» — внимательно прочитайте топик-вопрос.

Answer 1

[Weageoo]

Html sanitizer на js.

Comments

[Степан Зубашев]

Спасибо за готовое решение, возьму на заметку, но в данный момент мне важнее понять и написать самому. Проект не коммерческий, а для личного профессионального роста, и моя задача самому пройти через все грабли, какие есть. Через 625 строк чужого искомый опыт получить, ИМХО, малореально :)

[Nikita Permin]

Это же клиентская сторона… то есть плохие данные все же лучше отсеивать еще на сервере, и по возможности банить от этого нехороших пользователей =) иначе при глобальной смене шаблона сайта можно попросту забыть про эту библиотеку…

[Степан Зубашев]

NekitoSP, в моём случае никто не мешает запустить этот код на сервере :)

Answer 2

[Виталий Желтяков]

Если по «правильному», то защита от XSS сводиться к элементарной проверке входящих данных на сервере. Желательно использовать белый список.

Answer 3

[AlexanderPHP]

Только на javascript фильтровать нельзя, т.к. firebug`ом можно обойти.

Вообще, на стороне PHP есть хороший способ:

$find = array ('/data:/i', '/about:/i', '/vbscript:/i', '/onclick/i', '/onload/i', '/onunload/i', '/onabort/i', '/onerror/i', '/onblur/i', '/onchange/i', '/onfocus/i', '/onreset/i', '/onsubmit/i', '/ondblclick/i', '/onkeydown/i', '/onkeypress/i', '/onkeyup/i', '/onmousedown/i', '/onmouseup/i', '/onmouseover/i', '/onmouseout/i', '/onselect/i', '/javascript/i', '/javascript/i' );
$replace = array ("data:", "about:", "vbscript<b></b>:", "onclick", "onload", "onunload", "onabort", "onerror", "onblur", "onchange", "onfocus", "onreset", "onsubmit", "ondblclick", "onkeydown", "onkeypress", "onkeyup", "onmousedown", "onmouseup", "onmouseover", "onmouseout", "onselect", "javascript" );

$txt = preg_replace( $find, $replace, $txt );
$txt = preg_replace( "#<iframe#i", "<iframe", $txt );
$txt = preg_replace( "#<script#i", "<script", $txt );
$txt = str_replace( "<?", "<?", $txt );
$txt = str_replace( "?>", "?>", $txt );

Comments

[Степан Зубашев]

1. nodeJS
2. обход вашего парсера

Пожалуйста, прочитайте топик-вопрос полностью.

Answer 4

[Nikita Permin]

Прочитав статью с того сайта вы похоже до сих пор немного не разобрались как действовать. Моя идея фильтрации данных на стороне сервера такова:
1) для начала декодируем все данные, заменяя все подобные вещи

на нормальные символы, с которыми далее будем работать
3) далее при нахождении границ тега, будь то ... мы удаляем все непечатаемые(?) символы (в т.ч. и переносы строк) в параметрах тега а так же между открывающим и закрывающим. Проблема будет лишь с \0, но если работать с данными как с массивом символов, а не как со строкой — то наверное удастся их обойти.
3) затем работа с параметрами тега, соответственно убираем всё, что не является нормальным URL-адресом, и по возможности, избавляемся от тега, если вдруг URL «небезопасный» (безопасными URL я думаю стоит считать лишь те, которые начинаются с http:// или https://, ну и на крайний случай — ... в общем вам решать)

Comments

[Nikita Permin]

… будь то <а>...</а> мы удаляем
теги скушались…

[Степан Зубашев]

Вы правы, я действительно запутался.

1. Спасибо, *ушёл искать способы конвертации*

2. Я пропускаю html через DOM-древо, с которым в дальнейшем и работаю. Итоговый код получаю через .innerHTML. Я правильно понимаю — второй пункт могу игнорировать? Или такая схема может пропустить какую-нибудь не attr-based уязвимость? Просто в моей схеме отсутствует ручной парсинг HTML-строки вне конкретного тега. Насколько это безопасно?

3. Не могли бы привести пример ссылки, которая бы обошла /^javascript:/i, и при этом была бы опасной? Насколько я понимаю, если выполнить пункт первый выполнить всякие премудрости вроде java%бред-какойнибудь%scrIpt: отпадут сами собой?

[Nikita Permin]

тогда последним пунктом скорее всего надо как-то декодированные данные из первого пункта вернуть на место… (то есть значения у параметров href, src, а так же текст внутри тегов, чтобы он нормально отобразился на странице)
3) вполне возможно что этот бред отпадет и можно будет нормально отсеять все javascript:, если оставить только a-zA-Z0-9а-яА-Я"':/ пример привести не могу — особо не в теме =) все что написано выше — лишь мой возможный ход действий в подобной ситуации.

Answer 5

[Xrizolin]

https://www.owasp.org/index.php/XSS_(Cross_Site_Sc...
И на всякий случай после проверки исходников прогнать поверх сканером.
Например https://metascan.ru