Valójában a hacker (aki én nem vagyok, félreértés ne essék) - bár ma már egy szétromantizált fogalom, de a valódi jelentése - egy olyan embert jelent, akinek az informatikai, azon belül sok témakörre kiterjedő szaktudása (részben security, részben op.rendszerek, programnyelvek, mindenféle ismeret) lévén ismernie kell (és ismeri is) a lehető legtöbb hibalehetőséget, minden helyzetben. Weblapoknál, programoknál, hálózatoknál, alkalmazásoknál. Ahol csak kell.
No, ezért nem vagyok, leszek én hacker. Ehhez tényleg nagy "kockafejnek" kell lenni. Szuper-szakbarbárnak. Én meg lusta dög vagyok, hogy akár csak gondoljak is ilyesmire.
Az én elenyésző tudásom, ami van, leginkább weblapos dolgokban merül ki, csak a hackerkedés felszínét súrolja. Ez is amiatt, hogy a legfőbb, legtipikusabb biztonsági réseket ismernem kell, hogy az általam megírt weblapok már védve legyenek ilyesmikkel szemben.
Tulajdonképp ma már csak azért érdekel, és azért tanulok mindenféle módszerről, amivel tönkre lehet tenni egy weboldalt, vagy elhelyezni rajta fájlokat, szöveget, kódot, vírust, hogy ne történhessen meg az én kreálmányaimnál. Maradjunk a weblapoknál..
A legtipikusabb esetek egy weblapon minden esetben a backenden történnek, azaz az én esetemben PHP-n. Mik az ilyen esetek (összefoglalóan: exploitok)?
- XSS - amikor van egy űrlap, kitöltheti a felhasználó, az bekerül az adatbázisba, és a beírt adat megjelenik egy másik lapján az oldalnak. Pl. a profilodon beírhatsz egy mottót, amit mások láthatnak. És ez az egész folyamat, amit írtam, nincs levizsgálva, semmilyen módon védve. Ebből mi következik? Konkrétan bármilyen kóddal bővítheti a weblapot, és az le fog futni a profilt megnyitó személynél. Ezzel adatokat is lehet lopni, és más dolgokat is lehet művelni.
- SQL injection - az előző esethez hasonló a dolog. Hozzáteszem, itt még van esély arra is, hogy a HTML részek szűrve vannak, pl. egy elég gyenge strip_tags PHP parancs által. Ez a módszer még az adatbázisba bekerülés előtt/közben csap le. Úgy, hogy a mottó mezőbe nem a mottónkat írjuk be, hanem aposztrófokat, amivel lezárjuk az adatbázis művelet parancsát, és utána kiegészíthetjük egyéb PHP kódokkal, amit a szerver lefuttat; simán úgy veszi, mintha az általunk beírt kód eredetileg is a fájl része lett volna. Ez veszélyes. Így lehet 2 perc alatt tönkretenni egy oldalt, elmenteni az adatbázisát, szóval adatokat lopni, stb. Ez persze könnyen kivédhető, ha minden esetben a legrosszabbra számítunk. Az összes mezőt ártalmatlanítani kell, ahol user képes adatot felvinni az oldalra. Ha számról beszélünk, legalább egy implicit típuskonverziót, szóval $szam = (int) $_POST['szam'], ha szöveg, akkor pedig legalább egy htmlspecialcharst írjunk a post adat köré, legalább egy ENT_QUOTES második paraméterrel!
- multibyte character exploit - vagy valami hasonló. Erről, illetve ilyesmiről egyszer olvastam valamerre. A lényeg az, hogy a weben sok helyen kell megadni a karakterkódolást. Ettől függ, hogy van-e pl. Ő és Ű betű az oldalon, vagy csak ilyen háztető formájú izé van az O és U felett. Azok nem igazi ŐŰ betűk. Ezt most nem magyarázom feleslegesen. Viszont olvastam ilyet régebben, hogy bár szűrve voltak az aposztrófok az adatbázisba érkezve, DE bizonyos karakterkódolású aposztrófokat nem escapeelt a védelem szerveroldalon. Escapeel = ártalmatlanít, mondjuk így röviden. Ami nem lett volna baj, de mivel más karakterkódolású volt a kliensoldal, meg a PHP, meg még az adatbázis is, így a beírás megtörtént (valahogy így volt), de bekerülni már a rendes aposztróf került be. Kiolvasásnál meg szintén az került ki. És amikor ez az adatbázis adat ki lett írva egy oldalon, és megnyitotta az oldalt egy ember, akkor viszont lefutott a kód, kitörve a PHP-s kiírásból. Ezért sem szabad tökölni hatvan féle kódolással, mindenhol UTF-8.
- MIME type exploit - sok oldalon lehet feltölteni képet, vagy esetleg fájlokat/mást, de a leggyakoribb a kép. Na most, tisztázzunk valamit. Ha készíteni kell egy (fájl, vagy) képfeltöltő cuccot, PHP-ban, minimum korlátozzuk elfogadólistásra a feltölthető dolgokat. Ugyanis, ha valaki fogja magát, feltölt egy PHP fájlt, akkor felkerült a szerverre egy PHP fájl. Ez tudjuk mit jelent. Bővítette a weblapot, és bármit csinálhat a fájlból; törölheti az egész weblapot, letöltheti az adatbázist, stb. Elég megnyitnia a feltöltött fájlját. Ilyet nem játszunk. Ha már képet várunk feltöltési elemnek, azt nem árt több módon is megvizsgálni, hogy valóban kép-e. Ne bízzunk a content type-ban ($_FILES['file']['type']). Ez manipulálható, elég egy régi/egyedi böngésző. És máris annyi az ellenőrzésnek, hisz ez is kliensoldalról küldött információ. A fájlnév vizsgálat sem árt. De vigyázni kell. Lehet csinálni olyat, hogy a feltöltött fáljnál az utolsó pont utáni részt megnézzük, akkor viszont legyünk alaposak. Ne pontos egyezést nézzünk, hanem egy globális cserével szedjük ki a php végződést, és hasonló dolgokat a kiterjesztésből. Ugyanis pontos egyezésnél ha csak a PHP-t vizsgáljuk, akkor simán feltölthet egy megszivtad.php3 fájlt. Ami ugyanúgy lefut, ha megnyitja. És nem ez az egyetlen lehetőség. Legtutibb, ha írsz egy jó regexet, ami mindent töröl ettől a ponttól, ami p-től kezdődik, van benne h, és még a végén is van legalább egy p betű.
Ennek a posztnak egyébként, így belegondolva semmi értelme. Talán annyi, hogy ezeket leírva egy nálam kezdőbb tanulhat valami minimálisat, vagy kap ötletet, hogy mire keressen rá. Az mégiscsak több, mint a semmi.
Megjegyzés: ha valamilyen számítást kliensoldalon elvégeztél, JS-sel, akkor mielőtt kiírod adatbázisba, ugyanazon lépésekkel számoltasd át a PHP-val is, és ha egyeznek, akkor (is a) PHP általi értéket írd a DB-be. Biztos ami biztos. Főleg, ha webshopot kezdesz fejleszteni valakinek. Elég gáz, ha egy input mező átírásával féláron, vagy tizedáron lehet rendelni egy árucikket.
Megjegyzés2: ha rejtvényt csinálsz, vagy kuponos rendszert, vagy bármilyen ellenőrizendő adatbevitelt: ajax-szal csináld, ellenőrzésekkel és megszakításokkal. Ne a kliensoldalba rakd a "megoldást", vagy a kinyerhető adatokat. Még titkosítva se. Ha te vissza tudod fejteni (pl. a kuponkódot, annak adatait), akkor más is. Főleg, ha kliensoldali a visszafejtő funkció..
Filmajánló /sorozat/: Mr. Robot, A célszemély, Snowden
Nincsenek megjegyzések:
Megjegyzés küldése