ugrás a tartalomhoz

image verification kód probléma

TIV · 2006. Szep. 30. (Szo), 22.23
üdv

szeretnék a hírlevelemhez image verificationt, szereztem egy példakódot.:
	<? Header("Content-Type: image/png"); 
		session_start(); 
		$new_string; 
		session_register('new_string'); 

		$im = ImageCreate(43, 16);  
		$white = ImageColorAllocate($im, 0, 0, 0); 
		$black = ImageColorAllocate($im, 255, 255, 255); 
		srand((double)microtime()*1000000);  
		$string = md5(rand(0,9999));  
		$new_string = substr($string, 15, 5); 
		ImageFill($im, 0, 0, $black); 
		ImageString($im, 4, 2, 0, $new_string, $white); 
		ImagePNG($im, "verify.png"); 
		ImageDestroy($im);
		print "<img src=\"verify.png\">?>
és ami ellenőrzi:
<? session_start();
$random = trim($random);
if ($new_string == $random){
echo "You are verified";
}
else{
echo "Please go back and get verified.";
}?>
1. véleményem szerint, ez nem működik..volt egy olyan problémám is, hogy hiába dobta vissza az ellenőrző program az előző oldalra a böngészőt, az új kód elkészült, de a kép még mindig az előzőleg generált volt, amit rosszul írt be a felhasználó, szóval azt nem frissítette az IE (ami nem böngésző ugye:D).

2. nem csupán ehhez a kódhoz kérek segítséget, ha ez nem jó, akkor kérem magyarázza el valaki hogy miként kellene ilyet csinálni, mert sok tapasztalatom még nincs session és kép generálással kapcsolatban...+ akarok majd bele csíkokat is rakni, h ocr ne tudja olyan könnyen olvasni....

3. az oldalamat opera, mozilla kompatibilisre szerettem volna, de a fenti kódot tartalmazó php fájlt mikor includeolni szerettem volna az OPERA 9 nagyon ellenkezett és nem értem miért...:( miként lehetne kompatibilis oldalt gyártani?

előre is köszönöm!
‹ Menü kezelés php-ben Megjelenítés webcím paraméter alapján adatbázisból ›
 ■
1

ellenkezett?

Anonymous · 2006. Okt. 1. (V), 01.11
Hello!

Mit értesz az alatt, hogy az opera ellenkezett?

A kód hibája miatt legfeljebb a php vagy a webszerver
panaszkodhat.

Egyébként szerintem sem működhet, bár a kép készítéshez nem értek, azért
feltűnő, hogy az első kód elindítja a session-t, de nem tárol el benne
semmit vagyis a new_string-nek nem ad értéket, az ellenőrző kód meg nem is
olvas ki semmit a session-ből.
3

De igen

csla · 2006. Okt. 1. (V), 10.34
Tárol és olvas az, csak helytelenül van lekódolva. A kód arra épít, hogy be van kapcsolva a register_globals.
4

hát ez az

TIV · 2006. Okt. 1. (V), 16.42
köszi a választ!

igen, ez a röhej, rossz php kód miatt php ugathat meg a webszerver...nézd meg az első idézet kódrészletem, semmi dizájn nincs benne csak tömény php és az opera csupán a képernyő közepén egy képet helyét mutatja, mintha hiányozna a kép. érdekes, IE alatt megy...

miért van ez?

köszi köszi
2

cform-ban

toxin · 2006. Okt. 1. (V), 08.52
nézd meg példában, ill. a kódban (nincs beleágyazva a crossForm-mba külön adtam hozzá)

http://weblabor.hu/forumok/temak/14445#comment-33526

így vasárnap reggel, mostennyi helpre fussa :)

üdv t
5

egy kis önreklám :D

amonrpg · 2006. Okt. 1. (V), 22.37
Helló!

Egy kis önreklám, ha nem baj.

A http://www.theba.hu/projects.html oldalon találsz egy SecureText modult. Van benne howto is. Tesztelt, működik, sok lehetőséggel.

Amúgy az eredeti kódodban (lehet rosszul mérek fel vmit), a header png után miért írsz ki html kódot (img src) ?
6

Asszem azért mert

krey · 2006. Okt. 1. (V), 22.46
Ismeretlen okokból fájlba menti a képet, és aztán beágyazza, ahelyett, hogy a PHP kód képet output-olna. Ennek akkor van csak értelme, ha egy script-ben szeretnénk a html-t generálni és a képet is. A (felesleges) fájl írás miatt csökken a teljesítmény is persze...

üdv. krey
7

hjam

amonrpg · 2006. Okt. 1. (V), 23.06
Igen, ezt én is látom, de ettől még a kliens felé header('Content-Type: image/png'); megy ki, ami nem jó, mert html-t tesz ki...
8

elméleti fejtegetés, kóddal karöltve

Marcell · 2006. Okt. 2. (H), 13.06
Hát nem tudom, hol sikerült ezt a kódot beszerezned, de több sebből vérzik. Lássuk hogyan is működne ez az elméletben, pszeudo kóddal.

Először a küldő oldalt (kuldo.php):
- generálsz egy véletlenszerű szöveget, amit eltárolsz SESSION-ben vagy beleírsz adatbázisba, ízléstől függően,
- generálsz egy képet, amibe ezt a szöveget iratod bele,
- majd alá raksz egy űrlapot a megfelelő INPUT mezővel.

Most a fogadó rész jön (fogado.php):
- megnézed egyezik-e a POST-al küldött adat az előzőleg SESSION-ben/adatbázisban letárolt értékkel,
- ha igen örülsz, ha nem visszaküldöd az előző részhez egy kis fejmosással.

A register_globals-t egy magára valamit is adó szervernél nem találod bekapcsolva, tehát ez a kód hosszú távon teljességgel használhatatlan. Gondolom vmi ingyenes gyűjteményben volt benne, és mint tudjuk olcsó húsnak híg a leve.

Kicsit kipucoltam a kódot, meg csoportosítottam logikailag. Érdemes lenne rögtön ezt nyújtani felénk, hogy könnyebben találjunk hibákat. Jöjjön most a gyakorlati rész, nem írtam újat, csak átalakítottam ezt.

kuldo.php:
<?php

session_start(); 

// szöveg létrehozása
srand((double)microtime()*1000000);  
$string = md5(rand(0,9999));  
$new_string = substr($string, 15, 5); 

// letárolás
$_SESSION['code'] = $new_string;

// kép létrehozása
$im = ImageCreate(43, 16);  
$white = ImageColorAllocate($im, 0, 0, 0); 
$black = ImageColorAllocate($im, 255, 255, 255); 
ImageFill($im, 0, 0, $black); 
ImageString($im, 4, 2, 0, $new_string, $white); 

// kép mentése
ImagePNG($im, 'verify.png'); 
ImageDestroy($im);

?>
<img src="verify.png" alt="itt a kód" />

<form action="verify.php" method="post">
   <input type="text" name="new_string" />
   <input type="submit" value="küldés" />
</form>

<?php

session_start();

// eltárolt változó kinyerése
$random = trim($_SESSION['code']);

// 2 érték összehasonlítása (feltéve hogy űrlapon elküldték)
if (isset($_POST['new_string']) && $_POST['new_string'] == $random){
   print 'Jó vagy vazze!';
}
else {
   print 'Nem jött össze!';

   // retorziók

}

?>
Zárszóként pár megjegyzés:
- mint már mondották, nem érdemes elmentegetni a PNG-ket. Ha 2 különböző kérés érkezik egyszerre, akkor mit csinálsz egy képpel?
- ha nem PNG kimenetet adsz, nem érdemes olyan fejlécet használni,
- a kódban vannak felesleges függvényhívások, amiket egyszerűbben is meg lehet oldani,
- hülyék a változónevek; van $string meg $new_string is. Minek? Legyen egyértelmű az elnevezés.

Akarok majd bele csíkokat is rakni, h ocr ne tudja olyan könnyen olvasni....
Hogy akarsz, ha a képgeneráláshoz sem értesz?
9

hááát

krey · 2006. Okt. 2. (H), 13.48
Nekem nem igazán tetszik az az elképzelés, hogy session-be tesszük az ellenőrző kódot. Megnéztem a linux.hu-t, ahol tudom, hogy ilyen a login, és ott úgy működik, hogy van egy gfx.php, ami jpeg-et generál.
A gfx.php-nek kell adni egy random_num paramétert is, ami alapján kiszámol egy másik számot, amit kiír.
Ha ezt a kódolt számot beírod, submit, post, akkor ő visszakódolja és ha nem vagy gép (vagy béna), akkor beenged! (A randomszámot pedig hidden inputból kapja meg)

üdv. krey

ps. Most jöttem rá, hogy a linux.hu-s megoldás sem sokkal biztonságosabb :(
10

miért nem bízol a session-ben?

tiku I tikaszvince · 2006. Okt. 2. (H), 14.25
Komolyan nem értem azokat, akik ennyire nem bíznak a php munkamenet kezelésében. Persze én is körültekintően használom, és csak azt teszem oda amit mindenképpen szükséges megőrizni.

Ha jól értem, szeretnél két lapletöltés között információt (egy ellenőrző kódot) tárolni a felhasználódról. Szerintem erre találták ki a munamenet kezelést.

Ha annyira parázol attól, hogy valaki újra felhasználja ugyanazt a kódot, akkor még mindig több lehetőséged van. Szerintem egy jó módszer lehet, hogy a munkamenet indításakor tárolod az aktuális időpontot, a session-t kezelő kódodban pedig definiálsz két idő intervallumot.
Ha még nem érted el az első időpontot, akkor nem teszel semit. Ha a két meghatásozott időpont között jársz, akkor veszel minden eddigi adatot amit eltároltál, törlöd az eddigi munkamenetet, létrehozol egy újat és berakod a régi adatokat (esetleg még egy takarítást is végre lehet hajtani). Ha már a második időpont is elmúlt akkor pedig jöhet a drasztikusabb szankció (kiléptetés, ellenőrző kód érvénytelenítése, stb.).

Ha pedig magának a munkamenetek tárolásával nem vagy megelégedve, akkor uccu, megvan a lehetőség a cserére. Bevethető az adatbázis a munkamenetek tárolására, elvetemültebb esetben teljesen másik adatbázis, ha túl paranoiás szeretnék lenni még az adatbáziskezelőből is választhatsz teljesen másikat.

tikuVoltam
11

nos igen

Anonymous · 2006. Okt. 2. (H), 15.07
Igen, komoly probléma az, hogy mindenképpen olyan módszert kell választani, amelynek a kiszámolása kliens oldalról szinte lehetetlen.
Ez csak úgy lehetséges, hogy random cuccot használsz.
Viszont ebben az esetben tárolnod kell a számot vhol.
Kliens oldalra kiküldeni ugye nem lehet. Így marad: file, db, session. (Néha ez ugyanaz :D)

A fent belinkelt SecureText csomagban is van lehetőség választani ezek között. Sőt, beállíthatsz magadnak callback fgv-t, amelyekben te magad intézed a kód tárolását és visszaolvasását. Ami még van, az egy idő alapú, peruser random biztonsági kód generálása, amely nem tökéletes (beállított időszakonként kapod ugyanazt a sorozatot), ha éppen eltalálja a júzer a váltást, akkor sajna 2x kell próbálkoznia. Nagy hátrány. De van előnye is: nem kell letárolni a kódot sehol, tehát feleslegesen nem muszáj DB-hez nyúlni, stb.

Tiku:

Nem arról van szó, hogy nem bízik az ember a session-ben. Bár ez egészséges hozzáállás, ugyanis lehetséges ugye a session lopás. Ezt természetesen el kell kerülni. De ez akár egy cikk témája is lehetne.
Vannak esetek (pl. amikor már DB-ben tárolódik a session), nem biztos, hogy csak ezért DB-hez akar az ember nyúlni! Stb.
12

nos igen vol2.

amonrpg · 2006. Okt. 2. (H), 15.08
#11 : nos igen # 15.07

Ez meg én voltam, csak kiléptetett az oldal. :(
13

szegényes fantáziám

tiku I tikaszvince · 2006. Okt. 2. (H), 15.33
Lehet (sőt biztos), hogy szegényes a fantáziám, de
Kliens oldalra kiküldeni ugye nem lehet. Így marad: file, db, session
ergo megint ott vagyunk, ahol a part szakad.
Akkor kiegészítve a fentebb vázolt ötletemet: ne csak a véletlenszerűen generált x^n hosszú kódot generáld le, hanem 4-5 dolog alapján azonosíts be a felhasználót.
Pl.:
  • referer,
  • ip,
  • a böngésző néhány adata,
  • lerakhatsz még két random sütit,
  • JS-segítségével lekérdezheted néhány adatát, pl. MAC, felbontás, ablak mérete,
  • esetleg további adatok,
és ezek véletlenszerű kombinációi.
Mondjuk összeállítasz egy csokrot (10-20 darabot) ezekből az adatokból, és kliensenként véletlenszerűen kiválasztasz 4-et (legyen 3 amit szerveroldalról kideríthetsz, +1 amihez kell JS), plusz ott van ugye az ellenőrző kód. Ha egy nemstimmel elhajíthatod az egész munkamenetet, mert vagy ellopták, vagy böngészőt cserélt, rosszab esetben csak új IP-t kapot, de szerintem ez belefér...

Én nem azt mondom, hogy feltétel nélkül, vakon meg kellene bízni a gyári módszerben, de néha olvasok itt egy-két olyan véleményt és félelmet, amit egyáltalán nem érzek megalapozottnak. Pláne mikor ugyanaz a kérdező (jelenlévők kivételek :) + tisztelet a kivételnek), egy másik kérdésével a hozáértés teljes hiányáról tesz tanubizonyságot.
Ha meg valaki védelemre vágyik, ott van a https://.

tikuVoltam
14

biztos kell ez neki?

Marcell · 2006. Okt. 2. (H), 18.18
Egész eddig nem szóltam hozzá, de most hadd mondjak pár dolgot. Ha abból indulsz ki, hogy a kérdező nem igazán ért a PHP-hez, akkor azt is reálisnak tartom, hogy az oldal, ahova ez a megoldás kell, nem a NASA-é lesz. Ergó nem kell 10/10 biztonsági szintre felkészíteni és atomtámadás ellen is bevédeni, mert úgyse fordul elő és nem is létfontosságú.

Sokszor látom, hogy egy gyík szavazáshoz egyesek 500 soros kódot képesek írni (COOKIE, IP, MAC ellenőrzés stb stb), pedig egy kis fos oldalról van szó és persze még így is kijátszható, ha valaki ki akarja.

Sztem meg kell találni a működöképesség és a kód túlburjánzása (ami ugye egyenesen arányos a belefektetett idővel) közötti arany középutat. Ebben az esetben a SESSION sztem megfelelő megoldás.
15

igaz

krey · 2006. Okt. 2. (H), 18.37
Ebben az esetben a semmi lenne egy észszerű megoldás, megjegyzem, egy hírlevélről van szó. Jellemző, hogy gonosz spambot-ok feliratkoznak hírlevelekre, ozt olvasgatják otthon? :) Ha igen szóljatok please, mert lesz mit átírnom ;)

üdv. krey