 |
| Ethical Hacking |
🛡️ Ethical Hacking — Day 15
Authentication & Access Control: Understanding Who Can Do What
⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. All practical exercises are intended for your local OWASP Juice Shop lab, applications you own, or systems for which you have explicit authorization. Never test authentication or access-control weaknesses on real websites without permission.
Welcome to Day 15.
You've now built your local web-security lab with:
Docker
↓
OWASP Juice Shop
↓
Burp Suite
↓
Browser
Today we're going to study one of the most important areas of web security:
🔐 Authentication & Authorization
These two concepts are closely related, but they are not the same thing.
🎯 Day 15 Learning Objectives
Today you'll learn:
Authentication
Authorization
Identity
Sessions
Cookies
Login workflow
Access-control boundaries
Horizontal access control
Vertical access control
Role-based access
Object-level authorization
Burp HTTP History
Burp Repeater
Safe request comparison
How to identify authorization checks
How developers should fix access-control problems
Linux practical commands
Windows PowerShell practical commands
macOS practical commands
1. Authentication vs Authorization
Remember this simple rule:
Authentication = Who are you?
Authorization = What are you allowed to do?
For example:
User enters credentials
↓
Authentication
↓
"Yes, this is Alice."
↓
Authorization
↓
"What is Alice allowed to access?"
2. Real-World Example
Imagine an institution ERP.
A student logs in.
Authentication:
Username + Password
↓
Student identified
Authorization:
Student
├── View own profile ✅
├── View own attendance ✅
├── Edit fee records ❌
├── Delete students ❌
└── Manage administrators ❌
An administrator might have:
Administrator
├── View students ✅
├── Edit students ✅
├── Manage fees ✅
└── Manage users ✅
This distinction is fundamental to secure ERP, CRM and SaaS applications.
3. Authentication
Authentication verifies identity.
Common mechanisms include:
Username + Password
MFA
Passkeys
Certificates
OAuth/OIDC
Session cookies
API tokens
A simplified login process:
Browser
│
│ username + password
▼
Server
│
│ Verify credentials
▼
Authentication System
│
│ Success
▼
Session Created
│
▼
Browser
4. What Happens After Login?
Suppose you successfully log in.
The server may establish a session.
Conceptually:
Login
↓
Authentication successful
↓
Session created
↓
Session identifier
↓
Browser cookie
The browser may subsequently send:
Cookie: session=LAB_SESSION
with requests.
5. Session Cookie
A session cookie can look conceptually like:
Set-Cookie: session=abc123
The browser later sends:
Cookie: session=abc123
The server uses the session to associate the request with an authenticated user.
⚠️ Important
A real session cookie is effectively sensitive authentication material.
Never publish:
Session cookies
Access tokens
Refresh tokens
API keys
Passwords
Authorization headers
in:
Screenshots
GitHub
Blog posts
Tutorials
Chat messages
For today's exercises, use only your local lab.
6. Authentication Flow
A simplified flow:
LOGIN
│
▼
┌───────────────┐
│ Credentials │
└───────┬───────┘
│
▼
┌────────────────┐
│ Authentication │
└───────┬────────┘
│
┌──────┴──────┐
│ │
FAIL SUCCESS
│ │
▼ ▼
Error Session
│
▼
Browser
7. Authorization Flow
After authentication:
Request
↓
Who is the user?
↓
What resource is requested?
↓
What action is requested?
↓
Is the user allowed?
↓
YES → Continue
NO → Deny
This is authorization.
8. Three Important Questions
For every protected endpoint, ask:
Who?
Which user?
What?
Which resource?
Which action?
Read?
Create?
Update?
Delete?
For example:
User: Alice
Resource: Student #25
Action: Edit
Then:
Is Alice allowed to edit Student #25?
9. Horizontal Access Control
Horizontal access control concerns users at approximately the same privilege level.
Example:
Alice → Account A
Bob → Account B
If Alice is authenticated as Alice, she should generally not be able to access Bob's private information simply by changing an object identifier.
Conceptually:
Alice
│
├── Own profile ✅
└── Bob's profile ❌
This is commonly called horizontal privilege/access-control separation.
10. Vertical Access Control
Vertical access control concerns different privilege levels.
Example:
Student
↓
Teacher
↓
Administrator
A student should not automatically gain administrator capabilities.
Conceptually:
Student
│
├── View courses ✅
└── Manage users ❌
Administrator
│
├── View courses ✅
└── Manage users ✅
11. Object-Level Authorization
Modern APIs frequently work with objects.
For example:
GET /api/users/25
The 25 may identify a user.
Another example:
GET /api/orders/104
The 104 may identify an order.
The security question is:
Does the server verify that the authenticated user is allowed to access that specific object?
12. Important Security Principle
Never rely on:
"Nobody will change the ID."
The client is under the user's control.
A secure application must enforce authorization on the server.
Bad design:
Browser
↓
"I am allowed"
↓
Server trusts browser
Better design:
Browser
↓
Request
↓
Server
↓
Authentication
↓
Authorization
↓
Allow/Deny
13. Client-Side vs Server-Side Authorization
Imagine a page hides an administrator button:
if (user != admin)
hide Delete button
That improves the user interface.
But it isn't enough for security.
An attacker could potentially construct a request without using the button.
Therefore:
Security authorization must be enforced server-side.
The UI should reflect permissions, but the server must enforce them.
14. Role-Based Access Control
A common model is RBAC:
Role-Based Access Control
For example:
Roles
│
├── Student
├── Teacher
├── Manager
└── Administrator
Permissions:
Student
├── profile.view
└── attendance.view
Teacher
├── profile.view
├── attendance.view
└── attendance.manage
Administrator
├── user.view
├── user.create
├── user.update
└── user.delete
15. Least Privilege
A very important security principle:
Give users only the permissions they actually need.
For example:
Receptionist
may need:
Lead.View
Lead.Create
Lead.Update
but not:
User.Delete
System.Settings
Database.Admin
This reduces the impact of compromised accounts.
16. Day 15 Lab Architecture
We'll use:
Browser
│
▼
Burp Suite
│
▼
OWASP Juice Shop
│
▼
Docker
│
▼
127.0.0.1
Everything remains local.
🧪 Practical Lab 1
Confirm Juice Shop Is Running
Linux
docker ps
Then:
curl -I http://127.0.0.1:3000
Windows PowerShell
docker ps
Then:
curl.exe -I http://127.0.0.1:3000
macOS
docker ps
Then:
curl -I http://127.0.0.1:3000
If the application isn't running:
docker start <container-id>
17. Start Burp
Open:
Burp Suite
↓
Proxy
↓
Open Browser
Use Burp's dedicated browser for this lab.
Go to:
http://127.0.0.1:3000
18. Set Scope
In Burp:
Target
↓
Site map
↓
127.0.0.1:3000
↓
Add to scope
Then in HTTP History:
Show only in-scope items
Your goal is:
IN SCOPE
└── 127.0.0.1:3000
19. Explore the Login Page
In Juice Shop, navigate to the login functionality.
Don't attempt password attacks.
Instead, simply observe the normal login workflow.
In Burp:
Proxy
↓
HTTP history
Look for the request associated with the login process.
20. Identify the Login Request
You may see a request similar in concept to:
POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
{
"email": "your-lab-account",
"password": "your-lab-password"
}
The exact request can differ between application versions.
Identify:
Method:
Endpoint:
Content-Type:
Body:
⚠️ Don't Save the Password
When documenting the request, write:
Password: [REDACTED]
Never put your actual password in your notes or screenshots.
21. Send Login Request to Repeater
Right-click your authorized local login request:
Send to Repeater
Then open:
Repeater
Do not perform password guessing.
We're only learning the request structure.
22. Observe the Successful Response
If you log in successfully, the application may return authentication information.
The exact response depends on the application's implementation.
You may see information conceptually similar to:
{
"authentication": {
"token": "[REDACTED]"
}
}
Treat any token as sensitive.
23. Authentication Token
Modern web applications may use:
Session Cookie
or:
Bearer Token
For example:
Authorization: Bearer [LAB_TOKEN]
Never publish the actual value.
24. Find Authenticated Requests
After logging into your local Juice Shop lab, browse a normal authenticated feature.
Return to:
Proxy
↓
HTTP history
Find a request that occurs while you're authenticated.
Look for:
Cookie
Authorization
Session
You may discover that the browser automatically attaches authentication information.
25. Authentication vs Authorization in Burp
Burp helps you observe:
Authentication
↓
How does the application know who I am?
Then:
Authorization
↓
How does the application decide what I can access?
This distinction is critical.
🧪 Practical Lab 2
Build an Authorization Map
Using only your local Juice Shop lab, create a table:
| Endpoint/Feature | Authentication Needed? | Expected Permission |
|---|---|---|
| Home | No | Public |
| Product browsing | No/varies | Public |
| Basket | Usually user-specific | Current user |
| Profile | Yes | Current user |
| Admin functionality | Yes | Authorized role |
| User-management functionality | Yes | Authorized role |
The exact behavior depends on the current application state/version.
Your job is to observe, not assume.
26. What Is an Authorization Boundary?
An authorization boundary is where the application decides:
ALLOW
or:
DENY
For example:
Request
↓
Authenticated?
↓
YES
↓
Correct role?
↓
YES
↓
Owns resource?
↓
YES
↓
ALLOW
If any required condition fails:
DENY
27. Horizontal Authorization Test — Safe Method
In your local lab only, identify two legitimate test objects/accounts where the application itself provides them.
For example:
Object A
Object B
Observe how the application normally accesses them.
Do not attempt to access another real person's account.
The safe learning process is:
Normal authorized request
↓
Understand object identifier
↓
Change only the object identifier
↓
Observe server behavior
↓
Determine whether authorization is enforced
28. What Should a Secure Application Do?
Suppose:
GET /api/resource/25
belongs to User A.
User B requests it.
The server should verify authorization.
Conceptually:
User B
↓
Request resource 25
↓
Authorization check
↓
Not allowed
↓
403 / appropriate denial
The application should not simply return User A's private data.
29. Vertical Authorization Test — Safe Method
Use the local lab to identify functionality that is clearly associated with different roles.
For example:
Normal User
↓
Normal Features
Administrator
↓
Administrative Features
The security question is:
Does the server enforce the role restriction, or does it merely hide the interface?
Again, don't attempt to bypass access controls on real applications.
30. Never Trust the UI
Suppose the page shows:
[Dashboard]
[Profile]
[Admin Panel]
and the application hides:
[Admin Panel]
for normal users.
That's not sufficient protection.
A secure application must enforce:
GET /admin
↓
Server authorization
↓
User role?
↓
Allow/Deny
31. Repeater and Authorization
Repeater is useful because you can take a legitimate request from your own lab and inspect how the server responds.
Workflow:
Normal Request
↓
Repeater
↓
Understand
↓
Controlled modification
↓
Server Response
↓
Compare
The key is:
Don't guess blindly. Understand the request first.
32. Status Codes and Authorization
Common responses include:
200 OK
401 Unauthorized
403 Forbidden
404 Not Found
But don't assume:
403 = secure
or:
404 = secure
The important question is whether the server correctly prevents unauthorized access.
33. 401 vs 403 — Again
401
Typically:
Authentication is missing or invalid.
403
Typically:
The server understands who you are but does not permit the action/resource.
The exact behavior is application-dependent.
34. Authorization Checklist
For every protected endpoint ask:
1. Is authentication required?
2. Which user is making the request?
3. Which role does the user have?
4. What resource is being requested?
5. Who owns that resource?
6. What action is being performed?
7. Does the server check authorization?
8. What happens when authorization fails?
This checklist is extremely useful.
35. CRUD and Authorization
Think about CRUD:
Create
Read
Update
Delete
A user might have:
Read own profile ✅
Update own profile ✅
Delete own profile ❌
Read another user ❌
Update another user ❌
Delete another user ❌
Authorization should be evaluated for each operation.
36. API Authorization
Modern applications often expose APIs.
Example:
GET /api/users/25
POST /api/users
PUT /api/users/25
DELETE /api/users/25
A secure API must enforce authorization on every relevant operation.
It isn't enough to protect only the web page.
37. Why APIs Are Important
A user might never see:
Delete User
in the interface.
But the API might still expose:
DELETE /api/users/25
Therefore:
The API itself must enforce authorization.
This is why Burp is useful.
It allows security professionals to understand the underlying HTTP/API communication.
38. Least Privilege in APIs
Imagine an employee application.
Employee:
GET /api/profile
might be allowed.
But:
DELETE /api/employees/25
should require appropriate privileges.
A secure architecture checks:
Authentication
+
Authorization
+
Resource ownership
+
Requested action
39. Practical Linux Investigation
For your local Juice Shop:
Check Docker:
docker ps
Check application:
curl -I http://127.0.0.1:3000
Inspect local listening ports:
ss -tuln
Or:
lsof -nP -iTCP:3000 -sTCP:LISTEN
These commands help confirm your local lab environment.
40. Windows Investigation
Check:
docker ps
Test:
curl.exe -I http://127.0.0.1:3000
Check port:
netstat -ano | findstr :3000
If you need the process information:
Get-Process -Id <PID>
Replace <PID> with the actual process ID shown by netstat.
41. macOS Investigation
Check:
docker ps
Test:
curl -I http://127.0.0.1:3000
Check port:
lsof -nP -iTCP:3000 -sTCP:LISTEN
42. Use curl to Understand Authentication
For a local lab endpoint, you can inspect the response headers:
Linux/macOS
curl -i http://127.0.0.1:3000/
Windows
curl.exe -i http://127.0.0.1:3000/
The -i option displays response headers along with the body.
Do not use this to collect credentials or tokens from real systems.
43. Understanding Cookies Locally
If your local application sends a cookie, curl can show headers:
curl -i http://127.0.0.1:3000/
You may see:
Set-Cookie: ...
Don't copy sensitive values into public notes.
44. Cookie Storage with curl
For a local lab, curl can maintain cookies:
Linux/macOS
curl -c cookies.txt http://127.0.0.1:3000/
Later:
curl -b cookies.txt http://127.0.0.1:3000/
Windows
curl.exe -c cookies.txt http://127.0.0.1:3000/
Then:
curl.exe -b cookies.txt http://127.0.0.1:3000/
This is useful for learning how clients maintain HTTP state.
⚠️ Protect cookies.txt
That file may contain authentication/session information.
Do not:
❌ Upload it to GitHub
❌ Share it
❌ Put it in a blog
❌ Send it to someone
For the lab, you can delete it afterward.
45. Day 15 Main Practical Lab
Step 1 — Start Juice Shop
docker ps
Make sure it is running.
Step 2 — Open Burp
Proxy
↓
Open Browser
Step 3 — Visit
http://127.0.0.1:3000
Step 4 — Set Scope
Target
↓
Site map
↓
127.0.0.1:3000
↓
Add to scope
Step 5 — Login Normally
Use an account you created/are authorized to use in your local lab.
Do not perform password guessing.
Step 6 — Find the Login Request
Open:
Proxy
↓
HTTP history
Find the login request.
Record:
Method:
Endpoint:
Content-Type:
Do not record the actual password or token.
Step 7 — Find an Authenticated Request
After login, visit a normal authenticated feature.
Find its request in HTTP History.
Record:
Endpoint:
Method:
Authentication mechanism:
Status:
Step 8 — Send to Repeater
Choose a normal, authorized request.
Right-click
↓
Send to Repeater
Step 9 — Establish Baseline
Click:
Send
Record:
Status:
Length:
Response type:
Step 10 — Controlled Authorization Observation
If your local lab request contains a legitimate object identifier, change only that identifier to another valid test object that is part of your authorized lab.
Observe:
Status
Response
Data returned
Do not attempt to access real users or other people's information.
46. Day 15 Analysis Table
Complete:
| Item | Observation |
|---|---|
| Login endpoint | ______ |
| Login method | ______ |
| Authentication mechanism | ______ |
| Authenticated endpoint | ______ |
| HTTP method | ______ |
| Object/resource | ______ |
| Baseline status | ______ |
| Controlled test status | ______ |
| Authorization behavior | ______ |
| Security conclusion | ______ |
47. What Does a Secure Result Look Like?
Suppose an unauthorized local test produces:
403 Forbidden
and no sensitive information is returned.
That's evidence that an authorization control may be functioning for that request.
But don't conclude that the entire application is secure.
You need broader testing.
48. What Does a Concerning Result Look Like?
Suppose a user who should not have access receives:
200 OK
with another user's private data.
That could indicate an access-control weakness.
In a real assessment, you would:
Stop
↓
Preserve evidence
↓
Document exact request/response
↓
Determine impact
↓
Report
You would not continue accessing more private records just because the system allowed it.
49. Ethical Testing Principle
Finding one authorization weakness doesn't mean:
"Let's download everything."
Instead:
Confirm
↓
Minimize access
↓
Collect only necessary evidence
↓
Stop
↓
Report
This is an important professional habit.
50. How Developers Fix Access-Control Problems
The server should implement checks such as:
Request
↓
Authenticate
↓
Identify user
↓
Identify resource
↓
Check permission
↓
Check ownership
↓
Allow/Deny
For example:
if (!authenticated):
deny()
if (!user.can("order.view")):
deny()
if (!user.owns(order)):
deny()
allow()
The exact implementation depends on the framework and architecture.
51. Defense-in-Depth
Don't rely on a single control.
A secure application may use:
Authentication
+
Role permissions
+
Object ownership
+
Server-side authorization
+
Input validation
+
Logging
+
Monitoring
This makes the system more resilient.
52. Common Authorization Mistakes
Developers sometimes make mistakes such as:
Mistake 1
Only hiding buttons.
UI restriction ≠ security
Mistake 2
Trusting user-supplied role information.
role=admin
should never be trusted merely because the client sent it.
Mistake 3
Checking authorization on one endpoint but forgetting another.
Mistake 4
Checking authentication but not object ownership.
Mistake 5
Protecting HTML pages but forgetting APIs.
53. Authentication Security Checklist
For a secure application, consider:
☐ Strong password policy
☐ Secure password hashing
☐ MFA where appropriate
☐ Secure session handling
☐ Session expiration
☐ Secure cookies
☐ HttpOnly where appropriate
☐ SameSite configuration
☐ TLS
☐ Rate limiting
☐ Account recovery protection
54. Authorization Security Checklist
☐ Server-side authorization
☐ Least privilege
☐ Role checks
☐ Resource ownership checks
☐ API authorization
☐ Administrative endpoint protection
☐ Deny by default
☐ Consistent authorization
☐ Logging
☐ Security testing
55. Day 15 Security Mindset
Whenever you encounter:
/api/users/25
don't immediately think:
"Can I change 25?"
Think:
Who am I?
↓
What is user 25?
↓
Should I have access?
↓
What permission is required?
↓
Does the server verify it?
↓
What happens when authorization fails?
That's the ethical-hacking mindset we want to develop.
📝 Day 15 Assignment
Answer these questions:
1.
What is authentication?
2.
What is authorization?
3.
What is the difference between horizontal and vertical access control?
4.
What is object-level authorization?
5.
Why must authorization be enforced server-side?
6.
What is RBAC?
7.
What is least privilege?
8.
Why is a session cookie sensitive?
9.
Why should APIs enforce authorization independently?
10.
What is the difference between 401 and 403?
11.
Why shouldn't you simply hide an administrator button?
12.
What should you do if an authorized lab test unexpectedly exposes sensitive information?
13.
Why should you minimize evidence collection during a security assessment?
14.
Why is authentication alone insufficient for application security?
15.
What questions should you ask when testing an access-control boundary?
🏆 Day 15 Challenge
Create an Authorization Matrix for your local Juice Shop lab.
Example:
| Feature | Anonymous | Normal User | Admin | Expected |
|---|---|---|---|---|
| Home | ✅ | ✅ | ✅ | Public |
| Product browsing | ✅ | ✅ | ✅ | Public |
| Own profile | ❌/varies | ✅ | ✅ | User |
| Another user's private data | ❌ | ❌ | Depends | Restricted |
| Admin functionality | ❌ | ❌ | ✅ | Admin |
| User management | ❌ | ❌ | ✅ | Admin |
Do not assume the exact Juice Shop behavior from this example. Verify it in your local lab.
Then write:
"The most important authorization boundary I observed was ______. The server should allow ______ and deny ______."
🔐 Day 15 Golden Rule
Remember:
AUTHENTICATION
↓
WHO ARE YOU?
↓
AUTHORIZATION
↓
WHAT ARE YOU ALLOWED TO DO?
↓
RESOURCE OWNERSHIP
↓
WHAT ARE YOU ALLOWED TO ACCESS?
↓
SERVER-SIDE ENFORCEMENT
↓
ALLOW / DENY
LEARNING PURPOSE ONLY: Practice these concepts only inside your local Juice Shop lab or another explicitly authorized environment. Never test another person's account or attempt to access private information.
✅ Day 15 Summary
Today you learned:
Authentication
Authorization
Sessions
Cookies
Authentication tokens
Horizontal access control
Vertical access control
Object-level authorization
RBAC
Least privilege
Authorization boundaries
CRUD authorization
API authorization
Server-side enforcement
401 vs 403
Burp HTTP History
Burp Repeater
Authorization matrices
Linux commands
Windows PowerShell commands
macOS commands
Safe access-control testing
🔑 Most Important Lesson
Authentication tells the application who you are. Authorization determines what you're allowed to do. A secure application must enforce both on the server.
🔜 Day 16 — SQL Injection Fundamentals
Tomorrow we'll begin one of the most famous web-security vulnerabilities:
💉 SQL Injection
We'll learn:
What SQL is
How web applications communicate with databases
SQL queries
User input and database queries
Why unsafe query construction is dangerous
Parameterized queries
Prepared statements
SQL injection concepts
Safe demonstrations inside your local Juice Shop/training lab
How to recognize vulnerable vs secure code
Linux, Windows and macOS practical exercises
No real-world targets
🔐 LEARN → UNDERSTAND → TEST YOUR LOCAL LAB → ANALYZE → FIX → SECURE.
No comments:
Post a Comment