Et CSRF -angrep er det som får autentiserte brukere til å utføre uønskede handlinger i webapplikasjonen de er autentisert med. Dette gjøres gjennom et eksternt nettsted som brukeren besøker og som utløser disse handlingene.

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 de legitime forespørslene og lurer brukeren til å besøke den siden mens den er autentisert. Du vil også lage noen få iterasjoner om det grunnleggende beviset på konseptet for å få det til å se mer ut som et angrep i den virkelige verden, der offeret ikke legger merke til det. Merk at kodefilen for denne artikkelen finner du på forfatterens GitHub.

Gjør seg klar

Du trenger en gyldig brukerkonto i Bodgeit for denne artikkelen. Denne artikkelen bruker [email protected] som offeret:

Hvordan gjøre det…

Først må du analysere forespørselen du vil tvinge offeret til å lage. For å gjøre dette, trenger du Burp Suite eller en annen proxy konfigurert i nettleseren:

1. Logg deg på Bodgeit som enhver bruker og klikk på brukernavnet for å gå til profilen.
2. Gjør en passordendring. Se hvordan forespørselen ser ut i proxy:

   Så det er en POST forespørsel til http: // 192.168.56.11/Bodgeit/Passord.JSP, og har bare passordet og dets bekreftelse i kroppen.

3. Forsøk å lage en veldig enkel HTML -side som gjentar denne forespørselen. Opprett en fil (navn CSRF-Change-Password.html) med følgende innhold:
   
   
   
   
   
   
   
   
   
   
4. Last nå denne filen i samme nettleser som din innloggede økt:
5. Klikk på Send inn, så blir du omdirigert til brukerens profilside. Det vil fortelle deg at passordet ble oppdatert med hell.
6. Selv om dette beviser poenget, kan et eksternt nettsted (eller en lokal HTML -side som i dette tilfellet) utføre en forespørsel om passordendring på applikasjonen. Det er fremdeles usannsynlig at en bruker vil klikke på Sende inn Du kan automatisere det og skjule inngangsfeltene slik at det ondsinnede innholdet er skjult. Lag nå en ny side basert på den forrige; kall det CSRF-Change-Password-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 vil sende inn innholdet når siden er lastet fullstendig.

7. Hvis du laster inn denne siden i den samme nettleseren der du har en bodgeit -økt initiert, vil den automatisk sende forespørselen, og brukerens profilside vises etter det. I det følgende skjermbildet, nettleseren DebuggerAngi et bruddpunkt rett før forespørselen ble fremsatt:
8. 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 heve et varsel.
9. Du kan forbedre den angripende siden ved å få den til å laste responsen i en usynlig ramme på samme side. Det er mange måter å gjøre dette på; En rask og skitten er å sette en 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.
   
   Target = "Target_Frame">
   
   
   
   
   
   
   

   Legg merke til hvordan målegenskapen til skjemaet er iFrame definert rett under den, og at en slik ramme har 0%høyde og bredde.

10. Last inn den nye siden i nettleseren der økten ble startet. Dette skjermbildet viser hvordan siden ser ut når du blir inspisert med nettleseren Utviklerverktøy: Legg merke til at IFRAME -objektet bare er en svart linje på siden, og i inspektør kan du se at den inneholder Bodgeit -brukerens profilside.
11. Hvis du analyserer nettverkskommunikasjonen som er utført av CSRF -siden din, kan du se at det faktisk kommer med forespørsler om å endre Bodgeit -passordet:

Hvordan det fungerer…

Når du sender en forespørsel fra en nettleser og allerede har en cookie som tilhører måldomenet som er lagret, vil nettleseren knytte informasjonskapselen til forespørselen før den sendes. Dette er det som gjør informasjonskapsler så praktisk som sesjonsidentifikatorer, men denne karakteristikken for hvordan HTTP fungerer også er det som gjør det sårbart for et angrep som den du så i denne artikkelen.

Når du laster inn en side i den samme nettleseren, der du har en aktiv økt i en applikasjon, vil nettleseren automatisk legge til øktkake til den forespørselen. Dette skjer selv om det er en annen fane eller et vindu, og denne siden gir en forespørsel til domenet der økten er startet.

Hvis serveren ikke bekrefter at forespørslene den mottar faktisk har sin opprinnelse fra applikasjonen, lar den et ondsinnet nettsted for å ringe på vegne av legitime, aktive brukere som besøker dette ondsinnede nettstedet mens de er autentisert til måldomenet.

I en penetrasjonstest for webapplikasjoner, den første koden du brukte, den med de to tekstfeltene og Sende inn knapp, 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ød teamøvelse. I dette tilfellet vil det kreves noe ekstra krefter for å forhindre at offerbrukeren mistenker at noe skjer.

I denne artikkelen brukte du JavaScript for å automatisere sendingen av forespørselen ved å sette Onload -hendelsen på siden og utføre skjemaets innsendingsmetode i hendelsesbehandlerfunksjonen. 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 fant denne artikkelen interessant, kan du utforske Kali Linux Web Penetration Testing Cookbook - Second Edition For å oppdage de vanligste nettsårbarhetene og forhindre dem i å bli en trussel mot nettstedets sikkerhet. Kali Linux Web Penetration Testing Cookbook - Second Edition 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.