безопасность серверной части веб приложений часть 1
Лекция 16: Обеспечение безопасности веб-приложений
В данной лекции рассматриваются некоторые наиболее распространенные уязвимости веб-серверов и методы, противодействующие использованию данных уязвимостей.
В последние годы число атак, нацеленных на веб-сервера, значительно возросло. Веб-серверы особенно уязвимы в силу своей открытости, поскольку рассчитаны на обмен информацией с пользователями.
Веб- сервер формируется несколькими слоями ПО (рис. 23.1), каждый из которых подвержен разнообразным способам атаки
Обеспечение безопасности операционной системы реализуется путем установления последних обновлений системы безопасности, регулярно выпускаемых разработчиками этой ОС.
Атаки веб-серверов можно разделить на две категории: локальные и глобальные.
Локальные атаки обычно направлены на кражу информации или перехват управления на отдельном веб-сервере.
Глобальные атаки обычно направлены на несколько веб-сайтов и ставят своей целью заражение всех их посетителей.
Наиболее опасные виды сетевых атак
Spyware. Эта разновидность программ не обязательно вредоносна. Некоторые разработчики ПО встраивают такие программы в свои продукты, чтобы отслеживать предпочтения своих клиентов. К сожалению, не все эти программы столь безобидны. Некоторые программы spyware в соответствии со своим названием отслеживают действия хозяина машины, куда эта программа внедрена (нажатия клавиш, посещаемые сайты, конфиденциальную информацию и т.д.) и передают результаты своему хозяину. Заражение spyware может осуществиться традиционно через почту, IM ( Instant Messaging ) или в результате посещения скомпрометированного сайта.
Атаки на веб-серверы
Одним из основных инструментов вторжения в последнее время стала атака типа «drive-by download » ( загрузка файлов или скриптов без ведома хозяина). Разнообразие мультимедиа форматов также облегчает работу хакеров. Ведь пользователя обычно не удивляет необходимость загрузки новейшей версии кодека или драйвера для просмотра или прослушивания материала, размещенного на удаленном сервере.
Вредоносной может быть ссылка с использованием уязвимого веб-сайта:
Страница же отклика должна иметь вид (как результат исполнения wellcome.cgi):
Файлы cookie
Большинство браузеров поддерживают два метода, которые веб-приложения могут использовать для сохранения информации о запросах клиентов: обычные файлы cookie и файлы cookie сеанса.
Файл cookie сеанса позволяет веб-приложениям хранить данные в памяти.
Различие между двумя методами заключается в том, что обычный файл cookie сохраняется на компьютере пользователя и остается на нем до момента удаления пользователем. Файл cookie сеанса, напротив, хранится только на протяжении времени работы компьютера и автоматически теряется при закрытии приложения-браузера. При этом оба файла подвержены манипуляциям извне.
SQL-инъекция
XSS (межсайтовый скриптинг)
После ввода имени в веб-форме сайт отображает на странице соответствующее сообщение. Если указать в форме имя » John «, то сообщение будет иметь следующий вид: » Your name: John «.
Что произойдет, если вместо имени ввести следующую конструкцию:
Веб-приложения — неотъемлемая часть рабочего процесса большинства организаций — АБС системы банков, CRM, 1C и другие программы, которыми ежедневно пользуются сотрудники. Они аккумулируют в себе огромное количество данных, обладающих коммерческой ценностью. Поэтому способствовать обеспечению безопасности веб-приложений — одна из ключевых задач для минимизации финансовых и репутационных рисков бизнеса.
Зачем нужна защита web-приложений?
Безопасность веб-приложений — это защитные меры, при которых злоумышленник не сможет получить доступ к конфиденциальным данным как извне при попытке взлома, так и внутри компании через нелегитимный доступ.
А если инсайдером окажется привилегированный пользователь — он не сможет воспользоваться конфиденциальными данными, так как его нетипичное поведение будет расценено как аномалия, и об этом немедленно будет оповещена служба информационной безопасности.
Веб-приложения становятся финансово-привлекательными не только для их разработчиков, но и для желающих нелегально воспользоваться данными, хранящимися в них. Виды и число атак на них растут в геометрической прогрессии. Атаки можно условно поделить на две категории угроз ИБ:
нарушение конфиденциальности информации;
нарушение доступности информации.
Наиболее распространенная угроза безопасности web-приложений — это эксплуатация уязвимостей, а при популяризации приложения в интернете — не избежать и DDoS-атак. Для взлома и вывода приложения из строя могут использоваться различные инструменты как любительские, так и профессиональные кибератаки и использование автоматических систем сканирования для эксплуатации уязвимостей.
Первый шаг злоумышленника при попытках атак — сканирование с помощью различных утилит. Это может увидеть администратор по частому обращению с одного IP-адреса к разным страницам и большому числу ошибок 404. Поэтому безопасность веб-приложений начинается с непрерывного мониторинга.
Защита веб-приложений актуальна в любых условиях — в том числе и внутри периметра компании. В большинстве случаев доступ к ним имеют не только офисные работники, но и удаленные сотрудники, которые нередко заходят в них с личных компьютеров в обход VPN. И если не обеспечить непрерывный мониторинг доступа к запросам и ответам, может произойти утечка ценной информации.
Чем грозит утечка конфиденциальной информации из веб-приложения?
Риски делятся на две основные группы:
Например, «горячие» лиды из CRM могут быть перепроданы прямым конкурентам нечестным сотрудником. Утечка клиентской базы, в результате которой клиентские данные оказались в продаже на черном рынке или выложены в публичный доступ, подрывает доверие к организации и влечет ответственность в виде штрафных санкций регуляторов.
Поэтому использование веб-приложений в бизнесе и в работе с конфиденциальными данными невозможно без продуманной всесторонней защиты от всех типов существующих угроз и предиктивным подходом к безопасности.
Как обеспечить безопасность web-приложений?
Приложения доступны из Интернета, чем привлекают внимание злоумышленников. Для получения доступа к конфиденциальным данным в них содержащихся, они применяют разнообразные векторы атак.
Прямой способ защиты приложений — межсетевой экран или брандмауэр. Для большего числа веб-приложений применяется прикладной сетевой экран Web Application Firewall (WAF). Если же мы говорим о бизнес-приложениях, которые содержат базы коммерческих и персональных данных, — то здесь требуется другой тип защиты — брандмауэр баз данных Database Firewall (DBF). Это позволяет защитить конфиденциальные данные на разных уровнях.
Применение специализированных решений по информационной безопасности позволяет обнаружить и предотвратить атаки на прикладном и сетевом уровне и реализовать комплекс мер, чтобы обеспечить доступность и непрерывность работы web-приложений за счёт защиты от различных классов атак.
Межсетевой экран автоматически обнаруживает и блокирует атаки на веб-приложения и определяет нелегитимных пользователей, пытающихся проникнуть в веб-приложение.
К основным мерам относятся:
проверка данных на соответствие стандартам протоколов;
контроль трафика на основе нейронных сетей;
защита от SQL-инъекций;
протекция от межсетевого скриптинга (XSS);
контроль доступа к конфиденциальным данным.
Внедрение программно-аппаратных комплексов снижает риски несанкционированного доступа к критичной информации и эксплуатации уязвимостей системного ПО. Более того, наличие специализированных решений по информационной безопасности позволяет обеспечить законодательные требования по защите персональных данных, а также банковских стандартов (СТО БР) и стандарта безопасности данных индустрии платежных карт PCI DSS в вопросах защиты веб-приложений.
Применение специализированных систем защиты web-приложений позволит своевременно обнаруживать и предотвращать попытки несанкционированных действий злоумышленников как внутри организации, так и извне.
Кроме выявления и блокировки атак для защиты данных в приложениях требуется непрерывный мониторинг доступа к базам данных и анализ поведения пользователей и систем. Эти функции обеспечивают решения класса DAM (database activity monitoring). Рассмотрим подробнее принцип работы таких решений.
DAM и DBF — классы систем для защиты веб-приложений
Веб-приложения тесно связаны с СУБД, поэтому атаки, направленные на них могут быть критичными. Получая доступ к приложению, злоумышленник может не только деактивировать его работу, но и завладеть ценной информацией, что грозит крупными финансовыми и репутационными рисками.
Согласно исследованию «Гарда Технологии», базы данных страховых и финансовых компаний оказываются на черном рынке преимущественно из автоматизированных систем, работающих через приложения. Риски утечек могут оцениваться в миллионы долларов. Прибавьте сюда штрафные санкции от регуляторов за нарушение закона о персональных данных и снижение уровня доверия клиентов. Поэтому игнорировать вопрос защиты веб-приложений при веде́нии бизнеса — опрометчивое решение.
Как говорили выше, чтобы защитить бизнес-приложения от современных угроз, одного WAF и сигнатурных средств недостаточно. Требуются специализированные решения для обеспечения безопасности баз данных. Средства по защите баз данных и веб-приложений относятся к классам Database firewall (DBF) / Database Activity Monitoring (DAM) – это аппаратно-программные комплексы для мониторинга, аудита и контроля доступа к информации и защиты от целевых атак на них. Есть решения, объединяющие в себе функциональные возможности по мониторингу, аудиту и защите от атак на базы данных.
В качестве основных функций систем DAM/DBF выделим следующие:
защита от внешних атак;
выявление уязвимостей БД;
обнаружение неучтенных конфиденциальных данных в базах приложений;
блокировка неавторизованных или нетипичных запросов и ответов;
проверка данных на обезличенность при передаче;
тотальный контроль всех запросов к БД и настраиваемые политики безопасности;
построение профилей пользователей и выявление подозрительной активности;
автоматическое сканирование БД на наличие конфиденциальной информации;
расследование инцидентов безопасности;
предотвращение утечек данных.
Обеспечение информационной безопасности веб-приложений с помощью специализированных систем — это комплексная задача бизнеса и возможность нивелировать риски.
Отечественное решение для информационной безопасности веб-приложений
Первое российское решение для обеспечения безопасности веб-приложений классов DBF и DAM стал аппаратно-программный комплекс «Гарда БД» от производителя систем информационной безопасности «Гарда Технологии».
«Гарда БД» изначально разрабатывалась как система защиты баз данных и веб-приложений. И большинство практических кейсов как раз связано с CRM, 1C, банковскими АБС и другими приложениями, которые используются в ежедневной практике работы сотрудников.
Это система аудита и блокировки сетевого доступа к базам данных и бизнес-приложениям. За счет непрерывного мониторинга обращений к базам данных и веб-приложениям детектирует подозрительные действия в реальном времени.
«Гарда БД» за счет сочетания технологических возможностей обеспечивает комплексную защиту: хранение запросов и ответов для дальнейшего ретроспективного анализа, автоматический поиск неконтролируемых баз данных, поведенческий анализ и выявление нарушений политик ИБ, аналитика и автоматическое уведомление об аномалиях.
Систему отличает скорость анализа трафика свыше десяти Гбит/с, что позволяет мгновенно реагировать на аномалии и информировать об этом службу безопасности, ни один подозрительный запрос или атака не останутся незамеченными.
Поведенческая аналитика позволяет выявлять отклонения от нормального поведения сотрудников или приложений. Все данные собираются в наглядные статистические отчеты, где можно видеть все логины, IP-адреса и запросы к базам данных и приложениям за конкретный период времени, а также большое количество запросов и множественные неуспешные авторизации. Контроль осуществляется по протоколам передачи данных HTTP/HTTPS и протоколам аутентификации.
АПК «Гарда БД» — прогрессивное решение, которое позволяет предотвратить инциденты уже по первым признакам аномального поведения пользователей и систем и обеспечить защиту web-приложений от всех видов угроз. Для тестирования системы в организации предусмотрен бесплатный пилотный проект. Уже за первый месяц работы системы удается предотвратить инциденты информационной безопасности в бизнес-приложениях.
Безопасность в продуктах Microsoft глазами IT-специалиста. Часть 1
В первой части статьи будет рассказано об основных угрозах для серверных и клиентских приложений.
Автор: Богданов Марат (bogdanov_marat@mail.ru)
Безопасность в продуктах Microsoft глазами IT-специалиста – рекомендации для технических специалистов, нацеленные на обеспечение безопасности серверных продуктов или рабочей среды пользователя
Часть I. Основные угрозы для серверных и клиентских приложений.
В первой части статьи будет рассказано об основных угрозах для серверных и клиентских приложений, во второй части мы рассмотрим шаги Microsoft, направленные на обеспечение информационной безопасности, а также обсудим рекомендации для специалистов, обеспечивающих безопасность серверных и клиентских приложений.
1. Угрозы для серверных и клиентских приложений
Угрозу для информационных систем представляют случаи как намеренного, так и ненамеренного причинения вреда пользователями, обслуживающим персоналом и третьими лицами. К случаям намеренного причинения вреда можно отнести кражу оборудования и носителей информации, а также такие злонамеренные действия, как взлом, применения вредоносных программ и мошенничество. К случаям непреднамеренного причинения вреда можно отнести различные проявления халатности (потеря оборудования, случайное разглашение секретных сведений, неправильное размещение данных).
На рис. 1. показана динамика случаев нарушения безопасности за период с первого полугодия 2008-г года (1П08) по второе полугодие 2009-го года [1].
Рис. 1. Случаи нарушения безопасности по типу инцидентов [1]
Из рисунка видно, что неуклонно снижается количество краж оборудования и носителей, а также случайных потерь учетных записей на веб-сайтах. Выяснилось, что число случаев взлома, применения вредоносных программ и мошенничества значительно меньше числа случаев халатности (кража или потеря оборудования, случайное разглашение или неправильное размещение) [1]. Несмотря на общее снижение числа инцидентов, количество атак на основе вредоносных программ остается неизменным.
Поговорим об угрозах для информационных систем, основанных на применении вредоносных программ.
Применение вредоносных программ обычно связано с уязвимостями.
Уязвимости — это слабые места программного обеспечения, используя которые злоумышленнику может нарушить его целостность, доступность или конфиденциальность. Некоторые из наиболее опасных уязвимостей позволяют запускать на зараженном компьютере произвольный программный код. Разглашение — это обнародование данных об уязвимости программного обеспечения. Этот термин не относится к нарушению конфиденциальности ограниченным числом людей [1].
Говоря о вредоносных программах, мы часто упоминаем термин «эксплойт».
Эксплойт — вредоносный код, предназначенный для заражения компьютеров без согласия пользователя и нередко без его ведома. Эксплойты часто распространяются через веб-страницы, хотя злоумышленники также использую и другие способы распространения, например с помощью электронной почты или обмена мгновенными сообщениями [1].
1.1. Историческая справка
Десять лет назад серьезной опасности подвергался сетевой уровень информационных систем. Так, в мае 2000-го года вирус ILOVEYOU поразил миллионы компьютеров, июль 2001-го года был отмечен широким распространением вируса Code Red, сразу после атак 11 сентября 2001-го года началась эпидемия Nimda [2]. Мишенями червя Nimda, вызывающего замедление сетевого трафика, были компьютеры с Microsoft Web Server, Internet Information Server (IIS), а также пользователи, открывшие электронную почту с присоединенным вложением [2]. В 2003-м году возникла эпидемия вируса SQL Slammer, использовавшего бреши в MS SQL Server. Угроза была устранена через 6 месяцев. За это время вредоносная программа поразила 75000 серверов, включая компьютеры Bank of America, сети платежных терминалов в Вашингтоне, авиакомпанию Continental, сеть МЧС в Сиэтле и атомную электростанцию в Огайо [2].
Позднее акцент сместился на уровень приложений, в частности, воспользовавшись брешью в безопасности платежной системы Heartland, хакеры взломали 100 миллионов кредитных карточек [2].
Примерно в середине декады, на первый план вышли уязвимости веб-приложений, которые превысили уязвимости сетевого уровня и в конце десятилетия составили около 80% от общего числа уязвимостей.
Все большую актуальность приобретают кибератаки и кибертерроризм. В качестве примера можно привести операцию «Аврора», проведенную китайскими хакерами. В тоже время атакам подвергались социальные сети, такие как FaceBook и Twitter. В ходе атаки RockYou пострадало 32 миллиона учетных записей пользователей. Российские хакеры периодически взламывают миллионы кредитных карточек. Атакам продолжают подвергаться сайты университетов, предприятий розничной торговли, государственные учреждения [2].
1.2. Основные угрозы для веб-приложений
Рис. 2. Распределение уязвимостей во второй половине 2009 года [2]
Из рисунка видно, что 19% уязвимостей приходится на Cross-Site Scripting (XSS), 16% приходится на SQL Injection, 8% на веб-браузеры. Большая часть уязвимостей (44%) приходится на остальные уязвимости (рис. 3).
Рис. 3. Остальные уязвимости веб-приложений (вторая половина 2009-го года) [2].
1.3. Уязвимости коммерческих веб-приложений
Как уже говорилось выше, 89% всех уязвимостей пришлось на код коммерческих веб-приложений.
В коммерческих приложениях самыми распространенными уязвимостями были межсайтовый скриптинг (XSS) и SQL-инъекции, в приложениях для личного пользования преобладают такие уязвимости как утечка данных, межсайтовый скриптинг и управление сессиями [2].
В топ 10 уязвимостей второй половины 2009 года вошли такие известные имена как Adobe, HP, Sun, Citrix и Oracle. Продукты Adobe включающие Flash, ColdFusion и Reader, были одними из наиболее часто взламываемых [2].
1.4. Уязвимости веб-браузеров
Уязвимости браузеров составили 8% от общего числа уязвимостей. Среди веб-браузеров на первом месте по числу уязвимостей оказалась Mozilla Firefox (77 уязвимостей или 44% от общего числа, непропатчены 12%), у Internet Explorer было 44 уязвимости (25% от общего числа, непропатчены 36%), Safari и Google Chrome имели по 25 уязвимостей каждый (по 14% от общего числа), у браузера Opera было отмечено 3 уязвимости (2% от общего числа, 33% непропатчены) (рис. 4) [2].
Рис. 4. Количество зарегистрированных и пропатченных уязвимостей у различных браузеров [2].
1.5. Уязвимости веб-серверов
Что касается веб-серверов, на первом месте была Websphere (51%), далее шли Apache (33%), IIS (12%), Domino (4%).
Рис. 5. Уязвимости веб-серверов (конец 2009-го года) [2].
1.6. Распределение уязвимостей веб-приложений
93% веб-приложений имеют уязвимости, могущие привести к потере или разглашению данных в процесс их передачи. Кроме того, в веб-приложениях отмечен целый ряд других уязвимостей (рис. 6) [2].
Рис. 6. Процентное соотношение уязвимостей различных типов в веб-приложениях [2].
Рассмотрим распространенные уязвимости веб-приложений подробнее.
Утечки информации и разглашение конфиденциальных сведений (93%)
Транзакции в процессе обычного использования веб-приожений могут раскрыть секретную информацию, принадлежащую другим пользователям. Существует возможность вызвать ошибку приложения за счет ввода неправильной последовательности символов, могущих содержать секретную информацию. Другим примером утечек информации являются HTML-комментарии, которые могут сообщить хакеру информацию о приложении или архитектуре [2].
Межсайтовый скриптинг (81%)
Межсайтовый скриптинг позволяет хакеру нарушать целостность кода приложения за счет размещения злонамеренных сценариев в само приложение, часто прямо в базу данных. Это позволяет воровать куки пользовательских сессий, мошенничать или перенаправлять пользователей на вредоносные веб-сайты. В настоящее время межсайтовый скриптинг активно развивается [2].
Недостатки авторизации и аутентификации (71%)
Недостаточная аутентификация наблюдается тогда, когда уязвимость в веб-приложении позволяет пользователю войти в систему без ввода корректных учетных данных, например, благодаря хакерской атаке или используя недостатки сайта [2].
Управление сессиями (72%)
Эта уязвимость позволяет хакеру пользоваться ресурсами с привилегиями пользователя [2].
Удаленное выполнение кода (32%)
Переполнение буфера, целочисленное переполнение, Format String-атаки могут дать злоумышленнику немедленный контроль над веб-приложением и его операционной системой. Иногда это может позволить злоумышленнику вызвать ситуацию отказа от обслуживания за счт вывода из строя уязвимого веб-приложения. В последнее время отмечается уменьшение количества подобных уязвимостей [2].
SQL-инъекции (32%)
Подобные атаки позволяют хакеру выполнять команды в основой базе данных веб-приложения, что дает возможность получить доступ к содержимому базы данных. В некоторых случаях хакер может использовать SQL-инъекцию для проникновения в веб-приложение с черного хода или запуск команд операционной системы. Отмечается скачок приложений с уязвимостями к SQL-инъекциям [2].
Небезопасное размещение ресурсов (24%)
Например, конфигурация по умолчанию некоторых приложений электронной коммерции хранит информацию о транзакциях, включая данные о кредитных карточках в незащищенных каталогах. Наблюдается рост подобных уязвимостей [2].
Несанкционированный доступ к каталогу (19%)
Небезопасные разрешения к каталогу могут позволить злоумышленнику получить доступ к веб-сайту или веб-приложению, которое должно было бы быть защищено. В других случаях это делает возможным прямой просмотр содержимого каталога, что облегчает хакеру планирование атаки на сервер. Наблюдается небольшой рост приложений с подобными уязвимостями [2].
Подделка межсайтового запроса (14%)
Подделка межсайтового запроса (CSRF) – это атака, обманным путем вынуждающая жертву загрузить веб-страницу с вредоносным кодом. При этом наследуются права и привилегии жертвы и от его имени рассылается электронная почта или совершаются покупки. Доля приложений с подобными уязвимостями осталась на прежнем уровне [2].
Защита веб-приложения: практические кейсы
Безопасность веб-приложений находится в первой десятке трендов и угроз информационной безопасности уже свыше 10 лет. Действительно, современные бизнес-процессы и повседневная жизнь — все больше и больше зависит от использования веб-приложений, в разнообразнейших аспектах: от сложных инфраструктурных систем до IoT устройств. Тем не менее специализированных средств защиты веб-приложений довольно мало, по большей части эту задачу возлагают (или надеются что она будет решена) на разработчиков. Это и использование различных фреймворков, средств санации, очистки данных, нормализации и многого другого. Тем не менее, даже с использованием этих средств безопаснее веб не стал, более того, в все уязвимости «классического веба» практически в неизменном виде мигрировали в мобильную разработку. В этой статье будет рассказано не как не допустить уязвимость, а как защитить веб-приложение от ее эксплуатации с использованием Web Application Firewall.
Из чего складывалась защита веб-приложения раньше? Из грамотной настройки веб-сервера, чистки сайта от ненужных файлов и участков кода и минимального контроля. Действительно, каналы были слабые, DDoS не был распространен, уязвимостей было мало, приложения были простыми, действия пользователей предсказуемы несколькими сценариями.
Со временем усложнялись веб-приложения, серверная инфраструктура и взаимодействие, код становился все более объемным и громоздким — это намного увеличило т.н. «поверхность атаки». Веб стал очень популярным, в нем появились возможности финансового роста — что естественно привлекло в эту сферу желающих незаконно воспользоваться чужим трудом.
Экспоненциально стало расти количество и разновидность атак на веб-приложения, которые условно можно разделить на две категории (исходя из концепции информационной безопасности):
В первую очередь это касается эксплуатации уязвимостей, во вторую атак на отказ в обслуживании. И если часть атак можно попытаться избежать на этапе планирования и разработки приложения (использую инструменты тестирования, отладки, анализ кода и т.д.), то при размещении веб-приложения в сети интернет сайт (особенно популярной сферы деятельности или компании) начинает подвергаться атакам практически по всем направлениям:
Они обладают различными методами, способами и инструментарием — объединяет их только одна цель взломать или вывести из строя веб приложение.
Практика и статистика
Хватит теории, давайте перейдем к практике. Очень часто многие оппоненты из dev апеллируют к тому, что уязвимостей скоро (или уже) не будет, есть фреймворки, модные и секюрные, исходный код проверяют тысчи человек, хакеры скоро вымрут. А как же на практике?
Давайте пройдемся по блогу «информационная безопасность» и посмотрим что было «горячего» за последнее время:
Кейс: 3 апреля: 0day в банковском ПО для геолокации (топик удален)
Тип уязвимости: SQL injection, RCE, Auth Bypass.
Описание: слепая инъекция на форме входа в службу геолокации банка. Сервис критичный, доступен в сети интернет.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции, такие как: использование кавычек, специальных конструкций — в данном примере функции sleep.
Кейс: 24 марта: Взлом сайта доставки пиццы, взлом mobidel.ru
Тип уязвимости: Insecure Direct Object References, хранимая XSS, захват сессии
Описание: отсутствие каких-либо проверок, классические клиент-сайд атаки.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны эксплуатации XSS вектора — использование функций инъекций html кода, множества запросов авторизации с разными id.
Кейс: 22 марта: Немного о приватности реальных Git-репозиториев
Тип уязвимости: Insecure Direct Object References, раскрытие информации
Описание: прямой доступ к критичным объектам.
Риски: получения информации о приложения для развития атаки.
Защита: выявлять и блокировать множественные обращения к служебным файлам репозитория.
Кейс: 12 марта: Надёжная авторизация для веб-сервиса за один вечер
Тип уязвимости: SQL injection
Описание: типичный разработчик, фигак-фигак и в продакшн.
Риски: security through obscurity.
Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции (union, select и т.д.) — даже зная где она находится (при наличии исходного кода), злоумышленник не сможет ее проэксплутировать.
Кейс: 6 марта: Как взламывают телеком-провайдеров: разбор реальной атаки
Тип уязвимости: SQL injection
Описание: взлом периметра через веб, проникновение в сеть.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны использования автоматических средств поиска уязвимостей (по заголовкам, частоте (парсингу) обращений.
Это все то, что как говорится «на виду». Веб-приложения как ломали, так и будут ломать дальше. Никакие инструкции по разработке безопасного кода, рекомендации, бест-прэкстис и т.д. не работают. Необходимы дополнительные защитные, или даже страховочные меры, для того чтобы предотвратить взлом веб-приложения. Это не значит что современные WAF — панацея. Это одна из защитных мер, которая поможет предотвратить взлом веб-приложения.
Выявление паттернов
Давайте разберем основные паттерны из представленных выше кейсов.
Инъекции
Эксплуатация sql-инъекции. В первую очередь злоумышленник (или автоматической средство) будет смотреть на поведение приложения, при подстановке в тот или иной параметр кавычки:
Будем считать, что инъекция есть, и сайт нам выведет ошибку (классика) you have an error in your sql syntax. Можем ли мы блокировать простую кавычку? По идее да, но вот что делать с фамилиями типа О’Коннор, служебными или админ-панелями, где применение кавычки вполне уместно? (та же markdown-разметка даст нам множество false-детектов).
Такие запросы напрямую не относятся к эксплуатации, это можно назвать зондированием, probe-запросом, который помогает злоумышленнику обнаружить признак уязвимости. Т.е. такие запросы должны блокироваться, но в тех зонах, где не определено другое правило. Также, необходимо осуществлять проверку IP-адреса, откуда пришел запрос: если ранее с этого адреса были атаки, он в черном списке и т.д. — можно осуществлять блокировку на основе репутационной политики.
Злоумышленник нашел уязвимость, теперь он попытается ее проэкплуатировать (для начала подобрать количество полей):
Либо, как в первом примере:
Эти запросы явно относятся к попыткам эксплуатации (и их как правило много) и должны быть заблокированы защитными средствами. Но, стоит учитывать область применения — если это находится в теле запроса, необходимо проводить преобразование (либо очистку) опасных конструкций средствами веб-приложения. Как например в моей статье — хабр не ругается на сломанный синтаксис запроса и дает мне нормально опубликовать кавычку и паттерн атаки (без выполнения).
Атака. Злоумышленник знает как устроено веб-приложение (у него есть код, как из примера выше), он может заранее подготовить конструкцию для атаки, например с применением специальных запросов типа drop/infile/outfile/dumpfile/load_file:
Это явная атака и она должна быть заблокирована (опять же по зоне применения правила). Если брать за основу балльную систему — то эта конструкция должна получить множество штрафных баллов: использование паттерна union select (и вариаций), функции LOAD_FILE, наличия спецсимволов и их потенциально опасных комбинаций (‘/, обращений к служебным файлам /etc/passwd, и символов терминации/комментирования /*.
Теперь перейдем к XSS. Тут вариаций пейлоадов довольно много, они более разнообразные и сложные. В этом случае необходимо и защищать веб приложение и давать возможность пользователю вводить данные в формы ввода, не блокируя его. Это необходимо делать, как на уровне приложения, так и средствами защиты.
К примеру, простейшая форма ввода телефона (возьмем вариант без валидации вводимых значений и типов) может быть заполнена пользователем в силу его умений и фантазии:
канонично:
со сломанным пробелом:
на европейский манер:
Т.е. пользователь даже в такой простой форме может использовать несколько вариаций использования символов и их комбинаций, что говорить про большие веб-формы, которые содержат множество полей? А если они предполагают украшение/выделение текста? Ваша компания:
Конечно такой запрос не будет блокироваться, опасных комбинаций здесь нет. «Обычные» xss-зонды, тоже выявляются довольно просто:
Это может дать выявить попытки эксплуатации уязвимости, поэтому такие запросы будут заблокированы.
Есть и более серьезные запросы на выявления XSS — например классика жанра (практически не устаревающая) — универсальный XSS вектор от raz0r:
В этом запросе есть практически все, чтобы «выстрелить» при наличии XSS. Такой запрос — это явная атака и он должен быть немедленно заблокирован.
Сканеры уязвимостей
Обычно предвестником атаки является сканирование веб-приложения теми или иными утилитами. Явный признак: частое обращение с одного IP к разными страницам, больше количество 404 ошибок. Это может быть поисковый бот (его ни в коем случаем не баним, но и при этом мы должны быть точно уверены что это именно бот — проверка поля User Agent не даст таких гарантий). Это может быть краулер или парсер — если нам не жалко — пусть парсит, можно лишь ограничить ему «аппетит» количеством запросов в минуту, если у вас слабый сервер. Другое дело сканеры: в первую очередь их можно сразу же определить по User Agent/служебным заголовкам (а большинство из тех, кто ими пользуется, никогда его не меняют и скорее всего даже не догадываются об этом): например сразу же выявляются такие сканеры, как: acunetix, w3af, netsparker, nikto и т.д. Такие обращения необходимо блокировать сразу же, чтобы не облегчать злоумышленникам работу (и не засорять логи). Если заголовки все-таки замаскированы — определить сканер можно по множеству 404 ошибок, попыток авторизации и обращений к служебным файлам.
Защита
Как мы видели в вышеприведенных примерах, используются разные технологии, платформы — поэтому современные защитные средства должны это учитывать. Во всех случаях использование WAF могло бы предотвратить эксплуатацию уязвимости, а система уведомлений сообщить о попытке эксплуатации.
Для того, чтобы избежать эксплуатации тех или иных уязвимостей, современный WAF должен: