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
{{ message }}
Repository navigation
Commit 5ef1123
Browse filesBrowse the repository at this point in the historyBrowse files
*[Fuzzhttpbypass](https://github.com/carlospolop/fuzzhttpbypass) - This tool use fuzzing to try to bypass unknown authentication methods, who knows...
9
9
10
-
## **Session token Attacks**
10
+
## **Session Token Attacks**
11
+
12
+
<details>
13
+
14
+
<summary>Session Token Attacks</summary>
11
15
12
16
* Session tokens should be randomized and not easily guessed. 
13
17
* Session tokens should properly track a user. 
@@ -17,17 +21,25 @@
17
21
* Start live capture to start generating session tokens 
18
22
* After a certain number of tokens it will give a summary of entropy, char level analysis and bit level analysis.
19
23
24
+
</details>
25
+
20
26
## **Password-Based Logins**
21
27
22
-
### Brute Force attacks
28
+
<details>
29
+
30
+
<summary>Brute Force Attacks</summary>
23
31
24
32
* Brute-forcing usernames - Check for any accidental public disclosure, email addresses
25
33
* Brute forcing passwords
26
34
* Username Enumeration
27
35
* Observe changes in the websites behavior depending on input
28
36
* Notice changes in Status Codes, Error Messages, and [Response times](https://app.gitbook.com/s/-MQCNQTNhvnXD58Vo8Mf/web-app-hacking/Web\_Applications--Attack\_types--OWASP\_2\_-\_Broken\_Auth\_Attacks--Vuls\_in\_password-based\_login--Username\_enumeration\_via\_different\_responses.html)
29
37
30
-
### Flawed Brute force protection
38
+
</details>
39
+
40
+
<details>
41
+
42
+
<summary>Flawed Brute Force Protection</summary>
31
43
32
44
* Two most common ways to protect: Locking the account and blocking the remote users IP
33
45
* Ip blocking
@@ -49,20 +61,28 @@
49
61
* Easy to decrypt
50
62
* HTTP basic authentication is also particularly vulnerable to session-related exploits, notably [CSRF](https://portswigger.net/web-security/csrf), against which it offers no protection on its own. 
51
63
64
+
</details>
65
+
52
66
## **MultiFactor Authentication**
53
67
54
68
MFA -mandatory and optional two-factor authentication (2FA) based on something you know and something you have.
55
69
56
70
Two-Factor Tokens - Many high-security websites now provide users with a dedicated device for this purpose, such as the RSA token or keypad device that you might use to access your online banking or work laptop
57
71
58
-
### Bypassing 2FA
72
+
### Bypassing 2fa
59
73
60
74
If the user is first prompted to enter a password, and then prompted to enter a verification code on a separate page, the user is effectively in a "logged in" state before they have entered the verification code. In this case, it is worth testing to see if you can directly skip to "logged-in only" pages after completing the first authentication step.
61
75
62
76
Mind Map: [https://www.mindmeister.com/1736437018?t=SEeZOmvt01](https://www.mindmeister.com/1736437018?t=SEeZOmvt01)
63
77
64
-
#### Response manipulation
78
+
#### Resources
79
+
80
+
*[https://mrd0x.com/bypass-2fa-using-novnc/](https://mrd0x.com/bypass-2fa-using-novnc/) - Steal credentials and bypass 2FA by giving users remote access to your server via an HTML5 VNC client that has a browser running in kiosk mode.
#### Missing 2FA Code integrity validation, code for any user account can be used
120
142
121
143
```
@@ -156,13 +178,15 @@ code=null
156
178
```
157
179
158
180
Source: [Harsh Bothra](https://twitter.com/harshbothra\_) and [https://github.com/daffainfo/AllAboutBugBounty/blob/master/Bypass/Bypass%202FA.md](https://github.com/daffainfo/AllAboutBugBounty/blob/master/Bypass/Bypass%202FA.md)
159
-
160
-
*[https://mrd0x.com/bypass-2fa-using-novnc/](https://mrd0x.com/bypass-2fa-using-novnc/) - Steal credentials and bypass 2FA by giving users remote access to your server via an HTML5 VNC client that has a browser running in kiosk mode.
* Sometimes flawed logic in two-factor authentication means that after a user has completed the initial login step, the website doesn't adequately verify that the same user is completing the second step.
167
191
* This is extremely dangerous if the attacker is then able to [brute-force](https://portswigger.net/web-security/authentication/password-based) the verification code as it would allow them to log in to arbitrary users' accounts based entirely on their username.
168
192
* Brute forceing 2FA
@@ -173,30 +197,44 @@ Source: [Harsh Bothra](https://twitter.com/harshbothra\_) and [https://github.co
### The "Remember me" or "Keep me logged in" feature
204
+
<details>
205
+
206
+
<summary>The "Remember me" or "Keep me logged in" feature</summary>
179
207
180
208
* This is usually set by a persistent cookie
181
209
* If you can obtain or guess the cookie, the login process can be bypassed entirely
182
210
* If the creation of this cookie is based off of simple rules, it cna be guessed or brute forced.
183
211
* Even if the attacker is not able to create their own account, they may still be able to exploit this vulnerability. Using the usual techniques, such as [XSS](https://portswigger.net/web-security/cross-site-scripting), an attacker could steal another user's "remember me" cookie and deduce how the cookie is constructed from that. If the website was built using an open-source framework, the key details of the cookie construction may even be publicly documented.
* It should go without saying that sending users their current password should never be possible if a website handles passwords securely in the first place. Instead, some websites generate a new password and send this to the user via email.\
189
222
 Generally speaking, sending persistent passwords over insecure channels is to be avoided. In this case, the security relies on either the generated password expiring after a very short period, or the user changing their password again immediately. Otherwise, this approach is highly susceptible to man-in-the-middle attacks.\
190
223
 Email is also generally not considered secure given that inboxes are both persistent and not really designed for secure storage of confidential information. Many users also automatically sync their inbox between multiple devices across insecure channels.
224
+
225
+
<!---->
226
+
191
227
* Resetting passwords using a URL
192
228
* A more robust method of resetting passwords is to send a unique URL to users that takes them to a password reset page. Less secure implementations of this method use a URL with an easily guessable parameter to identify which account is being reset
193
229
* An attacker could change the `user` parameter to refer to any username they have identified. They would then be taken straight to a page where they can potentially set a new password for this arbitrary user.
194
230
* A better implementation of this process is to generate a high-entropy, hard-to-guess token and create the reset URL based on that. In the best case scenario, this URL should provide no hints about which user's password is being reset.
195
231
* However, some websites fail to also validate the token again when the reset form is submitted. In this case, an attacker could simply visit the reset form from their own account, delete the token, and leverage this page to reset an arbitrary user's password.
* The attacker first enters the victim's username and requests a password reset. They then intercept this request using Burp. If certain headers are supported, the attacker may be able to utilize them to override the hostname for the generated URL. They may even be able to simply change the value of the `Host` header directly.
202
240
* If the attacker changes the `Host` to a domain that they control, such as `evil-user.net`, the victim would then receive an email similar to the following:\
@@ -205,11 +243,21 @@ Source: [Harsh Bothra](https://twitter.com/harshbothra\_) and [https://github.co
 This would be a genuine email from the website and, importantly, would contain the valid token required to reset this user's password. However, as the URL points to the attacker's website, clicking this link would cause the user to expose their reset token to the attacker. By visiting the real URL with the user's leaked token, the attacker could subsequently reset the victim's password unimpeded.
207
245
208
-
### Changing user passwords
246
+
</details>
247
+
248
+
<details>
249
+
250
+
<summary>Changing user passwords</summary>
209
251
210
252
* Typically, changing your password involves entering your current password and then the new password twice. These pages fundamentally rely on the same process for checking that usernames and current passwords match as a normal login page does. Therefore, these pages can be vulnerable to the same techniques.
211
253
* Password change functionality can be particularly dangerous if it allows an attacker to access it directly without being logged in as the victim user. For example, if the username is provided in a hidden field, an attacker might be able to edit this value in the request to target arbitrary users. This can potentially be exploited to enumerate usernames and brute-force passwords.
212
254
213
-
### User registration sanitization
255
+
</details>
256
+
257
+
<details>
258
+
259
+
<summary>User registration sanitization</summary>
214
260
215
261
* If you can discover a valid username, attempt to create a new user with the same name preceeded by a space
0 commit comments