Мы открыли публичное тестирование .NET-версии библиотеки LibProtection. Для тех, кто принимал участие в моём докладе с ноябрьского DotNext и в курсе того, что эта библиотека делает: доступны репозиторий и тестовый сайт, имитирующий уязвимое приложение, защищённое с помощью LibProtection. На сайте можно заценить её функциональность и потестировать на возможные байпассы и ложные срабатывания (вот тут будем рады любой помощи).
Для тех, кто не в курсе: LibProtection предоставляет альтернативную реализацию форматных и интерполированных строк, которая позволяет разработчикам не задумываться о проблеме инъекций в различные грамматики: о санитизации входных данных, их валидации в рамках проблемы инъекций -- вот это всё. Уже сейчас поддерживаются грамматики HTML, URL, JavaScript, SQL и файловые пути.
Работает это примерно так: при форматировании/интерполировании строки автоматически определяется граматический контекст для каждого из плейсхолдеров, на основе которого выводится функция кодирования значения, переданного в плейсхолдер. Далее, выведенные функции применяются и результат форматирования/интерполяции подвергается валидации по формальным признакам атак инъекции (которым и был посвящён упомянутый выше доклад). Если валидация завершается успешно, то результирующая строка отдаётся в вызвавший библиотеку код. Если же нет, то выбрасывается исключение, либо возвращается false (в зависимости от того, какой из методов библиотеки был использован).
Поиграться с конкретными примерами работы библиотеки, как я уже написал выше, можно на тестовом сайте
В этот четверг провожу вебинар, посвящённый принципам работы библиотеки и формальной модели атак инъекций. Также расскажу (и покажу на конкретных примерах), почему параметризация и объектный подход не являются панацеей и могут приводить к возникновению уязвимостей, даже в простейших случаях.
Участие в вебинаре бесплатное, требуется регистрация (по ссылке выше)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Для тех, кто не в курсе: LibProtection предоставляет альтернативную реализацию форматных и интерполированных строк, которая позволяет разработчикам не задумываться о проблеме инъекций в различные грамматики: о санитизации входных данных, их валидации в рамках проблемы инъекций -- вот это всё. Уже сейчас поддерживаются грамматики HTML, URL, JavaScript, SQL и файловые пути.
Очень-очень вредный совет. Cтранно слышать это от профессионала
Здравствуйте, koandrew, Вы писали:
K>Очень-очень вредный совет. Cтранно слышать это от профессионала
В процитированном тобой тексте никаких советов вроде нет Попробую "угадать", ты имеешь в виду, что прямую работу со строками (даже защищённую, как в случае с данной библиотекой) использовать не стоит, а стоит смотреть в сторону средств параметризации и объектного подхода?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>В процитированном тобой тексте никаких советов вроде нет Попробую "угадать", ты имеешь в виду, что прямую работу со строками (даже защищённую, как в случае с данной библиотекой) использовать не стоит, а стоит смотреть в сторону средств параметризации и объектного подхода?
Я имел в виду совет "не задумываться". Это очень опасный совет.
Здравствуйте, koandrew, Вы писали:
K>Я имел в виду совет "не задумываться". Это очень опасный совет.
Исходя из собственных наблюдений, могу сказать, что наиболее серьёзные уязвимости чаще всего появляются не тогда, когда разработчик не задумывался над вопросами безопасности, а когда жестоко ошибался, считая, что задумался над ними в достаточной степени. За 5+ лет работы с сообществами и командами разработчиков, чтения им докладов и обучающих курсов, а также разбора тонн уязвимого кода -- могу сказать, что количество разработчиков, как способных, так и готовых в достаточной степени задумываться над вопросами безопасности их приложений, находится где-то на уровне статистической погрешности.
А, следовательно, проблема есть и её необходимо решать. Если у разработчика нет каких-либо знаний, их ему всегда можно дать. Но что делать в том случае, когда у разработчика нет возможности уделять достаточное количество времени применению этих знаний в своей деятельности? Ответ очевиден -- уменьшать это самое "достаточное количество", автоматизируя то, что не требует от разработчика принятия каких-либо решений.
Так вот под "не задумываться" здесь подразумевалось именно "не тратить время". Как и любая другая библиотека, LibProtection скрывает за своим API весьма рутинную и нетривиальную логику, реализовать которую вручную, под силу далеко не каждому разработчику при том, что она неплохо формализуется и автоматизируется.
Но, даже если говорить о "не задумываться" в прямом смысле, почему собственно нет? Когда разработчик использует параметры в SQL-запросе, разве ему нужно задумываться о том, что в точке выполнения запроса у него произойдёт SQL-инъекция? Или о коде, который будет сгенерирован Razor'ом по параметризованной разметке? Или об SQL-запросах, сформированных ORM на основе входных данных? Иногда такая необходимость, разумеется, есть, но цель всех этих средств (в том числе) -- как раз избавление разработчика от рутины, которую можно автоматизировать, чтобы дать ему возможность сосредоточиться на решении своей основной задачи.
И LibProtection здесь не исключение. Фактически, она является средством параметризации текстов сразу для нескольких грамматик, в произвольном синтаксическом контексте (в отличие от традиционных средств, поддерживающих 2-3 контекста максимум) и с дополнительной фичей по контролю корректности преобразованных параметров перед передачей сформированного текста в потенциально-опасную операцию. И при этом, не требует от разработчика каких-либо знаний в предметной области безопасности.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Поиграться с конкретными примерами работы библиотеки, как я уже написал выше, можно на тестовом сайте
Не очень понял описание тестового сайта:
This site mimics the behavior of a vulnerable web application that performs string formatting via LibProtection library API to generate the arguments for the potentially vulnerable operations based on the input data.
Если используется LibProtection library, то почему приложение в итоге vulnerable? В чём тогда смысл библиотеки? Или имелось в виду, что было бы уязвимо без использования библиотеки? Но дальше всё равно сказано, что опасные операции будут выполнены...
Здравствуйте, User239, Вы писали:
U>Если используется LibProtection library, то почему приложение в итоге vulnerable? В чём тогда смысл библиотеки? Или имелось в виду, что было бы уязвимо без использования библиотеки? Но дальше всё равно сказано, что опасные операции будут выполнены...
Представьте себе гипотетическое приложение, в котором используется string.Format для формирования аргумента некоторой потенциально опасной (с точки зрения атак инъекций) операции. Форматная строка при этом жестко задана в коде этого приложения и является константой, а её аргументы формируются на основе входных данных, без должной предварительной обработки. Это делает приложение уязвимым к атакам инъекций в аргумент потенциально опасной операции. Библиотека позволяет устранить уязвимость к таким атакам в том числе с помощью простой замены string.Format на SafeString.Format. Тестовый сайт имитирует поведение именно такого приложения, использующего SafeString.Format для защиты от атак инъекций. Потенциально опасные операции при этом не имитируются, а выполняются абсолютно честно (т.е. SQL-запросы действительно уходят в движок SQLite, файлы действительно читаются, JavaScript действительно выполняется и т.п).
Для того, чтобы позволить пользователям оценить работу библиотеки на этом кейсе в полной мере, на сайте оставлена возможность задавать произвольные форматные строки (являющиеся константами в гипотетическом имитируемом приложении). Поэтому ничто не мешает* вбить в качестве форматной строки что-то типа "DROP TABLE {0}", а в качестве её аргумента указать имя таблицы. Это не является атакой инъекции, т.к. имя таблицы -- это один токен и нарушения целостности SQL запроса в данном случае нет.
В дисклеймере речь идёт именно о таких кейсах.
* на самом деле, мешает, но с библиотекой это никак не связано и сейчас дисклеймер оставлен только потому, что в самой библиотеке всё ещё могут быть ошибки, которые позволят обойти механизмы защиты. После окончания бета-тестирования мы его, разумеется, уберём.
Попробую "угадать", ты имеешь в виду, что прямую работу со строками (даже защищённую, как в случае с данной библиотекой) использовать не стоит, а стоит смотреть в сторону средств параметризации и объектного подхода?
