Moet nooit `n lêernaam oopmaak op grond van `n parameter wat die gebruiker moet verskaf nie. As jy byvoorbeeld `n lêer aan `n gebruiker moes wys, sou dit `n versoeking wees om `n URL van tipe te gebruik display.php? file = algo.txt. As jy dit gedoen het, sal jou PHP-kode hierdie stelling insluit:

vereis ("/ www / awesomeapp / text-files /" . $ _GET ["lêer"]) -

Dit sal uiters gevaarlik wees, aangesien jy hom sal toelaat om sekwense van te gebruik "../" (om na die ouergids te gaan) en kan enige lêer wat aan die lêerstelsel behoort, insluit, byvoorbeeld, na display.php? file = .. / .. / .. / .. / .. / etc / passwd.

Op sy beste sal dit hulle toelaat om inligting oor u bediener se opset te versamel, wat nuttige inligting vir `n ander aanval kan verskaf. In die ergste geval, as die funksie vereis of sluit van PHP (of `n ander ekwivalent in die taal wat jy gebruik) sal gebruik word om die inhoud van die lêer in te sluit. Dit kan die uitvoering van kode toelaat (die kopie van die gebruiker-agent heen en dan die lêer insluit / proc / self / omgewings).

Die oplossing hiervoor is om `n ander manier te vind om `n lêer in te sluit wat dit nie doen nie, gegrond op wat die gebruiker betree, of deur die verskafde lêer versigtig te ontsmet. Kontroleer die geldigheid van elke karakter en gooi diegene wat verbode is Gebruik die beginsel dat karakters wat nie toegelaat word nie, verbied word, in plaas daarvan om bloot diegene wat gevaarlik is, uit te skakel. Met ander woorde, probeer nie om slegte karakters in `n tou te vervang nie. Skep `n lys van diegene wat uitdruklik toegelaat word en scan die ketting om te sien of dit net diegene gebruik wat diegene wat nie in die toegelate lys is, uitskakel nie. Dit is aan die een kant eenvoudiger, en aan die ander kant sal dit jou verdedig teen aanvalvektore wat jy nie in ag geneem het nie.

Desinfecteer enige data wat jy op die bladsy skryf. Jou kode kan `n parameter genaamd aanvaar "persoon" (byvoorbeeld, index.php? persoon = Bob) en dit sal so iets bevat:

hallo,

Dit sal toelaat dat `n aanvaller te arbitrêre jаvascript-kode op die bladsy, wat beteken dat as jy iemand `n skakel na die webwerf volg oortuig, kan maak `n aksie wat `n newe-effek het uitlok skryf (bv kommentaar of stuur enige ander vorm). Vervang enige slegte bekende karakter (aanhalings, <, en >) met sy ekwivalente entiteit in HTML voordat dit op `n bladsy geskryf word.

Baie sjabloon-enjins kan dit outomaties doen en jy kan slegs die HTML-karakters van `n uitvoerveranderlike toelaat wat eksplisiet veilig verklaar is. Dit sal goed wees om die moontlikheid te oorweeg om een ​​te gebruik.

As jy `n beperkte HTML moet toelaat (byvoorbeeld om die teks in die opmerkings te formatteer), ontsmettend daardie HTML om etikette wat as veilig beskou word, toe te laat en het klein newe-effekte (soos ), wegdoen alle ander, en gooi ook enige ander ongewenste HTML-kenmerk af. Weereens moet die beginsel wees aanvaar slegs wat eksplisiet toegelaat word en verwyder alles anders (as hierdie beginsel gevolg is, kan een van die mees berugte WordPress-kwesbaarhede vermy word, waar die CSS-kode van `n kenmerk ontsmet is "styl", maar as die naam van die attribuut in hoofletters geskryf is, was dit ongeskonde).

Moet nooit `n veranderlike deur `n gebruiker aan `n dop voorsien nie. Byvoorbeeld, jy het dalk `n kode geskryf om `n ping na `n bepaalde bediener te stuur. Dit sal `n parameter genoem gasheer (byvoorbeeld, ping.php? host = 127.0.0.1) en op hierdie manier kan jy versoek word om die kode te gebruik:

stelsel ("ping " . $ _GET ["gasheer"]) -

`Dit is uiters gevaarlik, want deur `n parameter te verskaf "gasheer" Met `n vertikale balk of semikolon, sal u die gebruiker toelaat om enige opdrag op u stelsel uit te voer (byvoorbeeld deur die gasheer te gee "127.0.0.1 | wget https://wikihow.com/").

Die oplossing hiervoor is om die stelsel funksies te vermy wanneer dit moontlik is. Oproep die eksterne program op `n ander manier. Die opdrag pcntl_exec Dit is `n beter idee in PHP. As jy moet gebruik stelsel, Dit versigtig ontsmet enige data wat deur die gebruiker verskaf word voordat dit na die dop oorgedra word (`n voorbeeld vir die kode van "ping" sal elke karakter nagaan om seker te maak dit is `n nommer, `n brief of `n tydperk, en gooi enige ander karakter wat nie een hiervan is nie).

Gebruik funksies soos eval in PHP met baie, maar baie omgee. As die string `n veranderlike bevat wat deur die gebruiker verskaf word, sal dit die gebruiker toelaat om arbitrêre kode uit te voer. Trouens, byna Daar is nooit `n geldige rede om dit te doen nie. As jy dit gebruik, Jou kode is waarskynlik verkeerd en jy moet dit herformuleer.

Kyk waar die verwysing vandaan kom in alle HTTP POST versoeke wat newe-effekte het. Maak seker dat die webwerf wat die verwysing maak, jou webwerf is. Andersins kon dit gemaak word deur `n gebruiker wat op `n knoppie gekliek het van `n vorm wat aan enige Nog `n webwerf (miskien is dit gerieflik om seker te maak dat die webwerf waar die verwysing vandaan kom nie leeg is of dalk nie.) Die webwerf waar die verwysing vandaan kom, kan leeg wees as die webblad wat deur die aanvaller beheer word, veilige HTTP gebruik. en joune nie). Nog `n truuk wat verband hou met die gebruik van vorms is om `n unieke kode te genereer en dit in `n sessie veranderlike en in `n verborge veld in die vorm te stoor. Wanneer die vorm ingedien word, maak seker dat die waarde van die verborge veld ooreenstem met die waarde wat in die sessie veranderlike gestoor is.

Moet nooit `n HTTP-GET-versoek toelaat om `n newe-effek te hê nie. Byvoorbeeld, skryf nooit aan `n databasis deur gebruik te maak van parameters wat in `n GET-versoek voorsien word nie. Onthou dat `n GET-versoek `n gebruiker van jou werf kan wees wat die aanvaller gelok het om op `n skakel te klik.

Verifieer geloofsbriewe in elke stap Hier is `n voorbeeld:

1. Die gebruiker versoek om sekere aksie uit te voer.
2. Maak seker dat die gebruiker toestemming het om hierdie aksie uit te voer en wys `n bladsy wat sê "Toegekende toestemming geweier" in die geval dat jy dit nie het nie.
3. Jy wys `n bladsy wat sê "Is jy seker jy wil dit doen?" uitgedruk in verborge velde van die vorm.
4. Die bladsy word dan gestuur na `n kode wat die operasie uitvoer.

Die truuk is dat as u slegs die toestemming om daardie bedrywighede in stap 2 te verifieer, maar nie in die kode waarna u die bladsy in stap 4 gestuur het nie, dit sal tel sodat die gebruiker nie die vorm kon verander wat u hom gewys het nie stap 3 (waarin vertroue in `n groot mate misplaas is), of gaan selfs direk na stap 4.

Moenie wagwoorde as gewone teks stoor nie. Dit is `n versagtende maatreël in die geval dat u webwerf in gevaar gestel word. Omdat baie gebruikers hul wagwoorde hergebruik, kan dit beteken dat al hul ander aanlynrekeninge ook in gevaar sal tree. Die standaard teenmaatreël hiervoor is om `n Kriptografiese hash (byvoorbeeld met behulp van die SHA-2-algoritme) gevorm deur die som van `n paar grepe willekeurige data plus die wagwoord. Dit sal toelaat om te verifieer of `n wagwoord wat deur die gebruiker verskaf is, korrek is sonder om die wagwoord self te stoor.

Om meer versigtig te wees, sou dit `n goeie idee om die tipe algoritme gebruik, as jy nodig het om te migreer na `n ander hash algoritme in die geval van `n ernstige swakhede ontdek in die huidige algoritme te slaan nie. Dit het gebeur met MD5 en SHA-1, en dit kan ook vandag met die mees betroubare hash-algoritmes gebeur.

Wanneer u `n databasis gaan gebruik, moet u intekeninginligting direk in die hoofmap van u aansoek stoor. In plaas daarvan, stoor dit in `n ander gids en, as `n eerste stap, beperk toegang tot die gids deur gebruik te maak van die instellings van jou webbediener of .htaccess - as `n tweede maatreël, stoor die lêer buite die wortel van die dokument. Sluit dan die lêer in (jou aansoek sal nie geraak word deur die toestemming van die webbediener nie). Dit sal voorkom dat mense inkom https://tu-fabuloso-sitio.ejemplo.com/config.ini om jou databasis se aanmeldinligting uit te vind (maar jy sal nie `n aanvaller kan stop wat `n lêer insluiting kwesbaarheid gekry het nie, soos die een wat in stap 3 genoem word, of `n dopkode eksekusie gebruik soos dit word in stap 4 genoem).