Folytatjuk a hitelesítési modell támadási felületeinek és védekezési eljárásainak feltérképezését. Ahogy az előző részben már szó volt róla sok esetben az a leggyengébb láncszem és igen sokféle támadási felületet ad. »»

A hacker tanfolyam negyedik részében a hitelesítés megtámadásával fogunk foglalkozni. A weblapok mintegy 67%-ánál található valamiféle biztonsági rés ezen a területen. Valójában a hitelesítés a védekezés frontvonala, de ennek ellenére sokszor a leggyengébb láncszem is. »»

Hacker tanfolyamunk harmadik részében megkezdjük a támadási és tesztelési módszerek ismertetését. Elsőként a kliens oldali ellenőrzéseket próbáljuk meg kijátszani. A fő szabály amit webfejlesztőként meg kell tanulnunk, hogy a kliens oldali ellenőrzések kizárólag kényelmi eszközök és semmiféleképpen nem alkalmasak biztonsági előlapnak. Ennél fogva mindennemű kliens oldali ellenőrzést meg kell ismételni szerver oldalon is. »»

Miután megismerkedtünk az alapelvekkel egy oldal feltörésénél az első dolgunk az alkalmazás feltérképezése lesz. A feltérképezés során tulajdonképpen a megtámadható felületeket keressük meg. Két fő dolgunk lesz ennek során. Először is megismerkedünk az alkalmazással és megpróbáljuk a lehető legtöbb háttér információt összeszedni róla, majd második lépésként feltérképezzük a támadási felületeket. »»

A tömegek életének mind több mozzanatának online irányba való elmozdulásával egyre inkább érzékenyek kell lennünk olyan témákra amelyek eddig esetleg többnyire nem igazán mozgatták meg a fejlesztői fantáziánkat. Az eddig ilyen a webalkalmazások biztonsága. A téma egyre fontosabb és fontosabb lesz és láthatjuk, hogy még az olyan nagyok mint a twitter vagy az amazon is belefut időnként egy-egy ilyen jellegű problémába.

Kezdődjön hát a hacker tanfolyam! »»

Egy új webes szolgáltatás bevezetésénél és népszerűsödésében egyre nagyobb és nagyobb súllyal esik latba, hogy a szolgáltatás rendelkezik-e valamiféle API-val és ha igen akkor az hogyan is funkcionál. Nem lehet véletlen, hogy a Google is egyre inkább rászokik arra, hogy minden újdonságát API-val együtt vezet be. Arra keressük ma a választ, hogy a webes szolgáltatásoknak kell-e API-t nyitniuk, vagy sem, mikor, miért és mennyire. »»

Ma egy igen kényes témát szeretnék bemutatni. Kényes mert a biztonsági tanácsok egyben ötletek másoknak arra, hogy hogyan tudnak ténylegesen feltörni oldalakat. Egy webalkalmazás biztonsági tesztelése praktikusan nem jelent mást mint, hogy a webalkalmazás fejlesztője / tesztelője egy rövid időre a támadó bőrébe bújik. Rászántam a hétvégét és egy dologra jöttem rá, egy weblap feltöréséhez egyetlen dolog szükséges: IDŐ.
»»

Az első részben megnéztük a két hasonló módszer, a vezérlő engedélyekre és a modell engedélyekre alapuló hozzáférés kezelést. A következőkben megnézzük a jogosultságok kezelésére is használható ACL-ek kétféle hasznosítási elvét. Aki eddig esetleg nem tette volna, az olvassa el először a CakePHP szakácskönyv ACL-lel foglalkozó részét. »»

Minden komolyabb webalkalmazás fejlesztése során egy igen lényeges momentum a felhasználók hozzáférésének, jogainak kezelése. Annak szabályozása, hogy ki mihez férjen hozzá nem csak biztonsági, hanem működtetési szempontból is fontos. Meglehetősen sok leírás található arról angolul, hogy a problémát hogyan kezeljük a CakePHP keretrendszer használata esetén, de ezek nagy része már elavult vagy csak rész igazságokat közöl. Most itt megpróbálom felszolgálni a teljes sütit. »»

Habár a cake szakácskönyve elég részletesen leírja, hogy hogyan kell egy usereket hitelesítő részt megírni 1.2-es cake esetén, de még mindig időről időre keresgélnem kelett amikor egy új projekthez szerettem volna ezt a funkciót megírni. Végül fogtam (és az egyébként jó ideje vázlatként várakozó postot) és megírtam. Íme. »»

Történetünk első lépésében arra kerestem a megoldást, hogy hogyan lehet egy futó rendszert menet közben teljesen átépíteni. A több lehetséges megközelítés közül a béka módszert választottam, azaz azt, hogy szépen elemenként kifejlesztünk egy funkciót és aktiválásakor kiiktatjuk a régi rendszer részt. Lássuk a hogyant! »»

A legnagyobb aktivitás a blogon a rövid url-ekkel foglalkozó bejegyzésnél van. Sok kérdés összegyűlt és úgy láttam, hogy érdemes lenne pár kiegészítést és választ kiemelni egy külön bejegyzésként. Szeretném még itt az elején leszögezni, hogy nem vagyok egy mod_rewrite szakértő, csak épp annyira foglalkozok vele amennyire muszáj. Ennek a leírásnak a célja inkább az, hogy a korábbi bejegyzés pár gondolatát magyarázza, illetve, hogy az egész modul fő elvét bemutassa. »»

Egy szövegfájl beolvasása és feldolgozása PHP-val valami olyasmi amit egy 8 éves gyerek 5 perc alatt összehoz. Az a szép a webfejlesztő életében amikor egy ilyen feladattal bármikor sikerülhet egy teljes napot elpiszmognia. A miértre a válasz mindig más és természetesen az operációs rendszerek ködbe vesző csakmer’ típusú történetében lapulnak. Szomorú történetem következik mások okulására. »»

Hallottál már a tündéri CSS manócskákról? Érted őket igazán? A manók igazából nem is olyan picikék, hanem nagyok, pont ez a lényeg. Ezzel a technikával több kisebb képet egy nagyobbal tudsz helyettesíteni és ezután annak csak bizonyos részeit használni épp ott és úgy ahogy a weblap egyes részein kell. A CSS manók legegyszerűbb példája amikor egy gomb normál és benyomott állapotban másképpen néz ki és nem két külön képként, hanem egy képként használjuk őket. Persze ebben az esetben kell egy kis varázslat. »»

A relációs adatbázisok előnyei közül ma a tranzakciókezelést szolgáljuk fel ebédre. Egy tranzakció tulajdonképpen egy nagy tányér SQL művelet amelyeknek csak együtt van értelme. Tipikus példa erre egy banki átutalás, amelynek során (jó esetben) az egyik számla egyenlegét akkor csökkentjük amikor a másikét növeljük. »»

A SELECT-tel már ismerkedtünk az 5. részben, de van jónéhány egyéb parancs és kiegészítés ami gyakran használatos a SELECT utasításokban. Ezek közül küldjük most a boncasztalra azt a párat amit garantáltan minden projektben használni fogunk. »»

Amikor egy élő weboldalon módosítjuk a CSS fájlt akkor jó eséllyel a látogatók egy ideig a régi CSS-sel fogják látni az oldalt. Ez oda vezethet, hogy bizonyos linkek nem látszanak, a szinek nam passzolnak vagy az oldal teljesen szétesik – attól függően, hogy mit módosítottunk a CSS-ben. »»

Minden webfejlesztővel előfordul, hogy valaki másnak a kódjához kell hozzányúlnia. Még egy átlagos webalkalmazás is annyira összetett, hogy eltarthat egy jó darabig amíg az ember fel tudja térképezni, hogy valójában melyik kódrészlet mire hivatott vagy, hogy mit hol keressen. »»

A következő leírás kipróbálgatására szükségünk lesz egy adatokkal feltöltött adatbázisra. Akinek nincs éppen kéznél az letöltheti innen. Ebben a részben a táblakapcsolatokkal fogunk mélyebb ismeretségbe keveredni. »»

Az 1.2-es CakePHP sok mindenben megkönnyíti a dolgunkat, köztük a projektünk nemzetközivé tételében is. Ha több nyelven is elérhetővé akarjuk tenni a webalkalmazásunkat akkor a következőket kell tennünk. »»

Ha az előző részben ismertetett adatbázist sikerült létrehoznunk magunktól (vagy a mellékelt sql script segítségével) akkor elkezdhetünk ismerkedni azokkal az SQL parancsokkal amelyek segítségével az adatbázisunkba adatokat tudunk elhelyezni, illetve adatokat tudunk lekérni. »»

Elég volt a dumából, ideje lenne nekilátni a valódi munkának! A türelmetlenség legalább akkora erénye a jó programozónak mint amekkora hátránya. A megfelelő tervezés és háttérinformációk sok későbbi többlet munkától kímél meg bennünket. Kellőképpen telepumpáltuk a fejünket az okossággal, szóval akkor hajrá! »»

Elvi tudásunkhoz már csak egyetlen dolog hiányzik, mivel eddig nem beszéltünk a MySQL által használt adattípusokról. Az adatbázisunk tábláiban minden oszlopnak meg kell adnunk egy adattípust. Ez a definíció azt mondja meg, hogy az adott oszlopban miféle adatot tárolhatunk. A kiválasztott adattípus több kisebb-nagyobb következménnyel jár. »»

Adatokat sokféle módon tárolhatunk de az biztos, hogy bizonyos méret felett a saját dolgunkat könnyítjük meg ha valamilyen struktúrába szervezzük őket. Így vagyunk ezzel mindennel amiben kereséseket akarunk végezni. Ezért van egy fiókunk a zokniknak és a gatyáknak, egy az ingeknek és egy a pólóknak. Helykihasználtság szempontjából rakhatnánk mindent egybe is, de így sokkal nehezebb lenne megtalálni a kedvenc piros-citromsárga kockás szerencse zokninkat. No, ilyen egy adatbázis. »»

Miután kiválogattuk a használni kívánt eszközöket és háttéralkalmazásokat az igények alapján összeállíthatjuk a megvalósítási ütemtervet. Persze ez még mindig azok közé a lépések közé tartozik amit a programozók szeretnek ignorálni, de anélkül, hogy átgondolnánk a megvalósítás fázisait nem ugorhatunk bele a kódba. »»