Day 1 – Understanding the Web Before Breaking It
Most people jump straight into payloads, tools, and exploit chains.
Professional testers don’t.
They start by understanding how the web actually works, because every OWASP Top 10 vulnerability is a failure of fundamentals—not magic.
This blog lays the technical groundwork required before diving into practical exploitation aligned with the OWASP Top 10.
1. What Is the Internet? (Pentester Perspective)
At its core, the Internet is a global system of interconnected computer networks that communicate using standardized protocols, primarily the TCP/IP stack. However, from a web application security standpoint, the Internet is not just “a network” — it is a complex chain of trust relationships.
When a user accesses a website, their request does not travel directly to the server. It traverses multiple intermediaries:
Local network devices
ISP routers
Internet exchange points
Content Delivery Networks (CDNs)
Load balancers
Reverse proxies
Application servers
Each hop introduces latency, transformation, filtering, and trust assumptions.
From an attacker’s mindset, the Internet is:
A distributed attack surface
A medium where traffic can be observed, altered, replayed, or blocked
A system where misplaced trust leads to compromise
For example:
Applications often trust headers added by upstream proxies (like
X-Forwarded-For)Developers assume TLS terminates securely at the edge
Internal services are assumed unreachable from the Internet
Pentesters routinely exploit these assumptions by:
Spoofing headers
Bypassing CDN restrictions
Accessing origin servers directly
Leveraging exposed admin interfaces
Key insight:
The Internet is not secure by default. It is merely connected by agreement. Security is layered on top — often inconsistently.
Understanding this helps testers identify where security controls are expected but not enforced, which is the root cause of many real-world breaches.
2. What Is an IP Address?
An IP address is a logical identifier assigned to a device participating in a network. It enables routing, communication, and identification.
There are two main versions:
IPv4 (32-bit, e.g.,
192.168.1.1)IPv6 (128-bit, e.g.,
2001:db8::1)
From a security perspective, IP addresses are used for:
Access control
Rate limiting
Geo-fencing
Logging and attribution
However, these controls are frequently flawed.
Key distinctions every pentester must understand:
Public IPs → Internet-accessible, external attack surface
Private IPs → Internal networks (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16)Static IPs → Long-term exposure risk
Dynamic IPs → Attribution challenges
Common vulnerabilities tied to IP handling:
IP-based authentication bypass
Trusting internal IP ranges without validation
Leaking internal IPs via error messages
SSRF exploiting access to internal IPs
For example, many applications restrict admin functionality to “internal IPs.”
Through SSRF or proxy misconfigurations, attackers can appear internal without actually being internal.
Pentester takeaway:
IP addresses are identifiers, not identities. Trusting them blindly is a design flaw.
3. What Is DNS?
DNS (Domain Name System) translates human-readable domain names into IP addresses. Without DNS, the web would be unusable at scale.
The DNS resolution process involves:
Browser cache
Operating system resolver
Recursive resolver
Root name servers
TLD servers
Authoritative name servers
From a security standpoint, DNS is a goldmine for reconnaissance.
Why attackers care about DNS:
It reveals infrastructure
It exposes subdomains
It leaks internal naming conventions
It enables takeover opportunities
Common DNS-related issues:
Dangling DNS records
Orphaned subdomains pointing to decommissioned services
Overly permissive wildcard records
Split-horizon DNS misconfigurations
Subdomain takeover is a direct result of:
DNS pointing to a resource that no longer exists, but can be claimed by an attacker.
DNS is often neglected because it is considered “infrastructure,” not “application.”
That assumption is wrong — DNS weaknesses frequently lead to full application compromise.
Pentester mindset:
If DNS is wrong, everything above it is already broken.
4. Ports and Services
Ports are logical endpoints that allow multiple services to operate on a single IP address. Services listen on ports to accept connections.
Examples:
80 → HTTP
443 → HTTPS
22 → SSH
3306 → MySQL
In web application testing, ports matter because:
Exposed services expand attack surface
Non-standard ports often host forgotten admin panels
Development services sometimes leak into production
Security issues arise when:
Services are exposed unintentionally
Authentication is weak or missing
Version information is leaked
Services are outdated
A common real-world scenario:
Application secured on port 443, but admin panel exposed on port 8080 with no auth.
Rule for pentesters:
Every open port is a question. Every listening service deserves an answer.
5. How Websites Work
At a technical level, every website operates on a request–response model. While this sounds simple, nearly all web vulnerabilities exist somewhere inside this lifecycle.
Let’s break it down properly.
Step 1: Client Sends a Request
When a user visits a website or submits a form, the browser sends an HTTP request that includes:
URL and path
HTTP method (GET, POST, etc.)
Headers (cookies, tokens, user-agent)
Parameters (query strings, body data)
From a pentester’s perspective, this request is fully under attacker control. Anything the client sends must be treated as untrusted — yet many applications fail to do so.
Step 2: Server Receives and Processes Input
The server parses the request and extracts:
User input
Session identifiers
Authorization context
This is where input validation and sanitization should occur. When it doesn’t, vulnerabilities such as SQL Injection, XSS, and command injection emerge.
Step 3: Business Logic Execution
Business logic defines how the application behaves.
Examples:
Who can access what
How money transfers work
How roles are enforced
Most critical vulnerabilities are not syntax issues — they are logic flaws, such as:
Missing authorization checks
Incorrect workflow enforcement
Race conditions
These flaws cannot be detected by scanners alone. They require understanding how the application is intended to work versus how it actually behaves.
Step 4: Database Interaction
The application may:
Fetch user data
Update records
Validate credentials
Security failures here include:
Improper query construction
Excessive database privileges
Trusting client-supplied identifiers
Step 5: Response Generation
The server sends a response containing:
Status code
Headers
Body content
Information leakage often happens at this stage via:
Verbose error messages
Stack traces
Debug data
Pentester takeaway:
A vulnerability is rarely a single mistake. It is usually a chain of small trust failures across this lifecycle.
6. Backend vs Frontend
Understanding the separation between frontend and backend is foundational to WAPT.
Frontend
Runs in the user’s browser
Written in HTML, CSS, JavaScript
Controls presentation and user experience
Backend
Runs on the server
Handles authentication, authorization, and data access
Enforces security rules
Here’s the core security rule:
The frontend can be manipulated. The backend must never trust it.
Yet many applications violate this rule.
Common Frontend Trust Mistakes
Hiding buttons instead of enforcing permissions
Disabling form fields instead of validating server-side
Relying on JavaScript checks for security decisions
Attackers bypass frontend controls by:
Modifying requests directly
Calling APIs manually
Replaying requests with altered parameters
This is why Broken Access Control consistently ranks as the #1 risk.
Pentester mindset:
If a feature exists in the frontend, assume the backend endpoint exists — and test it directly.
7. Web Application Infrastructure
Modern web applications are multi-layered systems, not single servers.
A typical production setup includes:
Browser (client)
CDN (caching, DDoS protection)
WAF (rule-based filtering)
Load balancer
Web server
Application server
Database
External APIs
Each layer introduces:
Configuration complexity
Trust assumptions
Potential bypass paths
Why Pentesters Care About Layers
Security controls applied at one layer may:
Be absent at another
Be bypassed internally
Behave inconsistently
Examples:
WAF blocking payloads, but backend APIs accepting them
CDN hiding origin server, but origin IP exposed via DNS
Authentication enforced on UI but missing on APIs
8. HTTP Response Codes
HTTP response codes communicate how the server handled a request.
For pentesters, they reveal application logic and security posture.
Commonly Abused Codes
200 OK→ Action succeeded302 Found→ Redirect logic401 Unauthorized→ Authentication missing403 Forbidden→ Authorization check500 Internal Server Error→ Backend failure
Why They Matter
By observing how response codes change when:
Parameters are removed
IDs are modified
Tokens are altered
Testers can infer:
Authorization logic
Validation rules
Hidden application states
A subtle difference between 401 and 403 can reveal privilege boundaries.
Pentester rule:
Always test the same request under different roles and states. Compare responses, not just content.
9. Making Requests
Everything in web application pentesting revolves around HTTP requests.
HTTP Methods and Intent
-
GET → Retrieve data
-
POST → Submit data
-
PUT/PATCH → Modify data
-
DELETE → Remove data
Security failures occur when:
-
Methods are not properly restricted
-
Authorization checks are method-specific
-
APIs accept unintended verbs
Why Intercepting Requests Is Critical
Tools like Burp Suite allow testers to:
-
Observe raw requests
-
Modify parameters
-
Replay actions
-
Change roles and tokens
This exposes:
-
Hidden parameters
-
Trust assumptions
-
Inconsistent validation
Reality check:
If you can modify it in a request, you can test it.
If you can test it, you can likely break it.
