tag: token

19Dec

Konstruáljunk web API-t - 2. felvonás

Amikor az ember webről beszél, a legtöbb esetben színes weboldalakat képzel el, ezerféle közösségi platform belépéssel, ahol az ember minden mozzanatát lépésen tudják követni különböző módszerekkel, hogy a leginkább testreszabott élményt kapja. Ha bejelentkezünk egy oldalra, akkor a következő oldalbetöltéskor már az üdvözlő képernyő fogad, azt a hamis érzést keltve, hogy a weboldal tudja, hogy pontosan kik is vagyunk. Ez persze közel sem igaz, csupán a böngészőnk által küldött sütiben szerepel egy session ID, amivel azonosítanak bennünket és ezáltal hozzánk igazíthatják az oldal tartalmát. Ehhez viszont az kell, hogy a böngésző süti ide-oda közlekedjen a kérésekben/válaszokban. Azt már tudjuk régről, hogy a HTTP az egy ún. stateless protokoll, vagyis a két egymást követő lekérés közt nincs semmiféle kapcsolat, állapotváltozás. Ezt hivatott áthidalni az imént említett sütis megoldás. Azonban amikor REST webservicekről beszélünk, ott ez a sütis módszer nincs jelen. A korábbi példákban ez nem is okozott gondot, hiszen még nem volt szó arról, hogy ki mit is csinálhat az adott REST erőforrásokkal. Viszont mi a helyzet akkor, ha bizonyos műveleteket csak adott jogosultság mellett szeretnénk megengedni? Valamilyen formában tudtára kell adjuk a szervernek, hogy mégis kik vagyunk, ami alapján ő vagy végrehajtja az említett műveletet, vagy egy jól irányzott 401-es válasszal finoman elutasít bennünket. Ilyen műveletek lehetnek pl. azok, amikor törölni akarunk egy elemet, hozzá akarunk adni, módosítani, netán valakinek a privát dolgaiba akarunk kutakodni. Cikkünkben belepillantást nyerünk abba, hogy mi is az OAuth2.0 protokoll és hogy segíthet nekünk a fentiekben, third party vagy épp a saját API-nk használatakor.

Tovább »

30Jan

Önvédelmi gyakorlatok - CSRF és Session hijacking

Az előző részben végigvettünk pár támadási formát és az ellenük való védekezés lehetőségét. Ebben a részben a CSRF-el, a cross site request forgery-vel és a session hijackingel fogunk foglalkozni. A CSRF támadások azt használja ki, hogy az adott oldal megbízik a felhasználóban és nem ellenőrzi, hogy adott lekérést valóban a felhasználó vitte-e véghez, mégpedig valóban a saját oldaláról.form_builder A CSRF támadások általában fórumokról indulnak, ahol az egyes hozzászólások szövegét az XSS-nél említett htmlentities-el már hatástalanították, így javascript kódot nem tudnak posztolni, ellenben képet igen. A képek src attributumában el lehet helyezni ártalmas kódot, a következőképpen:

Tovább »

22Jan

Önvédelmi gyakorlatok - 1. rész

Aki már helyezett ki kódot éles környezetbe (és volt némi felelősségérzete persze :D) abban bizonyára felmerült többször is, hogy "vajon mindent megtettem a szerverem biztonsága érdekében?". Nos a PHP, mint mondtam egy olyan nyelv, amin viszonylag korán el tudunk érni sikereket és ettől felbátorodva idő előtt éles környezetbe helyezzük a kódunkat, akár csak haveri alapon, saját célra valami kis oldalra. A gondot viszont az jelenti, ha valaki fizetett azért a "lukas" kódért, ami ott várja a neten a mókás kedvű arra tévedő 5. osztályosokat. Persze ez a probléma nem csak kezdőket érinthet, hiszen egy nagy, nehezen átlátható rendszerben is ( a kellő tervezés nélkül ) becsúszhat egy hiba és máris kész a baj.

Tovább »

2014-2018 © Letscode.hu. Minden jog fenntartva. Build verzió: