Anteriormente, se recomendaba un programa de código abierto https://github.com/yandex/gixy en Sec-News para detectar problemas en el archivo de configuración de Nginx. Dio la casualidad de que Pwnhub también tuvo un problema en el juego de la semana pasada, incluida una vulnerabilidad causada por una mala configuración de Nginx.
Entonces elijo lo que creo que es más
Tres casos típicos que son interesantes y que pueden cometer errores, hablemos de la seguridad de los archivos de configuración de Nginx.
Además, los tres casos involucrados en este artículo se han conectado a Vulhub ( https://github.com/phith0n/vulhub/tree/master/nginx/insecure-configuration ). Puede probarlo usted mismo mientras lee este artículo.
$uriLa vulnerabilidad de inyección de CRLF resultante
Los siguientes dos escenarios son muy comunes:
- Visitas de usuarios
http://example.com/aabbcc, saltar automáticamente ahttps://example.com/aabbcc - Visitas de usuarios
http://example.com/aabbcc, saltar automáticamente ahttp://www.example.com/aabbcc
Por ejemplo, mi blog, visite http://www.leavesongs.com/other/tinger.html, será redirigido a 301 https://www.leavesongs.com/other/tinger.html. Con la popularidad de https ahora, muchos sitios se ven obligados a utilizar el acceso https, y estos saltos son muy comunes.
El segundo escenario es principalmente para unificar los nombres de dominio que visitan los usuarios, lo que es más propicio para la optimización SEO.
En el proceso de salto, debemos asegurarnos de que la página a la que accede el usuario permanezca sin cambios, por lo que debemos obtener la ruta del archivo solicitada por el usuario de Nginx. Al mirar la documentación de Nginx, puede encontrar que hay tres variables que representan uri:
1 $ s
2. $ document_uri
3. $ request_uri
Para explicar, 1 y 2 indican la ruta de solicitud después de la decodificación, sin parámetros; 3 indica el URI completo (sin decodificar). Luego, si la operación y mantenimiento se configura con el siguiente código:
ubicación / {
return 302 https: // $ host $ uri;
}
Debido a que $ uri es la ruta de solicitud después de la decodificación, puede contener saltos de línea, lo que crea una vulnerabilidad de inyección de CRLF. (Para conocer las vulnerabilidades de inyección de CRLF, consulte mi artículo anterior https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html )
Esta vulnerabilidad de inyección de CRLF puede provocar vulnerabilidades de reparación de sesiones, vulnerabilidades de CSRF causadas por la configuración de cookies o vulnerabilidades de XSS. Entre ellos, podemos controlar el cuerpo HTTP para XSS inyectando dos \ r \ n, pero como el navegador cree que es un salto 300, no mostrará el contenido que inyectamos.
En este caso, podemos usar algunas técnicas: por ejemplo, usar el encabezado CSP a la dirección del iframe, para que el navegador no salte, y luego ejecutar el HTML que insertamos:
Para los métodos de uso anteriores, puede consultar otro artículo mío
" Explorando la vulnerabilidad de inyección de encabezado HTTP de botella ".
¿Cómo solucionar esta vulnerabilidad CRLF? El enfoque correcto debería ser el siguiente:
ubicación / {
return 302 https: // $ host # request_uri;
}
Además, es posible que la $urivulnerabilidad de inyección de CRLF resultante no solo aparezca en los dos escenarios anteriores, sino que, en teoría, este problema se producirá siempre que se pueda configurar el encabezado HTTP.
Vulnerabilidad transversal de directorio
Esto es común cuando Nginx se usa como un proxy inverso. La parte dinámica se pasa al puerto de back-end por proxy_pass, mientras que los archivos estáticos necesitan ser procesados por Nginx.
Suponiendo que los archivos estáticos se almacenan en el directorio / home /, y el directorio se denomina archivos en la url, entonces debe usar alias para establecer el alias del directorio:
ubicación / archivos {
alias / home /;
}
En este momento, visite http://example.com/files/readme.txt, puede obtener el archivo /home/readme.txt.
Pero notamos que no hay sufijo / para / archivos en la URL, y / home / set by alias tiene un sufijo /. Esto / nos hace viajar desde el directorio / home / a su directorio superior:
Luego obtuvimos una vulnerabilidad de descarga de archivos arbitraria.
Esta interesante laguna apareció en el último concurso de Pwnhub " Finding SNH48 ", el tema de @Ricter Master.
¿Cómo solucionar este vacío legal? Solo es necesario asegurarse de que los valores de ubicación y alias tengan un sufijo /o ninguno de ellos.
El encabezado http está cubierto
Como todos sabemos, el archivo de configuración de Nginx se divide en algunos bloques de configuración como Servidor, Ubicación, Si, y existen relaciones de inclusión, que son similares a los lenguajes de programación. Si se configuran algunas opciones en la capa exterior, se pueden heredar en la capa interior.
Pero la herencia aquí también tiene algunas características, como add_header. Después de ser configurado en el bloque secundario, todos los encabezados HTTP agregados por add_header en el bloque principal se sobrescribirán , lo que genera algunos riesgos de seguridad.
Como en el siguiente código, el encabezado CSP se agrega al bloque del servidor:
server {
...
add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options DENY;
location = /test1 {
rewrite ^(.*)$ /xss.html break;
}
location = /test2 {
add_header X-Content-Type-Options nosniff;
rewrite ^(.*)$ /xss.html break;
}
}Sin embargo, el encabezado X-Content-Type-Options se agregó a la ubicación de / test2, lo que provocó que todos los add_headers en Fu Kuaizhong fallaran:
En este punto, el csp de test2 es completamente inválido y activamos con éxito el XSS:
para resumir
Los archivos de configuración de Nginx causan más de estos tres tipos de vulnerabilidades. Por ejemplo, la vulnerabilidad de análisis anteriormente popular ( https://github.com/phith0n/vulhub/tree/master/nginx_parsing_vulnerability ) también está relacionada con la configuración de Nginx.
Resuelva este tipo de vulnerabilidad,
Hay algunas soluciones en Baidu.com, muchos errores se propagan uno tras otro y finalmente se propagan.
Además, también podemos utilizar la herramienta gixy mencionada al principio de este artículo. Escanee el sitio web antes de que entre en funcionamiento, y es posible que encuentre algunos posibles problemas.
Articulo de referencia:
- http://blog.volema.com/nginx-insecurities.html
- https://github.com/phith0n/vulhub/tree/master/nginx/insecure-configuration
- https://hackerone.com/reports/25275
La forma más fundamental es leer la documentación oficial detenidamente, que explica muchos errores del archivo de configuración y el uso correcto.