următorul mesaj »

[alopia]

Scopul acestui topic ar fi sa gasim impreuna cea mai buna solutie la problema securitatii unei sesiuni php.

In timpul liber ma distrez dezvoltand un CMS productie proprie. M-am izbit dea lungul timpului de problema login-ului si a sesiunilor PHP. Ca oricare dintre noi am inceput prin a folosi metoda simpla prezentata in help-ul oficial cu privire la o sesiune php...

Recunosc din start ca sunt un programator paranoic Simpla generare a unui sesion id si perpetuarea lui nu mi se pare o solutie viabila daca tineti la securitatea site-ului dumneavoastra. Si e dea dreptul nelistitor cati programatori folosesc aceasta metoda in siteurile lor. Am sa prezint in continuare ce solutie folosesc in prezent. Va rog de asemenea sa-mi spuneti daca exista metode mai sofisticate care ar putea inbunatatii securitatea sesiunii php, altele decit cele prezentate mai jos.

Ce aduce in plus metoda folosita de mine fata de cea a generari si perpetuarii unui simplu session id:

Ce avem in baza de date:

• Session id-ul generat de PHP
• IP-ul utilizatorului
• User Agent-ul
• alte informatii utile cum ar fi id-ul utilizatorului logat pe sesiune daca este cazult etc. Aceste informatii nu ne intereseaza pentru ca nu tin de procedura de verificare a sesiunii.

De fiecare data cind ruleaza scriptul se urmareste schema logica de mai jos:

• se seteaza un nume de sesiune customizat via session_name (pentru a ingreuna putin un atacator care se holbeaza din start dupa un sid)
• se starteaza sesiunea via session_start
• se obtine session id si se cauta in baza de date pentru a vedea daca sesiunea este noua sau avem de a face cu o sesiune mai veche
• daca sesiunea nu a fost gasita in baza de date se creeaza o inregistrare noua in baza de date unde se salveaza toate informatiile prezentate mai sus si cam aici se termina procedura...
• daca sesiunea a fost gasita in baza de date se verifica ip-ul utilizatorului sa corespunda cu cel stocat in baza de date si user agentul de asemenea
• daca IP-ul sau User agentul nu corespunde orice utilizator logat pe acea sesiune este scos si se regenereaza o noua sesiune si se salveaza citeva informatii despre acest posibil atac asupra site-ului

Aceasta metoda rezolva urmatoarele brese de securitate alea metodei "obisnuite" bazata numai pe perpetuarea unui session id:

• posibilitatea ca altcineva decat utilizatorul sa puna mina pe session id si sa se conecteze la site dandu-se altcineva lucru care prin metoda clasica este posibil
• sa presupunem ca atacatorul este cineva cu access la traficul intre site si user si are posibilitatea sa mistifice ip-ul si sa "prinda" la intoarcere pachetele ... este probabil insa sa nu banuiasca ca e nevoie sa mistifice si user agentul. Compararea User Agentului ar trebui sa-i puna bete in roate si sa atraga atentia administratorului site-ului ca pe o sesiune User Agentul a fost brusc schimbat. Pentru acest tip de atacator accesul la formularul de login ar trebui de asemenea sa se faca printr-o conexiune https altfel nu mai e nevoie sa sparga securitatea sesiunii ca pune mina direct pe password si userid... Accesul la restul site-ului se poate face prin o conexiune normala.

Cam asta ar fi in mare
Alte idei ? 

Ah ... am atasat de asemenea codul sursa. Puteti sa-l folositi under the GNU General Public License...

[bassul]

Pentru securitate sporita, cel putin intr-un mediu shared, iti doresti probabil sa definesti un director custom pentru salvarea sesiunilor, nu default-ul (/tmp sau care o fi). De asemenea timpul limitat de pastrare al sesiunii.

Cat despre User Agent, probabil ca cel care stie sa se injecteze in traficul facut de un anumit browser stie sa disimuleze si User Agent, Referer si alte chestii. Yahoo, spre exemplu, se protejeaza la asa ceva cerand inca odata parola prin https pentru chestii mai sensibile, iar aplicatiile bancare folosesc https all around.

[Tomoiaga]

Daca ai "acces" la server poti sa compilezi php-ul sa salveze sesiunile direct in memorie, fara /tmp sau altele, plus, cresti si viteza de citire scriere la sesiuni.

[vladb]

Verificarea IPului e problematica.  Unii provideri (AOL fiind in capul listei) trec traficul prin proxyuri si e posibil ca IPul unui request sa nu corespunda cu urmatorul.  Nu stiu daca la noi procedeaza cineva asa, insa posibilitatea exista.  O buna practica este evident schimbarea session id-ului la fiecare request - orice verificari trebuie insa analizate atent pentru ca risti sa blochezi accesul unor utilizatori legitimi.

Cat despre sesiuni in memorie, am incercat cu memcache iar rezultatul (benchmark cu ab) a fost o incetinire, asa ca am dat inapoi.  Da, foloseam conexiuni persistente cu serverul memcache.  E destul de surprinzator si nu exclud posibilitatea unei greseli de partea mea, desi n-am putut sa-mi dau seama unde; php. ini nu ofera prea multe optiuni cu privire la engineul de stocare iar serverul memcache este configurat ok si folosit cu succes in mod curent pentru a destresa mysql.

[dt]

Vezi si http://shiflett.org/articles/session-hijacking + comentariile

[alopia]

Verificarea IPului e problematica.  Unii provideri (AOL fiind in capul listei) trec traficul prin proxyuri si e posibil ca IPul unui request sa nu corespunda cu urmatorul.

Dupa cum ziceam in postul original "daca IP-ul sau User agentul nu corespunde orice utilizator logat pe acea sesiune este scos si se regenereaza o noua sesiune si se salveaza citeva informatii despre acest posibil atac asupra site-ului".

Well am lasat sa treaca citeva luni si am strins toate logurile de pe site-urile unde foloseam perechea session id/IP. S-au adunat doar citeva zeci de situatii in care au existat neconcordante candidate la situatia pe care o remarcai tu. Un numar absolut infim.

Din analiza logurilor cred insa ca si din astea 99% au fost situatii de paste link care includea session id.

Revenind la celelalte comentarii era oarecum de asteptat sa primesc sfaturi aici din persepectiva hoster-ilor. Din pacate in viata de zi cu zi de web designer te confrunti cu o gramada de conturi de gazduire unde nu ai nici un control si treaba ta e doar sa scri codul cit mai bine. Cat despre https sunt perfect de acord dar nu toata lumea isi permite sau vrea certificate SSL pentru un simplu forum sau alte lucruri de acest tip.

Am mai remarcat o alta metoda foarte uzitata in ro pe diverse site-uri (unele supercunoscute): setarea unui cookie continind un id unic generat la logare. Care fiind client side deschide posibilitati mirifice de atac.

[Gupi]

...
 Cat despre https sunt perfect de acord dar nu toata lumea isi permite sau vrea certificate SSL pentru un simplu forum sau alte lucruri de acest tip.
...

CACert.org ofera certificate SSL gratuite, perfect valabile tehnic, dar nerecunoscute de browsere.
Daca le explici utilizatorilor de ce le apare mesajul de eroare si ii pui sa desccarde/instaleze root-certificatul de la CACert, poti securiza site-ul foarte bine si ieftin.

[alopia]

Am incercat si eu recent Gupi pe un site sa folosesc un certificat free de la CACert.org. Rezultatul a fost ca peste 90% din userii cu mozilla 3 nu depaseau niciodata prima pagina... cred ca incercau accesul la login probabil cu intentia de a se loga si acolo ramineau cand dadeau cu nasul de mesajul de eroare. In celelalte browsere unde warning-ul e mai putin evident abandonul a fost mult mai redus

Problema e ca nu prea apuci sa le explici ce se intimpla pentru ca majoritatea interpreteaza mesajul total aiurea si pleaca urgent.

Am atasat un screenshot sugestiv cu mozilla 3 face to face cu CACert.org. Cred ca multi confunda la repezeala mesajul cu page not found sau o problema tehnica a serverului mai ales datorita asemanarii cu alte tipuri de mesaje de eroare si mai cred ca modul in care afiseaza mozilla mesajul este total neinspirat datorita confuziei clare ce se creeaza intre utilizatorii obisnuiti.

[alopia]

  Am facut un experiment interesant mai adineauri pe messenger ... mass la prietenii cu mai putine cunostinte tehnice cu link catre https://www.CACert.org

Cateva raspunsuri aproape identice:

"Nu merge linku..."
"Cu ce browser te-ai uitat?"
"Mozilla..."

[Gupi]

@alopia, tratarea problemei se face invers:
- mai intai anunti pe site ca o sa instalezi un certificat de securitate de la CACert si prezinti urmarile posibile
- lasi o perioada site-ul sa ruleze dual (si http:// si https://, invitand utilizatori sa incerce si sa raporteze erorile)
- in aceasta perioada te asiguri ca utilizatorii instaleaza root-certificate de la CACert;
- dupa 2-3 luni fortezi doar folosirea cu https:// a site-ului; optional, poti lasa prima pagina necriptata,
in care explici din nou situatia cu certificatul de la CACert.

Desigur, ai si solutia alternativa, comerciala.
Costa cam 15-20 euro/an pentru un certificat SSL.

[LiveHosting]

De aici cumparam certificate ieftin. Poate mai sunt si altii cu preturi asa mici insa doar pe acestia ii stiu eu.

https://www.servertastic.com/VENDORS/RapidSSL/RapidSSL-Certificates-and-Renewals/p-87-121-222/

[alopia]

Costa cam 15-20 euro/an pentru un certificat SSL.

Cum spunea si LiveHosting se gasesc mult mai ieftin. Noi de exemplu vindem un GeoTrust RapidSSL cu 14 Euro in romania.

Oricum topicul s-a deturnat mult. Eram mai degraba interesat de diverse solutii pentru sesiune PHP/login INDEPENDENTE de contul de gazduire. Multa lume cred dezvolta propriul CMS care-l foloseste la o gramada de site-uri unde repet de multe ori nu ai control asupra serverului. Unde ai sau nu certificate SSL. Unde clientul vrea sau nu certificate SSL. Unde admin-ul serverului "uita" sa defineasca un director custom pt. sesiuni. In cazul meu acest CMS mai este si free open source...

Legat de CACert ce vroiam sa remarc in comentarii este ca nu reprezinta o solutie viabila atita timp cit nu e recunoscut de browserele majore si in unele cazuri iti face un deserviciu enorm. La cit timp au si ce superficiali sunt unii utilizatori repet ma indoiesc ca va sta cineva sa citeasca explicatii alambicate despre instalat root-certificate de la CACert. Poate pe un forum tehnic mai merge.

Asadar scopul topicului era mai degraba sa enumeram diverse metode in PHP de a rezolva metoda login-ului.

Eu am enumerat 2 metode, cea a perechii de SID/IP si cea a setarii unui cookie continind ID unic generat la logare. Care fiind client side clar poate fi furat. Sunt enorm de multe site-uri care folosesc metoda din urma unde e de ajuns sa clonezi cookie-ul ala si esti logat de exemplu. Metoda simpla cea din manualul PHP are si ea dezavantajele ei si depinde enorm de configurarea serverului. Cat despre furtul parolelor sau altor date senzitive de catre "man in the middle" acolo cred ca la final toti suntem expusi mai mult sau mai putin.

[alopia]

Ah si 2 link-uri despre posibile metode de atack "man in the middle" a unei conexiuni SSL. Daca sapati mai adinc casiti mii de articole:

http://www.sans.org/reading_room/whitepapers/threats/480.php
http://forums.devshed.com/security-and-cryptography-17/ssl-man-in-the-middle-attack-86557.html

[bassul]

clar discutia iese mult in afara necesitatilor unui CMS. alopia, cred ca cel mai folositor este sa lasi partea de autentificare si de sesiuni extensibila prin module, si atunci fiecare va folosi ce i se potriveste mai bine.

O aplicatie care are necesitati de securitate va folosi oricum SSL, iar o bancara sau similara va folosi oricum o alta metoda externa de autentificare, deci singurele setari de securitate folosibile din CMS ar fi ca link-urile sa suporte SSL, lungimea sesiunilor, sesiuni bazate pe IP sau nu si modul de stocare al lor.

[pitagora]

session hijacking-ul se rezolva pe site-uri bancare (sau alte site-uri criticie) punand in fiecare form sub forma de camp hidden un token unic, care daca nu este transmis corect la urmatoarea pagina automat invalideaza sesiunea.  Dezavantaje ar fi ca nu se va mai naviga cu mai multe tab-uri pe acelasi site.