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íbase a theNET, el resumen mensual de Cloudflare sobre las ideas más populares de Internet.
Copiar 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 OWASP Top 10 es un informe que se actualiza con regularidad y en el que se exponen los problemas de seguridad de las aplicaciones web, centrándose en los 10 riesgos más importantes. El informe lo elabora un equipo de expertos en seguridad de todo el mundo. El OWASP hace referencia al Top 10 como un "documento de concienciació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 OWASP Top 10 de 2017:
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.
Los ataques de inyección pueden evitarse al validar o sanear los datos enviados por el usuario. (La validación significa rechazar los datos que tienen un aspecto sospechoso, mientras que la sanitización hace referencia a la limpieza de las partes de aspecto sospechoso de los datos). Además, el administrador de la base de datos puede establecer controles para minimizar la cantidad de información que puede sacar a la luz un ataque de inyección.
Más información sobre cómo evitar la inyección de código SQL.
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.
Si las aplicaciones web no protegen los datos confidenciales, como la información financiera y las contraseñas, los atacantes pueden acceder a esos datos y venderlos o utilizarlos con fines maliciosos. Un método popular para robar información confidencial es el uso de un ataque en ruta.
El riesgo de exposición de datos puede minimizarse al encriptar todos los datos confidenciales, y al desactivar el almacenamiento en caché* de cualquier información confidencial. Además, los desarrolladores de aplicaciones web deben asegurarse de que no están almacenando innecesariamente ningún dato confidencial.
*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.
Este es un ataque contra una aplicación web que analiza la entrada XML*. Esta entrada puede hacer referencia a una entidad externa, que intenta aprovecharse de una vulnerabilidad en el analizador. En este contexto, una "entidad externa" hace referencia a una unidad de almacenamiento, como un disco duro. A un analizador XML se le puede engañar para que envíe datos a una entidad externa no autorizada, que a su vez 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 dato menos complejo, como JSON**, o al menos parchear los analizadores XML y desactivar el uso de entidades externas en una aplicación XML.
*XML, o Lenguaje de marcado extensible, es un lenguaje de marcado destinado a ser legible tanto por humanos como por máquinas. Debido a su complejidad y su las vulnerabilidades de seguridad, se está dejando de utilizar en muchas aplicaciones web.
**La Notación de objetos de JavaScript (JSON) es un tipo de notación simple y legible para seres humanos que se suele utilizar para transmitir datos a través de Internet. Aunque fue creado originalmente para JavaScript, JSON es independiente del lenguaje y puede ser interpretado por diferentes lenguajes de programación.
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 inician sesión los usuarios. Cada solicitud privilegiada que haga un usuario requerirá que haya un token de autorización. Esta es una forma segura de garantizar que el usuario es quien dice ser, sin tener que introducir constantemente sus credenciales de acceso.
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.
Las vulnerabilidades de scripting entre sitios se producen cuando las aplicaciones web permiten que los usuarios añadan código personalizado en una url o en un sitio web que será visto por otros usuarios. Esta vulnerabilidad puede ser explotada para ejecutar código JavaScript malicioso en el navegador de la víctima. Por ejemplo, un atacante podría enviar un correo electrónico a una víctima que parece que viene de un banco de confianza, con un enlace al sitio web de dicho banco. Este enlace podría tener algún código JavaScript malicioso etiquetado al final de la url. Si el sitio del banco no está debidamente protegido contra el scripting entre sitios, ese código malicioso se ejecutará en el navegador de la víctima cuando se haga clic en el enlace.
Las estrategias de mitigación para el scripting entre sitios incluyen evitar las solicitudes HTTP que no sean de confianza, así como validar o sanear el contenido generado por el usuario. El uso de marcos de desarrollo web modernos, como ReactJS y Ruby on Rails, también ofrece cierta protección integrada contra el scripting entre sitios.
Esta amenaza se dirige a las numerosas aplicaciones web que serializan y deserializan datos con frecuencia. La serialización implica tomar objetos del código de la aplicación y convertirlos en un formato que pueda ser utilizado con otro objetivo, como almacenar los datos en el disco o transmitirlos. La deserialización es justo lo contrario: convertir los datos serializados de nuevo en objetos que la aplicación pueda utilizar. La serialización es como meter los muebles en cajas antes de una mudanza, y la deserialización es como sacarlos de las cajas y volver a montarlos después de la mudanza. Un ataque de deserialización inseguro es como si la empresa de mudanzas manipulara el contenido de las cajas antes de desembalarlas.
Una explotación de deserialización insegura es el resultado de la deserialización de datos desde fuentes no confiables, y puede tener graves consecuencias, como los ataques DDoS y los ataques de ejecución remota de código. Aunque se pueden tomar medidas para intentar atrapar a los atacantes, como la supervisión de la deserialización y la implementación de comprobaciones de tipo, la única forma segura de protegerse antes los ataques de deserialización insegura es prohibir la deserialización de datos desde fuentes no fiables.
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 parches de seguridad y actualizaciones para tapar las vulnerabilidades conocidas, pero los desarrolladores de aplicaciones web no siempre tienen las versiones parcheadas o más recientes de los componentes que se ejecutan en sus aplicaciones. Para minimizar el riesgo de ejecutar componentes con vulnerabilidades conocidas, los desarrolladores deben eliminar de sus proyectos los componentes que no utilicen, así como asegurarse de que reciben componentes de una fuente de confianza y de que estos estén actualizados.
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.
Para un análisis más técnico y profundo del OWASP Top 10, consulta el informe oficial.