You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue 1226: moving this section from WSTG-ATHN-04 to WSTG-ATHZ-02 (#1232)
* Issue 1226: moving this section from WSTG-ATHN-04 to WSTG-ATHZ-02
* Issue 1226: remove spurious line
* Update document/4-Web_Application_Security_Testing/05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema.md
Co-authored-by: Rick M <kingthorin@users.noreply.github.com>
* Renumber images after removal of image
* Tweak "admin ID"
---------
Co-authored-by: Rick M <kingthorin@users.noreply.github.com>
Copy file name to clipboardExpand all lines: document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md
+6-14Lines changed: 6 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,18 +26,10 @@ Problems related to the authentication schema can be found at different stages o
26
26
27
27
There are several methods of bypassing the authentication schema that is used by a web application:
28
28
29
-
- Direct page request ([forced browsing](https://owasp.org/www-community/attacks/Forced_browsing))
30
29
- Parameter modification
31
30
- Session ID prediction
32
31
- SQL injection
33
32
34
-
### Direct Page Request
35
-
36
-
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.
37
-
38
-
\
39
-
*Figure 4.4.4-1: Direct Request to Protected Page*
40
-
41
33
### Parameter Modification
42
34
43
35
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,24 +63,24 @@ Many web applications manage authentication by using session identifiers (sessio
71
63
In the following figure, values inside cookies increase linearly, so it could be easy for an attacker to guess a valid session ID.
72
64
73
65
\
74
-
*Figure 4.4.4-3: Cookie Values Over Time*
66
+
*Figure 4.4.4-2: Cookie Values Over Time*
75
67
76
68
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.
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.
84
76
85
77
\
86
-
*Figure 4.4.4-5: SQL Injection*
78
+
*Figure 4.4.4-4: SQL Injection*
87
79
88
80
The following figure shows that with a simple SQL injection attack, it is sometimes possible to bypass the authentication form.
@@ -121,7 +113,7 @@ a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";} // original value: a:2:{s:11
121
113
Let's disassemble what we did in this string:
122
114
123
115
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`
124
-
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"`
116
+
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"`
Copy file name to clipboardExpand all lines: document/4-Web_Application_Security_Testing/05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema.md
+19-1Lines changed: 19 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,13 +21,31 @@ Try to access the application as an administrative user and track all the admini
21
21
22
22
## Test Objectives
23
23
24
-
- Assess if horizontal or vertical access is possible.
24
+
- Assess if unauthenticated, horizontal, or vertical access is possible.
25
25
26
26
## How to Test
27
27
28
+
- Access resources and conduct operations without login. - Direct page request ([forced browsing](https://owasp.org/www-community/attacks/Forced_browsing))
28
29
- Access resources and conduct operations horizontally.
29
30
- Access resources and conduct operations vertically.
30
31
32
+
### Testing for Basic Unauthenticated Access
33
+
34
+
#### Using a Browser Manually
35
+
36
+
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.
37
+
38
+
\
39
+
*Figure 4.5.2-1: Direct Request to Protected Page*
40
+
41
+
#### Using Automation
42
+
43
+
This process can be automated if you have a list of all endpoints with tools like ffuf, gobuster, ZAP, and Burp Suite Intruder.
44
+
45
+
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.
46
+
47
+
For Burp Suite, built-in tools such as Intruder, and a number of plugins, including Autorize, help the tester automate testing authorization.
48
+
31
49
### Testing for Horizontal Bypassing Authorization Schema
32
50
33
51
For every function, specific role, or request that the application executes, it is necessary to verify:
0 commit comments