Problēma ar formas token vērtību

[ArnisR]

Tātad PHP ģenerē token vērtību:

<?php
session_start();
$token = $_SESSION["token"] = md5(uniqid(rand(), true));
?>

 

Un ir HTML forma ar token lauku:

<form action="process.php" method="post">

<input type="text" name="username"/>
<input type="password" name="password"/>


<input type="hidden" name="token" value="<?php echo $token; ?>"/>

<input type="submit" name="submit" value="Sign In!"/>
</form>

 

Apstrādes failā tiek salīdzinātas $_POST un $_SESSION token'a vērtības, un attiecīgi viss parējais notiek! Bet ir viena problēma: ja formas lapu atver jaunā cilnē un refresho, neaizverot sākotnējo, vai arī apskatās source un refrešo, tad ielogošanās no sākotnējās lapas nesanāk, jo sesijas token's jau ir mainījis savu vērtību, bet forma - ne!

Kā to var apiet, vai ir kāda cita metode token'u izmantošānā? Paldies!

Edited July 1, 2012 by ArnisR

[daGrevis]

Tāda ir tokena doma. Palasi kas ir CSRF.

[codez]

Uztaisi formas tokenu, kas piesaistīts ip adresei, nevis randomā, tad tas nemainīsies tabos.

[spainis]

hash's no urļa, kas apstrādās pieprasījumu + sesijas id + vēl kādu server side secret'u, katram lietotājam katrai darbībai būs unikāls tokens

Edited July 1, 2012 by spainis

[draugz]

Es savulaik mēģināju uztaisīt captcha un saskāros ar to pašu problēmu.

Beigās es uztaisīju, ka sesijā ir masīvs ar 10 pēdējiem captcha kodiem, līdz ar to pat ja ir atvērts paralēls tabs vai skatīts source, tad $_POST vērtība tiek pārbaudīta in_array($_POST['captcha'], $_SESSION['captcha'])

[codez]

Kādas problēmas kapčai sūtīt līdzi tokenu, kurš ģenerēts no kapčas?

 

$token=hash($capcha+$salt);

 

formai līdzi sūta $tokenu. Pie ievades pārbauda, vai no ievadītās kapčas var iegūt tokenu. Saprotams, ka zinot tokenu iegūt kapču nav iespējams, ja lieto modernu hash algoritmu.

[F3llony]

Uztaisi formas tokenu, kas piesaistīts ip adresei, nevis randomā, tad tas nemainīsies tabos.

 

W00t risinājums, īpaši lielu paldies tev pateiks gov aģentūras un kompānijas ar X lietotājiem aiz vienas adreses + ISP'i, kur X klientiem ir viena IP. :>

 

hash's no urļa, kas apstrādās pieprasījumu + sesijas id + vēl kādu server side secret'u, katram lietotājam katrai darbībai būs unikāls tokens

 

Jau labāk.

 

Kādas problēmas kapčai sūtīt līdzi tokenu, kurš ģenerēts no kapčas?

 

$token=hash($capcha+$salt);

 

formai līdzi sūta $tokenu. Pie ievades pārbauda, vai no ievadītās kapčas var iegūt tokenu. Saprotams, ka zinot tokenu iegūt kapču nav iespējams, ja lieto modernu hash algoritmu.

 

Good, You can now take a cookie from the Jar.

 

 

Kāds, ja interesē, varētu paņemt https://github.com/Addvilz/x0Cache/blob/master/x0cache/session.php kā pamatu un palabot, lai iegūtu tokenus formām. Double the gun, double the fun.

[codez]

W00t risinājums, īpaši lielu paldies tev pateiks gov aģentūras un kompānijas ar X lietotājiem aiz vienas adreses + ISP'i, kur X klientiem ir viena IP. :>

 

Jā kā tad, viens aģentūras galdiņa urbējs taisīs xsrf uzbrukumu tieši kādam no tās pašas aģentūras - tas ir statistiski mazvarbūtīgi, tad jau vieglāk ieiet kabinetā un palaist trojāni.

[F3llony]

 

Jā kā tad, viens aģentūras galdiņa urbējs taisīs xsrf uzbrukumu tieši kādam no tās pašas aģentūras - tas ir statistiski mazvarbūtīgi, tad jau vieglāk ieiet kabinetā un palaist trojāni.

Vieglāk ir "palūgt" galdiņa urbējam visas paroles ar cirvi, ja jau sākam par šo runāt.

 

Nav jau gluži runa par to, kas un no kurienes. Runa ir par to, ka IP bindošana ļauj uzbrukumus pret masām, ne pret katru atsevišķo jūzeri. Un tas ir validi ne tikai xsrf

[Aleksejs]

IP piesaiste pilnīgi noteikti samazina to indivīdu kopu, kam ļauts izmantot konkrētās funkcionalitātes konkrētajā gadījumā. Problēma šeit nav faktā, ka daudzi lietotāji nāk no vienas adreses, bet gan tajā, ka eksistē lietotāji, kam sesijas laikā vairākkārt mainās IP adrese.