How a Web Server Actually Works
A web server is a computer system that stores, processes, and delivers web pages to clients over HTTP. A client's browser sends an HTTP request for a resource (a page, photo, video); the server pulls that content from storage or an application server and sends back an HTTP response. If it can't find what was asked for, it returns an error message instead.
A web server is really a hardware/software application that hosts websites and implements the client-server model: the server plays "server," the browser plays "client." Each server has a domain name and IP address, can host more than one website, and any machine can become a web server if it runs the right server software and has an internet connection. Servers are chosen for their ability to handle server-side programming, security, and site-building/search tools - and attackers typically go after vulnerable software components and configuration errors to compromise them.
Why Attackers Shifted to the Web Layer
Firewalls, IDS, and IPS handle most network- and OS-level attacks well. That forces attackers "up the stack" to web servers and web applications instead - because a web server hosting a public app is, by design, reachable from anywhere on the internet. A poorly configured web server can punch a hole straight through an otherwise well-designed firewall.
Why Web Servers Get Hacked
Common Goals Behind Web Server Hacking
Attacker goals can be technical or purely personal:
Technical / Financial Goals
- Stealing credit cards or credentials via phishing
- Roping the server into a botnet for DoS/DDoS attacks
- Compromising a database
- Obtaining closed-source applications
- Hiding and redirecting traffic
- Escalating privileges
Personal Motives
- Pure curiosity
- Completing a self-set intellectual challenge
- Damaging the target organization's reputation
Dangerous Oversights That Create Vulnerable Servers
Poorly trained admins, inadequate knowledge, negligence, laziness, and inattentiveness toward security are the biggest threats to web server security. Common oversights:
- Not updating the web server with the latest patches
- Using the same sysadmin credentials everywhere
- Allowing unrestricted internal and outbound traffic
- Running unhardened applications and servers
Four Perspectives on the Same Problem
Root Causes & Impact of Compromise
- Unpatched software
- Poor security configuration
- Vulnerable web applications
- Weak authentication
- Human error / administrator negligence
- Lack of security awareness
- Default credentials left in place
- Unnecessary services enabled
- Data theft and tampering
- Website defacement
- Malware distribution
- Privilege escalation
- Secondary attacks against users/partners
Mnemonic - Why Servers Get Popped: "PASS-U"
P-A-S-S-U = Patching skipped, Authentication weak, Security misconfigured, Services unnecessary, User (human) error. Five root causes, one password-shaped word.
Web Server Vulnerabilities & Attacks
The Named Vulnerability List
Mnemonic - Web Server Vulnerabilities: "Big Dogs Bark, People Even Fear Unfriendly Snakes"
B-D-B-P-E-F-U-S = Buffer overflow, DoS/DDoS, Banner info, Permissions, Error messages, Features (unnecessary), User accounts, SQL injection. Eight named vulnerabilities from the slide, one weird sentence.
The Named Attacks
DNS Server Hijacking
DNS resolves a domain name to an IP address. In DNS server hijacking, the attacker compromises the DNS server and changes its mapping settings to point toward a rogue DNS server. When a user types a legitimate URL, the poisoned settings redirect them to the attacker's fake site instead.
DNS Amplification Attack
A DDoS technique that abuses open DNS resolvers: the attacker sends small spoofed-source DNS queries that trigger much larger DNS responses, all directed at the victim - "amplifying" a small request into a crushing flood of traffic.
Directory Traversal Attack
Exploits insufficient input validation on file paths (e.g. using ../../ sequences) to escape the intended web root and read arbitrary files elsewhere on the server's filesystem.
Man-in-the-Middle / Sniffing Attack
The attacker positions themselves between the client and the server (or simply sniffs unencrypted traffic) to intercept, read, or alter data in transit.
Web Cache Poisoning
Attacks the reliability of an intermediate web cache. The attacker forces the server's cache to flush its real content, then sends a specially crafted request so infected content gets stored in the cache instead. Every user who requests that URL through the cache gets the malicious content until the cache is flushed. Possible when the web server/application has HTTP Response-Splitting flaws.
Session Hijacking with Cookies
An attacker steals or predicts a valid session cookie and replays it to impersonate the legitimate user - no password needed, since the session is already "logged in."
Web Server Attack Methodology
Banner Information
A banner reveals information about the web server. Connecting to port 80 (HTTP) is the classic way to receive and read a web server's banner - which usually names the software and version, handing the attacker a shortlist of known exploits.
Control access to a server and its content - but can easily be misconfigured.
Have the potential to allow access to locations on the web server that should not be accessible.
Unnecessary Features
Servers should be purpose-built for the role they fill in the organization. Anything not essential to that role should be eliminated. Hardening removes features, services, and applications that aren't necessary for a system to do its job - if a feature isn't needed, disable it, or better yet, uninstall it.
User Accounts
Most operating systems ship preconfigured with user accounts and groups already defined and in place. These accounts can easily be discovered through research by an attacker, who then uses them to gain access to the system.
Security Best Practices
- Disable or remove default accounts
- Create new ones that correspond to how an administrator will actually use the service
When the Code on Top Is the Weak Link
Even if a web server is configured securely and sits behind a firewall, a poorly coded web application deployed on top of it can still hand an attacker a way in. If developers skip secure coding practices, attackers get the chance to exploit application-level vulnerabilities and compromise both the app and the underlying server.
Mnemonic - The Four Web App Attacks: "Cats Understand XML SQL"
C-U-X-S = Cookie tampering, Unvalidated input/file injection, XSS, SQL injection - exactly the four the slides call out under "Web Application Attacks."
XSS in Practice - Three Flavors (Enrichment)
The slides name XSS as "malicious script injected into a trusted site, delivered to another user" - in practice, that plays out in three well-known ways worth knowing cold:
Reflected XSS
The payload rides in the request (e.g. a URL parameter) and is immediately "reflected" back in the response - only the person who clicks the crafted link is affected.
Stored XSS
The payload is saved server-side (e.g. in a comment or profile field) and served to every visitor who views that page - much more dangerous, no crafted link needed.
DOM-Based XSS
The vulnerability lives entirely in client-side JavaScript that unsafely writes attacker-controlled data into the page's DOM - the server may never even see the malicious payload.
Mnemonic - XSS Types: "RSD"
R-S-D = Reflected (bounces back once), Stored (sticks around for everyone), DOM-based (never leaves the browser). Think "Reflected once, Stored forever, DOM never left home."
Imagine a search box that echoes your query straight back into the page: Results for: [your input]
Fix: HTML-encode/escape all user-supplied output before it's rendered, and use a Content-Security-Policy to block inline scripts.
SQL Injection: How the "Malicious Code in a String" Attack Actually Works
The slides define SQL injection simply: the attacker injects malicious code into strings later passed to the SQL server for execution. In practice, this happens whenever user input is concatenated directly into a SQL query instead of being safely parameterized. Below is a worked walkthrough plus the standard categories of SQLi you'll see referenced across the ethical-hacking literature and tools.
A vulnerable login query built by string concatenation:
If the attacker types this into the username field:
the query the database actually executes becomes:
Since '1'='1' is
always true and
-- comments out the rest of the line, the
password check never runs - the attacker is logged in as the first user in the table, no valid credentials
needed.
Categories of SQL Injection
In-Band SQLi
The attacker uses the same channel to launch the attack and gather results - the most common and easiest to exploit. Includes both error-based and union-based SQLi.
Blind SQLi
No data is returned directly in the response. The attacker infers information indirectly - via true/false behavior (boolean-based) or response timing (time-based).
UNION operator
to append a second query and pull
extra data into the visible results.SLEEP(5)) and infers truth from how long the
response takes.Mnemonic - SQLi Types: "EUBT"
E-U-B-T = Error-based, Union-based (both in-band), Boolean-blind, Time-blind (both blind). "Every Ugly Bug Talks" - eventually, one way or another, the database always talks.
Common Tools
sqlmap
The industry-standard automated tool for detecting and exploiting SQL injection, enumerating databases, dumping data, and even gaining OS-level access through a vulnerable DB connection.
Burp Suite
An intercepting proxy used to capture, inspect, and modify HTTP requests - the standard way testers craft and replay SQLi/XSS payloads by hand before (or instead of) automating with sqlmap.
Defense: Parameterize, Don't Concatenate
The single most effective countermeasure is parameterized queries / prepared statements - user input is always treated as data, never as executable SQL. Pair this with input validation, least-privilege database accounts, and stored procedures used correctly (not as a substitute for parameterization).
Session Management Issues & Encryption Weaknesses
What Is a Session?
A session represents the connection a client has with the server application. It typically has a unique identifier, some form of encryption, and other parameters. Session information is high-value: if an attacker gets it, they get access to confidential information without needing to authenticate normally.
Session Vulnerabilities
- Long-lived sessions that never expire
- Missing or broken logout features
- Insecure or weak session identifiers
- Granting session IDs to unauthorized users
- Absent or inadequate password change controls
- Inclusion of unprotected information in cookies
Encryption Weaknesses
Use short keys or are poorly designed/implemented, which lets an attacker decrypt data easily and gain unauthorized access.
Implementations such as SSL may themselves have poor programming, undermining whatever encryption strength the algorithm was supposed to provide.
Exam Trivia Note
The six session vulnerabilities above are a classic multiple-select exam list - know them as a set, not just individually.
Database Attacks & Vulnerabilities
Databases store an organization's most critical and sensitive information, and they're almost always connected to web applications that sit exposed on the internet. A single weakness anywhere in that chain can expose the entire system - which makes databases high-value attack targets.
Database Vulnerabilities
- Weak or default passwords
- Excessive user privileges
- Unpatched database software
- Insecure configuration
- Lack of encryption
- Shared database accounts
- Weak authentication mechanisms
- No role-based access control
- Open database ports
- Poor backup protection
- Default settings left unchanged
- Unnecessary database services enabled
- Weak auditing and logging
- Inadequate monitoring
- Human configuration errors
Mnemonic - 15 Database Vulnerabilities in 5 Buckets
Group them as Credentials (weak/default/shared passwords, weak auth), Access Control (excessive privileges, no RBAC), Patching/Config (unpatched, insecure/default config, unnecessary services, open ports), Visibility (weak logging, inadequate monitoring), and Resilience (no encryption, poor backups, human error). Five buckets are far easier to recall than fifteen bullets.
Named Database Attacks
Mnemonic - 10 Database Attacks: "Sneaky Crooks Prefer Unlocked Doors, Manipulating Stolen Passwords, Evading Bypassed Insiders"
S-C-P-U-D-M-S-P-E-B-I ≈ SQL injection, Credential brute-force, Privilege escalation, Unauthorized data access, Data manipulation, abuse of Stored procedures, exploiting misconfigured Permissions, password cracking, Bypassing authentication, Insider attacks. Ten attack types, one long crime-scene sentence.
Impact of Database Attacks
Locating Databases on the Network & Cracking Passwords
Before an attacker can hit a database, they first have to find it - including "rogue" or unknown database installations that IT doesn't even know exist.
Network Database Scanner
Effective at locating rogue or unknown database installations across the network.
SQLRecon
Similar to a network database scanner, but specifically targets Microsoft SQL Server installations.
Oscanner
A scanner purpose-built for finding and enumerating Oracle installations.
Mnemonic - Database-Locating Tools: "NSO"
N-S-O = Network Database Scanner (general/rogue DBs), SQLRecon (Microsoft SQL), Oscanner (Oracle). Say it like the name "N-S-O" - three tools, three targets.
Database Server Password Cracking
SQLPing3
A password-cracking tool aimed specifically at SQL Server.
Cain & Abel
A general-purpose password recovery/cracking tool, also used against database credentials.
Dictionary-Based Cracking
The underlying method both tools rely on - trying a curated wordlist of likely passwords rather than brute-forcing every possible combination.
Locating Vulnerabilities in Databases
Once inside striking distance, attackers (and pen testers) look for:
- Unused/misused stored procedures
- Service account privilege issues
- Weak or poor authentication methods enabled
- No or limited audit log settings
"Out of Sight, Out of Mind" - Hardening the Database
The slides frame database defense under the heading "Out of Sight, Out of Mind" - the less visible and less exposed the database is, the harder it is to attack.
Learn the Security Features in the Database System
You can't turn on protections you don't know exist - know your platform's built-in security controls.
Evaluate the Use of Nonstandard Ports
Running the database on a nonstandard port won't stop a determined attacker, but it removes the database from casual/automated default-port scans.
Keep Up to Date
Apply patches promptly - unpatched database software is one of the core vulnerabilities listed above.
Secure the Operating System
A database is only as secure as the OS underneath it - harden the host, not just the DB engine.
Use a Firewall
Restrict who can even reach the database port in the first place.
Mnemonic - Database Defense: "LEKSF"
L-E-K-S-F = Learn the security features, Evaluate nonstandard ports, Keep up to date, Secure the OS, use a Firewall. Five steps, "Out of Sight, Out of Mind."
Exam Tips & Tricks
Why Attackers Moved to the Web Layer
Network defenses (firewalls, IDS/IPS) handle network-level attacks well, pushing attackers toward web servers and web applications instead.
8 Web Server Vulnerabilities
Buffer overflow, DoS/DDoS, banner info, permissions, error messages, unnecessary features, user accounts, SQL injection - "Big Dogs Bark, People Even Fear Unfriendly Snakes."
Web Cache Poisoning Needs HTTP Response-Splitting
Web cache poisoning attacks are only possible if the web server/application has HTTP Response-Splitting flaws - remember that precondition.
4 Web Application Attacks
Cookie tampering, unvalidated input/file injection, XSS, SQL injection - "Cats Understand XML SQL."
Reflected vs Stored vs DOM XSS
Reflected = bounces back once via a crafted link. Stored = saved server-side, hits every viewer. DOM = lives entirely in client-side JS.
SQLi = Code Injected Into a String
The exact slide definition: attacker injects malicious code into strings later passed to the SQL server for execution - remember this phrasing.
3 Database-Locating Tools = 3 Targets
Network Database Scanner (general/rogue), SQLRecon (Microsoft SQL), Oscanner (Oracle) - each maps to a specific platform.
SQLPing3 & Cain and Abel = DB Password Cracking
Both named tools rely on dictionary-based cracking methods against database credentials.
"Out of Sight, Out of Mind" = 5 Defenses
Learn security features, evaluate nonstandard ports, keep up to date, secure the OS, use a firewall - "LEKSF."
6 Session Vulnerabilities
Long-lived sessions, missing logout, weak session IDs, IDs given to unauthorized users, no password change controls, unprotected cookie data.
Weak Ciphers vs Vulnerable Software
Weak ciphers = short/poorly designed keys. Vulnerable software = the implementation itself (e.g. SSL) is poorly programmed - two different failure points.
Quick Reference - Everything at a Glance
| Topic | Key Point |
|---|---|
| Web Server | Stores, processes, delivers web pages over HTTP; client-server model with browser as client |
| Why Web Servers Are Targeted | Network defenses handle network-level attacks, pushing attackers to the web layer; web servers are publicly reachable by design |
| Goals of Web Server Hacking | Steal credit cards/creds, build a botnet, compromise a database, steal closed-source apps, hide traffic, escalate privileges, or purely for curiosity/challenge/reputation damage |
| Dangerous Oversights | No patching, reused sysadmin credentials, unrestricted traffic, unhardened apps/servers |
| 4 Perspectives | Webmaster (exposed internals), Network Admin (misconfiguration), End User (assumes safety), Key Principle (poor config bypasses firewalls) |
| Root Causes | Unpatched software, poor config, vulnerable apps, weak auth, human error |
| Impact of Compromise | Data theft/tampering, defacement, malware distribution, privilege escalation, secondary attacks |
| 8 Web Server Vulnerabilities | Buffer overflow, DoS/DDoS, banner info, permissions, error messages, unnecessary features, user accounts, SQL injection |
| DNS Server Hijacking | Attacker compromises DNS server, redirects mappings to a rogue DNS server / fake site |
| DNS Amplification Attack | Small spoofed queries to open resolvers trigger large responses flooding the victim (DDoS) |
| Directory Traversal | Uses path sequences like ../../ to escape the web root and read arbitrary files |
| MITM / Sniffing | Intercepts or reads traffic in transit between client and server |
| Web Cache Poisoning | Flushes real cache content, stores infected content instead; requires HTTP Response-Splitting flaw |
| Session Hijacking with Cookies | Steals/replays a valid session cookie to impersonate the user |
| Banner Information | Connect to port 80 (HTTP) to read the web server's banner and identify software/version |
| Permissions | Control server/content access; incorrectly assigned permissions expose restricted locations |
| Unnecessary Features | Servers should be purpose-built; hardening removes anything not essential; disable/uninstall unused features |
| User Accounts | Default OS accounts are discoverable; disable/remove defaults, create purpose-matched accounts |
| 4 Web Application Attacks | Cookie tampering, unvalidated input/file injection, XSS, SQL injection |
| Cookie Tampering | Modifying persistent/non-persistent cookies in transit from client to server |
| XSS (Definition) | Injection of malicious (often browser-side) script into a trusted site, delivered to another user |
| XSS Types (enrichment) | Reflected (bounces back once), Stored (persists, hits all viewers), DOM-based (client-side JS only) |
| SQL Injection (Definition) | Malicious code injected into strings later passed to the SQL server for execution |
| SQLi Categories (enrichment) | In-band (error-based, union-based); Blind (boolean-based, time-based) |
| SQLi Tools (enrichment) | sqlmap (automated exploitation), Burp Suite (intercepting proxy for manual testing) |
| SQLi Defense | Parameterized queries/prepared statements, input validation, least-privilege DB accounts |
| Session (Definition) | A client-server connection with a unique identifier, encryption, and other parameters |
| Session Vulnerabilities | Long-lived sessions, missing logout, weak session IDs, IDs to unauthorized users, weak password change controls, unprotected cookie data |
| Encryption Weaknesses | Weak ciphers (short/poor keys) vs. vulnerable software implementations (e.g. poorly programmed SSL) |
| Database Vulnerabilities | Weak/default/shared passwords, excessive privileges, unpatched software, insecure/default config, no RBAC, open ports, poor backups, weak logging/monitoring, human error |
| 10 Database Attacks | SQL injection, credential brute-force, privilege escalation, unauthorized data access, data manipulation, abuse of stored procedures, exploiting misconfigured permissions, password cracking, bypassing authentication, insider attacks |
| Impact of Database Attacks | Data theft → tampering/deletion → loss of confidentiality/integrity → service disruption → legal/ reputational damage |
| Database-Locating Tools | Network Database Scanner (rogue DBs), SQLRecon (Microsoft SQL), Oscanner (Oracle) |
| Database Password Cracking | SQLPing3, Cain and Abel; both use dictionary-based cracking methods |
| Locating DB Vulnerabilities | Misused stored procedures, service account privilege issues, weak auth methods, no/limited audit logs |
| Database Defense ("Out of Sight, Out of Mind") | Learn security features, evaluate nonstandard ports, keep up to date, secure the OS, use a firewall |