Nu deschideți niciun nume de fișier pe baza unui parametru pe care trebuie să îl furnizeze utilizatorul. De exemplu, dacă ar trebui să afișați un fișier unui utilizator, ar fi tentant să utilizați un URL de tip display.php? file = algo.txt. Dacă ați făcut acest lucru, codul dvs. PHP ar include această afirmație:

cer ("/ www / awesomeapp / text-fișiere /" . $ _GET ["fișier"]) -

Acest lucru ar fi extrem de periculos, deoarece i-ai permite să folosească secvențe "../" (pentru a ajunge la directorul părinte) și ar putea include orice fișier care aparține sistemului de fișiere, de exemplu, merge la display.php? file = .. / .. / .. / .. / .. / etc / passwd.

În cel mai bun caz, acest lucru le-ar permite să adune informații despre configurația serverului dvs., care ar putea oferi informații utile pentru un alt atac diferit. În cel mai rău caz, în cazul în care funcția necesita sau include din PHP (sau alt echivalent în limba pe care o folosiți) vor fi folosite pentru a include conținutul fișierului, acestea ar putea permite executarea codului (manipularea antetului User-Agent și apoi includerea fișierului / proc / auto / mediu).

Soluția este găsirea unui alt mod de a include un fișier care nu face acest lucru în funcție de ceea ce intră utilizatorul sau prin dezinfectarea cu atenție a numelui de fișier furnizat. Verificați valabilitatea fiecărui caracter și aruncați cele care sunt interzise folosind principiul că interzicerea caracterelor care nu sunt permise, în loc să elimine pur și simplu cele care sunt periculoase. Cu alte cuvinte, nu încercați să înlocuiți caractere rău într-un șir. Creați o listă a celor care sunt admise în mod explicit și scanați lanțul pentru a vedea dacă utilizează numai acelea, eliminând cele care nu se află în lista permisă. Aceasta, pe de o parte, este mai simplă și, pe de altă parte, vă va apăra de vectorii de atac pe care nu i-ați luat în considerare.

Dezinfectează toate datele pe care le scrieți pe pagină. Codul dvs. ar putea accepta un parametru numit "persoană" (de exemplu, index.php? person = Bob) și ar conține ceva de genul:

Bună ziua,

Acest lucru ar permite unui atacator să scrie în mod arbitrar coduri jаvascript pe pagină, ceea ce înseamnă că dacă aceștia vor convinge pe cineva să urmeze un link către site, ar putea cauza declanșarea unei acțiuni care are un efect secundar (de exemplu, postați un comentariu). sau trimiteți orice altă formă). Înlocuiește orice caracter greșit cunoscut (citate, <și >) cu entitatea sa echivalentă în HTML înainte de a scrie pe o pagină.

Multe motoare șablon pot face acest lucru automat și ați putea permite doar acele caractere HTML ale unei variabile de ieșire care sunt explicit declarate sigure. Ar fi bine să luăm în considerare posibilitatea de a utiliza unul.

Dacă trebuie să permiteți un anumit HTML limitat (de exemplu, pentru a permite formatarea textului în comentarii), dezinfectați codul HTML pentru a permite etichetelor considerate sigure și cu efecte secundare minore (cum ar fi ), elimină toate celelalte și, de asemenea, aruncă orice alt atribut HTML nedorit. Încă o dată, principiul ar trebui să fie acceptați doar ceea ce este explicit permis și eliminați orice altceva (dacă acest principiu ar fi fost urmat, una dintre cele mai notorii vulnerabilități WordPress ar fi putut fi evitate, unde codul CSS al unui atribut a fost dezinfectat "stil", dar dacă numele atributului a fost scris cu majuscule, acesta a fost lăsat intact).

Nu treceți niciodată o variabilă furnizată de un utilizator unei cochilii. De exemplu, este posibil să fi scris un cod pentru a trimite un ping la un anumit server. Acest lucru ar necesita un parametru numit gazdă (de exemplu, ping.php? host = 127.0.0.1) și astfel puteți fi tentat să utilizați codul:

sistem ("ping " . $ _GET ["gazdă"]) -

`Acest lucru este extrem de periculos, deoarece prin furnizarea unui parametru "gazdă" cu o bară verticală sau cu punct și virgulă, le-ați permite utilizatorului să execute orice comandă din sistemul dvs. (de exemplu, oferind gazdei "127.0.0.1 | wget https://wikihow.com/").

Soluția este aceea de a evita utilizarea funcțiilor sistemului atunci când este posibil. Invocă programul în alt mod. Comanda pcntl_exec Este o idee mai bună în PHP. Dacă trebuie să utilizați sistem, Îndepărtează cu atenție toate datele furnizate de utilizator înainte de al trece în coajă (un exemplu pentru codul de "ping" ar verifica fiecare caracter pentru a vă asigura că este un număr, o literă sau o perioadă, și aruncați orice alt caracter care nu este unul dintre acestea).

Utilizați funcții cum ar fi eval în PHP cu foarte multă grijă. Dacă șirul include o variabilă furnizată de utilizator, atunci acesta ar permite utilizatorului să execute codul arbitrar. De fapt, aproape Nu există niciodată un motiv valid pentru a face acest lucru. Dacă îl utilizați, Codul dvs. este probabil greșit și trebuie să îl reformulați.

Verificați de unde provine trimiterea în toate cererile HTTP POST care au efecte secundare. Asigurați-vă că site-ul care face referință este site-ul dvs., în caz contrar, ar putea fi făcut de un utilizator care a făcut clic pe un buton al unui formular care aparține oricărui Un alt site web (poate că este convenabil să vă asigurați că site-ul de unde provine referința nu este necompletat sau poate nu.) Site-ul din care provine referința ar putea fi gol dacă pagina web controlată de către atacator folosește HTTP securizat și al tău nu). Un alt truc legat de utilizarea formularelor este de a genera un cod unic și de a le stoca într-o variabilă de sesiune și într-un câmp ascuns în formă. Când se trimite formularul, pur și simplu verificați dacă valoarea câmpului ascuns se potrivește cu valoarea stocată în variabila de sesiune.

Nu permiteți niciodată unei solicitări HTTP GET să aibă un efect secundar. De exemplu, nu scrieți într-o bază de date utilizând parametrii furnizați într-o solicitare GET. Amintiți-vă că o solicitare GET ar putea fi un utilizator al site-ului dvs. pe care atacatorul la păcălit să facă clic pe un link.

Verificați datele de identificare din fiecare pas Iată un exemplu:

1. Utilizatorul cere să efectueze anumite acțiuni.
2. Verificați dacă utilizatorul are permisiunea de a efectua această acțiune și a afișa o pagină care spune "A fost refuzată permisiunea" în cazul în care nu aveți.
3. Arătați o pagină care spune "Sigur vrei să faci asta?" exprimată în câmpuri ascunse ale formularului.
4. Această pagină este apoi trimisă unui cod care execută operația.

Trucul este că, dacă ați verificat permisiunea de a efectua acele operații la pasul 2, dar nu în codul la care ați trimis pagina la pasul 4, acest lucru ar conta ca utilizatorul să nu poată schimba formularul în care i-ați arătat pasul 3 (în care încrederea, în mare măsură, este deplasată greșit) sau chiar mergând direct la pasul 4.

Nu stocați parolele ca text simplu. Aceasta este o măsură de atenuare în cazul în care site-ul dvs. este compromis. Deoarece mulți utilizatori reutilizează parolele, acest lucru ar putea însemna că toate celelalte conturi online vor fi, de asemenea, compromise. Contramăsura standard pentru acest lucru este de a stoca a - hash criptografic (de exemplu, folosind algoritmul SHA-2) format de suma a câtorva octeți de date aleatoare plus parola. Acest lucru ar permite verificarea dacă o parolă furnizată de utilizator este corectă fără a fi nevoie să stocați parola în sine.

Pentru a fi mai precaut, ar fi o idee bună de a stoca, de asemenea, tipul de algoritm folosit, în cazul în care trebuie să migrați la un algoritm de hashing diferit în cazul în care sunt detectate deficiențe grave în algoritmul curent. Acest lucru sa întâmplat cu MD5 și SHA-1 și s-ar putea întâmpla și cu cei mai fiabili algoritmi de hash de astăzi.

Când intenționați să utilizați o bază de date, nu stocați informațiile de conectare direct în directorul rădăcină al aplicației. În schimb, le stoca într-un alt director, ca un prim pas, restricționează accesul la directorul utilizând setările de pe serverul web sau .htaccess- ca un al doilea pas, fișierul stocat în afara rădăcinii documentului. Apoi includeți fișierul (aplicația dvs. nu va fi afectată de permisiunile serverului web). Acest lucru va împiedica intrarea persoanelor https://tu-fabuloso-sitio.ejemplo.com/config.ini pentru a afla informațiile de conectare la baza de date (dar nu se poate opri un atacator care și-a găsit un fișier de incluziune vulnerabilitate, cum ar fi menționat în pasul 3 sau codul de exploatare a cochilie de executie menționat în pasul 4).