В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET, в голову пришла идея набросать proof-of-concept того, как на самом деле оно должно быть реализовано, чтобы давать хоть какие-то гарантии защиты от отраженных XSS. В итоге, после пары вечеров кодинга и недели тестов с привлечением коллег, родилось вот это: https://github.com/kochetkov/Irv
Результаты по производительности и проценту false-позитивов обоих родов приятно удивили (ожидал, что будет еле ворочаться и пропускать некоторые замороченные векторы атак). Поиграть с демкой можно тут: http://irv.c2e.pw/Demo/
P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET
По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко. Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?
Re: Improved ASP.NET Request Validation: реальная защита от XSS
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Re: Improved ASP.NET Request Validation: реальная защита от XSS
От:
Аноним
Дата:
19.04.13 19:18
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
A>Про такую штуку в курсе? http://wpl.codeplex.com/
TL;DR: MS в последнем релизе WPL, предполагающем фикс критичной уязвимости, выпустила совершенно непригодную для использования в реальных проектах библиотеку, не предоставив исходников для этого релиза и забив на фидбек возмущенных пользователей
Re[3]: Improved ASP.NET Request Validation: реальная защита от XSS
Здравствуйте, <Аноним>, Вы писали:
A>>Про такую штуку в курсе? http://wpl.codeplex.com/ А>http://eksith.wordpress.com/2012/02/13/antixss-4-2-breaks-everything/ А>TL;DR: MS в последнем релизе WPL, предполагающем фикс критичной уязвимости, выпустила совершенно непригодную для использования в реальных проектах библиотеку, не предоставив исходников для этого релиза и забив на фидбек возмущенных пользователей
Здравствуйте, denis8158, Вы писали:
D>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>В процессе подготовки статьи на тему того, насколько бестолковым и несерьезным является проверка запросов в ASP.NET
D>По описанию, я понял, что Вы занимаетесь данной проблемой достаточно глубоко.
Примерно так, только я занимаюсь вопросами потроения защищенных веб-приложений и анализа их защищенности в целом, не только в плане XSS
D>Не могли бы Вы ответить на вопрос, в каких случаях актуально защищать именно запросы. Ведь можно просто экранировать строки при выдаче клиенту?
Не можно, а нужно Более подробно уже рассказывал об этом здесь (начиная с абзаца "Определение степени доверия к данным", написанное относится к любым ошибкам обработки данных, а не только к межсайтовому скриптингу). Еще более подробно и на практических примерах, буду рассказывать (и показывать) это буквально через месяц, на Positive Hack Days (см. соседнюю
Если в двух словах, то правильная обработка входных и выходных данных (санитизация, валидация, типизация и т.п.) является обязательным условием разработки защищенного кода, в то время, как навесные защиты (встроенная в ASP.NET валидация запросов, Irv, Mod-security for IIS, .NETIDS и т.п.) не зависят от логики приложения и являются дополнительными средствами усиления защиты, как разрабатываемых проектов (на случай ошибок разработчиков, недостаточной обработки входных/выходных данных и т.п.), так и проектов третьих сторон (например, когда исходники недоступны или затруднена их правка, а уязвимость закрыть нужно).
Здравствуйте, Andir, Вы писали: A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье A>Про такую штуку в курсе? http://wpl.codeplex.com/
Если они хотя бы выложили исходники 4.2 или дали официальное добро на реверсинг бинарников той версии, то из нее можно было бы сделать весьма достойный продукт, исправив поломанное и добавив функционал Irv
Здравствуйте, <Аноним>, Вы писали: А>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье А>Отличное начинание!
Спасибо. Да это действительно неплохая библиотека и есть мысли, как в плане ее интеграции с уже написанным, так и расширением функционала обоих (от автоматического вывода политики, аналогичной AntiSamy, на основе реальных критериев опасности входных данных, до автоматического контекстного экранирования данных в выходном документе).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>P.S: Как и почему это работает, а также почему это единственный адекватный способ, дающий гарантии защиты от отраженных XSS — расскажу в статье
KV>Собственно, статья: http://habrahabr.ru/company/pt/blog/178357/
Прочитал,весьма познавательно. В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире .
Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация .
Re[3]: Improved ASP.NET Request Validation: реальная защита от XSS
Здравствуйте, Codechanger, Вы писали:
C>В целом, я так понимаю, механизм защиты выстроен в основном на проверках входных данных на невалидные символы, ну и на естественной контрацепции в виде, например, выполнения sql — запросов с параметрами. В целом все как и в десктопном мире .
В целом так и есть, за исключением того, что такой механизм защиты будет защищать только от уязвимостей, принадлежащих двум классам недостатков. На самом деле, их чуть больше (http://projects.webappsec.org/w/page/13246970/Threat%20Classification%20Enumeration%20View — колонка weakness).
C>Вообще, по прошлому PHDays сложилось впечатление, что многие вещи ломаются тупым перебором комбинаций входных данных. Потом все это называется красивыми словами(типа графа исполнения) и делается презентация .
Граф исполнения — это из области whitebox-анализа (исследование защищенности кода). А тупой перебор комбинаций входных данных — фаззинг, относится к blackbox (исследование защищенности развернутого приложения). И он далеко не всегда тупой
