WAHH

This report provides a comprehensive analysis of security vulnerabilities identified across two key cybersecurity documents: "OWASP Code Review Guide v2.pdf" and "The Web Application Hacker's Handbook.pdf." It aims to educate developers on various threat types,

Vulnerability Report

1. Injection Vulnerabilities

Injection vulnerabilities allow attackers to inject malicious content or commands into an application, modifying its intended behavior. These are common and often easy to exploit.

SQL Injection

Description / Definition: SQL Injection occurs when an attacker can submit crafted input to interfere with an application's interaction with back-end databases. This can lead to the disclosure or leaking of sensitive information, data integrity issues (modifying, adding, or deleting data), elevation of privileges, or gaining access to the back-end network. The core problem is that the SQL parser cannot distinguish between code and data when untrusted input is included in SQL statements.
Vulnerable Code Example: Applications often construct SQL statements by concatenating user-supplied input directly into the query string without proper sanitization.
```
// Java example from OWASP Guide
HttpServletRequest request = ...;
String userName = request.getParameter("name");
Connection con = ...;
String query = "SELECT * FROM Users WHERE name = '" + userName + "'"; // Vulnerable concatenation
con.execute(query);
```
An attacker could input "' OR 1=1" for userName, making the query: SELECT * FROM Users WHERE name = '' OR 1=1'. This would return all user records.

Another example from "The Web Application Hacker's Handbook" for an ASP.NET application:
```
// C# .NET example (representative, based on)
string employeeID = request.getParameter("ei_id");
string sql = "SELECT name, lastname FROM authors WHERE ei_id = '" + employeeID + "'"; // Vulnerable
// ... execute sql
```
An attacker could insert "123';DROP TABLE pubs --" for employeeID, executing SELECT name, lastname FROM authors WHERE ei_id = '123'; DROP TABLE pubs --'.
Root Cause: The primary root cause is the unprotected concatenation of untrusted user input directly into SQL statements. This occurs because the SQL parser cannot distinguish between the developer's intended code and the malicious data injected by the attacker. Additionally, a lack of input validation or parameter mishandling can expose this flaw.
Remediation / Secure Fix:
1. Parameterize SQL queries: This is considered one of the most effective ways to prevent SQL Injection. It involves using SQL methods provided by the programming language or framework that explicitly separate code from data.
2. Use Stored Procedures: While generally helpful, stored procedures must be correctly implemented and not build dynamic SQL statements internally using untrusted input, as this can reintroduce the vulnerability.
3. Input Validation: Always validate user input by testing type, length, format, and range. Accept only expected values and reject entries containing binary data, escape sequences, or comment characters. Implement multiple layers of validation.
4. HtmlEncode all user input: This can mitigate some forms of injection, though it's not a complete solution for SQL injection specifically.
5. Developer Training: Train developers in secure coding techniques to avoid common vulnerabilities.

Corrected Code Example: Using parameterized queries in Java:

// Java example with PreparedStatement from OWASP Guide
HttpServletRequest request = ...;
String userName = request.getParameter("name");
Connection con = ...;
String query = "SELECT * FROM Users WHERE name = ?"; // Use a placeholder
PreparedStatement pstmt = con.prepareStatement(query);
pstmt.setString(1, userName); // Set parameter safely
ResultSet results = pstmt.executeQuery();

Using parameterized queries in .NET:

// C# .NET example (representative, based on)
using (SqlConnection conn = new SqlConnection(connectionString)) {
    DataSet dataObj = new DataSet();
    SqlDataAdapter sqlAdapter = new SqlDataAdapter("StoredProc", conn);
    sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure; // Or CommandType.Text for direct query
    sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
    sqlAdapter.SelectCommand.Parameters["@usrId"].Value = UID.Text;
    // ... execute
}

Explanation of Fix: Parameterized queries (and correctly implemented stored procedures) explicitly tell the database engine which parts of the statement are code and which are data, preventing the attacker's input from being interpreted as executable SQL. The database treats the user-supplied value as a literal string, even if it contains SQL syntax. Strict input validation reduces the attack surface by ensuring that only data conforming to expected types and formats is processed, further limiting an attacker's ability to craft malicious inputs.

NoSQL Injection

Description / Definition: NoSQL injection vulnerabilities arise in applications using NoSQL data stores (which break from standard relational database architectures and use key/value mappings without a fixed schema). Similar to SQL injection, these allow attackers to interfere with how the application processes data in NoSQL databases.

Vulnerable Code Example: (Representative, based on's explanation of MongoDB injection)

// JavaScript (Node.js/MongoDB) example
router.get('/products', function(req, res) {
    let query = {
        category: req.query.category // User-controlled input
    };
    db.collection('products').find(query).toArray(function(err, docs) {
        // ... process results
    });
});

An attacker might send ?category[$ne]=null as input, which for some NoSQL databases might alter the query's logic to return all documents where the category is not null.

Root Cause: The root cause is similar to SQL injection: unsafe incorporation of user-supplied data into queries or commands executed by the NoSQL database. This is compounded by the flexible, schema-less nature of NoSQL, which can sometimes lead developers to be less rigorous with input handling compared to traditional SQL.
Remediation / Secure Fix:
1. Use specific API functions for queries: Most NoSQL databases provide APIs that distinguish between data and commands.
2. Strict Input Validation: Implement rigorous validation for all user input that interacts with the NoSQL database.
3. Sanitization: Ensure proper sanitization of input, especially for dynamic queries.
Explanation of Fix: Using specific API functions helps ensure that user input is treated as literal data and not as part of the query structure, thus preventing code execution. Strict input validation and sanitization further reduce the risk by disallowing malicious characters or structures from reaching the database layer.

XPath Injection

Description / Definition: XPath injection vulnerabilities occur when user-supplied input is incorporated unsafely into XPath queries, which are used to navigate XML documents. This can allow an attacker to bypass application logic or extract arbitrary data from XML data stores.

Vulnerable Code Example: (Representative, based on's concept of informed XPath injection)

// Java example (representative)
String username = request.getParameter("username");
String password = request.getParameter("password");
String query = "/users/user[username='" + username + "' and password='" + password + "']";
// ... execute XPath query against an XML document

An attacker could input "' or '1'='1" for username, bypassing authentication.

Root Cause: The root cause is the direct concatenation of user-supplied data into XPath query strings without proper escaping or validation, allowing an attacker to manipulate the query's logic.
Remediation / Secure Fix:
1. Use Parameterized XPath Queries: Employ APIs that allow parameters to be bound to XPath expressions, treating input as data.
2. Whitelist Validation: For dynamic parts of the query (e.g., element names), use a whitelist approach to ensure only expected values are used.
3. Escape Special Characters: Properly escape all XPath metacharacters within user input before inclusion in queries.
Explanation of Fix: Parameterized queries and proper escaping ensure that user input cannot alter the structure or meaning of the XPath expression, preventing injection. Whitelisting restricts dynamic parts of queries to safe, predefined values.

LDAP Injection

Description / Definition: LDAP (Lightweight Directory Access Protocol) injection arises when user-supplied input is embedded directly into LDAP queries without proper sanitization. This can allow attackers to bypass authentication, retrieve unauthorized information from directory services (like Active Directory), or subvert application logic.

Vulnerable Code Example: (Representative, based on's example)

// Java example (representative)
String username = request.getParameter("username");
String password = request.getParameter("password");
String ldapFilter = "(&(uid=" + username + ")(userPassword=" + password + "))";
// ... search LDAP directory with ldapFilter

An attacker could submit *)(objectClass=*) for username, which might modify the filter to (&(uid=*)(objectClass=*))(userPassword=...)) allowing arbitrary access.

Root Cause: The root cause is the unsafe direct inclusion of user input into LDAP filters or queries, without proper escaping of LDAP special characters (e.g., *, (, ), =, ,).
Remediation / Secure Fix:
1. Escape LDAP Special Characters: Implement rigorous escaping for all user-supplied data that will be used in LDAP queries.
2. Use Parameterized APIs: Utilize LDAP APIs that support parameterized queries, similar to prepared statements in SQL.
3. Strict Input Validation: Validate input against a whitelist of allowed characters or expected patterns.
Explanation of Fix: Escaping LDAP metacharacters ensures that user input is treated as literal data and not as control characters that could alter the LDAP query's structure. Parameterized APIs provide a secure separation between query logic and user data.

OS Command Injection

Description / Definition: OS Command Injection allows an attacker to execute arbitrary operating system commands on the server running the web application. This happens when an application incorporates user-supplied input into commands that are passed to an underlying operating system shell. A successful attack can lead to full compromise of the underlying operating system.

Vulnerable Code Example:

// C# ASP.NET example from Web Application Hacker's Handbook
string dirName = "C:\\filestore\\" + Directory.Text;
ProcessStartInfo psInfo = new ProcessStartInfo("cmd", "/c dir " + dirName); // Vulnerable concatenation
Process proc = Process.Start(psInfo);

An attacker could input & dir C:\ -- to Directory.Text, which would execute cmd /c dir C:\filestore\ & dir C:\ --, leading to dir C:\ being executed.

Root Cause: The root cause is the direct concatenation of untrusted user input into system commands that are executed by functions like Process.Start (C#), Runtime.exec (Java), or system (PHP/Perl). The application fails to properly separate the command from its arguments or data.
Remediation / Secure Fix:
1. Avoid Shell Execution: Do not pass user-supplied input, or data derived from it, into any dynamic execution or shell-level command functions if at all possible.
2. Use Specific APIs: If external processes must be launched, use APIs that allow command arguments to be passed as separate parameters (e.g., ProcessStartInfo.Arguments in C#, ProcessBuilder in Java), which prevents shell metacharacters from being interpreted.
3. Whitelist Validation: If dynamic command parts are unavoidable, use a strict whitelist of known good values and reject any input not matching this list.
4. Least Privilege: Configure the application to run with the least possible operating system privileges.

Corrected Code Example: Using arguments array in C#:

// C# ASP.NET example with safe argument passing (representative)
string dirName = Directory.Text; // User input
// Ensure dirName itself does not contain malicious paths or commands if it needs to be part of the command's target
ProcessStartInfo psInfo = new ProcessStartInfo("cmd.exe", "/c dir " + Process.EscapeArgument(dirName)); // Safer
// For more complex commands or variable inputs, pass arguments separately:
// ProcessStartInfo psInfo = new ProcessStartInfo("cmd.exe");
// psInfo.Arguments = "/c dir \"" + dirName + "\""; // Escape the path or ensure it's safe
Process proc = Process.Start(psInfo);

Using ProcessBuilder in Java:

// Java example with ProcessBuilder (representative)
String userName = request.getParameter("name");
ProcessBuilder pb = new ProcessBuilder("cmd.exe", "/c", "echo", userName); // Arguments as separate strings
pb.start();

Explanation of Fix: Avoiding direct shell execution where user input can manipulate commands is the best defense. When direct execution is unavoidable, passing arguments as separate parameters to specific APIs prevents the shell from interpreting user-supplied metacharacters (like &, |, ;) as new commands, treating them instead as literal parts of an argument. Whitelisting provides a strong layer of control over accepted inputs.

Script Injection (Dynamic Execution)

Description / Definition: Script injection occurs when an application dynamically executes code that is generated at runtime, and user input is incorporated into this code. Attackers can supply crafted input that breaks out of the intended data context and specifies commands to be executed on the server. This is distinct from XSS, as it targets server-side scripting languages.
Vulnerable Code Example: (Representative, based on PHP/Perl eval() and Classic ASP Execute() examples in)
```
// PHP example (representative)
$mysearch = $_GET['search_query'];
eval("\$result = " . $mysearch . ";"); // Vulnerable if $mysearch contains executable code
```
If $mysearch is wahh; system('cat /etc/passwd'), it would execute system('cat /etc/passwd').
Root Cause: The root cause is the passing of user-supplied input, or data derived from it, into dynamic execution or include functions of scripting languages. These functions interpret concatenated strings as executable code, rather than literal data.
Remediation / Secure Fix:
1. Avoid Dynamic Execution of User Input: The best way to prevent script injection is to never pass user-supplied input into dynamic execution or include functions.
2. Strict Input Validation: If such functions are absolutely unavoidable, the relevant input should be strictly validated using a whitelist of known good values. Reject any input that does not appear on this list or contains characters known to be harmful.
Explanation of Fix: Not using dynamic execution functions with user input removes the interpreter's ability to execute malicious code. When unavoidable, strict whitelisting ensures that only safe, predefined inputs are processed, effectively preventing an attacker from introducing executable syntax.

E-mail Header Manipulation (SMTP Injection)

Description / Definition: SMTP Injection occurs when an attacker manipulates email headers by injecting CRLF (carriage return/line feed) characters into user-supplied input used to construct an email. This can allow attackers to send arbitrary emails, spam, or even bypass security controls by injecting additional headers.

Vulnerable Code Example: (Representative, based on's description)

// Java example (representative)
String recipient = request.getParameter("to"); // User-supplied recipient
// ... construct email
Message msg = new MimeMessage(session);
msg.setRecipients(Message.RecipientType.TO, InternetAddress.parse(recipient)); // Vulnerable if recipient contains CRLF
// ... send email

An attacker might input attacker@example.com%0aBcc:spam@example.com to inject a Bcc header.

Root Cause: The root cause is the failure to validate user input for newline characters (CRLF) before incorporating it into email headers. SMTP and mail libraries interpret these characters as separators for new headers or body content, allowing injection.
Remediation / Secure Fix:
1. Validate User Input for Newlines: Strictly validate user-supplied email inputs to ensure they do not contain any newline characters (CR and LF, %0d and %0a) or other SMTP metacharacters.
2. Use Specific API Methods: Use mail APIs that properly handle or escape user input for email addresses and content.
Explanation of Fix: Removing or encoding newline characters (%0a, %0d) from user input prevents the mail server from interpreting them as new headers or commands. This ensures that user input remains within its intended data field.

Back-End HTTP Request Injection (HPI/HPP/Server-Side Redirection)

Description / Definition: These vulnerabilities occur when an application constructs internal (server-side) HTTP requests using user-supplied data without proper validation or sanitization.
- HTTP Parameter Injection (HPI): Injecting parameters into the server's internal HTTP request.
- HTTP Parameter Pollution (HPP): Supplying multiple parameters with the same name, which may be handled differently by various components of the application.
- Server-Side HTTP Redirection: When a server-side component (e.g., a proxy, an internal redirect) constructs a new HTTP request based on user-supplied URL fragments, allowing an attacker to control the destination.

Vulnerable Code Example: A classic example of server-side HTTP redirection (representative, based on)

// Java example (representative)
String url = request.getParameter("redirect_url"); // User-controlled URL
URL target = new URL(url); // Vulnerable if 'url' can be manipulated
HttpURLConnection conn = (HttpURLConnection) target.openConnection();
// ... fetch content from 'target'

An attacker could submit http://internal-host/admin to access an internal service.

Root Cause: The root cause is the unvalidated or unsanitized inclusion of user-supplied data into the URL or parameters of internal HTTP requests. Different components (e.g., web server, application framework, back-end service) might interpret the same string differently, leading to unintended behavior.
Remediation / Secure Fix:
1. Whitelist Destinations: For redirects and forwards, only allow destinations that are explicitly defined in a whitelist.
2. Use Relative Paths: Prefer using relative paths for redirects and forwards to ensure they stay on the trusted site.
3. Strict Input Validation: Ensure user-supplied scheme name or authority section of URLs are thoroughly validated, allowing only necessary prefixes, alphanumerics, hyphens, and periods.
4. Avoid Assumptions: Do not assume default browser behavior will properly escape characters.
Explanation of Fix: Whitelisting destinations and using relative paths severely restricts an attacker's ability to redirect to arbitrary external or internal locations. Strict input validation ensures that only safe characters and structures are permitted in dynamic URL parts, preventing injection of malicious components.

XML Injection (XXE)

Description / Definition: XML External Entity (XXE) injection is a type of XML injection that occurs when an XML parser processes XML input containing references to external entities (URIs) that are not properly secured. This can allow attackers to read local files, execute OS commands, perform server-side request forgery (SSRF), or launch denial-of-service attacks.
Vulnerable Code Example: (Representative, based on's concept)
```
<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<data>&xxe;</data>
```
If an application parses this XML and renders the data element, it might display the content of /etc/passwd.
Root Cause: The root cause is the improper configuration of XML parsers, which by default often allow the resolution and processing of external entities. When these parsers receive user-controlled XML input, they can be tricked into fetching and including external content, or even executing commands.
Remediation / Secure Fix:
1. Disable External Entities: The most effective remediation is to disable the processing of external entities in the XML parser configuration.
2. Disable DTD Processing: Disabling DTD (Document Type Definition) processing can also prevent XXE attacks.
3. Use Whitelisting for DTDs: If DTDs are necessary, use a whitelist for allowed DTDs.
4. Input Validation: Validate XML input against a schema and reject any malformed or unexpected structures.
Explanation of Fix: Disabling external entity processing directly prevents the XML parser from resolving and including external content, thereby mitigating the core XXE vulnerability. This ensures that even if an attacker provides external entity definitions, they will not be processed.

SOAP Injection

Description / Definition: SOAP (Simple Object Access Protocol) injection vulnerabilities occur when user-supplied data is incorporated directly into back-end SOAP messages without proper sanitization. Attackers can inject XML metacharacters or SOAP-specific syntax to alter the message structure, potentially bypassing application logic or accessing unauthorized data.

Vulnerable Code Example: (Representative, based on's explanation) Consider a SOAP message for adding an item, where the item description is user-controlled:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Body>
        <m:AddItem xmlns:m="http://example.com/products">
            <m:Description>User supplied description here</m:Description>
        </m:AddItem>
    </soap:Body>
</soap:Envelope>

If User supplied description here is </m:Description><m:Price>0</m:Price>, an attacker might inject a price.

Root Cause: The root cause is the direct concatenation of unvalidated or unsanitized user input into the XML structure of SOAP messages. This allows attackers to manipulate the XML, leading to unintended processing by the SOAP service.
Remediation / Secure Fix:
1. XML Encoding: Properly encode all user input that will be inserted into SOAP messages.
2. Use APIs for XML Construction: Utilize XML parsing and construction libraries that handle escaping automatically rather than manually building XML strings.
3. Schema Validation: Validate incoming SOAP messages against their WSDL-defined schema.
Explanation of Fix: Proper XML encoding ensures that user input is treated as literal text within XML elements and not as new XML tags or attributes. Using XML construction APIs helps automate this process securely.

2. Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is a common web application vulnerability that enables attackers to inject malicious script into web pages viewed by other users. This can allow attackers to bypass access controls (like the same-origin policy), gain access to user data, perform unauthorized actions on their behalf, or carry out other attacks.

Reflected XSS (Non-Persistent)

Description / Definition: Reflected XSS occurs when user-supplied data is immediately returned or "reflected" in the application's HTTP response without proper sanitization. The malicious script is delivered via a crafted URL or request, which, when clicked or processed, executes in the victim's browser.
Vulnerable Code Example:
```

<input type="text" name="fname" value="UNTRUSTED DATA">
```
If UNTRUSTED DATA comes directly from a URL parameter like ?fname="><script>alert(1)</script>, the rendered HTML becomes: <input type="text" name="fname" value=""><script>alert(1)</script>">. The attacker's script then executes.

Another example might be an error page reflecting user input:
```
// PHP example (representative, based on)
echo "Error: Invalid input " . $_GET['message'];
```
If $_GET['message'] is <script>alert('XSS')</script>, the script executes in the user's browser.
Root Cause: The root cause is the failure to perform output encoding or sanitization on user-supplied data before it is inserted into the HTML output. The application trusts that the reflected input is benign and embeds it directly into the page.
Remediation / Secure Fix:
1. Output Encoding (Context-Sensitive): The most crucial defense. Encode all user-supplied data based on the context in which it will be displayed in the HTML. For HTML attributes, use &#xHH; format (or named entities). For HTML body, encode &, <, >, ", ', and /.
2. Input Validation: While not a primary defense for output, validating input (e.g., length, character sets) can reduce the attack surface.
3. Content Security Policy (CSP): Implement a robust CSP header to restrict where scripts can be loaded from and executed [498 (implied by "Potential solutions: OWASP HTML Sanitizer Project")].
4. Client-Side Sanitizers (OWASP HTML Sanitizer): Use libraries to sanitize HTML content.

Corrected Code Example: Using HTML attribute encoding for the input value:

<!-- Corrected HTML example (representative, based on) -->
<input type="text" name="fname" value="&#x22;&#x3e;&#x3c;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3e;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x31;&#x29;&#x3c;&#x2f;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3e;">

Using encoding functions (e.g., from OWASP ESAPI or Java Encoder):

// Java example with encoding (representative, based on)
String message = request.getParameter("message");
// org.owasp.esapi.ESAPI.encoder().encodeForHTML() or encodeForHTMLAttribute()
// For HTML body:
System.out.println("Error: Invalid input " + ESAPI.encoder().encodeForHTML(message));
// For HTML attribute:
// <input value='" + ESAPI.encoder().encodeForHTMLAttribute(message) + "'>

Explanation of Fix: Output encoding transforms characters that have special meaning in HTML (like < and >) into their entity equivalents (like < and >). This ensures that the browser interprets the user's input as literal text rather than executable code. By consistently encoding based on the output context (HTML element content, attribute value, JavaScript string, etc.), the application prevents the attacker's script from breaking out of its intended context and executing.

Stored XSS (Persistent)

Description / Definition: Stored XSS occurs when malicious user-supplied data is permanently stored by the application (e.g., in a database) and later retrieved and displayed to other users without proper sanitization. This is often considered more serious than reflected XSS because the malicious payload is "stored" and can affect multiple users over time without further attacker interaction.

Vulnerable Code Example: (Representative, based on's explanation) Consider a message board where users can post comments. If comments are stored and then retrieved, the following could be vulnerable:

// PHP example (representative)
// When storing:
$comment = $_POST['comment']; // Attacker inserts <script>alert('Stored XSS')</script>
// ... store $comment in database

// When displaying:
$stored_comment = getCommentFromDB();
echo "<p>" . $stored_comment . "</p>"; // Vulnerable, directly echoes stored content

Root Cause: The root cause is the failure to perform output encoding or sanitization when retrieving and displaying user-supplied data that was previously stored. The application assumes that data once stored is safe, or that sanitization happened only upon input, neglecting to sanitize upon output, where the context of display might differ.
Remediation / Secure Fix:
1. Output Encoding (Context-Sensitive): As with reflected XSS, the most critical defense is to encode all user-supplied data based on the context of its display in the HTML output, whenever it is retrieved from storage. This includes &, <, >, ", ', and / for HTML body, and &#xHH; for attributes.
2. Input Validation/Sanitization: While output encoding is paramount, filtering and sanitizing input before storage can add a layer of defense. However, do not rely solely on input filtering, as output context can vary. If HTML content is legitimately allowed, use an HTML sanitization library (e.g., OWASP HTML Sanitizer Project) to remove dangerous tags and attributes.
Explanation of Fix: The core principle remains output encoding at the point of display. By transforming special characters into their harmless HTML entity equivalents just before they are rendered in the browser, the application ensures that the stored malicious script is displayed as text, not executed as code. This is a "defense-in-depth" approach, recognizing that input filters can be bypassed or that data might originate from different, less-controlled sources.

DOM-Based XSS

Description / Definition: DOM-based XSS occurs entirely on the client-side when a JavaScript application modifies the page's DOM (Document Object Model) using attacker-controlled data, without proper sanitization. The malicious script is executed as a result of client-side code manipulating a part of the DOM, rather than the server reflecting or storing the payload.

Vulnerable Code Example:

<!-- HTML with JavaScript example from OWASP Guide -->
<script>
    function setWelcomeMessage() {
        var name = document.location.hash.substring(1); // User-controlled part of URL
        document.write("Welcome " + name + "!"); // Vulnerable sink
    }
    setWelcomeMessage();
</script>

If the URL is http://hostname/welcome.html#name=<script>alert(1)</script>, the script in the hash is read by JavaScript and written to the DOM, executing alert(1).

Root Cause: The root cause is client-side JavaScript directly using untrusted data from the DOM (e.g., document.location, window.location, document.URL, document.referrer) to modify the HTML DOM without proper sanitization or encoding. This allows an attacker to inject script that is then interpreted and executed by the browser.
Remediation / Secure Fix:
1. Client-Side Sanitization/Encoding: All untrusted data that modifies the DOM must be sanitized or encoded before being written to the DOM. Use JavaScript encoding functions (e.g., ESAPI.encoder().encodeForJavaScript()) or HTML sanitizers on the client side.
2. Avoid Dangerous JavaScript Functions: Avoid functions like eval(), document.write(), document.writeln(), innerHTML, setTimeout(), setInterval() when processing untrusted data, as they are common sinks for DOM-based XSS.
3. Use Safe DOM Manipulation: Prefer safe DOM manipulation methods like textContent or createElement combined with appendChild instead of innerHTML when inserting untrusted data.
4. Static Analysis Tools: Use static analysis tools with taint analysis to identify data flows from sources to sinks.

Corrected Code Example: Using safe DOM manipulation (representative):

<!-- Corrected HTML with JavaScript example (representative) -->
<div id="welcomeDiv"></div>
<script>
    function setWelcomeMessage() {
        var name = document.location.hash.substring(1); // Still user-controlled source
        var welcomeDiv = document.getElementById("welcomeDiv");
        // Safely set text content, not HTML
        welcomeDiv.textContent = "Welcome " + name + "!"; // Safest sink
        // Alternatively, if HTML is needed and sanitized:
        // welcomeDiv.innerHTML = DOMPurify.sanitize("Welcome " + name + "!"); // Using a sanitizer library
    }
    setWelcomeMessage();
</script>

Explanation of Fix: By using safe DOM manipulation methods like textContent, the browser treats any injected HTML or script as literal text, preventing it from being parsed and executed as code. Avoiding dangerous functions and implementing client-side sanitization libraries ensures that even if user input reaches a DOM manipulation function, it is rendered harmlessly.

3. Broken Authentication

Broken Authentication encompasses various vulnerabilities related to the improper implementation or design of authentication mechanisms, allowing attackers to bypass authentication, impersonate legitimate users, or gain unauthorized access to accounts.

Verbose Failure Messages (Username Enumeration)

Description / Definition: Verbose failure messages disclose different responses (error messages, HTTP status codes, response lengths, or subtle HTML differences) depending on whether a username is valid or invalid during login or other authentication-related functions (e.g., password reset). This allows attackers to enumerate valid usernames, which can then be targeted for brute-force or password-guessing attacks.
Vulnerable Behavior Example:
- "Username not found." vs. "Incorrect password." messages for invalid vs. valid usernames.
- Different HTTP status codes (e.g., 200 OK vs. 403 Forbidden) or different response lengths/times for valid vs. invalid usernames.
Root Cause: The root cause is the application's failure to provide a generic, indistinguishable response for all failed login attempts, regardless of whether the username was valid or the password incorrect. This often stems from developers creating distinct code paths for different failure conditions, inadvertently leaking information.
Remediation / Secure Fix:
1. Generic Error Message: Always return a single, generic error message for all failed login attempts (e.g., "Invalid username or password").
2. Consistent Responses: Ensure that HTTP status codes, response lengths, and response times are consistent for all failed attempts to prevent inference.
3. Account Lockout (Rate Limiting): Implement rate limiting and account lockout mechanisms to deter brute-force attacks on usernames, but be careful not to disclose lockout status for specific accounts.
Explanation of Fix: A generic error message eliminates the attacker's ability to differentiate between valid and invalid usernames based on the application's response, thus preventing enumeration. Consistent response behavior (status codes, lengths, times) reinforces this by removing other detectable "side channels" of information leakage.

Description / Definition:
- Weak Passwords: Applications allowing users to set easily guessable passwords (e.g., dictionary words, short passwords, simple patterns, predictable initial passwords).
- Brute-Forcible Login: Applications failing to implement adequate controls (like rate limiting) to prevent an attacker from systematically guessing passwords through a large number of attempts.
Vulnerable Behavior Example:
- An application allowing "password" as a password.
- No lockout after 100 failed login attempts, allowing unlimited guessing.
- Initial passwords generated sequentially, e.g., user001, user002.
Root Cause:
- Weak Password Policies: Lack of robust password complexity rules (length, character types).
- Insufficient Rate Limiting: Failure to implement mechanisms to detect and block or slow down repeated failed login attempts from a single source or against a single account.
- Predictable Generation: Use of weak or easily reversible algorithms for generating initial or temporary passwords.
Remediation / Secure Fix:
1. Strong Password Policy: Enforce strong password complexity rules (minimum length, combination of character types) and prevent the use of common dictionary words.
2. Rate Limiting/Account Lockout: Implement rate limiting on login attempts (e.g., delaying responses, CAPTCHAs after a few failures) and account lockout after a reasonable number of failed attempts. Be careful not to leak enumeration info, as noted above.
3. Salted Hashing for Passwords: Store passwords using strong, salted, and adaptive hashing algorithms (e.g., bcrypt, Argon2). Never store cleartext passwords.
4. Secure Password Generation: If generating passwords, use cryptographically secure random number generators to ensure unpredictability.
5. Multi-factor Authentication (MFA): Implement MFA for critical accounts [206 (Implied)].
Explanation of Fix: Strong password policies make brute-force attacks computationally expensive and impractical. Rate limiting and account lockout directly mitigate brute-force attacks by slowing down or stopping an attacker's attempts. Salted hashing protects stored passwords even if the database is breached, making it impossible to reverse hashes to plaintext or use rainbow tables. Cryptographically secure generation ensures new passwords are unpredictable.

Vulnerable Transmission & Insecure Storage of Credentials

Description / Definition:
- Vulnerable Transmission: Credentials (usernames, passwords) are transmitted over unencrypted channels (HTTP instead of HTTPS) or are exposed in URLs or cookies.
- Insecure Storage: Passwords are stored in plaintext, easily reversible encryption, or unsalted/weakly hashed forms in the database or filesystem.
Vulnerable Behavior Example:
- http://www.wahh-app.com/app?action=login&uname=joe&password=pass – Credentials in URL query string.
- A database containing a "passwords" column with cleartext values.
- Multiple user accounts sharing the same hash for a common password due to lack of salting.
Root Cause:
- Inadequate Use of HTTPS: Failure to use HTTPS for all authentication-related communication.
- Improper Credential Handling: Storing sensitive data in easily accessible locations (URLs, cookies) or using insecure storage methods for passwords (plaintext, weak hashing).
- Lack of Cryptographic Best Practices: Not applying standard, secure algorithms with strong key sizes for password hashing or data encryption.
Remediation / Secure Fix:
1. Always Use HTTPS: All sensitive communication, especially authentication, must occur over HTTPS. Cookies carrying session tokens should be flagged as Secure.
2. Never Store Passwords in Cleartext: Passwords should be hashed using cryptographically strong, salted, adaptive hashing algorithms (e.g., PBKDF2, bcrypt, scrypt, Argon2).
3. Avoid Exposure in URLs/Cookies: Never transmit credentials in URL query strings or set them directly in insecure cookies.
4. Review Cryptographic Implementations: Ensure standard, secure algorithms are used, and custom cryptographic implementations are avoided.

Corrected Code Example: (Illustrates secure hashing, no code for HTTPS itself)

// Java example for secure password storage (representative)
public String hashPassword(String password, byte[] salt) {
    // Use a strong, adaptive hashing algorithm like BCrypt or Argon2 (external library needed)
    // Example using a conceptual strongHash function:
    return strongHash(password, salt);
}
// ... when storing
byte[] salt = generateRandomSalt(); // Cryptographically secure random salt
String hashedPassword = hashPassword(userPassword, salt);
// Store hashedPassword and salt in the database

Explanation of Fix: HTTPS encrypts data in transit, protecting credentials from eavesdropping. Salting adds randomness to password hashing, preventing rainbow table attacks and ensuring that identical passwords result in different hashes for different users. Adaptive hashing algorithms (like bcrypt) are computationally intensive, making brute-force attacks against stored hashes infeasible even with powerful hardware. Avoiding URLs/cookies for credentials prevents their exposure in logs or browser history.

Incomplete Validation of Credentials / Logic Flaws in Authentication

Description / Definition: These are subtle defects in the authentication process where the application's logic for validating credentials or managing authentication states is flawed. This can lead to bypasses, such as a partial password check or allowing login with only a username.

Vulnerable Behavior Example:

// Java example of incomplete validation from Web Application Hacker's Handbook
public boolean checkCredentials(String username, String password) {
    if (!userExists(username)) return false; // Check 1
    if (!passwordMatches(password)) return false; // Check 2 (problematic)
    if (password.length() < 8) return false; // Check 3
    // If passwordMatches() is not called and the application relies on an exception
    // that isn't always thrown or handled, a bypass might occur.
    // ... more complex logic that can be bypassed
    return true;
}

An attacker might find ways to make passwordMatches() not return false (e.g., by causing an exception that is not caught, leading to a "fail-open" state).

Root Cause: The root cause is flawed assumptions or incomplete logic in the authentication flow, especially in complex, multi-layered or multi-stage processes. Developers might overlook edge cases, error handling, or the sequence of validation checks, leading to "fail-open" conditions where the application grants access despite an invalid input.
Remediation / Secure Fix:
1. Full Credential Validation: Passwords should be validated in full, case-sensitively, without filtering or modifying characters, and without truncating them.
2. Aggressive Error Handling: Applications should be aggressive in defending against unexpected events during login processing. Use catch-all exception handlers around all API calls.
3. Strict State Management: Ensure that the authentication state machine is strictly enforced, and unexpected state transitions are rejected.
4. Explicit Failure: Design authentication logic to explicitly fail closed if any validation check or error condition is encountered that prevents full authentication.
Explanation of Fix: Full and consistent credential validation prevents attackers from guessing partial passwords or exploiting weaknesses in the validation logic. Aggressive error handling and explicit "fail closed" design ensure that any unexpected conditions or errors during the authentication process default to denying access, rather than inadvertently granting it.

4. Broken Session Management

Broken Session Management refers to vulnerabilities in how an application manages user sessions, including session ID generation, handling, and termination. Flaws can lead to session hijacking, session fixation, or unauthorized access.

Predictable Session Tokens

Description / Definition: Session tokens (or session IDs) are predictable if an attacker can guess or deduce valid tokens for other users. This predictability can arise from using weak random number generators, sequentially generated IDs, or embedding predictable/meaningful data within the token.
Vulnerable Behavior Example:
- Session IDs that are sequential numbers.
- Session IDs that include easily discoverable information like a username, timestamp, or IP address in a plaintext or easily decodable format.
- Using weak random number generators (java.util.Random instead of SecureRandom).
Root Cause: The root cause is the use of insecure or insufficient entropy sources for generating session IDs, leading to values that are guessable or can be reverse-engineered. Developers may also include meaningful but sensitive data directly in the token, which can be decoded.
Remediation / Secure Fix:
1. Cryptographically Strong Session IDs: Generate session IDs using cryptographically strong random number generators (e.g., java.security.SecureRandom).
2. Meaningless Content: Session ID content (or value) must be meaningless to prevent information disclosure attacks. Avoid embedding any user-specific or predictable data directly in the ID.
3. Sufficient Length and Character Set: Ensure session IDs are of sufficient length and use a broad character set to increase entropy and make brute-forcing impractical.
4. Regular Regeneration: Regenerate session IDs after successful authentication and privilege level changes to mitigate session fixation.

Corrected Code Example:

// Java example for generating a secure random number (from OWASP Guide)
package org.owasp.java.crypto;
import java.security.SecureRandom;
import java.security.NoSuchAlgorithmException;
// ...
public class RandomNumberGenerator {
    public static void main(String[] args) {
        try {
            SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); // Or another strong algorithm
            byte[] bytes = new byte; // Generate 16 bytes for a strong session ID
            sr.nextBytes(bytes);
            // Convert bytes to a hex or Base64 string for the session ID
            // String sessionId = new BASE64Encoder().encode(bytes); // Example
            // ... then set the cookie
        } catch (NoSuchAlgorithmException e) {
            // handle exception
        }
    }
}

Explanation of Fix: Cryptographically strong random number generators produce high-entropy, unpredictable session IDs, making them practically impossible for an attacker to guess. Ensuring the ID is meaningless prevents information leakage if an attacker captures it. Regular regeneration of IDs (especially after login) prevents an attacker from using a known, unauthenticated session ID to hijack a legitimate, authenticated session (session fixation).

Insecure Session Token Transmission & Disclosure

Description / Definition: Session tokens are transmitted insecurely (e.g., over HTTP) or are disclosed in vulnerable locations such as application logs, URLs, or error messages. This can allow attackers to steal session tokens and hijack user sessions.
Vulnerable Behavior Example:
- Session tokens transmitted in the URL query string (http://example.com/page?sessionid=abc).
- Session tokens sent over plain HTTP instead of HTTPS.
- Application logs (accessible by attackers or compromised parties) containing plaintext session IDs.
Root Cause: The root cause is the failure to enforce HTTPS for all sensitive communication and improper logging or handling of sensitive session information. Developers might mistakenly believe that only login pages need HTTPS, or they might log too much sensitive data.
Remediation / Secure Fix:
1. Always Use HTTPS: Session tokens must only be transmitted over HTTPS.
2. Secure Cookie Flag: HTTP cookies used for session tokens should be flagged as Secure to prevent browsers from sending them over unencrypted HTTP.
3. HttpOnly Cookie Flag: Use the HttpOnly flag to prevent client-side scripts (like JavaScript) from accessing the session cookie, mitigating XSS-based session hijacking.
4. Never Expose in URLs: Session IDs should never be passed in URLs (query strings or path parameters).
5. Sensitive Data Logging: Avoid logging sensitive information like session tokens in application logs that could be accessed by unauthorized parties.
Explanation of Fix: HTTPS encryption protects the session token from eavesdropping during transit. The Secure flag ensures the browser only sends the cookie over encrypted connections. The HttpOnly flag prevents client-side script access, making XSS-based session hijacking more difficult. Avoiding URLs prevents tokens from being exposed in browser history, server logs, or referrer headers. Restricting logging of sensitive data prevents their disclosure if logs are compromised.

Session Fixation

Description / Definition: Session fixation allows an attacker to "fix" a victim's session ID to a value known to the attacker. If the application does not issue a new session ID after successful authentication, the victim's authenticated session will use the attacker-supplied ID, allowing the attacker to hijack the session.
Vulnerable Behavior Example:
1. Attacker visits an application, obtains a session ID (e.g., in a URL parameter).
2. Attacker sends this fixed session ID to the victim.
3. Victim logs in using the fixed session ID.
4. Application does not issue a new session ID after login.
5. Attacker uses the original, fixed session ID to access the victim's now-authenticated session.
Root Cause: The root cause is the application's failure to generate a new, cryptographically strong session ID upon successful user authentication or any change in privilege level.
Remediation / Secure Fix:
1. Generate New Session ID on Login: Always invalidate the old session and generate a completely new session ID after a user successfully authenticates.
2. Invalidate Session on Logout: Properly invalidate sessions upon logout.

Corrected Code Example:

// Java example to invalidate old session and create new one (from OWASP Guide)
request.getSession(false).invalidate(); // Invalidate existing session
// Then create a new session
request.getSession(true); // getSession() also creates new if none exists

Explanation of Fix: By invalidating the pre-authentication session ID and issuing a new one upon successful login, the application ensures that the attacker's "fixed" session ID becomes invalid, and the attacker can no longer use it to access the victim's authenticated session.

5. Access Control Vulnerabilities (Missing Function Level Access Control)

Access control vulnerabilities occur when an application fails to properly enforce restrictions on what authenticated users can do or access. This can lead to horizontal privilege escalation (accessing other users' data at the same privilege level) or vertical privilege escalation (accessing functions or data reserved for higher-privileged users).

Unprotected Functionality (Vertical Privilege Escalation)

Description / Definition: This vulnerability allows a lower-privileged user to access functionality or pages intended for higher-privileged users (e.g., administrative functions) by directly navigating to the URL or manipulating parameters, without proper server-side authorization checks.
Vulnerable Behavior Example:
- An administrative page (e.g., /admin/users.jsp) that can be accessed by a regular user simply by typing the URL, even if there's no link to it in their UI.
- Client-side JavaScript or HTML comments containing references to hidden administrative URLs or API methods.
Root Cause: The root cause is the reliance on client-side controls (e.g., hiding links, disabling buttons) for enforcing access control, or the absence of robust server-side authorization checks for every request to sensitive functionality. Developers might assume that if a function is not linked, it cannot be accessed.
Remediation / Secure Fix:
1. Server-Side Enforcement: All access control decisions must be enforced on the server-side. Client-side controls should only be used for UI/UX, not security.
2. Per-Function Authorization: Implement explicit authorization checks for every sensitive function or resource, verifying the user's role and permissions before executing the action or returning data.
3. Role-Based Access Control (RBAC): Use a robust RBAC model, where access is granted based on assigned roles, and these checks are performed at every access point.
4. Least Privilege: Applications should always apply the principle of least privilege, granting users only the minimum necessary permissions for their tasks.

Corrected Code Example: (Representative example, demonstrating server-side check)

// Java example for server-side authorization check (representative)
public void adminPage(HttpServletRequest request, HttpServletResponse response) {
    if (!request.getSession().getAttribute("userRole").equals("admin")) { // Server-side role check
        response.sendError(HttpServletResponse.SC_FORBIDDEN, "Access Denied");
        return;
    }
    // Proceed with administrative functionality
}

Explanation of Fix: Enforcing access control on the server-side means that even if an attacker bypasses client-side restrictions or guesses URLs, the server will independently verify their authorization, denying access if privileges are insufficient. Per-function authorization ensures that no sensitive action is left unprotected, preventing unauthorized users from invoking them.

Insecure Direct Object Reference (Horizontal Privilege Escalation)

Description / Definition: Insecure Direct Object Reference (IDOR) vulnerabilities occur when an application exposes a direct reference to an internal implementation object (like a file, database key, or directory) and allows a user to manipulate this reference to access resources they are not authorized to view or modify, typically belonging to another user at the same privilege level.

Vulnerable Behavior Example:

// Java example from OWASP Guide
String query = "SELECT * FROM accts WHERE account = ?"; // Uses parameter for account number
PreparedStatement pstmt = connection.prepareStatement(query, ...);
pstmt.setString(1, request.getParameter("acct")); // Untrusted 'acct' parameter
ResultSet results = pstmt.executeQuery();

An attacker might change the acct parameter in the URL (e.g., viewinvoice.jsp?acct=12345) to viewinvoice.jsp?acct=67890 to access another user's account without proper authorization checks.

Root Cause: The root cause is the application's failure to implement proper authorization checks to verify if the user requesting a resource is indeed authorized to access that specific resource, especially when the resource is identified by user-controlled input. The application assumes that direct object references provided by the user are always legitimate.
Remediation / Secure Fix:
1. Per-Resource Authorization: For every request involving a direct object reference, the application must perform an authorization check to confirm the user is authorized for that specific object.
2. Indirect Object References: Use indirect object references (e.g., a per-session, per-user, or randomly generated index) instead of direct database keys or file names in URLs or parameters. Map these indirect references to the actual objects on the server-side.
3. Input Validation: Ensure any untrusted input used to reference objects is properly understood and used by the server-side code, although authorization is the primary defense.
Explanation of Fix: Per-resource authorization checks ensure that even if an attacker guesses valid object IDs, they will only be granted access if their authenticated session is explicitly linked to that resource. Indirect object references make it harder for attackers to guess valid resource identifiers, adding an additional layer of security, though the server-side authorization check remains the critical control.

6. Security Misconfiguration

Security Misconfiguration refers to vulnerabilities arising from improperly configured security settings across the application stack, including web servers, application servers, databases, frameworks, and custom code.

Description / Definition: This category includes vulnerabilities due to:
- Default accounts or credentials that are left unchanged.
- Default or unnecessary content (e.g., sample applications, development files) exposed in production environments.
- Improper permissions on files and directories.
- Missing security hardening (e.g., disabling unneeded services, insecure error handling).
Vulnerable Behavior Example:
- A production server with default admin username/password (e.g., admin/admin).
- Default sample applications like Apache Tomcat's "Sessions Example" script that exposes session variables.
- Directory listings enabled on web servers, allowing attackers to browse file structures.
- Insecure error handling disclosing sensitive debug information.
Root Cause: The root cause is often a lack of awareness or oversight during deployment, where default, insecure settings are not changed, or unnecessary components are left exposed. It can also stem from complex frameworks with many configurable options, making it difficult to secure everything correctly.
Remediation / Secure Fix:
1. Secure Installation and Hardening: Follow secure installation guides and hardening checklists for all components (OS, web server, application server, database, frameworks).
2. Change Defaults: Change all default credentials and remove any default accounts not strictly required.
3. Remove Unnecessary Features/Content: Remove or disable all unused features, components, services, and default content (e.g., sample applications, old files, debug functionality) from production servers.
4. Principle of Least Privilege: Configure all accounts, processes, and file/directory permissions with the minimum necessary privileges.
5. Secure Error Handling: Implement generic error pages and ensure verbose error messages or stack traces are not displayed to users. Logs containing sensitive information should be stored server-side and secured.
6. Automated Security Scans: Regularly run automated security misconfiguration scans to identify deviations from secure baselines.
Explanation of Fix: Hardening and removing defaults eliminate easy entry points for attackers who rely on common configurations. Least privilege minimizes the impact if a component is compromised. Secure error handling prevents information leakage that attackers can use to fine-tune attacks. These measures create a more robust and smaller attack surface for the application.

7. Sensitive Data Exposure (Cryptographic Flaws)

Sensitive Data Exposure occurs when applications fail to adequately protect sensitive data (e.g., financial information, PII, passwords) both at rest and in transit. This often stems from improper implementation of cryptographic controls.

Description / Definition: Vulnerabilities include:
- Use of non-standard cryptographic algorithms or custom implementations.
- Use of cryptographically insecure standard algorithms (e.g., DES, MD5 for passwords without salting).
- Insecure key management (e.g., hardcoding keys, weak key sizes, improper key storage).
- Lack of encryption for sensitive data in storage or transit.
Vulnerable Behavior Example:
- A custom hashing algorithm implemented by a developer instead of well-vetted library functions.
- Storing passwords using MD5 without a unique salt per password.
- Hardcoding encryption keys within the application source code.
Root Cause: The root cause is typically a lack of cryptographic expertise among developers, leading them to implement weak or incorrect cryptographic practices, or choose outdated/insecure algorithms. Developers may "roll their own" crypto instead of using well-vetted, standard libraries.
Remediation / Secure Fix:
1. Use Standard, Strong Algorithms: Always use standard, cryptographically strong algorithms (e.g., AES for encryption, SHA-256/SHA-512 for hashing with proper salting, modern KDFs like PBKDF2, bcrypt, scrypt, Argon2 for password storage).
2. Never "Roll Your Own Crypto": Never implement custom cryptographic algorithms; instead, use functions provided by the language, framework, or common (trusted) cryptographic libraries.
3. Secure Key Management: Implement secure practices for generating, storing, and managing cryptographic keys. Avoid hardcoding keys.
4. Encrypt Data at Rest and in Transit: Ensure sensitive data is encrypted both when stored (at rest) and when transmitted (in transit) using strong encryption protocols like TLS.
5. Regularly Update Crypto Libraries: Keep cryptographic libraries and implementations up-to-date to benefit from security patches and new best practices.

Corrected Code Example: (Illustrates concept of using a trusted library for hashing)

// Java example for secure hashing using a standard library (conceptual, specific library not in source)
// Avoids custom hash functions or simple MD5/SHA-1 without salting.
public String hashPasswordSecurely(String password) throws NoSuchAlgorithmException, InvalidKeySpecException {
    // Example: Using PBKDF2 (requires proper salt generation and iteration count)
    SecureRandom random = new SecureRandom();
    byte[] salt = new byte;
    random.nextBytes(salt);

    PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 65536, 256); // High iteration count, key length
    SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
    byte[] hash = factory.generateSecret(spec).getEncoded();

    // Store salt and hash securely
    return Base64.getEncoder().encodeToString(salt) + ":" + Base64.getEncoder().encodeToString(hash);
}

Explanation of Fix: Relying on standard, well-vetted cryptographic libraries ensures that the algorithms and their implementations have been rigorously tested and are resistant to known attacks. Secure key management prevents attackers from accessing the "keys to the kingdom" even if they gain some level of system access. Proper hashing with salts and adaptive functions for passwords and encryption for other sensitive data protects against brute-force, rainbow table, and decryption attacks.

8. Cross-Site Request Forgery (CSRF)

Description / Definition: Cross-Site Request Forgery (CSRF) is an attack that forces an authenticated end-user to submit an unwanted request to a web application they are currently authenticated to. Unlike XSS, CSRF attacks target the application's functionality, not its users directly, by leveraging the trust the application has in the user's browser.
Vulnerable Behavior Example: (Representative, based on's explanation) A banking application allows a user to transfer funds via a POST request that looks like: POST /transfer HTTP/1.1 Cookie: sessionid=abc... amount=1000&account=attacker_account

If this request doesn't include any unpredictable tokens, an attacker can create a malicious HTML page:
```

<form action="http://bank.com/transfer" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="account" value="attacker_account">
    <input type="submit" value="Click me!">
</form>
<script>
    document.forms.submit(); // Auto-submits the form
</script>
```
If a logged-in user visits this page, the form is submitted to bank.com with the user's session cookie, performing the transfer.
Root Cause: The root cause is that the application relies solely on session cookies for tracking user sessions and does not include any unique, unpredictable, and user-specific token in sensitive requests to verify that the request originated from the legitimate user's browser. Browsers automatically include session cookies with cross-site requests, which the application implicitly trusts.
Remediation / Secure Fix:
1. Anti-CSRF Tokens (Synchronizer Token Pattern): The primary defense is to include a unique, unpredictable, and cryptographically strong anti-CSRF token in every state-changing request. This token should be generated server-side, associated with the user's session, and validated on the server. It should be placed in hidden form fields or custom HTTP headers, not in cookies.
2. SameSite Cookie Attribute: Use the SameSite cookie attribute (Lax or Strict) to instruct browsers to restrict sending cookies with cross-site requests. (This is not explicitly in the sources but is a modern related best practice.)
3. Referrer Header Validation: While not a standalone defense, checking the Referer header can offer some protection, but it can be bypassed.
4. Re-authentication: For highly sensitive actions, requiring the user to re-authenticate can mitigate CSRF.

Corrected Code Example: (Representative)

<!-- HTML form with anti-CSRF token -->
<form action="/transfer" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="account" value="attacker_account">
    <input type="hidden" name="csrf_token" value="GENERATED_SERVER_SIDE_TOKEN"> <!-- Anti-CSRF token -->
    <input type="submit" value="Transfer Funds">
</form>

On the server, before processing the transfer:

// Java example for server-side CSRF token validation (representative)
String submittedToken = request.getParameter("csrf_token");
String sessionToken = request.getSession().getAttribute("csrf_token");

if (submittedToken == null || !submittedToken.equals(sessionToken)) {
    response.sendError(HttpServletResponse.SC_FORBIDDEN, "Invalid CSRF token");
    return;
}
// Proceed with funds transfer

Explanation of Fix: An anti-CSRF token acts as a secret shared only between the legitimate user's browser and the server for a specific request. When a malicious request is forged, the attacker cannot obtain this secret token (due to the same-origin policy), so the forged request will lack the valid token, and the server will reject it. This breaks the trust relationship that CSRF attacks exploit.

9. Unvalidated Redirects and Forwards

Description / Definition: Unvalidated Redirects and Forwards allow an attacker to redirect or forward a user to an arbitrary, untrusted URL based on unvalidated user input. This can be used for phishing attacks, malware distribution, or to bypass access controls for internal forwards.

Vulnerable Code Example:

// Java example from OWASP Guide
String url = request.getParameter("url"); // User-controlled 'url' parameter
response.sendRedirect(url); // Vulnerable, redirects to arbitrary URL

An attacker could submit ?url=http://malicious.com to redirect the victim.

Root Cause: The root cause is the application's failure to validate user-supplied input used to determine redirect or forward destinations. The application implicitly trusts that the provided URL or path is safe.
Remediation / Secure Fix:
1. Whitelist Destinations: All redirects/forwards must be constructed based on a whitelist of known, safe destinations.
2. Relative Paths: Use relative paths for redirects whenever possible to ensure the user stays on the trusted site.
3. Strict Input Validation: If external redirects are necessary, strictly validate the user-supplied URL to ensure it matches allowed patterns and does not contain malicious schemes or hosts.

Corrected Code Example:

// Java example with whitelist validation (representative)
String urlParam = request.getParameter("url");
List<String> allowedUrls = Arrays.asList("/home", "/profile", "/logout"); // Whitelist of relative paths

if (allowedUrls.contains(urlParam)) {
    response.sendRedirect(urlParam); // Safe redirect to known internal path
} else {
    response.sendRedirect("/error"); // Redirect to a safe default page
}

Explanation of Fix: A whitelist ensures that the application will only redirect or forward to predefined, trusted locations, preventing an attacker from arbitrarily sending users to malicious sites. Using relative paths further constrains redirects to within the current application, reducing the scope of potential attacks.

10. Application Logic Flaws

Application logic flaws (also known as business logic flaws) are defects in an application's design or implementation that allow an attacker to subvert the intended workflow or rules of the application to achieve unauthorized outcomes. These are highly varied and often unique to each application's specific functionality.

Description / Definition: Logic flaws can manifest in many ways, including:
- Bypassing multi-stage processes by skipping steps or submitting requests out of sequence.
- Invalidating input validation by exploiting the order or recursion of validation steps (e.g., truncation after sanitization).
- Abusing search functions to infer sensitive data not directly accessible.
- Exploiting race conditions where concurrent requests can lead to unintended states.
- Trust boundary violations where components implicitly trust data from other, less-secured components.
Vulnerable Behavior Example:
- Bypassing multi-stage process: A "password change" function that requires current password, new password, and confirmation, but can be bypassed by omitting the "current password" parameter.
- Invalidating input validation: An application filters single quotes then truncates input. An attacker submits admin'-- which becomes admin''--. If the filter is applied, but then truncation cuts off some of the escaping, it might become admin' again, leading to SQL Injection.
- Abusing Search: A search function for "public documents" also indexes "private documents". Searching for parts of private documents reveals their existence or content through hits, even if the user can't view them directly.
Root Cause: The root cause is typically flawed assumptions made by designers or developers about user behavior, data integrity, or the interaction between different application components. They fail to consider how an attacker might intentionally violate these assumptions. Complex applications with multiple developers and layered logic are particularly susceptible.
Remediation / Secure Fix:
1. Thorough Design Documentation: Document every aspect of the application's design, including all assumptions made by developers and designers.
2. Clear Code Comments: Comment source code to explain the purpose of components, their assumptions, and client code dependencies.
3. Strict State Management: For multi-stage processes, strictly enforce the expected sequence of steps and reject out-of-sequence requests. Use server-side state machines.
4. Validate All Input: Understand how input validation interacts with other data transformations (truncation, encoding) and ensure robust validation at all layers, not just at the entry point.
5. Test Trust Boundaries: Explicitly define and test trust boundaries between application components. Treat data from adjacent components with the same skepticism as external user input.
6. Review Search Indexing: Ensure search functions only index data appropriate for the user's privilege level, and that results do not allow inference of unauthorized data.
7. Systematic Logic Testing: Conduct systematic probing and lateral thinking to test the application's behavior in response to unexpected input or sequence changes.
Explanation of Fix: Thorough documentation and clear code comments help prevent flawed assumptions from being introduced or remaining undetected. Strict server-side state management ensures that business processes are followed correctly, preventing attackers from skipping steps or manipulating workflows. Robust input validation at all stages and explicit trust boundary definitions mitigate issues arising from data transformations or inter-component communication. Ultimately, imaginative and systematic testing is key to uncovering these subtle flaws.

11. Native Code Vulnerabilities

These vulnerabilities specifically affect applications written in native code languages like C and C++, which do not run in managed execution environments (like Java or .NET). They are low-level memory safety issues that can be exploited for arbitrary code execution or denial of service.

Buffer Overflows

Description / Definition: Buffer overflows occur when a program attempts to write more data into a fixed-size memory buffer than it can hold, overwriting adjacent memory locations. This can lead to crashes (denial of service), corruption of data, or, in severe cases, arbitrary code execution by overwriting return addresses or other critical program data.

Vulnerable Code Example: (Representative, based on's general description)

// C example (representative)
char buffer; // Fixed-size buffer
strcpy(buffer, userinput); // Vulnerable if userinput > 199 characters (plus null terminator)

If userinput is larger than 199 characters, strcpy will write beyond buffer's boundary.

Root Cause: The root cause is the use of unsafe C/C++ string or memory manipulation functions (e.g., strcpy, strcat, memcpy, sprintf) that do not perform bounds checking and do not explicitly ensure the destination buffer is large enough for the source data.
Remediation / Secure Fix:
1. Use Bounds-Checking Functions: Always use safe, bounds-checking versions of string/memory functions (e.g., strncpy, strncat, memcpy_s, snprintf) or higher-level abstractions that manage memory safely.
2. Input Length Validation: Validate the length of user input before copying it into fixed-size buffers.
3. Managed Memory Environments: Where possible, develop in languages that use managed memory environments (e.g., Java, C#, Python) where buffer overflows are significantly less common.
4. Compiler Protections: Enable compiler-level protections (e.g., Stack Smashing Protectors like /GS in Visual C++, -fstack-protector in GCC/Clang) [636 (implied)].

Corrected Code Example: (Representative)

// C example with bounds-checking (representative)
char buffer;
// Ensure userinput_len is properly calculated and does not exceed buffer size
strncpy(buffer, userinput, sizeof(buffer) - 1); // Copies at most size-1 characters
buffer[sizeof(buffer) - 1] = '\0'; // Ensure null termination

Explanation of Fix: Bounds-checking functions explicitly prevent writing beyond the allocated buffer size, truncating input if necessary, thereby eliminating the overflow condition. Input validation ensures that malicious overlong input is detected and rejected early. Using managed languages offloads memory management to a runtime, eliminating common low-level memory errors.

Integer Vulnerabilities

Description / Definition: Integer vulnerabilities arise from improper handling of integer values within calculations or comparisons, leading to issues like:
- Integer Overflow/Underflow: When an arithmetic operation produces a value that is too large (overflow) or too small (underflow) to be stored in the intended integer type, causing it to "wrap around".
- Signedness Errors: Mismatching signed and unsigned integer types in operations or comparisons, leading to unexpected behavior.

Vulnerable Behavior Example: (Representative, based on's explanation)

// C example (representative)
int numItems = request.getParameter("items"); // User supplies a large number like 2,000,000,000
int pricePerItem = 2;
int totalCost = numItems * pricePerItem; // Integer overflow if totalCost exceeds max int value
// totalCost might wrap around to a negative number, leading to discount or free items

Root Cause: The root cause is insufficient validation of integer inputs and outputs, combined with a lack of awareness of how integer types behave at their boundaries and when different types (signed/unsigned) interact.
Remediation / Secure Fix:
1. Input Range Validation: Validate that user-supplied numerical inputs are within expected safe ranges to prevent overflow/underflow before performing calculations.
2. Use Larger Data Types: Use integer data types that are sufficiently large to hold expected values, or use fixed-precision arithmetic for financial calculations.
3. Careful Signed/Unsigned Comparisons: Be cautious when mixing signed and unsigned integer types in comparisons or arithmetic operations.
4. Error Handling for Arithmetic Operations: Explicitly check for overflow/underflow conditions after sensitive arithmetic operations.
Explanation of Fix: Input range validation prevents attackers from supplying values that would cause integer overflows or underflows. Using appropriately sized data types and explicit checks ensures that calculations do not produce unintended results due to integer wrapping.

Format String Bugs

Description / Definition: Format string bugs occur when an application processes user-supplied input as a format string in functions like printf or sprintf. This can allow an attacker to read or write arbitrary memory locations, or even execute arbitrary code, by supplying specially crafted format specifiers (e.g., %x, %n, %s).
Vulnerable Code Example: (Representative, based on's explanation)
```
// C example (representative)
char buffer;
sprintf(buffer, request.getParameter("input")); // Vulnerable: input is directly used as format string
```
If request.getParameter("input") is "%x%x%x%x", it will print stack contents. If it contains %n, it can write to memory.
Root Cause: The root cause is passing unvalidated user input directly as the format argument to format string functions. These functions interpret the input as instructions for how to parse and print subsequent arguments, which an attacker can manipulate to access memory or crash the application.
Remediation / Secure Fix:
1. Never Use User Input as Format String: The most effective defense is to never pass user-supplied input as the format argument to printf-style functions.
2. Use Fixed Format String: Always use a fixed, constant format string, and pass user input as separate arguments (e.g., printf("%s", user_input);).
3. Input Validation: Validate and sanitize any user input that might be processed by format string functions to ensure it does not contain format specifiers.

Corrected Code Example: (Representative)

// C example with fixed format string (representative)
char buffer;
sprintf(buffer, "%s", request.getParameter("input")); // Secure: user input is treated as a string argument

Explanation of Fix: By using a fixed format string (%s) and passing the user input as a separate argument, the format string function is prevented from interpreting the user's input as its own formatting instructions. Instead, it treats the entire user input as a single string to be printed, effectively neutralizing any malicious format specifiers.

12. Information Disclosure

Information Disclosure vulnerabilities occur when an application unintentionally reveals sensitive information to an attacker that could be used to compromise the application or its underlying systems.

Description / Definition: This includes:
- Verbose Error Messages: Revealing stack traces, database error messages, internal paths, or debugging information.
- Source Code Comments: Containing sensitive details like usernames, passwords, "TODO" items for security fixes, or internal logic.
- Directory Listings: Allowing directory browsing on web servers.
- Insecure Logging: Logging sensitive data (passwords, session IDs, PII) in plaintext logs accessible to attackers.
- Debug Parameters: Hidden parameters (e.g., debug=true) that, when enabled, expose sensitive information or alter security logic.
Vulnerable Behavior Example:
- A database error message exposing parts of the SQL query and database schema (Server: Msg 105, Level 15... Unclosed quotation mark...).
- A stack trace showing internal class names, file paths, and library versions.
- A comment in source code: char buf; // I hope this is big enough indicating a potential buffer overflow.
- An application logging plaintext passwords.
Root Cause: The root cause is generally a lack of security awareness during development and deployment, leading to implicit trust in internal processes or components. Developers may leave debugging features enabled in production, fail to strip sensitive comments, or not configure logging appropriately.
Remediation / Secure Fix:
1. Generic Error Messages: Never return verbose error messages, stack traces, or debug information to the user's browser. Implement a single, generic error page.
2. Secure Logging: Log sensitive information only to a secure, server-side log file that is not publicly accessible. Sanitize all event data to prevent log injection attacks and to remove sensitive data.
3. Remove Debug Functionality: Ensure all debugging functionality, test code, and development-specific content are removed or disabled in production environments.
4. Code Review for Sensitive Comments: Conduct thorough code reviews to identify and remove sensitive comments (e.g., TODOs for security, hardcoded credentials) from production code.
5. Disable Directory Listings: Configure web servers to disable directory listings.
6. Apply Least Privilege: Ensure that accounts and processes run with minimal privileges, limiting the information accessible even if compromised.
Explanation of Fix: Generic error messages deny attackers clues about the application's internal structure or specific vulnerabilities. Secure logging ensures sensitive data remains confidential even if an attack triggers verbose logging. Removing debug features and sensitive comments prevents attackers from leveraging internal developer notes or functionality for exploitation. Disabling directory listings prevents attackers from easily mapping application content.

This category covers attacks that leverage application or browser weaknesses to exfiltrate sensitive data across domain boundaries or inject client-side code in unexpected ways, often bypassing the Same-Origin Policy.

UI Redress Attacks (Clickjacking/Strokejacking)

Description / Definition: UI Redress attacks, like clickjacking, trick users into clicking on invisible or disguised elements on a malicious webpage that are actually transparent overlays of elements from another, legitimate site. This can lead to unintended actions on the legitimate site, such as making purchases, changing settings, or revealing sensitive information. Strokejacking is similar but involves keylogging.
Vulnerable Behavior Example: (Representative, based on) A legitimate website allows a one-click purchase button. An attacker loads this site in an invisible iframe on their malicious site and overlays a tempting "Click here for a free prize!" button over the purchase button. When the user clicks for the "prize," they unknowingly trigger the purchase on the legitimate site.
Root Cause: The root cause is the absence of proper frame-busting defenses (HTTP headers) by the legitimate application, allowing it to be embedded within iframes on other domains.
Remediation / Secure Fix:
1. X-Frame-Options Header: Implement the X-Frame-Options HTTP header with DENY or SAMEORIGIN values to prevent the page from being embedded in iframes on other domains.
2. Content Security Policy (CSP) frame-ancestors directive: Use CSP's frame-ancestors directive for more granular control over framing.
3. Frame-Busting JavaScript: While less reliable than headers, JavaScript frame-busting code can be used as a secondary defense.
Explanation of Fix: The X-Frame-Options header instructs the browser not to display the page in a frame if it's from a different origin, directly preventing clickjacking attacks by removing the attacker's ability to overlay content.

Description / Definition: Client-side cookie injection allows an attacker to inject arbitrary cookies into a user's browser for a specific domain. This can bypass certain client-side controls or lead to session fixation if the application accepts the injected cookie as a valid session identifier.
Vulnerable Behavior Example: (Representative, based on) An application echoes unvalidated user input into a JavaScript string that is then used to set a cookie.
```
// JavaScript (representative)
document.cookie = "user=" + decodeURIComponent(window.location.hash.substring(1)); // Vulnerable
```
An attacker crafts a URL like http://example.com/page#user=attacker%3B%20sessionid=fixedvalue, which could inject sessionid into the victim's cookies.
Root Cause: The root cause is the unvalidated inclusion of user-controlled data into client-side scripts that set cookies, or server-side reflected input that can influence client-side cookie setting.
Remediation / Secure Fix:
1. Strict Client-Side Input Validation: Validate and sanitize all user input used in client-side scripts before it is used to set cookies.
2. Output Encoding: Properly encode user input on the server-side before reflecting it into JavaScript or HTML where it might influence cookie setting.
3. Server-Side Session Fixation Prevention: Implement server-side session fixation prevention by issuing a new session ID after login.
Explanation of Fix: Strict validation and encoding prevent malicious characters from being interpreted as cookie-setting commands in client-side scripts. Server-side session fixation prevention ensures that even if a cookie is injected, it won't be used for an authenticated session.

14. Shared Hosting and Architecture Vulnerabilities

These vulnerabilities arise from weaknesses in the application's overall architecture, especially in multi-tiered or shared hosting environments. Improper segregation or trust relationships can allow a compromise in one component or application to affect others.

Inadequate Segregation in Tiered Architectures

Description / Definition: In multi-tiered architectures (e.g., web server, application server, database server), inadequate segregation means that a compromise in one tier can lead to compromise of other tiers due to overly permissive trust relationships. For example, if the web application runs with high database privileges, a SQL injection on the web tier can fully compromise the database.
Vulnerable Behavior Example:
- Web application connecting to the database using the DBA (Database Administrator) account, instead of a least-privileged account.
- Application server process having file read/write access to MySQL data files.
- Decryption keys for sensitive data stored on the same tier as the encrypted data.
Root Cause: The root cause is the failure to apply the principle of least privilege across different tiers and components. Implicit trust is often placed between tiers, assuming that a higher-tier component will always properly enforce security controls for lower tiers.
Remediation / Secure Fix:
1. Principle of Least Privilege: Apply the principle of least privilege rigorously across all tiers and components. Each tier should only have the minimum necessary permissions to perform its function.
2. Separate Accounts/Permissions: Use separate, restricted accounts for database access, file system operations, and inter-component communication, each with only the necessary permissions.
3. Secure Key Management: Store decryption keys in a separate, highly secured key management system or different tier, separate from the encrypted data.
4. Network Segmentation: Implement strict network segmentation between tiers to limit direct communication paths and enforce security policies.
Explanation of Fix: Applying least privilege minimizes the "blast radius" of a compromise. If the web tier is compromised, an attacker cannot automatically gain DBA privileges if the web application only connects with a limited-privilege account. Segregating keys and sensitive data prevents direct access to them even if the application component itself is breached.

15. Vulnerable Server Configuration and Software

These refer to weaknesses in the web server and application server software itself, or its configuration, which can be leveraged by attackers to compromise the application or underlying system.

Default Credentials & Content

Description / Definition: Vulnerabilities due to web servers or application servers running with default administrative credentials or exposing default, unnecessary content (e.g., sample pages, administration interfaces) in a production environment.
Vulnerable Behavior Example:
- Leaving admin/admin as the default login for a server management console.
- Apache Tomcat's default "manager" application being accessible in production without strong authentication.
- Default documentation or example scripts being browsable, potentially revealing server versions or internal paths.
Root Cause: A lack of hardening and security awareness during deployment. Vendors ship products with defaults for ease of use, but these are often insecure for production, and administrators fail to change them.
Remediation / Secure Fix:
1. Change Default Credentials: Immediately change all default usernames and passwords for web servers, application servers, and any management interfaces.
2. Remove Default/Unnecessary Content: Remove or disable all default, sample, or unnecessary content and applications from production servers.
3. Restrict Management Interfaces: Limit access to administrative interfaces to trusted IP addresses only and/or unique, strong credentials, possibly on a different port.
Explanation of Fix: Changing default credentials removes easy entry points for attackers who rely on publicly known default logins. Removing unnecessary content reduces the attack surface by eliminating potentially vulnerable or informative files/applications that are not needed for production.

Key Takeaways, Best Practices, and Patterns

This comprehensive analysis reveals several recurring themes and best practices for developing secure applications:

Never Trust User Input: This is the fundamental principle of web application security. All input from users, external components, or untrusted sources must be validated and sanitized.
Validate on Output (Context-Sensitive Encoding): For vulnerabilities like XSS, output encoding based on the context of where data is inserted into HTML, JavaScript, or URLs is paramount. Input validation helps, but output encoding is the critical control for display.
Separate Code from Data: For injection vulnerabilities (SQL, LDAP, XPath, OS Command, Script), the core issue is the blending of code and data. Use parameterized queries or APIs that strictly separate user input from executable commands/queries.
Implement Robust Authorization Server-Side: All access control decisions must be enforced on the server-side. Client-side controls are easily bypassed. Employ least privilege and perform per-resource/per-function authorization checks.
Strong Cryptography: Use standard, well-vetted, and cryptographically strong algorithms for hashing passwords (with salts and adaptive functions) and encrypting sensitive data. Never "roll your own crypto".
Secure Session Management: Generate cryptographically strong and unpredictable session IDs. Regenerate session IDs upon authentication or privilege change. Transmit session tokens only over HTTPS and use Secure and HttpOnly flags.
Generic Error Handling: Avoid verbose error messages, stack traces, or debug information in production. Provide generic error messages to prevent information leakage.
Secure Defaults and Hardening: Always change default credentials and remove unnecessary services, content, and debug functionality in production environments. Configure components with the principle of least privilege.
Defense in Depth: No single control is foolproof. Implement multiple layers of security controls throughout the application's design and development lifecycle to provide redundancy in case one defense fails.
Regular Security Testing & Code Review: Conduct manual secure code reviews and penetration testing in addition to automated tools. Manual review provides contextual understanding and can find subtle logic flaws that tools miss. Automated tools can aid in finding common vulnerabilities and scanning large codebases.
Developer Education: Many vulnerabilities stem from a lack of security awareness. Continuous training for developers on secure coding practices is crucial.

By adhering to these principles, developers can significantly reduce the attack surface and enhance the overall security posture of web applications.

WAHH

Vulnerability Report

1. Injection Vulnerabilities

SQL Injection

NoSQL Injection

XPath Injection

LDAP Injection

OS Command Injection

Script Injection (Dynamic Execution)

E-mail Header Manipulation (SMTP Injection)

Back-End HTTP Request Injection (HPI/HPP/Server-Side Redirection)

XML Injection (XXE)

SOAP Injection

2. Cross-Site Scripting (XSS)

Reflected XSS (Non-Persistent)

Stored XSS (Persistent)

DOM-Based XSS

3. Broken Authentication

Verbose Failure Messages (Username Enumeration)

Weak/Predictable Passwords & Brute-Forcible Login

Vulnerable Transmission & Insecure Storage of Credentials

Incomplete Validation of Credentials / Logic Flaws in Authentication

4. Broken Session Management

Predictable Session Tokens

Insecure Session Token Transmission & Disclosure

Session Fixation

5. Access Control Vulnerabilities (Missing Function Level Access Control)

Unprotected Functionality (Vertical Privilege Escalation)

Insecure Direct Object Reference (Horizontal Privilege Escalation)

6. Security Misconfiguration

7. Sensitive Data Exposure (Cryptographic Flaws)

8. Cross-Site Request Forgery (CSRF)

9. Unvalidated Redirects and Forwards

10. Application Logic Flaws

11. Native Code Vulnerabilities

Buffer Overflows

Integer Vulnerabilities

Format String Bugs

12. Information Disclosure

13. Cross-Domain Data Capture (and related Client-Side Injections)

UI Redress Attacks (Clickjacking/Strokejacking)

Client-Side Cookie Injection

14. Shared Hosting and Architecture Vulnerabilities

Inadequate Segregation in Tiered Architectures

15. Vulnerable Server Configuration and Software

Default Credentials & Content

Key Takeaways, Best Practices, and Patterns