XSS i CSRF napadi su opasni i manje-više jedina efektivna zaštita od njih je blokirati ih na razini web stranice. Kao krajnji korisnik, moguće je blokirati izvršavanje skripti u korisnički-generiranim poljima i sličnom, ali, budimo iskreni, koliko će ljudi to ići raditi?
Za ljude koji nisu upućeni u to što su XSS i CSRF napadi, napisat ću ukratko objašnjenje.
XSS (cross-side scripting):
Ako neka forma nije filtrirana dobro i prikazuje svoj unos na ekranu, u tu formu netko može unijeti kod, recimo:
Ovo bi ispisalo
mojtekst, ali bi i boldalo ostatak stranice jer nema zatvarajući </b>. "Pa šta sad, netko može boldati tekst?!" Tu ima par problema koje čine XSS opasnijim od toga.
Problem 1: Stranica pohranjuje unos i ponovno ga prikazuje
Poput foruma, komentara na blogu, društvene mreže, nečega takvoga. To znači da svaki puta kada netko pristupi stranici koja prikazuje taj unos, taj kod kojeg je napadač uneo se ponovno izvršava. "Pa šta sad, netko može boldati stranice?!"
Problem 2: Javascript
HTML i web preglednici općenito imaju implementiran programski jezik Javascript koji omogućava da se HTML stranicom upravlja i izmjenjuje njen sadržaj poslije učitavanja. I svi skoro koriste Javascript. Google koristi JS. Gmail, Duckduckgo, ovaj forum (!), sve je puno Javascripta.
No problem kod XSS-a nastaje kad unos nije filtriran, ponovno se prikazuje i u njemu se nalazi Javascript. Tu napadač može raditi *jako* puno toga - Javascript je pravi programski jezik.
*
Tweetdeck, jedan veliki Twitter klijent namijenjen profesionalnim korisnicima i community managerima (kojeg je Twitter svojevremeno kupio) je nedavno imao ovaj problem gdje se dogodio... "self-retweeting tweet" - tweet koji sam sebe retweeta (ili ako ne znate što je Twitter, kao da je to na Facebooku status koji sam sebe podijeli).
Tweetdeck je koristio jQuery pomoću kojega je izrazito lako napraviti takvo što i autoru je stalo to u tih 140 znakova (čak mu je ostalo mjesta pa je stavio
). Zaobilazi sva upozorenja. Ne znate da se to dogodilo. Samo vam se iz ničeg pojavi obavijest 'XSS in Tweetdeck'.
Ovo je kod tog exploita:
Kod: Označi sve
<script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script>♥
WebKit (u mom slučaju Safari) recimo ima donekle (iako lošu) zaštitu od XSS-a pa ako nađe kod kojeg stranica pokušava izvršit, a nalazi se u requestu, on to odbije:
Kod: Označi sve
The XSS Auditor refused to execute a script in 'http://dev.pulsir.eu/iweb/sec/xss.php' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.
xss.php:21
Napravio sam primjer stranice koja je ranjiva na XSS pa se možete poigrati:
http://dev.pulsir.eu/iweb/sec/xss.php
Najjednostavnije (iako ne baš pretjerano učinkovito) rješenje za filtriranje XSS-a u PHP-u je
Kod: Označi sve
str_replace("<", "<", $nefiltrirana_varijabla);
ali bolje je nego ništa. Ako nekome treba, tu ima malo bolji XSS filter:
https://gist.github.com/mbijon/1098477
CSRF (cross-side request forgery):
CSRF je izrazito opasan i izrazito jednostavan napad na stranicu.
Kopirajte neku formu. Bilo koju. Ako stranica nije dobro zaštićena, ta forma će se poslati s druge stranice bez problema. Ovo je izrazito čest problem i opasan.
Takve forme se koriste za promjenu lozinki, brisanje računa, bankovne transakcije na internet bankarstvu. Većina bolje napravljenih stranica jesu zaštićene i imaju form tokene koji to sprječavaju, ali ako neka stranica nije, to je jako loše
Problem je što netko može onda poslati formu u vaše ime, bez da znate da je to forma, koja briše vaš račun ili radi nešto opasno, a da su sva polja skrivena i gumb za slanje zamaskiran kao link.
Evo demonstracija:
http://dev.pulsir.eu/iweb/sec/csrf.php
Način za zaštitu od ovoga je generacija tokena za specifičnu sesiju nekog usera koji se pohranjuju u bazi i moraju odgovarati onome navedenome u formi kod njene generacije. Ovo je izvrstan izvor o zaštiti od CSRF napada:
https://www.owasp.org/index.php/Cross-S ... heat_Sheet
Također, jedan veliki problem kod web appova koji koriste bazu je
SQL injection.
SQL injection je problem kad netko napiše SQL naredbu u input koji direktno ide u bazu.
Ako taj input nije filtriran, mogu unijeti ovo kao ime i obrisati tablicu users:
(ovo vjerojatno ne bi radilo jer skoro sigurno nije ispravan SQL , samo za svrhe demonstracije)
U PHP-u se protiv toga može lako obraniti s
(odnosno
ako koristite mysql set funkcija, što ne bi trebali).
izvor:
xkcd #327 - Exploits of a mom
U svakom slučaju, sve ove gore navedene napade može spriječiti samo osoba s pristupom sourceu web aplikacije, a najbolje što netko kao krajnji korisnik može učiniti je prestati koristiti tu aplikaciju dok se taj sigurnosni bug ne ispravi.
Ne znam zašto nismo već prije otvorili nešto slično. 
Jel ok?
