GitBook: [#2793] lol

SUMMARY.md

@@ -370,6 +370,7 @@
 * [Cookies Hacking](pentesting-web/hacking-with-cookies/README.md)
   * [Cookie Tossing](pentesting-web/hacking-with-cookies/cookie-tossing.md)
   * [Cookie Jar Overflow](pentesting-web/hacking-with-cookies/cookie-jar-overflow.md)
+  * [Cookie Bomb](pentesting-web/hacking-with-cookies/cookie-bomb.md)
 * [CORS - Misconfigurations & Bypass](pentesting-web/cors-bypass.md)
 * [CRLF (%0D%0A) Injection](pentesting-web/crlf-0d-0a.md)
 * [Cross-site WebSocket hijacking (CSWSH)](pentesting-web/cross-site-websocket-hijacking-cswsh.md)

pentesting-web/deserialization/README.md

@@ -77,6 +77,23 @@ If you look to the results you can see that the functions `__wakeup` and `__dest
 
 You can read an explained **PHP example here**: [https://www.notsosecure.com/remote-code-execution-via-php-unserialize/](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/), here [https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf) or here [https://securitycafe.ro/2015/01/05/understanding-php-object-injection/](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)
 
+### Serializing Referenced Values
+
+If for some reason you want to serialize a value as a **reference to another value serialized** you can:
+
+```php
+<?php
+class AClass {
+    public $param1;
+    public $param2;
+}
+
+$o = new WeirdGreeting;
+$o->param1 =& $o->param22;
+$o->param = "PARAM";
+$ser=serialize($o);
+```
+
 ### PHPGGC (ysoserial for PHP)
 
 ****[**PHPGCC**](https://github.com/ambionics/phpggc) can help you generating payloads to abuse PHP deserializations.\

pentesting-web/hacking-with-cookies/cookie-bomb.md

@@ -0,0 +1,7 @@
+# Cookie Bomb
+
+A cookie bomb is basically the capability of **adding a large number of big cookies to a user** for a domain an its subdomains with the goal that the victim will always **send very big HTTP requests **to the server (due to the cookies) that the **server won't accept the request**. Therefore, this will cause a DoS over a user in that domains and subdomains.
+
+A nice **example** can be seen in this write-up: [https://hackerone.com/reports/57356](https://hackerone.com/reports/57356)
+
+And for more information you can check this presentation: [https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=26)

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

@@ -1,5 +1,7 @@
 # Cookie Tossing
 
+### Description
+
 If an attacker is able to **control a subdomain of the domain of a company or finds a XSS in a subdomain** he will be able to perform this attack.
 
 As it was indicated in the Cookies Hacking section, when a **cookie is set to a domain (specifying it) it will be used in the domain and in subdomains.**
@@ -18,7 +20,7 @@ This can be really dangerous as the attacker may be able to:
 
 When a browser receives two cookies with the same name **partially affecting the same scope** (domain, subdomains and path), the **browser will send both values of the cookie** when both are valid for the request.
 
-Depending on who was the **oldest one**, and which has **the most specific path **indicated (when you set a cookie you indicates a path) the browser will **set the value of the cookie first** and then the value of the other one like in: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
+Depending on who has **the most specific path **or which one is the **oldest one**, the browser will **set the value of the cookie first** and then the value of the other one like in: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
 
 Most **web sites will only use the first value**. Then, if an attacker wants to set a cookie it's better to set it before another one if set or set it with a more specific path.
 
@@ -38,6 +40,14 @@ To bypass the scenario where the attacker is setting a cookie after the victim w
 
 Another useful **bypass **could be to **URL encode the name of the cookie** as some protections check for 2 cookies with the same name in a request and then the server will decode the names of the cookies.
 
+### Cookie Bomb
+
+A Cookie Tossin attack may be used also to perform **Cookie Bomb** attack:
+
+{% content-ref url="cookie-bomb.md" %}
+[cookie-bomb.md](cookie-bomb.md)
+{% endcontent-ref %}
+
 ### Defense**s**
 
 #### **Use the prefix `__Host` in the cookie name**
@@ -48,4 +58,5 @@ Another useful **bypass **could be to **URL encode the name of the cookie** as s
 ### References
 
 * ****[**@blueminimal**](https://twitter.com/blueminimal)****
+* ****[**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)****
 * ****[**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)****