GitBook: [#2793] lol
This commit is contained in:
parent
55da5e0b9b
commit
febd64a6ca
@ -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)
|
||||
|
@ -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.\
|
||||
|
7
pentesting-web/hacking-with-cookies/cookie-bomb.md
Normal file
7
pentesting-web/hacking-with-cookies/cookie-bomb.md
Normal file
@ -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)
|
@ -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/)****
|
||||
|
Loading…
Reference in New Issue
Block a user