Vă mulțumim pentru susținere

Securitatea sesiunii PHP

Care sunt câteva recomandări pentru menținerea securității sesiunii responsabile cu PHP? Există informații pe tot parcursul paginii web și este timpul ca totul să aterizeze într-un singur loc!

0
adăugat editat

14 răspunsuri

Iată ce cred că trebuie să faceți

Creați un blog nou pe mai multe site-uri pe noul domeniu "master" cu WP 3.0

Creați un nou blog gol adresa url h..p: //www.mysite.com/oldblogname

Exportați site-ul vechi și introduceți inport în noul blog

Trebuie să verificați dacă toate imaginile sunt copiate pe noul site OK, altfel păstrați blogul vechi în loc pentru a servi imaginile

Și veți avea un nou blog frumos

Pentru a păstra ordinea, ar trebui să introduceți o redirecționare 304 de la vechea adresă URL la noua adresă URL

Ceva de genul asta ar trebui (nu testat) să se transforme într-un fișier .htacces din vechiul dosar blog

RewriteEngine on
#
RewriteRule ^(.*)$ http://www.websiteA.com/oldblogname/ $1 [R=301,L]
1
adăugat

Cred că una dintre problemele majore (care este abordată în PHP 6) este register_globals. În prezent, una dintre metodele standard folosite pentru a evita register_globals este utilizarea codurilor $ REQUEST , $ _GET sau $ _ POST matrice.

Modul "corect" de a face acest lucru (din 5.2, deși este un mic buggy acolo, dar stabil din 6, care vine în curând) este prin filtre .

Deci, în loc de:

$username = $_POST["username"];

ați face:

$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);

sau chiar doar:

$username = filter_input(INPUT_POST, 'username');
0
adăugat
Sunt de acord, acest lucru nu răspunde complet la întrebare, dar este cu siguranță o PARTă a răspunsului la întrebare. Din nou, acest lucru scoate în evidență un punct de glont în răspunsul acceptat, "Nu utilizați registrele globale". Acest lucru spune ce să facă în schimb.
adăugat autor cmcculloh
Într-adevăr? Atunci de ce în răspunsul acceptat menționează că nu utilizează registrele globale? Nu ar fi, în ceea ce-i privește pe cei mai mulți dezvoltatori care se ocupă de proiectare, înregistrarea globalelor și formarea manevrabilității variabilelor se încadrează sub umbrela "sesiunilor", chiar dacă aceasta nu face parte din punct de vedere tehnic din obiectul "sesiune"?
adăugat autor cmcculloh
Aceasta nu are nicio legătură cu întrebarea.
adăugat autor The Pixel Developer
-1 Aceasta nu răspunde la întrebare.
adăugat autor Tomas

Un ghid este să sunați session_regenerate_id de fiecare dată când se schimbă nivelul de securitate al unei sesiuni. Acest lucru ajută la prevenirea deturnării sesiunii.

0
adăugat

Aș verifica atât agentul IP, cât și agentul de utilizator pentru a vedea dacă se schimbă

if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
    //Something fishy is going on here?
}
0
adăugat
@scotts Sunt de acord cu partea IP, dar pentru upgrade-ul browserului, ați seta sesiunea când vă logați, așa că nu văd cum ar face upgrade browser-ul fără a crea o nouă sesiune după ce se autentifică din nou.
adăugat autor JasonDavis
@jasondavis Există un browser numit Chrome.
adăugat autor Pacerier
Cred că user_agent se poate schimba de asemenea atunci când comută între modul compatibil în IE8. De asemenea, este foarte ușor să falsificați.
adăugat autor Heather Herbert
IP se poate schimba în mod legitim, în cazul în care utilizatorul se află în spatele unei ferme proxy cu încărcare echilibrată.
adăugat autor Kornel
Da, dar despre utilizatorii care au avut static IP eq GSM si se schimba la fiecare jumatate de ora. Deci, IP stocate în Session + nume de gazdă, când IP! = REMOTE_ADDR verifica gazdă și a compara hostanmes eq. 12.12.12.holand.nl-> când este holand.nl == adevărat. Dar unii gazde aveau numele de gazdă bazat pe IP Apoi trebuie comparat masca 88.99.XX.XX
adăugat autor user956584
Și user_agent se poate schimba de fiecare dată când un utilizator upgrada browserul.
adăugat autor scotts

Există câteva lucruri de făcut pentru a vă menține sesiunea sigură:

  1. Utilizați SSL atunci când autentificați utilizatorii sau efectuați operații sensibile.
  2. Regenerați ID-ul sesiunii ori de câte ori se modifică nivelul de securitate (cum ar fi conectarea). Puteți chiar să vă regenerați fiecare solicitare, dacă doriți.
  3. Setați timpul de ședință
  4. Nu utilizați globale înregistrate
  5. Stocați detaliile de autentificare pe server. Adică nu trimiteți detalii despre numele de utilizator în cookie.
  6. Verificați $ _ SERVER ['HTTP_USER_AGENT'] . Acest lucru adaugă o barieră mică la deturnarea sesiunii. De asemenea, puteți verifica adresa IP. Dar acest lucru cauzează probleme pentru utilizatorii care au o adresă IP în schimbare datorită echilibrării încărcării pe mai multe conexiuni la Internet etc. (ceea ce este cazul în mediul nostru de lucru).
  7. Blocați accesul la sesiunile din sistemul de fișiere sau folosiți manipularea personalizată a sesiunilor
  8. Pentru operațiile sensibile, luați în considerare necesitatea ca utilizatorii conectați să furnizeze din nou detaliile de autentificare
0
adăugat
Dacă regenerați id-ul sesiunii, atunci id-ul de sesiune pe care un atacator îl fură pe o cerere non-HTTPS este inutil.
adăugat autor grom
@ Rook, poate fi o barieră trivială (atacatorul poate capta agentul utilizator al victimei folosind site-ul propriu) și se bazează pe securitate prin obscuritate, dar este încă o barieră suplimentară. Dacă HTTP User-Agent urma să se schimbe în timpul utilizării sesiunii, ar fi extrem de suspicios și, cel mai probabil, de un atac. N-am spus niciodată că o poți folosi singură. Dacă o combinați cu celelalte tehnici, aveți un site mult mai sigur.
adăugat autor grom
@ The Rook, da Agentul utilizator poate fi falsificat. Este doar o barieră mică. Și ce vrei să spui prin faptul că cookie-ul nu poate fi scos pe http. Da, poate fi furat. http este text simplu.
adăugat autor grom
@grom Chrome nu schimba automat agentul utilizator atunci când actualizează în tăcere în fundal în timp ce utilizatorul utilizează browserul? În acest fel, blocați utilizatorii reali pentru niciun motiv real. Nu uitați că utilizarea îmbunătățită este și o siguranță sporită.
adăugat autor Pacerier
@grom cred că ei cum ar fi punerea unei bucăți de bandă scotch pe ușa ta și spunând că va împiedica oamenii de a sparge in.
adăugat autor rook
@că singura barieră este cea din mintea ta, nu oprești nici un atac.
adăugat autor rook
La naiba vreau să vă pot da un alt -1 pentru utilizarea ssl. În nici un moment, cookie-ul nu poate fi scos pe http, care este prezentat în OWASP A3.
adăugat autor rook
-1 Agentul utilizator este banal pentru spoof. Ce descrieți codul deșeurilor și nu este un sistem de securitate.
adăugat autor rook
Utilizarea SSL numai pentru anumite operațiuni nu este suficientă, cu excepția cazului în care aveți sesiuni separate pentru trafic criptat și necriptat. Dacă utilizați o singură sesiune pe HTTPS și HTTP, atacatorul o va fura pe prima cerere non-HTTPS.
adăugat autor Kornel
Nu regenerați sesiunea la fiecare solicitare. Este susceptibil la condițiile de cursă și vei pierde sesiunea mai devreme sau mai târziu.
adăugat autor Kornel
Sunt de acord cu porneL. De asemenea, pentru numărul 6, dacă un atacator are codul de sesiune, nu ar avea acces la agentul dvs. de utilizator?
adăugat autor Chad
Dacă verificați agentul de utilizator, veți bloca toate solicitările de la utilizatorii IE8 atunci când acestea comută modul de compatibilitate. Vedeți distracția pe care am urmărit-o în codul meu: serverfault.com/questions/200018/ http-302-problemă-la-IE7 . Duc la verificarea agentului de utilizator, pentru că este un lucru banal pentru spoof, așa cum au spus alții.
adăugat autor bestattendance

Acest lucru este destul de banal și evident, dar nu uitați să session_destroy după fiecare utilizare. Acest lucru poate fi dificil de implementat dacă utilizatorul nu se deconectează în mod explicit, deci un timer poate fi setat pentru a face acest lucru.

Aici este un bun tutorial pe setTimer () și clarTimer ().

0
adăugat

Folosirea adresei IP nu este cu adevărat cea mai bună idee din experiența mea. De exemplu; biroul meu are două adrese IP care se utilizează în funcție de încărcare și ne confruntăm în mod constant cu probleme în utilizarea adreselor IP.

În schimb, am optat pentru stocarea sesiunilor într-o bază de date separată pentru domeniile de pe serverele mele. În acest fel, nimeni din sistemul de fișiere nu are acces la informațiile despre sesiuni. Acest lucru a fost foarte util cu phpBB înainte de 3.0 (de când am fixat acest lucru), dar este încă o idee bună cred.

0
adăugat

Cei doi (sau mai mulți) centi:

  • Încredere nimănui
  • Filtru de intrare, ieșire de ieșire (cookie, date de sesiune sunt de intrare prea)
  • Evitați XSS (păstrați bine formatul HTML, aruncați o privire la PHPTAL sau HTMLPurifier )
  • Apărare în profunzime
  • Nu expuneți date

Există o carte mică dar bună despre acest subiect: Essential PHP Security by Chris Shiflett .

Essential PHP Security http://shiflett.org/images/essential-php-security-small.png

Pe pagina de pornire a cărții veți găsi câteva exemple de cod interesante și exemple de capitole.

You may use technique mentioned above (IP & UserAgent), described here: How to avoid identity theft

0
adăugat
+1 pentru prevenirea XSS. Fără acest lucru este imposibil să se protejeze împotriva CSRF, și astfel, cineva poate "conduce" sesiunea fără a obține chiar ID-ul sesiunii.
adăugat autor Kornel

Dacă utilizați session_set_save_handler () vă poate seta propriul handler de sesiuni. De exemplu, puteți să vă stocați sesiunile în baza de date. Consultați comentariile php.net pentru exemplele unui handler de sesiuni de bază de date.

Sesiunile DB sunt, de asemenea, bune dacă aveți mai multe servere altfel, dacă utilizați sesiuni bazate pe fișiere, va trebui să vă asigurați că fiecare server web avea acces la același sistem de fișiere pentru citirea / scrierea sesiunilor.

0
adăugat

This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.

0
adăugat

php.ini

session.cookie_httponly = 1
change session name from default PHPSESSID

eq Apache adăugați antetul:

X-XSS-Protection    1
0
adăugat
Rețineți că X-XSS-Protection nu este deloc util. De fapt, algoritmul de protecție în sine ar putea fi exploatat, făcându-l mai rău decât înainte.
adăugat autor Pacerier
Poti elabora?
adăugat autor domino
httpd.conf -> Antet set X-XSS-Protection "1" </ FilesMatch>
adăugat autor user956584

Principala problemă cu sesiunile PHP și securitatea (în afară de deturnarea sesiunii) vine cu mediul în care vă aflați. În mod implicit, PHP stochează datele sesiunii într-un fișier din directorul temporar al sistemului de operare. Fără nici o gândire sau planificare specială, acesta este un director lizibil în lume, astfel încât toate informațiile despre sesiune să fie publice pentru oricine care are acces la server.

În ceea ce privește menținerea sesiunilor pe mai multe servere. În acel moment, ar fi mai bine să comutați PHP la sesiunile manipulate de utilizatori, unde apelurile pe care le oferă funcțiile oferite de CRUD (crearea, citirea, actualizarea, ștergerea) datelor din sesiune. În acel moment, puteți stoca informațiile despre sesiuni într-o bază de date sau o soluție de tip memcache, astfel încât toate serverele de aplicații să aibă acces la date.

Depozitarea propriilor sesiuni ar putea fi de asemenea avantajoasă dacă vă aflați pe un server partajat, deoarece vă va permite să-l stocați în baza de date pe care de multe ori aveți mai mult control asupra sistemului de fișiere.

0
adăugat

Trebuie să fiți sigur că datele sesiunii sunt sigure. Privind la php.ini sau folosind phpinfo () vă puteți găsi setările de sesiune. _session.save_path_ vă spune unde sunt salvate.

Verificați permisiunea dosarului și a părinților săi. Nu ar trebui să fie publică (/ tmp) sau să fie accesibilă de alte site-uri de pe serverul dvs. partajat.

Presupunând că totuși doriți să utilizați sesiunea php, puteți seta php să folosească un alt folder modificând _session.save_path_ sau salvați datele în baza de date schimbând _session.save_handler_.

S-ar putea să puteți seta _session.save_path_ în php.ini (unii furnizori o permit) sau pentru apache + mod_php, într-un fișier .htaccess din dosarul rădăcină al site-ului: php_value session.save_path "/home/example.com/html/session" . De asemenea, îl puteți seta la ora de rulare cu _session_save_path () _.

Consultați tutorialul lui Chris Shiflett sau Zend_Session_SaveHandler_DbTable pentru a seta și un handler de sesiuni alternativ.

0
adăugat

Mi-am stabilit sesiunile ca asta -

pe pagina de conectare:

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);

(fraza definită pe o pagină configurată)

apoi pe antetul care este pe tot restul site-ului:

session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
    header('Location: http://website login page/');
    exit();     
}
0
adăugat