PHP Session Tracking

[iMa_NeKo_PljUgU]

Hm... Jel ima neko da mi objasni malo detaljnije praćenje sesija u PHP-u..
Radio sam u asp-u neko vreme i nikad se nisam susreo sa tim, pa me zanima da li je:

1. Neophodno ili je to samo sigurnosni fazon.
2. Kako izvesti praćenje preko hidden form-e (kapiram princip, ali ako može neki primer).

Hvala unapred

[holodoc]

Uf...Malo konfuzno pitanje

Generalno sesije služe da jedinstveno identifikuju korisnika u klijent-server komunikaciji. Kod PHP-a konkretno sesija se nativno (po srpski rečeno "po defaultu") identifikuje putem 32bajtnog MD5 hash stringa koji se jednostavnim imenom zove session id. Ako pogledaš kolačiće koje dobijaš nazad od bilo kog servera koji ti isporuči PHP stranicu primetićeš da se taj session id identifikuje putem kolačića pod imenom PHPSESSID. Session id se jako često koristi u sistemima za logovanje i autorizaciju pristupa određenim delovima aplikacije a najčešće se skladišti u bazu u tabelu korisnika gde slu\i da prilikom provere sesije jedinstveno identifikuje korisnikovu trenutno aktivnu sesiju. Session id-evi je takođe moguće iznova generisati putem funkcije session_regenerate_id a moguće su i razne druge manipulacije.

E sad... Sesije su obično i najčešće ciljani element komunikacije između klijenta i servera u cilju napada na sajtove. Pogrešno konfigurisani serveri i slične stvari koje se obično nazivaju session hijacking ili session spoofing (iako su ovo generalno dva različita pristupa napada na sajt) često nateraju developere da sami konstruišu svoj sistem praćenja sesija. za to developeri veoma često primenjuju tehnike kao što su generisanje sesija putem nekog jačeg hash algoritma (recimo SHA1, SHA2 ili SHA256) i njegovo skladištenje u bazu podataka. Ovo se skoro uvek radi na deljenim serverima gde se često dešava da pošto su sesije skladištene u fajl sistemu putem "rupa" u drugim sajtovima na istom deljenom serveru tvoj sajt takođe može da strada.

Za ovaj primer što pominješ preko hidden forme iskreno mi nije jasno šta si tačno hteo da kažeš... Mada...Možda si mislio na session hijacking. Jedna od veoma često korišćenjih tehnika za izvođenje tog napade na sajtove se opet sastoji od tzv. form spoofing-a ili defaceovanje forme (po srpski rečeno sakaćenje forme sa nekog sajta kako bi se prosledili maliciozni podaci istom). Kako to radi? Pa jednostavno... PHP funkcioniše po fallback sistemu kada su sesije u pitanju. Dakle sesije zahtevaju kolačiće a ako oni ne postoje ili nisu dozvoljeni na klijentskoj mašini kompletna "autentifikacija" klijenta se sprovodi slanjem (najčešće) GET parametra PHPSESSID u adresi aplikacije...

Primera radi... Čika Voja se na ovom forumu loguje u svoj admin deo ali iz nekog razloga su mu isključeni kolačići. PHP tada aktivira fallback sistem tj. session id prosleđuje putem adrese koja izgleda ovako:
http://www.sk.rs/forum/adminсp/?PHPS...7b82df129c8d38.

Ukoliko napadač nekom od tehnika (najčešće XSS-om) uspe da sazna ovaj PHPSESSID čika Voja bi (u suštini) bio pečen zato što je samo dovoljno originalnu formu sa adrese koju sam gore naveo sačuvati na svom hard disku i izmeniti je tako da sadrži hidden polje koje se zove PHPSESSID i dodati mu odmah vrednost 89ec1dbd2234c979a07b82df129c8d38 Dovoljno je da napadač pošalje takvu formu i isti automatski preuzima sve privilegije administratora jer za sistem ne postoji (skoro) način da prepozna da to nije Voja jer bože moj...Session id se poklapa

Na žalost svih onih koji misle da sada počnu da se igraju sa tehnikom koju sam gore naveo stvari nisu uvek baš tako jednostavne i postoje sistemi zaštite koji eliminišu mogućnost da se na ovakav način sistem "obije". Sistem zaštite pre svega podrazumeva da se zahteva korišćenje kolačića i da se sve POST i GET promenjljive filtriraju. Evo jednog dobrog primera zbog čega je $_REQUEST način pribavljanja podataka gledano sa aspekta sigurnosti loš mada ne bih sada zalazio u dubinu o tome

E sad... Neki sistemi još uvek nisu otporni na gore navedenu tehniku ali imaju možda druge načine detekcije i prevencije napada koju web developeri vole da razviju sami. Zaštite mogu biti svakakve od "cinkarenja" servera adminu na mail kada se nešto sumnjivi desi do veoma često korišćene opcije automatske regeneracije session id-a svaki put kada se poseti neka stranica.

Za kraj... Sve što sam naveo gore služi isključivo u edukativne svrhe i u najvećem broju slučajeva neće funkcionisati jer su sistemi zaštite već razvijeni ali treba da ima za cilj da vas upozori da pazite da recimo kada vam neko pošalje na email link u kome na kraju stoji PHPSESSID ne klikćete na njega jer je skoro uvek u pitanju krađa vašeg identiteta. To je samo jedan moguć scenario

A da... Veoma dobri izvori koji će generalno odgovoriti na sva tvoja pitanja su sledeći linkovi...
http://shiflett.org/
http://phpsec.org/
i naravno http://www.php.net/session
Knock yurselves out

[iMa_NeKo_PljUgU]

Uh, koliki text
Znao sam da ćeš ti da odgovoriš tako detaljno, ali... Kapiram ja šta su sesije i koristim ih upravo u svrhe logovanja na sistem, e sad u asp-u sam ih stvarao i samo proveravao da li postoje bez ikakvih hash stvari u url-u ili u hidden formama... I tako isto sam uradio u PHP-u, ali avaj onda nađoh da ljudi prate te PHPSESSID i ubacuju ih u tabele i prate ih putem query stringa ili hidden formi?

Npr.

<input type="hidden" name="securitytoken" value="8905479d4be2863131f07df931cbbe115c31fa05" />

E sad moje pitanje je jesnostavno: zašto to rade, kako to rade, da li time dobijaju samo na bezbednosti, jbt. ili me osakatio asp ili sam glup...

P.S. Hvala na onako detaljnom odgovoru

[holodoc]

E vidiš i ovde sada može da bude različitih razloga zbog čega ti imaš taj sakriveni token u formi mada generalno je pravilo da se izbegava da se bilo šta od "sigurnih" informacija ostavlja po sakrivenim poljima u formi. U suštini ako nešto i ostaviš kod posetioca u browseru to je "samosklepani" sessionid hash u cookie-u i još par nekih podataka koji ne mogu da posluže za "obijanje" sajta (preferirana podešavanja i sl.)

E sad...Što se tiče samog PHPSESSID-a pretpostavljam da je najjednostavnije da ti odgovorim ovako... Zaboravi na njega Naime da ne bih ponovo zalazio u teoriju najbolje je da se upoznaš sa načinima kako da isključiš prosleđivanje PHPSESSID-a Razloga ima milion a jedan od njih jesu i pretraživači... PHPSESSID u URL je isto kao da sipaš cement umesto soli u kafu

Evo primera jednog linka koji mi se čini OK.. Izguglao sam ga i ja tako da možda nije baš najbolji ali koliko vidim sadrži najvažnije
http://www.ragepank.com/articles/26/disable-phpsessid/

A u vezi ovih sakrivenih podataka u formama... Oni mogu da znače sve i svašta... Primera radi ovde se radi o SHA1 (mada može biti i neka jača SHA enkripcija to nije moguće proveriti) koji se možda koristi za garantovanje da je formu generisala stranica na serveru tj. ovo je najverovatnije form spoofing protekcija. Kako ovo radi? Radi tako što kada posetilac zatraži formu server je generiše ali usput prosledi i secirity token. U isto vreme taj security token upiše u $_SESSION promenjljivu i onda kada ti pošalješ popunjenu formu server upoređuje prosleđeno hidden polje sa podatkom upisanim u server promenjlivoj. Ako su isti onda je forma originalna tj. nije spoofovana. Ako nije forma se opet prosleđuje i dobija se drugi security token. Generalno taj kod služi da forma važi samo za jedan ciklus slanja sa servera i primanja te forme od klijenta.

Da li je namena ovog koda ovo što sam ja napisao najlakše ćeš proveriti tako što ćeš jednostavno da osvežiš stranicu i kod će se promeniti mada ni tada ne možeš baš 100% da garantuješ Nažalost ovu sigurnosnu tehniku je jako lako zaobići Firebug-om i sličnim aplikacijama tako da i nema neku preterano veliku upotrebnu vrednost.

Pa opet... Taj token može da se koristi i za sprečavanje da browseri automatski popunjava podatke u formama kada se sačuvaju itd. No to je potpuno druga priča

PHP i web razvoj su tako zanimljive igračke aeh?

[iMa_NeKo_PljUgU]

Uh... Holy ti si
Sada mi je jasnije/jasno Malo sam zaglupljen ovih dana, imam PHP, napredni JS/AJAX, Javu, MySQL, C# i C običan u glavi (ispiti)...
U svakom slučaju hvala na objašnjenjima i videću da pokupim sve tvoje postove o web-u i da ih objavim u knjizi i zaradim milione

P.S. Nego šta nego su zanimljive "igračke"

[holodoc]

iMa_NeKo_PljUgU kaže:

Uh... Holy ti si
Sada mi je jasnije/jasno Malo sam zaglupljen ovih dana, imam PHP, napredni JS/AJAX, Javu, MySQL, C# i C običan u glavi (ispiti)...
U svakom slučaju hvala na objašnjenjima i videću da pokupim sve tvoje postove o web-u i da ih objavim u knjizi i zaradim milione

Ako zaradiš milione na njima ne zaboravi da pošalješ flajku "Bitter Leafa" (koristim politički korektan izraz zbog toga što ovaj forum ne podržava alkoholizam čak ga i prezire)

[AlekBGD]

Има још једна квака...
Сесије могу представљати проблем на дељеном хостингу када је у питању оптимизација сајта за претраживаче.

[holodoc]

AlekBGD kaže:

Има још једна квака...
Сесије могу представљати проблем на дељеном хостингу када је у питању оптимизација сајта за претраживаче.

Sve to piše na stranici za koju je naveden linak gore

EDIT: Mada...Kakve veze ima deljeni hosting i session id-evi sa optimizacijom sajta za pretraživače?

[iMa_NeKo_PljUgU]

Od tvog tutorijala je prošlo "dosta" vremena Holy tako da sam bio slobodan da još malo proučim sesije

Koliko znam na deljenom hostingu problem sa sesijama je sigurnost, ako se naravno prave session fajlovi... Tako da sam napravio klasicu koja zaobilazi upisivanje session podataka u fajlove i upisuje ih u bazu... Bravo za mene

[AlekBGD]

Могао си само да измениш директоријум где се чувају сесије, ово сам пробао, али нисам детаљније испробавао.
Свакако ћу ускоро да се позабавим више сесијама на мом ЦМС-у, сада имам битнијих ствари да радим.
Проблем на дељеном хостингу је што нису све ПХП функције дозвољене, тако да ?sid=als43klh489f54khgf не могу да сакријем. То Гоогле претраживач види као страницу.

[holodoc]

AlekBGD kaže:

Могао си само да измениш директоријум где се чувају сесије, ово сам пробао, али нисам детаљније испробавао.
Свакако ћу ускоро да се позабавим више сесијама на мом ЦМС-у, сада имам битнијих ствари да радим.
Проблем на дељеном хостингу је што нису све ПХП функције дозвољене, тако да ?sid=als43klh489f54khgf не могу да сакријем. То Гоогле претраживач види као страницу.

Ovo je gomila gluposti tako da ću zbog ostalih koji čitaju moje komentare prokomentarisati a tebe neću terati da počneš da učiš latinicu

Kao prvo promena deafultnog foldera gde se skladište fajlovi sa informacijama o sesijama PHP klijenata je totalna glupost koja je bila aktuelna u knjigama koje su se bavili tematikom PHP sigurnosti pre jedno 5-6 pa i više godina. Infomacija gde se nalazi folder u kome se smeštaju podaci se može dobiti bar malim milionom dostupnih tehnika od kojih je recimo jedan najobičniji phpinfo() sakriven u injektovanoj PHP skripti dovoljan da za manje od mikrosekunde da tačnu informaciju gde se nalazi "defaultni" folder za snimanje sesija. Potrebno je samo očitati vrednost session.save_path parametra i voila.

Kao drugo kada se smišlja koncept same aplikacije potrebno je uzeti u obzir da će ta aplikacija verovatno raditi na različitim serverima u različitim PHP okruženjima pa je zbog toga zlatno pravilo dobrog planiranja da treba planirati za svaki mogući scenario. Predlog da se promeni defaultni session storage folder (gore pomenuti session.save_path) je stavka o kojoj mogu da sanjaju samo oni koji imaju kompletnu kontrolu na svom serveru a da o tako nečemu ni ne počinjem u slučaju deljenog hostinga gde klijent može biti srećan ako ne bude morao da koristi ograničenja "Safe mode"-a.

Kao treće... Problem sa tzv. "transparentnim session id-evima" se u većini slučajeva kod servera koji su tvrdoglavi pa imaju ovu opciju po "defaultu" uključenu rešava ili u samom .htaccess fajlu (ne preproučujem mada radi)

php_flag session.use_trans_sid off

ili putem runtime konfiguracije u PHP skripti gde se odmah na početak postavlja sledeći red

PHP kod:

ini_set('session.use_trans_sid', false); 


Da stvar bude interesantnija ova direktiva spada u klasu tzv. PHP_INI_ALL direktiva (detaljan pregled PHP direktiva i njihovih klasa) što znači da se mogu postaviti apsolutno bilo gde u sistemu tj. čak i kada je aktivan "Safe Mode" tako da stvarno mora da bude u pitanju jako nestandardan razlog zbog čega bi ikada na bilo kom normalnom serveru došlo do problema da transaprentni id-evi budu uvek prisutni u komunikaciji između klijenta i servera. To sa sid-ovi bitno utiču na plasiranost stranice se slažem jer Google često može da protumači različite sid-ove kao recimo refleksiju (identična stranica vremenom se indeksira sa dva različita sid-a i Google razume to kao dve različite stranice sa istim sadržajem i obara rank sajtu) itd. Za taj deo se slažem.

Kao četvrto... Čuvanje podataka o sesijama u bazi podatka je danas de facto standard kada su u pitanju aplikacije koje će prevashodno biti korišćenje na deljenim serverima. Ovaj pristup jednostavno eliminiše potrebu programera da vodi računa o tome da li će neko kojim slučajem da reši da primeni neku od često veoma uspešnih taktika za eksploataciju sigurnosnih propusta sesija na deljenim hostinzima. Za konstruisanje sistema koji će koristiti bazu za skladištenje sesija umesto klasičnog fajl sistema treba pogledati funkciju session_set_save_hadler koja obezbeđuje ovu funkcionalnost ili je još bolje ovakav sistem dobro zasnovati na jednoj abstraktnoj klasi koja će implementirati sve metode koje gore pomenuta funkcija zahteva.

To opet ne znači da su sistemi koji skladište sesije u bazama podataka apsolutno sigurni. Znam za slučajeve kada su kolege toliko bile sigurne u navedeni sistem da su potpuno zaboravili na činjenicu da adekvatno zaštite svoj sistem od SQL injekcije I ode mas' u propas'...

Eto toliko... Ovaj tekst treba da ima za cilj da objasni zbog čega je gore citirani tekst najobičnija glupost i plod neiskustva njegovog autora a ne da bi se dokazalo čiji je duži

[AlekBGD]

Само неискусном програмеру може свако да "ињуктује" пхп инфо и да види директоријум. Али постоји и .хтаццесс
А то што си горе рекао ми не помаже. php flag је забрањен као и ini_set зато што је дељени хостинг.
Нигде нисам рекао да сам искусан програмер, а чак што више када ме неко пита кажем да сам аматер и да многе ствари не знам.
Ти видим не можеш да се помириш са чињеницом да нико не може да зна све.
To што говориш да је све то гомила глупости ме вређа. Све што сам овде писао сам писао ако сам довољно упућен, ако нисам само читам.

[AlekBGD]

AlekBGD kaže:

Могао си само да измениш директоријум где се чувају сесије, ово сам пробао, али нисам детаљније испробавао.
Свакако ћу ускоро да се позабавим више сесијама на мом ЦМС-у, сада имам битнијих ствари да радим.
Проблем на дељеном хостингу је што нису све ПХП функције дозвољене, тако да ?sid=als43klh489f54khgf не могу да сакријем. То Гоогле претраживач види као страницу.

Да ли си уопште прочитао ово од слова до слова? Поготово овај део "нису све ПХП функције дозвољене" и "нисам детаљније испробавао".

[holodoc]

AlekBGD kaže:

Само неискусном програмеру може свако да "ињуктује" пхп инфо и да види директоријум.

Jel treba i ovo da nazovem najobičnijom glupošću ili ćeš ti to ovog puta da uradiš sam? Iskustvo programera ni na koji način ne isključuje mogućnost najbanalnijih kikseva koji mogu da dovedu do kompromitovanja sigurnosti sistema. Net je upravo prepun takvih primera.

A phpinfo injekcija. Tačno je da je preuzimanje kompletnog phpinfa postalo malo i demode ali treba imati u vidu da je sve što je potrebno za kompletan listing injekcija linije "phpinfo();" bilo gde u kodu stranice. XSS napadi su za to savršeni Očitavanje sadržaja foldera se takođe relativno lako radi korišćenjem bilo koje od tehnika za "directory traversing" tako da... Poenta cele priče je... Sigurnost jednostavno nije nešto što je zapisano crno-na belo već je to stvar koja se kreće, razvija i menja. Svakoga dana rađaju se nove tehnike za kompromitovanje sistema a zadatak onoga ko je zadužen za bezbednost sistema, ne samo programera već i administracije koja održava sistem, da se što pre upozna sa novim "izumima" i zaštiti svoj sistem od potencijalnih napada.
Obavezna lektira: http://shiflett.org/ i http://phpsec.org/.

AlekBGD kaže:

Нигде нисам рекао да сам искусан програмер, а чак што више када ме неко пита кажем да сам аматер и да многе ствари не знам.
Ти видим не можеш да се помириш са чињеницом да нико не може да зна све.

Poenta cele ove moje priče nije da nekome nabijam na nos to što nešto ne zna, jer je to sasvim normalna stvar, već da sprečim ljude da svoje neznanje (ili bar polovično znanje) šire dalje. Naučiti nekoga nečemu što si čuo ili nisi baš siguran da li je tačno ali ćeš za potrebe zadovoljenja svoje sujete ipak ekspertski da ga izneseš nekome je po meni mnogo veći problem nego prećutati nešto i sačuvati sebe blama i druge netačnih informacija.

AlekBGD kaže:

To што говориш да је све то гомила глупости ме вређа. Све што сам овде писао сам писао ако сам довољно упућен, ако нисам само читам.

Istina i moje citiranje nije baš bilo najsrećnije. Kada sam rekao gluposti mislio sam na prvi deo tvog posta u kome pominješ promenu deafult foldera za skladištenje sesija što samo po sebi vuče oko 95% one kvalifikacije "glupost"

AlekBGD kaže:

Али постоји и .хтаццесс

...koji neće raditi sve dok ga ne nazoveš .htaccess... Zbog toga ti cela stvar najverovatnije i ne funkcioniš

AlekBGD kaže:

А то што си горе рекао ми не помаже. php flag је забрањен као и ini_set зато што је дељени хостинг.

Ukoliko ti host zaista zabranjuje u isto vreme i ini_set i postavljanje direktiva u .htaccess, što je inače totalna paranoja ili pre svega neiskustvo administratora, onda ne znam zbog čega insistiraš da svoj sajt držiš na takvom host-u? Naime, takve restrikcije višestruko prevazilaze stepen paranoje zbog kojeg bi neko recimo odlučio da uključi "safe mode" PHP-a jer se ini_set onda našao na listi eksplicitno zabranjenih PHP funkcija što je opet moram da kažem potpuna glupost.

AlekBGD kaže:

Да ли си уопште прочитао ово од слова до слова? Поготово овај део "нису све ПХП функције дозвољене" и "нисам детаљније испробавао".

Detaljno. Zato i kažem da sa jedne strane ne možeš pričati o iluzijama da ćeš na istom serveru gde su (potencijlano) zabranjen recimo ini_set i .htaccess ne funckioniše ti biti u stanju da menjaš stazu gde se čuvaju sesije.

Da rezimiram... Sve što sam gore naveo nema za cilj da bilo koga uvredi ili kompromituje. Reći za nešto da je glupost je sasvim normalna stvar i ja ću uvek nešto nazvati glupošću ako mislim da to jeste. Možda je pomalo okrutno ali tako stvari stoje a sve u cilju da iz kompletne priče izvuče bar neka pouka vredna kompletnog ovog romana.

[AlekBGD]

Хаххаха како сам се насмејао. Неколико људи је тражило рупе и нису нашли, а сада ми ти причаш једино ако ти у баналан кикс подражумеваш када се на скрипти за upload дозволи уплоад .php фајлова такве стари нису баш баналне. То су великли пропусти.
.htaccess није забрањен на хостингу, наравно.

И питам се зашто настављаш по старом и цитираш глупости покушавајући да докажеш оно што је немогуће гледај:
Citat:
AlekBGD kaže:
Али постоји и .хтаццесс

...koji neće raditi sve dok ga ne nazoveš .htaccess... Zbog toga ti cela stvar najverovatnije i ne funkcioniš

???????????
заиста мислиш да сам ћирилицом писао .хтаццесс или се само правиш паметан као до сада

[holodoc]

AlekBGD kaže:

Хаххаха како сам се насмејао. Неколико људи је тражило рупе и нису нашли, а сада ми ти причаш

Ih bre... Čak nekoliko ljudi? Pa za to već ne postoji dobar kontraargument Elem, nije bitno koliko već koji ljudi vrše proveru. Potvrda nekolicine ljudi koji su "probali a nisu uspeli" da naprave neki karambol svakako nije potvrda da je sistem siguran. Takvu procenu (koja čak ni tada nije stopostotno sigurna) mogu davati samo priznati stručnjaci koji se bave analizom sigurnosnih propusta softvera i koji imaju jako jako puno godina iskustva sa sistemom koji se posmatra. Par "casual" posmatrača sasvim sigurno nisu verodostojni za etiketu "100%"

AlekBGD kaže:

једино ако ти у баналан кикс подражумеваш када се на скрипти за upload дозволи уплоад .php фајлова такве стари нису баш баналне. То су великли пропусти.

Ajde da budemo konstruktivni Ti meni reci kako ti obezbeđuješ da se uploaduju samo zadati tipovi fajlova a ja ću ti odmah reći gde grešiš i gde tvoja zaštita nije dobra

AlekBGD kaže:

.htaccess није забрањен на хостингу, наравно.

Ako je ovo tačno onda gde tačno postoji problem da zabraniš transparentne sid-ove za vreme izvršenja tvoje aplikacije (tzv. runtime config)

AlekBGD kaže:

И питам се зашто настављаш по старом и цитираш глупости покушавајући да докажеш оно што је немогуће гледај:
Citat:
AlekBGD kaže:
Али постоји и .хтаццесс

...koji neće raditi sve dok ga ne nazoveš .htaccess... Zbog toga ti cela stvar najverovatnije i ne funkcioniš

???????????
заиста мислиш да сам ћирилицом писао .хтаццесс или се само правиш паметан као до сада

Hm... Pa pazi... Jedna dobra prijateljica, inače novinar, ima običaj da kaže kada joj pristignu loši dopisi "pobogu...pa ja nisam prorok nego novinar" Isto važi i ovde... Gore si lepo napisao kako ti se fajl zove i kako da ja prokomentarišem drugačije nego da ti skrenem pažnju da naziv fajla mora da bude .htaccess

P.S. Za onaj zadatak gore za forme imaš nedelju dana vremena da lepo izložiš način zaštite svojih upload formi

[AlekBGD]

Хаха ејој.... :d
А што се тиче форми... То, наравно, не желим да откривам.

[holodoc]

AlekBGD kaže:

Хаха ејој.... :d
А што се тиче форми... То, наравно, не желим да откривам.

Jednog dana kada se uozbiljiš možda i prokljuviš značenje potpisa koji promovišem po "dev" forumima

PHP kod:

<?php
abstract class Ignorance extends Stupidity implements Unavoidable {
     public static $humiliation;

     final function findCover();
}
?>

[AlekBGD]

Хаха а баш си завидан :d
Нека би је Бог у помоћи.