How Web Apps Get Hacked: The OWASP Top 10
You've spent Phase 2 learning to find things: subdomains, ports, services, hidden pages. That's recon and enumeration. This week is the next stage of the methodology, Gaining Access, where you turn something you found into an actual way in. And for beginners, the friendliest place to start gaining access is the web application, because you can poke at it with nothing more than a browser and curl.
Before you meet any single attack, spend a few minutes on the map.
One idea underneath almost every web bug
Here is the whole secret, and it is small:
A web app gets hacked when it trusts input it shouldn't.
Everything your browser sends, a URL, a form field, a cookie, a header, is just text the app chose to trust. When that text is handled as safe, but it actually reaches a database, an HTML page, a file path, or a security decision, an attacker can slip in something the developer never intended. Almost every vulnerability in this week is a variation on that one theme: data from the user got treated as code, or as trusted, when it wasn't.
So the question you ask of every input is always the same:
Where does this input end up, and is it treated as code or as data?
The OWASP Top 10, the industry shortlist
You can't test for every possible bug, so the security community maintains the OWASP Top 10: a regularly updated list of the ten most critical web application risks. It's the shortlist every tester works through. You don't need to memorise it, but recognise the big families:
| Family | The app wrongly trusts... | You'll learn it as |
|---|---|---|
| Injection | input that reaches a database or shell | SQL Injection |
| Cross-Site Scripting (XSS) | input reflected into a page | XSS |
| Broken Access Control | that you'll only ask for your own data | Access Control & IDOR |
| Security Misconfiguration | default settings, verbose errors, open directories | recon (Phase 2) |
| Identification & Auth failures | weak passwords, guessable sessions | wordlists, auth lessons |
The three we attack hands-on this week, injection, XSS, and broken access control, are consistently near the top of that list, and they're the most beginner-friendly to understand and to find.
Why start with the web?
- The tools are simple. A browser, its dev tools,
curl, and later an intercepting proxy (Burp Suite). No exploit code to write yet. - The feedback is instant. Change a URL, hit enter, see what happens.
- It's where the bugs are. Most real-world breaches start at a web-facing application, exactly the thing your recon surfaced.
The mindset shift
Recon asked "what exists?" Enumeration asked "what exactly is running?" Gaining access asks a new question:
"What does this app do with what I give it, and can I make it do something else?"
That's it. For the rest of the week, every lesson takes one input, a URL parameter, a search box, an account number, and shows how an app that trusts it too much hands you data, a session, or control you were never meant to have.
Try it (terminal)
There's no single flag to grab here, this lesson is the map. But warm up the muscle: fetch a target and look at what it does with input.
curl http://10.10.10.20/, read the page. Where might it take input?curl "http://10.10.10.20/search?q=hello", does your inputhellocome back on the page?- Ask yourself the question: where did my input end up? That instinct is the whole week.
Why this matters
"Hacking" in most people's imagination is this stage, the break-in. In reality it's the shortest stage, and it rests entirely on the recon beneath it and the one habit above: never assume an app is careful with what you send it. Learn to see every input as a question the app is answering, and you'll start finding the answers it didn't mean to give.