imprs

src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md

@@ -83,10 +83,6 @@ if __name__ == "__main__":
 	main()
 ```
 
-## More information
-
-from here: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
-
 ### The Publish/Subscribe Pattern <a href="#b667" id="b667"></a>
 
 The publish/subscribe model is composed of:

src/pentesting-web/cache-deception/README.md

@@ -81,6 +81,14 @@ _Note that this will poison a request to `/en?region=uk` not to `/en`_
 cache-poisoning-to-dos.md
 {{#endref}}
 
+### Cache poisoning through CDNs
+
+In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** it's explained the following simple scenario:
+
+- The CDN will cache anything under `/share/`
+- The CDN will NOT decode nor normalize `%2F..%2F`, therfore, it can be used as **path traversal to access other sensitive locations that will be cached** like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- The web server WILL decode and normalize `%2F..%2F`, and will respond with `/api/auth/session`, which **contains the auth token**.
+
 ### Using web cache poisoning to exploit cookie-handling vulnerabilities
 
 Cookies could also be reflected on the response of a page. If you can abuse it to cause a XSS for example, you could be able to exploit XSS in several clients that load the malicious cache response.

src/pentesting-web/hacking-with-cookies/cookie-tossing.md

@@ -14,6 +14,7 @@ As it was indicated in the Cookies Hacking section, when a **cookie is set to a
 This can be dangerous as the attacker may be able to:
 
 - **Fixate the cookie of the victim to the attacker's account** so if the user doesn't notice, **he will perform the actions in the attacker's account** and the attacker may obtain some interesting information (check the history of the searches of the user in the platform, the victim may set his credit card in the account...)
+  - An example of this [can be found here](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) where the attacker set his cookie in specific sections a victim will use to authorize **access to his git repos but from the attackers account** as he will be setting his cookies in the needed endpoints.
 - If the **cookie doesn't change after login**, the attacker may just **fixate a cookie (session-fixation)**, wait until the victim logs in and then **use that cookie to log in as the victim**.
   - Sometimes, even if the session cookies changes, the attacker use the previous one and he will receive the new one also.
 - If the **cookie is setting some initial value** (like in flask where the **cookie** may **set** the **CSRF token** of the session and this value will be maintained after the victim logs in), the **attacker may set this known value and then abuse it** (in that scenario, the attacker may then make the user perform a CSRF request as he knows the CSRF token).

src/pentesting-web/xss-cross-site-scripting/README.md

@@ -1155,7 +1155,6 @@ trigger()
 
 - **Different obfuscations in one page:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
 - [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
-- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
 - [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
 - [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
 - [http://www.jsfuck.com/](http://www.jsfuck.com)