Showing 44 Result(s)

Writeup: Stealing OAuth access tokens via an open redirect

Lab link. Various methods can be used to prevent manipulation of the redirect_uri parameter, one of them is the whitelist method. However, suppose we manage to communicate with the external domain at another point in the system, for example through a directory traversal vulnerability. In that case, we can manipulate it and steal important tokens. …

Writeup: OAuth account hijacking via redirect_uri

Lab link. We log in and when we log out and log in again, we see that we can log in without entering any login information. We pass the “GET /auth?client_id” request to the repeater and experiment with the redirect_uri parameter. When we change the value of the redirect_uri parameter, we do not get an …

Writeup: Forced OAuth profile linking

Lab link. The state parameter stores a unique unpredictable value that depends on the current session in the client application. The OAuth service should return exactly this value in the response along with the authorization code. The state parameter ensures that the request comes from the person who initiated the OAuth flow. The state parameter …

Writeup: Authentication bypass via OAuth implicit flow

Lab link. Implicit Grant Type is used as OAuth Grant Type in Lab. The difference of the Implicit Grant Type is that the access token is sent immediately after the user approves. It is less reliable because all communication is routed through the browser. After logging in with the wiener:peter gave to us in the …

Writeup: Password brute-force via password change

Lan link. We are evaluating the requests for the password change system. If we enter the existing password incorrectly in the password change process, the system logs us out of our account and says “You have made too many incorrect login attempts. Please try again in 1 minute(s).” error. To bypass this measure against brute-force …

Writeup: Password reset poisoning via middleware

Lan link. The lab description says it is vulnerable to a password reset poisoning vulnerability. At first, we reset the password of the wiener user to understand the system structure. Specifying username in the POST /forgot-password request is enough to request a password, if we can manipulate this request with X-Forwarded-Host, the email for username …

Writeup: Offline password cracking

Lab link. We see that our lab description contains XSS. At first, we look at the cookie value used in the system. We find a forum on the blog page to organize our XSS attack. Here we first try a basic XSS payload to see if it is XSS. <script>alert(1);</script> We have found our XSS …

Writeup: Brute-forcing a stay-logged-in cookie

Lab link. Persistent cookies are used in sections such as “Remember me”. Some websites keep This cookie in predictable values or simple hashed form. In this Lab, operations are also done through cookies, we will examine this first. We need a hash-type detector to solve the structure in Cookie, you can use whatever you want. …

Writeup: 2FA bypass using a brute-force attack

Lab link. There is a weakness in the system related to 2FA authentication. To understand the structure of the vulnerability, we enter the system with the credentials given to us. If the MFA code is sent incorrectly twice, the system redirects us back to the login page. This makes our brute-force attack fail. For this …

Writeup: 2FA broken logic

Lab link. On the 2FA login pages, we send the MFA code, which is our last request. We leave only the verify component in the cookie value and make it carlos instead of wiener. When we send the request, we get the information that the MFA code is incorrect, which indicates that the system is …