Phenquestions
I denne artikel får du de nødvendige oplysninger fra applikationen for at vide, hvad det angribende websted skal gøre for at sende gyldige anmodninger til den sårbare server. Derefter opretter du en side, der simulerer de legitime anmodninger og bedrager brugeren til at besøge den side, mens den er godkendt. Du laver også et par gentagelser af det grundlæggende bevis for koncept for at få det til at ligne et mere virkeligt angreb, hvor offeret ikke bemærker det. Bemærk, at kodefilen til denne artikel kan findes på forfatterens github.
Gøre sig klar
Du skal bruge en gyldig brugerkonto i BodgeIt til denne artikel. Denne artikel bruger [e-mail beskyttet] som offeret:
Hvordan gør man det…
Først skal du analysere den anmodning, du vil tvinge offeret til at fremsætte. For at gøre dette skal du bruge Burp Suite eller en anden proxy konfigureret i browseren:
- Log ind på BodgeIt som enhver bruger, og klik på brugernavnet for at gå til profilen.
- Foretag en ændring af adgangskoden. Se hvordan anmodningen ser ud i proxyen:
Så det er en
STOLPEanmodning tilhttp: // 192.168.56.11 / bodgeit / adgangskode.jsp,og har kun adgangskoden og dens bekræftelse i kroppen. - Prøv at lave en meget enkel HTML-side, der replikerer denne anmodning. Opret en fil (navngiv den
csrf-skift-adgangskode.html) med følgende indhold:
- Indlæs nu denne fil i samme browser som din loggede session:
- Klik på send, så omdirigeres du til brugerens profilside. Det fortæller dig, at adgangskoden blev opdateret.
- Selvom dette beviser pointen, kan et eksternt websted (eller en lokal HTML-side som i dette tilfælde) udføre en anmodning om ændring af adgangskode på applikationen. Det er stadig usandsynligt, at en bruger vil klikke på Indsend Du kan automatisere det og skjule inputfelterne, så det ondsindede indhold skjules. Lav nu en ny side baseret på den forrige; kald det
csrf-ændre-adgangskode-scriptet.html:En helt harmløs side
Du kan stole på denne side.
Intet dårligt vil ske med dig eller din BodgeIt-konto.
Denne gang har formularen en ID-parameter, og der er et script på siden, der sender sit indhold, når siden er indlæst helt.
- Hvis du indlæser denne side i samme browser, hvor du har startet en BodgeIt-session, sender den automatisk anmodningen, og brugerens profilside vises derefter. I det følgende skærmbillede, browserens Fejlfindingsæt et brudpunkt lige før anmodningen blev fremsat:
- Dette sidste forsøg ser bedre ud fra en angribers perspektiv. Du har kun brug for offeret for at indlæse siden, og anmodningen sendes automatisk, men så ser offeret Din adgangskode er blevet ændretbesked, og det vil helt sikkert give en alarm.
- Du kan forbedre den angribende side yderligere ved at få den til at indlæse svaret i en usynlig ramme inden for den samme side. Der er mange måder at gøre dette på; en hurtig og beskidt er at indstille størrelse 0 til rammen. Din fil vil se sådan ud:
En helt harmløs side
Du kan stole på denne side.
Intet dårligt vil ske med dig eller din BodgeIt-konto.
Bemærk, hvordan formularens målegenskab er den iframe, der er defineret lige under den, og at en sådan ramme har 0% højde og bredde.
- Indlæs den nye side i den browser, hvor sessionen blev startet. Dette skærmbillede viser, hvordan siden ser ud, når den inspiceres med browseren Udvikler værktøjer:
Bemærk, at iframe-objektet kun er en sort linje på siden, og i Inspector kan du se, at det indeholder BodgeIt-brugerens profilside. - Hvis du analyserer netværkskommunikationen foretaget af din CSRF-side, kan du se, at den rent faktisk fremsætter anmodninger om at ændre BodgeIt-adgangskoden:
Hvordan det virker…
Når du sender en anmodning fra en browser og allerede har en cookie, der hører til måldomænet, gemt, vedhæfter browseren cookien til anmodningen, før den sendes. Dette gør cookies så bekvemme som sessionsidentifikatorer, men denne egenskab ved hvordan HTTP fungerer er også det, der gør dem sårbare over for et angreb som det, du så i denne artikel.
Når du indlæser en side i samme browser, hvor du har en aktiv session i en applikation, vedhæfter browseren automatisk sessionscookien til den anmodning. Dette sker, selvom det er en anden fane eller et andet vindue, og denne side fremsætter en anmodning til det domæne, hvor sessionen startes.
Hvis serveren ikke verificerer, at de anmodninger, den modtager, faktisk stammer fra applikationen, tillader det et ondsindet sted at foretage opkald på vegne af legitime, aktive brugere, der besøger dette ondsindede websted, mens de er godkendt til måldomænet.
I en penetrationstest til webapplikationer, den første kode, du brugte, den med de to tekstfelter og Indsend knap, kan være nok til at demonstrere tilstedeværelsen af en sikkerhedsfejl. Imidlertid kan penetrationstesten af applikationen være en del af et andet engagement, såsom en social engineering eller et rødt team øvelse. I dette tilfælde kræves der en ekstra indsats for at forhindre offerbrugeren i at mistanke om, at der sker noget.
I denne artikel brugte du JavaScript til at automatisere afsendelsen af anmodningen ved at indstille onload-begivenheden på siden og udføre formularens indsendemetode i begivenhedshåndteringsfunktionen. Du brugte også en skjult iframe til at indlæse svaret på ændringen af adgangskoden, så offeret ser aldrig beskeden om, at hans / hendes adgangskode er ændret.
Hvis du fandt denne artikel interessant, kan du udforske den Kali Linux Web Penetration Testing Cookbook - Anden udgave at finde de mest almindelige websårbarheder og forhindre dem i at blive en trussel mod dit websteds sikkerhed. Kali Linux Web Penetration Testing Cookbook - Anden udgave giver dig de færdigheder, du har brug for til at dække hvert trin i en penetrationstest - fra at indsamle information om systemet og applikationen til at identificere sårbarheder gennem manuel test.
