© 1995-2022 Компания «Инфосистемы Джет»
Безопасность web-приложений: а нужно ли тестирование?
Информационная безопасность Информационная безопасность

Web-приложение независимо от его назначения является наиболее простым и, соответственно, самым распространенным способом доставки различного рода услуг до конечного пользователя

Главная>Информационная безопасность>Безопасность web-приложений: а нужно ли тестирование?
Информационная безопасность Тема номера

Безопасность web-приложений: а нужно ли тестирование?

16.09.2014

Посетителей: 276

Просмотров: 222

Время просмотра: 1.5 мин.

Авторы

Автор
Андрей Попов В прошлом - эксперт Центра информационой безопасности компании "Инфосистемы Джет"
Web-приложение независимо от его назначения является наиболее простым и, соответственно, самым распространенным способом доставки различного рода услуг до конечного пользователя. Повсеместное использование обусловливает высокие требования к надежности и бесперебойности работы web-приложений. Их удовлетворение возможно лишь путем применения широкого перечня защитных мер, одной из них является тестирование безопасности.

 

 

Хотя 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.

Уведомления об обновлении тем – в вашей почте

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня