Las 10 vulnerabilidades de seguridad web más comunes

OWASP u Open Web Security Project es una organización benéfica sin fines de lucro enfocada 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 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 explotar la vulnerabilidad de seguridad? La mayor explotabilidad es 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 fácil es la información que se muestra en la URL, el formulario o el mensaje de error, y la más fácil es el código fuente.
• Impacto o daño –¿Cuánto daño se producirá si la vulnerabilidad de seguridad queda expuesta o atacada? El más alto es un fallo completo del sistema y el más bajo es nada en absoluto.

El objetivo principal de OWASP Top 10 es educar a los desarrolladores, diseñadores, administradores, arquitectos y organizaciones sobre las vulnerabilidades de seguridad más importantes.

Las 10 principales vulnerabilidades de seguridad según OWASP Top 10 son:

SQL Injection

Descripciones

La inyección es una vulnerabilidad de seguridad que permite a un atacante alterar el backend SQL declaraciones 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 desde la base de datos.
• Los datos de la base de datos se pueden modificar (Insertar/Actualizar/Eliminar).
• Administración OperaLas operaciones 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 Nombre_Usuario = sjones Y Contraseña = 1=1′ o pass123;

Recomendaciones

1. Listado blanco de los campos de entrada.
2. Evite mostrar mensajes de error detallados que sean útiles para un atacante.

Secuencias de comandos entre sitios

Descripciones

Cross Site Scripting también se conoce brevemente como XSS.

Las vulnerabilidades XSS se dirigen 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 utilizar XSS para ejecutar scripts maliciosos en los navegadores de los usuarios, en este caso 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 cookies de sesión, alterar sitios web o redirigir al usuario a sitios web maliciosos y no deseados.

XSS es un ataque que permite al atacante ejecutar scripts en el navegador de la víctima.

Implicación:

• Al aprovechar 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
• URL

Ejemplos

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

Cuando el script anterior se ejecuta en un navegador, se mostrará un cuadro de mensaje si el sitio es vulnerable a XSS.

Se puede realizar un ataque más grave si el atacante desea mostrar o almacenar cookies de sesión.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> <fuente = http://google.com ancho = 500 alto 500>

Cuando se ejecuta el script 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

1. Campos de entrada de Lista blanca
2. Codificación de entrada y salida

Autenticación rota y gestión de sesiones

Descripciones

Los sitios web generalmente crean 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, ya sea al cerrar sesión o al cerrar el navegador abruptamente, estas cookies deben invalidarse, es decir, para cada sesión. Debería haber una nueva cookie.

Si no se invalidan las cookies, los datos sensibles existirán en el sistema. Por ejemplo, un usuario que utiliza una computadora pública (Cyber ​​Café), las cookies del sitio vulnerable se almacenan en el sistema y quedan expuestas a un atacante. Un atacante utiliza la misma computadora pública después de un tiempo, los datos confidenciales se ven comprometidos.

De la misma manera, un usuario que utiliza una computadora pública, en lugar de cerrar 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 tarjetas de crédito, etc.

Se debe realizar una verificación para encontrar la solidez de la autenticación y la gestió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 de cerrar sesión e iniciar sesión.
• Los tiempos de espera de 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

• Al aprovechar esta vulnerabilidad, un atacante puede secuestrar una sesión y obtener acceso no autorizado al sistema, lo que permite la divulgación y modificación de información no autorizada.
• Las sesiones pueden ser secuestradas mediante cookies robadas o sesiones mediante XSS.

Ejemplos

1. La aplicación de reservas de aerolíneas admite la reescritura de URL, colocando ID de sesión en la URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venta de billetes 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 el ID de sesión y pueden utilizarlo para realizar modificaciones no autorizadas o hacer un uso indebido de los datos de la tarjeta de crédito guardados.
2. Una aplicación es vulnerable a XSS, mediante el cual un atacante puede acceder al ID de la sesión y puede usarse para secuestrar la sesión.
3. Los tiempos de espera de las aplicaciones no están configurados correctamente. El usuario utiliza una computadora pública y cierra el navegador en lugar de cerrar sesión y se marcha. El atacante utiliza el mismo navegador algún tiempo después y la sesión se autentica.

Recomendaciones

1. 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 OWASP.
2. Nunca exponga ninguna credencial en URL o registros.
3. También se deben realizar grandes esfuerzos para evitar fallas XSS que puedan usarse para robar identificaciones de sesión.

Referencias de objetos directos inseguras

Descripciones

Ocurre 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 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

• Al utilizar esta vulnerabilidad, un atacante puede obtener acceso a objetos internos no autorizados, modificar datos o comprometer la aplicación.

Objetos vulnerables

• En la URL.

Ejemplos:

Cambiar “userid” en la siguiente URL puede permitir 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:

1. Implementar controles de control de acceso.
2. Evite exponer referencias a objetos en las URL.
3. Verifique la autorización para todos los objetos de referencia.

Falsificación de solicitud entre sitios

Descripciones

La falsificación de solicitud entre sitios es una solicitud falsificada que proviene del sitio cruzado.

Un 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 la 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

La víctima inicia sesión en el sitio web de un banco con credenciales válidas y recibe un correo electrónico 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, crea la siguiente solicitud 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

1. Ordene la presencia del usuario mientras realiza acciones sensibles.
2. Implementar mecanismos como CAPTCHA, reautenticación y tokens de solicitud únicos.

Configuración incorrecta de seguridad

Descripciones

Se debe definir e implementar una configuración de seguridad para la aplicación, los marcos, el servidor de aplicaciones, el servidor web, el servidor de bases de datos y la plataforma. Si se configuran correctamente, un atacante puede tener acceso no autorizado a datos o funciones confidenciales.

A veces, tales fallas resultan en un compromiso completo del sistema. Mantener el software actualizado también es una buena seguridad.

Implicación

• Al hacer uso de esta vulnerabilidad, el atacante puede enumerar la tecnología subyacente y la información de la versión del servidor de aplicaciones, 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

1. La consola de administración del servidor de aplicaciones se instala automáticamente y no se elimina. Las cuentas predeterminadas no se modifican. El atacante puede iniciar sesión con contraseñas predeterminadas y obtener acceso no autorizado.
2. El listado de directorios no está deshabilitado en su servidor. El atacante descubre y puede simplemente enumerar directorios para encontrar cualquier archivo.

Recomendaciones

1. Una arquitectura de aplicación sólida que proporciona una buena separación y seguridad entre los componentes.
2. Cambie los nombres de usuario y contraseñas predeterminados.
3. Deshabilite los listados de directorios e implemente controles de control de acceso.

Almacenamiento criptográfico inseguro

Descripciones

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 del perfil, los detalles de salud, la información de la tarjeta de crédito, etc. se consideran 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 utilizar 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 y modificar datos débilmente protegidos para llevar a cabo robo de identidad, fraude con tarjetas de crédito u otros delitos.

Objetos vulnerables

• Base de datos de la aplicación.

Ejemplos

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 de forma bruta en poco tiempo, mientras que las contraseñas con sal tardarían miles de años.

(*Hashes sin sal: Salt es un dato aleatorio agregado a los datos originales. Salt se agrega a la contraseña antes del hash)

Recomendaciones

1. Asegúrese de utilizar algoritmos estándar sólidos y adecuados. No cree sus propios algoritmos criptográficos. Utilice únicamente algoritmos públicos aprobados, como AES, criptografía de clave pública RSA y SHA-256, etc.
2. Asegúrese de que las copias de seguridad externas estén cifradas, pero que las claves se administren y se realicen copias de seguridad por separado.

No restringir el acceso a la URL

Descripciones

Las aplicaciones web verifican los derechos de acceso a 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 privilegiadas. Un atacante puede acceder a páginas confidenciales, invocar funciones y ver información confidencial.

Implicación

• Al hacer uso de esta vulnerabilidad, el atacante puede obtener acceso a URL no autorizadas, sin iniciar sesión en la aplicación y explotar la vulnerabilidad. Un atacante puede acceder a páginas confidenciales, invocar funciones y ver información confidencial.

Objetos vulnerables:

• URL

Ejemplos

1. El atacante nota que la URL indica la función como "/usuario/getaccounts". Se modifica como “/admin/getaccounts”.
2. Un atacante puede agregar un rol a la URL.

http://www.vulnerablsite.com se puede modificar como http://www.vulnerablesite.com/admin

Recomendaciones

1. Implementar controles de acceso estrictos.
2. Las políticas de autenticación y autorización deben basarse en roles.
3. Restrinja el acceso a URL no deseadas.

Protección insuficiente de la capa de transporte

Descripciones

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, el uso de certificados vencidos o no válidos o no utilizar SSL pueden permitir que la comunicación quede expuesta a usuarios no confiables, lo que puede comprometer una aplicación web o robar información confidencial.

Implicación

• Al aprovechar esta vulnerabilidad de seguridad web, un atacante puede detectar las credenciales de los usuarios legítimos 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

1. Habilite HTTP seguro y aplique la transferencia de credenciales solo a través de HTTPS.
2. Asegúrese de que su certificado sea válido y no esté caducado.

Ejemplos:

1. En una aplicación que no utiliza SSL, un atacante simplemente monitoreará el tráfico de la red y observará una cookie de sesión de víctima autenticada. Un atacante puede robar esa galleta y realizar un ataque Man-in-the-Middle.

Redirecciones y reenvíos no validados

Descripciones

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 existe una validación adecuada al redirigir a otras páginas, los atacantes pueden hacer uso de esto y 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 contenga 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 explorarla y convertirse en víctima.

Ejemplos

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modificado a

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Recomendaciones

1. Simplemente evite utilizar redirecciones y reenvíos en la aplicación. Si se utiliza, no implique el uso de parámetros de usuario al calcular el destino.
2. Si los parámetros de destino no se pueden evitar, asegúrese de que el valor proporcionado sea válido y esté autorizado para el usuario.