Контакты
Подписка
МЕНЮ
Контакты
Подписка

Защита Web-приложений

Защита Web-приложений

В рубрику "Спецпроект: mobile security" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Защита Web-приложений

Еще восемь лет назад словосочетание “защита Web-” ассоциировалось у меня с DDoS-атакой. Тогда это было интересно. Еще не было мощных, как ныне, организаций, которые способны пропустить через свои сети трафик и поломать нападение.
Андрей Ревяшко
Технический директор, Wildberries

Как сейчас помню тревожный звонок одного из пионеров анти-DDoS-предприятий, настоятельно просящего убрать наш трафик с их канала, т.к. те просто не рассчитывали в своих рекламных проспектах на такой объем. Часто оставались один на один с проблемами нападок на наше Web-приложение. Отключать иностранный трафик на уровне провайдера был не вариант, т.к. добрая часть клиентов приходила через западные сети. Отключить иностранный трафик приравнивалось к отключению части заказов. Садились всем ИТ-отделом за дело – получали слепок IP-адресов посетителей сайта, проверяли их через Whois-сервисы и включали в бан на файрволе, если пул адресов явно принадлежал не нашим клиентам. К примеру, Китаю. Кстати, Азия до сих пор видится мне лидером по числу машин, принимающих участие в ботнетах.

Обращаясь в компании по защите, в частности, Web-приложений от DDoS-атак, закажите услугу мониторинга периметра приложения на уязвимости. К примеру, наличие уязвимого из-за устаревшей версии Web-сервера или наличия опасных Cross-Origin-настроек. Этот второй по популярности метод в моем рейтинге защиты от нападения на Web-приложения поможет оперативнее реагировать на появление новых уязвимостей.

Как бы ни были интересны подобные истории, DDoS – это то, что не обращает внимания на качество безопасности приложений. Поэтому предлагаю оставить борьбу с действиями ботнетов профессионалам, которые на сегодняшний день набрались опыта, силы и способны "переварить" большой объем трафика.

Как рекомендация. Обращаясь в компании по защите, в частности, Web-приложений от DDoS-атак, закажите услугу мониторинга периметра приложения на уязвимости. К примеру, наличие уязвимого из-за устаревшей версии Web-сервера или наличия опасных Cross-Origin-настроек. Это поможет оперативнее реагировать на появление новых уязвимостей – второй по популярности метод в моем рейтинге защиты от нападения на Web-приложения.

Говоря о втором методе, разработчики серьезных требований по безопасности в первых строчках указывают обязательное изучение CVE/CWE-баз данных на постоянной основе. Суть – поиск новых уязвимостей приложений, которые имеются у вас в периметре.

Был случай, когда один из наших системных администраторов вырезал со страничек версию "коробочного" форума после очередного обновления; спросил его: зачем? Мне ответили: чтобы поисковики не показали наш форум в списке, когда злоумышленник будет искать подобные форумы по версии, на которую есть метод использовать ту или иную уязвимость. Именно так и представлена информация в CVE/CWE-базах: ПО + версия + вид уязвимости.

Когда злоумышленники изучают наш сайт в поисках уязвимостей, около недели идут 404-ошибки – верный признак того, что надо "держать ухо востро". Подобные поиски не прерываем, просто ждем и анализируем ситуацию. Если что-то всплывет нежелательное для нашего Web-приложения, надо быть готовыми быстро отреагировать.

Приступая к защите Web-приложения, лучше понимать, как работают злоумышленники (сейчас не говорим про социальную инженерию). Чтобы это понять, возьмите за правило повышать осведомленность сотрудников в области ИБ, особенно принимающих участие в разработке ПО. В нашем случае ПО для Web.

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

Как ни странно, но даже "старенькие" разработчики с опытом находят на встречах что-то новое для себя. Много кто знает, что есть, к примеру, SQL-инъекции, но не каждый может объяснить, что такое CSRF, а значит скорее всего не учтет этот вектор атаки.


Уверен, что защита Web-приложений должна начинаться именно отсюда – с практик OWASP. Не поленитесь, заведите себе в компании мини-лабораторию на виртуальной машине для изучения атак на Web-приложения. К примеру, bWAPP.


Особенно это касается тех, кто использует "коробочные" решения. Как ни крути – в большинстве компаний в подразделениях используются "коробочные" форумы и CMS. Чем не вектор атаки? Защита припаздывает перед появлением новых уязвимостей – правда жизни.

В хакерских дистрибутивах KaliLinux есть даже отдельные утилиты по анализу "коробок", в частности WordPress. Настолько это популярно – начинать взлом со стандартной мелочи.


Это один из примеров того, на что обязательно и систематически надо обращать внимание и что, к сожалению, не делается. Не следится за поступлением новых не только уязвимостей, а даже готовых эксплойтов, через которые способно пострадать ваше Web-приложение. Вроде бы ничего сложного – зайти в Exploit-DB и пройтись по используемому ПО, но людская лень в общей массе сильна.


Про выкладку в Git-репозитории проектов вместе с файлами конфигураций (логины + пароль и адреса баз данных) даже говорить не приходится – классика жанра.

Повторять про существование OWASP и необходимость знакомства с материалами проекта не будем – просто делайте это периодически и организовывайте мероприятия по ознакомлению ваших сотрудников с материалом, чтобы это было интересно. Это будет залогом в защите вашего же Web-приложения.

Напоследок хочется отметить два волнующих момента: анализ кода приложения и Security Development Lifecycle (SDL).

Анализ кода

Мировая статистика говорит о том, что разработчики эффективно могут работать только несколько часов в свой рабочий день. По опыту понимаю, что информация близка к правде. Бывают случаи когда, к примеру, до обеда есть отличные идеи реализации того или иного механизма/функционала, а после мысли становятся какими-то "тяжелыми". В такие моменты работа идет на автомате. Подобные-то "автоматы" и допускают появление "узких" мест в ПО. Хорошо, если ваш код будет проверен кем-то вышестоящим, а если вы senior developer и находитесь в состоянии "автомата"?

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

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

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

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

SDL

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

Защита Web-приложения – это не просто установить и настроить на периметре, к примеру, WAF. Это комплексная работа, в первую очередь защита от DDoS, анализ уязвимостей по OWASP, говоря о "коробочных" решениях.

Когда речь идет о собственных разработках, защита начинается с разработки. И важно организовать каждый этап разработки в безопасном русле. Как это организовать – внедрить в отделе разработки SDL. Пусть каждый этап становления вашего ПО будет осознанным в контексте безопасности. Не стоит забывать о моделировании угроз. К примеру, по STRIDE-подходу. А то из разговоров с коллегами нередко всплывает печальный факт: заявление о внедрении SDL имеется, а угрозы не моделируются. Получается, что защита Web-приложения не предполагает, с какой стороны ожидать подвоха.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #5, 2017

Приобрести этот номер или подписаться

Статьи про теме