tipuri de autentificare

Autentificare pe server
Un browser Web stabileste o conexiune cu un server Web folosind TCP/IP. Apoi, browserul si serverul transfera date folosind HTTP. La nivel de server exista doua scheme native de autentificare Basic si Digest. Concret la accesul pe site in zona protejata, serverul Web raspunde cu o cerere 401 de autentificare, la care browserul clientului va deschide un formular cu nume utilizator si parola.

Autentificarea la nivel aplicatie
Desi o autentificare Digest pe server cu utilizarea unei sesiuni criptate SSL poate parea o solutei buna, marea majoritate a organizatiilor aleg sa utilizeze pentru site-urile lor, o shema de autentificare proprie la nivelul aplicatie Web, din urmatoarele motive:

• necesitatea de a culege mai multe informatii privind clientii, inafara numelui si parolei
• posibilitatea de delogare nu doar prin inchiderea browserului
• pentru evitarea atacurilor prin forta bruta
• necesitatea integrarii intr-o arhitectura a site-ului cu diferite nivele de acces

Pastrarea informatiilor in cookie

Atunci cand sunt asteptate informatii dintr-un cookie, pentru a avea siguranta ca aceste date nu au fost modificate, se poate folosi urmatoarea tehnica: trimiterea simultana a valorii combinate cu inca o valoare secreta, encodate md5, si compararea valorilor la primirea variabilelor.

la primirea informatiilor se confrunta valorile

aici informatia continuta in $valoare poate fi id-ul de sesiune, sau o combinatie de alte valori.
Informatia $secret e utilizata la verificare dupa primirea cookie-ului, si poate fi pastrata fie intr-o baza de date pe server.

masuri de protectie la inregistrare

Vorbind de autentificare, primul punct in care se cer masuri de protectie sunt formularele de inregistrare (login).
Cateva din masurile de securitate care se impun, sunt:

• oprirea/blocarea accesului la formularul de inregistrare, dupa un numar de incercari esuate
• utilizarea de imagini in formulare (captcha) pentru evitarea accesului prin programe robot
• blocarea contului pentru o perioada de timp la un numar de incercari esuate de inregistrare
• jurnalizarea incercarilor de inregistrare soldate cu esec
• obligarea la alegerea de parole suficient de complexe
• informarea utilizatorilor privind aceste masuri.

masuri de imbunatatire a securitatii

Desi nu sunt legate de PHP merita mentionate cateva masuri suplimentare de securitate:

-utilizarea de conexiuni securizate cu SSL; acestea furnizeaza criptarea datelor, autentificarea serverului, integritatea mesajelor si (optional) autentificarea clientului pentru o conexiune TCP/IP.
-separarea zonei de administrare si restrangerea accesului in zona respectiva lucru posibil si din aplicatie si la nivelul serverului web.

Protejarea informatiilor din baza de date

Internetul este un mediu nesigur si trebuie luata in calcul si posibilitatea ca un atacators sa treaca peste masurile de securitate si sa aiba acces la baza de date. Encriptarea informatiilor senzitive este o buna modalitate de a face fata unui astfel de atac. Datele cu continut senzitiv sunt encriptate inainte de a ajunge sa fie pastrate in tabele. Un exemplu este pastrarea parolelor. Dupa preluarea informatiei aceasta este encriptata folosind functia md5().

Pastrarea informatiilor de acces

Conexiunea la baza de date se face prin specificarea host/username/password care in mod obisnuit e trecuta intr-un fisier unic. Acest fisier urmeaza sa fie inclus in fiecare pagina program care necesita conexiune. Exista o practica de a da extensia .inc unui fisier ce urmeaza sa fie inclus. Pericolul este acela ca acest fisier sa fie accesat direct via url, ori neavand extensia .php serverul il va trimite ca text, si prin urmare codul va aparea clar in browser fiind expuse si datele de conexiune la bc.
O practica buna e aceea ca acest fisier sa fie plasat in structura de directoare intr-un loc inaccesibil (inafara structurii de directoare accesibile prin serverul web) sau sa ii fie data o extensie.php sau fiserele ce urmeaza a fi incluse sa fie marcate prin .inc.php.
Aici trebuie mentionat si faptul ca serverul web poate fi setat sa interpreteze fisierele cu extensia .ini, sau o alta extensie.
Este posibila scrierea informatiilor pentru accesul bd si in fisierul php.ini. Daca informatiile de conectare nu sunt gasite in alta parte, se apeleaza implicit cele scrise in acest fisier. E important de stiut ca oricine are acces pe server poate folosi functia ini_get() pentru a citi fisierul php.ini.

Filtrarea datelor de intrare

Prima modalitate de contracarare a injectiei SQL are un principiu simplu si anume acela de nu permite utilizatorului sa modifice sintaxa interogarii SQL. In acest scop informatiile primite de la utilizator trebuie filtrate/prelucrate.
Pentru informatia de intrare de tip sir, acest lucru se realizeaza la fel ca si in cazul ghilimelelor magice prin functia addslashes() sau functii specifice ale bazei de date my_sql_real_escape_string (recomandat).
Daca aplicatia asteapta un parametru valoare numerica pot fi folosite functiile is_numeric() pentru testare, sau poate fi schimbat tipul prin settype().
La setul de caractere trebuie adaugate si caracterele folosite ca wildcard in interogarile SQL, atunci cand se utilizeaza clauza LIKE si anume '%' si '_'.

Securitatea bazei de date

Securitatea bazei de date este un subiect vast ce urmareste urmatoarele aspecte:

• securitatea serverului
• filtrarea datelor de intrare
• pastrarea informatiilor de acces
• protejarea informatiilor din baza de date

Securitatea serverului are ca scop principal evitarea expunerii serverului de date. Atacurile exploateaza configurarile slabe.
O aplicatie nesigura poate de asemenea sa fie folosita pentru a accesa serverul de date: fie prin lipsa validarii datelor de intrare ce urmeaza a fi folosite in interogari (injectie SQL), fie prin expunerea informatiilor din baza sau a informatiilor de acces.

Register_globals off

Aplicatiile Web interactioneaza cu utilizatorii, primind informatii de la acesta sub diferite forme.

Modalitatile prin care sunt transmise variabilele sunt ilustrate in figura de mai jos:

Prin setarea in php.ini a directivei register-globals toate aceste variabile pot fi accesate direct prin nume, fara a conta cum anume au fost preluate. Aceasta modalitate de lucru a fost considerata un mare avantaj in PHP pentru usurinta lucrului.

La variantele actuale de PHP (dupa 4.2.0) setarea by default este off. In acest fel variabilele sunt izolate dupa modul in care au fost create si poate fi determinta provenienta fiecareia.

In manualul PHP se specifica: setata pe on, directiva register_globals va determina injectarea de variablile cu scop global la nivelul scritpului. Acest lucru impreuna cu faptul ca in PHP initializarea variabilelor nu este obligatorie, duce la scrierea de cod vulnerabil. A fost o decizie dificila, dar comunitatea PHP a decis dezactivarea acetei directive.

Oprirea accesarii automate a unui formular

Un formular este intotdeauna expus prin faptul ca accesarea acestuia poate fi facuta automat prin roboti. Cel mai adesea sunt vizate site-urile ce gazduiesc forumuri, bloguri cu scopul de a insera linkuri catre propriile site-uri, acest lucru avand efect in cresterea rankingului in motoarele de cautare.

In scopul evitarii unor astfel de situatii, cele mai multe site-uri apeleaza la imagnile incluse in formulare (captcha images). Principiul consta in generarea unei imagini ce contine un sir de caractere aleatoare, care nu poate fi citit de roboti, controland in acest fel accesul prin formular. Imaginea este generata prin utilizarea librariei GD, literele sunt deformate si imaginea este prelucrata pentru a fi greu de citit.

Odata cu generarea imaginii, sirul continut in imagine este encodat md5 si pastrat intr-o variabila de sesiune. Ulterior la primirea informatiilor prin formular, sirul introdus de utilizator este de asemenea encodat si comparat cu variabila pastrata pe server.

Atunci cand atacul vizeaza un formular de login, ca masura de securitate suplimetara poate fi blocat accesul pe contul in cauza pentru un anumit timp fiind de asemenea foarte important ca abuzul sa fie inregistrat.

semnarea informatiilor ascunse din formulare

Atunci cand sunt asteptate informatii dintr-un cookie, sau dintr-un camp ascuns (input - hidden) al unui formular, pentru a avea siguranta ca aceste date nu au fost modificate, se poate folosi urmatoarea tehnica: trimiterea simultana a valorii combinate cu inca o valoare secreta, encodate md5, si compararea valorilor la primirea variabilelor.

In cazul unui formular:






si verificarea:

Filtrarea informatiei

Anumite caractere prezente in informatia de intrare pot avea semnificatie ca formatare HTML si trebuie inlocuite cu echivalentul lor pentru a nu fi interpretate in browserul clientului. Vulnerabilitati cum ar fi XSS sau injectarea SQL, pot si trebuie oprite prin filtrarea informatiei. PHP pune la dispozitie doua functii in acest scop. Spre exemplu pentru encodarea informatiei ce urmeaza sa fie afisata pe ecran (forumuri, bloguri, mesaje) poate fi utilizata functia htmlentities(); aceasta converteste caracterele HTML in echivalentul, astfel incat in loc ca acestea sa fie interpretate de browser, ele sa apara in pagina HTML, impiedicand executia de cod javascript in browserul clientului.







Functia htmlentities() este identica cu htmlspecialchars() dar transforma toate caracterele HTML, pe cand htmlspecialchars() permite precizarea actiunii asupra ghilimelelor simple/duble.
Actiunea f unctiei htmlentities():





Functia strip_tags nu inlocuieste codul HTML ci 'incearca' sa stearga tagurile. Pentru ca nu face nici un fel de validare a codului HTML e posibil sa apara efecte nedorite in cazul unor taguri incomplete, prin urmare nu este recomandata.
Ghilimelele pun probleme atunci can sirul preluat urmeaza sa fie parte a unei interogari SQL. In acest caz e necesara anularea(escape) prin '\', lucru ce poate fi facut prin functii ale SGBD-ului sau din PHP.

Expresii regulare

Validarea datelor de intrare presupune uneori restrictionarea dupa un tipar: spre exemplu pentru codul numeric personal care trebuie sa aiba un anumit numar de caractere, primul poate lua doar doua valori, urmatoarele 6 contin o data calendaristica.
Pentru verificarea formatului informatiilor de intrare, PHP pune la dispozitie doua seturi de functii ce permit lucrul cu expresii regulare: ereg - ofera functionalitate de baza, in genul traditional al comenzii egrep din UNIX - si setul de functii preg- valabile cu instalarea librariei PCRE si care utilizeaza sintaxa Perl.

exemple:






Utilizarea expresiilor regulare ofera o modalitate comoda de scriere a codului, permitand inlocuirea mai multor linii cu o simpla functie, dar cere insa putin exercitiu si atentie.
Nu exista un tipar unic pentru o restrictionare. Decizia pentru o expresie sau alta trebuie facuta cantarind intre exact si practic, pentru ca utilizarea acestora poate avea efecte in performanta programului.
Exista si programe de asistenta in consturirea expresiilor, un exemplu consacrat fiind RegexBuddy.
Cum expresiile regulare sunt subiect de discutii nu doar in PHP, intrebarea logica este daca exista cumva expresii 'la cheie' spre exemplu pentru validarea unei adrese de email. Raspunsul este nu, nu exista, desi poate fi gasit pe internet un standard scris in 1982 - RFC 822 - care accepta orice adresa valida, e inclus si in RegexBuddy si are mai bine de 6000 de caractere.

Utilizarea variabilei $PHP_SELF

Cand vorbim de formulare ne gandim in primul rand la transmiterea si validarea variabilelor. In exempul urmator nici macar nu e necesara transmiterea valorilor via formular ci pur si simplu afisarea acestuia.

$PHP_SELF este o variabila predefinita ce are ca valoare numele scriptului curent cu tot cu calea sa pornind din root plus informatiile transmise odata cu acesta. Daca spre exemplu scriptul curent ce se executa este http ://xyz.com/dir/script.php, $_SERVER[‘$PHP_SELF’] returneaza /dir/script.php. Daca in plus mai avem si informatii in plus acestea vor fi si ele retinute http ://xyz.com/script.php/plus_info

O practica obisnuita este aceea de a grupa in acelasi fisier mai multe module functionale - spre exemplu: prezentarea unui formular, validarea datelor preluate si procesarea informatiilor. In acest caz formularul face trimitere in acelasi fisier in care e definit. Din motive de portabilitate in acest caz informatiile sunt trimise via formular prin utilizarea variabilei $PHP_SELF:


Ce se intampla daca din browser schimbam adresa cu


Rezultatul e ca la afisarea formularului este executat automat si codul javascript astfel fiind posibil un atac XSS.

Prin urmare $PHP_SELF implica aceleasi riscuri ca orice alta variabila afisata in browser.

Solutia este filtrarea prin htmlentities($_SERVER[‘PHP_SELF’]) sau utilizarea variabilei $_SERVER['SCRIPT_NAME'] ce pasteaza doar numele fisierului.

PHP dog

From the PHP angle, in a way, Scotch affected a bunch of parts in PHP - since she was the only one I could consult with when I developed certain parts of the language, in the middle of the night many years ago... She was definitely a PHP dog. Zeev Suraski

Si povestea continua: adaugati "?=PHPE9568F36-D428-11d2-A769-00AA001ACF42" in continuarea unei adrese URL ce indica o pagina php si ....
in functie de versiunea php avem:

• http://savoirprint.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
• http://www.zend.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
• http://www.php.net/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
• http://rubyonrails.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
  

schimbam si avem si ceva phpinfo()

• http://www.php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
  

povestea toata o gasiti aici http://www.0php.com/php_easter_egg.php