Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Most már tudom, miért szeret
olyan sok ember fát vágni.
Ennek a munkának ugyanis
mindig azonnal látni
lehet az eredményét.
/Albert Einstein/
2013. május 25.  
 A munka menete 
   
A jelen írás célja most csak a rendszerezés és összefoglalás a munkamenet-változókhoz kapcsolódóan, újdonságot nem fog tartalmazni.

A HTTP protokollról tudjuk, hogy állapotmentes, ezért külön kell gondoskodni a különböző kérések-válaszok közötti kapcsolat fenntartásáról. Erre alkalmasak az ú.n. munkamenet-változók, amelyeket a felhasználóhitelesítéssel összefüggésben is szoktak használni, azaz biztonsági szempontból fontos téma. Bár, "cookie" típusú adatok a böngésző tárában keletkezhetnek felhasználóhitelesítés nélkül is, a jelszó helyett már csak egy "session" azonosító utazik a felhasználónévvel a sikeres felhasználóhitelesítés után. A felhasználókezeléshez kötődő munkamenet-változók adatai érzékenyek, bizalmasak, éppen ezért nem mindegy, hogy milyen módon kerülnek átadásra oldalról-oldalra, hívásról-hívásra. Erre vannak különböző technikák, amelyek közül a legegyszerűbbeket mutatom be a PHP programozási nyelv segítségével.

A munkamenet-változók kezelésére - többek között - az alábbi módok alkalmasak:
  • HTTP GET
  • HTTP POST
  • COOKIE
  • SESSION
HTTP GET

A HTTP GET metódus során az URL-be ágyazódva kerülnek elküldésre a munkamenet-változó adatok. Ezen paraméterezett URL-ekről jó tudni, hogy - bár, az IETF RFC 2616 nem korlátozza a maximális méretüket - a gyakorlatban legfeljebb kb. 2000 karakter hosszúak lehetnek (kliens oldalon IE-nél 2048/2083 karakter, Firefox-nál 65536 karakter, szerver oldalon Apache-nál 4000 karakter a felső határ), nyomot hagynak a szerver oldalon a web szerver naplóállományaiban, a kliens oldalon a böngészőben, illetve maga a felhasználó is - ha nem figyel, akkor - könnyen ki tudja adni harmadik félnek az URL-ekben tárolt bizalmas adatokat (pl. e-mailben elküldi az URL-t). Biztonsági szempontból tehát a lehető legrosszabb megoldás bizalmas adatok átadására a HTTP GET, igaz programozni ezt a legkönnyebb (pl. <a href=""> vagy <form method="GET" action=""> segítségével). Figyelni kell azonban arra, hogy minden továbbugrásnál bele legyen kódolva a munkamenet-változó értéke az URL-be.

A kiinduló weboldal betöltésekor beállításra kerül a változó neve ("username") és értéke ("Aron Szabo"), ami ezután oldalról-oldalra ugorva átadódik az URL paramétereként.


HTTP POST

A HTTP POST esetében a HTTP üzenet törzsében (Body) utaznak a munkamenet-változó adatok. A HTTP GET metódushoz hasonlóan a programozónak kell megoldania, hogy oldalról-oldalra ugorva átadódjanak a változók értékei (<form method="POST" action=""> segítségével), azonban ezek nem kerülnek bele a naplóállományokba.

A kiinduló weboldal betöltésekor beállításra kerül a változó neve ("username") és értéke ("Aron Szabo"), ami ezután oldalról-oldalra ugorva átadódik a HTTP Body részeként.


COOKIE

A sütik a munkamenet-változók (és egyéb változók) neveit, típusait és értékeit a kliens (böngésző) oldalán tárolják. Ez a tárolt adathalmaz lehet állomány, vagy akár adatbázisbeli bejegyzés is (pl. a Firefox böngésző a "cookies.sqlite" nevű SQLite adatbázisban tárolja ezeket).


A sütik tartalmát a böngészőknek van jogosultsága elérni (a weboldal címe - illetve az esetlegesen tartalomba ágyazott, third-party elemek címe - alapján kérdezi le őket), a böngészők működését pedig a weboldalak befolyásolhatják, éppen ezért fontos, hogy a sütikhez való hozzáférés - amennyire lehet - szabályozva legyen. Biztonsági szempontból két attribútumot érdemes kiemelni. Egyrészt a sütik tárolásánál meg lehet adni a "HttpOnly" attribútum értéket (ld. IETF RFC 6265), amely jelzi a böngészőnek, hogy kizárólag HTTP kérés elküldéséhez használhatja fel a sütit (azaz pl. nem engedi egy JavaScript kódnak kiolvasni az értékét egy XSS - cross-site scripting - támadás során). A másik érdekes tulajdonság a "Secure" attribútum (ld. IETF RFC 6265), amely a HTTP kérés esetében is csak akkor enged hozzáférést az érzékeny adatokhoz, ha azok SSL/TLS protokoll révén védett, rejtjelezett csatornán kerülnek átküldésre.


A setcookie() függvényhívást tartalmazó weboldal betöltésekor letárolásra kerül a változó neve ("username") és értéke ("Aron Szabo"), érvényességének lejárata és a weboldal címe, amihez kapcsolódik a süti. A kliens böngészője tárolja az értékeket (Set-Cookie), amelyek elküldésre kerülnek a későbbi kéréseknél (Cookie).


SESSION

A "session" változó egy különleges süti, aminél a kliens oldalon már csak egy egyedi azonosító található, a kezelendő változók nevei, típusai és értékei pedig nem a kliens, hanem a szerver oldalon tárolódnak. A kliens oldalon a "hagyományos" sütikhez hasonlóan a Firefox SQLite adatbázisában keletkezik új bejegyzés (megadva, hogy melyik weboldalhoz - domain és path - tartozik), a szerver oldalon pedig a PHP keretrendszer által használt ideiglenes mappában (pl. C:\WINDOWS\Temp) egy sess_<PHPSESSID> nevű állomány jön létre a megadott adattartalommal.



A "session" süti (PHPSESSID) esetében érdemes tudni, hogy az azt létrehozó session_start() függvény a "HttpOnly" és "Secure" attribútumokra vonatkozó beállításokat a php.ini állományból veszi (session.cookie_httponly, session.cookie_secure). Ezeket felül lehet bírálni a session_set_cookie_params() függvénnyel, de akkor erre a programozónak kell figyelnie!

A session_start() függvényhívást tartalmazó weboldal betöltésekor letárolásra kerül a "session" süti (egy egyedi azonosító) a kliens oldalon, illetve a változó neve ("username") és értéke ("Aron Szabo") a szerver oldalon. A kliens böngészője tárolja az egyedi azonosító értékét (Set-Cookie), amely elküldésre kerül a későbbi kéréseknél (Cookie), hogy a szerver oldalon tárolt változókat be tudja tölteni a keretrendszer (a sess_<PHPSESSID> nevű állományból).


A munkamenet-változók kezelésére tehát több lehetőség is van, de a körülményektől is függ, hogy melyiket célszerű alkalmazni, ha a biztonság az elsődleges szempont. A HTTP GET metódust érdemes lehúzni a listáról, a többi megoldás viszont mind jó lehet. Megfelelő, ha pl. sütik ("cookie", "session") esetében a "HttpOnly" és "Secure" attribútumok be vannak állítva (és ellenőrzésre is kerülnek!), vagy korlátozott sütikezelési joggal futó böngészők esetében a HTTP POST is jó lehet, de ott meg valahogy biztosítani kell, hogy mindig legyen SSL/TLS csatorna (akár kétoldali hitelesítéssel man-in-the-middle támadás ellen), ráadásul programozás szempontjából is sokkal nagyobb odafigyelést igényel.

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info