Хабрахабр

Могут ли автотесты заменить человека в поиске уязвимостей: интервью с Александрой Сватиковой

Более 8 лет назад она перешла от разработки на Java к тестированию безопасности приложений. Александра Сватикова работает экспертом по информационной безопасности в Одноклассниках.

Мы взяли у неё интервью, где обсудили:

  • сложно ли перейти разработчику в аналитику приложений;
  • различия в работе пентестера, ресерчера и аналитика;
  • security development lifecycle или SDLC;
  • роль человека в поиске уязвимостей;
  • как обстоят дела с аналитикой безопасности в других компаниях.

Подробнее к её докладу перейдём в конце поста, а пока добро пожаловать под кат. В этой статье не будет хардкора — за ним можно съездить на Heisenbug 2019 Moscow, где Александра расскажет о статическом тестировании безопасности.

Войти в application security не так сложно, как кажется

Почему ты стала заниматься безопасностью приложений? — На кого ты училась?

Я училась на программиста, и в дипломе написано что-то вроде «software engineering». — Я, наверное, не пример для подражания (смеётся). После поиска очередной работы Java-программистом я попала в команду, которая занимается application security — поддержанием связанной с безопасностью части разработки. Работала сначала мобильным разработчиком, затем перешла в веб-разработку на Java. Соответственно, они искали Java-программиста и были готовы научить его безопасности. Там был хорошо организованный сформулированный процесс, и им были нужны люди, которые занимались бы ревью кода и статическими анализаторами. Мне это показалось интересным, так я и осталась.

— Как ты думаешь, в этой области ты останешься надолго, или за этим этапом дальше что-то последует?

Опыта разработки у меня уже меньше, получается. — Думаю, что навсегда останусь, ведь я с 2011 года application security аналитик. Программист должен не бояться рутинных задач, фиксить баги, а у специалиста по безопасности другая специфика, она меня больше привлекает.

— Какие дополнительные области по сравнению с обычной разработкой тебе пришлось освоить?

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

У специалистов по безопасности иногда должна быть подобная точка зрения. Например, 10−15 лет назад считалось, что тестировщики должны сломать систему и найти баг любым способом. Значит, нужно понимать, как система работает в целом.

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

Например, как работает JS, фронт, бэк? — А что-то инженерное, например, сетевые стеки, тебе пришлось изучать с нуля?

Нужно иметь определённый кругозор, но углубление в детали уже зависит от того, чем ты занимаешься. — В принципе, я уже была фуллстек-разработчиком, поэтому понимаю, как работает бэкенд и фронтенд. Это зависит от обстоятельств. Те же разработчики и тестировщики в зависимости от проекта больше знают какие-то системные вещи (например, сетевые протоколы), либо больше знают про фронтенд.

— Насколько тебе кажется реальным, что абстрактный фулстек-разработчик или фулстек-тестировщик, который занимается программированием, автоматизацией и тестированием, перейдёт в анализ приложений, то есть то, чем ты занимаешься?

Обязательно надо обладать какими-то навыками программирования и понимать, как система устроена изнутри. — Тестировщику вообще всё просто. Если это есть, то дальше идёт вопрос специализации: ему надо почитать про безопасность и определённые технологии (например, Android или бэк), то есть то, в чём он пытается найти уязвимости. Но хороший тестировщик без этого уже не существует.

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

Пентестер, ресерчер и application security-аналитик: в чём различие

Насколько соотносятся пентестеры и исследователи уязвимостей нулевого дня, или всё это смешано в один флакон и разобраться, кто есть кто, очень трудно? — Как я понимаю, твоя специализация связана с пентестерами.

Но расскажу, какими терминами оперирует тусовка. — Нет чёткого деления на должности.

Под интересной понимается проблема, которую раньше не находили, или выявили в неожиданном месте, либо это сложная комбинация ранее известных проблем. Есть ресерчеры, которые исследуют продукт, технологию, протокол, сервер в попытке найти интересную проблему. Могу сказать, что как правило, всякие 0day-уязвимости находят ресерчеры.

У тебя есть система, и ты хочешь найти уязвимые места. Пентест — это услуга. Они не смогут найти все потенциальные проблемы. Задача пентестеров — проникнуть в систему. Пентестер будет искать то, что реально эксплуатируется, а после выдаст отчёт и уйдет, поскольку у него нет задачи повышать безопасность системы или настраивать процессы разработки. Например, какая-то уязвимость может быть нивелирована другими механизмами безопасности на разных уровнях.

Они, наоборот, смотрят на систему изнутри. Есть также application security или product security-аналитики. Это значит, что у них есть информация о системе, и она для них не «чёрный ящик». Их задача – сделать систему безопасной. Аналитики рассматривают даже те уязвимости, которые в настоящий момент не могут быть эксплуатированы. С другой стороны, они по-другому ранжируют проблемы. Но человек изнутри понимает, что при определённых обстоятельствах может случиться страшное. Например, в админке критическая дыра, и понятно, что она доступна только из внутренней сети, и поэтому не очень страшно.

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

— Тогда application security-аналитик занимается этим в процессе, day-by-day?

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

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

— Получается, работа application security-аналитика тесно связана с командами и процессом разработки именно внутрь?

SDLC (Secure Development LifeCycle) — это первый buzzword, который встретится, если читать про application security. — Да, application security-аналитик должен поднять вопрос о процессе разработки. Не всегда при этом выполнением конкретных задач занимается именно специалист по безопасности, иногда можно делегировать другим членам команды. Если вкратце, цель этих действий в том, чтобы на каждом этапе разработки были учтены соображения безопасности системы. Ведь чем раньше ты найдёшь проблему, тем дешевле ее исправлять.

Человеческий разум всё ещё незаменим в поиске уязвимостей

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

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

Если взять ту же форму на сайте, то обязательно нужно сделать капчу, чтобы запретить перебор пароля. Также ещё на этапе ТЗ можно предположить, что система будет подвержена определённым уязвимостям, и придётся внедрять некоторые механизмы защиты. Поэтому такие моменты должны быть упомянуты в разработке архитектуры.

То есть чтобы можно было «напедалить» какой-либо пайплайн в Jenkins или TeamCity, и там был отдельный этап, где запускаются тесты на безопасность. — Насколько часто тестирование безопасности встраивается в CI/CD-процессы, и сложно ли это? Насколько это реально?

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

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

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

Аналитика безопасности в других компаниях

— Какая компания или какой отдельный проект, по твоему мнению, является флагманом в application security-аналитике, исходя из выступлений компаний и докладов на конференциях?

Но вот как все устроено у них на самом низком уровне, какие инструменты используются, я не знаю. — Microsoft придумала имплементацию SDLC, которая стала каноном.

Некоторые инструменты Facebook даже являются open source-проектами, поэтому можно поковыряться в их «кишочках». Facebook много пишет про то, как все у них устроено в техническом плане: как они сканируют код, находят уязвимости в работающих системах и т.д.

Хотя application security-команда у них немаленькая, её не хватает на множество разработчиков. Если взять российские компании, то Сбербанк интересно рассказывал про то, как они формализовывали SDLC, документировали процесс. Поэтому они воспитывают security-чемпионов в командах, вкладывают им в голову какие-то знания о безопасности, и в случае чего чемпионы могут поднять красный флаг.

Яндекс рассказывает на конференциях про крутые штуки вроде «как взломать браузер».

Например, компания купит за условные 10 тысяч долларов сканер, который в пайплайне Jenkins ищет «дыры». — Реально ли, что тестировщик после конференции, где услышал доклад про угрозы и инструменты, получит значимый эффект после их внедрения? Или же важнее знание механик эксплуатации уязвимостей, чтобы внедрить какие-то вещи?

долларов ты сканер не купишь (смеётся). — За 10 тыс. Сценарии берутся из сборников общих знаний. Если говорить про поиск уязвимостей, то всё сводится к тестированию конкретных сценариев.

Например, в OWASP Application Security Verification Standard написано обо всем, что нужно тестировать. Например, OWASP (Open Web Application Security Project) публикует гайды, как проводить тестирование безопасности, ревью кода и т.д. Для чтения документа специальных знаний не требуется, достаточно знать о веб-приложениях, поэтому любой тестировщик справится.

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

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

Но когда ты запускаешь сканер, может быть три варианта развития событий:

  1. Инструмент выдал отчет, где много хороших воспроизводимых багов и немного false positive (идеально, но маловероятно).
  2. В отчете 20 тыс. находок, из которых истинных около 1%. Поэтому придётся посидеть и определить, настоящие ли проблемы.
  3. Инструмент не смог что-то понять в системе, поэтому выдал отчёт, в котором всё хорошо, но это не так. Например, не смог скомпилировать код, потому что не нашёл библиотеку. Или это сканер уязвимостей, который сделал 10 запросов, нарвался на антифлуд, и на оставшийся миллион запросов не получил от сервера ответа.

Поэтому, думаю, важно всё же понимать, что у сканера «под капотом», чтобы выбирать соответствующий решаемой задаче инструмент и адекватно оценивать полученный результат.

Там она расскажет о применении и кастомизации SAST-решений SonarQube и Find Security Bugs для поиска уязвимостей в своём проекте. Тему правильного выбора и настройки инструментов Александра разовьёт в своём докладе на Heisenbug. А как самостоятельно расширить их функциональность? Какие возможности эти инструменты предоставляют «из коробки»? В качестве примера спикер рассмотрит уязвимости XSS и IDOR.

Конференция пройдёт 5-6 декабря в Москве.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть