Существуют различные методы проверки кода приложения на безопасность. Одним из таких методов является анализ исходного кода, также известный как статическое тестирование безопасности приложений (SAST). В этой статье представлен обзор подхода SAST и определены преимущества и недостатки по сравнению с другими методами тестирования.

Работа этического хакера и пентестера разнообразна. Помимо классических тестов на проникновение, в которых пентестер занимает позицию хакера в черной шляпе, то есть настоящего злоумышленника, существуют и другие формы анализа безопасности. Сюда также входит автоматическое тестирование безопасности приложений с использованием соответствующих инструментов. Мы различаем различные варианты, в том числе:

Статическое тестирование безопасности приложений (SAST): здесь исходный код анализируется «оффлайн», то есть без запуска приложения.

Динамическое тестирование безопасности приложений (DAST). В этом варианте приложение выполняется, и специальные входные данные используются для проверки того, ведет ли программа ожидаемое поведение, реагирует ли она неожиданно или даже выходит из строя.

Тестирование безопасности приложений на основе обратной связи (FAST). Это дальнейшее развитие подхода DAST, при котором входные данные систематически дорабатываются с использованием фаззинга. Таким образом, ввод корректируется в соответствии с обратной связью от приложения через механизм мутации, чтобы в каждом последующем раунде делать более целевые записи, которые призваны спровоцировать ошибки в приложении.

Ниже мы рассмотрим SAST и выделим сильные и слабые стороны этого метода.

Анализ исходного кода часто является частью анализа безопасности в рамках теста на проникновение. Код конфиденциально предоставляется пентестеру для тестирования в рамках теста «белого ящика». Даже код, который был опубликован намеренно или непреднамеренно (здесь мы говорим об «утечке») обычно анализируется и проверяется различными сторонами.

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

Вместо этого код (также часто называемый исходным кодом) анализируется в автономном режиме и проверяется на наличие уязвимостей. Сегодняшние приложения часто содержат многие тысячи строк кода и больше не могут быть проверены полностью вручную.

Поэтому обычно используются соответствующие инструменты, которые проводят автоматизированный анализ кода и проверяют его на наличие возможных уязвимостей. Существуют различные инструменты с открытым исходным кодом и коммерческие инструменты для всех мыслимых языков программирования. На странице проекта OWASP представлен обзор инструментов. Критерии выбора подходящего инструмента также можно найти здесь.

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

Результаты анализа включают критические строки кода и точное местоположение в коде, чтобы разработчики и пентестеры могли быстро определить проблему. С другой стороны, такой автоматизированный подход далеко не раскрывает всех уязвимостей. Уязвимости аутентификации и доступа не могут быть идентифицированы таким способом.

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

Раскрытые источники необходимо проверить, чтобы определить, действительно ли конкретный случай представляет собой уязвимость, которую можно использовать, или же код в контексте безвреден для целостности приложения. Для этого аналитик должен, с одной стороны, иметь четкое представление о концепциях программирования и конкретном языке программирования, а с другой стороны, иметь представление о подходах и концепциях, в соответствии с которыми проводится ручной анализ исходного кода. Это понимание необходимо для эффективного анализа.

Что действительно важно, так это понимать, что любые действия пользователей программного обеспечения могут быть потенциально опасными. Для анализа исходного кода это означает, что должны быть идентифицированы все точки, в которых обрабатываются входные данные. Этот вход также называется «Источники». Многие языки программирования также имеют ряд потенциально опасных функций.

Это могут быть, например, функции, выполняющие команды на уровне системы, или функции, загружающие и исполняющие другой исходный код. Также следует отметить файловые операции, то есть функции, которые записывают что-то в файл или манипулируют им другим способом, например, удаляют, изменяют и т. д. Эти функции называются «Приемниками».

Чтобы найти «приемники», вы можете просто автоматически выполнить поиск по всему исходному коду по соответствующим именам функций. Поскольку аналитику при анализе исходного кода приходится концентрироваться на потенциально небезопасных частях, теперь он может целенаправленно искать источники и приемники. Как только соответствующие части исходного кода будут идентифицированы, он сможет систематически понимать, достигает ли пользовательский ввод из одного из источников одного из приемников.

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

Однако часто случается, что со временем код становится очень сложным и запутанным даже для разработчиков. Чем больше возможностей и функций встроено, тем больше вероятность того, что пользовательский ввод будет обработан там, где этого не ожидают разработчики.

Анализируя исходный код, аналитик может подходить к нему с разных сторон. Например, если приемников много, а источников мало, то имеет смысл двигаться дальше по коду и проверять все возможные пути источников. Если приемников немного, он может вернуться по коду и проверить, можно ли отследить один из источников.

Этот подход может обнаружить множество критических проблем, но, к сожалению, недостаточно сосредоточиться на вводе пользователя и потенциально опасных функциях. Аналитик теперь может исключить возможность того, что пользователь может выполнить код или внедрить что-то вредоносное, но он по-прежнему мало что знает о логической структуре и функциональности программы.

Поэтому после приблизительного общего обзора стоит разбить код на отдельные функциональные части. Какая часть кода отвечает за аутентификацию пользователей? Есть ли функция сброса пароля? Где именно код взаимодействует с базой данных? Эти и другие вопросы требуют прояснения, и это всего лишь несколько примеров того, как части приложения могут определять безопасность. Прежде всего следует обратить внимание на то, как логически структурирован код, какие есть проверки, какие функции используются для проверки и насколько на самом деле сложен и запутан код.

Становится ясно, что SAST — важный инструмент анализа безопасности приложений, но не панацея. Из-за многочисленных ложных отчетов инструмента SAST существует риск того, что важные ошибки будут упущены из виду во время анализа. Несмотря на автоматизацию, такой анализ часто занимает много времени, если все отчеты приходится проверять на актуальность.

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

Этот подход предполагает взаимодействие с программой во время выполнения для проверки ее обратной связи и реакции. Это дает то преимущество, что генерируется очень мало ложных срабатываний, но с другой стороны, есть проблема: даже если входные значения тщательно выбраны, не весь код можно протестировать. Каждая форма анализа имеет свои преимущества и недостатки. Поэтому аналитик должен четко понимать значение используемого варианта и его ограничения.

Важно отметить, что не только вредоносное ПО и вирусы влияют на работу сайта, а и многие другие факторы. Но, какова бы ни была причина, по которой страница сайта не открывается, например проблемы с базой данных или сервером, DDoS-атаки или вирусы, важно контролировать доступность сайта для посетителя. Ситуация, при которой пользователь не может открыть страницу вашего сайта, отрицательно влияет на поднятие сайта в поиске (поисковой выдаче) и оставляет негативное впечатление о вашем сайте у посетителя. Вы теряете потенциальных клиентов, а значит и деньги. Используйте хороший сервис, например BAILRY для постоянного контроля (проверки) доступности сайта. Сервис предоставляет как бесплатную регулярную (периодическую) проверку доступности сайта, так и платную услугу - для постоянного контроля доступности сайта.

Компания Mainton - разработка и тестирование программного обеспечения под заказ, SEO и реклама в интернете с 2004 года.