Подписаться
Читать в телеграм
Хотя web-технологии зародились еще в начале 1990-х годов и прошли немалый путь в своем развитии, они остались все той же комбинацией транспорта (HTTP) и представления (HTML), обросшей множеством «фишек» для удовлетворения современных потребностей в броском внешнем виде и удобстве управления. Безопасность же до сих пор является лишь опцией в общей схеме, ввиду того что она не была заложена как необходимое условие на начальном этапе.
В компаниях постоянно имеют место события информационной безопасности в результате проблем в web-приложениях, часто это приводит к прямым финансовым потерям. Тем не менее многие разработчики, ставя во главу угла коммерческий успех, стремятся сокращать сроки проектов, часто в ущерб безопасности. Например, для упрощения своей работы они могут использовать методы и конструкции, не совместимые с принципами разработки безопасного кода.
Web-приложение является тем промежуточным звеном, которое соединяет бизнес и дикий, в какой-то степени даже хаотичный мир интернета, поэтому уделять внимание безопасности по остаточному принципу нельзя
Взгляд изнутри
Типичное web-приложение по своей сути является системой, состоящей из множества компонент. Ее границы могут быть разными и зависят от конкретной, «живой» реализации. Соответственно, чтобы понять, как обеспечивается безопасность web-приложений, нужно начать с декомпозиции, рассмотреть их отдельные составляющие.
Любое приложение – это набор реализованных алгоритмов. В случае web алгоритмы реализованы, как правило, на скриптовых языках программирования, для их работы требуются вспомогательные программы (окружение). Написанные сценарии выполняются интерпретаторами, которые, в свою очередь, работают в связке с web-серверами – с серверным ПО, непосредственно отвечающим за подготовку и передачу данных. А взаимодействие с пользователем происходит с помощью дополнительного прикладного программного обеспечения интернет-обозревателя (браузера).
Степень вероятности нарушения штатной работы приложения зависит от качества кода реализованных алгоритмов и конфигурации компонент окружения. Отметим, что обычно используемые языки программирования и программные компоненты работы приложения сами по себе несут достаточно большое количество проблем информационной безопасности. В сумме же – в готовом приложении – все это дает просто огромное количество уязвимостей, которыми могут воспользоваться злоумышленники. Хотя в каждом продукте и технологии присутствуют свои «дыры», концептуально они похожи.
Рис. 1. Как злоумышленник видит web-приложение
Разложим web-приложение на логические уровни.
Уровень web-сервера. К нему относится ПО, реализующее работу приложения, – это и web-сервер (IIS, Apache, Nginx и т.п.), и платформа исполнения активного содержимого (PHP, JavaScript – JS, .NET), и элементы преобразования данных для подготовки к передаче (SSL), и компоненты третьих систем, например, коннекторы систем управления данными (СУБД).
Исходя из нашего опыта выполнения исследований защищенности ИТ-инфраструктуры компаний мы приведем пример проблемы ИБ на этом уровне. Протокол HTTP, отвечающий за транспорт всех данных приложения, в открытом виде не имеет состояния соединения, просто передавая запрос ресурса и получение ответа клиентом. Для хранения данных сессии используются так называемые cookie – область данных, вырабатываемых приложением и хранящихся в клиентском ПО. Cookie хранятся на стороне пользователя в открытом виде и могут быть ему доступны. При каждом запросе cookie передаются серверу в качестве параметров запроса. Иногда для передачи данных также могут быть использованы скрытые поля.
Так вот, у одного из наших заказчиков был обнаружен корпоративный портал, у которого было достаточно большое количество уязвимостей. Но наибольший интерес вызвало то, что передача данных осуществлялась по незащищенному протоколу HTTP. Это позволило достаточно быстро и без особых усилий внедриться в сетевое соединение, перехватить сессионные cookie пользователей и получить доступ к порталу от их имени. Конечно, доступ непосредственно к порталу не привел к прямому финансовому ущербу, но позволил от имени легитимных пользователей взаимодействовать с другими сотрудниками. В конечном счете это позволило осуществлять атаки, направленные именно на них, в том числе социотехнические.
Уровень приложения. На нем реализуется обработка данных приложения, пользовательского ввода, а также генерация ответов пользователю. Собственно, здесь реализуется логика работы приложения.
К этому уровню относится, например, общая для динамических сайтов web-уязвимость SQL Injection, которая может привести к утечке всей базы данных, используемой приложением. Возникает такая уязвимость в связи с недостаточной обработкой пользовательского ввода (проблема форматирования и шаблонов ввода), за которую полностью отвечает разработчик. Если пользовательский ввод обрабатывается и превращается на стороне сервера в часть SQL-запроса, злоумышленник может внедрить дополнительные запросы в своем вводе и таким образом управлять удаленной БД.
Описанные выше уровни относятся к серверной составляющей web-приложения. На стороне пользователя также можно выделить несколько логических уровней.
Уровень web-клиента. Это прикладное программное обеспечение (интернет-обозреватель – браузер), которое реализует пользовательский интерфейс: принимает от пользователя запросы, посылает их web-серверу (HTTP), отображает полученные данные (HTML), а также исполняет некоторое активное содержимое приложения (JS). Здесь наибольшая опасность состоит в том, что в самом браузере могут быть уязвимости. Ими может воспользоваться злоумышленник, отправив клиенту вредоносные данные.
Уровень представления.К нему относится как статическая, так и динамическая информация, полученная от web-сервера и представленная в форматированном виде. Угрозу для этого уровня представляют атаки типа Cross-Site Scripting (XSS). Уязвимости, позволяющие реализовать XSS, обычно возникают из-за недостаточной обработки пользовательского ввода, который затем отображается на web-странице. Они позволяют атакующему внедрить код, такой как JavaScript, исполняемый на стороне клиента в web-странице, которую просматривает пользователь. Вредоносный код, полученный пользователем, может похищать cookie, перенаправлять сотрудника на другие web-ресурсы и т.п.
Рис. 2. Пример реализации атаки XSS
Лучшая защита – это…
Для защиты корпоративных ресурсов специалисты по информационной безопасности используют различный набор средств. Например, для шифрования трафика применяют SSL-сертификаты. При этом сертификаты часто являются не доверенными – из соображений экономии, либо используются устаревшие протоколы (SSLv2) или алгоритмы шифрования (RC4) – из-за недостатка конфигурирования. На периметре web-серверов сейчас модно ставить дорогостоящие WAF, которые, к сожалению, требуют серьезной настройки и длительного процесса самообучения.
Поэтому действительно эффективным средством обеспечения безопасности корпоративных web-ресурсов остается периодическая проверка со стороны. Проводя аудит архитектуры, процессов, настроек и кода приложения, а также осуществляя моделирование действий потенциальных злоумышленников, можно получить картину, наиболее четко отражающую текущие проблемы в web-приложении. Кроме того, это позволяет определить приоритетные направления деятельности разработчиков, подразделений ИТ и ИБ в части защиты корпоративных ресурсов.
С целью повышения общего уровня защищенности web-технологий международное ИТ-сообщество создало проект OWASP (Open Web Application Security Project). Это открытый проект обеспечения безопасности web-приложений, который работает над созданием соответствующих инструментов и технологий, документации, статей. Все это находится в свободном доступе. Сообщество OWASP не аффилировано ни с одной компанией, занимающейся разработкой технологий. При этом его участники действительно делают приложения безопаснее благодаря тому, что учитывают и человеческий фактор, и технологический уровень. Наиболее востребованные документы, опубликованные OWASP, – Руководство OWASP, Обзорное Руководство по Коду OWASP и OWASP TOP 10.
