Ataques más comunes

Debemos tener en cuenta que el front-end hoy en día comparte las mismas responsabilidades que el back-end o DevOps en términos de seguridad. Hay miles de ataques maliciosos que pueden ocurrir desde el front-end de la aplicación web.

Carga de archivos sin restricciones

Este es un ataque en el que los archivos maliciosos se cargan en el servidor y luego se ejecutan para atacar el sistema. El ataque puede incluir: un sistema de archivos sobrecargados o base de datos, control total del sistema, ataques del lado del cliente, ataques de reenvío a sistemas de back-end o desfiguración simple.

Clickjacking

Este es un ataque en el que el usuario es engañado a hacer clic en una página web o un elemento que no pertenece al sitio. Este ataque puede hacer que los usuarios proporcionen sin darse cuenta credenciales o información confidencial, descarguen malware, visiten páginas web maliciosas, compren productos en línea o transfieran dinero.

Ataque XSS

Este es un ataque en el que se inyectan secuencias de comandos maliciosos, en forma de una secuencia de comandos del lado del navegador en la página web. Las fallas en los sitios web permiten que estos ataques tengan éxito.

SQL injection

Este es un ataque en el que se inyecta código malicioso SQL para destruir su base de datos a través de campos de entrada.

Ataque de denegación de servicio (DoS attack)

Este es un ataque en el cual los atacantes bombardean su servidor con mucho tráfico para que el servidor o sus recursos no están disponibles para el usuario que intenta acceder a el sitio web.

Ataque de intermediario (Session hijacking)

Este es un ataque en el que las comunicaciones entre el cliente y el servidor se interceptan para robar contraseñas, números de cuenta o cualquier información personal.

El atacante siempre intentará encontrar algún hueco de seguridad en la interfaz para llegar al servidor y hacer su trabajo. En este artículo, veremos algunas de las mejores prácticas comunes para tener siempre en cuenta al codificar la interfaz.

Recomendaciones al programar el front-end de una aplicación web

1. Entrada estricta del usuario (el primer punto de ataque)

La entrada del usuario siempre debe ser estricta, para evitar vulnerabilidades como inyección SQL, clickjacking, etc. Por lo tanto, es importante validar y filtrar la entrada del usuario antes de enviarla al back-end. La filtración de datos se puede hacer eliminando o reemplazando caracteres contextualmente peligrosos, como mediante el uso de una whitelist para posteriormente escapar los datos de entrada.

Sin embargo, me doy cuenta de que filtrar no es una tarea fácil por todas las posibilidades existentes, por lo que podemos usar las siguientes librerías de código abierto:

• DOMPurify Esta es la más simple de usar y tiene un método para filtrar la entrada del usuario. Tiene una opción para personalizar las reglas y es compatible con HTML5, SVG y MathML.
• secure-filters Una biblioteca de Salesforce que proporciona métodos para filtrar HTML, JavaScript, estilos CSS en línea y otros contextos. Es especialmente útil si desea utilizar la entrada del usuario en otros lugares, por ejemplo para generar CSS o JavaScript.

En el caso de la carga de archivos, compruebe siempre el tipo de archivo y use una función de filtro de archivos y permita que solo se carguen ciertos tipos de archivos.

2. Cuidado con los campos ocultos o los datos almacenados en la memoria del navegador

Si agregamos input type="hidden" para ocultar datos confidenciales en páginas o guardarlos en el localStorage, sessionStorage o cookies del navegador y creemos que es seguro, debemos pensarlo dos veces.

El atacante puede acceder fácilmente a todo lo que se agrege al navegador. Un atacante puede abrir las herramientas de desarrollor y cambiar todas las variables en memoria. ¿Y si hubiera ocultado la página de autenticación en función de los valores del localStorage, sessionStorage o cookies?

Hay herramientas como Zaproxy e incluso herramientas de inspección en el navegador que pueden exponer esos valores a los atacantes si encuentran una manera de inyectar un script, y luego pueden usarlos para atacar aún más. Por lo tanto, evite usar type="hidden" y evite almacenar claves, tokens de autenticación, etc., en el almacenamiento en memoria del navegador tanto como sea posible.

3. Utilice una política de seguridad de contenido fuerte (CSP)

Nunca confíe en todo lo que envía el servidor: defina siempre un encabezado HTTP de Política de seguridad de contenido que solo permita que cierto contenido confiable se ejecute en el navegador o genere más recursos.

Es una buena práctica tener una whitelist (una lista de fuentes permitidas). Ahora, incluso si un atacante inyecta un script, el script no coincidirá con la whitelist y no se ejecutará.

content-security-policy: script-src ‘self’ https://apis.xyz.com

Aquí la aplicación solo confía en los scripts que provienen de apis.xyz.com y de nosotros mismos (self). Para el resto de las fuentes, se produce un error en la consola.

Nota: Una política de seguridad de contenido fuerte no resuelve el problema de la ejecución de scripts, por lo tanto, el ataque XSS sigue siendo válido.

4. Habilitar el modo de protección XSS

Si de alguna manera un atacante inyecta código malicioso desde un campo entrada, podemos indicarle al navegador que bloquee la respuesta proporcionando el encabezado "X-XSS-Protection": "1; mode = block".

La mayoría de los navegadores modernos tienen el modo de protección XSS habilitado de manera predeterminada, pero aún se recomienda incluir el encabezado X-XSS-Protection. Esto ayuda a garantizar una mejor seguridad para los navegadores más antiguos que no admiten encabezados CSP.

5. Evite los errores típicos de XSS

Un ataque XSS generalmente se remonta al innerHTML de la DOM API. Por ejemplo:

document.querySelector('.tagline').innerHTML = nameFromQueryString

Cualquier atacante puede inyectar código malicioso con la línea de arriba. Considere usar textContent en lugar de innerHTML para evitar generar una salida HTML por completo. Si no genera HTML, no hay forma de insertar JavaScript; puede ver el contenido pero no sucederá nada.

Nota: No establezca el valor innerHTML basado en la entrada del usuario y use textContent en lugar de innerHTML tanto como sea posible.

Además, las cabeceras de respuestas HTTP Content-Type y X-Content-Type-Options deben establecerse correctamente, con su comportamiento esperado. Por ejemplo, los datos JSON nunca deben codificarse como texto/HTML, para evitar la ejecución accidental.

6. Deshabilite la incrustación de iframe

Desactivar iframe puede protegernos de un ataque de clickjacking. Siempre debemos usar el encabezado "X-Frame-Options": "DENY" en la solicitud que prohíbe la renderización de un sitio web en un iframe. Además, podemos usar la directiva CSP frame-ancestors, que proporciona más control sobre qué padres pueden incrustar la página en un iframe.

7. Escriba los errores en forma genérica

Un error como "Su contraseña es incorrecta" puede ser útil para el usuario pero también para los atacantes. Pueden descubrir información de estos errores que les ayude a planificar su próxima acción.

Cuando se trata de cuentas, correos electrónicos y información personal, debemos tratar de usar errores ambiguos como "Información de inicio de sesión incorrecta".

8. Utilice Captcha

Haga uso de Captcha en endpoints como el inicio de sesión, registro y contacto. Un Captcha es un programa o sistema informático destinado a distinguir a los humanos de los bots y puede ayudar a detener los ataques DoS (denegación de servicio).

9. Asegúrese de establecer siempre "Referrer-Policy"

Siempre que usemos una etiqueta de anclaje o un enlace que navegue fuera del sitio web, asegúrese de usar una política de encabezado "Referrer-Policy": "no-referrer" o, en el caso de la etiqueta de anclaje, establezca rel = noopener o noreferrer.

Cuando no configuramos estos encabezados, el sitio web de destino puede obtener datos como tokens de sesión o IDs de bases de datos.

10. Audite las dependencias regularmente

Ejecute npm audit regularmente para obtener una lista de paquetes vulnerables y actualícelos para evitar problemas de seguridad.

GitHub ahora nos avisa sobre las dependencias vulnerables que utilizamos en nuestros repositorios. También podemos usar Snyk que verifica su código fuente automáticamente.

11. Evite utilizar servicios de terceros

Una línea de código de servicios de terceros como Google Analytics, Google Tag Manager, Intercom, Mixpanel, puede hacer que su aplicación web sea vulnerable. Piense en una situación en la que estos servicios de terceros están comprometidos.

Es importante tener una política fuerte de CSP. La mayoría de los servicios de terceros tienen una directiva CSP definida, por lo tanto, agréguela siempre. Además, asegúrese de incluir el atributo integrity cuando sea posible, al agregar una etiqueta de script. La función de integridad de recursos secundarios puede validar el hash criptográfico del script y asegurarse de que no haya sido manipulado.

src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..." crossorigin="anonymous" 

Considere cuidadosamente los campos de autocompletado

La información de identificación personal almacenada en el autocompletado de un navegador puede ser conveniente tanto para usuarios como para atacantes. Los atacantes agregan scripts de terceros para explotar el autocompletado incorporado de los navegadores, para extraer direcciones de correo electrónico

Muchos de nosotros ni siquiera somos conscientes de qué información ha almacenado el autocompletado de nuestro navegador.

Deshabilite el relleno automático de formularios para datos confidenciales.