Phenquestions
I denne artikkelen får du den nødvendige informasjonen fra applikasjonen for å vite hva det angripende nettstedet skal gjøre for å sende gyldige forespørsler til den sårbare serveren. Deretter oppretter du en side som simulerer legitime forespørsler og lurer brukeren til å besøke den siden mens den er autentisert. Du vil også gjøre noen gjentakelser av det grunnleggende beviset på konseptet for å få det til å se mer ut som et angrep fra den virkelige verden, der offeret ikke merker det. Merk at kodefilen for denne artikkelen finnes på forfatterens github.
Gjør seg klar
Du trenger en gyldig brukerkonto i BodgeIt for denne artikkelen. Denne artikkelen bruker [e-postbeskyttet] som offeret:
Hvordan gjøre det…
Først må du analysere forespørselen du vil tvinge offeret til å komme med. For å gjøre dette trenger du Burp Suite eller en annen proxy konfigurert i nettleseren:
- Logg inn på BodgeIt som en hvilken som helst bruker og klikk på brukernavnet for å gå til profilen.
- Gjør passordendring. Se hvordan forespørselen ser ut i proxyen:
Så det er en
POSTforespørsel tilhttp: // 192.168.56.11 / bodgeit / passord.jsp,og har bare passordet og bekreftelsen i kroppen. - Prøv å lage en veldig enkel HTML-side som replikerer denne forespørselen. Opprett en fil (gi den navnet
csrf-endre passord.html) med følgende innhold:
- Last nå denne filen i samme nettleser som den påloggede økten din:
- Klikk på send inn og du blir omdirigert til brukerens profilside. Det vil fortelle deg at passordet ble oppdatert.
- Selv om dette beviser poenget, kan et eksternt nettsted (eller en lokal HTML-side som i dette tilfellet) utføre en forespørsel om endring av passord på applikasjonen. Det er fortsatt lite sannsynlig at en bruker vil klikke på Sende inn Du kan automatisere den og skjule inntastingsfeltene slik at det ondsinnede innholdet blir skjult. Lag nå en ny side basert på den forrige; kall det
csrf-endre-passord-skriptet.html:En helt ufarlig side
Du kan stole på denne siden.
Ingenting ille kommer til å skje med deg eller din BodgeIt-konto.
Denne gangen har skjemaet en ID-parameter, og det er et skript på siden som sender innholdet når siden er lastet helt inn.
- Hvis du laster inn denne siden i samme nettleser der du har startet en BodgeIt-økt, vil den automatisk sende forespørselen, og brukerens profilside vil vises etter det. I det følgende skjermbildet, nettleserens Feilsøkingangi et bruddpunkt rett før forespørselen ble gjort:
- Dette siste forsøket ser bedre ut fra angriperens perspektiv. Du trenger bare offeret for å laste inn siden, og forespørselen blir sendt automatisk, men da vil offeret se ditt passord har blitt endretmelding, og det vil sikkert gi et varsel.
- Du kan forbedre den angripende siden ytterligere ved å få den til å laste inn responsen i en usynlig ramme på samme side. Det er mange måter å gjøre dette på; en rask og skitten er å sette størrelse 0 for rammen. Filen din vil se slik ut:
En helt ufarlig side
Du kan stole på denne siden.
Ingenting ille kommer til å skje med deg eller din BodgeIt-konto.
Legg merke til hvordan målegenskapen til skjemaet er iframe definert like under den, og at en slik ramme har 0% høyde og bredde.
- Last inn den nye siden i nettleseren der økten ble startet. Dette skjermbildet viser hvordan siden ser ut når den inspiseres med nettleseren Utviklerverktøy:
Legg merke til at iframe-objektet bare er en svart linje på siden, og i Inspector kan du se at den inneholder BodgeIt-brukerens profilside. - Hvis du analyserer nettverkskommunikasjonen gjennomført av CSRF-siden din, kan du se at den faktisk ber om å endre BodgeIt-passordet:
Hvordan det fungerer…
Når du sender en forespørsel fra en nettleser og allerede har en informasjonskapsel som tilhører måldomenet lagret, vil nettleseren legge ved informasjonskapselen til forespørselen før den sendes. Dette er det som gjør informasjonskapsler så praktiske som øktidentifikatorer, men denne egenskapen til hvordan HTTP fungerer er også det som gjør dem sårbare for et angrep som det du så i denne artikkelen.
Når du laster inn en side i samme nettleser, der du har en aktiv økt i en applikasjon, vil nettleseren automatisk legge ved øktkaken til den forespørselen. Dette skjer selv om det er en annen fane eller et annet vindu, og denne siden ber om et domene der økten startes.
Hvis serveren ikke bekrefter at forespørslene den mottar faktisk kommer fra applikasjonen, tillater det et ondsinnet nettsted å ringe på vegne av legitime, aktive brukere som besøker dette ondsinnede nettstedet mens de autentiseres til måldomenet.
I en penetrasjonstest for webapplikasjoner, den første koden du brukte, den med de to tekstfeltene og Sende inn knappen, kan være nok til å demonstrere tilstedeværelsen av en sikkerhetsfeil. Imidlertid kan penetrasjonstestingen av applikasjonen være en del av et annet engasjement, for eksempel en sosial ingeniør eller rødt teamøvelse. I dette tilfellet vil det være nødvendig med litt ekstra innsats for å forhindre offerbrukeren i å mistenke at noe skjer.
I denne artikkelen brukte du JavaScript for å automatisere sending av forespørselen ved å angi onload-hendelsen på siden og utføre skjemaets innsendemetode i hendelsesbehandlingsfunksjonen. Du brukte også en skjult iframe for å laste inn svaret på passordendringen, så offeret ser aldri meldingen om at passordet hans har endret seg.
Hvis du syntes denne artikkelen var interessant, kan du utforske den Kali Linux Web Penetration Testing Cookbook - Andre utgave for å oppdage de vanligste nettsårbarhetene og forhindre at de blir en trussel mot nettstedets sikkerhet. Kali Linux Web Penetration Testing Cookbook - Andre utgave gir deg ferdighetene du trenger for å dekke hvert trinn i en penetrasjonstest - fra å samle informasjon om systemet og applikasjonen til å identifisere sårbarheter gjennom manuell testing.
