Web Application Hacking · Topic 4 of 8
Authorization, Access Control, Session, Injection and Logic Attacks
Recognize attacks on authorization schemes, access controls, session management, injection and input validation, and application logic flaws, with fixes.
- 5 min
- Authentication proves identity. Authorization decides rights.
- IDOR is a missing ownership check on the server.
- Vertical escalation goes up to admin. Horizontal goes sideways to another user.
What it is
After login, an application must decide what each user may do (authorization), enforce it on every request (access control), track the user (session management), and handle input safely. Each stage has typical flaws.
Authentication asks "who are you". Authorization asks "what may you do". Mixing the two is a classic exam trap.
How it works
Attack authorization schemes
Authorization attacks try to act with more rights than the account has.
| Attack | Description |
|---|---|
| Parameter tampering | Changing values such as role, user ID or price in a request |
| HTTP request tampering | Editing methods, headers or cookies |
| Cookie parameter tampering | Changing a role or flag stored in a cookie |
| Privilege escalation | Moving up (vertical) to admin rights or across (horizontal) to another user's data |
| Forced browsing to protected pages | Requesting an admin URL directly |
Attack access controls
Access control attacks exploit missing or weak server side checks.
- Insecure direct object reference (IDOR): the application uses an identifier such as an account number in the request and does not check that the user owns it. Also called broken object level authorization in APIs.
- Missing function level access control: a page or function is hidden in the menu but not protected on the server.
- Path and file access: traversal and unprotected static files.
- Defense: deny by default, check ownership and role on every request on the server, use indirect or unpredictable references, and log access failures.
Attack session management mechanism
| Weakness | Description |
|---|---|
| Predictable tokens | Sequential or time based IDs can be guessed |
| Token in the URL | Leaks in logs and referrer headers |
| Session fixation | The attacker sets the ID before login |
| Token not renewed at login | Allows fixation |
| Long or missing timeouts and weak logout | Stolen tokens stay useful |
| Cookie flags missing | Without Secure, HttpOnly and SameSite the cookie is easier to steal or misuse |
| Cross site request forgery | The victim's browser submits an unwanted request using its session |
Defenses: random, long tokens from a secure generator, regeneration on login, strict timeouts, cookie flags, anti CSRF tokens and re-authentication for sensitive actions.
Injection and input validation attacks
Injection sends data that an interpreter treats as a command. The type depends on the interpreter.
| Type | Interpreter | Impact |
|---|---|---|
| SQL injection | Database | Read or change data (covered in detail later) |
| Command injection | Operating system shell | Run commands on the server |
| LDAP and XPath injection | Directory and XML query | Bypass logins and read records |
| Cross site scripting (XSS) | Browser | Script runs in other users' pages: reflected, stored or DOM based |
| File inclusion | Server | Local or remote file inclusion runs unintended files |
| XML external entity (XXE) | XML parser | Reads local files or reaches internal systems |
| Server side template injection | Template engine | Runs code in the template |
Defenses: validate input against an allow list, encode output for the context, use parameterized queries, avoid passing user data to shell commands, disable external entities in parsers, and set a content security policy.
Attack application logic flaws
Logic flaws are mistakes in the intended workflow rather than coding bugs, so scanners often miss them.
- Skipping a step in a multi step process such as checkout.
- Applying a discount code repeatedly, or using a negative quantity.
- Race conditions where two requests are processed at the same time.
- Trusting a value that the user can alter, such as a total passed in the request.
- Abusing a password reset or coupon flow.
The fix is to design the workflow with state checks on the server and to test the business rules, not only the code.
A worked example
A shopping basket sends the item price in the request. A tester changes the price to a low value and the order is accepted. The root causes are a trusted client value (logic flaw) and missing server side validation. The server must look up the price itself.
How the exam asks about this
- "A user changes
account=1001toaccount=1002in a URL and sees another customer's data. What is it?" -> Insecure direct object reference (broken access control). - "Which cookie attribute helps prevent CSRF?" -> SameSite (with anti CSRF tokens).
- "A multi step payment can be completed without the payment step. What type of flaw?" -> Application logic flaw.
What to remember for the exam
- Authentication proves identity. Authorization decides rights.
- IDOR is a missing ownership check on the server.
- Vertical escalation goes up to admin. Horizontal goes sideways to another user.
- Injection types depend on the interpreter. The cure is separating data from commands.
- Logic flaws need business rule testing because scanners rarely find them.
Hiding a link is not access control. If the server does not check, the page can still be requested directly.
Common mistakes
Mixing up XSS and CSRF. XSS runs attacker script in the victim's page. CSRF makes the victim's browser send a request.
Relying on obscurity. Unpredictable URLs without checks still leak.
Validating only the format. An allowed format can still hold a harmful value.
Check yourself
What fixes an IDOR flaw?
A server side check that the logged in user owns or may access the requested object.
What is the difference between vertical and horizontal privilege escalation?
Vertical raises the level of rights, while horizontal reaches another user at the same level.
Why do scanners miss logic flaws?
The requests look valid, and the flaw is in the business workflow rather than a detectable pattern.
Topic 4 of 8 in Web Application Hacking
Test yourself on Web Application Hacking
The full EC-Council 312-50 question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.