---

Introduction

Module 13 — Hacking Web Servers

Web servers are high-value targets that can expose sensitive data or allow total system compromise.
Understand reconnaissance, exploitation of misconfigurations, directory traversal, and web shell deployment.
Mitigate through patching, least privilege, web application firewalls, and secure configurations.

Module 14 — Hacking Web Applications

Web apps are primary attack surfaces due to their public exposure and user interaction.
Study OWASP Top 10 vulnerabilities — SQLi, XSS, CSRF, and authentication flaws.
Emphasize secure coding, input validation, and security testing (DAST/SAST) to build resilient applications.

Module 15 — SQL Injection

SQL injection manipulates database queries through unvalidated input to access or modify sensitive data.
Understand in-band, blind, and out-of-band techniques and tools like sqlmap.
Prevent through parameterized queries, least privilege, and proper error handling with input sanitization.

Module 13 — Hacking Web Servers

Overview & Purpose

Web servers host applications and content accessible from the Internet; they mediate requests between clients and backend systems (application runtimes, databases, caches). Attacking a web server can give direct access to hosted applications, sensitive configuration and credential files, or a foothold to move deeper into an environment. This module focuses on discovery, misconfiguration exploitation, server-side weaknesses, post-compromise persistence, and defense at the server level.

Attack Surface & Key Components

• HTTP/HTTPS endpoints and virtual hosts.
• Web server software and modules (examples include widely used servers and their extensions).
• Application runtimes and server-side modules (scripting engines, language runtimes).
• Configuration files, log files, and default/sample pages.
• Admin interfaces, management consoles, and remote management endpoints.
• File systems, user permissions, and service accounts used by the web server.
• Reverse proxies, load balancers, CDNs, and web application firewalls that sit in front of the server.

Typical Weaknesses & How They’re Abused

• Server version and banner disclosure: publicly revealing software versions enables attackers to map known vulnerabilities to the server.
• Default or sample files left on the server: example scripts, backup files, or unremoved admin panels can be leveraged to gain access.
• Directory listing enabled: reveals filenames and structure that ease discovery of sensitive files.
• Misconfigured file uploads: uploading files into web-accessible locations can allow execution of malicious content.
• Insecure file permissions: writable webroot or world-writable files let attackers add or modify content.
• Unprotected admin consoles: admin interfaces without sufficient access controls or exposed to the internet are high-value targets.
• Poor TLS/SSL configuration: weak ciphers, expired or misissued certificates, and missing security headers increase the risk of interception or downgrade attacks.
• Vulnerable server modules or plugins: outdated or improperly configured modules can be directly exploited.

Attack Techniques

• Reconnaissance & fingerprinting: identify server type, versions, virtual hosts, and exposed management endpoints.
• Exploiting misconfigurations: reading configuration files, abusing permissive file permissions, or leveraging exposed admin functions.
• File upload abuse: submit content that ends up in a web-accessible location, then trigger server-side processing that executes it.
• Inclusion vulnerabilities: local file inclusion or remote inclusion can be used to execute or reveal sensitive files.
• Log injection & log inclusion: poisoning logs (for example via user-agent or request fields) to later get included and executed by a vulnerable include mechanism.
• Post-compromise persistence: planting web shells, cron tasks, backdoors inside site code, or modifying startup scripts.

Post-Exploitation Risks

• Discovery of application credentials and connection strings inside configuration files.
• Escalation from web user to system-level privileges via misconfigurations or vulnerable helpers.
• Lateral movement using found credentials or misconfigured services.
• Long-term persistence through hidden backdoors, scheduled tasks, or modified code.
• Data exfiltration of databases, file shares, or backups accessible from the compromised server.

Detection Signals & Forensics

• Unexpected new files or changed timestamps in webroot.
• Unusual outbound traffic from the web server to unknown addresses.
• Anomalous requests in access logs (long URIs, unexplained POSTs, attempts to access config paths).
• Sudden creation of admin accounts or atypical privilege assignments.
• Error logs indicating attempts to include or access files outside expected directories.

Defensive Controls & Hardening

• Remove default/sample files and restrict directory listings.
• Harden configuration: disable unsafe features and hide version banners.
• Enforce least-privilege for web server user accounts and restrict file permissions.
• Store uploaded files outside the web root and validate file types and content server-side.
• Keep server software and modules patched; maintain a software bill-of-materials for quick CVE mapping.
• Use reverse proxies, WAFs, and CDNs for filtering and rate-limiting; tune WAF rules carefully to avoid false positives.
• Centralize logging and monitor for anomalous patterns; apply file integrity monitoring for web content.
• Secure TLS configurations and apply security headers to reduce client-side exploitation risk.

Module 14 — Hacking Web Applications

Overview & Purpose

Web applications are frequent targets because they accept user input and implement business logic. This module concentrates on application-layer vulnerabilities that stem from how applications process input, manage sessions, enforce access control, and use third-party components. The focus is both on attack methodology and secure development practices to prevent exploitation.

Core Principles

• Most application vulnerabilities arise from improper handling of untrusted input, weak authentication/authorization, insecure configuration, or use of vulnerable third-party components.
• Successful exploitation often requires a combination of reconnaissance (mapping endpoints and functionality), careful manipulation of inputs, and contextual understanding of app logic.

High-Impact Vulnerability Classes

Injection (SQL, NoSQL, LDAP, Command)

• Occurs when input is interpreted as part of an instruction to a backend interpreter.
• Attack impact: data extraction, modification, authentication bypass, or execution of arbitrary commands in the backend context.

Cross-Site Scripting (XSS)

• Client-side code injection where user-supplied input is delivered to other users without proper encoding.
• Attack impact: session theft, redirection, or executing actions on behalf of victims.

Broken Authentication & Session Management

• Weaknesses in how credentials, sessions, or tokens are issued and validated.
• Attack impact: account takeover, session hijacking, bypass of multi-step verifications.

Broken Access Control (IDOR, escalation)

• Failure to enforce authorization checks for objects or functions results in users accessing or modifying resources they shouldn’t.
• Attack impact: data leakage, unauthorized actions, privilege escalation.

Security Misconfiguration

• Default settings, exposed debug endpoints, permissive CORS policies, or incorrect error handling can all expose information or functionality to attackers.

Sensitive Data Exposure

• Data in transit or at rest is not properly protected, or secrets are stored in source code or logs.

Insufficient Logging & Monitoring

• When attacks are not logged or alerts are not tuned, intrusions can persist undetected.

CSRF (Cross-Site Request Forgery)

• Forcing authenticated users to perform unintended actions through crafted requests.

Using Components with Known Vulnerabilities

• Third-party libraries or frameworks with unpatched vulnerabilities introduce high risk.

API-Specific Issues: Rate-limiting, schema validation, and improper CORS

• Modern APIs require careful input validation, rate limits, and secure cross-origin configurations.

Common Attack Patterns

• Parameter manipulation: change IDs, parameters, or headers to access different users’ data.
• Payload encoding to bypass filters: alternate encoding or nested encodings to sneak past naive filters.
• Business logic abuse: exploiting how an application enforces business rules (e.g., refunds, discounts).
• File upload abuse: tricking uploads into storing executable content or bypassing validation.
• Chaining vulnerabilities: combining XSS for token theft with CSRF or chaining SQL injection to access files.

Detection & Indicators

• Unusual patterns of parameter fuzzing or repeated similar requests against many endpoints.
• Error messages revealing stack traces, internal table/column names, or framework details.
• Sudden spikes in requests to endpoints that normally see little traffic.
• Client-side indicators: suspicious scripts or third-party inclusions being returned to users.

Secure Development & Prevention

• Apply input validation using whitelists and type checks; validate server-side even if client-side checks exist.
• Use parameterized interactions with interpreters (databases, LDAP) to separate code from data.
• Enforce robust authentication and session controls: secure cookies, short-lived tokens, rotation at sensitive events, and multi-factor authentication.
• Implement defense-in-depth: output encoding for context (HTML, JavaScript, CSS), content security policy, rate limiting, and strict CORS policies.
• Keep dependencies up to date, maintain an inventory of libraries, and regularly scan for known vulnerabilities.
• Integrate security into the development lifecycle: automated static analysis, dependency scanning, and application security testing in CI/CD.
• Log critical events and set up monitoring and alerts for anomalous behavior.

Post-Exploitation Risks

• Stealing session tokens or credentials to access privileged features.
• Deploying persistent client-side attacks (stored XSS) to target additional users.
• Exfiltrating sensitive data via application endpoints or hidden APIs.

Module 15 — SQL Injection

Overview & Purpose

SQL Injection (SQLi) is an application-layer vulnerability resulting from unsafe construction of database queries using untrusted input. It is among the most severe classes because it allows attackers to read, modify, or destroy database content and, in some cases, perform actions on the hosting server.

Why It’s Critical

• Databases typically store highly sensitive data, such as user credentials, personally identifiable information, financial records, and configuration secrets.
• SQLi can enable full database compromise, escalation to system-level access, data exfiltration, or creation of persistent backdoors.

Types of SQL Injection

In-Band SQL Injection

• The attacker uses the same communication channel to both launch the attack and receive data. Common forms:
  • Error-based: extracting data from error messages returned by the database or application.
  • Union-based: leveraging the query union operator to return attacker-controlled data within normal results.

Blind SQL Injection

• The application does not directly return database output; the attacker infers data by observing differences in application behavior.
  • Boolean-based: infer truth or falsehood by comparing responses.
  • Time-based: infer data by measuring response timing variations.

Out-of-Band (OOB) SQL Injection

• The database is coerced to make a secondary connection (for example, to a DNS or HTTP endpoint) to deliver data to an attacker-controlled listener. This is useful when immediate responses are not available.

Second-Order SQL Injection

• Input that is stored safely at first but later used insecurely in a different context, causing injection when that stored data is processed.

Typical Application Weaknesses Leading to SQLi

• Dynamic construction of SQL statements by concatenation of user input with query strings.
• Inadequate input validation or reliance on client-side validation only.
• Excessive privileges assigned to the application database account.
• Detailed database error messages displayed to users.
• Legacy codebases or outdated database drivers that do not offer parameterization facilities.

Attack Consequences

• Reading or exfiltrating entire databases or specific sensitive tables.
• Modifying or deleting records, impacting integrity and availability.
• Bypassing authentication mechanisms by manipulating login queries.
• Executing server-side commands or writing files (in environments where the database engine allows file operations), leading to remote code execution.
• Creating persistence by inserting malicious entries or modifying stored procedures.

Detection Signals & Monitoring

• Unexpected SQL error messages or stack traces in application responses or logs.
• Frequent requests including SQL metacharacters or patterns against the same parameters.
• Database log entries showing anomalous queries or queries that reference metadata tables frequently.
• Slow or delayed responses consistent with time-based probes, or unusual outbound connections from the database host (suggesting OOB extraction).
• Alerts from application firewalls or query anomaly systems based on unusual query shapes or access patterns.

Defenses & Mitigations

• Use parameterized statements or prepared statements to ensure data is always treated as data, never as executable code.
• Adopt the principle of least privilege for database accounts — grant only the minimum rights necessary for normal operation.
• Validate and canonicalize input on the server side; prefer strict whitelisting of acceptable values and types.
• Hide database error messages from end users and log them securely for developers/incident response.
• Disable or restrict dangerous database functions that allow read/write to the filesystem or external network access, if those functions are not needed.
• Implement database activity monitoring and anomaly detection to flag unusual query patterns or access to sensitive tables.
• Employ layered defenses: input validation, parameterization, WAF tuning, and monitoring.
• Keep database engines and connectors patched, and regularly review and test application code and query logic.

Post-Exploitation Considerations

• After extracting data, attackers may use credentials or discovered connection strings to pivot to other systems.
• Attackers may plant persistent mechanisms by creating new database users, stored procedures, or data that allows future re-entry.
• Recovery requires careful evidence preservation, rotating credentials, applying fixes, and verifying integrity of the database and associated systems.

Combined Key Takeaways

• Web servers (Module 13) are infrastructure-level targets; hardening them reduces the risk that attackers get a foothold.
• Web applications (Module 14) are logic-level targets where flawed input handling, auth, and configuration produce exploitable conditions; secure development practices are essential.
• SQL injection (Module 15) is a high-impact application-layer flaw rooted in unsafe handling of database queries; parameterization and least-privilege are primary defenses.
• Defense-in-depth is critical across all three areas: secure configuration, up-to-date components, input validation, least privilege, encrypted communications, centralized logging, and strong detection/response capabilities.