user_authentication()

[ezis]

Atkal es.

 

Nu, tad moku savu autorizēšanās sistēmu. Bet, jo vairāk meklēju info par to, jo vairāk saduros ar nepārliecību savam skriptam :\

Vēlētos noskaidrot vai man ar šo pietiktu? Kas man tur lieks un ko vēl vajadzētu? Kā būtu labāk.. jo cik dzirdēju, tagad jebkurš var nostopēt sessijas datus utt.. (Bija Alekseja rakstiņš forumā, kkas tāds..) Tāpēc tagad jāsāk vairāk baidīties ^^

 

function user_authentication(){

       global $db;

     @session_start();

     $user_id = isset($_SESSION['uid']) ? $_SESSION['uid'] : false;
     $session_token = isset($_SESSION['stoken']) ? $_SESSION['stoken'] : false;
     $visitor_token = md5(getip() . $_SERVER['HTTP_USER_AGENT']);

     if(is_numeric($user_id) AND $session_token == $visitor_token){
       $uChData = $db->get_row(sprintf("SELECT ID, user_salt FROM " . DBP . "users WHERE ID = %d AND Ses_token = '%s'", si($user_id), si($session_token)));
       if(empty($uChData)){ //Session data belong to noone
         //Destroy useless token and user id
         unset($_SESSION['stoken']);
         unset($_SESSION['uid']);
         return false;
       }else{ //Proceed if we are authenticated 
         //Set authentication data
         $this->uid       = $uChData->ID;
         $this->user_salt = $uChData->user_salt;
         $this->loggedin  = true;
         //updates last seen time
         $this->update_last_seen_time();
         //Regenerate session ID to prevent session fixation attacks
         session_regenerate_id();
         return true;
       }
     }else{ return false; }
   }

 

http://shiflett.org/articles/session-hijacking šeit smēlos nedaudz informāciju, bet wtf? Es īsti nesaprotu par to pēdējo koda daļu, kāda jēga vienkārši sessijā uzģenerēt kkādu token? :O Ko pēc tam viņš ar viņu dara? Man token vairāk asociējas ar kko, kas identificē no lietotāja puses šajā gadījumā.. Kā būtu, ja katru reizi, kad lapa tiek atjaunota, tiktu izsniegts lietotājam jauns token cepumā? :?

Edited January 18, 2011 by ezis

[briedis]

Tokenus parasti izmanto, lai novērstu XSRF uzbrukumus, teiksim, tu ieliec lietotājam sesijā random id un to pašu id pievieno arī kaut kādai formai. Kad lietotājs nosūta formas datus, salīdzini, vai formas tokens sakrīt ar lietotājam piešķirto tokenu sesijā. Ja sakrīt, viss labi, ja nē, tad pieprasījumu nevajadzētu apstrādāt.

[ezis]

Tokenus parasti izmanto, lai novērstu XSRF uzbrukumus, teiksim, tu ieliec lietotājam sesijā random id un to pašu id pievieno arī kaut kādai formai. Kad lietotājs nosūta formas datus, salīdzini, vai formas tokens sakrīt ar lietotājam piešķirto tokenu sesijā. Ja sakrīt, viss labi, ja nē, tad pieprasījumu nevajadzētu apstrādāt.

Kādā gadījumā nesakritīs sessijas tokens ar formas tokenu?

 

Nū man ir +/- līdzīgi, ja sessijā ir lietotāja ip + user agents, kas sakrīt ar apmeklētāja ip + user agent datiem, tad turpina čekot tālāk utt..

 

btw, $_SESSION datus 3ša persona taču nekādi nevar iegūt? Kkur lasīju, ja ir register globals on, tad caur url var kkā mainīt $_SESSION datus vai kas tamlīdzīgs. Izklausās jau mazliet pēc wtf? ^_-

 

hmm.. Cik sagūglēju, tad sesiju hijacking un fixation ir tā lielākā sāpē. Nū tad man liekas, ka esmu +/- pret to pasargāts.. Reģenerēju id, lai pasargātos no fixation un par to hijacking īsti nesaprotu :\ Sākt jukt viss kopa :@

 

Kā reāli tas notiek? http://phpsec.org/projects/guide/4.html Tēmā par Session Hijacking sanāk, ka sesija darbosies ar pieprasījumu no kkāda:

GET / HTTP/1.1

Host: example.org

User-Agent: Mozilla/5.0 Gecko

Accept: text/xml, image/png, image/jpeg, image/gif, */*

Cookie: PHPSESSID=1234

 

Un tad, ja ar tieši šādu pašu HTTP request (vai kā pareizi sakukt?) konektējos pie servera, tad man būs pieejama cita lietotāja sesija un šo visu procesu sauc par Session Hijacking? :D

 

Kas tad īsti ir tas:

GET / HTTP/1.1

Host: example.org

User-Agent: Mozilla/5.0 Gecko

Accept: text/xml, image/png, image/jpeg, image/gif, */*

Cookie: PHPSESSID=1234

 

sessijas atstāts cepums?

 

Bet pret to Session Hijacking esmu taču +/- pasargāts ar šo te

$session_token = isset($_SESSION['stoken']) ? $_SESSION['stoken'] : false;
$visitor_token = md5(getip() . $_SERVER['HTTP_USER_AGENT']);

 

ja pareizi esmu sapratis kā tas viss notiek.. :?

 

Kā sessija vispar zin, ka tas ir tas useris? Viņa atstaj kko lietotājam (cepumu?) un tad skatās vai tas ir tas pats? Vai ari glabā serverī kko no lietotāja puses.. Meklēju google kā darbojas sessijas, bet tracina, neatradu atbildi :O

aa, doh! http://www.php.net/manual/en/intro.session.php otrā rindkopa ;D

Edited January 18, 2011 by ezis

[daGrevis]

Es, protams, ļoti atvainos, bet... KAD TU GULI?! O.o

[ezis]

Es, protams, ļoti atvainos, bet... KAD TU GULI?! O.o

Gribēju uzzināt atbildi un iekritu azartā meklējot to! :D

[mad182]

Kādā gadījumā nesakritīs sessijas tokens ar formas tokenu?

Tad, kad post dati tiks sūtīti no citurienes, nevis formas tavā lapā :)

[briedis]

lietotājam ir cepums ar sesijas id.

 

Kad lietotājs ienāk lapā, viņš padod serverim cepumu. Serveris paskatās, kas tur par id ir cepumā un attiecīgi izmanto to sesiju, kas atbilst šim cepumam. Serveris nekādīgi nepārbauda, vai lietotājam patiešām pieder šī sesija.

 

Tāpēc, to tu vari darīt pats, ieliekot sesijā arī mainīgo, kas identificē īsto lietotāju, teiksim ip, vai useragent, vai abus kopā. Un, ja šis nesakrīt, visdrīzāk kāds ir nozadzis kādam citam sesijas identifikatoru un mēģina par viņi uzdoties :)

 

 

Vēl viens drošības risks ir XSRF, par to ir gana daudz materiālu: http://www.google.lv/search?q=XSRF tur arī būs aprakstīts par tokenu lietošanu.

[ezis]

lietotājam ir cepums ar sesijas id.

 

Kad lietotājs ienāk lapā, viņš padod serverim cepumu. Serveris paskatās, kas tur par id ir cepumā un attiecīgi izmanto to sesiju, kas atbilst šim cepumam. Serveris nekādīgi nepārbauda, vai lietotājam patiešām pieder šī sesija.

 

Tāpēc, to tu vari darīt pats, ieliekot sesijā arī mainīgo, kas identificē īsto lietotāju, teiksim ip, vai useragent, vai abus kopā. Un, ja šis nesakrīt, visdrīzāk kāds ir nozadzis kādam citam sesijas identifikatoru un mēģina par viņi uzdoties :)

 

 

Vēl viens drošības risks ir XSRF, par to ir gana daudz materiālu: http://www.google.lv/search?q=XSRF tur arī būs aprakstīts par tokenu lietošanu.

Kaut kā tā arī es tagad daru! Velku visu laiku līdzi iekš db user token (ip+user_agent) un pēctam tik čeko, ja šis nesakritīs, tad nebūs lietotāja pieeja :)