Prazan $_SERVER['HTTP_REFERER']

[bluesman]

Problem: Sistem privatnih poruka. Na sajtu postoji formular, pisu poruku i kliknu na send. U scriptu koji cuva poruke u bazu stoji ovako nesto:

PHP kôd:

if (!eregi($_SERVER['HTTP_HOST'], $_SERVER['HTTP_REFERER']))
    die ("no spam"); 


To je da bih sprecio da se uloguju pa onda sa nekih drugih servera salju gomila poruka (desava se da neki posalju i po 800-900 poruka za par sati). To uglavnom rade oni nigerijci budale koji traze pare i spamuju.

Medjutim, naizgled jednostavno resenje ima problem. Nekim clanovima je referer prazan. Znaci $_SERVER['HTTP_REFERER'] == ""

Kako je to moguce? Razliciti su browseri u pitanju a korisnici su sve samo ne strucni da umeju da sakriju referer na neku foru.

[Milos Vukotic]

Mislim da je caka u firewall-ovima...

[Petar Marić]

U prevodu ti imaš probleme sa CSRF?

E sad davno je bilo kad sam se zanimao time u php-u. U osnovi šalješ jedan skriveni parametar kroz forme/url/sesiju/kolačić čija vrednost je validna samo za taj zahtev.

Da koristiš django, mogao bih ti preporučiti CsrfMiddleware - simple Cross Site Request Forgery protection

[srdjevic]

Meni se desilo da sam kod drugara naleteo na njegov FireFox koji je slucajno podesen da salje $_SERVER['HTTP_REFERER'] = 'HTTP_REFERER';
pa mi neke redirekcije nisu radile... :-(

Znaci, ima i takvih slucajeva.

[bluesman]

Petre, hvala za link, medjutim to je definicija problema a ne rešenje

Što se tiče skrivenih parametara, ne znam kako si to mislio, da stavim neki "hidden"? To i nije zaštita, a $_SESSION, i $_COOKIE ostaje jer je on ulogovan. Kapiraš šta rade? Dođu na sajt i samo se uloguju. A onda sa svog servera šalju post zahteve na script koji šalje poruke i pošto su ulogovani ovamo, stoji im lepo i SESSION i COOKIE, tako da prođe bez problema. A to se iz javascripta relativno lako uradi... samo napraviš da fura neki array sa id-jevima članova i na load, šalje sledeći... nije neka nauka

[Ilija Studen]

Prosta CAPTCHA? Znam da smara korisnike, ali ako im jasno naglasiš da je to tu da bi zaštiti njih od spam poruka mislim da će razumeti. 3 cifre je sasvim dovoljno u tvom slučaju IMO.

Što se referera tiče može da se blokira slanje istog jako lako. Čak većina alternativnih browser, pogotovo IE ljuski ima ugrađen "paranoid" mod (ime mu govori sve ). I sam znaš kakvi su obični korisnici... Pročitaju u Mikru kojekakve priče i onda od mrava prave slonove

PS: Za one koji ne znaju šta je CAPTCHA.

[dinke]

Mozes i sam da generises referer i da ga ubacis u promenljivu sesije.

Recimo na prvoj strani nesto tipa:

PHP kôd:

$_SESSION['referer'] = $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; 


A na sledecoj:

PHP kôd:

if (!eregi($_SERVER['HTTP_HOST'], $_SESSION['referer']))
... 


Bitno je samo da prvo proveris referer a tek setujes nov u sesiji ili kukiju.

Inace, ja bi umesto captche generisao neki hash baziran na username/pass kompbinaciji i ubacio ga u sesiju, a istu proverio na sledecoj strani. Na primer na strani sa koje si zeleo da uzmes referer:

PHP kôd:

$_SESSION['hash'] = md5($_SESSION['username'].$_SESSION['pass']); 


a na sledecoj:

PHP kôd:

if($_SESSION['hash'] == md5($_SESSION['username'].$_SESSION['pass']))
... 


Naravno, mozes staviti bilo sta, ne mora username / pass.

[Petar Marić]

@bluesman: Nešto si rek'o

Sadržaj preuzet sa već pomenute stranice
Preventing CSRF

1. Make sure that the cgi that handles form submissions for forms that change server state only accepts POST parameters, not GET parameters. Some server-side languages default to accepting both.
2. Make sure form submissions use your own forms by including a hidden field that is an MD5 hash of the login cookie and a secret on the server. Then only accept the form if the hidden field is correct.
3. Optional added paranoia: Add a timestamp as a hidden field and include it in the hash. Make the form expire if the timestamp is too old. Give users a way to submit the form again when the form expires, such as by returning the form pre-filled with the data they entered last time but with a fresh hash.

Do not rely on the Referer header to protect your visitors from CSRF. (Browser bugs and features allow web sites to create referrerless links, so you would have to reject referrerless form submissions. Some users choose to turn off referers, so you can't protect these users without preventing them from accessing your site at all. Some users even spoof their referer so it always appears to come from the site they are requesting a page from, making them impossible to protect in this way. Users that spoof referrers usually do so in order to access porn sites that restrict access to content solely based on referers.)
Since so few sites protect their visitors against CSRF attacks, we have discussed possible client-side fixes for CSRF. We didn't come up with anything good. For reference, see bug 38933, bug 40132, bug 246476, and bug 246519. At most, browsers might be able to prevent CSRFs from web sites to intranet sites, but not between web sites.

Naravno dodatak CAPTCHA-e samo ulepšava rešenje, mada ti preporučujem da dodaš i proveru minimalnog intervala između slanja 2 poruke.

Edit: Čisto da napomenem, ako neki nisu do sada shvatili: Za svaku formu koja menja stanje (aka state) na serveru se koristi dotična kombinacija - naravno tajni ključevi se menjaju za svaki novi zahtev.

[noviKorisnik]

Ne razumem jedno - želiš da sprečiš postovanje s drugog sajta - ok - a kako izlaziš na kraj ako dođe na tvoj sajt i odatle odradi malo spamovanje od 700 PP?

[bluesman]

Pa to mu se ne isplati Mnogo dugo traje, oni ne rade to tako.