Как обратные прокси-серверы повышают безопасность веб-приложений

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

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

Несмотря на растущую популярность веб-приложений, они подвержены рискам и кибератакам. В этой статье мы рассмотрим основные виды атак, которым подвержены веб-приложения. Затем вы узнаете, как можно использовать обратный прокси для минимизации угроз.

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

Обзор архитектуры веб-приложений

Веб-приложение

В большинстве случаев веб-приложения состоят из веб-серверов и веб-страниц. Веб-серверы принимают запросы от клиентов (ваших веб-браузеров), которые веб-сервер обрабатывает и возвращает ответ клиенту.  

В то время как серверная часть кодируется с помощью динамических языков программирования, таких как PHP, Python, ASP.NET и т.д., клиентская часть кодируется с помощью HTML, CSS и JavaScript. Связь между клиентом и сервером происходит по протоколу HTTP.

Для получения дополнительной информации о структуре веб-приложений вы можете обратиться к этой статье. На рисунке ниже показано типичное взаимодействие клиента и сервера.

На приведенной выше диаграмме все коммуникации выглядят просто: запросы перемещаются туда-сюда между клиентом и сервером. Однако это не всегда так.

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

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

Каковы основные угрозы для веб-приложений?

Удивительная статистика кибератак

Согласно данным Positive Technologies об уязвимостях веб-приложений за 2018 год, на финансовую и банковскую отрасли пришлось 28 % всех атакованных веб-приложений. Кроме того, 14 % кибератак направлены на онлайн-приложения в телекоммуникационной и производственной отраслях, а 11 % - на транспортные приложения.

Среди других отраслей, подверженных риску, - государственные учреждения (11 %), информационные технологии, электронная коммерция и средства массовой информации.

Что касается типов атак, то в другом отчете F5 говорится о росте межсайтового скриптинга (с 4 до 54 %) и атак с использованием SQL-инъекций (SQLi) (с 15 до 76 %). 

Из этой статистики можно сделать вывод, что для защиты веб-приложений от уязвимостей требуются строгие меры. Некоторые из недостатков безопасности возникают из-за проблем с кодированием, в то время как другие причины могут быть связаны с неадекватной инфраструктурой, используемой веб-приложением. Именно здесь на помощь приходит брандмауэр веб-приложений (WAF), который позволяет минимизировать уязвимости путем фильтрации пакетов, блокировки HTTP-трафика и несанкционированного протоколирования. 

Мы рассмотрим его подробнее ниже. А пока - краткий обзор значимых угроз безопасности.

SQL-инъекции (SQLi)

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

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

Предположим, что в текстовом поле пользователь ввел следующие данные:

Идентификатор пользователя: 228 или 1=1

Тогда результирующий запрос будет выглядеть следующим образом:

SELECT * FROM Users WHERE UserId = 228 OR 1=1;

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

Более подробную информацию о SQLi вы можете найти здесь.

Межсайтовый скриптинг (XSS)

XSS возникает, когда пользователь внедряет вредоносный скрипт, в основном на javascript, через несанированные поля ввода. Обычно злоумышленник отправляет этот вредоносный скрипт пользователю, который не вызывает подозрений. Браузер конечного пользователя не знает о том, что этот скрипт вредоносен, и выполняет его. 

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

Сломанная аутентификация и управление сеансами

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

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

Для получения более подробной информации вы можете обратиться к этой статье.

Какие существуют методы предотвращения веб-атак?

Брандмауэр веб-приложений

WAF - это защитный уровень 7 в модели OSI, который может быть размещен в точке входа на целевой сервер, как показано на следующей диаграмме. Он защищает внутреннюю сеть сервера от атак и скрывает сетевую топологию сервера.

Для того чтобы WAF работал, необходимо произвести дополнительные настройки на сервере. Как и брандмауэры, WAF фильтрует входящий и исходящий HTTP-трафик, который кажется опасным для внутренней сети сервера, если он не удовлетворяет правилам, установленным на WAF.

WAF также является разновидностью обратного прокси, о котором мы поговорим в следующем разделе.

Обратный прокси-сервер

Работа прокси-сервера заключается в том, чтобы скрыть ваш IP-адрес и заменить его IP-адресом прокси-сервера. Обратный прокси-сервер делает то же самое и повышает безопасность веб-сервера, скрывая его, а также топологию внутренней сети сервера.

Клиент знает только адрес прокси-сервера, поэтому реальный сервер скрыт от клиента.

В идеале вы можете использовать обратный прокси в качестве брандмауэра веб-приложений (WAF), о котором мы говорили выше. Вы можете реализовать WAF для веб-приложений на устройствах с настроенным обратным прокси. В результате сфера применения WAF для повышения безопасности становится шире. Злоумышленник также не может увидеть фактическое местоположение веб-сервера.

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

Как работает обратный прокси?

Все обратные прокси-серверы выполняют все следующие основные операции:

1. Браузер клиента отправляет HTTP-запрос на общедоступный URL. Предположим, что URL будет www.host.com на порту 80.
2. Затем, как обычно, имя хоста разрешается вокруг обратного прокси-сервера. Этот обратный прокси-сервер прослушивает этот адрес и получает запрос.
3. После этого обратный прокси исследует URL, чтобы определить, куда ему нужно направить запрос. Обычно обратный прокси может использовать любой компонент URL, чтобы решить, куда направить запрос. Например, он может использовать хост, протокол, путь, порт или строку запроса. Обычно путь является основным компонентом, который принимает решение о маршрутизации.
   1. Параметры конфигурации обратного прокси определяют исходящий URL, на который будет отправлен запрос. Этим исходящим URL обычно является внутренний сервер, отвечающий за предоставление содержимого. Обратный прокси-сервер может переписывать части запроса. Например, он может изменять или добавлять сегменты маршрута.
   2. Следующим шагом будет изменение заголовка запроса; обратный прокси должен также обновить некоторые данные HTTP-заголовка, чтобы указать внутренний веб-сервер в дополнение к изменению URL. Заголовок "Host:", например, содержит имя хоста, с которого запрашивается URL.
   3. Чтобы завершить сопоставление URL, http://www.host.com можно переназначить на http://realhost.com:8080.As, в этом случае имя хоста изменится на realhost. Затем номер порта также изменился на 8080.

4. Наконец, обратный прокси отправляет запрос на реальный сервер, который обрабатывает его.
5. После того как сервер обработает запрос, он отправляет ответ обратному прокси.
6. Затем обратный прокси выполняет следующие действия:
   1. Он изменяет ответ для корректной отправки клиенту. Сюда входит поле "Location:", которое содержит местоположение файла на сервере.
   2. Обратный прокси переставляет заголовки и, наконец, отправляет ответ клиенту.

Как защитить веб-приложение с помощью обратного прокси-сервера

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

Проверка содержимого запроса

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

Подход с использованием фильтра "черный список

Фильтр черного списка хранит известные вредоносные запросы. Затем он сравнивает каждый запрос с записями в списке. Если он обнаруживает совпадение, то отклоняет запрос. Различные варианты одного и того же нападения должны быть занесены в список отдельно. С помощью черных списков вы сможете предотвратить только известные нападения. Всеохватность черного списка способствует его эффективности. 

Подход, основанный на фильтрации по белому списку

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

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

Любые изменения в защищенном веб-приложении потребуют обновления белого списка. В результате ведение белого списка увеличивает нагрузку на администратора. 

Проверка содержимого ответа

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

Ведение журнала запросов и ответов

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

Заключение

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

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