SPAM-erek kerülgetik az ajánlatkérő formomat!
Sziasztok!
Tapasztaltam egy érdekes jelenséget, és már olvastam ezzel a témával kapcsolatbna itt a laboron.
Van a weboldalamon egy kapcsolatfelvételi űrlap. Jelenleg a beküldés AJAX-al történik és egy php file dolgozza fel az adatokat a háttérben.
Mostanság terveztem egy köszönő levélküldő rutin beiktatását, de észrevettem, hogy valakik rendszeresen próbálkoznak mindenféle elmebeteg e-mail címmel. Gondolom lefordultak a témáról, mert nem kaptak levelet a megadott címre.
Arra gondoltam, hogy ha beiktatom a köszönő levélküldő rutint, akkor a következő képen járok el:
1. Hozzáadok a formhoz egy 6 karakterből álló képformátumú kódot és egy szövegmezőt. A kód ugy jön léter, hogy a képkód src-je egy php file, ami random legyártja a kódot változóba, beírja sütibe, és ImageTTFText-el megcsinálja a képet, majd küld egy header("Content-type: image/jpg");-t.
2. A form elmegy AJAX-al, úgy hogy belekerül a form összes adata, a user által beírt kód, és sütiből a kód eredeti példánya.
3. Háttérben a php file feldolgozza az adatokat és ha a user által beírt kód nem egyezik a sütiben található eredeti kóddal akkor visszadobja a kérést!
Az a kérdésem, szerintetek ez így jó-e, illetve az eljárás közben biztonságban van a sütit, és a POST adatok (nem lehet manipulálni)?
Várom észrevételeiteket, és bocsi, kicsit hosszú lett!
s_volenszki
■ Tapasztaltam egy érdekes jelenséget, és már olvastam ezzel a témával kapcsolatbna itt a laboron.
Van a weboldalamon egy kapcsolatfelvételi űrlap. Jelenleg a beküldés AJAX-al történik és egy php file dolgozza fel az adatokat a háttérben.
Mostanság terveztem egy köszönő levélküldő rutin beiktatását, de észrevettem, hogy valakik rendszeresen próbálkoznak mindenféle elmebeteg e-mail címmel. Gondolom lefordultak a témáról, mert nem kaptak levelet a megadott címre.
Arra gondoltam, hogy ha beiktatom a köszönő levélküldő rutint, akkor a következő képen járok el:
1. Hozzáadok a formhoz egy 6 karakterből álló képformátumú kódot és egy szövegmezőt. A kód ugy jön léter, hogy a képkód src-je egy php file, ami random legyártja a kódot változóba, beírja sütibe, és ImageTTFText-el megcsinálja a képet, majd küld egy header("Content-type: image/jpg");-t.
2. A form elmegy AJAX-al, úgy hogy belekerül a form összes adata, a user által beírt kód, és sütiből a kód eredeti példánya.
3. Háttérben a php file feldolgozza az adatokat és ha a user által beírt kód nem egyezik a sütiben található eredeti kóddal akkor visszadobja a kérést!
Az a kérdésem, szerintetek ez így jó-e, illetve az eljárás közben biztonságban van a sütit, és a POST adatok (nem lehet manipulálni)?
Várom észrevételeiteket, és bocsi, kicsit hosszú lett!
s_volenszki
minek a süti?
Miért nem Session a cookie helyett? Azt biztosan nem lehet törni.
Vagy legalábbis nagyságrendekkel nehezebb.
Felesleges, kódold inkább le hidden mezőbe
Szerintem teljesen feleslegesen bonyolítanátok sütivel vagy sessionnel.
Sztem ...
egészen addig
Szerintem jobban jársz, ha ebben a módszerben nem bízol.
Amúgy az ilyen kipörgetés elleni védelem az is, amikor generált formot használ az ember, sessionben eltárolod, melyik mezőnek mi a neve, generálsz minden mezőhöz egy 32 karakteres hash-t (bármilyne módon, csak legyen egyedi), azt szolgálod ki, s amikor visszaküldi a formot, a sessionből visszakonvertálod a mezőket. Ember legyen a talpán az a bot, amelyik tudja, hogy merre, hány méter.... :D Persze ehhez kell a szintaktikai ellenőrzés, amit írtál.
De ez sem az igazzy megoldás. A legjobb, ha hangmintát kreálsz a securetextből, és azt íratod be a mezőbe. A hangfelismerő szoftverek még nem nagyon vannak felkészítve az ilyesmire, csak ez meg aránytalanul nagy terhelést ró a szerverre. De van ahol érdemes bepróbálkozni.
Mint írtam ...
securetext
Ha nem feltétlenül szeretnél molyolni a megvalósítással, itt egy osztály, amit én már megcsináltam, használd egészséggel, ha tetszik (MIT Licensze, azt csinálsz vele, amit jónak látsz :D)
http://www.theba.hu/files/securetext.zip
Kevés hozzá a help (konkrétan még nincs), de van komment, és szívesen segítek, ha kell. Amúgy meg sztem nagyjából egyértelmű. :p
a cookiet meg felejtsd el, két perc alatt összedobok neked egy delphi alkalmazást, ami nagyüzemben postol a site-odra, olvassa a sütijét, és irogatja vissza a biztonsági kódodat... :p
inkább session, persze a megfelelő biztonsági óvintézkedésekkel. :D
Kész osztály.
Köszönöm a nagyvonalú felajánlásodat. Mivel egy unalmas téli estén a véletlenszerű kódgenerálás, és a képpé alakítás már megtörtént, ezért a szíves segítségedet szeretném kérni, hogy megértsem mit is jelent az session megfelelő biztonsággal. Azt tudom mi a session és bírok vele, de hogyan az extra biztoság?
Mi a logikai felépítése a folyamatnak? Tovább bonyolítja a helyzetet, hogy a formot AJAX küldi a háttérben feldolgozásra, és nem tudom, hogy ott mit ér az elindított session? Viszont a file-ba írásos eljárás tökéletesen értehető (számomra)!
Előkészítés:
1. Kód generálás változóba.
2. Változó tartalmának kiírása képre.
3. Változó és időbélyeg beírása fiel-ba.
Ellenőrzés:
0. Javascript leellenőrzi a form beviteli mezőit.
1. AJAX elküldi a feldolgozó php-nek a teljes form tartalmát.
2. Feldolgozó kiolvassa a file-ból a kódot és a lejárat dátumát.
3. Összehasonlítja a kapott kódot és a kiolvasottat, az időbélyeg függvényében.
4. stb.
Hogyan lenne ez session-al?
Várom válaszod:
s_volenszki
ps.: A kódot tartalmazó file-t, ha a könyvtár amibe van, csak a tulajdonos számára írható és olvasható, akkor azt tudják bűvölni?
session egyszerűbb
Előkészítés:
- kódgen
- képgen
- $_SESSION['securetext']['time'] = time();
- $_SESSION['securetext']['code'] = $code;
Ellenőrzés:
mint fent, csak a session-ből
Amúgy meg izlés szerint. A session extrabiztonság valszeg' félreérthető volt, a lényeg annyi, hogy vigyázni kell, ne lophassanak sessiont. De igazából ez alap dolog, és csak lazán kapcsolódik a témához :)
A securetext tartalma:
kódgen, képgen, tárolás: session, file, callback-fgv-en keresztül, ellenőrzés, és egy rahedli beállítás a képhez és a kódgenhez.
Amúgy a képgennél figyelj, hogy ne lehessen könnyen OCR-ezni. :D
Én ellenőrzésre régebben az Abby Finereadert használtam (amíg volt legális hozzáférésem). Amit az 90%-ban felismer az már extra jó védelem, az átlag OCR progik közel sincsenek ilyen szinten.
Ez így tiszta!
Köszönöm szépen a segítséget!
s_volenszki
trükk
én azt a trükköt találtam ki, hogy teszek a formba egy olyan mezőt, amit szemmel nem látni (display:none;) és adok neki egy preferált nevet (pl. address2). Ha ezen a mezőn jön be adat, akkor egyértelműen spam.
Üdv.: Ricsi
már megint...
Ezen kívül a spammerek nem lusták, így nyugodtan belenéznek a forrásodba, és esetleg beleépítik az új verziójú bot-jukba az ilyesfajta "védelmet". Sokra nem megy vele az ember. Sajnos.
de mégis
R.
count $_POST -ot használom.
Én csak azt számolom POST tömb akkora-e mint az általam kért.
Tapasztalatom szerint is csak azt postolják amit 100%-ban felismernek.
Igaz manapság van olyan robot is ami, amit nem ismer azt kitölti mint email cím.
Azok megjönnek de megunják ha látják hogy másnak nem továbbit a form.
Ha áttudnak vinni vesszőt vagy pontos vesszőt az email cím mezőn, na azt szeretik.
Percenként annyit küldenek amennyit csak tudnak. :-(
(Persze a szolgáltatók is tudják hogy nem mindenki figyel erre, ezért átalakítják a mail függvényüket. Az enyémek sikerült is kiirtani minden vezérlőt a subject mezőből, és nem is tördelődik 70 karakterenként …)
rand
ui: Inkább törlöm a SPAM -et mint az felhasználóimat zaklatnám a kódok beírásával.