|
Securitatea in phprel este un standard. O serie de masuri au fost luate pentru a imbunatati securitatea aplicatiilor scrise cu phprel in fata atacurilor de diverse tipuri. Bineinteles, codul scris de programator determina in mare parte cat de sigur este un site, dar phprel nu inchide ochii si asteapta sa rezolvati dumneavoastra totul, ci participa activ la acest proces.
De ce anume se ocupa phprel? In primul rand, majoritatea query-urilor construite intr-o aplicatie phprel vor fi create si executate de nucleul phprel, dumneavoastra furnizand doar anumite indicatii. Fiecare query in parte este analizat si protejat impotriva atacurilor de tip sql injection, dumneavoastra ramanandu-va doar sarcina protejarii query-urilor sau partilor de query pe care decideti sa le scrieti fara ajutorul phprel. Dar nici aici nu sunteti singur: phprel va pune la dispozitie metode rapide de escaping, cu ajutorul caruia veti putea scrie query-uri sigure foarte repede.
O alta amenintare des intalnita este trimiterea de formulare neautorizate care simuleaza formularele reale de pe site dar incearca sa gaseasca o bresa in codul site-ului pentru a obtine acces la baza de date. Cu phprel, formularele primesc un cod de identificare si aplicatia isi va da seama imediat care formular este autorizat si care nu, ignorandu-le pe cele provenite din alte surse. Mai mult, validarile realizate automat de asistentul phprel cu javascript sunt verificate din nou inainte de introducerea datelor in baza de date, pentru a fi conforme cu validarea realizata la client si a impiedica o eventuala tentativa de a trimite date false folosind un formular creat fraudulos. Aceasta revalidare precum si procesul de autentificare al formularelor au loc complet automat, fara nici o linie de cod necesara din partea dumneavoastra.
Cu phprel, sesiunea php este de asemenea protejata impotriva atacurilor de tip session hijacking. Datele din sesiune sunt stocate folosind o cheie criptata valabila doar pentru identitatea utilizatorului curent. Daca cineva preia codul de sesiune php si incearca sa acceseze datele stocate sau sa se autentifice drept posesorul sesiunii, informatiile necesare nu vor fi valabile deoarece cheia de acces calculata pentru noul utilizator nu va corespunde cheii de acces calculate pentru posesorul real al sesiunii.
De asemenea, transferul informatiilor prin AJAX este criptat. Eventualele noduri de pe traseu sau cei care incearca sa intervina pentru a citi informatiile nu vor putea accesa datele trimise. La afisarea paginii initiale se trimite clientului o cheie de criptare, cunoscuta doar de server. Datele sunt codificate folosind cheia respectiva, si sunt decodificate la primirea cererii asincrone, asigurand un transfer mai sigur al informatiilor de la client la server.
In plus, phprel introduce o tehnologie inovativa de a valida url-urile cu risc ridicat (cele care se ocupa de introducerea sau stergerea datelor din baza de date). O pagina de editare sau un url de stergere bazat pe trimiterea unui id al liniei tinta poate fi de multe ori exploatata pentru a accesa sau sterge alte linii din tabel, din cauza faptului ca este dificil de tinut evidenta tuturor paginilor de acest tip si de asigurat codul impotriva schimbarii frauduloase a id-ului tinta. Cu phprel, aceasta grija nu mai exista: url-urile riscante sunt cautate si gasite automat de phprel, iar fiecaruia i se adauga un cod de validare unic pentru respectivul url. La accesarea url-ului, nucleul phprel valideaza automat codul recalculand un nou cod pentru url-ul curent: daca cele doua coduri nu se potrivesc sau codul de validare este necesar dar lipseste, va sterge dintre parametrii GET acei parametrii cu risc ridicat, incarcand url-ul fara risc. Rezultatul: construiti pagini de editare sau stergere, precum si de acces la informatii sensibile fara grija ca cineva ar putea modifica neautorizat url-urile pentru a accesa sau sterge informatii importante.
Cheile de securitate folosite in diferitele situatii de phprel pentru a proteja continutul aplicatiei dumneavoastra sunt emise automat de phprel si se bazeaza pe siruri generate aleator, cu un termen fix de expirare. Astfel, chiar daca cineva reuseste sa duplice o cheie de acces in viitor, respectiva cheie nu va mai putea fi folosita. Mai mult, nu exista un algoritm fix de calcul al cheii care ar putea fi duplicat si folosit, fiecare cheie contine in generarea ei un factor aleator.
Nu in ultimul rand, aplicatiile de tip "backend" pot fi securizate prin politici de acces pe baza grupurilor de utilizatori. Anumite pagini, operatiuni de editare sau stergere dintr-o pagina, sau anumite informatii din tabelele MySQL pot fi protejate prin politici de restrictionare a accesului, autorizandu-se accesul doar din partea anumitor grupuri de utilizatori predefinite. Fiecare utilizator poate apartine unuia sau mai multor grupuri, poate avea acces la anumite pagini, iar pe acele pagini poate avea acces doar de vizualizare, sau doar de vizualizare sau editare, sau complet (inclusiv stergere). In plus, anumite linii din anumite tabele pot fi protejate, accesul unui utilizator fiind limitat la liniile detinute de el, liniile detinute de grupurile sale sau acces complet. Modificarea query-urilor pentru a respecta drepturile de acces precum si modificarea continutului paginii pentru a sterge anumite linkuri sau butoane care contravin drepturilor utilizatorului curent este realizata automat de catre nucleul phprel, iar dumneavoastra veti putea crea o aplicatie sigura, structurata pe nivele de acces, foarte rapid si foarte usor.
|
