Cómo abordar las vulnerabilidades web con Apache APISIX API Gateway

El Open Worldwide Application Security Project es una comunidad en línea que produce artículos, metodologías, documentación, herramientas y tecnologías disponibles gratuitamente en los campos de IoT, software de sistemas y seguridad de aplicaciones web. El OWASP proporciona recursos gratuitos y abiertos. Está dirigido por una organización sin fines de lucro llamada The OWASP Foundation. El OWASP Top 10 - 2021 es el resultado publicado de una investigación reciente basada en datos completos recopilados de más de 40 organizaciones asociadas.

-- Sitio web de OWASP

La OWASP publica periódicamente un informe de las 10 principales vulnerabilidades. El informe se centra en las vulnerabilidades de las aplicaciones web.

En esta publicación, me gustaría describir cómo solucionar algunos de ellos a través de Apache APISIX API Gateway .

El Top 10 de OWASP 2021

En 2021, el informe menciona:

• A01:2021-Control de acceso roto
• A02:2021-Fallos criptográficos
• A03:2021-Inyección
• A04:2021-Inseguro
• A05:2021-Mal configuración de seguridad
• A06:2021-Componentes vulnerables y obsoletos
• A07:2021-Fallos de identificación y autenticación
• A08:2021-Fallos de integridad de datos y software
• A09:2021-Fallos de monitoreo y registro de seguridad
• A10:2021-Falsificación de solicitudes del lado del servidor

Para obtener más detalles, consulte el informe completo.

La reparación de una vulnerabilidad depende de su naturaleza exacta. Por ejemplo, la reparación de componentes vulnerables y obsoletos se basa en procesos, lo que requiere disciplina a la hora de gestionar las versiones y retirar las más antiguas. Algunos, sin embargo, son técnicos y solo requieren una configuración adecuada en el proxy inverso o API Gateway, por ejemplo , Server Side Request Forgery .

A nadie le importa la seguridad

La seguridad es un tema delicado porque reforzarla no aporta ningún valor al negocio. A los gerentes impulsados por su carrera no les importará la seguridad, ya que no podrán demostrar que aumentaron las ganancias de la empresa en un X% en su próxima evaluación anual. A menos que la junta considere seriamente la seguridad, es probable que a nadie le importe. Por esta razón, la mayoría de las organizaciones implementan seguridad basada en casillas de verificación, también conocida como negación plausible. Si está interesado en implementar la seguridad correctamente, escribí algunas ideas en una publicación de blog anterior: Trate la seguridad como un riesgo .

En definitiva, proteger las aplicaciones no requerirá mucho presupuesto, si es que lo hay. Por lo tanto, debemos ser inteligentes y buscar un componente existente. Afortunadamente, OWASP ofrece una configuración lista para usar para manejar el Top 10, que se puede solucionar mediante una configuración llamada Core Rule Set . Desafortunadamente, apunta a ModSecurity:

ModSecurity, a veces llamado Modsec, es un firewall de aplicaciones web (WAF) de código abierto. Diseñado originalmente como un módulo para el servidor HTTP Apache, ha evolucionado para proporcionar una variedad de capacidades de filtrado de respuestas y solicitudes del protocolo de transferencia de hipertexto junto con otras características de seguridad en varias plataformas diferentes, incluidas el servidor HTTP Apache, Microsoft IIS y Nginx. Es un software gratuito publicado bajo la licencia Apache 2.0.

-- ModSecurity en Wikipedia

Si bien es teóricamente posible configurar Nnginx a través de la configuración de Apache APISIX, existe otra forma más sencilla.

El conjunto de reglas básicas de OWASP y Coraza

La descripción del conjunto de reglas básicas es bastante relevante para nuestras necesidades:

El conjunto de reglas básicas (CRS) de ModSecurity de OWASP® es un conjunto de reglas genéricas de detección de ataques para usar con ModSecurity o firewalls de aplicaciones web compatibles. El CRS tiene como objetivo proteger las aplicaciones web de una amplia gama de ataques, incluido el OWASP Top Ten, con un mínimo de alertas falsas. El CRS brinda protección contra muchas categorías de ataques comunes, que incluyen:

• Inyección SQL (SQLi)
• Secuencias de comandos entre sitios (XSS)
• Inclusión de archivos locales (LFI)
• Inclusión remota de archivos (RFI)
• Inyección de código PHP
• Inyección de código Java
• HTTPoxi
• Neurosis de guerra
• Inyección de shell Unix/Windows
• Fijación de sesión
• Secuencias de comandos/escáner/detección de bots
• Metadatos/fugas de errores

-- Sitio web del conjunto de reglas básicas ModSecurity de OWASP®

OWASP también proporciona Coraza , un puerto de ModSecurity disponible como biblioteca Go. Coraza Proxy Wasm está construido sobre Coraza e implementa la ABI proxy-wasm , que especifica un conjunto de interfaces Wasm para proxies. Finalmente, Apache APISIX ofrece integración proxy-wasm.

Poniendolo todo junto

Resumamos:

1. OWASP proporciona una lista de las 10 principales vulnerabilidades de seguridad web
2. Los implementa para ModSecurity a través del Core Ruleset
3. Coraza es un puerto de ModSecurity, disponible como implementación de proxy-wasm.

Podemos configurar Apache APISIX con valores predeterminados sensatos y seguros de esta manera. Vamos a hacerlo.

Lo primero es lo primero: Coraza no forma parte de la distribución Apache APISIX. Sin embargo, es sencillo agregarlo aquí con 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. Definir variables para una mejor mantenibilidad
2. Obtenga el lanzamiento de Coraza Wasm
3. En versiones recientes de APISIX, el usuario es apisix para reforzar la seguridad. Como necesitamos instalar paquetes, debemos cambiar a root .
4. Instale unzip ya que no está instalado, descomprima el archivo descargado, elimine el archivo, desinstale unzip y cambie el propietario de la carpeta extraída
5. Volver al usuario apisix

El siguiente paso es configurar APISIX para usar el complemento Coraza Wasm.

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

1. Nombre del filtro configurado en código Wasm
2. Establece la prioridad más alta para que se ejecute antes que cualquier otro complemento.
3. Ruta al archivo extraído, consulte el Dockerfile arriba

Finalmente, podemos asignar el complemento a rutas o configurarlo como una regla global para aplicar a cada ruta. Estoy usando una configuración estática:

 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. Configure el complemento coraza-filter ahora que está disponible
2. Definir configuraciones. Aquí definimos uno solo, default , pero podríamos definir varios y usar diferentes en diferentes rutas.
3. Aumente el nivel de registro para ver qué sucede en los registros
4. Enciende el motor
5. Usar la configuración de Coraza
6. Utilice todas las reglas. Podríamos elegir los que queramos para un control más detallado.
7. Utilice la configuración default definida anteriormente

Procedemos a definir rutas a https://httpbin.org/ para probar nuestra configuración. Llamemos a la ruta a /get :

 curl localhost:9080?user=foobar

La respuesta es la esperada:

 { "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" }

Ahora, intentemos enviar JavaScript en la cadena de consulta. No hay forma de que se espere esta solicitud del lado del servidor, por lo que nuestra infraestructura debería protegernos de ella.

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

La respuesta es un código de estado HTTP 403. Si miramos el registro, podemos ver las siguientes sugerencias:

 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

¡Coraza hizo el trabajo!

Conclusión

La mayoría de las organizaciones no incentivan la seguridad. Por lo tanto, debemos ser inteligentes al respecto y utilizar los componentes existentes tanto como sea posible.

Podemos reforzar Apache APISIX frente al OWASP Top 10 utilizando Coraza y Core Ruleset.

Para llegar más lejos:

• Top 10 de seguridad de OWASP
• Conjunto de reglas básicas de OWASP ModSecurity
• OWASP Coraza WAF
• APISIX - Integrar con Coraza

El código fuente completo de esta publicación se puede encontrar en GitHub .

Publicado originalmente en A Java Geek el 4 de febrero de 2024