Hace aproximadamente un año, en DataLine lanzamos para buscar y analizar vulnerabilidades en aplicaciones de TI. El servicio se basa en la solución en la nube Qualys, cuyo funcionamiento . Durante un año de trabajo con la solución, realizamos 291 análisis de diferentes sitios y acumulamos estadísticas sobre vulnerabilidades comunes en aplicaciones web.
En el artículo siguiente, le mostraré exactamente qué agujeros en la seguridad de un sitio web se esconden detrás de los diferentes niveles de criticidad. Veamos qué vulnerabilidades encontró el escáner con especial frecuencia, por qué pueden ocurrir y cómo protegerse.
Qualys divide todas las vulnerabilidades de las aplicaciones web en tres niveles de criticidad: baja, media y alta. Si nos fijamos en la distribución por “gravedad”, parece que no todo está tan mal. Existen pocas vulnerabilidades con un alto nivel de criticidad, en su mayoría todas no son críticas:
Pero acrítico no significa inofensivo. También pueden causar daños graves.
Principales vulnerabilidades "no críticas"
- Vulnerabilidades de contenido mixto.
El estándar de seguridad de un sitio web es la transferencia de datos entre el cliente y el servidor a través del protocolo HTTPS, que admite el cifrado y protege la información contra la interceptación.
Algunos sitios usan contenido mixto: Algunos datos se transfieren a través del protocolo HTTP no seguro. Así es como se transmite con mayor frecuencia. contenido pasivo – información que afecta únicamente a la visualización del sitio: imágenes, estilos CSS. Pero a veces así se transmite. contenido activo: scripts que controlan el comportamiento del sitio. En este caso, utilizando un software especial, puedes analizar información con contenido activo procedente del servidor, modificar tus respuestas sobre la marcha y hacer que la máquina funcione de una forma no prevista por sus creadores.
Las versiones más recientes de los navegadores advierten a los usuarios que los sitios con contenido mixto no son seguros y bloquean el contenido. Los desarrolladores de sitios web también reciben advertencias del navegador en la consola. Por ejemplo, así es como se ve en :
Porque es peligroso: Los atacantes utilizan un protocolo inseguro para interceptar información del usuario, reemplazar scripts y enviar solicitudes al sitio en su nombre. Incluso si un visitante del sitio no ingresó datos, esto no lo protege de suplantación de identidad – obtener información confidencial utilizando métodos fraudulentos. Por ejemplo, utilizando un script, puede redirigir al usuario a un sitio inseguro que se hace pasar por uno familiar para el usuario. En algunos casos, el sitio malicioso se ve incluso mejor que el original y el usuario puede completar el formulario él mismo y enviar datos confidenciales.Lo que un desarrollador web debe recordar: Incluso si el administrador del sitio ha instalado y configurado un certificado SSL/TLS, puede surgir una vulnerabilidad debido a un error humano. Por ejemplo, si en una de las páginas no coloca un enlace relativo, sino un enlace absoluto de http y, además, no configuró redireccionamientos de http a https.
Puede detectar contenido mixto en un sitio utilizando un navegador: busque el código fuente de la página, lea las notificaciones en la consola del desarrollador. Sin embargo, el desarrollador tendrá que retocar el código durante mucho tiempo y de forma tediosa. Puedes acelerar el proceso con herramientas de análisis automatizadas, por ejemplo: , el software gratuito Lighthouse o el software pago Screaming Frog SEO Spider.
Además, la vulnerabilidad puede surgir debido a problemas con el código heredado, es decir, código heredado. Por ejemplo, si algunas páginas se generan utilizando una plantilla antigua, que no tiene en cuenta la transición de sitios a https.
- Cookies sin los indicadores "HTTPOnly" y "secure".
El atributo "HTTPOnly" protege las cookies para que no sean procesadas por scripts que los atacantes utilizan para robar datos del usuario. La bandera "segura" no permite que las cookies se envíen en texto sin cifrar. Sólo se permitirá la comunicación si se utiliza el protocolo seguro HTTPS para enviar la cookie.
Ambos atributos se especifican en las propiedades de la cookie:
Set-Cookie: Secure; HttpOnlyPorque es peligroso: Si el desarrollador del sitio no especificó estos atributos, un atacante podría interceptar la información del usuario de la cookie y explotarla. Si se utilizan cookies para autenticación y autorización, podrá secuestrar la sesión del usuario y realizar acciones en el sitio en su nombre.
Lo que un desarrollador web debe recordar: Como regla general, en los marcos populares estos atributos se configuran automáticamente. Pero aun así verifique la configuración del servidor web y establezca la bandera: Set-Cookie HttpOnly; Seguro.
En este caso, el atributo "HTTPOnly" hará que las cookies sean invisibles para su propio JavaScript.
- Vulnerabilidades basadas en rutas.
El escáner informa de dicha vulnerabilidad si encuentra un archivo o directorio de sitio web de acceso público con información potencialmente confidencial. Por ejemplo, detecta archivos de configuración del sistema individuales o acceso a todo el sistema de archivos. Esta situación es posible si los derechos de acceso están configurados incorrectamente en el sitio.
Porque es peligroso: Si el sistema de archivos "sobresale", un atacante puede ingresar a la interfaz del sistema operativo e intentar encontrar carpetas con contraseñas si están almacenadas en texto sin cifrar (¡no hagas eso!). O puede robar hashes de contraseña y aplicar fuerza bruta a la contraseña, y también intentar aumentar los privilegios en el sistema y profundizar en la infraestructura.
Lo que un desarrollador web debe recordar: No se olvide de los derechos de acceso y configure la plataforma, el servidor web y la aplicación web para que sea imposible "escapar" del directorio web.
- Formularios para ingresar datos confidenciales con autocompletar habilitado.
Si un usuario completa formularios con frecuencia en sitios web, su navegador almacena esta información mediante la función de autocompletar.
Los formularios de los sitios web pueden incluir campos con información confidencial, como contraseñas o números de tarjetas de crédito. Para dichos campos, vale la pena deshabilitar la función de autocompletar del formulario en el propio sitio.
Porque es peligroso: Si el navegador del usuario almacena información confidencial, un atacante puede interceptarla más tarde, por ejemplo mediante phishing. De hecho, un desarrollador web que se ha olvidado de este matiz está configurando a sus usuarios.
Lo que un desarrollador web debe recordar: En este caso, tenemos un conflicto clásico: conveniencia versus seguridad. Si un desarrollador web piensa en la experiencia del usuario, puede elegir conscientemente la función de autocompletar. Por ejemplo, si es importante seguir – recomendaciones para la accesibilidad de contenidos para usuarios con discapacidad.
Para la mayoría de los navegadores, puede desactivar la función de autocompletar con el atributo autocompete="off", por ejemplo:
<body> <form action="/es/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Pero no funcionará para Chrome. Esto se evita usando JavaScript; se puede encontrar una variante de la receta .
- El encabezado X-Frame-Options no está configurado en el código del sitio.
Este encabezado afecta a las etiquetas de marco, iframe, incrustado u objeto. Con su ayuda, puede prohibir por completo la inserción de su sitio dentro de un marco. Para hacer esto, debe especificar el valor X-Frame-Options: negar. O puede especificar X-Frame-Options: Sameorigin, luego la incrustación en un iframe solo estará disponible en su dominio.
Porque es peligroso: La ausencia de dicho encabezado se puede utilizar en sitios maliciosos para secuestro de clics. Para este ataque, el atacante crea un marco transparente encima de los botones y engaña al usuario. Por ejemplo: los estafadores enmarcan páginas de redes sociales en un sitio web. El usuario cree que está haciendo clic en un botón de este sitio. En cambio, el clic es interceptado y la solicitud del usuario se envía a la red social donde hay una sesión activa. Así es como los atacantes envían spam en nombre del usuario o obtienen suscriptores y me gusta.
Si no desactiva esta función, un atacante puede colocar el botón de su aplicación en un sitio malicioso. Puede que esté interesado en su programa de referencias o en sus usuarios.
Lo que un desarrollador web debe recordar: La vulnerabilidad puede ocurrir si se configuran X-Frame-Options con un valor conflictivo en el servidor web o el balanceador de carga. En este caso, el servidor y el equilibrador simplemente reescribirán el encabezado, ya que tienen una prioridad más alta en comparación con el código de fondo.
Los valores deny y Sameorigin del encabezado X-Frame-Options interferirán con el funcionamiento del visor web Yandex. Para permitir el uso de iframes para el visor web, debe escribir una regla separada en la configuración. Por ejemplo, para nginx puedes configurarlo así:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnerabilidades de PRSSI (importación de hojas de estilo relativas a la ruta).
Esta es una vulnerabilidad en el estilo del sitio. Ocurre si se utilizan enlaces relativos como href="/es/somefolder/styles.css/" para acceder a archivos de estilo. Un atacante se aprovechará de esto si encuentra una manera de redirigir al usuario a una página maliciosa. La página insertará un enlace relativo en su URL y simulará una llamada de estilos. Recibirá una solicitud como badsite.ru/…/somefolder/styles.css/, que puede realizar acciones maliciosas bajo la apariencia de un estilo.
Porque es peligroso: Un estafador podría aprovechar esta vulnerabilidad si encuentra otro agujero de seguridad. Como resultado, es posible robar datos de usuario a partir de cookies o tokens.
Lo que un desarrollador web debe recordar: establezca el encabezado X-Content-Type-Options en: nosniff. En este caso, el navegador comprobará el tipo de contenido de los estilos. Si el tipo no es texto/css, el navegador bloqueará la solicitud.
Vulnerabilidades críticas
- Una página con un campo de contraseña se transmite desde el servidor a través de un canal inseguro (el formulario HTML que contiene campos de contraseña se entrega a través de HTTP).
La respuesta del servidor a través de un canal no cifrado es vulnerable a ataques de "hombre en el medio". Un atacante puede interceptar el tráfico y situarse entre el cliente y el servidor a medida que la página viaja del servidor al cliente.
Porque es peligroso: El estafador podrá reemplazar la página y enviar al usuario un formulario con datos confidenciales, que irá al servidor del atacante.
Lo que un desarrollador web debe recordar: Algunos sitios envían a los usuarios un código de un solo uso por correo electrónico o por teléfono en lugar de una contraseña. En este caso, la vulnerabilidad no es tan crítica, pero el mecanismo complicará la vida de los usuarios.
- Envío de un formulario con nombre de usuario y contraseña a través de un canal inseguro (el formulario de inicio de sesión no se envía a través de HTTPS).
En este caso, el usuario envía un formulario con un nombre de usuario y contraseña al servidor a través de un canal no cifrado.
Porque es peligroso: A diferencia del caso anterior, esta ya es una vulnerabilidad crítica. Es más fácil interceptar datos confidenciales porque ni siquiera es necesario escribir código para hacerlo.
- Usar bibliotecas de JavaScript con vulnerabilidades conocidas.
Durante el escaneo, la biblioteca más utilizada fue jQuery con una gran cantidad de versiones. Cada versión tiene al menos una, o incluso más, vulnerabilidades conocidas. El impacto puede ser muy diferente dependiendo de la naturaleza de la vulnerabilidad.
Porque es peligroso: Existen exploits para vulnerabilidades conocidas, por ejemplo:
Lo que un desarrollador web debe recordar: Vuelva periódicamente al ciclo: busque vulnerabilidades conocidas - solucione - compruebe. Si utiliza bibliotecas heredadas deliberadamente, por ejemplo para admitir navegadores más antiguos o para ahorrar dinero, busque una oportunidad para corregir una vulnerabilidad conocida. - Secuencias de comandos entre sitios (XSS).
Cross-Site Scripting (XSS), o cross-site scripting, es un ataque a una aplicación web que da como resultado la introducción de malware en la base de datos. Si Qualys encuentra tal vulnerabilidad, significa que un atacante potencial puede o ya ha introducido su propio script js en el código del sitio para realizar acciones maliciosas.XSS almacenado más peligroso, ya que el script está incrustado en el servidor y se ejecuta cada vez que se abre la página atacada en el navegador.
XSS reflejado más fácil de llevar a cabo ya que se puede inyectar un script malicioso en una solicitud HTTP. La aplicación recibirá una solicitud HTTP, no validará los datos, los empaquetará y los enviará inmediatamente. Si un atacante intercepta el tráfico e inserta un script como
<script>/*+что+то+плохое+*/</script>luego se enviará una solicitud maliciosa en nombre del cliente.
Un ejemplo sorprendente de XSS: rastreadores js que simulan páginas para ingresar CVC, fecha de vencimiento de la tarjeta, etc.
Lo que un desarrollador web debe recordar: En el encabezado Content-Security-Policy, use el atributo script-src para forzar al navegador del cliente a descargar y ejecutar solo código de una fuente confiable. Por ejemplo, script-src 'self' incluye en la lista blanca todos los scripts de nuestro sitio únicamente.
La mejor práctica es el código en línea: solo permita javascript en línea utilizando el valor en línea no seguro. Este valor permite el uso de js/css en línea, pero no prohíbe la inclusión de archivos js. En combinación con script-src 'self', inhabilitamos la ejecución de scripts externos.Asegúrese de registrar todo usando report-uri y observe los intentos de implementarlo en el sitio.
- Inyecciones SQL.
La vulnerabilidad indica la posibilidad de inyectar código SQL en un sitio web que accede directamente a la base de datos del sitio web. La inyección SQL es posible si los datos del usuario no se filtran: no se comprueba su exactitud y se utilizan inmediatamente en la consulta. Por ejemplo, esto sucede si un formulario en un sitio web no verifica si la entrada coincide con el tipo de datos.Porque es peligroso: Si un atacante ingresa una consulta SQL en este formulario, puede bloquear la base de datos o revelar información confidencial.
Lo que un desarrollador web debe recordar: No confíes en lo que viene del navegador. Debe protegerse tanto en el lado del cliente como en el del servidor.
En el lado del cliente, escriba la validación de campos usando JavaScript.
Las funciones integradas en frameworks populares también ayudan a escapar de caracteres sospechosos en el servidor. También se recomienda utilizar consultas de bases de datos parametrizadas en el servidor.
Determine dónde tiene lugar exactamente la interacción con la base de datos en la aplicación web.
La interacción se produce cuando recibimos cualquier información: una solicitud con un id (cambio de id), la creación de un nuevo usuario, un nuevo comentario o nuevas entradas en la base de datos. Aquí es donde pueden ocurrir las inyecciones de SQL. Incluso si eliminamos un registro de la base de datos, la inyección SQL es posible.
recomendaciones generales
No reinventes la rueda: utiliza marcos probados. Generalmente, los marcos populares son más seguros. Para .NET - ASP.NET MVC y ASP.NET Core, para Python - Django o Flask, para Ruby - Ruby on Rails, para PHP - Symfony, Laravel, Yii, para JavaScript - Node.JS-Express.js, para Java - Primavera MVC.
Siga las actualizaciones de los proveedores y actualícelas periódicamente. Encontrarán una vulnerabilidad, luego escribirán un exploit, lo pondrán a disposición del público y todo volverá a suceder. Suscríbase a actualizaciones de versiones estables del proveedor de software.
Verificar derechos de acceso. Del lado del servidor, trate siempre su código como si, desde la primera hasta la última letra, hubiera sido escrito por su enemigo más odiado, que quiere dañar su sitio y violar la integridad de sus datos. Es más, a veces esto es cierto.
Utilice clones, sitios de prueba y luego utilícelos para producción.. Esto ayudará, en primer lugar, a evitar errores y equivocaciones en un entorno productivo: un entorno productivo genera dinero, un entorno productivo simple es fundamental. Al agregar, solucionar o cerrar cualquier problema, vale la pena trabajar en un entorno de prueba, luego verificar la funcionalidad y las vulnerabilidades encontradas y luego planificar el trabajo con el entorno de producción.
Proteja su aplicación web con e integrar informes del escáner de vulnerabilidades con él. Por ejemplo, DataLine utiliza Qualys y FortiWeb como un paquete de servicios.
Fuente: habr.com