El Proyecto abierto de seguridad de aplicaciones web mantiene una lista actualizada periódicamente de los problemas de seguridad de las aplicaciones web más urgentes.
Después de leer este artículo podrás:
Contenido relacionado
Seguridad de aplicaciones web
Ataque por fuerza bruta
Fuga de datos
Ataques en ruta
Ataque de desbordamiento de búfer
Suscríbete a theNET, el resumen mensual de Cloudflare sobre las ideas más populares de Internet.
Copiar el enlace del artículo
El Proyecto abierto de seguridad de aplicaciones web, o OWASP, es una organización internacional sin ánimo de lucro dedicada a la seguridad de las aplicaciones web. Uno de los principios fundamentales del OWASP es que todos sus materiales están disponibles de forma gratuita y son fácilmente accesibles en su sitio web, lo cual posibilita que cualquiera pueda mejorar la seguridad de su propia aplicación web. Entre los materiales que ofrecen se incluyen documentación, herramientas, vídeos y foros. Quizá su proyecto más conocido sea el OWASP Top 10.
El Top 10 de OWASP es un informe actualizado de forma periódica donde se exponen los problemas de seguridad de las aplicaciones web, centrándose en los 10 riesgos más importantes. Un equipo de expertos en seguridad de todo el mundo elabora el informe. OWASP hace referencia al Top 10 como un "documento de concientización" y recomienda que todas las empresas incorporen el informe a sus procesos para minimizar o mitigar los riesgos de seguridad.
A continuación, se muestran los riesgos de seguridad recogidos en el informe Top 10 de OWASP de 2017:
El Control de acceso hace referencia un sistema que controla el acceso a la información o a la funcionalidad. Los controles de acceso que no funcionan permiten a los atacantes saltarse la autorización y realizar tareas como si fueran usuarios privilegiados, como los administradores. Por ejemplo, una aplicación web podría permitir que un usuario cambiara la cuenta con la que ha iniciado sesión con solo cambiar parte de una url, sin ninguna otra verificación.
Los controles de acceso pueden asegurarse al asegurar que una aplicación web utilice tokens de autorización* y establezca controles estrictos sobre los mismos.
*Muchos servicios emiten tokens de autorización cuando los usuarios inician sesión. Cada solicitud privilegiada que haga un usuario requerirá un token de autorización. Esta es una manera segura de garantizar que el usuario es quien dice ser, sin tener que ingresar constantemente sus credenciales de acceso.
Si las aplicaciones web no protegen los datos confidenciales, como por ejemplo la información financiera y las contraseñas, mediante cifrado, los atacantes pueden acceder a esos datos y venderlos o utilizarlos con fines maliciosos. También pueden robar información confidencial mediante un ataque en ruta.
Para minimizar el riesgo de exposición de datos, se pueden cifrar todos los datos confidenciales, autenticar todas las transmisiones e inhabilitar el almacenamiento en caché* de la información confidencial. Además, los desarrolladores de aplicaciones web deben asegurarse de no almacenar innecesariamente datos confidenciales.
*El almacenamiento en caché es la práctica de almacenar temporalmente los datos para reutilizarlos. Por ejemplo, los navegadores web suelen almacenar en caché las páginas web para que, si un usuario vuelve a visitarlas en un periodo de tiempo determinado, el navegador no tenga que recuperarlas de la web.
Los ataques de inyección ocurren cuando se envían datos que no son de confianza a un intérprete de código a través de la entrada de un formulario o algún otro envío de datos a una aplicación web. Por ejemplo, un atacante podría introducir código de base de datos SQL en un formulario que espera un nombre de usuario en texto plano. Si la entrada del formulario no está asegurada de forma adecuada, se acabaría ejecutando el código SQL. Esto se conoce como un ataque de inyección de código SQL.
La categoría de inyección también incluye ataques de cross-site scripting (XSS), que anteriormente era parte de su propia categoría en el informe de 2017. Las estrategias de mitigación para cross-site scripting incluyen la elusión de las solicitudes HTTP no fiables y el uso de marcos de desarrollo web modernos como ReactJS y Ruby on Rails, que brindan cierta protección integrada contra el cross-site scripting.
En general, los ataques de inyección pueden evitarse al validar y/o sanear los datos enviados por el usuario. (La validación significa rechazar los datos que tienen un aspecto sospechoso, mientras que el saneamiento hace referencia a la limpieza de las partes de aspecto sospechoso de los datos). Además, el administrador de la base de datos puede configurar controles para minimizar la cantidad de información que un ataque de inyección puede exponer.
Consigue más información sobre cómo impedir las inyecciones de código SQL.
El diseño no seguro incluye una serie de debilidades que pueden estar integradas en la arquitectura de una aplicación. Se centra en el diseño de una aplicación, no en su implementación. OWASP enumera el uso de preguntas de seguridad (p. ej. "¿En qué calle creciste?") para la recuperación de contraseñas como un ejemplo de un flujo de trabajo que no es seguro por diseño. Independientemente de lo bien que los desarrolladores implementen un flujo de trabajo de este tipo, la aplicación seguirá siendo vulnerable, ya que más de una persona pueden saber la respuesta a esas preguntas de seguridad.
El uso del modelado de amenazas antes de la implementación de una aplicación puede ayudar a mitigar este tipo de vulnerabilidades.
La desconfiguración de la seguridad es la vulnerabilidad más común de la lista, y suele ser el resultado de usar configuraciones por defecto o de mostrar errores excesivamente detallados. Por ejemplo, una aplicación podría mostrar al usuario errores demasiado descriptivos que mostraran vulnerabilidades en la aplicación. Esto se puede mitigar mediante la eliminación cualquier función no utilizada en el código y al asegurarse de que los mensajes de error sean más generales.
La categoría errores de configuración de seguridad incluye el ataque XML External Entities (XEE), que anteriormente era parte de una categoría propia en el informe de 2017. Se trata de un ataque contra una aplicación web que analiza la entrada XML*. Esta entrada puede hacer referencia a una entidad externa que intenta aprovechar una vulnerabilidad en el analizador. Una "entidad externa" en este contexto hace referencia a una unidad de almacenamiento, como un disco duro. Se puede engañar a un analizador XML para que envíe datos a una entidad externa no autorizada, que puede pasar datos confidenciales directamente a un atacante. La mejor manera de prevenir los ataques XEE es hacer que las aplicaciones web acepten un tipo de datos menos complejo, como JSON, o al menos revisar los analizadores XML y deshabilitar el uso de entidades externas en una aplicación XML.
*XML, o lenguaje de marcado extensible, es un lenguaje de marcado que es legible tanto por humanos como por máquinas. Por su complejidad y las vulnerabilidades de seguridad, se está dejando de utilizar en muchas aplicaciones web.
Muchos desarrolladores web modernos utilizan componentes como bibliotecas y marcos en sus aplicaciones web. Estos componentes son piezas de software que ayudan a los desarrolladores a evitar el trabajo redundante y a ofrecer la funcionalidad necesaria; un ejemplo común son los marcos frontales como React y las bibliotecas más pequeñas que se utilizan para añadir iconos compartidos o pruebas a/b. Algunos atacantes buscan vulnerabilidades en estos componentes que luego pueden utilizar para orquestar ataques. Algunos de los componentes más famosos se utilizan en cientos de miles de sitios web; un atacante que encuentre un agujero de seguridad en uno de estos componentes podría dejar cientos de miles de sitios vulnerables.
Los desarrolladores de componentes suelen ofrecer revisiones de seguridad y actualizaciones para solucionar problemas de vulnerabilidad conocidos, pero los desarrolladores de aplicaciones web no siempre tienen las versiones de componentes más recientes o las revisiones que se ejecutan en sus aplicaciones. Para minimizar los riesgos de ejecutar componentes con vulnerabilidades conocidas, los desarrolladores deben eliminar los componentes que no utilicen y asegurarse de que reciben componentes actualizados de una fuente de confianza.
Las vulnerabilidades en los sistemas de autenticación (login) pueden dar a los atacantes acceso a las cuentas de los usuarios e incluso la capacidad de poner en riesgo todo un sistema mediante el uso de una cuenta de administrador. Por ejemplo, un atacante puede coger una lista con miles de combinaciones conocidas de nombres de usuarios y contraseñas conseguidas durante una fuga de datos, y utilizar un script para probar todas esas combinaciones en un sistema de inicio de sesión para ver si funciona alguna.
Algunas estrategias para mitigar las vulnerabilidades de autenticación son pedir la autenticación en dos fases (2FA), así como limitar o retrasar los intentos repetidos de inicio de sesión mediante el uso de la limitación de velocidad.
En la actualidad, muchas aplicaciones dependen de complementos de terceros y otras fuentes externas para su funcionamiento, y no siempre se aseguran de que las actualizaciones y los datos de esas fuentes no hayan sido manipulados y se originen en una ubicación esperada. Por ejemplo, una aplicación que acepta automáticamente actualizaciones de una fuente externa podría estar expuesta a que un atacante cargue sus propias actualizaciones maliciosas, que luego se distribuirían a todas las instalaciones de esa aplicación. Esta categoría también incluye las vulnerabilidades de deserialización no seguras: estos ataques son el resultado de la deserialización de datos de fuentes no fiables, y pueden tener graves consecuencias, como ataques DDoS y ataques de ejecución remota de código.
Para garantizar que no se haya violado la integridad de los datos y las actualizaciones, los desarrolladores de aplicaciones deben utilizar firmas digitales para verificar las actualizaciones, controlar sus cadenas de suministro de software y asegurarse de que las canalizaciones de integración/implementación continuas (CI/CD) tengan un control de acceso estricto y estén configuradas correctamente.
Muchas aplicaciones web no toman suficientes medidas para detectar las fugas de datos. Se suele tardar unos 200 días de media en detectar una fuga después de que esta se haya producido. Esto da a los atacantes mucho tiempo para causar daños antes de que haya una respuesta. OWASP recomienda que los desarrolladores web implementen planes de registro y supervisión, así como de respuesta a incidentes, para asegurarse de que están al tanto de los ataques a sus aplicaciones.
La falsificación de solicitudes del lado del servidor (SSRF) es un ataque en el que alguien envía una solicitud de URL a un servidor que hace que el servidor obtenga un recurso inesperado, incluso si ese recurso está protegido de otra manera. Un atacante podría, por ejemplo, enviar una solicitud a www.example.com/super-secret-data/, aunque se supone que los usuarios de la web no pueden navegar a esa ubicación, y obtener acceso a datos supersecretos de la respuesta del servidor.
Hay una serie de posibles mitigaciones para los ataques SSRF, y una de las más importantes es validar todas las URL procedentes de los clientes. Las URL no válidas no deberían generar una respuesta directa y sin procesar del servidor.
Para un análisis más técnico y profundo del OWASP Top 10, consulta el informe oficial.