Hoja de respuestas

Módulo Desarrollo seguro

Nombre y
apellidos
← Fecha
18/04/2021
entrega

1. Identificar todas las vulnerabilidades que tiene la aplicación

(utilizando una herramienta semiautomática como Vega u OWASP
Zap).

Después de usar la herramienta Vega para realizar el escaneo, he conseguido

el siguiente listado de vulnerabilidades.

Ya nos
viene
clasificado por tipos de vulnerabilidades y nivel de riesgo.
Vemos 13 ocurrencias de alto riesgo, 126 de riesgo medio y 23 de riesgo bajo.
La página es vulnerable a XSS, inyecciones SQL y ni sus cookies ni la página es
segura al carecer de Flags y certificado SSL respectivamente.
También tiene errores de programación que en caso de dar un error muestra el
log entero dando información valiosa a los atacantes.

2. Explotar las vulnerabilidades, indicando cómo se ha explotado cada

vulnerabilidad y cuál ha sido el resultado (adjuntando pantallazos).
XSS reflejado:
Según el informe de Vega, el campo search es vulnerable a XSS, así que vamos
a hacer que ejecute un script sencillo para comprobar que es así

Al darle a ‘Search’ nos ejecuta el alert sin problemas.

Y al
cerrar el alert nos muestra el resultado de una búsqueda vacía

XSS DOM:
La caja de comentarios en la pestaña “Guestbook” es susceptible a ataques de
XSS guardando el script.

Hacemos submit y recargamos la página.

Inyecciones SQL:
Según el informe, el campo user del login es vulnerable a las inyecciones. He
creado una cuenta llamada Chengze con la contraseña hola para trabajar sobre
ella.
Al introducir el usuario con comilla doble no reacciona, entonces probamos con
una comilla simple.
El error mostrado corresponde a la prueba de la comilla doble mencionado.
Ahora al probar la comilla simple y darle al login, nos devuelve el siguiente
error.

Entonces vemos que usa sintaxis de MySQL y que podemos jugar con las
comillas simples.

Teniendo en cuenta que usa la línea mostrada arriba, vamos a intentar los
siguientes usuarios:
Chengze‘ -- (doble guión para comentar el resto de línea)
O
Chengze’ # (hashtag para comentar el resto de línea también)

Con la version de doble guión nos muestra este error.

Y con la version de
hashtag,

Nos loguea correctamente sin necesidad de contraeña.

Mala gestión de cookies y contraseñas por defecto:

A las cookies creadas no se le han puesto los siguientes flags a true, HttpOnly y
Secure. Esto hace que cualquier atacante que consiga la cookie tenga acceso
con los privilegios de dicha cookie y realizar ataques con ello.
Es muy sencillo de conseguir la cookie en uso, y unido a una serie de
contraseñas por defecto que no se han cambiado se puede conseguir la cookie
de sesión de un administrador sin problemas. El usuario y contraseña usadas
ha sido “admin” y “admin”.
Inyección por línea de comandos:

Al usar la función del passcheck, la respuesta que nos devuelve nos muestra la
ruta absoluta de la aplicación.
Además nos pone exactamenter que usa el comando grep y la sintaxis usada,
esto puede ser explotable si el atacante inserta líneas de comandos en la
contraseña.

Usamos la comilla ` para indicar que se trata de un comando, con el comando

ls hacemos que nos liste los elementos del directorio actual y lo pasamos al
archivo ubicado en upload/test y si nos vamos a ese directorio podemos ver el
contenido.
Local file inclusion

Cuando accedemos al sitio de admin con las credenciales por defecto y

hacemos click en “Create a new user”

Nos muestra este error, que no existe el create.php dándonos a entender que
la web es vulnerable al LFI.

Para explotar esta vulnerabilidad basta con cambiar la palabra “create” por la
ruta deseada. Vamos a ejecutar el error.php que está en la carpeta padre del
directorio en el que estaba.
3. Proponer, al menos, una medida de prevención para cada
vulnerabilidad analizada (se entiende como medidas de prevención las
modificaciones en el código donde se encuentra el problema).
Asimismo, se podrán indicar medidas adicionales sobre buenas
prácticas de seguridad relativas a la tipología de la vulnerabilidad.

Las capturas de pantalla han sido hechas del código fuente de

WackoPicko

Inyecciones SQL: Se debe a que los datos introducidos y enviados no han

sido limpiados de caracteres especiales.

Ese $username debería estar como la pass, con mysql_real_escape_string para,

que es una función de PHP para escapar ciertos caracteres poniendo barras
invertidas, haciendo que las comillas por ejemplo se conviertan en parte del
string.

XSS: En el ejercicio hemos guardado un script sin ninguna clase de problema.

Habría dos maneras de solucionarlo, la primera es hacer una comprobación y
limpieza de caracteres especiales de HTML como “<>” antes de meter los
comentarios a la base de datos como en el caso de las inyecciones SQL o
aplicar esa limpieza al recoger los datos con un SELECT, antes de volcar los
datos la página web. por eso cualquier usuario que acceda a la pestaña
Guestbook ejecuta ese script.
Esta es la función que usa y podemos comprobar que vuelca los datos tal y
como los recoge.
Lo mismo pasa con el GET del XSS reflejado, y ejecuta el script a la hora de
buscar imágenes.

Mala gestión de cookies:

Según Vega, este problema se soluciona poniendo HttpsOnly y Secure Flag a
true.

Información de rutas:
Hay varios sitios donde se muestran las rutas, el usuario no debería verlas. En
el ejercicio anterior aparece en un div la ejecución de código que se hace,
facilitando enormemente el ataque.

Credenciales por defecto:

Se deberían eliminar las credenciales por defecto, el clásico “admin-admin” o
“user-user” no deberían ser opciones.

Inyección por línea de comandos:

Como en los casos de inyección SQL y XSS, los input deberían ser comprobados
y limpiados antes de hacer algo con ellos del lado del servidor. En este caso
habría que escapar los caracteres usados en la línea de comandos como “|” o
“--”