Sangfor Campus Recruitment Security Offense and Defense Volumen A
1. Hablar sobre la idea de la ruta de ataque de trazabilidad de registros web en el proceso de manejo de emergencia de problemas de seguridad WEB
Al analizar la seguridad del registro WEB, puede expandirlo paso a paso de acuerdo con las siguientes dos ideas y restaurar todo el proceso de ataque.
Primero determine el intervalo de tiempo del ataque, utilícelo como una pista para encontrar registros sospechosos en este intervalo de tiempo e investigue más a fondo de acuerdo con la IP sospechosa, las características del ataque, etc. (los registros WEB registrarán las solicitudes de acceso del cliente a las aplicaciones WEB, incluyendo Usuarios normales Solicitudes de acceso y comportamiento malicioso del atacante. A través de muchos análisis, encontramos que cuando el atacante invadió el sitio web, la solicitud al sitio web contendrá características de ataque específicas, como el uso de escáneres WEB para escanear el sitio web en busca de vulnerabilidades A veces se genera una gran cantidad de registros de errores 404. Cuando un atacante detecta un sitio web para las vulnerabilidades de inyección SQL, las palabras y 1 = 1 generalmente aparecerán en el registro de acceso WEB), y finalmente bloquean al atacante, confirman el ataque. método y restaurar el proceso de ataque.
2. ¿Cuáles son las causas y los peligros de las fugas por goteo cardíaco?
Respuesta: Vulnerabilidad Heartbleedt. Esta falla grave (VE-204-0160) se debe a que no se realizó la verificación de límites correctamente antes de llamar al usuario víctima para que ingrese contenido como parámetro de longitud en mencpy (). El atacante puede rastrear la caché de 64 KB asignada por OperSSL., Copie la información de bytes más allá del rango necesario en la caché y luego devuelva el contenido de la caché, de modo que el contenido de la memoria de la víctima se filtre a una velocidad de 64 KB cada vez. Al leer la memoria del servidor de red, un atacante puede acceder a datos confidenciales, poniendo en peligro la seguridad del servidor y de los usuarios. Los datos de seguridad confidenciales, como la clave maestra dedicada del servidor, permiten a un atacante descifrar los datos de transmisión actuales o almacenados a través de ataques pasivos de intermediario cuando el servidor y el cliente no están utilizando el secreto directo completo o el uso complete En el caso del secreto hacia adelante, lance un ataque de intermediario activo. El atacante no puede controlar los datos devueltos por el servidor porque el servidor responde a bloques de memoria aleatorios.
Las vulnerabilidades también pueden exponer solicitudes y respuestas confidenciales de otros usuarios, incluida cualquier forma de datos de solicitud POST, cookies de sesión y contraseñas, que pueden permitir a los atacantes secuestrar las identidades de servicio de otros usuarios. En el momento de su divulgación, aproximadamente el 17% o 500.000 servidores de redes de seguridad de Internet certificados por organismos de certificación se consideraban vulnerables. La Electronic Frontier Foundation, ArsTechnica y Bruce Schnell consideraron que la vulnerabilidad al sangrado del corazón era "catastrófica". La versión específica de operSSL se puede convertir en una "cerradura en desuso" que se puede abrir sin llave. El intruso puede verificar la información de 54K del jefe de hogar cada vez. Siempre que tenga suficiente paciencia y tiempo, puede verificar suficientes datos para reconstruir el jefe del banco Datos sensibles como contraseñas y mensajes privados.
3. ¿Cómo se analizan y explotan las vulnerabilidades de análisis de archivos de Apache, IIS y Nginx?
Respuesta: Vulnerabilidad de análisis de Apache. Comienza de derecha a izquierda para juzgar el análisis, si es irreconocible, luego ve a la izquierda para juzgar. Por
ejemplo, upupimage.php.owf.rar ".owf" y ".rar"? Estos dos sufijos son apache irreconocible En el análisis, Apache analizará upupimage.php.owf.rar en php.
Vulnerabilidades de análisis de IIS:
una es /xx.asp/xx.jpg en IIS5.x / 6.0, los nombres de las carpetas creadas en el sitio web son .asp,. asa El archivo con cualquier extensión en su directorio es analizado y ejecutado como un archivo asp por IIS.
El segundo es 123.asp; .jpg será considerado por el servidor como 123.asp, y el archivo ejecutable predeterminado de IIS6.0 además de asp también contiene estos tres tipos de /upupimage.asa/upupimage.cer /upupimage.cdx
nginx Analizar vulnerabilidades:
una Cuando Fast-CGI está activado de forma predeterminada en nginx, Heikuo carga un nombre como upupimage.jpg y el contenido es <? PHPfputs (fopen ('shell.php', 'w'), '<? php eval ($ _POST [cmd])?> ');?>, Y luego visite upupimage.jpg / .php, se generará una palabra Trojan shell.php en este directorio.
La segunda es que Nginx incrusta el código PHP en la imagen y luego ejecuta el código visitando xxx.jpg% 00.php, lo que afecta a la versión: 0.5., 0.6., 0.7 <= 0.7.65, 0.8 <= 0.8. 37
4. ¿Desde qué aspectos se puede implementar la defensa frente a vulnerabilidades CSRF?
Respuesta: La defensa de vulnerabilidades CSRF se puede llevar a cabo desde tres niveles, a saber, defensa del lado del servidor, defensa del lado del usuario y defensa del equipo de seguridad.
(1) Compruebe que el campo HTTPreferer sea el mismo dominio. Según el protocolo HTTP, hay un campo llamado Referer en el encabezado HTTP, que registra la dirección de origen de la solicitud HTTP. En circunstancias normales, las solicitudes para acceder a una página restringida segura deben provenir del mismo sitio web. Por ejemplo, una transferencia bancaria se completa cuando el usuario visita la página http: //bank.test/test? Page = 10 & userID = 101 & money = 10000. El usuario primero debe iniciar sesión en bank.test y luego hacer clic en el botón en el página para activar el evento de transferencia. Cuando un usuario envía una solicitud, el valor de Referer de la solicitud de transferencia será la URL de la página donde se encuentra el botón de transferencia (en este ejemplo, generalmente es una dirección que comienza con el nombre de dominio de prueba del banco). Si un atacante desea implementar un ataque CSRF en el sitio web de un banco, solo puede crear una solicitud en su propio sitio web. Cuando un usuario envía una solicitud al banco a través del sitio web del atacante, el Referer de la solicitud apunta al sitio web del atacante. Por lo tanto, para defenderse de los ataques CSRF, el sitio web del banco solo necesita verificar el valor de Referer para cada solicitud de transferencia. Si es un nombre de dominio que comienza con bank. Test, significa que la solicitud proviene del sitio web del banco y es legítima. Si Referer es otro sitio web, puede ser un ataque CSRF y luego rechazar la solicitud
(2) Limitar el ciclo de vida de la cookie de sesión. El ataque CSRF es condicional, cuando el usuario visita el enlace malicioso, la cookie de autenticación sigue siendo válida, por lo que cuando el usuario cierra la página, la cookie de autenticación debe borrarse a tiempo
(3) Utilice el código de verificación. Aunque el atacante ha obtenido la identidad del usuario al obtener la cookie, al incluir el código de verificación en su formulario, el sitio web de hecho ha eliminado el riesgo de ataques de falsificación de solicitudes entre sitios. Puede utilizar este proceso en cualquier forma en la que necesite realizar una acción.
(4) Establezca el atributo HttpOnly en el campo de clave de cookie. Puede defenderse contra CSRF hasta cierto punto.