AVK Selected

Показавшиеся интересными, на мой вкус, посты

Improved ASP.NET Request Validation: реальная защита от XSS

kochetkov.vladimir kochetkov.vladimir
В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET, в голову пришла идея набросать proof-of-concept того, как на самом деле оно должно быть реализовано, чтобы давать хоть какие-то гарантии защиты от отраженных XSS. В итоге, после пары вечеров кодинга и недели тестов с привлечением коллег, родилось вот это: https://github.com/kochetkov/Irv

Результаты по производительности и проценту false-позитивов обоих родов приятно удивили (ожидал, что будет еле ворочаться и пропускать некоторые замороченные векторы атак). Поиграть с демкой можно тут: http://irv.c2e.pw/Demo/

P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
denis8158
denis8158
19.04.2013 04:32
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET



По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко. Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?
kochetkov.vladimir
kochetkov.vladimir
20.04.2013 09:43
Здравствуйте, denis8158, Вы писали:

D>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET

D>По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко.


Примерно так, только я занимаюсь вопросами потроения защищенных веб-приложений и анализа их защищенности в целом, не только в плане XSS

D>Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?


Не можно, а нужно Более подробно уже рассказывал об этом здесь (начиная с абзаца "Определение степени доверия к данным", написанное относится к любым ошибкам обработки данных, а не только к межсайтовому скриптингу). Еще более подробно и на практических примерах, буду рассказывать (и показывать) это буквально через месяц, на Positive Hack Days (см. соседнюю тему).

Если в двух словах, то правильная обработка входных и выходных данных (санитизация, валидация, типизация и т.п.) является обязательным условием разработки защищенного кода, в то время, как навесные защиты (встроенная в ASP.NET валидация запросов, Irv, Mod-security for IIS, .NETIDS и т.п.) не зависят от логики приложения и являются дополнительными средствами усиления защиты, как разрабатываемых проектов (на случай ошибок разработчиков, недостаточной обработки входных/выходных данных и т.п.), так и проектов третьих сторон (например, когда исходники недоступны или затруднена их правка, а уязвимость закрыть нужно).
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
Andir
Andir
19.04.2013 06:49
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье


Про такую штуку в курсе? http://wpl.codeplex.com/

С Уважением, Andir!
using(<< RSDN@Home 1.2.0 alpha 5 rev. 67>>) { /* Работаем */ }
gravatar
Аноним
19.04.2013 07:25
Здравствуйте, Andir, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье


A>Про такую штуку в курсе? http://wpl.codeplex.com/


http://eksith.wordpress.com/2012/02/13/antixss-4-2-breaks-everything/

TL;DR: MS в последнем релизе WPL, предполагающем фикс критичной уязвимости, выпустила совершенно непригодную для использования в реальных проектах библиотеку, не предоставив исходников для этого релиза и забив на фидбек возмущенных пользователей
Andir
Andir
19.04.2013 07:38
Здравствуйте, <Аноним>, Вы писали:

A>>Про такую штуку в курсе? http://wpl.codeplex.com/

А>http://eksith.wordpress.com/2012/02/13/antixss-4-2-breaks-everything/
А>TL;DR: MS в последнем релизе WPL, предполагающем фикс критичной уязвимости, выпустила совершенно непригодную для использования в реальных проектах библиотеку, не предоставив исходников для этого релиза и забив на фидбек возмущенных пользователей

Хах, не знал про такую её судьбу. Со времён AntiXSS её не видел. Жаль, ведь в первых версиях AntiXSS идеи были заложены правильные.
Reviews of latest release впечатляют: http://wpl.codeplex.com/releases/view/80289#ReviewsAnchor

С Уважением, Andir!
using(<< RSDN@Home 1.2.0 alpha 5 rev. 67>>) { /* Работаем */ }
kochetkov.vladimir
kochetkov.vladimir
20.04.2013 09:48
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье

A>Про такую штуку в курсе? http://wpl.codeplex.com/

Конечно Как сказали выше, ее рантайм-часть "слегка" поломали, что сделало невозможным ее использование. А энкодинг-часть плавно перекочевала в ASP.NET 4.5 (http://idunno.org/archive/2011/09/14/net-4-5-now-includes-the-core-antixss-functions.aspx) в связи с чем, на оригинальный проект разработчики забили.

Если они хотя бы выложили исходники 4.2 или дали официальное добро на реверсинг бинарников той версии, то из нее можно было бы сделать весьма достойный продукт, исправив поломанное и добавив функционал Irv
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
gravatar
Аноним
19.04.2013 07:18
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье


Отличное начинание!

Несколько лет в публичных проектах используем для санитизации пользовательского ввода https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET (или Java-версию, где это требуется)
Может, что-то из этого проекта пригодится и для развития вашего.
kochetkov.vladimir
kochetkov.vladimir
20.04.2013 09:54
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье

А>Отличное начинание!



А>Несколько лет в публичных проектах используем для санитизации пользовательского ввода https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET (или Java-версию, где это требуется)

А>Может, что-то из этого проекта пригодится и для развития вашего.

Спасибо. Да это действительно неплохая библиотека и есть мысли, как в плане ее интеграции с уже написанным, так и расширением функционала обоих (от автоматического вывода политики, аналогичной AntiSamy, на основе реальных критериев опасности входных данных, до автоматического контекстного экранирования данных в выходном документе).
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
kochetkov.vladimir
kochetkov.vladimir
29.04.2013 12:02
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье


Собственно, статья: http://habrahabr.ru/company/pt/blog/178357/
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
Codechanger
Codechanger
30.04.2013 01:18
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье


KV>Собственно, статья: http://habrahabr.ru/company/pt/blog/178357/


Прочитал,весьма познавательно. В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире .

Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация .
kochetkov.vladimir
kochetkov.vladimir
13.05.2013 04:45
Здравствуйте, Codechanger, Вы писали:

C>В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире .


В целом так и есть, за исключением того, что такой механизм защиты будет защищать только от уязвимостей, принадлежащих двум классам недостатков. На самом деле, их чуть больше (http://projects.webappsec.org/w/page/13246970/Threat%20Classification%20Enumeration%20View — колонка weakness).

C>Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация .


Граф исполнения — это из области whitebox-анализа (исследование защищенности кода). А тупой перебор комбинаций входных данных — фаззинг, относится к blackbox (исследование защищенности развернутого приложения). И он далеко не всегда тупой
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>