 |
| Ethical Hacking |
🛡️ Ethical Hacking — Day 11
Web Application Fundamentals: HTTP, Cookies, Sessions & Authentication
⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. Perform practical exercises only against applications you own, deliberately vulnerable training applications, or systems for which you have explicit permission to test. Never test random websites or applications.
Welcome to Day 11.
So far, you've learned:
Networking fundamentals
Linux, Windows & macOS networking
Nmap
Wireshark
Packet analysis
DNS
Reconnaissance
Today we move into one of the most important areas of ethical hacking:
🌐 Web Application Security
Before learning vulnerabilities such as SQL injection, XSS, CSRF, or authentication weaknesses, you need to understand how a web application actually works.
🎯 Day 11 Learning Objectives
Today you'll learn:
How websites work
Client vs server
HTTP and HTTPS
URLs
HTTP methods
Request and response
HTTP headers
Status codes
Cookies
Sessions
Authentication
Authorization
Parameters
Forms
APIs
Browser Developer Tools
curlA safe local web-security lab
Linux, Windows and macOS practical exercises
1. How Does a Website Work?
When you open:
https://example.com
a lot happens behind the scenes.
Simplified:
Browser
│
│ DNS
▼
IP Address
│
│ TCP/TLS
▼
Web Server
│
│ Application
▼
Database
Then the response travels back:
Database
↓
Application
↓
Web Server
↓
Browser
2. Client vs Server
Client
Usually your:
Browser
Mobile app
Desktop application
Server
The system providing the service.
For example:
Client
Chrome / Safari / Firefox
│
│ HTTP request
▼
Web Server
│
▼
Application
│
▼
Database
3. What Is HTTP?
HTTP = Hypertext Transfer Protocol
It defines how clients and servers communicate.
Example:
GET /products HTTP/1.1
Host: example.com
The server responds:
HTTP/1.1 200 OK
<html>
...
</html>
4. What Is HTTPS?
HTTPS is HTTP protected by TLS.
Conceptually:
HTTP
↓
TLS encryption
↓
Network
Therefore:
HTTP
❌ No TLS protection
HTTPS
✅ TLS protection
HTTPS protects the confidentiality and integrity of traffic between the client and server, assuming TLS is correctly configured.
5. Understanding a URL
Consider:
https://example.com/products?id=25
Break it down:
https://
↓
Protocol
example.com
↓
Hostname
/products
↓
Path
?id=25
↓
Query parameter
This structure becomes very important when studying web vulnerabilities.
6. HTTP Request
A request can look like:
GET /products?id=25 HTTP/1.1
Host: example.com
User-Agent: Browser
Accept: text/html
The browser sends the request to the server.
7. HTTP Response
The server may respond:
HTTP/1.1 200 OK
Content-Type: text/html
<html>
...
</html>
So:
REQUEST
↓
SERVER
↓
RESPONSE
This is the foundation of web application security.
8. HTTP Methods
The most important HTTP methods for beginners are:
| Method | Typical purpose |
|---|---|
| GET | Retrieve information |
| POST | Submit/create/process data |
| PUT | Replace/update a resource |
| PATCH | Partially update a resource |
| DELETE | Delete a resource |
| HEAD | Request headers without normal response body |
| OPTIONS | Discover supported methods/options |
Don't assume the method alone determines what an application actually does. The server-side implementation matters.
9. GET Request
Example:
GET /products?id=25 HTTP/1.1
Host: example.com
The parameter is:
id=25
The server may use it to retrieve a product.
10. POST Request
A POST request may look like:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=student&password=example
This is why authentication forms must be handled carefully.
⚠️ Never test credentials or authentication mechanisms against accounts you don't own or have explicit permission to test.
11. HTTP Headers
Headers carry additional information.
Example:
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Content-Type: application/json
Authorization: ...
Cookie: ...
Important categories include:
Request Headers
↓
Client → Server
Response Headers
↓
Server → Client
12. Important Request Headers
Host
Host: example.com
Identifies the requested host.
User-Agent
User-Agent: Mozilla/5.0
Provides information about the client.
Accept
Accept: text/html
Indicates acceptable response formats.
Content-Type
Content-Type: application/json
Describes the request/response body format.
13. Important Response Headers
Examples:
Content-Type
Content-Length
Cache-Control
Set-Cookie
Location
Content-Security-Policy
Strict-Transport-Security
These are important when analyzing web security.
14. HTTP Status Codes
You've already seen some of these in Day 10.
Successful
200 OK
201 Created
204 No Content
Redirect
301 Moved Permanently
302 Found
307 Temporary Redirect
308 Permanent Redirect
Client-side problems
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
429 Too Many Requests
Server-side problems
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
15. 401 vs 403
This is particularly important.
401
Usually indicates that authentication is required or hasn't been successfully provided.
401 Unauthorized
403
Usually means the server understood the request but refuses to authorize access.
403 Forbidden
The exact semantics depend on the application's implementation.
16. Cookies
Web applications often need to remember information about a browser.
That's where cookies come in.
Example:
Set-Cookie: session_id=abc123
The browser stores the cookie and may later send:
Cookie: session_id=abc123
Conceptually:
Server
│
│ Set-Cookie
▼
Browser
│
│ Cookie
▼
Server
17. Why Are Cookies Important?
Cookies can contain:
Session identifiers
Preferences
Tracking identifiers
Application state
A session cookie can be security-sensitive.
Therefore:
Never publish real authentication/session cookies in screenshots, blog posts, GitHub repositories, or tutorials.
18. Important Cookie Security Attributes
You may encounter:
Secure
HttpOnly
SameSite
Secure
The browser should send the cookie only over HTTPS.
HttpOnly
Helps prevent JavaScript from directly accessing the cookie.
SameSite
Controls when cookies are sent in cross-site contexts and can help mitigate certain cross-site request risks.
19. Sessions
HTTP itself is fundamentally stateless.
But applications often need to remember:
"This browser is logged in."
A common architecture is:
Browser
│
│ Session Cookie
▼
Web Application
│
▼
Session Data
For example:
Browser
↓
session_id=ABC123
↓
Server
↓
User = authenticated
The actual architecture varies by framework.
20. Authentication vs Authorization
These are frequently confused.
Authentication
Who are you?
Examples:
Username + Password
Passkey
MFA
Certificate
Authorization
What are you allowed to do?
Example:
User
↓
Can view profile
Admin
↓
Can view profile
↓
Can manage users
Remember:
Authentication
↓
Identity
Authorization
↓
Permissions
21. Example
Suppose:
Alice
logs in successfully.
Authentication:
Is Alice really Alice?
↓
YES
Authorization:
Can Alice delete another user?
↓
NO
An application can have strong authentication but poor authorization.
That's why both matter.
22. Parameters
Web applications receive input through many places.
URL parameter
/products?id=25
Form parameter
username=student
JSON
{
"product_id": 25
}
HTTP header
Authorization: Bearer ...
Cookie
Cookie: session_id=...
Security testing often involves understanding how an application handles each type of input.
23. Forms
A login form might conceptually be:
┌──────────────────────────┐
│ Username │
│ [______________________] │
│ │
│ Password │
│ [______________________] │
│ │
│ [ LOGIN ] │
└──────────────────────────┘
The browser converts that input into an HTTP request.
For example:
POST /login
with form data.
24. APIs
Modern applications frequently communicate through APIs.
Example:
GET /api/products/25
The server may respond:
{
"id": 25,
"name": "Laptop",
"price": 50000
}
Instead of returning HTML, the server returns structured data.
25. REST API Basics
You may see:
GET /api/users
GET /api/users/10
POST /api/users
PUT /api/users/10
PATCH /api/users/10
DELETE /api/users/10
Conceptually:
GET
↓
Read
POST
↓
Create/Process
PUT/PATCH
↓
Update
DELETE
↓
Delete
The actual behavior is defined by the API.
26. Browser Developer Tools
Your browser already provides a powerful learning tool.
Open:
Chrome/Edge → Developer Tools → Network
or:
Safari → Develop → Show Web Inspector → Network
You'll see requests such as:
Name
Method
Status
Type
Initiator
Size
Time
Click a request.
You can inspect:
Headers
Payload
Response
Cookies
Timing
This is one of the best ways to understand how web applications work.
🧪 Practical Lab 1 — Inspect Your Own Web Traffic
Use a website/application you own or an intentionally provided training application.
Open Developer Tools.
Go to:
Network
Load the page.
Click a request.
Record:
URL:
Method:
Status:
Request Headers:
Response Headers:
Content-Type:
Do not record:
Password
Session Cookie
Authorization Token
API Key
27. curl — Your Command-Line Web Client
You already used curl in Day 10.
Today we'll use it more.
Check:
Linux/macOS
curl --version
Windows
curl.exe --version
28. GET Request
Linux/macOS
curl https://example.com
Windows
curl.exe https://example.com
This requests the page.
29. Headers Only
Linux/macOS
curl -I https://example.com
Windows
curl.exe -I https://example.com
This is useful for examining response headers.
30. Verbose Mode
You can use:
curl -v https://example.com
Windows:
curl.exe -v https://example.com
Verbose output can expose request/response details.
Use it only against authorized applications.
31. Follow Redirects
Some websites redirect:
http://example.com
↓
https://example.com
You can ask curl to follow redirects:
Linux/macOS
curl -L https://example.com
Windows
curl.exe -L https://example.com
32. Inspect HTTP Methods Safely
You can use curl against your own local training application.
For example:
curl -X OPTIONS http://127.0.0.1:8080/
Windows:
curl.exe -X OPTIONS http://127.0.0.1:8080/
This is a safe way to learn about HTTP methods if you have a local application listening on port 8080.
If you don't have one, don't randomly send requests to public servers.
33. Build Your Own Web Security Lab
For the next part of this course, we'll use a deliberately vulnerable application rather than testing random websites.
Good training environments include:
OWASP Juice Shop
WebGoat
DVWA
PortSwigger Web Security Academy labs
The important concept:
Your Computer
↓
Training Application
↓
Practice
↓
Observe
↓
Fix/Understand
This gives you a safe environment to learn vulnerabilities later.
34. Localhost Lab Concept
A local lab might look like:
┌───────────────────────────────┐
│ YOUR MAC │
│ │
│ Browser │
│ ↓ │
│ Proxy / Developer Tools │
│ ↓ │
│ Vulnerable Training App │
│ ↓ │
│ Local Database │
└───────────────────────────────┘
The entire environment can remain on your own machine.
35. Linux Lab Check
First check whether something is listening locally:
ss -tuln
You might find:
127.0.0.1:8080
Then:
curl http://127.0.0.1:8080/
36. Windows Lab Check
PowerShell:
netstat -ano
Look for a local service such as:
127.0.0.1:8080
Then:
curl.exe http://127.0.0.1:8080/
37. macOS Lab Check
Terminal:
lsof -nP -iTCP -sTCP:LISTEN
Look for your local application.
Then:
curl http://127.0.0.1:8080/
38. If Port 8080 Is Empty
That's completely normal.
It means you don't currently have a service running there.
Don't start scanning random IP addresses to find one.
Instead, we'll install a deliberately vulnerable application in a future lab.
🧪 Day 11 Practical Lab #2
Build a Web Request in Your Head
Suppose your browser requests:
https://example.com/products?id=25
Identify:
Protocol:
________________
Host:
________________
Path:
________________
Parameter:
________________
Answer:
Protocol = HTTPS
Host = example.com
Path = /products
Parameter = id=25
🧪 Day 11 Practical Lab #3
Analyze a Request
Imagine this request:
POST /login HTTP/1.1
Host: lab.example
Content-Type: application/x-www-form-urlencoded
username=student&password=example
Identify:
Method
POST
Path
/login
Content Type
application/x-www-form-urlencoded
Parameters
username
password
This is the type of analysis you'll eventually perform on real authorized applications.
39. Security Questions to Ask About Every Web Request
Whenever you see a request, ask:
1. What is the method?
GET?
POST?
PUT?
DELETE?
2. What is the endpoint?
/login
/api/users
/products
3. What input does it accept?
Query
Form
JSON
Headers
Cookies
4. Who is authenticated?
Anonymous?
User?
Admin?
5. What authorization is applied?
What is this user allowed to access?
6. What does the server return?
200?
403?
404?
500?
7. Is sensitive data exposed?
Passwords?
Tokens?
Personal data?
This mindset will become extremely important in upcoming lessons.
40. Web Application Architecture
A typical application may look like:
INTERNET
│
▼
Load Balancer
│
▼
Web Server
│
▼
Application
│
┌──────────┴──────────┐
▼ ▼
Database Cache
Modern systems can be much more complicated:
Browser
↓
CDN
↓
WAF
↓
Load Balancer
↓
API Gateway
↓
Microservices
↓
Databases
Reconnaissance helps identify the exposed components.
41. Common Web Security Areas
Later in this course, we'll study topics such as:
Authentication
Authorization
Input Validation
SQL Injection
XSS
CSRF
File Upload Security
Session Management
Access Control
API Security
Security Headers
Configuration
But don't jump directly to exploitation.
First understand how the application works.
42. The Security Testing Method
For every future vulnerability, we'll follow:
Understand
↓
Observe
↓
Form a hypothesis
↓
Test in an authorized lab
↓
Verify
↓
Understand impact
↓
Learn remediation
↓
Document
This is much better than blindly copying exploit commands.
43. Day 11 Cross-Platform Practical
🐧 Linux
curl --version
curl -I https://example.com
curl -v https://example.com
dig example.com
ss -tuln
🪟 Windows
curl.exe --version
curl.exe -I https://example.com
curl.exe -v https://example.com
nslookup example.com
netstat -ano
🍎 macOS
curl --version
curl -I https://example.com
curl -v https://example.com
dig example.com
lsof -nP -iTCP -sTCP:LISTEN
Remember:
These public-domain examples are for basic HTTP/DNS demonstrations. For active security testing, use your own domain or authorized lab.
📊 Day 11 Analysis Table
Create this table:
| Item | Your Observation |
|---|---|
| URL | ______ |
| HTTP method | ______ |
| Status code | ______ |
| Content-Type | ______ |
| Server header | ______ |
| Cookies present? | ______ |
| HTTPS/TLS? | ______ |
| Query parameters | ______ |
| Request body | ______ |
| Authentication used? | ______ |
Do not copy real session cookies, passwords, API keys, or authorization tokens into your notes.
🧠 Day 11 Assignment
Answer these questions:
1.
What is the difference between a client and a server?
2.
What is HTTP?
3.
What does HTTPS add to HTTP?
4.
What is the difference between GET and POST?
5.
What is an HTTP header?
6.
What is a cookie?
7.
What is a session?
8.
What is authentication?
9.
What is authorization?
10.
What is the difference between 401 and 403?
11.
What is a URL query parameter?
12.
What is an API?
13.
What does curl -I do?
14.
Why should you never publish session cookies or API tokens?
15.
Why should we use a deliberately vulnerable local application for practical web-security training?
🏆 Day 11 Challenge
Use your own website or a deliberately vulnerable local lab.
Perform:
1️⃣ Open Developer Tools
↓
2️⃣ Open Network tab
↓
3️⃣ Load the application
↓
4️⃣ Select one request
↓
5️⃣ Identify HTTP method
↓
6️⃣ Identify URL/path
↓
7️⃣ Identify parameters
↓
8️⃣ Inspect request headers
↓
9️⃣ Inspect response headers
↓
🔟 Identify status code
Then write:
"The browser sent a ______ request to ______. The server returned ______. The request contained ______, and the response contained ______."
Do not include passwords, tokens, cookies, or other sensitive values.
🔐 Ethical Hacking Reminder
LEARNING PURPOSE ONLY: Everything in this tutorial is for educational and authorized security testing. Do not experiment with login forms, parameters, cookies, APIs, or HTTP methods on websites you don't own or have explicit permission to test.
A website being publicly accessible does NOT mean you have permission to security-test it.
✅ Day 11 Summary
Today you learned:
How websites work
Client/server architecture
HTTP
HTTPS
URLs
HTTP methods
HTTP requests
HTTP responses
Headers
Status codes
Cookies
Sessions
Authentication
Authorization
Parameters
Forms
APIs
Developer Tools
curlLocal web-security labs
Linux practical commands
Windows PowerShell commands
macOS commands
🔑 Most Important Lesson
Before you learn how to attack a web application, learn how the web application communicates.
Once you can look at a request and immediately understand:
Who?
What?
Where?
How?
With what data?
What response?
What permissions?
you have built the foundation needed for serious web application security.
🔜 Day 12 — Burp Suite Fundamentals
Tomorrow we'll introduce Burp Suite in a safe local lab.
You'll learn:
What Burp Suite is
Proxy concept
Browser → Burp → Server
Installing Burp Suite
Configuring a browser
Intercepting your own requests
HTTP history
Repeater
Request/response modification in a local lab
Understanding parameters
Comparing browser traffic with Burp
Linux, Windows & macOS setup
Learning-purpose-only vulnerable lab
🔐 LEARN → OBSERVE → ANALYZE → PRACTICE SAFELY → SECURE.
No comments:
Post a Comment