¿Que es OWASP?
El OWASP opera sobre un principio central que hace que todo su material esté disponible y accesible gratuitamente en su sitio web. Este enfoque de comunidad abierta garantiza que cualquier persona y cualquier organización puedan mejorar la seguridad de sus aplicaciones web. Los materiales que proporciona incluyen documentación, eventos, foros, proyectos, herramientas y videos, como OWASP Top 10, el protocolo web OWASP CLASP y OWASP ZAP, un escáner de aplicaciones web de código abierto.
El OWASP es importante para las organizaciones porque su consejo es muy apreciado por los auditores, quienes consideran que las empresas que no abordan la lista OWASP Top 10 no cumplen con los estándares de cumplimiento. Por lo tanto, las organizaciones necesitan incorporar los consejos de protección de OWASP en su ciclo de vida de desarrollo de software y usarlos para dar forma a sus políticas y mejores prácticas.
¿Qué es el OWASP Top 10 y cómo funciona?
El OWASP Top 10 es un informe, o «documento de concientización», que describe las preocupaciones de seguridad en torno a la seguridad de las aplicaciones web. Se actualiza regularmente para garantizar que presente constantemente los 10 riesgos más críticos que enfrentan las organizaciones. OWASP recomienda a todas las empresas que incorporen los hallazgos del documento en sus procesos corporativos para garantizar que minimicen y mitiguen los riesgos de seguridad más recientes.
El informe de vulnerabilidades de OWASP está formado por consenso de expertos en seguridad de todo el mundo. Clasifica los riesgos según la frecuencia de los defectos de seguridad, la gravedad de la vulnerabilidad y su impacto potencial. Esto proporciona a los desarrolladores y profesionales de la seguridad información sobre los riesgos más destacados y les permite minimizar el potencial de los riesgos en las prácticas de seguridad de sus organizaciones.
1. Inyección
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.
2. Autenticación rota
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.
3. Exposición de datos confidenciales
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.
4. Entidades XML externas (XXE)
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.
5. Pérdida de control de acceso
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.
6. Mala configuración de la seguridad
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.
7. Scripting entre sitios
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.
8. Deserialización no segura
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.
9. Uso de componentes con vulnerabilidades conocidas
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.
10. Registro y supervisión insuficientes
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.
< 1 – 2 >
Fuentes de Información
Si deseas que tu empresa cuentes con expertos que te puedan asesorar para la protección de tu empresa para estos ataques, haz clic aquí y uno de nuestros asesores se podrá en contacto contigo para proporcionarte más información sobre el servicio.
0 comentarios