Find almindelige fejl
IDOR, XSS, SSRF
Find almindelige fejl er en gratis Ethical Hacking Academy-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Ethical Hacking Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Ethical Hacking Academy-kurset indeholder 4 lektioner i alt.
De vigtigste fejl
En håndfuld sårbarhedsklasser giver de fleste bug bounty-belønninger, fordi de er almindelige og har stor effekt. Lær først disse tre grundigt:
- IDOR — adgang til andre brugeres data via forudsigelige id'er
- XSS — indsættelse af et script på en side
- SSRF — at få serveren til at hente URL'er, som angriberen vælger
I denne lektion lærer du at lede metodisk efter hver af dem.
Forstå IDOR
Insecure Direct Object Reference (IDOR) opstår, når en app bruger en identifikator fra brugeren til at hente et objekt uden at kontrollere, om brugeren ejer det.
Skift id'et, og få adgang til en andens data. Det er en adgangskontrolfejl, ikke en injektion.
# Your own invoice
GET /api/invoices/1001 Authorization: Bearer <your-token>
# Change the ID - do you get someone else's?
GET /api/invoices/1002 Authorization: Bearer <your-token>Sådan finder du IDOR effektivt
Opret to konti, og sammenlign dem for at finde IDOR. Alt, der refererer til et objekt via et id, er en mulig kandidat.
- Optag en anmodning fra konto A, der henter A's data
- Send den igen med konto B's session, men med A's objekt-id
- Hvis B kan se A's data, er det IDOR
Hold øje med id'er i URL'er, JSON-legemer, headere og endda i base64-/UUID-formater.
# Original (account A)
POST /api/profile/update
{ "user_id": 5001, "email": "a@example.com" }
# Tamper: use account B's session, keep A's user_id
# If A's profile changes, broken object-level authorization.Forstå XSS
Cross-Site Scripting (XSS) er indsættelse af JavaScript, som kører i en anden brugers browser. Der er tre hovedtyper:
- Reflekteret — nyttedataene sendes tilbage i det umiddelbare svar
- Lagret — nyttedataene gemmes og leveres til andre brugere (størst effekt)
- DOM-baseret — JavaScript på klientsiden skriver angriberens input usikkert ind i DOM'en
Test for XSS
Indsæt først en unik markør for at se, hvor og hvordan dit input reflekteres, og udform derefter nyttedata, der passer til konteksten (HTML-brødtekst, attribut eller script).
Konteksten afgør, hvilke nyttedata der kan bryde ud og blive udført.
# Probe reflection with a unique canary
?q=xss7391canary
# Basic HTML-context payload
<script>alert(document.domain)</script>
# Attribute breakout
" onmouseover=alert(1) x="Påvis effekten af XSS
En simpel alert(1) beviser, at koden udføres, men kontrollører vil se effekten. Demonstrér, hvad en angriber faktisk kunne stjæle eller gøre.
- Læs et CSRF-token eller sessionsoplysninger, som JavaScript har adgang til
- Vis
document.domainfor at bevise oprindelsen - Vis ved lagret XSS, at den udløses på en offerkonto
Stjæl aldrig rigtige brugeres sessioner; demonstrér kun muligheden.
Forstå SSRF i apps
SSRF i en bug bounty-sammenhæng betyder at finde en funktion, der henter en URL, som du kontrollerer. Sandsynlige kandidater er:
- Webhook-URL'er og callback-URL'er
- Generatorer til billeder/PDF'er, der henter eksterne ressourcer
- Funktioner til URL-forhåndsvisning eller udfoldning af links
- Funktionalitet til import fra URL
Ret disse mod interne slutpunkter eller metadata-slutpunkter for at påvise effekten.
Bekræft SSRF uden for båndet
Når svaret ikke viser det hentede indhold, skal du bruge en out-of-band-server til at bekræfte, at målet sendte en anmodning. Et interaktions-callback beviser blind SSRF.
Værktøjer som Burp Collaborator eller interactsh giver dig en unik URL, der logger træffene.
# Give the app your unique OOB URL
POST /api/webhook
{ "callback": "http://abc123.oast.fun/" }
# If abc123.oast.fun logs a DNS/HTTP hit, the server fetched it = SSRF.Brug en proxy til at lede
Alle tre fejlklasser findes ved at opfange og manipulere anmodninger. En proxy, der kan opfange trafik, er det centrale værktøj.
- Burp Suite eller OWASP ZAP til at opfange og ændre trafik
- Repeater til at sende enkelte anmodninger igen og justere dem
- Intruder/fuzzer til at teste mange id'er eller nyttedata
Det betaler sig mere at lære din proxy grundigt at kende end at lære en enkelt teknik.
Kæd fejl sammen for større effekt
De største belønninger kommer fra at kæde fejl sammen. En fejl med middel alvorlighed kan blive kritisk sammen med en anden.
- SSRF, der når cloud-metadata, kan føre til tyveri af legitimationsoplysninger og overtagelse af konti
- IDOR, der afslører tokens, kan føre til fuld kompromittering af en konto
- Lagret XSS i et administrationspanel kan føre til overtagelse af administratorens konto
Spørg altid: Hvad kan denne fejl kombineres med?
Test omhyggeligt og inden for scope
Disse fejl berører rigtige data og rigtige brugere. Opfør dig etisk:
- Brug dine egne testkonti, og se ikke rigtige brugeres data ud over det, der er nødvendigt som bevis
- Undgå lagrede XSS-nyttedata, der kan blive udløst for rigtige brugere, og begræns dem til dig selv
- Ved SSRF må du ikke bevæge dig dybt ind i interne systemer; påvis den grundlæggende mulighed, og stop
Ansvarlig påvisning af effekt holder dig inden for safe harbor.
Hurtigt tjek
Du logger ind som bruger B, sender en anmodning igen med B's session, men med bruger A's objekt-id, og modtager A's private data. Hvilken sårbarhed er dette?
Opsummering: Find almindelige fejl
Du har lært at lede efter de tre mest værdifulde fejlklasser.
- IDOR: sammenlign to konti, manipulér objekt-id'er, og kontrollér håndhævelsen af ejerskab
- XSS: undersøg refleksion, tilpas nyttedataene til konteksten, og påvis reel effekt
- SSRF: find funktioner, der henter URL'er, og bekræft blinde tilfælde out-of-band
- Kæd fejl sammen for kritisk effekt (f.eks. SSRF til cloud-metadata)
- Brug en proxy, der kan opfange trafik, og hold dig inden for scope
Næste trin: at omsætte fund til rapporter, der udløser betaling.
Lær Ethical Hacking Academy med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 31
- Lektioner
- 111
Ofte stillede spørgsmål
Er lektionen “Find almindelige fejl” gratis?
Ja — hele teksten til “Find almindelige fejl” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Ethical Hacking Academy-kurset, skal du opgradere til CoddyKit PRO. Ethical Hacking Academy-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Find almindelige fejl”?
IDOR, XSS, SSRF Du øver dig i Ethical Hacking Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Ethical Hacking Academy?
Der kræves ingen tidligere erfaring. Ethical Hacking Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.
Hvor lang tid tager lektionen “Find almindelige fejl”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Ethical Hacking Academy-lektion?
Ja. Alle Ethical Hacking Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Valg af mål
- Reconnaissance i stor skala
- Find almindelige fejl
- Skriv gode rapporter