Publish Latest 2025-09-03

latest/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md

@@ -35,18 +35,10 @@ Problems related to the authentication schema can be found at different stages o
 
 There are several methods of bypassing the authentication schema that is used by a web application:
 
-- Direct page request ([forced browsing](https://owasp.org/www-community/attacks/Forced_browsing))
 - Parameter modification
 - Session ID prediction
 - SQL injection
 
-### Direct Page Request
-
-If a web application implements access control only on the log in page, the authentication schema could be bypassed. For example, if a user directly requests a different page via forced browsing, that page may not check the credentials of the user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.
-
-![Direct Request to Protected Page](images/Basm-directreq.jpg)\
-*Figure 4.4.4-1: Direct Request to Protected Page*
-
 ### Parameter Modification
 
 Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
@@ -71,7 +63,7 @@ Content-Type: text/html; charset=iso-8859-1
 ```
 
 ![Parameter Modified Request](images/Basm-parammod.jpg)\
-*Figure 4.4.4-2: Parameter Modified Request*
+*Figure 4.4.4-1: Parameter Modified Request*
 
 ### Session ID Prediction
 
@@ -80,24 +72,24 @@ Many web applications manage authentication by using session identifiers (sessio
 In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.
 
 ![Cookie Values Over Time](images/Basm-sessid.jpg)\
-*Figure 4.4.4-3: Cookie Values Over Time*
+*Figure 4.4.4-2: Cookie Values Over Time*
 
 In the following figure, values inside cookies change only partially, so it's possible to restrict a brute force attack to the defined fields shown below.
 
 ![Partially Changed Cookie Values](images/Basm-sessid2.jpg)\
-*Figure 4.4.4-4: Partially Changed Cookie Values*
+*Figure 4.4.4-3: Partially Changed Cookie Values*
 
 ### SQL Injection (HTML Form Authentication)
 
 SQL Injection is a widely known attack technique. This section is not going to describe this technique in detail as there are several sections in this guide that explain injection techniques beyond the scope of this section.
 
 ![SQL Injection](images/Basm-sqlinj.jpg)\
-*Figure 4.4.4-5: SQL Injection*
+*Figure 4.4.4-4: SQL Injection*
 
 The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.
 
 ![Simple SQL Injection Attack](images/Basm-sqlinj2.gif)\
-*Figure 4.4.4-6: Simple SQL Injection Attack*
+*Figure 4.4.4-5: Simple SQL Injection Attack*
 
 ### PHP Loose Comparison
 
@@ -130,7 +122,7 @@ a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}  // original value: a:2:{s:11
 Let's disassemble what we did in this string:
 
 1. `autologinid` is now a boolean set to `true`: this can be seen by replacing the MD5 value of the password hash (`s:32:"8b8e9715d12e4ca12c4c3eb4865aaf6a"`) with `b:1`
-2. `userid` is now set to the admin id: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"`
+2. `userid` is now set to the admin ID: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"`
 
 ## Tools
 

latest/4-Web_Application_Security_Testing/05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema.md

@@ -30,13 +30,31 @@ Try to access the application as an administrative user and track all the admini
 
 ## Test Objectives
 
-- Assess if horizontal or vertical access is possible.
+- Assess if unauthenticated, horizontal, or vertical access is possible.
 
 ## How to Test
 
+- Access resources and conduct operations without login. - Direct page request ([forced browsing](https://owasp.org/www-community/attacks/Forced_browsing))
 - Access resources and conduct operations horizontally.
 - Access resources and conduct operations vertically.
 
+### Testing for Basic Unauthenticated Access
+
+#### Using a Browser Manually
+
+When a web application does not properly enforce access control mechanisms, sensitive resources become exposed, allowing unauthenticated users to view them. For example, if a user directly requests a different page via forced browsing, that page may not check the authorization of the anonymous user before granting access. Attempt to directly access a protected page through the address bar in your browser to test using this method.
+
+![Direct Request to Protected Page](images/Basm-directreq.jpg)\
+*Figure 4.5.2-1: Direct Request to Protected Page*
+
+#### Using Automation
+
+This process can be automated if you have a list of all endpoints with tools like ffuf, gobuster, ZAP, and Burp Suite Intruder.
+
+For ZAP, using a adddon for [Access Control Testing](https://www.zaproxy.org/docs/desktop/addons/access-control-testing/) allows testers to determine which parts of the application are available to anonymous users, and identify potential access control issues.
+
+For Burp Suite, built-in tools such as Intruder, and a number of plugins, including Autorize, help the tester automate testing authorization.
+
 ### Testing for Horizontal Bypassing Authorization Schema
 
 For every function, specific role, or request that the application executes, it is necessary to verify: