mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 21:53:54 +00:00
GitBook: [#3305] No subject
This commit is contained in:
parent
a5d822e198
commit
d0fa6ab7e2
1 changed files with 23 additions and 27 deletions
|
@ -1,4 +1,4 @@
|
|||
|
||||
# Cookies Hacking
|
||||
|
||||
<details>
|
||||
|
||||
|
@ -16,20 +16,19 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
|
||||
</details>
|
||||
|
||||
|
||||
# Hacking cookies
|
||||
## Hacking cookies
|
||||
|
||||
If you find some kind of custom cookie containing sensitive data (sessionID, username, emails...) you should definitely try to exploit it
|
||||
|
||||
## Decoding the cookie
|
||||
### Decoding the cookie
|
||||
|
||||
If the **cookie** is using some **Base encoding** (like Base64) or similar you may be able to **decode it**, **change** the **content** and **impersonate** arbitrary users.
|
||||
|
||||
## Session Hijacking
|
||||
### Session Hijacking
|
||||
|
||||
Steal a cookie and use it to impersonate the user inside an application
|
||||
|
||||
## Session fixation
|
||||
### Session fixation
|
||||
|
||||
The attacker get a cookie from a web page and send to the victim a link so the **victim logins using the cookie of the attacker**. If the cookie is not changed when a user logs in, this could be useful because the attacker could be able to impersonate the user using the cookie.
|
||||
|
||||
|
@ -39,7 +38,7 @@ If you found a **XSS in a subdomain** or you **control a subdomain**, read:
|
|||
[cookie-tossing.md](cookie-tossing.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Session donation
|
||||
### Session donation
|
||||
|
||||
The attacker sends his own session to the victim. The victim will see that he is already loged and will suppose that he is inside his own account but **the actions will be performed inside the attackers account**.
|
||||
|
||||
|
@ -49,13 +48,13 @@ If you found a **XSS in a subdomain** or you **control a subdomain**, read:
|
|||
[cookie-tossing.md](cookie-tossing.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## [JWT Cookie](../hacking-jwt-json-web-tokens.md)
|
||||
### [JWT Cookie](../hacking-jwt-json-web-tokens.md)
|
||||
|
||||
Click on the previous link to access a page explaining possible flaws in JWT.
|
||||
|
||||
## Checking Cookies
|
||||
### Checking Cookies
|
||||
|
||||
### **Basic checks**
|
||||
#### **Basic checks**
|
||||
|
||||
* The **cookie** are the **same** every time you **login**
|
||||
* Log out and try to use the same cookie
|
||||
|
@ -65,7 +64,7 @@ Click on the previous link to access a page explaining possible flaws in JWT.
|
|||
* Check "**remember me**" option if it exists and check how does it works. If it exists and could be vulnerable, always use the cookie of **remember me** without any other cookie.
|
||||
* If you change the password and previous cookie still works
|
||||
|
||||
### **Advanced cookies attacks**
|
||||
#### **Advanced cookies attacks**
|
||||
|
||||
If the cookie remains the same (or almost) when you log in, this probably means that the cookie is related to some field of your account (probably the username). Then you can:
|
||||
|
||||
|
@ -89,7 +88,7 @@ Padbuster will make several attempts and will ask you which condition is the err
|
|||
|
||||
Then it will start decrypting the cookie (it may take several minutes)
|
||||
|
||||
If the attack has been successfully performed, then you could try to encrypt a string of your choice. For example, if you would want to **encrypt** **user=administrator**
|
||||
If the attack has been successfully performed, then you could try to encrypt a string of your choice. For example, if you would want to **encrypt** **user=administrator**
|
||||
|
||||
```
|
||||
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
|
||||
|
@ -103,7 +102,7 @@ Maybe a cookie could have some value and could be signed using CBC. Then, the in
|
|||
|
||||
**The attack**
|
||||
|
||||
1. Get the signature of username **administ** = **t**
|
||||
1. Get the signature of username **administ** = **t**
|
||||
2. Get the signature of username **rator\x00\x00\x00 XOR t** = **t'**
|
||||
3. Set in the cookie the value **administrator+t'** (**t'** will be a valid signature of **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**
|
||||
|
||||
|
@ -120,24 +119,24 @@ Create a user called form example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|||
|
||||
There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"\*(size of block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".
|
||||
|
||||
# Cookies Attributes
|
||||
## Cookies Attributes
|
||||
|
||||
## Expires & Max-Age
|
||||
### Expires & Max-Age
|
||||
|
||||
* `Expires` sets an expiry date for when a cookie gets deleted
|
||||
* `Max-age` sets the time in seconds for when a cookie will be deleted **(use this, it’s no longer 2009)**
|
||||
|
||||
## **Domain**
|
||||
### **Domain**
|
||||
|
||||
The `Domain` attribute specifies **which hosts can receive a cookie**. If unspecified, the attribute **defaults** to the **same host** that set the cookie, _**excluding subdomains**_. **If `Domain` **_**is**_** specified, then subdomains are always included**. Therefore, specifying `Domain` is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
|
||||
The `Domain` attribute specifies **which hosts can receive a cookie**. If unspecified, the attribute **defaults** to the **same host** that set the cookie, _**excluding subdomains**_. **If `Domain` is** **specified**, then **subdomains are always included**. Therefore, specifying `Domain` is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
|
||||
|
||||
For example, if you set `Domain=mozilla.org`, cookies are available on subdomains like `developer.mozilla.org`. But if you don't, the cookie won't be sent to subdomains.
|
||||
|
||||
## **Path**
|
||||
### **Path**
|
||||
|
||||
The `Path` attribute indicates a **URL path that must exist in the requested URL in order to send the `Cookie` header**. The `%x2F` ("/") character is considered a directory separator, and subdirectories match as well.
|
||||
|
||||
## SameSite
|
||||
### SameSite
|
||||
|
||||
This will indicate the browser if the **cookie** can be sent **from other domains**. It has 3 possible values:
|
||||
|
||||
|
@ -158,15 +157,15 @@ This will indicate the browser if the **cookie** can be sent **from other domain
|
|||
Table from [here](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/)\
|
||||
A cookie with _**SameSite**_ attribute will **mitigate CSRF attacks** where a logged session is needed.
|
||||
|
||||
**Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie **_**samesite**_** attribute will be lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)). Notice that temporary, after applying this change, the **cookies without a SameSite** **policy** in Chrome will be **treated as None during the first 2 minutes and then as Lax**.
|
||||
**Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite** **attribute will be lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)). Notice that temporary, after applying this change, the **cookies without a SameSite** **policy** in Chrome will be **treated as None during the first 2 minutes and then as Lax**.
|
||||
|
||||
# Cookies Flags
|
||||
## Cookies Flags
|
||||
|
||||
## HttpOnly
|
||||
### HttpOnly
|
||||
|
||||
This avoids the **client** to access the cookie (Via **Javascript** for example: `document.cookie`)
|
||||
|
||||
### **Bypasses**
|
||||
#### **Bypasses**
|
||||
|
||||
* This could be Bypassed with **TRACE** **HTTP** requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called **Cross-Site Tracking**.
|
||||
* This technique is avoided by **modern browsers by not permitting sending a TRACE** request from JS. However, some bypassed to this have been found in specific software like sending `\r\nTRACE` instead of `TRACE` to IE6.0 SP2.
|
||||
|
@ -177,11 +176,10 @@ This avoids the **client** to access the cookie (Via **Javascript** for example:
|
|||
[cookie-jar-overflow.md](cookie-jar-overflow.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Secure
|
||||
### Secure
|
||||
|
||||
The request will **only** send the cookie in an HTTP request only if the request is transmitted over a secure channel (typically **HTTPS**).
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Support HackTricks and get benefits!</strong></summary>
|
||||
|
@ -197,5 +195,3 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue