regeda27 сен 2009 в 22:14

Не очередной XSS фильтр

2 мин

8.6K

Веб-разработка *

+19

Комментарии 61

remal 27 сен 2009 в 22:31

Я бы при помощи Tidy приводил бы ввод к XML, а дальше можно при помощи того же самого XSLT прибивать лишнее.

corristo 28 сен 2009 в 00:01

code.google.com/p/jevix/

Kakysha 28 сен 2009 в 05:06

Пробовал Jevix & htmlpurifier. Остановился на jevix'e, который опказался гораздо понтянее и проще и легче (заметно легче). Алco присутствует полезная связка Jevix'a и Geshi(подсветка кода) + video парсера, и все это в одной библиотеки дял CI: www.coolweb.su/blog/7.html

eugeneorlov 28 сен 2009 в 04:09

htmlpurifier

dienow 28 сен 2009 в 09:05

Warning: Element '<style><a>' is not supported (for information on implementing this, see the support forums) in /home/ezyang/htmlpurifier.org/live/library/HTMLPurifier/HTMLDefinition.php on line 265
К тому же мне работать с white list не так удобно как с black list.

regeda 28 сен 2009 в 09:38

Если

regeda 28 сен 2009 в 09:39

если <style> еще можно понять, то что плохого сделал старый добрый <a> ???

dienow 28 сен 2009 в 09:58

Видимо плохо ему стало именно от style, с «a» без «style» у него всё хорошо.

eugeneorlov 28 сен 2009 в 18:46

black list — зло, т.к. все возможные дыры предусмотреть невозможно.

dienow 29 сен 2009 в 07:27

Да, постепенно прихожу к тому же выводу. Хоть blacklist и whitelist у меня в разы, обрезать редкий тэг меньшая беда чем пропустить вредоносный код. Честно говоря, до прочтения вот этого ha.ckers.org/xss.html я и не представлял что xss атаки бывают настолько разнообразны.

egorinsk 28 сен 2009 в 18:58

А вы можете написать 100%-ный black list?

dienow 29 сен 2009 в 07:30

Не могу, согласен с Вами. Я просто знал о некоторых хитрых способах обойти защиту, но не знал что их так много =( Теперь уже склоняюсь к white list.

boston 28 сен 2009 в 04:43

Старенький, но проверенный phpinputfilter

tenshi 28 сен 2009 в 06:20

-moz-binding

regeda 28 сен 2009 в 07:28

Данная фича тоже фильтруется

tenshi 28 сен 2009 в 09:48

а сколько их ещё не фильтруется…

tenshi 28 сен 2009 в 06:35

> Кому интересно поучавствовать в проекте или взломать XSS-фильтр, пишите в личку.
создай страничку с песочницей…

LMaster 28 сен 2009 в 16:02

dev.plakmag.ru/xss:
</textarea> < script> alert('xss');</script>
(удалите пробелы).

regeda 28 сен 2009 в 16:06

Ну максимум, Вы украдете свои данные.

LMaster 28 сен 2009 в 16:09

Почему? Контекстно загрузить страницу с передачей POST-параметра и последующим воровством cookies никто не отменял.

regeda 28 сен 2009 в 16:11

OK! Обновлено

recompileme 28 сен 2009 в 18:18

вот такие ссылки проходят в фф
ой, не знаю пустит ли фльтр хабра))
XSS

recompileme 28 сен 2009 в 18:27

гыгыгы
1

recompileme 28 сен 2009 в 18:32

хабр не пропустил)
А ваш — пропустил вот такой xss

Вобщем не стило хаять кодеигнайтер. Его защиту я так и не смог пробить, а ваша свалилась через 10 минут

regeda 28 сен 2009 в 18:40

Я CI не хаял, а просто показал один пример. Благодаря Вашему фидбеку данная уязвимость будет устранена ))

regeda 28 сен 2009 в 19:31

Обновлено! Значения в аттрибутах @href @src пропускаются через «rawurldecode»

recompileme 29 сен 2009 в 07:01

т.е. сразу выведите читсый javаscript вместо непонятных символов?
Библиотека для фильрации XSS в codeigniter совсем не зря заменяет javаscript на [removed] Совсем. Не зря. Вы слишком самоуверены мне кажется. Не разобравшись толком раскритиковали выбранный кодеигнайтером метод и предложили свой, не потрудившись даже прогнать его через топ 500 xss скриптов.

regeda 29 сен 2009 в 07:58

если у Вас есть на руках Ваш топ 500, то милости прошу на обозрение.
А чистый javascript, конечно же, не пропускается ;)

recompileme 29 сен 2009 в 08:20

ha.ckers.org/xss.html

regeda 29 сен 2009 в 08:28

Этот ТОП использовался как отправная точка для написания фильтра, все примеры проверялись на корректное преобразование

egorinsk 28 сен 2009 в 20:25

А разве такой способ работает в браузере? Это вообще уязвмость?

regeda 28 сен 2009 в 20:34

Скорее всего нет…
Во всяком случае Opera 10 не преобразует %3C в < или %3A в двоеточие

egorinsk 28 сен 2009 в 21:50

Дык а смыл тогда блокировать? давайте теперь и русское слово «яваскрипт» банить :) Вот за этои не люблю эти фильтры — работают бестолково, видимо единтвенный нормальный способ — разрираьть текст по тегам/аттрибутам/виду ссылки и пересобирать заново.

regeda 29 сен 2009 в 07:59

Если надо будет банить «яваскрипт», то будем банить

Isis 28 сен 2009 в 18:31

recompileme 28 сен 2009 в 18:33

знакомые всё ники)

Isis 28 сен 2009 в 18:33

Простите,

<img src='http://ya.ru/logo.gif'bo=o"onload="alert();>

regeda 28 сен 2009 в 18:43

Спасибо за пример

regeda 28 сен 2009 в 19:26

Обновлено! Теперь в unquoted значениях аттрибутов все двойные кавычки экранируются.

<img src='http://ya.ru/logo.gif' bo="o\"onload=\"alert();" />

FloppyFormator 28 сен 2009 в 22:41

Ещё вот такая штука прокатывает:

<img src="http://ya.ru/logo.png" style=color:red;"onload=alert('XSS!');a="1>

FloppyFormator 28 сен 2009 в 22:52

Адский парсер! Я имел в виду вот это: <img src="http://ya.ru/logo.png" style=color:red;"onload=alert('XSS!');a="1>

FloppyFormator 28 сен 2009 в 22:58

Ох ты ж ёканый бабайка, получите-ка лучше картинку:

pxx 29 сен 2009 в 07:37

Вы не могли бы пояснить, благодаря чему этот код сработает?
Я в XSS не силен, поэтому мне он с виду кажется абсолютно безумным и не дееспособным.

regeda 29 сен 2009 в 08:26

Как показала практика и примеры других участников, экранирование — не лучший способ, поэтому двойные кавычки в unquoted значения аттрибутов заменяются на "

regeda 29 сен 2009 в 08:29

фу-ты, ну-ты на & quot;

artyfarty 28 сен 2009 в 18:54

ооо.
Я покажу вам страшную вещь — презентацию с конференции BlackHat.
Когда я её прочитал, я полчаса сидел в шоке.

Оригинальный линк лежит, поэтому перезалил к себе: artyfarty.ru/blackhat_xss.rar

Советую всем хабраюзерам ознакомится. Вообще, сиё творение достойно топика-ссылки или топика-перевода.

artyfarty 28 сен 2009 в 18:56

Спойлер:

(É=[Å=[],µ=!Å+Å][µ[È=-~-~++Å]+({}+Å) [Ç=!!Å+µ,ª=Ç[Å]+Ç[+!Å],Å]+ª])() [µ[Å]+µ[Å+Å]+Ç[È]+ª](Å)



($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''

+$)[_/_]+$_[+$])])()[__[_/_]+__[_+~$]+$_[_]+$$](_/_)

Это тоже xss-вектор. Я правда до конца не понял принципа именно этой техники, но там и других извращений мама мия.

egorinsk 28 сен 2009 в 22:01

Это не вектор, это кусок кода на яваскрипте, отличающийся от нормального тем, что в нем не ипользуюстя симолы [a-z0-9], только и всего. Попробуйте этой фигней что нибудь взломать.

artyfarty 28 сен 2009 в 22:02

Адресуйте это автору презентации. Как я написал, я сам не до конца понял, как это применить, но выглядит впечатляюще :)

insa 28 сен 2009 в 19:08

Сходу бага в обработке IE «expression», по мотивам onsec.ru/vuln?id=5

regeda 28 сен 2009 в 19:51

Обновлено! IE «expression» фильтруется даже если каждый символ экранируется символом \ или C-подобным комментарием /*XSS*/:

style="onsec:e\x\p\re\s\s\i\o\n(alert('XSS'))"

или

style="onsec:e/*XSS*/x/*XSS*/p/*XSS*/re/*XSS*/s/*XSS*/s/*XSS*/i/*XSS*/o/*XSS*/n(alert('XSS'))"

insa 28 сен 2009 в 20:18

Остается только пожелать успехов в этом неравном бою с бесконечностью :)

Becoming_Insane 28 сен 2009 в 20:54

Странно, никто не вспомнил про htmLawed, а ведь он, имхо, достаточно крутой соперник и джевиксу и саксу и инпутфильтру.

вывод сделан опытным путем, вставвляя дескрипшены айтемов с ебэя и смотря на то, что в итоге приходит.
надо было чтобы всё было один в один, тока без опасных элементов. (не все дескры подходили, т.к. в некоторых менюхи генерились динамически ЖС-ом. на такие забивали)
сначала юзали джевикс, но он подвел, потом сакс, подвел, вернули джевикс — и там карачун.
да и у джевикса рекурсивный вывод жрал много памяти при дереве > 20-и нодов, при этом пхп сначала умирал с ошибкой нестед левел 100 ричед

artyfarty 28 сен 2009 в 21:55

Мне стукнул в аську человек, не имеющий аккаунта тут (32523553), и попросил выложить ещё одну строку, обходящую фильтр:
<img src='o.gif'bo=o"onerror=alert();//>

Он очень желает присоединится к дискуссии и ищет инвайт. У меня, увы, инвайта нет.

Он какбы говорит нам: «экранизация там не играет роли. в прошлом рабочем варианте она помогла только потому что перед знаком равно возник слеш»

cdbrk 29 сен 2009 в 06:26

Если пропускать html-тэги, то вероятность xss всегда будет существовать.
Почему бы не использовать bb-код?

regeda 29 сен 2009 в 09:29

А если используется WYSIWYG редактор? То HTML нужно преобразовывать в bb-код, а потом обратно?

artyfarty 29 сен 2009 в 15:06

Так делает IPB.

egorinsk 29 сен 2009 в 14:21

В общем, по итогам обсуждения и четния ha.ckers.org, у меня такие мысли:

Фильтр автора — несовершенен, т.к. использует конечные автоматы (чтает по символу), что очень медленно, фильтрует по черным спискам (что также плохо, т.к. не предугадаешь все уязвимости).

Моя идея — надо делать одно из 2: 1) преобразовывать входные данные в дерево DOM, и проходить по нему белым списком, затем пересобирать уже валидный и безопасный HTML 2) чтобы побыстрее делать — парсить регулярками на теги/аттрибуты/текст и опять же, проходить белым списком, и пересобирать заново. Ключевое слово — пересобирать, чтобы обезвредить выходной код. В этом случае всякие уязвимости с незакрытими тегами, двойными скобками и прочими нарушениями синтаксиса просто превратятся в безвредный обычный текст.

regeda 29 сен 2009 в 15:05

Идея с белым листом мне очень нравится, скорее всего буду развивать защиту в этом ключе.
Изначально алгоритм с конечным автоматом заложен для реализации как php extension, что будет крайне быстро.
Если по-Вашему итог в обсуждении и поставлен, то в развитии кода ставится «to be continued».

egorinsk 30 сен 2009 в 00:45

Так объясните хоть, чем ваш способ, медленно ковыряться по одному символу, лучше идеи разрезать регуляркой код на куски и их перебирать, а потом склеить назад?

regeda 30 сен 2009 в 09:49

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий