Pagerinkite mūsų programų saugumą naudodami PHP

PHP atsirado kaip universali kalba, leidžianti manipuliuoti duomenimis, įvestais naudojant formą HTMLŽinoma, jos konstitucijoje yra daugiau įrankių ir galimybių nei tik tai.
Dėl universalumo ir lengvo naudojimo tai yra viena iš plačiausiai naudojamų kalbų visame pasaulyje žiniatinklio projektams, pradedant nuo paprastų kontaktinių formų ir pradedant nuo didelių programų, pvz. Facebook.
Universalumo ir naudojimo paprastumo problema yra ta, kad kūrėjas nėra priverstas rašyti saugų kodą, tačiau su labai nesaugiomis funkcijomis kodas veiks puikiai, ir būtent čia kyla problemos.
Žiniatinklio programų saugumas yra tai, ko neturite nuo pat pradžių PHPTačiau tai nepadaro jos nesaugia kalba, nes saugumas atitinka metodų ir darbo stilių rinkinį, kurį programuotojas turi žinoti, kad galėtų juos pritaikyti savo scenarijuose.
KarkasaiTiesa, kad su išvaizda rėmus Pagal numatytuosius nustatymus įtraukta daug saugos funkcijų, tačiau ne kiekvienas kūrėjas naudojo sistema senesnėse programose ir gali būti, kad kai kurioms funkcijoms naudoti a sistema būti pertekliumi.
Raktai, skirti mūsų programų saugumui pasiekti PHP Tai yra: kontroliuoti ir patikslinti duomenis, kuriuos vartotojas įveda į formą, patikrinti užklausų kilmę HTTP kurią mūsų programa gauna, ir pagaliau išvengti tiesioginio nurodymų vykdymo naudojant formas.
Yra programavimo taisyklė ir ji yra universali, tai yra, ji taikoma ne tik PHPTai yra tai, kad visi duomenys, kurie nėra sukurti programoje, yra potencialiai kenkėjiški, tai reiškia, kad jei tai nėra kažkas, ką mes sukūrėme, mes negalime pasitikėti.
Šis principas taikomas formų reikšmėms, failams, Duomenų bazės, todėl pirmasis žingsnis siekiant pagerinti mūsų saugumą yra filtruoti duomenis, jei turime sąveikauti su šiais elementais.
Išvardysime keletą geriausių praktikų, kurias galime taikyti filtruodami į mūsų formą įvestus duomenis:
Naudokite leidžiamų verčių sąrašusSu šia praktika mes žinome, kad jei duomenys, kurie pateikiami per formą, neatitinka mūsų leidžiamų ir saugių verčių sąrašo, jie neturėtų būti apdorojami, šiuo metu vartotojui turi būti išsiųstas pranešimas, kad jis ištaisytų savo duomenis.
Niekada netaisykite neteisingų duomenųGali atrodyti viliojanti sukurti labai protingą sistemą, kuri ištaisytų duomenis, neatitikimus, tačiau ilgainiui tai gali sukelti problemų ir pažeidžiamumų, todėl, jei aptiksime kažką nereguliaraus, neturėtume to apdoroti.
Naudokite pavadinimo susitarimąNaudodamiesi šia praktika, galime atskirti saugius duomenis ir vertes nuo tų duomenų ir verčių, kuriuos įvedė vartotojas, ir taip programavimo metu sustiprinsime pirmųjų naudojimą apdorojimui.
Yra dviejų tipų filtrai kad mes galime tai padaryti, pirmasis yra apie mums žinomas vertybes, o antrasis - apie tas, kurių mes nežinome.
The Pirmas Tai padaryti labai paprasta, mums tereikia atlikti įprastas procedūras su žinomų elementų sąrašais ir palyginti su tuo, tačiau tai yra sudėtinga ir sunku atlikti didesnėse programose. The antra Tai reiškia, kad reikia sukurti tvarką, kuri įvertintų vertės struktūrą ir, jei ji atitinka tą, kurią laikome saugia, leidžiame ją apdoroti, nes priešingu atveju išmetame klaidą, kuri yra dinamiško pobūdžio, todėl rekomenduojamas formatas.
Toliau pažiūrėkime pirmojo tipo filtravimo kodo pavyzdį:
Šiame kode pamatysime, kaip sukuriame formą, kurioje yra elementas pasirinkti Kad vartotojas galėtų pasirinkti spalvą, nes vartotojas neturi rašyti duomenų, kad galėtų tiesiogiai įvesti, galime patekti į klaidą, kai nepatvirtiname informacijos, tačiau tai reiškia tik tai, kad turime saugumo spragą, nes naudojant formą tuos pačius pavadinimus galime gauti potencialiai pavojingos informacijos.
Štai kodėl, kai formos vertė yra išsiųsta POST, mūsų scenarijus įvertina galimas vertes ir, jei yra kuri nors iš tikėtinų, perduodame ją savo saugių vertybių masyvui, kaip matome toliau.

Tokiu būdu mes išsprendėme problemą paprastu būdu, tačiau jei sąraše, o ne trijose spalvose būtų šimtas, paprastumo istorija būtų kitokia.
Šiame pavyzdyje mes dinamiškai patvirtinsime vartotojo įvestą lauką tinkamu būdu, todėl turime tai naudoti taisyklingos išraiškos ir tokiu būdu išvengti simbolių, dėl kurių kyla pavojus mūsų apdorojimui, įvedimo, taip pat įvertinti įrašo dydį ir taip išvengti a perpildymas arba mūsų duomenų tipo perkrova apdorojant programą. Pažiūrėkime kodą paveikslėlyje:

DIDELIS

Svarbiausia norint pasiekti patvirtinimą yra teisingai žinoti, ką norime apdoroti, pavyzdžiui, vartotojo vardo atveju paprastai prašome raidžių ir skaitmenų bei brūkšnelių, todėl įprasta frazė Mes tai patvirtiname, mums taip pat reikia, kad jis būtų ilgesnis nei 0 simbolių ir ne daugiau kaip 32, jei tai, ką įvedė vartotojas, atitinka visa tai, jis patvirtina, geriausia, kad tai veikia su tokia verte kaip šimtas, nes jis yra visiškai dinamiškas.
Kita grėsmė, nuo kurios turime apsisaugoti, yra scenarijų vykdymas iš kitų svetainių AJAX Mes galime išsiųsti formas iš kliento į maršrutą, įskaitant užklausos tipą ir norimas vertes.
Minkšta vietaDėl tokio silpnumo labai lengva kam nors patikrinti mūsų formą ir patikrinti mūsų laukus, kur turint šiuos pavadinimus ir metodą HTTP Pabandykite siųsti nesaugias vertes, kad to išvengtume, turime taikyti metodus, leidžiančius patvirtinti, iš kur gaunama užklausa, ir ar saugu leisti ją vykdyti, kitaip venkite tęsti kelią mūsų programoje.
Siekiant išvengti šios problemos, sistema žetonų Y sesijos, kad pateikę formą įvertintume, ar seansas yra tas pats, kuris nustatytas saugiu būdu, ir todėl kenkėjiškas vartotojas negali tęsti.
Pagrindinis užpuoliko tikslas yra sugebėti įterpti savo kodą į mūsų aplinką, tam jie naudoja kodo injekcijas SQL, šis išpuolis yra žinomas kaip SQL įpurškimas, kur su neužtikrintomis formomis ir netinkamu apdorojimu galime gauti instrukcijas SQL tiesiogiai be apribojimų. Pavyzdžiui, jei mūsų vertinimas SQL yra toks mūsų scenarijuje PHP:

Mes galime naudoti bet kurį sistemos vartotoją kaip vartotojo vardą ir Slaptažodis mes naudojame du scenarijus “--” tai galime perduoti saugumą be problemų, nes du scenarijai yra komentaras SQL todėl slaptažodis nebus įvertintas.
Teisingas kelias į įvertinti SQL iš vartotojo, pašalina specialius ir pavojingus simbolius, įvertina tik saugias išraiškas. Toliau pateikiamas pavyzdys, kaip išvengti ankstesnio atvejo:
Pirmas dalykas, kurį turime padaryti, yra a duomenų dezinfekavimas, tai yra, neleisti, kad jis grynas iš formos patektų į mūsų SQL; Antras dalykas, kurį turime įvertinti, yra tas, kad jei abi vertės atitinka prieigą, bet pastarosios atitinka kiekvieno logiką, pažiūrėkime į paveikslėlį, kaip mes pasiekiame tikslą:

DIDELIS

Štai ką mes padarėme, tai naudoti įrankį parengtus pareiškimus ką mums leidžia knygynas SKVN prisijungimui prie Duomenų bazė, tokiu būdu mes pasiekiame, kad tai, kas įvesta, niekada nebūtų paimta kitame kontekste, kuris nėra duomenys, taip pat matome, kad užuot naudoję metodą POST Mes panaudojome savo saugų masyvą, tai reiškia, kad mūsų duomenys jau yra patikrinti, todėl rizika yra mažesnė.
Tai baigėme, nes matome, kad veiksmai, kurių galime imtis, kad mūsų programa būtų saugesnė, yra paprasti, jiems nereikia žmogiškų pastangų, tačiau jie padeda išvengti dažniausiai pasitaikančių ir galbūt dažniausių atakų . yra duodami. Yra blogas suvokimas apie PHP tų, kurie sako, kad tai nesaugi kalba, tačiau realybė yra tokia, kad nesaugumą sukuria programuotojas, nes kalba turi tik įrankius, kuriuos galime naudoti norėdami patobulinti ir užkirsti kelią atakoms prieš mūsų programas per vartotojo įvestus duomenis.