Всем привет. Меня зовут Тетка Андрей и я работаю в компании Checkmarx. Мы занимаемся разработкой статических и динамических анализаторов кода на поиск секьюрити уязвимостей и сегодня я хотел бы разобрать какие есть подходы для поиска проблем в коде.

Начнём с того, что есть несколько основных подходов для анализа кода:

1. SAST (Static Application Security Testing) - Статическое тестирование безопасности приложений, также известное как “тестирование белого ящика”, существует уже более десяти лет. Это позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на более ранних этапах жизненного цикла разработки программного обеспечения. Это также обеспечивает соответствие руководящим принципам и стандартам кодирования без фактического выполнения базового кода.

2. DAST (Dynamic Application Security Testing) - Динамическое тестирование безопасности приложений, также известное как тестирование “черного ящика”, может обнаружить уязвимости и слабые места в системе безопасности в запущенном приложении, обычно в веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложение, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, таких как внедрение SQL и межсайтовые сценарии. DAST также может пролить свет на проблемы во время выполнения, которые не могут быть выявлены с помощью статического анализа, например, проблемы с аутентификацией и конфигурацией сервера, а также недостатки, видимые только при входе известного пользователя в систему.

3. IAST (Interactive Application Security Testing) - Интерактивное тестирование безопасности приложений в реальном времени. Поскольку и SAST, и DAST являются более старыми технологиями, есть те, кто утверждает, что им не хватает того, что нужно для защиты современных веб и мобильных приложений. Например, IAST испытывает трудности с библиотеками и фреймворками, используемыми в современных приложениях. Это связано с тем, что статические инструменты видят только исходный код приложения, которому они могут следовать. Более того, библиотеки и сторонние компоненты часто приводят к тому, что статические инструменты захлебываются, создавая сообщения “потерянные источники” и “потерянные приемники”. То же самое относится и к фреймворкам. Запустите статический инструмент на API, веб-службе или конечной точке REST, и он не найдет в них ничего неправильного, потому что не может понять структуру.

4. RASP (Run-time Application Security Protection) - Как и в случае с IAST, RASP, или Защита приложений во время выполнения, работает внутри приложения, но это не инструмент тестирования, а скорее инструмент безопасности. Он подключен к приложению или его среде выполнения и может управлять выполнением приложения. Это позволяет RASP защищать приложение, даже если защита периметра сети нарушена и приложения содержат уязвимости безопасности, пропущенные командой разработчиков. RASP позволяет приложению выполнять непрерывные проверки безопасности и реагировать на атаки в реальном времени, прерывая сеанс злоумышленника и предупреждая защитников об атаке.

Здесь мы рассмотрели основные подходы для поиска секьюрити уязвимостей и как мы видим они абсолютно разные. Где то мы анализируем код, где то мы пытаемся в реальном времени обнаружить атаку и предотвратить её. Обычно все эти подходы используются совместно, на разных этапах разработки приложения.

Но как же конкретно искать секьюрити уязвимости. Давайте на примере SAST рассмотрим два основных подхода для их поиска на примере SQL инъекций.

Первый и наверное самый известный это построение дерева кода и его анализ. В таком случае наш SAST строит внутри себя дерево по которому уже видно какой метод что вызывает и может проанализировать когда мы заходим в какой то метод и передаем параметры, которые могут быть потенциально опасными.

Второй метод это простой анализ текста (который используется в checkmarx). Здесь мы просто анализируем текст программы и при нахождении точки входа(например GET запрос), мы смотрим какие параметры мы передаем туда и следим за ними чтобы они не передавались сразу в базу данных. Нету никакого дерева или других дополнительных структур как у первого варианта, мы просто следим за всеми входящими параметрами и пытаемся их проанализировать, чтобы они не попали напрямую в базу данных. Если при получении параметра мы видим что этот параметр пишется в базу данных без санитайзинга, то мы сразу подсвечиваем это как потенциальную секьюрити уязвимость.

В целом это были основные способы искать секьюрити уязвимости. Какие то варианты работают лучше, какие то хуже, но обычно все они используются совместно, так как могут дополнять друг друга и находить разные типы уязвимостей. Как правило они так же используются на разных этапах разработки программного обеспечения, как показано на картинке чуть выше. Так же поиск секьюрити уязвимостей часто объединяют с проверкой качества кода, так как используются схожие механизмы, что позволяет не только предотвратить потенциальную угрозу, но и так же сохранить продукт более жизнеспособным на долгом промежутке времени.

Анализаторы кода уже давно стали обязательным стандартом при разработке какого либо софта. Уже давно прошёл то время когда софт разрабатывался без тестов, так как тесты стали стандартом нашей индустрии. Так и программные анализаторы кода уже стали им, по этому не принебрегайте программным анализом кода в своём приложении и узнаете много нового о том, что творится в вашем приложении.

Всем спасибо за внимания, если знаете другие подходы, то будет интересно почитать о них в комментариях.