Hiba a kezdő php-fejlesztőknek, hogyan kell írni biztonságos kódot
Azok számára, akik legalábbis valamennyire megérintették a biztonság témáját, tudják, hogy az információ védelme soha véget nem érő folyamat. Információt kell biztosítania:
- elérhetőség;
- integritását;
- titoktartás.
Az egyetem az ötéves edzés során a fejébe sodródott =)
Ez a folyamat bizonyos szintű védelmet nyújt, de lehetetlen 100% -os biztonságot elérni. De a programozók feladata az, hogy a lehető legteljesebb mértékben biztosítsuk az alkalmazást a különböző fenyegetésekkel szemben.
Hibák a fejlődőben
A fenyegetések teljesen különbözőek, és sajnos nem mindegyikre számíthatunk. Azonban vannak olyan leggyakoribb hibák, amelyek az alkalmazások sebezhetőségéhez vezetnek. Ebben a cikkben megnézzük a legnépszerűbb hibák típusát, valamint azok kezelésének módjait. Szóval, menjünk.
Adatbázisok kezelése - SQL injektálás
Miért ez az első elem? Igen, mert ez a legfontosabb dolog. Az adatbázis tárolja az összes adatot a felhasználókról, pontosan ez a versenytársak és más gazemberek érdekli először.
Nézzünk egy sérülékeny kódot.
Az adatbázishoz intézett kérésünk a következő formát öltheti:
Az UNION lehetővé teszi, hogy több kérést egyesíts. A paraméterben a nem létező rekord számát adtuk át: -1, és a lekérdezés első része nem hozott nekünk semmit. Ezután a lekérdezés második részében megkerestük a felhasználók asztalát, és kihúztuk az e-mail és jelszó mezőket. kérve őket, hogy nevükben és szövegükben nevezzék el őket a mintában. Ezt a kérést végrehajtottuk, és ennek eredményeként a felhasználó e-mailje és jelszava a hírkiadó oldalon érkezett.
Megoldás - OEM
Az OEM lehetővé teszi az SQL injekciók elleni védelmet. lehetővé téve a helyes adatok helyes helyettesítését. Ez a továbbított adatok kötődésének köszönhető - a lekérdezésben bizonyos helyettesítéseket adunk meg, majd átadjuk nekik az értékeket. A kód így fog kinézni:
Itt a helyettesítést hívtuk: id, majd a végrehajtási módszerben az értéket átadta. Mindig használja az OEM-t és a kötési értékeket, ez nem teszi lehetővé, hogy bármi veszélyt dobjon az SQL lekérdezésbe.
PHP injekció
Ez egy olyan technika, amely lehetővé teszi a támadó számára, hogy tetszőleges kódot futtasson a webhelyen. Egyszerű példa: a webhelycikkek szöveges fájlok. Ezek megnyitásához a beépítési konstrukciót kell használni. amely elfogadja a get paramétereket.
Távoli fájlbevitel
A főfájlban tárolt cikk megtekintéséhez. a következő URL-t használják:
És a kód letöltésre kerül a webhelyről, mert a beillesztési funkció lehetővé teszi a kód távoli kiszolgálókon történő futtatását.
Nézzük meg azt a kódot is, amely a paraméterekhez hozzáad egy kiterjesztést a fájlnévhez.
Így PHP-ben a fájl végrehajtásra kerül:
Amint láthatja, itt a kiterjesztés lekérdezési paraméterré vált, és egyszerűen figyelmen kívül hagyják.
Helyi fájlbeillesztés
Természetesen ez a kód is használható a bizalmas fájlok elérésére a szerveren. Például egyszerűen adja meg a paraméterben szereplő útvonalat.
A fájl megjelenik a támadó böngészőjében.
Ha a csatlakoztatni kívánt fájl elején van egy elérési útvonal, csak helyi befecskendezés használható.
Csak relatív útvonalak használhatók.
Mindketten megtalálhatják az aktuális szkripthez vezető utat, ha hiba történik (ha a szerver hibajelentést tartalmaz, ami nagy hiba). Például egy nem létező abracadabra átadása a get paraméterre, a támadó hibát fog kapni, és megjelenik a hibaüzenettel kapcsolatos információ. Nevezetesen az útja. Ezzel már használhatja a különböző fájlok hozzávetőleges elhelyezkedését.
A PHP injekciók elleni védelem
Kihozhat egy csomó különböző szűrővel. De azt javasolnám, hogy tartsuk be a szabályt - ne engedjük meg, hogy a felhasználó beléphessen az include, require, eval-ba.
Kilépés - használja a htmlentities () függvényt
Olyan karaktereket alakít át, mint a zárójelek behelyezése speciális karakterekké, amelyek a böngésző ugyanazon zárójeleként jelennek meg, és nem kezelik őket címkékként.
Vagyis a böngészőben a látogató csak a szöveget fogja látni:
Mi mást kell tudnom a biztonságos fejlődésről?
A leggyakoribb biztonsági réseken kívül vannak olyan jobb gyakorlatok is, amelyek biztonságosabbá teszik a kódot. Tekintsük őket.
Az adatok hitelesítése és mentesítése
A kód által feldolgozott felhasználók összes adat potenciálisan veszélyes. Ezenkívül gyakran csak azt kell biztosítanunk, hogy az adatok hozzánk jöjjenek és tárolódjanak egy bizonyos formátumban. Így tudunk beszélni a munka kiszámíthatóságáról. Ez segít nekünk az adatok hitelesítésében és tisztításában.
Mit kínál a PHP ebben a tekintetben?
Először is ez a típuscsökkentés. Minden azonosítót, amelyet a felhasználó továbbít, egész számra kell vezetni (és nem csak ez, meg kell adnia az összes szükséges típust).
Másodszor - rendszeres kifejezések. A PHP-ben számos funkció van a szabályos kifejezésekkel való együttműködésre. Nagyon gyorsan dolgoznak, mert a könyvtárak, akik velük dolgoznak, C-ben vannak írva, és a rendszeres munkák nagyon alacsonyak.
Harmadszor, van egy beépített függvény filter_var (). amely lehetővé teszi mind az érvényesítést, mind a szennyvízkezelést. Például egy e-mail ürítéséhez elég írni:
Ahelyett, hogy gyakran a kódban láthatók a több száz karakterből álló szokványosak. Ne légy így, minden már megtett érted.
titkosítás
Először is azt szeretném mondani, hogy a titkosítás nagyon összetett téma, és meg kell értened, hogy valószínűleg nagyon felületesen megérted. Vannak azonban speciálisan képzett emberek, akik részt vesznek ebben a témában, és olyan bevált gyakorlatokat kínálnak, amelyeket be kell tartani. Ebben a cikkben a hamisításról beszélünk. Ez az eljárás magában foglalja az egyirányú titkosítást, amely után az eredő értékből lehetetlen visszaállítani az eredeti példányt.
Ezt a technikát gyakran használják a jelszavak tárolására. Ez azért van így, hogy ne tárolja a felhasználó kezdeti jelszavát. Mivel sok felhasználó ugyanazokat a jelszavakat használja különböző webhelyeken, és ha egy webhely egyik adatbázisa ellopták, és a jelszavakat világos formában látják, akkor valószínűleg ugyanaz a bejelentkezés és jelszó alkalmas más webhelyek számára. Tehát, hogyan valósult meg ez. A jelszó igazolásához egyszerűen titkosítjuk a bejelentkezési űrlapon megadott jelszót ugyanazzal az algoritmussal és összehasonlítjuk az értékeket. Ha megfelelnek, a jelszó helyes.
Hosszú ideig az MD5 algoritmust használtam erre. Egy ilyen hash létrehozása php-ben egy beépített md5 () függvény. Íme egy példa a használatára.
A hasítás eredményeként ez az algoritmus 16 bájtos hexadecimális kódot állít elő. Mint megérted, az összes lehetséges hash számát véges. Ezért a két különböző érték elvesztése eredményeként ugyanazt a hash értéket kaphatja. Ezt ütközésnek nevezik. Ez hatással van az összes hash függvényre. Sajnos, a világ tökéletlen. Tehát visszatérve az MD5 algoritmus - ma már úgynevezett szivárvány táblázatok neki (szivárvány asztal), amelyek lehetővé teszik, hogy megkapjuk az értéket (nem feltétlenül az eredeti), amely után a hash egyezik az értéket zaheshirovannogo eredeti érték. Így a hash ismeretében gyorsan kaphat egy jelszót, amely lehetővé teszi a webhely belépését.
Aztán jöttek fel sóval. Vagy, ahogy mondják, "sózzuk meg a hasokat". Az alsó sor az, hogy néhány szöveg hozzá van adva az eredeti jelszóhoz. Az eredmény egy másik hash.
Amikor a felhasználó megadja a jelszót, hozzáadjuk ezt a sort a jelszavához, kiszűrjük az eredményt, majd összehasonlítjuk a kapott értéket az adatbázisban szereplő értékkel.
Így védelmet nyújt a Rainbow Tables, mivel az ütközés valószínűsége csökken, mivel a sóban a sónak egybe kell esnie.
Senki sem fog szivárványos asztalokat készíteni a sós értékekre, bár az MD5-et még a sóval is igen gyorsan választják ki, különösen akkor, ha valaki nagyon szükséges.
Tehát az MD5 használata hiba. Ez egy elavult, nem biztonságos algoritmus. Amit azonban sokan továbbra is használnak.
Mi a helyzet a jelszavak tárolásával?
Most PHP-ben vannak speciális funkciók a hasításhoz, amelyek modern titkosítási algoritmusokat használnak. Ezek a _passwordhash () és _passwordverify () függvények. Az első függvény létrehoz egy hash értéket.
A második az első funkcióval kapott jelszó és hash. Ez hamis vagy igaz. attól függően, hogy a jelszó helyes-e.
Ezek a funkciók már működnek a sóval, és automatikusan hozzáadódik a hashhoz, amikor létrejön, és a hash-ból is kihúzódik, amikor összehasonlítja a beírt jelszóval. Használja ezeket a funkciókat, és boldog leszel.
következtetés
Ebben a cikkben csak felületesen beszéltem a kezdők fejlesztőinek legkedveltebb hibáiról, és példákat adtam arra, hogyan kell kezelni őket. Most azt tanácsolom, hogy részletesen tanulmányozd mindegyik területet annak érdekében, hogy megértsd, mit kell elsősorban félnie. A Google segítséget nyújt Önnek.
Mi más a biztonság szempontjából a fakápia?
Természetesen mindenkinek van fakapja, mindannyian ember vagyunk. A közelmúltban és én is - a projektkonfigurációs fájlban volt egy jelszó az e-mailből az emap üzenetek küldéséhez. Elfelejtettem letiltani ezt a konfigurációs fájlt a .gitignore fájlban. Ennek eredményeként a jelszó nyilvánosan elérhető a github-ban. Szerencsére volt egy személy, aki ezt a hibát írta. Rögtön megváltoztattam a jelszót, és köszönetet mondtam az embernek egy kis anyagi bónuszsal. Természetesen nagyon szerencsés voltam. Miután elérte az e-mailt, hozzáférhet az elküldött üzenetekhez és egyesíti a felhasználói bázist. Vagy, még rosszabb, küldj nekik valami csúnya dolgot ebből a postból.
A megoldás ebben az esetben a következő: figyelmen kívül hagyni a .gitignore összes konfigurációját, amint létrejönnek, és jobb, ha ezeket teljesen kiiktatják a tárból.