-
PHP
(
http://www.devprotalk.com/forumdisplay.php?f=9)
| bluesman |
09. 11. 2005. 02:40 |
Prazan $_SERVER['HTTP_REFERER']
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 |
09. 11. 2005. 08:47 |
Mislim da je caka u firewall-ovima...
|
| Petar Marić |
09. 11. 2005. 09:25 |
|
| srdjevic |
09. 11. 2005. 16:16 |
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 |
09. 11. 2005. 16:36 |
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 |
09. 11. 2005. 16:57 |
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 |
09. 11. 2005. 17:53 |
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ć |
09. 11. 2005. 19:52 |
@bluesman: Nešto si rek'o :p
Citat:
Sadržaj preuzet sa već pomenute stranice
Preventing CSRF
- 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.
- 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.
- 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 |
09. 11. 2005. 23:47 |
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 |
10. 11. 2005. 00:09 |
Pa to mu se ne isplati :) Mnogo dugo traje, oni ne rade to tako.
|
| Vreme je GMT +2. Trenutno vreme je 00:52. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
