En las aplicaciones web, los problemas de seguridad causados por errores de configuración de seguridad son comunes. Las configuraciones de seguridad comunes son problemas de seguridad de configuración de Apache, problemas de seguridad de configuración de Nginx y problemas de seguridad de configuración de Tomcat. Aquí describimos brevemente los problemas de configuración de estos tres software de servidor.
1. Problemas de configuración de seguridad de Apache
El archivo de configuración de Apache se llama httpd.conf Antes de iniciar nuestra propia aplicación web, primero debemos modificar su configuración.
Si queremos que Apache lo analice con x-httpd-php cuando encuentre un archivo de página con la extensión PHP, entonces podemos agregar el código AddHandler application/x-httpd-php .php al archivo de configuración
Antes de un análisis en profundidad, debemos comprender una característica básica de Apache, es decir, Apache permite que los archivos tengan múltiples sufijos y admite la ejecución de diferentes programas de análisis para diferentes sufijos. Cuando configuramos las opciones anteriores, si el sufijo de nuestro archivo contiene el sufijo l.php, apache llamará al programa de análisis de PHP para analizar el archivo.
Aquí usamos el campo de tiro como ejemplo:
Primero cargue test.test.php.xyz.jpg, el contenido del archivo es:<?php phpinfo();?>
Según la lógica normal, deberíamos mostrar el resultado de uno de nuestros formatos de imagen.
Pero en este momento modificamos el contenido del archivo de configuración de apache y agregamos: AddHandler application/x-httpd-php .php. Luego reinicie el servicio Apache2.
Luego visite el archivo que cargamos, y el contenido de respuesta obtenido se convierte en el siguiente:
Aquí puede ver que el código PHP malicioso que subimos se ha ejecutado. En este punto, la aplicación web ya no es segura.
Se puede ver que si nuestro administrador de aplicaciones web configura esta opción, nuestro atacante puede usar esta configuración para eludir el límite de carga y getshell.
2. Problemas de configuración de seguridad de Nginx
Nginx es un servidor web proxy inverso y HTTP de alto rendimiento, podemos ejecutarlo en Unix y Linux. Es ampliamente utilizado, solo superado por el software de servidor web de apache, y su tasa de utilización aumenta año tras año, y tiende a ponerse al día con apache.
Cuando nuestro nginx no está configurado correctamente, también causará problemas de seguridad.
El siguiente código es un archivo de configuración para un host virtual de Nginx:
server {
listen 8080;
root /usr/share/nginx/html;
index index.html;
server_name _;
location / {
return 302 https://$host$uri;
}
}
En este archivo de configuración de Nginx, la configuración problemática está en la última línea, solo debemos prestar atención a esta parte:
return 302 https://$host$uri;
$host puede entenderse simplemente como la información del host en la solicitud original, mientras que $uri es la clave para los problemas de seguridad y representa la ruta de la solicitud decodificada en la solicitud. Si el atacante establece la información de URL solicitada de la siguiente manera:
http://ip:port/%0a%0dSet-Cookie:%20a=test
En esta URL, %0a es CR después de la decodificación, %0d es LF después de la decodificación y %20 corresponde a un espacio después de la decodificación. Por lo tanto, cuando Nginx decodifica $uri, decodificará %0a%0d en CRLF, lo que hará que el mensaje HTTP se ajuste y luego inicie una solicitud Set-Cookie, que es el efecto de la inyección de CRLF.
Hagamos una prueba, visite 127.0.0.1:8080/%0a%0dSet-Cookie:%20a=test, y descubra que salta a https, pero el contenido de nuestro Set-cookie se encuentra en la respuesta, lo que indica nuestra Inyección CRLF ha sido exitoso.
3. Problemas de configuración de seguridad de Tomcat
El servidor Tomcat es un servidor de aplicaciones web gratuito y de código abierto, que es un servidor de aplicaciones liviano y se usa comúnmente en sistemas pequeños y medianos y en ocasiones donde no hay muchos usuarios de acceso simultáneo. De hecho, Tomcat es una extensión del servidor Apache, pero se ejecuta de forma independiente en tiempo de ejecución, por lo que cuando ejecuta Tomcat, en realidad se ejecuta como un proceso separado de Apache.
Hay un problema de configuración de seguridad bien conocido en Tomcat, que es CVE-2017-12615. El problema específico es que cuando Tomcat se ejecuta en un host de Windows y DefaultServlet readonly se establece en false en el archivo de configuración conf/web.xml, entonces, si habilita el método de solicitud HTTP PUT, conducirá a la seguridad de la escritura de archivos arbitrarios. ocurre un problema. Esto es algo similar a la vulnerabilidad de carga IIS PUT.
Aquí llegamos a la prueba real, encendemos nuestra máquina de destino, la pantalla es Tomcat 8.5.19:
Luego usamos la herramienta de escaneo de vulnerabilidades para realizar un escaneo de vulnerabilidades:
Los resultados del escaneo muestran que nuestra máquina de destino tiene múltiples vulnerabilidades de seguridad, y nuestra vulnerabilidad PUT de Tomcat también se escanea, y luego usamos la herramienta de explotación de vulnerabilidades PUT de Tomcat para explotar la vulnerabilidad:
Se puede ver que el exploit es exitoso y se han obtenido privilegios de administrador.
4. Principios de configuración de seguridad
Para evitar errores de configuración de seguridad, debemos cumplir con varios principios al configurar aplicaciones web:
- Principio de servicio mínimo
我们需要将 Web 应用不需要的服务进行关闭或限制，防止攻击者通过这些服务发起恶意行为
- Configuración de informes de errores generalizados
将 Web 应用的报错信息设置得通用化，使得报错信息中不包含错误发生的细节信息，防止因此导致的敏感信息泄露
- Modificar la información de la cuenta predeterminada
将 Web 应用默认的账户信息进行修改，尽量让账户密码变得复杂，否则攻击者很容易就会猜出账户信息，登陆进 Web 应用的管理后台