URL перезапись подделываемая

Содержание

Вопрос или проблема
Ответ или решение
URL Rewrite Spoofability in Kubernetes NGINX Proxy: A Detailed Analysis
Суть Концепции
Возможные Риски и Способы Их Обхода
Заключение

Вопрос или проблема

Я рассматриваю возможность использования перезаписей URL в прокси nginx kubernetes для публикации выбранных контекстных путей в микросервисах, которые работают в кластере с внутренними сервисами. Например

https://public.mycompany.com/microserviceone/api/v4/resource1

будет перезаписан и направлен на

http://microserviceone/public/api/v4/resource1

внутри кластера k8s. Веб-сервисы, как правило, основаны на REST и принимают GET и POST запросы с полезной нагрузкой application/json.

Это гипотетическая конфигурация ingress в этом случае:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: microserviceone-public-ingress
  namespace: default
  labels:
    app: microserviceone
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /public/
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
    - host: public.mycompany.com
      http:
        paths:
          - path: /microserviceone
            backend:
              serviceName: microserviceone-service
              servicePort: 80
  tls:
    - hosts:
        - public.mycompany.com
      secretName: microserviceone-cert

Мой вопрос таков: предполагая, что все ресурсы в контексте URL /public/ на сервисе защищены соответствующими методами, такими как сертификаты, API токены или токены аутентификации пользователей, существует ли известный способ для злоумышленника обойти перезапись URL и запросить ресурсы за пределами контекстного пути /public/?

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

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

Если это выходит за пределы вашего бюджета, то стоит попробовать автоматизированный сканер уязвимостей. Большинство хорошо разработанных сканеров уязвимостей предлагают бесплатную пробную версию, но обязательно соблюдайте лицензионные требования (особенно в отношении коммерческого использования, если это вас касается). Имейте в виду, что автоматизированные сканеры дадут автоматизированные результаты, поэтому, пожалуйста, не сравнивайте “Сканер ничего не нашел” с “Уязвимостей не существует”.

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

Ответ или решение

URL Rewrite Spoofability in Kubernetes NGINX Proxy: A Detailed Analysis

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

Суть Концепции

Вы планируете использовать NGINX Ingress Controller для маршрутизации HTTP-запросов, направленных на публичный адрес вашего сервиса, к внутренним микросервисам, защищенным необходимыми мерами безопасности. Ваш пример с конфигурацией Ingress показывает, как запросы к https://public.mycompany.com/microserviceone/api/v4/resource1 будут переправляться на http://microserviceone/public/api/v4/resource1.

Конфигурация, которую вы предоставили, включает:

Перезапись пути: Настройка nginx.ingress.kubernetes.io/rewrite-target, которая позволяет изменять запрашиваемый URL перед переадресацией.
SSL-шифрование: Использование TLS для защиты передаваемых данных.

Возможные Риски и Способы Их Обхода

Безопасность Перезапись Путей:
- Убедитесь, что только предусмотренные пути могут быть переписаны. Путем применения правил в NGINX можно задать более строгие ограничения, позволяя только определенные подмножества путей.
- Атакующие могут попробовать использовать манипуляции с параметрами запроса или хеддерами для обхода логики перезаписи. Например, если отсутствует проверка допустимости пути, злоумышленник может напрямую запрашивать ресурс http://microserviceone/private/api/v4/resource1.
Проверка Доступа:
- Даже при наличии SSL/HTTPS и токенов аутентификации, критически важно контролировать доступ на уровне приложения. Все микросервисы должны быть сконфигурированы для проверки прав доступа, а не полагаться только на внешнюю аутентификацию. Это значит, что необходимо реализовать механизм проверки прав пользователя для каждого запрашиваемого ресурса.
Уязвимости в Серверной Части:
- Поскольку входящие запросы могут обрабатывать данные от клиента, убедитесь, что все ваши микросервисы защищены от типичных уязвимостей, таких как SQL-инъекции, XSS, CSRF и других. Применяйте практики безопасного кодирования и регулярно проводите аудит кода и тестирование на проникновение (pentesting).
Логирование и Мониторинг:
- Настройка логирования запросов и мониторинга активности поможет вам реагировать на подозрительные действия. Логи должны отслеживать, какие пути запрашиваются, и с каких IP-адресов, что поможет выявить возможные попытки обхода.
Пенетестинг и Автоматизированные Сканеры Уязвимостей:
- Рекомендуется проводить регулярные тесты на проникновение с использованием сторонних специалистов или надежных инструментов для автоматического сканирования. Хотя автоматизированные сканеры могут снизить общую нагрузку, их результаты не можно рассматривать как окончательные. Всегда стоит учитывать возможность пропуска уязвимостей.

Заключение

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

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