Autorizēšanās sesijas in-depth

[kristers_Z]

Ielogojot lietotāju lapas administratoru zonā, es lietoju sesiju. Vai parbauditu, vai lietotajs ir ielogots, ar isset() parbaudu vai vinam ir sesija.

 

Kādi mehānismi pastāv, kas mani attur no iespējas nozagt cita ielogota lietotāja cookie vērtību, izmainīt manā pārlūkprogrammā esošo cookie, refreshot lapu un iekļūt tā otra cilvēka profilā? P.S (Šeit pieņemam, ka man IR piekļuve otra cilvēka datoram bet kaut kāda iemesla pēc es nevaru nozagt plain-text paroli un nevaru arī izmantot jau ielogoto profilu. Man obligāti vajag autorizēties uz cita datora.)

Edited August 27, 2013 by kristers_Z

[Kasspars]

Man kaut kā šķiet, ka tu par muļķi mēģini izlikties. Tik smalki esi izpētījis, bet saprašanas par sesiju kā tādu nav, hmmm... Piedod ja apvainoju!

[codez]

4.) Kas mani attur no iespējas nozagt cita ielogota lietotāja cookie vērtību, izmainīt manā pārlūkprogrammā esošo cookie, refreshot lapu un iekļūt tā otra cilvēka profilā?

 

P.S (Šeit pieņemam, ka man IR piekļuve otra cilvēka datoram. Praktiski tā būtu attālināta piekļuve. Vīruss, kas nozog cookie. Ja man būtu tieša fiziska piekļuve autorizēta profila cookie, tad man būtu arī piekļuve šim profilam. Lai veiktu kaut kādas darbības, man nebūtu vajadzības ielogoties uz cita datora.)

 

Lol, ja tev ir piekļuve datoram, tad var nozagt arī paroles un visu pārējo. Pie tam vienkāršā variantā kūkijs tev ļauj tikai uz tās sesijas laiku piekļūt profilam.

[mandarīnpīle]

Man šķiet tāda veida uzbrukumu sauc par session poisoning. Kā jau codez teica, diez vai par to ir vērts ļoti satraukties, jo, ja ir iespējas īstenot ko tādu, tad tik pat labi var īstenot tiešās paroles nozagšanu.

 

Par tiem apstākļiem. Ja nozog kukiju, tad IP adreses un browsera sakrišana varētu īstenoties tikai diezgan šauros apstākļos. Abiem datoriem jābūt aiz viena rūtera  un jālieto viens pārlūks. Es uzreiz iedomājos interneta kafejnīcu ai autobusus ar bezmaksas wifi. Turklāt, dēļ sesijas ierobežotā lifetaima, visa nozagšana un pārrakstīšana jāīsteno mazāk nekā 5 minūtēs (standarta sesijas laiks).

Edited July 16, 2013 by mandarīnpīle

[kristers_Z]

php.com :

 

"Also its always good to ensure every valid session is checked against an ip. One good method is to store the session id and remote ip information in a table, or better store the ip as a session variable itself, once the user logs in and ensure that this is continued for remaining pages for security. This ofcourse wont work when users use the same office or shared network as the ip to the outside world is the same."

 

Kā tiek atšķirti divi datori aiz viena rūtera vai aiz vienas proxy adreses, kam ir vienādas pārlukprogrammas? Tas nozīmē ka IP un User Agent sakrīt. Vai šādā gadījumā atškiršanai tiek lietots Code Igniter saglabātais sesijas izveidošanas (ielogošanās) timestamp?

Edited August 27, 2013 by kristers_Z

[codez]

Tad mans nākošais jautājums - kā tiek atšķirti divi datori aiz viena rūtera vai aiz vienas proxy adreses, kam ir vienādas pārlukprogrammas?

 

Katram datoram ir cits kūkijs un attiecīgi cita sesija.

 

Kas attiecas uz IP, tad pat lielajos servisos IP netiek izmantots, jo vari mierīgi ar portatīvo ceļot no vienas vietas uz otru un nebūs jāautorizējas katru reizi.

[codez]

1.) Ar Chrome atveru for_chrome.php, atveru see_sessions.php, iegūstu "Google Chrome".

2.) Neaizverot Chromu, ar Firefox atveru for_firefox.php, atveru see_sessions.php, iegūstu "Mozilla Firefox".

3.) Refreshoju Chromā atvērto lapu, tā arī saka "Mozilla Firefox". 

Tas liek domāt, ka native PHP sesijas neatšķir browsera maiņu. Abiem browseriem bija piekļuve pie viena un tā paša 'id' sesijas mainīgā. Ja lietotājs ielogojies Chromā, atvērs to pašu lapu Firefoxā, viņš redzēs nevis autorizēšanās paneli, bet savu profilu.

 

Nezinu, ko tu pīpē, bet pat veselais saprāts saka, ka nekas tāds nav iespējams.

Tāpēc uztaisīju eksperimentu un tiešām nekas tāds nav:

Projekta faili: https://c9.io/codez2/testphp

Uzstāda vienu sesijas vērtību: http://testphp.codez2.c9.io/one.php

Uzstāda otru sesijas vērtību: http://testphp.codez2.c9.io/two.php

Apskatās sesijas masīvu: http://testphp.codez2.c9.io/view.php

[kristers_Z]

Codez, ar IP neizmantošanu lielajos servisos tu domāji tā, ka ar portatīvo vienā WiFi tīklā autorizējās kādā lapā, tad atslēdzas no tā tīkla, pievienojas citam, refrešo lapu un netiks prasīts ielogoties vēlreiz?

[codez]

Codez, ar IP neizmantošanu lielajos servisos tu domāji tā, ka ar portatīvo vienā WiFi tīklā autorizējās kādā lapā, tad atslēdzas no tā tīkla, pievienojas citam, refrešo lapu un netiks prasīts ielogoties vēlreiz?

Jā.

[kristers_Z]

Jā.

 

1.) Kāda jēga CodeIgniter cepumā saglabāt visu to, kas tur tiek saglabāts - IP, User Agent, timestampu ?

2.) Vai IP izmantošana lielajos servisos vispār dotu kādu papildus drošību un vai tā izmantošana ir iespējama? Papildus drošību es iztēlojos tā, ka bez IP kāds var nozagt kukiju un 5min laikā to ievadīt savā pārlūkā, autorizēties. Ja tiek salīdzinātas IP, tas nav iespējams. Un to neiespējamību izmantot es iedomājos dēļ lietotājiem kas ir aiz proxijiem un tml ietaisēm, dēļ kurām lapas browsošanas laikā lietotājam var mainīties IP adrese, dēļ kā viņš tiks regulāri izmests no lapas un lūgts autorizēties vēlreiz.

Edited July 16, 2013 by kristers_Z

[codez]

1.) Kāda jēga CodeIgniter cepumā saglabāt visu to, kas tur tiek saglabāts - IP, User Agent, timestampu ?

Neesmu pētījis konkrēti CI kodu, bet visdrīzāk, ka kūkijos nekas tāds netiek saglabāts.

Ja tu domā, ka tiek, vai vari parādīt par kuru koda vietu konkrēti ir runa?

2.) Vai IP izmantošana lielajos servisos vispār dotu kādu papildus drošību un vai tā izmantošana ir iespējama? Papildus drošību es iztēlojos tā, ka bez IP kāds var nozagt kukiju un 5min laikā to ievadīt savā pārlūkā, autorizēties. Ja tiek salīdzinātas IP, tas nav iespējams. Un to neiespējamību izmantot es iedomājos dēļ lietotājiem kas ir aiz proxijiem un tml ietaisēm, dēļ kurām lapas browsošanas laikā lietotājam var mainīties IP adrese, dēļ kā viņš tiks regulāri izmests no lapas un lūgts autorizēties vēlreiz.

IP papildus lietošana dodu papildus drošību tikai tajos gadijumos, kad kūkiju var nozagt, bet pašu paroli nevar. Vienīgais, kas nāk prātā šādai situācijai, ir lapa ar XSS ievainojamību, kur to izmantojot labā tiek iekļauts js, kurš nozog lietotāju kūkijus un nosūta saimniekam.

[rATRIJS]

Nu kukijus var nozagt arī caur tīklu kuram esi pievienojies ( publisks WiFi, piemēram, ar Firesheep ). Te var izlīdzēties ar SSL ( tiesa paliks codez pieminētā problēma ar XSS, bet normālās lapās tak XSS ievainojamības nav vai ne? ).

[codez]

Nu kukijus var nozagt arī caur tīklu kuram esi pievienojies ( publisks WiFi, piemēram, ar Firesheep ). Te var izlīdzēties ar SSL ( tiesa paliks codez pieminētā problēma ar XSS, bet normālās lapās tak XSS ievainojamības nav vai ne? ).

Ja WiFi-jā var nozagt kūkijus, tad var nozagt ari post datus, tātad paroles.

 

P.S. Te gan jāpiemin, ja XSS ievainojamība ir lapas daļā, kas ir vienlaikus ar login formu, tad arī ar XSS var nozagt paroles.

P.P.S. Īstenībā pietiek, ka XSS ir jebkurā vietā. XSS var pārvērst lapu par login lapai līdzigu un tādā veidā nozagt paroli.

Edited July 16, 2013 by codez

[F3llony]

Pret kūkiju zagļiem der tikai behavioral analysis. Piemēram, sesijas īpašnieks diez vai spēja te pēkšņi lapu lietot UK un pēc 2 minūtēm Krievijā. Arī pārlūkus sesijas laikā nemaina, arī to versijas ne. 

[kristers_Z]

Neesmu pētījis konkrēti CI kodu, bet visdrīzāk, ka kūkijos nekas tāds netiek saglabāts.

Ja tu domā, ka tiek, vai vari parādīt par kuru koda vietu konkrēti ir runa?IP papildus lietošana dodu papildus drošību tikai tajos gadijumos, kad kūkiju var nozagt, bet pašu paroli nevar. Vienīgais, kas nāk prātā šādai situācijai, ir lapa ar XSS ievainojamību, kur to izmantojot labā tiek iekļauts js, kurš nozog lietotāju kūkijus un nosūta saimniekam.

 

CI User guide oficiālā lapa http://ellislab.com/codeigniter/user-guide/libraries/sessions.html sadaļā ""What is session data?" raksta:

 

A session, as far as CodeIgniter is concerned, is simply an array containing the following information:

• The user's unique Session ID (this is a statistically random string with very strong entropy, hashed with MD5 for portability, and regenerated (by default) every five minutes)
• The user's IP Address
• The user's User Agent data (the first 120 characters of the browser data string)
• The "last activity" time stamp.

The above data is stored in a cookie as a serialized array with this prototype:

[array]

(

     'session_id'    => random hash,

     'ip_address'    => 'string - user IP address',

     'user_agent'    => 'string - user agent data',

     'last_activity' => timestamp

)

 

 

 

Izvilkums no koda:

// Is the session data we unserialized an array with the correct format?
		if ( ! is_array($session) OR ! isset($session['session_id']) OR ! isset($session['ip_address']) OR ! isset($session['user_agent']) OR ! isset($session['last_activity']))
		{
			$this->sess_destroy();
			return FALSE;
		}

		// Is the session current?
		if (($session['last_activity'] + $this->sess_expiration) < $this->now)
		{
			$this->sess_destroy();
			return FALSE;
		}

		// Does the IP Match?
		if ($this->sess_match_ip == TRUE AND $session['ip_address'] != $this->CI->input->ip_address())
		{
			$this->sess_destroy();
			return FALSE;
		}

		// Does the User Agent Match?
		if ($this->sess_match_useragent == TRUE AND trim($session['user_agent']) != trim(substr($this->CI->input->user_agent(), 0, 120)))
		{
			$this->sess_destroy();
			return FALSE;
		}

Edited August 27, 2013 by kristers_Z