OWASP o Open Web Security Project es una organización benéfica sin fines 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 según la explotabilidad, la detectabilidad y el impacto en el software.
- Explotabilidad -
¿Qué se necesita para aprovechar la vulnerabilidad de seguridad? Máxima explotabilidad cuando el ataque solo necesita un navegador web y la menor es programación y herramientas avanzadas.
- Detectabilidad -
¿Qué tan fácil es detectar la amenaza? La más alta es la información que se muestra en la URL, el formulario o el mensaje de error y la más baja es el código fuente.
- Impacto o daño -
¿Cuánto daño se producirá si se expone o ataca la vulnerabilidad de seguridad? Lo más alto es un bloqueo completo del sistema y lo más bajo es nada en absoluto.
El objetivo principal de 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 OWASP Top 10 son:
- Inyección SQL
- Secuencias de comandos entre sitios
- Autenticación rota y gestión de sesiones
- Referencias de objetos directos inseguras
- Falsificación de solicitud entre sitios
- Configuración incorrecta de seguridad
- Almacenamiento criptográfico inseguro
- No restringir el acceso a la URL
- Protección insuficiente de la capa de transporte
- Redirecciones y reenvíos no validados
Inyección SQL
Descripción
La inyección es una vulnerabilidad de seguridad que permite a un atacante alterar declaraciones SQL de backend manipulando los datos proporcionados por el usuario.
La inyección ocurre 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 le da acceso a datos no autorizados.
El comando SQL que, cuando se ejecuta mediante una aplicación web, también puede exponer la base de datos back-end.
Implicación
- Un atacante puede inyectar contenido malicioso en los campos vulnerables.
- Los datos confidenciales como nombres de usuario, contraseñas, etc. se pueden leer de la base de datos.
- Los datos de la base de datos se pueden modificar (Insertar / Actualizar / Eliminar).
- Las operaciones de administración se pueden ejecutar en la base de datos
Objetos vulnerables
- Campos de entrada
- URL que interactúan con la base de datos.
Ejemplos:
- Inyección SQL en la página de inicio de sesión
Iniciar sesión en una aplicación sin tener credenciales válidas.
El nombre de usuario válido está disponible y la contraseña no está disponible.
URL 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 muestra a continuación
SELECCIONE * DE Usuarios DONDE User_Name = sjones AND Password = 1 = 1 'o pass123;
Recomendaciones
- Lista blanca de los campos de entrada
- Evite mostrar mensajes de error detallados que sean útiles para un atacante.
Secuencias de comandos entre sitios
Descripción
Cross Site Scripting también se conoce en breve como XSS.
Las vulnerabilidades XSS apuntan a 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. Estas fallas pueden ocurrir cuando la aplicación toma datos que no son de confianza y los envía al navegador web sin la validación adecuada.
Los atacantes pueden usar XSS para ejecutar scripts maliciosos en los usuarios, en este caso, en los navegadores de las víctimas. Dado que el navegador no puede saber si el script es confiable o no, el script se ejecutará y el atacante puede secuestrar las cookies de sesión, desfigurar sitios web o redirigir al usuario a sitios web no deseados y maliciosos.
XSS es un ataque que permite al atacante ejecutar los scripts en el navegador de la víctima.
Implicación:
- Al hacer uso de esta vulnerabilidad de seguridad, un atacante puede inyectar scripts en la aplicación, robar cookies de sesión, desfigurar sitios web y ejecutar malware en las máquinas de la víctima.
Objetos vulnerables
- Campos de entrada
- URLs
Ejemplos de
1. http://www.vulnerablesite.com/home?" < script > alert(" xss") script >
Cuando se ejecuta el script anterior en un navegador, se mostrará un cuadro de mensaje si el sitio es vulnerable a XSS.
El ataque más serio se puede realizar si el atacante desea mostrar o almacenar una cookie de sesión.
2. http://demo.testfire.net/search.aspx?txtSearch
Cuando se ejecuta la secuencia de comandos anterior, el navegador cargará un marco invisible que apunta a http://google.com .
El ataque puede agravarse ejecutando un script malicioso en el navegador.
Recomendaciones
- Campos de entrada de lista blanca
- Codificación de entrada y salida
Autenticación rota y gestión de sesiones
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 confidenciales como nombre de usuario, contraseña, etc. Cuando la sesión finaliza al cerrar la sesión o el navegador se cierra abruptamente, estas cookies deben invalidarse, es decir, para cada sesión. debería haber una nueva cookie.
Si las cookies no se invalidan, los datos sensibles existirán en el sistema. Por ejemplo, un usuario que usa una computadora pública (Cyber Cafe), las cookies del sitio vulnerable se encuentran en el sistema y están expuestas a un atacante. Un atacante usa la misma computadora pública después de un tiempo, los datos confidenciales se ven comprometidos.
De la misma manera, un usuario que usa una computadora pública, en lugar de cerrar la sesión, cierra el navegador abruptamente. 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 información de perfil, información de tarjeta de crédito, etc.
Se debe realizar una verificación para encontrar la solidez de la autenticación y la administración de sesiones. Las claves, los tokens de sesión y las cookies deben implementarse correctamente sin comprometer las contraseñas.
Objetos vulnerables
- Los ID de sesión expuestos en la URL pueden provocar un ataque de fijación de sesión.
- Los ID de sesión son los mismos antes y después del cierre de sesión y el inicio de sesión.
- Los tiempos de espera de la sesión no se implementan 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.
Implicación
- Haciendo uso de esta vulnerabilidad, un atacante puede secuestrar una sesión, obtener acceso no autorizado al sistema que permite la divulgación y modificación de información no autorizada.
- Las sesiones pueden ser secuestradas usando cookies robadas o sesiones usando XSS.
Ejemplos de
- La aplicación de reserva de aerolíneas admite la reescritura de URL, colocando los ID de sesión en la URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venta de entradas a Maldivas)
Un usuario autenticado del sitio quiere informar a sus amigos sobre la venta y envía un correo electrónico. Los amigos reciben la identificación de la sesión y se pueden utilizar para realizar modificaciones no autorizadas o hacer un mal uso de los datos guardados de la tarjeta de crédito.
- Una aplicación es vulnerable a XSS, mediante el cual un atacante puede acceder al ID de sesión y puede usarse para secuestrar la sesión.
- Los tiempos de espera de las aplicaciones no están configurados correctamente. El usuario usa una computadora pública y cierra el navegador en lugar de cerrar la sesión y se aleja. El atacante usa el mismo navegador algún tiempo después y la sesión se autentica.
Recomendaciones
- Todos los requisitos de autenticación y administración de sesiones deben definirse según el Estándar de verificación de seguridad de aplicaciones de OWASP.
- Nunca exponga credenciales en URL o registros.
- También se deben hacer grandes esfuerzos para evitar fallas XSS que pueden usarse para robar ID de sesión.
Referencias de objetos directos inseguras
Descripción
Ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, como un archivo, directorio o clave de base de datos como en una URL o como un parámetro 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
- Con esta vulnerabilidad, un atacante puede obtener acceso a objetos internos no autorizados, puede modificar datos o comprometer la aplicación.
Objetos vulnerables
- En la URL.
Ejemplos:
Cambiar "ID de usuario" en la siguiente URL puede hacer que un atacante vea 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 de identificación del usuario.
Recomendaciones:
- Implementar verificaciones de control de acceso.
- Evite exponer referencias a objetos en URL.
- Verifique la autorización de todos los objetos de referencia.
Falsificación de solicitud entre sitios
Descripción
La falsificación de solicitud de sitio cruzado es una solicitud falsificada procedente del sitio cruzado.
El ataque CSRF es un ataque que ocurre 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 confiable para el cual el usuario está actualmente autenticado.
Un ataque CSRF obliga al navegador de una víctima que ha iniciado sesión a enviar una solicitud HTTP falsificada, incluida 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 cuando inicie sesión en el sitio web original, los datos serán robados del sitio web.
Implicación
- El uso de esta vulnerabilidad como atacante puede cambiar la información del perfil del usuario, cambiar el estado, crear un nuevo usuario en nombre del administrador, etc.
Objetos vulnerables
- Página de perfil de usuario
- Formularios de cuenta de usuario
- Página de transacciones comerciales
Ejemplos de
La víctima inicia sesión en el sitio web de un banco con credenciales válidas. Recibe un correo de un atacante que dice "Haga clic aquí para donar $ 1 a la causa".
Cuando la víctima haga clic en él, se creará una solicitud válida para donar $ 1 a una cuenta en particular.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
El atacante captura esta solicitud y crea la solicitud a continuación y la inserta en un botón que dice "Apoyo la causa".
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Dado que la sesión está autenticada y la solicitud llega a través del sitio web del banco, el servidor transferiría $ 1000 dólares al atacante.
Recomendación
- Exigir la presencia del usuario mientras realiza acciones sensibles.
- Implemente mecanismos como CAPTCHA, Re-Autenticación y Tokens de solicitud únicos.
Configuración incorrecta de seguridad
Descripción
La configuración de seguridad debe definirse e implementarse para la aplicación, los marcos, el servidor de aplicaciones, el servidor web, el servidor de base de datos y la plataforma. Si se configuran correctamente, un atacante puede tener acceso no autorizado a datos confidenciales o funcionalidad.
A veces, tales fallas resultan en un compromiso completo del sistema. Mantener el software actualizado también es una buena seguridad.
Implicación
- Haciendo uso de esta vulnerabilidad, el atacante puede enumerar la tecnología subyacente y la información de la versión del servidor de la aplicación, la información de la base de datos y obtener información sobre la aplicación para montar algunos ataques más.
Objetos vulnerables
- URL
- Campos de formulario
- Campos de entrada
Ejemplos de
- La consola de administración del servidor de aplicaciones se instala automáticamente y no se elimina. Las cuentas predeterminadas no se cambian. El atacante puede iniciar sesión con contraseñas predeterminadas y puede obtener acceso no autorizado.
- La lista de directorios no está deshabilitada en su servidor. El atacante descubre y puede simplemente enumerar directorios para encontrar cualquier archivo.
Recomendaciones
- Una arquitectura de aplicación sólida que proporciona una buena separación y seguridad entre los componentes.
- Cambie los nombres de usuario y las contraseñas predeterminados.
- Desactive las listas de directorios e implemente comprobaciones de control de acceso.
Almacenamiento criptográfico inseguro
Descripción
El almacenamiento criptográfico inseguro es una vulnerabilidad común que existe cuando los datos confidenciales no se almacenan de forma segura.
Las credenciales de usuario, la información de perfil, los detalles de salud, la información de la tarjeta de crédito, etc. se incluyen en información confidencial en un sitio web.
Estos datos se almacenarán en la base de datos de la aplicación. Cuando estos datos se almacenan incorrectamente al no usar cifrado o hash *, serán vulnerables a los atacantes.
(* El hash es la transformación de los caracteres de la cadena 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
- Al utilizar esta vulnerabilidad, un atacante puede robar, modificar esos datos débilmente protegidos para realizar un robo de identidad, fraude con tarjetas de crédito u otros delitos.
Objetos vulnerables
- Base de datos de la aplicación.
Ejemplos de
En una de las aplicaciones bancarias, la base de datos de contraseñas utiliza hashes * sin sal para almacenar las contraseñas de todos. Una falla de inyección SQL permite al atacante recuperar el archivo de contraseña. Todos los hashes sin sal se pueden forzar brutalmente en poco tiempo, mientras que las contraseñas saladas tardarían miles de años.
(* Hashes sin sal: Salt es un dato aleatorio adjunto a los datos originales. Salt se adjunta a la contraseña antes del hash)
Recomendaciones
- Asegurar algoritmos estándar sólidos adecuados. No cree algoritmos criptográficos propios. Utilice solo 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 encriptadas, pero que las claves se administren y respalden por separado.
No restringir el acceso a la URL
Descripción
Las aplicaciones web comprueban los derechos de acceso a la URL antes de mostrar enlaces y botones protegidos. Las aplicaciones deben 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.
Mediante una suposición inteligente, un atacante puede acceder a páginas de privilegios. Un atacante puede acceder a páginas sensibles, invocar funciones y ver información confidencial.
Implicación
- Al hacer uso de esta vulnerabilidad, el atacante puede obtener acceso a las URL no autorizadas, sin iniciar sesión en la aplicación y aprovechar la vulnerabilidad. Un atacante puede acceder a páginas sensibles, invocar funciones y ver información confidencial.
Objetos vulnerables:
- URLs
Ejemplos de
- El atacante nota que la URL indica el rol como "/ user / getaccounts". Se modifica como "/ admin / getaccounts".
- Un atacante puede agregar un rol a la URL.
http://www.vulnerablsite.com se puede modificar como http://www.vulnerablesite.com/admin
Recomendaciones
- Implemente comprobaciones sólidas de control de acceso.
- Las políticas de autenticación y autorización deben basarse en roles.
- Restrinja el acceso a URL no deseadas.
Protección insuficiente de la capa de transporte
Descripción
Se ocupa del intercambio de información entre el usuario (cliente) y el servidor (aplicación). Las aplicaciones transmiten con frecuencia información confidencial 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 no usar SSL puede permitir que la comunicación se exponga a usuarios que no son de confianza, lo que puede comprometer una aplicación web o robar información confidencial.
Implicación
- Al hacer uso de esta vulnerabilidad de seguridad web, un atacante puede rastrear las credenciales de un usuario legítimo y obtener acceso a la aplicación.
- Puede robar información de tarjetas de crédito.
Objetos vulnerables
- Datos enviados a través de la red.
Recomendaciones
- Habilite HTTP seguro y aplique la transferencia de credenciales solo a través de HTTPS.
- Asegúrese de que su certificado sea válido y no esté vencido.
Ejemplos:
1. Una aplicación que no usa SSL, un atacante simplemente monitoreará el tráfico de red y observará una cookie de sesión de víctima autenticada. 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 para un propósito previsto.
Si no hay una validación adecuada al redirigir 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 reenvíos para acceder a páginas no autorizadas.
Implicación
- Un atacante puede enviar una URL al usuario que contiene una URL genuina adjunta con una URL maliciosa codificada. Un usuario con solo ver la parte genuina de la URL enviada por el atacante puede navegar y convertirse en una víctima.
Ejemplos de
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modificado a
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Recomendaciones
- Simplemente evite el uso de redireccionamientos y reenvíos en la aplicación. Si se utiliza, no implique el uso de parámetros de usuario para calcular el destino.
- Si no se pueden evitar los parámetros de destino, asegúrese de que el valor proporcionado sea válido y esté autorizado para el usuario.
Este artículo es una contribución de Prasanthi Eati.