Запилил статью на тему используемых алгоритмов в нашем статическом анализаторе: https://habrahabr.ru/company/pt/blog/305000/ В "философию", потому что большинство тезисов оттуда применимы и к задаче анализа кода в целом, не только к поиску уязвимостей
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Запилил статью на тему используемых алгоритмов в нашем статическом анализаторе:
Не являясь специалистов в конкретной данной области, но имея большой опыт в области "автоматической" (машинной) генерации программ, могу сказать, что на мой взгляд высказанная в самом начале статьи мысль что "всё это искусство обмана" верна. Но тем не менее работать над "этой" темой надо.
Опять же вспоминая одну большую работу в которой код роботов автоматически генерировался на основании, ошибок их предков, могу сказать — для поиска уязвимости надо "просто" решить обратную задачу — "на каких данных программа окажется в данном состоянии". То есть задача построения обратного кода. То есть берем состояние и генерируем "обратную" программу которая выдаст входные данные. Задача решаемая но только в множествах естественно.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Опять же вспоминая одну большую работу в которой код роботов автоматически генерировался на основании, ошибок их предков, могу сказать — для поиска уязвимости надо "просто" решить обратную задачу — "на каких данных программа окажется в данном состоянии". То есть задача построения обратного кода. То есть берем состояние и генерируем "обратную" программу которая выдаст входные данные. Задача решаемая но только в множествах естественно.
Мысль интересная, но на практике такой подход не сработает. Дело в том, что определение уязвимости через запрещенные состояния представляет интерес большей частью с теоретической точки зрения, поскольку под программой там подразумевается полностью замкнутая система. В реальных же программах код `ExecuteSqlQuery("SELECT * FROM " + Request.Params["parm"])` подвержен SQL-инъекции, но в запрещенные состояния в результате атаки это приведёт не саму программу, а SQL-сервер, который будет выполнять этот запрос.
Читать про анализ кода на предмет поиска заковырок обычно весьма занимательно.
Но вот посыл применять статический (или даже динамический) анализатор для выявления уязвимостей в вебе слишком похож на попытку лечить симптомы болезни, а не ее причины.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Re[2]: [Хабр] Ищем уязвимости в коде: теория, практика и перспективы SAST
Здравствуйте, VTT, Вы писали:
VTT>Читать про анализ кода на предмет поиска заковырок обычно весьма занимательно. VTT>Но вот посыл применять статический (или даже динамический) анализатор для выявления уязвимостей в вебе слишком похож на попытку лечить симптомы болезни, а не ее причины.
А в чем причины болезни и как ее по вашему стоит лечить?
Ну вот например в статье есть упоминание XSS, но проблема-то не в приведенном куске кода, а в произвольном выполнении абы чего на стороне браузера.
Товарищ, который в свое время пилил netscape, вряд ли задумывался о вопросах безопасности. Главное было успеть сделать новую свистелку быстрее конкурентов.
И вот через 30 лет развития всемирной паутины в таком ключе мы имеем то, что имеем...
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Запилил статью на тему используемых алгоритмов в нашем статическом анализаторе: https://habrahabr.ru/company/pt/blog/305000/ В "философию", потому что большинство тезисов оттуда применимы и к задаче анализа кода в целом, не только к поиску уязвимостей
TL/DR для тех, кто поленился читать оригинальную статью тех парней: они взяли стандартный NIST'овский тестовый набор для Java/C и, используя подход, схожий с описанным в моей статье, внесли кейсы этих примеров в реальные опенсорсные проекты, которые затем просканировали двумя неназванными анализаторами (SAST на базе символических выполнений и DAST на базе классического фаззинга). В результате, были обнаружены только около 2% от общего числа кейсов.
Однако же, хотя сама идея получения тест-кейсов на базе реальных проектов достаточно интересна, её реализация не выдерживает никакой критики:
1.
Note that the names of tools under evaluation are being withheld in reporting results. Careful evaluation is a large and important job, and we would not want to give it short shrift, either in terms of careful setup and use of tools, or in presenting and discussing results.
Практически все современные средства DAST и SAST требуют некоторой предварительной настройки на конкретный проект. Некоторые, требуют настройки проекта на конкретный анализатор. Их запуск тупо "с кнопки", в большинстве случаев, приведёт к получению нерепрезентативных результатов анализа.
2. То, что можно формализовать в терминах свойств исследуемого кода, можно детектировать средствами автоматизированного анализа с математической точностью. То, что нельзя формализовать, можно детектировать только эвристиками, что даст в лучшем случае приблизительно равное соотношение фолзов обоих типов к корректным результатам. Значительная часть кейсов тестового набора Juliet содержит примеры недостатков, а не уязвимостей. Разница между ними в причинно-следственной связи: недостаток — это что-то присутствующее или отсутствующее в коде, что далее по коду может привести (а может и не привести) к возникновению уязвимости. Большинство недостатков не формализуемы. Кроме того, задачей средств анализа защищенности является поиск в первую очередь уязвимостей, а не недостатков. Наличие в коде недостатка ничего не говорит о его защищенности — недостаток может и не "выстрелить", а может и вообще являться осознанным решением разработчиков кода (например, использование не криптографически-сильного PRNG там, где этого и не требуется), в отличии от уязвимости.
Собственно, и сами парни в статье пишут, что не стоит делать вывод об эффективности конкретных средств SAST и DAST по их работе. Но тому журналисту, видимо, так не терпелось сорвать покровы, что эту часть он в спешке пропустил =/
Здравствуйте, VTT, Вы писали:
VTT>Ну вот например в статье есть упоминание XSS, но проблема-то не в приведенном куске кода, а в произвольном выполнении абы чего на стороне браузера. VTT>Товарищ, который в свое время пилил netscape, вряд ли задумывался о вопросах безопасности. Главное было успеть сделать новую свистелку быстрее конкурентов. VTT>И вот через 30 лет развития всемирной паутины в таком ключе мы имеем то, что имеем...
Да, а Фон-Нейман не думал к чему приведет его идея хранить данные и код в одной памяти — ему лишь бы побыстрее было свои работы опубликовать. А кто виноват в возможности появления в приложениях ошибок доступа, всевозможных логических `goto fail;` и прочих инъекций в эти ваши shellshock'и — еще предстоит выяснить
Простите, но это космос. А мы люди простые — ходим по земле и стремимся решать проблемы своей предметной области более очевидными и достижимыми способами
Здравствуйте, VTT, Вы писали:
VTT>Ну вот например в статье есть упоминание XSS, но проблема-то не в приведенном куске кода, а в произвольном выполнении абы чего на стороне браузера. VTT>Товарищ, который в свое время пилил netscape, вряд ли задумывался о вопросах безопасности. Главное было успеть сделать новую свистелку быстрее конкурентов. VTT>И вот через 30 лет развития всемирной паутины в таком ключе мы имеем то, что имеем...
Поставить -1 и уйти от диалога — это безусловно удобный способ, но со мной он не сработает. Вы утверждаете, что "болезнь" вы видите в том, что некий меркантильный дядька нагнул весь веб возможностью проведения XSS атак из-за того, что возможно не подумывал о безопасности, когда внедрял свою свистелку. Ок, посыл понятен.
А эффективно бороться с этой "болезнью"-то по вашему как?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Запилил статью на тему используемых алгоритмов в нашем статическом анализаторе: https://habrahabr.ru/company/pt/blog/305000/ В "философию", потому что большинство тезисов оттуда применимы и к задаче анализа кода в целом, не только к поиску уязвимостей
Вот только я не понял, в чём подвох
Подумайте над тем, какова будет мощность множества значений переменной parm1 в последней точке выполнения?
var parm1 = Request.Params["parm1"];
var count = int.Parse(Request.Params["count"]);
for (var i = 0; i < count; i++)
{
i % 2 == 0 ?
parm1 = parm1 + i.ToString():
parm1 = i.ToString() + parm1;
}
Response.Write(parm1);
Практически, parm1 = PrependOdds(count) + parm1 + AppendEvens(count)
Мощности множества префиксов и суффиксов ограничены мощностью множества int'ов.
Единственно, что можно докопаться, — множество исходных строк Request.Params["param1"] счётно. Ну так оно и безо всякого цикла, с самого начала, было счётно.
Перекуём баги на фичи!
Re[2]: [Хабр] Ищем уязвимости в коде: теория, практика и перспективы SAST
Это так. Но задача вывода подобной формулы по циклу упирается всё в те же ограничения тьюринговой модели. Даже наиболее продвинутые научные работы на эту тему покрывают лишь некоторое множество частных случаев. А если цикл еще и неявный и реализован через рекурсию или (не к ночи будет упомянут) goto, то там надо сначала решить задачу распознавания границ итерации и условий выхода из цикла
К>Мощности множества префиксов и суффиксов ограничены мощностью множества int'ов.
Да, в дотнете это 0x7FFFFFFF
К>Единственно, что можно докопаться, — множество исходных строк Request.Params["param1"] счётно. Ну так оно и безо всякого цикла, с самого начала, было счётно.
Множество Request.Params["param1"] на практике еще и конечно, потому что веб-серверы ограничивают максимальную длину URL в GET-запросе (https://boutell.com/newfaq/misc/urllength.html). Тут дело не в этом. Из-за наличия в цикле условия на значение индуктивной переменной, перезаписывающего значение переменной parm1 в обоих ветках, каждая итерация фактически удваивает мощность множества возможных значений parm1. И, если не прибегать к техникам типа LESE, то память для хранения элементов этого множества у нас закончится намного раньше, чем мы дойдем до 0x7FFFFFFF итерации.
Ну нет, это именно вы уходите от диалога в сторону сферической демагогии. Даже фон-Неймана вспомнили...
KV>Вы утверждаете, что "болезнь" вы видите в том, что некий меркантильный дядька нагнул весь веб возможностью проведения XSS атак из-за того, что возможно не подумывал о безопасности, когда внедрял свою свистелку. Ок, посыл понятен.
А что, скажите, что нет?
Сначала эти меркантильные дядьки хотели контролировать, как их УНИКАЛЬНЫЙ сайт отображается на стороне пользователя.
Затем они захотели контролировать, как пользователь взаимодействует с их сайтом.
Еще немного погодя у них возникла крайняя необходимость узнавать, где пользователь находится, послушать его, посмотреть на него.
KV>А эффективно бороться с этой "болезнью"-то по вашему как?
Надо быть проще.
Причем движуха в этом направлении вроде как есть: то выясняют, что 90% браузерных наворотов практически не используются, то хотят, чтобы web-стандарты были похожи на стандарты, а не на каталог аксессуаров для яблочного аппарата, и т.п.
Тенденция к впихиванию дополнительного функционала же явно противоречит тенденции к обеспечению безопасности.
Загвоздка в том, что для многих отказ от постоянного клепания наворотов представляется, как добровольный отказ от конкурентной борьбы.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Поставить -1 и уйти от диалога — это безусловно удобный способ, но со мной он не сработает. Вы утверждаете, что "болезнь" вы видите в том, что некий меркантильный дядька нагнул весь веб возможностью проведения XSS атак из-за того, что возможно не подумывал о безопасности, когда внедрял свою свистелку. Ок, посыл понятен.
KV>А эффективно бороться с этой "болезнью"-то по вашему как?
Как делают электрики, а вернее даже энергетики — проводят работы силами тех специалистов, у кого есть сертификат. За кустарщину — штрафуют и отключают от сети. И с водопроводом также. И с канализацией — ну можно самому где-то сделать выгребную яму, на 101 километре от города.
То есть, берем, и начинем бить по голове за самодеятельность.
Re[5]: [Хабр] Ищем уязвимости в коде: теория, практика и пер
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Вы утверждаете, что "болезнь" вы видите в том, что некий меркантильный дядька нагнул весь веб возможностью проведения XSS атак из-за того, что возможно не подумывал о безопасности, когда внедрял свою свистелку. Ок, посыл понятен.
KV>А эффективно бороться с этой "болезнью"-то по вашему как?
Отменять капитализм с его конкуренцией без правил. Заодно масса других проблем решится.
А если серьёзно — это не техническая, а социальная проблема. И решается она социальными способами.
Кстати, их уже предложили. http://rsdn.org:8888/forum/philosophy/6529104.1
То есть берем состояние и генерируем "обратную" программу которая выдаст входные данные. Задача решаемая но только в множествах естественно.
Перекуём баги на фичи!
