Resumen de gestión
El equipo de Centralized Exchange se puso en contacto con Sayfer para realizar una prueba de penetración de caja negra completa en su aplicación web y una revisión de caja blanca para su arquitectura criptográfica en diciembre de 2021.
Antes de evaluar los servicios anteriores, llevamos a cabo una reunión inicial con el equipo técnico de Centralized Exchange y recibimos una descripción general del sistema y los objetivos de esta investigación.
Durante el período de investigación de 4 semanas, descubrimos 10 vulnerabilidades en el sistema. Las vulnerabilidades más peligrosas fueron la inyección SQL y las fallas en la lógica empresarial.
El impacto en el sistema es crítico, ya que un atacante malicioso podría explotar algunas de estas vulnerabilidades para aprovechar el sistema, ya sea cambiando su rol de usuario a "superusuario" a través de la inyección de SQL o abusando del sistema y robando dinero del Intercambio centralizado. utilizando el mecanismo de actualización del sistema 30s.
Vulnerabilidades por Riesgo
Alta – Amenaza directa a los procesos clave del negocio.
Medio – Amenaza indirecta a los procesos comerciales clave o amenaza parcial a los procesos comerciales.
Baja – No existe amenaza directa. La vulnerabilidad puede explotarse utilizando otras vulnerabilidades.
Informativo – Este hallazgo no indica vulnerabilidad, pero establece un comentario que notifica sobre fallas de diseño e implementación incorrecta que podría causar un problema a largo plazo.
Enfoque
Metodología de Evaluación de Seguridad
usos sayfer OWASP WSTG como nuestro estándar técnico al revisar aplicaciones web. Después de obtener una comprensión profunda del sistema, decidimos qué pruebas OWASP se requieren para evaluar el sistema.
Evaluacion de seguridad
Después de comprender y definir el alcance, realizar el modelado de amenazas y evaluar las pruebas correctas requeridas para verificar completamente la aplicación en busca de fallas de seguridad, realizamos nuestra evaluación de seguridad.
Recopilación de información
Recopilación de información | Nombre de la prueba |
WSTG-INFO-01 | Llevar a cabo un reconocimiento de descubrimiento de motores de búsqueda para detectar fugas de información |
WSTG-INFO-02 | Servidor web de huellas dactilares |
WSTG-INFO-03 | Revise los metarchivos del servidor web para detectar fugas de información |
WSTG-INFO-04 | Enumerar aplicaciones en el servidor web |
WSTG-INFO-05 | Revisar el contenido de la página web para detectar fugas de información |
WSTG-INFO-06 | Identificar los puntos de entrada de la aplicación |
WSTG-INFO-07 | Asignar rutas de ejecución a través de la aplicación |
WSTG-INFO-08 | Marco de aplicaciones web de huellas dactilares |
WSTG-INFO-09 | Aplicación web de huellas dactilares |
WSTG-INFO-10 | Arquitectura de aplicaciones de mapas |
Pruebas de gestión de configuración e implementación
Pruebas de gestión de configuración e implementación | Nombre de la prueba |
WSTG-CONF-01 | Configuración de infraestructura de red de prueba |
WSTG-CONF-02 | Configuración de la plataforma de aplicaciones de prueba |
WSTG-CONF-03 | Manejo de extensiones de archivo de prueba para información confidencial |
WSTG-CONF-04 | Revise la copia de seguridad antigua y los archivos sin referencia en busca de información confidencial |
WSTG-CONF-05 | Enumerar interfaces de administración de aplicaciones e infraestructura |
WSTG-CONF-06 | Probar métodos HTTP |
WSTG-CONF-07 | Probar la seguridad de transporte estricta de HTTP |
WSTG-CONF-08 | Probar la política de dominios cruzados de RIA |
WSTG-CONF-09 | Permiso de archivo de prueba |
WSTG-CONF-10 | Prueba de adquisición de subdominio |
WSTG-CONF-11 | Prueba de almacenamiento en la nube |
Pruebas de gestión de identidad
Pruebas de gestión de identidad | Nombre de la prueba |
WSTG-IDNT-01 | Definiciones de roles de prueba |
WSTG-IDNT-02 | Proceso de registro de usuario de prueba |
WSTG-IDNT-03 | Proceso de aprovisionamiento de cuenta de prueba |
WSTG-IDNT-04 | Pruebas de enumeración de cuenta y cuenta de usuario adivinable |
WSTG-IDNT-05 | Prueba de política de nombre de usuario débil o no aplicada |
Pruebas de autenticación
Pruebas de autenticación | Nombre de la prueba |
WSTG-ATHN-01 | Prueba de credenciales transportadas a través de un canal cifrado |
WSTG-ATHN-02 | Prueba de credenciales predeterminadas |
WSTG-ATHN-03 | Prueba de mecanismo de bloqueo débil |
WSTG-ATHN-04 | Prueba para eludir el esquema de autenticación |
WSTG-ATHN-05 | Prueba para recordar contraseña vulnerable |
WSTG-ATHN-06 | Prueba de debilidades de caché del navegador |
WSTG-ATHN-07 | Prueba de política de contraseña débil |
WSTG-ATHN-08 | Prueba de respuesta de pregunta de seguridad débil |
WSTG-ATHN-09 | Prueba de funcionalidades de cambio o restablecimiento de contraseña débil |
WSTG-ATHN-10 | Prueba de autenticación más débil en canal alternativo |
Pruebas de autorización
Pruebas de autorización | Nombre de la prueba |
WSTG-ATHZ-01 | Prueba de inclusión de archivos transversales de directorios |
WSTG-ATHZ-02 | Pruebas para eludir el esquema de autorización |
WSTG-ATHZ-03 | Pruebas de escalada de privilegios |
WSTG-ATHZ-04 | Pruebas de referencias de objetos directos inseguros |
Pruebas de gestión de sesiones
Pruebas de gestión de sesiones | Nombre de la prueba |
WSTG-SESS-01 | Prueba del esquema de gestión de sesiones |
WSTG-SESS-02 | Prueba de atributos de cookies |
WSTG-SESS-03 | Prueba de Fijación de Sesión |
WSTG-SESS-04 | Prueba de variables de sesión expuestas |
WSTG-SESS-05 | Pruebas de falsificación de solicitudes entre sitios |
WSTG-SESS-06 | Prueba de funcionalidad de cierre de sesión |
WSTG-SESS-07 | Tiempo de espera de la sesión de prueba |
WSTG-SESS-08 | Prueba de desconcierto de sesión |
WSTG-SESS-09 | Prueba de secuestro de sesión |
Pruebas de validación de datos
Pruebas de validación de datos | Nombre de la prueba |
WSTG-INPV-01 | Pruebas de secuencias de comandos de sitios cruzados reflejadas |
WSTG-INPV-02 | Pruebas de secuencias de comandos entre sitios almacenadas |
WSTG-INPV-03 | Prueba de manipulación de verbos HTTP |
WSTG-INPV-04 | Pruebas de contaminación de parámetros HTTP |
WSTG-INPV-05 | Pruebas de inyección SQL |
WSTG-INPV-06 | Prueba de inyección LDAP |
WSTG-INPV-07 | Pruebas de inyección XML |
WSTG-INPV-08 | Pruebas de inyección de SSI |
WSTG-INPV-09 | Prueba de inyección XPath |
WSTG-INPV-10 | Pruebas de inyección IMAP SMTP |
WSTG-INPV-11 | Pruebas de inyección de código |
WSTG-INPV-12 | Prueba de inyección de comandos |
WSTG-INPV-13 | Prueba de inyección de cadenas de formato |
WSTG-INPV-14 | Pruebas de vulnerabilidad incubada |
WSTG-INPV-15 | Pruebas de contrabando de división HTTP |
WSTG-INPV-16 | Prueba de solicitudes entrantes HTTP |
WSTG-INPV-17 | Prueba de inyección de encabezado de host |
WSTG-INPV-18 | Prueba de inyección de plantilla del lado del servidor |
WSTG-INPV-19 | Pruebas de falsificación de solicitudes del lado del servidor |
Manejo de errores
Manejo de errores | Nombre de la prueba |
WSTG-ERRH-01 | Pruebas para el manejo inadecuado de errores |
WSTG-ERRH-02 | Prueba de rastros de pila |
Criptografía
Criptografía | Nombre de la prueba |
WSTG-CRYP-01 | Pruebas de seguridad de capa de transporte débil |
WSTG-CRYP-02 | Pruebas para Padding Oracle |
WSTG-CRYP-03 | Pruebas de información confidencial enviada a través de canales no cifrados |
WSTG-CRYP-04 | Pruebas de cifrado débil |
Pruebas de lógica de negocios
Pruebas de lógica de negocios | Nombre de la prueba |
WSTG-BUSL-01 | Prueba de validación de datos de lógica empresarial |
WSTG-BUSL-02 | Capacidad de prueba para falsificar solicitudes |
WSTG-BUSL-03 | Comprobaciones de integridad de la prueba |
WSTG-BUSL-04 | Prueba de temporización del proceso |
WSTG-BUSL-05 | Prueba Número de veces que se puede usar una función Límites |
WSTG-BUSL-06 | Pruebas de elusión de flujos de trabajo |
WSTG-BUSL-07 | Pruebe las defensas contra el mal uso de la aplicación |
WSTG-BUSL-08 | Carga de prueba de tipos de archivos inesperados |
WSTG-BUSL-09 | Carga de prueba de archivos maliciosos |
Pruebas del lado del cliente
Pruebas del lado del cliente | Nombre de la prueba |
WSTG-CLNT-01 | Pruebas para Cross Site Scripting basado en DOM |
WSTG-CLNT-02 | Prueba de ejecución de JavaScript |
WSTG-CLNT-03 | Prueba de inyección de HTML |
WSTG-CLNT-04 | Prueba de redirección de URL del lado del cliente |
WSTG-CLNT-05 | Pruebas de inyección de CSS |
WSTG-CLNT-06 | Pruebas de manipulación de recursos del lado del cliente |
WSTG-CLNT-07 | Probar el intercambio de recursos de origen cruzado |
WSTG-CLNT-08 | Prueba de intermitencia entre sitios |
WSTG-CLNT-09 | Pruebas de secuestro de clics |
WSTG-CLNT-10 | Prueba de WebSockets |
WSTG-CLNT-11 | Prueba de mensajería web |
WSTG-CLNT-12 | Probar el almacenamiento del navegador |
WSTG-CLNT-13 | Pruebas para la inclusión de secuencias de comandos en sitios cruzados |
Prueba de API
Prueba de API | Nombre de la prueba |
WSTG-APIT-01 | Probando GraphQL |
Revisión de billetera criptográfica
Revisión de billetera criptográfica | Nombre de la prueba |
SAYFER-CRPTW-01 | Probar la lógica comercial comercial |
SAYFER-CRPTW-03 | Probar configuraciones de nodos de criptomonedas basadas en UTXO |
SAYFER-CRPTW-04 | Probar configuraciones de códigos de criptomonedas basadas en cuentas |
SAYFER-CRPTW-05 | Código crítico de confirmación de transacciones de prueba |
SAYFER-CRPTW-06 | Pruebe la compatibilidad con TAPROOT |
SAYFER-CRPTW-07 | Probar el almacenamiento de claves privadas |
Ordenar auditoría de Sayfer
Conclusiones de la evaluación de seguridad
Guardar claves MPC privadas de forma insegura
ID | SAYFER-CRPTW-07 |
Riesgo | Alta |
Habilidad requerida | Alta |
OWASP Referencia |
– |
Destino | – |
Herramientas | Auditoría de configuración |
Descripción
Los intercambios centralizados sufren de prácticas de gestión de claves de baja calidad. Hay muchos ejemplos de casos en los que las llaves se perdieron o fueron robadas, lo que provocó que el servicio perdiera todos los fondos de la billetera o los bloqueara por completo.
Durante nuestra auditoría de archivos de configuración, revisamos el almacenamiento de administración de claves. Descubrimos que las claves que se utilizan para la billetera fría multi-sig no se almacenan en lugares suficientemente distribuidos.
Hay 3 claves que se utilizan dentro de la firma de claves MPC. 1 se almacena en una máquina física protegida. Los otros 2 se almacenan dentro de la misma máquina dedicada en GCP.
Se toman un par de medidas de seguridad para proteger estas máquinas, pero el problema radica en la distribución, si la máquina implementada en GCP se ve comprometida, un atacante puede firmar cualquier transacción desde la billetera fría.
Este es un lugar sensible y de alto riesgo donde muchos han fallado en el pasado, las mejores prácticas deben seguirse estrictamente.
Mitigación
Utilice el servicio de custodia de terceros para administrar monederos activos y bóvedas. Estaremos encantados de recomendar a uno de nuestros socios.
Estos servicios manejan MPC y la administración de claves por usted, con otras capas de seguridad adicionales que hacen que el uso de dichos servicios sea la mejor opción para los intercambios centralizados.
SQL Injection
ID | WSTG-INPV-05 |
Riesgo | Alta |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlace |
Destino | – ██████████████ |
Herramientas | Repetidor de eructos, sqlmap, PayloadAllTheThings |
Descripción
Un ataque de inyección SQL consiste en insertar o "inyectar" una consulta SQL parcial o completa en la entrada de datos que se transmite desde el cliente a la aplicación web. Un ataque de inyección SQL exitoso puede leer datos confidenciales de la base de datos, modificar los datos de la base de datos (insertar/actualizar/eliminar), realizar operaciones de administración de la base de datos (como apagar el DBMS), recuperar el contenido de un archivo determinado en el sistema de archivos DBMS o escribir archivos en el sistema de archivos y, en algunos casos, emitir comandos al sistema operativo.
Usando el transaction
endpoint pudimos abusar del more
Parámetro de consulta de URL para inyectar una carga SQL maliciosa:
/api/transactions?size=10&more=te');INJECTION_PAYLOAD
El payload que usamos fue:
/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b
– Que en este caso, verifica si la instancia en ejecución de Postgres es la versión 10 o no.
Un atacante que aproveche esta vulnerabilidad podría apoderarse del sistema. Pudimos extraer los esquemas de la tabla, actualizar el rol de nuestro propio usuario o volcar cualquier información guardada en la base de datos e incluso cambiar el saldo de nuestro usuario en la base de datos.
Mitigación
La vulnerabilidad de inyección de SQL es fácil de arreglar pero difícil de mitigar. Se necesita un fuerte linting o implementación de reglas de compilación que impongan cambios futuros.
La mitigación de las vulnerabilidades de inyección SQL generalmente se realiza siguiendo un marco de trabajo elegido, lo que significa que el desarrollador nunca debe concatenar cadenas en una declaración SQL completa.
Cada entrada del usuario debe ser desinfectada en un ejecutor de SQL en lugar de usarse como una simple cadena de consulta de SQL.
Para obtener más información sobre la perfección de la inyección SQL, consulte el SQL IHoja de referencia para la prevención de inyecciones.
Referencias de objetos directos inseguras
ID | WSTG-ATHZ-04 |
Riesgo | Alta |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlazar |
Destino | – ██████████████████/tablero/{DASHBOARD_ID} |
Herramientas | Repetidor de eructos, DevTools |
Descripción
Las referencias directas a objetos inseguras (IDOR) son un tipo de vulnerabilidad de control de acceso que surge cuando una aplicación utiliza la entrada proporcionada por el usuario para acceder a los objetos directamente. Como resultado de esta vulnerabilidad, los atacantes pueden eludir la autorización y acceder directamente a los recursos del sistema, por ejemplo, registros o archivos de la base de datos.
Descubrimos que la API █████████ le permite a un atacante ver la información del tablero de otros usuarios, incluidos todos los datos financieros de este usuario.
La vulnerabilidad se basa en el parámetro de identificación del tablero, que es un número entero adivinable. Solicitud de ejemplo para un panel único (para un panel que no es propiedad del usuario actual):
GET ████/dashboard/827371 HTTP/1.1
Host: ██████████████████
api-key: ██████████
…
Eso indica que el /dashboard/DASHBOARD_ID
el punto final no verifica la autorización para el recurso solicitado. Un atacante autenticado podría raspar cada panel que contenga información sobre los fondos del usuario y las transacciones pasadas.
Mitigación
Hay varias formas de mitigar las vulnerabilidades de IDOR, para este caso, parece que la solución podría ser verificar la autorización para todas y cada una de las solicitudes.
Esto significa que cada clave de solicitud podrá obtener solo los paneles de su cuenta.
Autenticación más débil en el canal alternativo
ID | WSTG-ATHN-10 |
Riesgo | Alta |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlace |
Destino | – ██████████████████ |
Herramientas | Google Chrome, DevTools, Amass, Fluf |
Descripción
Incluso si los mecanismos de autenticación primarios no incluyen ninguna vulnerabilidad, es posible que existan vulnerabilidades en canales de usuario de autenticación legítimos alternativos para las mismas cuentas de usuario.
Esta vulnerabilidad es parte de una cadena de 2 vulnerabilidades que nos permitieron controlar cualquier cuenta con solo una dirección de correo electrónico.
Como parte de nuestra fase de reconocimiento en la que tratamos de encontrar un vector de ataque más amplio al enumerar los principales subsistemas objetivo, encontramos una interfaz de administración bajo el subdominio ██████████████████. Es posible iniciar sesión en la interfaz de administración con un usuario normal de la aplicación, pero para casi todas las solicitudes de red que inspeccionamos durante la carga de la página principal, el servidor devuelve un error 401.
[IMAGE_REDACTED]
Hicimos ingeniería inversa del archivo del paquete main.js que tiene el código de front-end para la aplicación y encontramos todos los puntos finales potenciales con los que un administrador puede interactuar.
Podríamos explotar sólo el punto final de api/updateUser
. El punto final nos permitió editar cualquier correo electrónico de usuario y, al hacerlo, pudimos restablecer la contraseña de la víctima y tomar el control de la cuenta.
[IMAGE_REDACTED]
Mitigación
Es muy recomendable realizar un mecanismo de autenticación o una VPN para la depuración o para los servicios administrativos del sistema para evitar la presencia de aplicaciones públicas no seguras que puedan ser aprovechadas por un atacante.
Además, existe un mecanismo de autorización en la interfaz de administración, pero esto está fuera del alcance de este proyecto.
Revise los metarchivos del servidor web para detectar fugas de información
ID | WSTG-INFO-03 |
Riesgo | Alta |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlace |
Destino | – ████████████████
– █████████████████████████████ – ████████████ |
Herramientas | Chrome, vete a la mierda |
Descripción
Como parte de nuestra investigación sobre el objetivo y sus subdominios, encontramos algunos metarchivos que no deberían ser públicos, o al menos no sin el mecanismo de autenticación adecuado.
- ████████████████████████.gitignore
- ██████████████████████████████/docker-compose.yml
- ████████████████████████/swagger-ui.html
[IMAGE_REDACTED]
[IMAGE_REDACTED]
[IMAGE_REDACTED]
Encontramos tres tipos de archivos que pueden dañar los servicios de ████████, .gitignore
, swagger-ui
y del docker-compose.yml
archivo Estos tres archivos revelan datos confidenciales
sobre la arquitectura del servicio. Un actor malintencionado puede utilizar esta información para aumentar su vector de ataque sobre el objetivo.
Mitigación
Si es posible, elimine estos archivos del servicio público o implemente un mecanismo de autorización que otorgue acceso solo a usuarios privilegiados.
Falta el encabezado de la política de seguridad de contenido
ID | SAYFER-CONFIG-008 |
Riesgo | Medio |
Habilidad requerida | Alta |
OWASP Referencia |
– |
Destino | – |
Herramientas | eructo, navegador web |
Descripción
La Política de seguridad de contenido (CSP) es una capa adicional de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques, incluidos Cross-Site Scripting (XSS) y ataques de inyección de datos.
No encontramos un encabezado CSP en ninguna de las respuestas del servidor.
[IMAGE_REDACTED]
Al usar los administradores de sitios web de CSP, agregue otra línea de defensa contra XSS o ataques de clickjacking, al hacerlo, el sistema estará seguro incluso si se realizan cambios no seguros en el código fuente en el futuro.
Una política de CSP básica debe al menos describir los dominios incluidos en la lista blanca predeterminados para archivos estáticos (como secuencias de comandos, imágenes y CSS). Y frame-ancestors
para evitar ataques de click-jacking.
Más información:
Mitigación
Añadiendo el Content-Security-Policy: [policy]
en cada respuesta donde la carga de recursos externos podría ser peligrosa
Recomendamos encarecidamente usarlo y probarlo primero con la variación "Solo informe" para probar su política antes de lanzarla a producción:
Content-Security-Policy-Report-Only: [policy]
Prueba de encabezados de seguridad
ID | SAYFER-CONFIG-009 |
Riesgo | Medio |
Habilidad requerida | Alta |
OWASP Referencia |
– |
Destino | – ████████████ |
Herramientas | eructo, navegador web |
Descripción
- Los navegadores admiten muchos encabezados HTTP que pueden mejorar la seguridad de las aplicaciones para proteger contra una variedad de ataques comunes, los encabezados se intercambian entre un cliente web (generalmente un navegador) y un servidor para especificar los detalles relacionados con la seguridad de la comunicación HTTP.
Al mirar los encabezados de seguridad ████████, falta lo siguiente:
- Opciones de tipo de contenido X
Establecer este encabezado evitará que el navegador interprete los archivos como algo diferente a lo declarado por el tipo de contenido en los encabezados HTTP.
- Estricto-Transporte-Seguridad
HSTS es un mecanismo de política de seguridad web que ayuda a proteger los sitios web contra ataques de degradación de protocolo y secuestro de cookies. Permite que los servidores web declaren que los navegadores web solo deben interactuar con él mediante conexiones HTTPS seguras, y nunca a través del protocolo HTTP inseguro.
- Política de referencia
El encabezado Referer es un encabezado de solicitud que indica el sitio desde el que se originó el tráfico. Si no existe una prevención adecuada, la propia URL e incluso la información confidencial contenida en la URL se filtrarán al sitio de origen cruzado.
- Acceso-Control-Permitir-Origen
El encabezado tiene el valor de "*" que expone la API para cada sitio web, este podría no ser el resultado deseado.
Mitigación
Agregar los encabezados mencionados anteriormente a todos los servicios de back-end.
Revise los metarchivos del servidor web para detectar fugas de información
ID | WSTG-INFO-03 |
Riesgo | Baja |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlace |
Destino | – |
Herramientas | DevTools |
Descripción
Mientras investigamos el objetivo con DevTool, pudimos ver el código fuente de la interfaz sin ofuscación. Esta vulnerabilidad se produce porque los paquetes de JS se envían con mapas de código fuente a producción, lo que permite leer el código fuente original con comentarios que pueden revelar información, por ejemplo, el siguiente archivo paths.ts:
█████████████████████/paths.ts [IMAGEN_ELIMINADA]
Al tener el mapa fuente, un atacante puede obtener información sobre el código base, leer comentarios y encontrar partes de código en desuso que luego se pueden usar para encontrar vulnerabilidades.
Mitigación
No envíe los mapas de origen a la producción, la mayoría de los sistemas de registro y seguimiento de errores tienen la opinión de cargar los mapas de origen en un sistema de back-ofice. Otro enfoque sería servir los mapas de origen solo a usuarios autenticados a través de VPN u otros mecanismos.
Servidor web de huellas dactilares
ID | WSTG-INFO-002 |
Riesgo | Baja |
Habilidad requerida | Medio |
OWASP Referencia |
– Enlazar |
Destino | – ███████████████████████████ |
Herramientas | Eructo |
Descripción
Si bien la información del servidor expuesta en sí misma no es necesariamente una vulnerabilidad, es información que puede ayudar a los atacantes a explotar otras vulnerabilidades que puedan existir. La mayoría de los puntos finales no revelan ninguna información sobre el servidor a través de encabezados HTTP o páginas de error.
Usando la siguiente solicitud HTTP mal formada, pudimos identificar un servidor Nginx a través de una respuesta 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*
El cuerpo de la respuesta es:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>
Mitigación
Hay diferentes formas de ocultar los encabezados del servidor web, los métodos más utilizados son:
- Servidores proxy inversos que se interponen entre la Internet global y la interna
- Configure cada servidor web para eliminar estos encabezados.
Apéndice A: correcciones de evaluación de seguridad
Será actualizado por el equipo de Sayfer después de la primera revisión.