Cum la spre hack unsecure web application

în acest articol aș dori să demonstreze cât de ușor este de a obține informații confidențiale de la o aplicație web care… Ei bine, nu acordă prea multă atenție securității. Cu ce voi lucra este o aplicație Java de probă pe care am creat-o în Spring Boot în scopuri demonstrative. Dar atacurile efectuate sunt valabile pentru orice alt limbaj de programare sau cadru. Unele vulnerabilități și probleme de securitate care vor fi demonstrate includ:

• SQL Injection
• expunerea datelor sensibile
• logare insuficientă
• autentificare rupt

setup

vom lucra cu o aplicație Web fictiv, care vă permite să vă conectați ca utilizator, care este o parte a unui grup. Pe baza rolului utilizatorului, el poate vizualiza date de bază sau confidențiale. În acest caz, veți vedea o listă a angajaților dintr-o companie, statutul acestora etc.

puteți găsi sursele pentru această aplicație în Github meu: https://github.com/rapasoft/hackme.

atac #1: Omul din mijloc atac

Imaginați-vă că stați într-un restaurant și doriți să verificați ceva în aplicația de mai sus. Vă conectați la Wi-Fi-ul restaurantului, deschideți pagina de conectare, introduceți acreditările și obțineți informațiile dorite (de exemplu, lista angajaților specifici). Ceea ce s-ar putea să nu acum, este că acreditările au fost compromise. Să examinăm îndeaproape pagina de conectare:

această aplicație nu utilizează SSL/TLS (de exemplu, nu https:// conexiune). Aceasta înseamnă că orice informație trimisă poate fi privită ca text simplu de către oricine are acces la comunicarea dintre client și server.

aceasta este exact ceea ce se întâmplă în așa-numitul atac om din mijloc. Mai precis, în acest caz, spoofing-ul ARP a fost folosit ca o modalitate de a otrăvi întreaga rețea, astfel încât atacatorul să fie conștient de orice se întâmplă și să poată mirosi pe toate pachetele. Nu voi intra în detalii despre modul în care funcționează spoofingul ARP, dar îl voi demonstra în acest videoclip:

s-ar putea să fie nevoie să deschideți acest videoclip Youtube într-o fereastră nouă și pe ecran complet pentru a vedea mai multe detalii

ceea ce puteți vedea mai sus este că am început Ettercap, care este o suită cuprinzătoare pentru atacurile MITM și am efectuat spoofing ARP în rețeaua mea locală. Între timp, când utilizatorul (me prin iPad) introduce acreditările, acestea sunt vizibile atât în Ettercap, cât și în Wireshark (instrument pentru analiza traficului de rețea).

atac #2: SQL Injection

continuând rolul nostru ca atacator al acestei aplicații, Avem acum acreditările pentru utilizator hgravescu parola P4SSW0RD. Puteți vedea că nu numai această aplicație nu utilizează TLS, are o politică de parolă foarte slabă care permite utilizatorilor să aleagă parole cu adevărat îngrozitoare.

ne conectăm folosind acreditările de mai sus și putem vedea un câmp de introducere cu opțiunea de a căuta lista de persoane. Când apăsați Search vom primi lista completă de persoane. Dacă punem „Fra”, de exemplu, vom obține rezultate filtrate pe baza căutării. Ce se întâmplă dacă am pus acolo un caracter ilegal? Este evident că există o bază de date în spatele acestei aplicații, așa că haideți să încercăm caracterul ' :

nu numai că a eșuat, dar putem vedea că POST cererea a eșuat cu un mesaj de eroare foarte specific care expune structura întregii instrucțiuni SQL. Putem vedea că WHERE P.NAME LIKE '%'%' este folosit la sfârșit.

hacker calificat nu are nevoie de mai mult. Ajustarea șirului de căutare poate, după câteva încercări, să producă aceste rezultate:

injecția în acest caz a creat union to select declarație care preia numele de utilizator și parolele împreună cu rolul lor. Nu numai că acest lucru a avut succes, am reușit să-l afișăm în aplicația client originală.

avem acum acreditările tuturor utilizatorilor și rolurile lor (afișate de întregul în coloana „vârstă”). Dacă hframe are rolul 1, rgraves trebuie, prin urmare, să fie utilizator mai important cu rolul 3.

atac #3: Atacarea parolelor slab hash

am învățat în primul atac, că probabil nu există nicio politică de parolă setată pentru această aplicație. Acest lucru ne-ar da speranța că rgraves nu acordă prea multă atenție nici securității.

cel mai simplu mod de a sparge hash-ul parolei care utilizează algoritmul de hashing insuficient (cum ar fi MD5 în acest caz) este de a efectua dicționar sau atac de masă curcubeu. Există multe posibilități, dar cea mai ușoară este utilizarea serviciilor de internet care au deja o bază de date mare de combinații de parole la hash:

primul este hframe, al doilea este rgraves. smorgan pare să folosească parole mai puternice decât altele, deoarece nu este în dicționar.

puteți vedea că parola pentru rgraves este pește-spadă, ceea ce înseamnă că acum nu cât de important este să alegeți parola non-dicționar ;). Acum, nimic nu ne oprește să ne conectăm ca acest utilizator și să descoperim secțiunea „admin” și informații confidențiale:

nu citiți acest lucru dacă sunteți German 🙂

Cum de a remedia acest lucru?

ați putea spune că toate acestea ar putea fi ușor prevenite. Ați putea spune că acestea au fost greșeli de începător. Ei bine, acest lucru ar putea fi adevărat, dar ceea ce este, de asemenea, adevărat este că proiectul Open Web Application Security listează injecția ca vulnerabilitate #1 în aplicațiile web (și a fost așa de câțiva ani).

deci, dacă v-ați întrebat cum să preveniți toate acestea, să recapitulăm:

• utilizați întotdeauna SSL / TLS atunci când trimiteți ceva la server. Nu trebuie să fie acreditări, în prezent este considerată o bună practică în general. Chiar dacă nu aveți deloc intrări pe pagina dvs.! Cel mai simplu mod este de a furniza certificat prin servicii precum Let ‘ s Encrypt.
• amintiți-vă că certificatele auto-semnate ar putea atenua problema expunerii la date, dar nu împiedică atacatorul MITM să falsifice întregul site cu propriul său certificat auto-semnat cu totul.
• atunci când se ocupă cu interogări SQL scăpa întotdeauna parametrii obținuți de la client. Cel mai simplu mod de a face acest lucru este utilizarea capabilităților cadrului dvs., de exemplu, în primăvară puteți utiliza NamedParameterJdbcTemplate, care este bun și pentru lizibilitate.
• fii paranoic. Validați orice intrare de utilizator. Din nou în Java / Spring world puteți adăuga reguli de validare folosind JSR-380 implementarea validării bean ca validator hibernare și adnota parametri, de exemplu, @Pattern(regexp = "*") String namear împiedica intrarea '.
• Log orice încercări de a trece în intrare nevalidă în cerere. Mai mult, în caz de eroare, Nu expuneți clientului nicio informație specifică implementării.
• îmbunătățiți autentificarea.
  • dacă este posibil, utilizați cel puțin autentificarea cu 2 factori.
  • nu implementați algoritmi personalizați de stocare a parolelor sau de criptare. Este extrem de dificil să faci singur și cu siguranță vei eșua. Există soluții dovedite precum BCrypt.
• citiți și bookmark OWASP Top 10. Începe cu acolo și apoi du-te prin lista lor de cele mai bune practici.