Fortalecimiento de Apache APISIX con Coraza y el Conjunto de Reglas Centrales de OWASP

El Proyecto de Seguridad de Aplicaciones Abiertas a Nivel Mundial es una comunidad en línea que produce artículos, metodologías, documentación, herramientas y tecnologías gratuitas y disponibles al público en los campos de la seguridad de IoT, software de sistema y aplicaciones web. OWASP ofrece recursos gratuitos y abiertos. Está dirigido por una organización sin fines de lucro llamada Fundación OWASP. La OWASP Top 10 – 2021 es el resultado publicado de investigaciones recientes basadas en datos exhaustivos recopilados de más de 40 organizaciones colaboradoras.

– sitio web de OWASP

OWASP publica regularmente un informe de las 10 vulnerabilidades principales. El informe se enfoca en vulnerabilidades en aplicaciones web.

En esta publicación, me gustaría describir cómo solucionarlo algunas de ellas mediante el Gateway de API Apache APISIX.

La OWASP Top 10 2021

En 2021, el informe menciona:

• A01:2021-Control de Acceso Roto
• A02:2021-Fracasos Cryptográficos
• A03:2021-Inyección
• A04:2021-Inseguro
• A05:2021-Configuración de Seguridad Errónea
• A06:2021-Componentes Vulnerables y Desactualizados
• A07:2021-Fracasos en la Identificación y Autenticación
• A08:2021-Fracasos de Integridad del Software y los Datos
• A09:2021-Fracasos en Registros de Seguridad y Monitoreo
• A10:2021-Solicitud de Fuente Servidora Forzada

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

Arreglar una vulnerabilidad depende de su naturaleza exacta. Por ejemplo, arreglar Componentes Vulnerables y Desactualizados es un proceso impulsado, que requiere disciplina en la gestión de versiones y el retiro de las más antiguas. Sin embargo, algunas son técnicas y solo requieren una configuración adecuada en el proxy inverso o API Gateway, por ejemplo, Solicitud de Fraude del Servidor.

A Nadie Le Importa la Seguridad

La seguridad es un tema delicado porque el endurecimiento de la seguridad no aporta ningún valor al negocio. Los gerentes orientados a la carrera no se preocuparán por la seguridad ya que no podrán mostrar que aumentaron las ganancias de la empresa en un X% en su próxima evaluación anual. A menos que la junta considere la seguridad en serio, es probable que a nadie le importe. Por esta razón, la mayoría de las organizaciones implementan una seguridad basada en listas de verificación, también conocida como denegación plausible. Si está interesado en implementar la seguridad correctamente, he escrito algunas reflexiones en una entrada de blog anterior: “Tratar la Seguridad como un Riesgo.”

En general, proteger las aplicaciones no obtendrá mucho presupuesto, si es que obtiene alguno. Por lo tanto, debemos ser inteligentes al respecto y buscar un componente existente. Afortunadamente, OWASP ofrece una configuración fuera de la caja para manejar los 10 principales, que es fijable a través de una configuración llamada Conjunto de Reglas Centrales. Desafortunadamente, está dirigido a ModSecurity:

ModSecurity, a veces llamado Modsec, es un firewall de aplicaciones web de código abierto (WAF). Originalmente diseñado como un módulo para el servidor HTTP Apache, ha evolucionado para proporcionar una variedad de capacidades de filtrado de solicitudes y respuestas de Hypertext Transfer Protocol, junto con otras características de seguridad, en una serie de plataformas diferentes, incluyendo el servidor HTTP Apache, Microsoft IIS y Nginx. Es software libre publicado bajo la licencia Apache 2.0.

– ModSecurity en Wikipedia

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

El Conjunto de Reglas Core de OWASP y Coraza

La descripción del Conjunto de Reglas Core es bastante relevante para nuestras necesidades:

El Conjunto de Reglas Core de OWASP® ModSecurity (CRS) es un conjunto de reglas de detección de ataques genéricas para su uso con ModSecurity o firewalls de aplicaciones web compatibles. El CRS tiene como objetivo proteger las aplicaciones web de una amplia gama de ataques, incluyendo el Top Ten de OWASP, con un mínimo de alertas falsas. El CRS proporciona protección contra muchas categorías de ataques comunes, incluyendo:

• Injección SQL (SQLi)
• Escritura de Scripts en Sitios Cruzados (XSS)
• Inclusión de Archivos Locales (LFI)
• Inclusión de Archivos Remotos (RFI)
• Injección de Código PHP
• Injección de Código Java
• HTTPoxy
• Shellshock
• Injección de Shell de Unix/Windows
• Fijación de Sesión
• Detección de Escritura de Scripts/Escaneo/Bot
• Metadatos/Fugas de Errores

– Sitio web de OWASP® ModSecurity Core Rule Set

OWASP también proporciona Coraza, una versión de ModSecurity disponible como biblioteca en Go. Coraza Proxy Wasm se basa en Coraza y implementa la ABI de proxy-wasm, que especifica un conjunto de interfaces Wasm para proxies. Finalmente, Apache APISIX ofrece integración con proxy-wasm.

Uniendo Todo

Resumamos:

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

Podemos configurar Apache APISIX con valores predeterminados razonables y seguros de esta manera. Hagámoslo.

Primero lo primero: Coraza no es parte de la distribución de Apache APISIX. Sin embargo, es fácil agregarla 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 mejorar la mantenibilidad
2. Obtener la versión de Coraza Wasm.
3. En versiones recientes de APISIX, el usuario es apisix para endurecer la seguridad. Como necesitamos instalar paquetes, debemos cambiar a root.
4. Instalar unzip ya que no está instalado, descomprimir el archivo descargado, eliminar el archivo, desinstalar unzip, y cambiar el propietario de la carpeta extraída.
5. Cambiar de nuevo al usuario apisix. 

El siguiente paso es configurar APISIX para que utilice el plugin 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 establecido en el código Wasm
2. Establecer la prioridad más alta para que se ejecute antes que cualquier otro plugin.
3. Ruta al archivo extraído (ver el Dockerfile anterior)

Finalmente, podemos asignar el plugin a rutas o configurarlo como regla global para aplicar a todas las rutas. Estoy usando 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. Configurar el plugin coraza-filter, ahora que está disponible.
2. Definir configuraciones. Aquí, definimos una sola, default, pero podríamos definir varias y usar diferentes en diferentes rutas.
3. Aumentar el nivel de log para ver lo que sucede en los registros.
4. Encender el motor.
5. Usar la configuración de Coraza.
6. Usar todas las reglas. Podríamos seleccionar las que deseamos para un control más fino.
7. Usar la configuración default definida anteriormente.

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

curl localhost:9080?user=foobar

La respuesta es como se esperaba:

{
  "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 manera de que esta solicitud sea esperada del lado del servidor, por lo que nuestra infraestructura debería protegernos de ello.

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

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

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 componentes existentes en la medida de lo posible.

Podemos fortalecer Apache APISIX frente a los 10 principales riesgos de OWASP mediante el uso de Coraza y el conjunto de reglas básicas.

Para ir más allá

• APISIX – Integrar con Coraza

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