Improved ASP.NET Request Validation: реальная защита от XSS
19.04.2013
|
kochetkov.vladimir
 |
В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET, в голову пришла идея набросать proof-of-concept того, как на самом деле оно должно быть реализовано, чтобы давать хоть какие-то гарантии защиты от отраженных XSS. В итоге, после пары вечеров кодинга и недели тестов с привлечением коллег, родилось вот это: https://github.com/kochetkov/Irv
Результаты по производительности и проценту false-позитивов обоих родов приятно удивили (ожидал, что будет еле ворочаться и пропускать некоторые замороченные векторы атак). Поиграть с демкой можно тут: http://irv.c2e.pw/Demo/
P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Результаты по производительности и проценту false-позитивов обоих родов приятно удивили (ожидал, что будет еле ворочаться и пропускать некоторые замороченные векторы атак). Поиграть с демкой можно тут: http://irv.c2e.pw/Demo/
P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
... << RSDN@Home 1.2.0 alpha 5 rev. 72>>
| 19.04.2013 11 комментариев |
KV>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET
По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко. Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?
D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET
D>По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко.
Примерно так, только я занимаюсь вопросами потроения защищенных веб-приложений и анализа их защищенности в целом, не только в плане XSS
D>Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?
Не можно, а нужно
Если в двух словах, то правильная обработка входных и выходных данных (санитизация, валидация, типизация и т.п.) является обязательным условием разработки защищенного кода, в то время, как навесные защиты (встроенная в ASP.NET валидация запросов, Irv, Mod-security for IIS, .NETIDS и т.п.) не зависят от логики приложения и являются дополнительными средствами усиления защиты, как разрабатываемых проектов (на случай ошибок разработчиков, недостаточной обработки входных/выходных данных и т.п.), так и проектов третьих сторон (например, когда исходники недоступны или затруднена их правка, а уязвимость закрыть нужно).
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Про такую штуку в курсе? http://wpl.codeplex.com/
С Уважением, 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, предполагающем фикс критичной уязвимости, выпустила совершенно непригодную для использования в реальных проектах библиотеку, не предоставив исходников для этого релиза и забив на фидбек возмущенных пользователей
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!
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
A>Про такую штуку в курсе? http://wpl.codeplex.com/
Конечно
Если они хотя бы выложили исходники 4.2 или дали официальное добро на реверсинг бинарников той версии, то из нее можно было бы сделать весьма достойный продукт, исправив поломанное и добавив функционал Irv
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Отличное начинание!
Несколько лет в публичных проектах используем для санитизации пользовательского ввода https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET (или Java-версию, где это требуется)
Может, что-то из этого проекта пригодится и для развития вашего.
А>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
А>Отличное начинание!
А>Несколько лет в публичных проектах используем для санитизации пользовательского ввода https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET (или Java-версию, где это требуется)
А>Может, что-то из этого проекта пригодится и для развития вашего.
Спасибо. Да это действительно неплохая библиотека и есть мысли, как в плане ее интеграции с уже написанным, так и расширением функционала обоих (от автоматического вывода политики, аналогичной AntiSamy, на основе реальных критериев опасности входных данных, до автоматического контекстного экранирования данных в выходном документе).
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Собственно, статья: http://habrahabr.ru/company/pt/blog/178357/
KV>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
KV>Собственно, статья: http://habrahabr.ru/company/pt/blog/178357/
Прочитал,весьма познавательно. В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире
Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация
C>В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире
В целом так и есть, за исключением того, что такой механизм защиты будет защищать только от уязвимостей, принадлежащих двум классам недостатков. На самом деле, их чуть больше (http://projects.webappsec.org/w/page/13246970/Threat%20Classification%20Enumeration%20View — колонка weakness).
C>Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация
Граф исполнения — это из области whitebox-анализа (исследование защищенности кода). А тупой перебор комбинаций входных данных — фаззинг, относится к blackbox (исследование защищенности развернутого приложения). И он далеко не всегда тупой