OWASP o Open Web Security Project es una organización benéfica sin ánimo de lucro centrada en mejorar la seguridad del software y las aplicaciones web.
La organización publica una lista de las principales vulnerabilidades de seguridad web basada en los datos de varias organizaciones de seguridad.
Las vulnerabilidades de seguridad web se priorizan en función de la explotabilidad, la detectabilidad y el impacto en el software.
- Explotabilidad –
¿Qué se necesita para explotar la vulnerabilidad de seguridad? La más alta explotabilidad cuando el ataque sólo necesita el navegador web y la más baja siendo programación y herramientas avanzadas.
- Detectabilidad –
¿Cómo de fácil es detectar la amenaza? La más alta siendo la información mostrada en la URL, el Formulario o el mensaje de Error y la más baja siendo el código fuente.
- Impacto o daño –
¿Cuánto daño se producirá si la vulnerabilidad de seguridad es expuesta o atacada? El más alto siendo la caída completa del sistema y el más bajo siendo nada.
- Inyección SQL
- Cross Site Scripting
- Autenticación y gestión de sesiones rotas
- Referencias directas de objetos inseguras
- Falsificación de solicitudes en sitios cruzados
- Mala configuración de seguridad
- Almacenamiento criptográfico inseguro
- Falta de restricción de acceso a URL
- Insuficiente Protección de la capa de transporte
- Redirecciones y reenvíos no validados
- Un atacante puede inyectar contenido malicioso en los campos vulnerables.
- Datos sensibles como Nombres de Usuarios, Contraseñas, etc. pueden ser leídos desde la base de datos.
- Los datos de la base de datos pueden ser modificados (Insertar/Actualizar/Eliminar).
- Se pueden ejecutar operaciones de administración en la base de datos
- Campos de entrada
- URLs que interactúan con la base de datos.
- Inyección SQL en la página de inicio de sesión
- Enumerar en blanco los campos de entrada
- Evitar mostrar mensajes de error detallados que sean útiles para un atacante.
- Haciendo uso de esta vulnerabilidad de seguridad, un atacante puede inyectar scripts en la aplicación, puede robar cookies de sesión, desfigurar sitios web y puede ejecutar malware en las máquinas de la víctima.
- Campos de entrada
- URLs
- Listado en blanco de los campos de entrada
- Codificación de la salida de la entrada
- Los IDs de sesión expuestos en la URL pueden llevar a un ataque de fijación de sesión.
- Los IDs de sesión son los mismos antes y después del cierre de sesión y del inicio de sesión.
- Los tiempos de espera de sesión no están implementados correctamente.
- La aplicación asigna el mismo ID de sesión para cada nueva sesión.
- Las partes autenticadas de la aplicación están protegidas mediante SSL y las contraseñas se almacenan en formato hash o cifrado.
- La sesión puede ser reutilizada por un usuario con pocos privilegios.
- Haciendo uso de esta vulnerabilidad, un atacante puede secuestrar una sesión, obtener acceso no autorizado al sistema lo que permite la divulgación y modificación de información no autorizada.
- Las sesiones pueden ser high jacked usando cookies robadas o sesiones usando XSS.
- Una aplicación de reservas de avión soporta la reescritura de URLs, poniendo IDs de sesión en la URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venta de billetes a Maldivas)
Un usuario autentificado del sitio quiere avisar a sus amigos de la venta y envía un correo electrónico a través. Los amigos reciben el ID de la sesión y pueden ser utilizados para hacer modificaciones no autorizadas o hacer un mal uso de los datos de la tarjeta de crédito guardados.
- Una aplicación es vulnerable a XSS, por lo que un atacante puede acceder al ID de sesión y puede ser utilizado para secuestrar la sesión.
- Los tiempos de espera de las aplicaciones no están configurados correctamente. El usuario utiliza un ordenador público y cierra el navegador en lugar de cerrar la sesión y se marcha. El atacante utiliza el mismo navegador algún tiempo después, y la sesión se autentifica.
- Todos los requisitos de autenticación y gestión de sesiones deben definirse según el estándar de verificación de seguridad de aplicaciones de OWASP.
- Nunca expongas ninguna credencial en URLs o Logs.
- También se deben hacer grandes esfuerzos para evitar los fallos de XSS que pueden ser utilizados para robar IDs de sesión.
- Usando esta vulnerabilidad, un atacante puede acceder a objetos internos no autorizados, puede modificar datos o comprometer la aplicación.
- En la URL.
- Implementar comprobaciones de control de acceso.
- Evitar exponer referencias a objetos en las URLs.
- Verificar la autorización a todos los objetos de referencia.
- Usando esta vulnerabilidad como un atacante puede cambiar la información del perfil del usuario, cambiar el estado, crear un nuevo usuario en nombre del administrador, etc.
- Página de perfil de usuario
- Formularios de cuentas de usuario
- Página de transacciones comerciales
- Exigir la presencia del usuario mientras realiza acciones sensibles.
- Implementar mecanismos como , Re-Autenticación, y Tokens de solicitud únicos.
- Haciendo uso de esta vulnerabilidad, el atacante puede enumerar la tecnología subyacente y la información de la versión del servidor de aplicaciones, la información de la base de datos y obtener información sobre la aplicación para montar algunos ataques más.
- Campos de formulario
- Campos de entrada
- La consola de administración del servidor de aplicaciones se instala automáticamente y no se elimina. Las cuentas por defecto no se modifican. El atacante puede iniciar sesión con las contraseñas predeterminadas y puede obtener acceso no autorizado.
- El listado de directorios no está desactivado en su servidor. El atacante descubre y puede simplemente listar los directorios para encontrar cualquier archivo.
- Una arquitectura de aplicación fuerte que proporcione una buena separación y seguridad entre los componentes.
- Cambiar los nombres de usuario y contraseñas por defecto.
- Desactivar los listados de directorios e implementar comprobaciones de control de acceso.
- Utilizando esta vulnerabilidad, un atacante puede robar, modificar esos datos débilmente protegidos para realizar robos de identidad, fraudes con tarjetas de crédito u otros delitos.
- Base de datos de la aplicación.
- Asegurar algoritmos estándar fuertes y apropiados. No crear algoritmos criptográficos propios. Utilice sólo algoritmos públicos aprobados, como AES, criptografía de clave pública RSA y SHA-256, etc.
- Asegúrese de que las copias de seguridad externas están cifradas, pero las claves se gestionan y respaldan por separado.
- Haciendo uso de esta vulnerabilidad el atacante puede acceder a las URLs no autorizadas, sin iniciar sesión en la aplicación y explotar la vulnerabilidad. Un atacante puede acceder a páginas sensibles, invocar funciones y ver información confidencial.
- URLs
- El atacante observa que la URL indica el rol como «/user/getaccounts». Modifica como «/admin/getaccounts».
- Un atacante puede anexar el rol a la URL.
- Implementar fuertes comprobaciones de control de acceso.
- Las políticas de autenticación y autorización deben estar basadas en roles.
- Restringir el acceso a URLs no deseadas.
- Aprovechando esta vulnerabilidad de seguridad web, un atacante puede husmear las credenciales de un usuario legítimo y acceder a la aplicación.
- Puede robar información de tarjetas de crédito.
- Datos enviados por la red.
- Activar el HTTP seguro y forzar la transferencia de credenciales sólo a través de HTTPS.
- Asegurarse de que el certificado es válido y no está caducado.
- Un atacante puede enviar una URL al usuario que contenga una URL genuina anexada con una URL maliciosa codificada. Un usuario con sólo ver la parte genuina de la URL enviada por el atacante puede navegar por ella y puede convertirse en una víctima.
- Simplemente evitar el uso de redirecciones y reenvíos en la aplicación. Si se utilizan, no implique el uso de parámetros de usuario en el cálculo del destino.
- Si los parámetros de destino no se pueden evitar, asegúrese de que el valor suministrado es válido, y autorizado para el usuario.
El objetivo principal del OWASP Top 10 es educar a los desarrolladores, diseñadores, gerentes, arquitectos y organizaciones sobre las vulnerabilidades de seguridad más importantes.
Las 10 principales vulnerabilidades de seguridad según el OWASP Top 10 son:
Inyección SQL
Descripción
La inyección es una vulnerabilidad de seguridad que permite a un atacante alterar las sentencias SQL del backend manipulando los datos suministrados por el usuario.
La inyección se produce cuando la entrada del usuario se envía a un intérprete como parte de un comando o consulta y engaña al intérprete para que ejecute comandos no deseados y dé acceso a datos no autorizados.
El comando SQL que cuando se ejecuta por la aplicación web también puede exponer la base de datos de back-end.
Implicación
Objetos vulnerables
Ejemplos:
Entrar en una aplicación sin tener credenciales válidas.
Se dispone de un nombre de usuario válido y no se dispone de una contraseña.
Red de prueba: http://demo.testfire.net/default.aspx
Nombre de usuario: sjones
Contraseña: 1=1′ o pass123
Consulta SQL creada y enviada al Intérprete como se indica a continuación
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ o pass123;
Recomendaciones
Cross Site Scripting
Descripción
El Cross Site Scripting también se conoce brevemente como XSS.
Las vulnerabilidades XSS tienen como objetivo los scripts incrustados en una página que se ejecutan en el lado del cliente, es decir, en el navegador del usuario, en lugar de en el lado del servidor. Estos fallos pueden producirse cuando la aplicación toma datos no fiables y los envía al navegador web sin la validación adecuada.
Los atacantes pueden utilizar XSS para ejecutar scripts maliciosos en los usuarios, en este caso los navegadores víctimas. Como el navegador no puede saber si el script es de confianza o no, el script se ejecutará, y el atacante puede secuestrar las cookies de sesión, desfigurar los sitios web o redirigir al usuario a un sitio web no deseado y malicioso.
XSS es un ataque que permite al atacante ejecutar los scripts en el navegador de la víctima.
Implicación:
Objetos vulnerables
Ejemplos
1. http://www.vulnerablesite.com/home?»<script>alert(«xss»)</script>
El script anterior cuando se ejecuta en un navegador, se mostrará un cuadro de mensaje si el sitio es vulnerable a XSS.
El ataque más grave se puede realizar si el atacante quiere mostrar o almacenar la cookie de sesión.
2. http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com width = 500 height 500></iframe>
El script anterior cuando se ejecute, el navegador cargará un marco invisible que apunta a http://google.com.
El ataque se puede agravar ejecutando un script malicioso en el navegador.
Recomendaciones
Autenticación y gestión de sesiones rotas
Descripción
Los sitios web suelen crear una cookie de sesión y un ID de sesión para cada sesión válida, y estas cookies contienen datos sensibles como el nombre de usuario, la contraseña, etc. Cuando se termina la sesión, ya sea por cierre de sesión o por cierre abrupto del navegador, estas cookies deben ser invalidadas, es decir, para cada sesión debe haber una nueva cookie.
Si las cookies no se invalidan, los datos sensibles existirán en el sistema. Por ejemplo, un usuario que utiliza un ordenador público (Ciber Café), las cookies del sitio vulnerable permanecen en el sistema y están expuestas a un atacante. Un atacante utiliza el mismo ordenador público después de algún tiempo, los datos sensibles están comprometidos.
De la misma manera, un usuario que utiliza un ordenador público, en lugar de cerrar la sesión, cierra el navegador bruscamente. Un atacante utiliza el mismo sistema, cuando navega por el mismo sitio vulnerable, se abrirá la sesión anterior de la víctima. El atacante puede hacer lo que quiera desde robar la información del perfil, la información de la tarjeta de crédito, etc.
Se debe comprobar la fortaleza de la autenticación y la gestión de la sesión. Las claves, los tokens de sesión, las cookies deben ser implementadas correctamente sin comprometer las contraseñas.
Objetos Vulnerables
Implicación
Ejemplos
Recomendaciones
Referencias directas inseguras a objetos
Descripción
Se produce cuando un desarrollador expone una referencia a un objeto de implementación interna, como un archivo, directorio o clave de base de datos como en la URL o como parámetro de un FORM. El atacante puede utilizar esta información para acceder a otros objetos y puede crear un ataque futuro para acceder a los datos no autorizados.
Implicación
Objetos vulnerables
Ejemplos:
Cambiar «userid» en la siguiente URL puede hacer que un atacante pueda ver la información de otro usuario.
http://www.vulnerablesite.com/userid=123 Modificado a http://www.vulnerablesite.com/userid=124
Un atacante puede ver la información de otros cambiando el valor del id de usuario.
Recomendaciones:
Falsificación de Solicitudes de Sitio Cruzado
Descripción
La Falsificación de Solicitudes de Sitio Cruzado es una solicitud falsificada que proviene del sitio cruzado.
El ataque CSRF es un ataque que se produce cuando un sitio web, correo electrónico o programa malicioso hace que el navegador de un usuario realice una acción no deseada en un sitio de confianza para el que el usuario está actualmente autenticado.
Un ataque CSRF obliga al navegador de una víctima conectada a enviar una solicitud HTTP falsificada, incluyendo la cookie de sesión de la víctima y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable.
El atacante enviará un enlace a la víctima cuando el usuario haga clic en la URL al iniciar sesión en el sitio web original, los datos serán robados del sitio web.
Implicación
Objetos vulnerables
Ejemplos
La víctima está logueada en la web de un banco usando credenciales válidas. Recibe un correo de un atacante que dice «Por favor, haga clic aquí para donar 1 dólar a la causa».
Cuando la víctima haga clic en él, se creará una solicitud válida para donar 1$ a una cuenta concreta.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
El atacante captura esta solicitud y crea debajo la solicitud y la incrusta en un botón que dice «Apoyo a la causa.»
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Como la sesión está autenticada y la petición viene a través de la web del banco, el servidor transferiría 1000 dólares al atacante.
Recomendación
Desconfiguración de la seguridad
Descripción
La configuración de la seguridad debe ser definida y desplegada para la aplicación, los frameworks, el servidor de aplicaciones, el servidor web, el servidor de base de datos y la plataforma. Si estos están bien configurados, un atacante puede tener acceso no autorizado a datos o funcionalidades sensibles.
A veces, estos fallos dan lugar a un compromiso completo del sistema. Mantener el software actualizado también es una buena seguridad.
Implicación
Objetos vulnerables
Ejemplos
Recomendaciones
Almacenamiento criptográfico inseguro
Descripción
El almacenamiento criptográfico inseguro es una vulnerabilidad común que existe cuando los datos sensibles no se almacenan de forma segura.
Las credenciales de usuario, la información del perfil, los detalles de salud, la información de la tarjeta de crédito, etc. entran dentro de la información de datos sensibles en un sitio web.
Estos datos se almacenan en la base de datos de la aplicación. Cuando estos datos se almacenan de forma inadecuada al no utilizar encriptación o hashing*, serán vulnerables a los atacantes.
(*Hashing es la transformación de las cadenas de caracteres en cadenas más cortas de longitud fija o una clave. Para descifrar la cadena, el algoritmo utilizado para formar la clave debe estar disponible)
Implicación
Objetos vulnerables
Ejemplos
En una de las aplicaciones bancarias, la base de datos de contraseñas utiliza hashes * no salados para almacenar las contraseñas de todos. Un fallo de inyección SQL permite al atacante recuperar el archivo de contraseñas. Todos los hashes sin salar pueden ser forzados en poco tiempo, mientras que las contraseñas con salar tardarían miles de años.
(*Hashes sin sal – La sal es un dato aleatorio añadido a los datos originales. La sal se añade a la contraseña antes del hash)
Recomendaciones
Falta de restricción de acceso a URL
Descripción
Las aplicaciones web comprueban los derechos de acceso a las URL antes de renderizar enlaces y botones protegidos. Las aplicaciones necesitan realizar comprobaciones de control de acceso similares cada vez que se accede a estas páginas.
En la mayoría de las aplicaciones, las páginas, ubicaciones y recursos privilegiados no se presentan a los usuarios privilegiados.
Con una suposición inteligente, un atacante puede acceder a las páginas con privilegios. Un atacante puede acceder a páginas sensibles, invocar funciones y ver información confidencial.
Implicación
Objetos vulnerables:
Ejemplos
http://www.vulnerablsite.com puede modificarse como http://www.vulnerablesite.com/admin
Recomendaciones
Insuficiente protección de la capa de transporte
Descripción
Trata del intercambio de información entre el usuario (cliente) y el servidor (aplicación). Las aplicaciones transmiten frecuentemente información sensible como detalles de autenticación, información de tarjetas de crédito y tokens de sesión a través de una red.
El uso de algoritmos débiles o el uso de certificados caducados o no válidos o el no uso de SSL puede permitir que la comunicación esté expuesta a usuarios no confiables, lo que puede comprometer una aplicación web y o robar información sensible.
Implicación
Objetos vulnerables
Recomendaciones
Ejemplos:
1. Una aplicación que no utilice SSL, un atacante simplemente monitorizará el tráfico de red y observará una cookie de sesión de la víctima autentificada. Un atacante puede robar esa cookie y realizar un ataque Man-in-the-Middle.
Redirecciones y reenvíos no validados
Descripción
La aplicación web utiliza pocos métodos para redirigir y reenviar a los usuarios a otras páginas con un propósito previsto.
Si no hay una validación adecuada mientras se redirige a otras páginas, los atacantes pueden hacer uso de esto y pueden redirigir a las víctimas a sitios de phishing o malware, o utilizar los reenvíos para acceder a páginas no autorizadas.
Implicación
Ejemplos
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modificado a
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Recomendaciones
Este artículo ha sido contribuido por Prasanthi Eati