Hace aproximadamente un año, en DataLine lanzamos un servicio para buscar y analizar vulnerabilidades en aplicaciones de TI. La base del servicio es la solución en la nube Qualys, sobre la que . En un año de trabajo con esta solución, realizamos 291 escaneos para diferentes sitios y acumulamos estadísticas sobre las vulnerabilidades comunes en aplicaciones web.
En el artículo a continuación, mostraré qué agujeros de seguridad en los sitios se ocultan detrás de diferentes niveles de criticidad. Veremos qué vulnerabilidades encontró el escáner con mayor frecuencia, por qué pueden surgir y cómo protegerse.
Qualys clasifica todas las vulnerabilidades de las aplicaciones web en tres niveles de criticidad: bajo, medio y alto. Si miramos la distribución por ‘gravedad’, parece que no está tan mal. Hay pocas vulnerabilidades de alta criticidad, la mayoría son no críticas:
Pero no críticas no significa inofensivas. También pueden causar daños graves.
Las principales vulnerabilidades 'no críticas'
- Vulnerabilidades relacionadas con contenido mixto.
El estándar de seguridad de los sitios es la transmisión de datos entre el cliente y el servidor a través del protocolo HTTPS, que admite cifrado y protege la información contra interceptación.
Algunos sitios utilizan contenido mixto: envían parte de los datos a través del protocolo HTTP no seguro. Con mayor frecuencia se transmite contenido pasivo – información que solo afecta la visualización del sitio: imágenes, estilos css. Pero a veces también se transmite contenido activo: scripts que controlan el comportamiento del sitio. En este caso, utilizando software especializado, es posible analizar la información enviada desde el servidor con contenido activo, modificar las respuestas sobre la marcha y hacer que la máquina funcione de una manera diferente a la prevista por sus creadores.
Los navegadores de las nuevas versiones advierten a los usuarios que los sitios con contenido mixto no son seguros y bloquean el contenido. Los desarrolladores de sitios también reciben advertencias del navegador en la consola. Por ejemplo, así es como se ve en :
Lo peligroso es: los atacantes utilizan el protocolo no seguro para interceptar la información del usuario, reemplazar scripts y enviar solicitudes al sitio en su nombre. Incluso si el visitante del sitio no ingresó datos, esto no lo protege de phishing – extracción de información confidencial mediante métodos fraudulentos. Por ejemplo, mediante un script se puede redirigir al usuario a un sitio inseguro que se hace pasar por uno conocido. En algunos casos, el sitio malicioso puede parecer incluso mejor que el original, y el usuario puede completar el formulario y enviar información confidencial por su propia cuenta.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 al factor humano. Por ejemplo, si en alguna de las páginas se estableció un enlace absoluto con http en lugar de uno relativo, y además no se configuraron redirecciones de http a https.
Se puede detectar contenido mixto en el sitio utilizando el navegador: buscando en el código fuente de la página, revisando las notificaciones en la consola del desarrollador. Sin embargo, el desarrollador tendrá que hurgar en el código durante mucho tiempo y con esfuerzo. Este proceso se puede acelerar con herramientas de análisis automatizadas, como: , el software gratuito Lighthouse o el software de pago Screaming Frog SEO Spider.
También puede surgir una vulnerabilidad debido a problemas con el código heredado, es decir, el código que ha sido heredado. Por ejemplo, si algunas páginas se generan a partir de una plantilla antigua que no tiene en cuenta la transición de los sitios a https.
- Cookies sin las banderas 'HTTPOnly' y 'secure'.
El atributo 'HTTPOnly' protege los archivos de cookies contra el procesamiento por scripts que los atacantes utilizan para robar datos de usuarios. La bandera 'secure' no permite la transmisión de cookies en texto plano. El intercambio de datos estará permitido únicamente si se utiliza el protocolo seguro HTTPS para enviar las cookies.
Ambos atributos se configuran en las propiedades de las cookies:
Set-Cookie: Secure; HttpOnlyLo peligroso es: Si el desarrollador del sitio no especifica estos atributos, un atacante puede interceptar la información del usuario de las cookies y aprovecharse de ella. Si las cookies se utilizan 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 frameworks populares, estos atributos se configuran automáticamente. Pero aún así, verifica la configuración del servidor web y establece la bandera: Set-Cookie HttpOnly; Secure.
Ten en cuenta que el atributo 'HTTPOnly' hará que las cookies sean invisibles incluso para tu propio JavaScript.
- Vulnerabilidades basadas en rutas.
El escáner informa sobre esta vulnerabilidad si detecta archivos o directorios del sitio accesibles públicamente que contienen información potencialmente confidencial. Por ejemplo, puede encontrar archivos individuales con la configuración del sistema o el acceso completo a la estructura de archivos. Esta situación puede ocurrir si los permisos de acceso en el sitio están configurados incorrectamente.
Lo peligroso es: Si el sistema de archivos "está expuesto", un atacante puede ingresar a la interfaz del sistema operativo e intentar encontrar carpetas con contraseñas, si se almacenan en texto claro (¡no debe hacerse!). También puede robar los hashes de las contraseñas y probar combinaciones para adivinar la contraseña, así como intentar elevar privilegios en el sistema y avanzar profundamente en la infraestructura.
Lo que un desarrollador web debe recordar: No olvide sobre los permisos de acceso y configure la plataforma, el servidor web y la aplicación web para que no se pueda "escapar" del directorio web.
- Formularios para ingresar datos confidenciales con la función de autocompletar activada.
Si un usuario a menudo llena formularios en sitios, su navegador guarda esta información mediante la función de autocompletar.
Los formularios en los sitios pueden incluir campos con información confidencial, como contraseñas o números de tarjetas de crédito. Para tales campos, es recomendable desactivar la función de autocompletar en el sitio mismo.
Lo peligroso es: Si el navegador del usuario guarda información confidencial, un atacante puede interceptarla más tarde, por ejemplo, mediante phishing. En esencia, el desarrollador web que olvida este matiz está poniendo en riesgo a sus usuarios.
Lo que un desarrollador web debe recordar: En este caso, tenemos un clásico conflicto: comodidad vs seguridad. Si el desarrollador web piensa en la comodidad del usuario, puede optar conscientemente por la autocompletar. Por ejemplo, si es importante seguir – recomendaciones para la accesibilidad del contenido a usuarios con discapacidades.
Para la mayoría de los navegadores, se puede desactivar la autocompletar utilizando el atributo autocompete="off", por ejemplo:
<body> <form action="/es/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Nombre"> </div> <div> <input type="text" id="lname" placeholder="Apellido" autocomplete="on"> </div> <div> <input type="number" placeholder="Número de tarjeta de crédito"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="es"/></form> </body>Pero no funcionará para Chrome. Esto se evita usando JavaScript, se puede encontrar una variante de la receta .
- En el código del sitio no se ha especificado la cabecera X-Frame-Options.
Este encabezado afecta a las etiquetas frame, iframe, embed u object. Con él se puede prohibir completamente incrustar su sitio dentro de un marco. Para ello, debe especificar el valor X-Frame-Options: deny. O puede especificar X-Frame-Options: sameorigin, lo que permite la incrustación en iframe solo en su dominio.
Lo peligroso es: La ausencia de dicho encabezado puede ser utilizada en sitios maliciosos para clickjacking. Para tal ataque, el atacante crea un marco transparente sobre los botones y engaña al usuario. Por ejemplo: los estafadores colocan el marco en el sitio de páginas de redes sociales. El usuario piensa que está haciendo clic en un botón en ese sitio. En lugar de eso, el clic es interceptado y envía la solicitud del usuario a la red social donde hay una sesión activa. De esta forma, los atacantes envían spam en nombre del usuario o aumentan seguidores y me gusta.
Si no se prohíbe tal posibilidad, un atacante puede colocar el botón de su aplicación en un sitio malicioso. Puede estar interesado en su programa de referidos o en sus usuarios.
Lo que un desarrollador web debe recordar: La vulnerabilidad puede aparecer si X-Frame-Options con un valor conflictivo está establecido en el servidor web o en el balanceador de carga. En este caso, el servidor y el balanceador sobreescribirán el encabezado, ya que tienen una prioridad más alta en comparación con el código del backend.
Los valores deny y sameorigin del encabezado X-Frame-Options interferirán con el funcionamiento del webvisor de Yandex. Para permitir el uso de iframe para el webvisor, es necesario escribir una regla separada en la configuración. Por ejemplo, para nginx se puede configurar así:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnerabilidades PRSSI (Importación de estilos relativos a la ruta).
Es una vulnerabilidad en los estilos del sitio. Surge cuando se utilizan enlaces relativos del tipo href="/somefolder/styles.css/" para acceder a archivos de estilos. El atacante aprovechará esto si encuentra una manera de llevar al usuario a una página maliciosa. La página insertará un enlace relativo en su url e imitará el acceso a los estilos. Esto generará una solicitud como badsite.ru/.../somefolder/styles.css/, que, bajo la apariencia de un estilo, puede realizar acciones maliciosas.
Lo peligroso es: Un estafador puede aprovechar esta vulnerabilidad si encuentra otro fallo de seguridad. Como resultado, podría robar datos de usuario de las cookies o tokens.
Lo que un desarrollador web debe recordar: Establezca el encabezado X-Content-Type-Options: nosniff. En este caso, el navegador verificará el tipo de contenido para los estilos. Si el tipo es diferente de text/css, el navegador bloqueará la solicitud.
Vulnerabilidades críticas
- La página con el campo de contraseña se sirve desde el servidor a través de un canal no seguro (HTML form containing password field(s) is served over HTTP).
La respuesta del servidor a través de un canal no cifrado es vulnerable a ataques de tipo 'Man in the middle'. Un delincuente puede interceptar el tráfico e infiltrarse entre el cliente y el servidor cuando la página va del servidor al cliente.
Lo peligroso es: Un estafador podría reemplazar la página y enviar al usuario un formulario para datos confidenciales, que se enviarían al servidor del delincuente.
Lo que un desarrollador web debe recordar: Algunos sitios envían a los usuarios un código único por correo electrónico/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.
- El envío del formulario con el nombre de usuario y contraseña a través de un canal no seguro (Login Form Is Not Submitted Via HTTPS).
En este caso, el formulario con el nombre de usuario y la contraseña se envía desde el usuario al servidor a través de un canal no cifrado.
Lo peligroso es: A diferencia del caso anterior, esta es una vulnerabilidad crítica. Es más fácil interceptar datos confidenciales, ya que ni siquiera es necesario escribir código para ello.
- Uso de bibliotecas de JavaScript con vulnerabilidades conocidas.
Durante el escaneo, la biblioteca más utilizada fue jQuery, con un amplio rango de versiones. En cada una de las versiones hay al menos una, y a veces más, vulnerabilidades conocidas. El impacto puede ser muy diverso, dependiendo de la naturaleza de la vulnerabilidad.
Lo peligroso es: Para vulnerabilidades conocidas, hay exploits, por ejemplo:
Lo que un desarrollador web debe recordar: Regrese regularmente al ciclo: búsqueda de vulnerabilidades conocidas - eliminación - verificación. Si está utilizando bibliotecas obsoletas de manera consciente, por ejemplo, para soportar navegadores antiguos o para ahorrar presupuesto, busque la forma de eliminar la vulnerabilidad conocida. - Scripts entre sitios (XSS).
El Cross-Site Scripting (XSS), o scripts entre sitios, son ataques a aplicaciones web que resultan en la aparición de código malicioso en la base de datos. Si Qualys encuentra tal vulnerabilidad, significa que un posible atacante puede haber inyectado o ya inyectó su script js en el código del sitio para realizar acciones maliciosas.XSS almacenado son más peligrosos, ya que el script se inyecta en el servidor y se ejecuta cada vez que se abre en el navegador la página atacada.
XSS reflejado es más fácil de llevar a cabo, ya que el script malicioso se puede inyectar en la solicitud HTTP. La aplicación recibirá la solicitud HTTP, no validará los datos, los empaquetará y los enviará inmediatamente. Si el atacante intercepta el tráfico e inserta un script como el siguiente
<script>/*+что+то+плохое+*/</script>entonces se enviará una solicitud maliciosa en nombre del cliente.
Un ejemplo claro de XSS: js-sniffers que imitan páginas para introducir el CVC, la 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 que el navegador del cliente cargue y ejecute solo el código de fuentes de confianza. Por ejemplo, script-src ‘self’ lista en blanco todos los scripts solo de nuestro sitio.
La mejor práctica es el código en línea: permita solo javascript inline con el valor unsafe-inline. Este valor permite usar js/css en línea, pero no prohíbe la conexión de archivos js. En combinación con script-src ‘self’ prohibimos la ejecución de scripts externos.Asegúrese de registrar todo mediante report-uri y observe los intentos de inyección en el sitio.
- Inyecciones SQL.
La vulnerabilidad indica la posibilidad de inyectar código SQL en el sitio, que accede directamente a la base de datos del sitio. La inyección SQL es posible si los datos del usuario no se escapan: no se verifican por su validez y se utilizan directamente en la consulta. Por ejemplo, esto ocurre si un formulario en el sitio no valida la coherencia de la entrada con el tipo de datos.Lo peligroso es: Si un atacante introduce una consulta SQL en tal formulario, puede provocar que la base de datos se caiga o revelar información confidencial.
Lo que un desarrollador web debe recordar: No confíe en lo que proviene del navegador. Es necesario protegerse tanto en el lado del cliente como en el del servidor.
En el lado del cliente, implemente la verificación de campos utilizando JavaScript.
Las funciones integradas en los frameworks populares también ayudan a escapar de caracteres sospechosos en el servidor. También se recomienda utilizar consultas parametrizadas a las bases de datos en el servidor.
Identifique dónde exactamente se está interactuando con la base de datos en la aplicación web.
La interacción ocurre cuando obtenemos alguna información: una solicitud con id (cambio de id), creación de un nuevo usuario, nuevo comentario, - nuevas entradas en la base. Aquí pueden ocurrir inyecciones SQL. Incluso si se elimina una entrada de la base, puede haber una inyección SQL.
Recomendaciones generales
No inventes la rueda: utiliza frameworks probados.. En general, los frameworks populares son más seguros. Para .NET, son 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, Spring MVC.
Esté atento a las actualizaciones del proveedor y actualice regularmente.. Las vulnerabilidades serán encontradas, luego se escribirá un exploit, se pondrá en acceso público, y todo volverá a repetirse. Suscríbase a las actualizaciones de versiones estables del proveedor de software.
Verifique los permisos de acceso.. Desde el lado del servidor, siempre trate su código como si todo, desde la primera hasta la última letra, estuviera escrito por su enemigo más odiado, que desea romper su sitio, romper la integridad de sus datos. Especialmente porque a veces es realmente así.
Utilice clones, entornos de prueba, y luego despliegue en producción.. Esto ayudará, en primer lugar, a evitar errores en el entorno productivo: el entorno productivo genera dinero, el tiempo de inactividad en producción es crítico. Al agregar, corregir o cerrar cualquier problema, se deben realizar trabajos en el entorno de prueba, luego verificar la funcionalidad y las vulnerabilidades encontradas, y solo después planear el trabajo con el entorno productivo.
Proteja la aplicación web mediante e integre con los informes del escáner de vulnerabilidades.. Por ejemplo, en DataLine se utilizan Qualys y FortiWeb como combinación de servicios.
Fuente: habr.com
