Как устранить веб-уязвимости с помощью API-шлюза Apache APISIX

Open Worldwide Application Security Project — это онлайн-сообщество, которое производит свободно доступные статьи, методологии, документацию, инструменты и технологии в области Интернета вещей, системного программного обеспечения и безопасности веб-приложений. OWASP предоставляет бесплатные и открытые ресурсы. Его возглавляет некоммерческая организация The OWASP Foundation. Рейтинг OWASP Top 10 – 2021 — это опубликованный результат недавнего исследования, основанного на комплексных данных, собранных более чем 40 партнерскими организациями.

-- Веб-сайт OWASP

OWASP регулярно публикует отчет о 10 наиболее уязвимых местах. Отчет посвящен уязвимостям в веб-приложениях.

В этом посте я хотел бы описать, как исправить некоторые из них через API-шлюз Apache APISIX .

Топ-10 OWASP 2021 г.

В 2021 году в отчете упоминается:

• A01:2021-Нарушение контроля доступа
• A02:2021-Криптографические сбои
• A03:2021-Инъекция
• A04:2021-Небезопасно
• A05:2021-Неправильная конфигурация безопасности
• A06:2021-Уязвимые и устаревшие компоненты
• A07:2021-Ошибки идентификации и аутентификации
• A08:2021-Нарушения целостности программного обеспечения и данных
• A09:2021-Сбои регистрации и мониторинга безопасности
• A10:2021-Подделка запроса на стороне сервера

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

Исправление уязвимости зависит от ее точной природы. Например, исправление уязвимых и устаревших компонентов зависит от процесса и требует дисциплины в управлении версиями и выводе из эксплуатации старых. Однако некоторые из них являются техническими и требуют только правильной настройки в обратном прокси-сервере или шлюзе API, например , подделка запросов на стороне сервера .

Никто не заботится о безопасности

Безопасность — деликатная тема, поскольку усиление безопасности не приносит никакой пользы бизнесу. Менеджеры, ориентированные на карьеру, не будут заботиться о безопасности, поскольку они не смогут продемонстрировать, что увеличили прибыль компании на X% в своей следующей ежегодной оценке. Если совет директоров серьезно не отнесется к вопросам безопасности, скорее всего, это никого не заинтересует. По этой причине большинство организаций реализуют безопасность на основе флажков, то есть правдоподобное отрицание. Если вы заинтересованы в правильной реализации безопасности, я написал несколько мыслей в предыдущем сообщении блога: Относитесь к безопасности как к риску .

В целом, защита приложений не потребует большого бюджета, если таковой вообще будет. Следовательно, мы должны подойти к этому с умом и искать существующий компонент. К счастью, OWASP предлагает готовую конфигурацию для обработки Топ-10, которую можно исправить с помощью конфигурации под названием Core Rule Set . К сожалению, он нацелен на ModSecurity:

ModSecurity, иногда называемый Modsec, представляет собой брандмауэр веб-приложений с открытым исходным кодом (WAF). Первоначально разработанный как модуль для HTTP-сервера Apache, он был развит, чтобы предоставить набор возможностей фильтрации запросов и ответов протокола передачи гипертекста, а также другие функции безопасности на ряде различных платформ, включая HTTP-сервер Apache, Microsoft IIS и Nginx. Это бесплатное программное обеспечение, выпущенное под лицензией Apache 2.0.

-- ModSecurity в Википедии

Хотя теоретически Nnginx можно настроить через конфигурацию Apache APISIX, есть другой, более простой способ.

Основной набор правил OWASP и Coraza

Описание основного набора правил вполне соответствует нашим потребностям:

Базовый набор правил OWASP® ModSecurity (CRS) — это набор общих правил обнаружения атак для использования с ModSecurity или совместимыми брандмауэрами веб-приложений. Целью CRS является защита веб-приложений от широкого спектра атак, включая первую десятку OWASP, с минимальным количеством ложных предупреждений. CRS обеспечивает защиту от многих распространенных категорий атак, в том числе:

• SQL-инъекция (SQLi)
• Межсайтовый скриптинг (XSS)
• Включение локальных файлов (LFI)
• Удаленное включение файлов (RFI)
• PHP-инъекция кода
• Внедрение Java-кода
• HTTPокси
• Контузия
• Внедрение оболочки Unix/Windows
• Фиксация сеанса
• Скрипты/Сканер/Обнаружение ботов
• Утечки метаданных/ошибок

-- Веб-сайт основного набора правил OWASP® ModSecurity

OWASP также предоставляет Coraza , порт ModSecurity, доступный в виде библиотеки Go. Coraza Proxy Wasm построен на основе Coraza и реализует proxy-wasm ABI , который определяет набор интерфейсов Wasm для прокси. Наконец, Apache APISIX предлагает интеграцию прокси-сервера и Wasm.

Собираем все это вместе

Подведем итоги:

1. OWASP предоставляет список 10 крупнейших уязвимостей веб-безопасности.
2. Он реализует их для ModSecurity через основной набор правил.
3. Coraza — это порт ModSecurity, доступный в виде реализации proxy-wasm.

Таким образом мы можем настроить Apache APISIX с разумными и безопасными настройками по умолчанию. Давай сделаем это.

Перво-наперво: Coraza не является частью дистрибутива Apache APISIX. Тем не менее, его легко добавить сюда с помощью Docker:

 FROM apache/apisix:3.8.0-debian ENV VERSION 0.5.0 #1 ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip #1 ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2 USER root #3 RUN <<EOF apt-get install zip -y #4 unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm rm $CORAZA_FILENAME apt-get remove zip -y chown -R apisix:apisix /usr/local/apisix/proxywasm EOF USER apisix #5

1. Определите переменные для лучшей ремонтопригодности
2. Получите выпуск Coraza Wasm
3. В последних версиях APISIX пользователь имеет apisix для повышения безопасности. Поскольку нам нужно установить пакеты, мы должны переключиться на root .
4. Установить unzip так как он не установлен, разархивировать скачанный архив, удалить архив, удалить unzip и сменить владельца распакованной папки
5. Вернитесь к пользователю apisix

Следующим шагом является настройка самого APISIX для использования плагина Coraza Wasm.

 wasm: plugins: - name: coraza-filter #1 priority: 7999 #2 file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3

1. Имя фильтра задано в коде Wasm.
2. Установите наивысший приоритет, чтобы он запускался раньше любого другого плагина.
3. Путь к извлеченному файлу см. в Dockerfile выше.

Наконец, мы можем назначить плагин маршрутам или установить его как глобальное правило, которое будет применяться к каждому маршруту. Я использую статическую конфигурацию:

 global_rules: - id: 1 plugins: coraza-filter: #1 conf: directives_map: #2 default: - SecDebugLogLevel 9 #3 - SecRuleEngine On #4 - Include @crs-setup-conf #5 - Include @owasp_crs/*.conf #6 default_directives: default #7

1. Настройте плагин coraza-filter сейчас, когда он доступен.
2. Определите конфигурации. Здесь мы определяем один, default , но мы можем определить несколько и использовать разные в разных маршрутах.
3. Увеличьте уровень журнала, чтобы увидеть, что происходит в журналах.
4. Включите двигатель
5. Используйте настройку Coraza
6. Используйте все правила. Мы могли бы выбирать те, которые нам нужны, для более детального контроля.
7. Используйте конфигурацию default , определенную выше.

Мы приступаем к определению маршрутов к https://httpbin.org/ , чтобы протестировать нашу настройку. Давайте вызовем маршрут к /get :

 curl localhost:9080?user=foobar

Ответ ожидаемый:

 { "args": { "user": "foobar" }, "headers": { "Accept": "*/*", "Host": "localhost", "User-Agent": "curl/8.4.0", "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", "X-Forwarded-Host": "localhost" }, "origin": "192.168.65.1, 176.153.7.175", "url": "http://localhost/get?user=foobar" }

Теперь давайте попробуем отправить JavaScript в строке запроса. Этот запрос никоим образом не ожидается на стороне сервера, поэтому наша инфраструктура должна защитить нас от него.

 curl 'localhost:9080?user=<script>alert(1)</script>'

Ответом является код состояния HTTP 403. Если мы посмотрим на журнал, то увидим следующие подсказки:

 Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection Coraza: Warning. Javascript method detected Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1

Кораза сделал свою работу!

Заключение

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

Мы можем укрепить Apache APISIX в отношении топ-10 OWASP, используя Coraza и основной набор правил.

Чтобы пойти дальше:

• Топ-10 по безопасности OWASP
• Основной набор правил OWASP ModSecurity
• OWASP Кораса WAF
• APISIX — интеграция с Coraza

Полный исходный код этого поста можно найти на GitHub .

Первоначально опубликовано на сайте A Java Geek 4 февраля 2024 г.