If you find some kind of custom cookie containing sensitive data (sessionID, username, emails…) you should definitely try to exploit it
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.
Steal a cookie and use it to impersonate the user inside an application
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.
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.
Click on the previous link to access a page explaining possible flaws in JWT.
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:
Padding Oracle - Padbuster examples
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf
# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
Padbuster will make several attempts and will ask you which condition is the error condition (the one that is not valid).
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
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
This execution will give you the cookie correctly encrypted and encoded with the string user=administrator inside.
CBC-MAC
Maybe a cookie could have some value and could be signed using CBC. Then, the integrity of the value is the signature created by using CBC with the same value. As it is recommended to use as IV a null vector, this type of integrity checking could be vulnerable.
The attack
ECB
If the cookie is encrypted using ECB it could be vulnerable.
When you login the cookie that you receive has to be always the same.
How to detect and attack:
Create 2 users with almost the same data (username, password, email…) and try to discover some pattern inside the given cookie
Create a user called form example “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).
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”.
This will indicate the browser if the cookie can be sent from other domains. It has 2 possible values:
Request Type | Example Code | Cookies sent |
---|---|---|
Link | <a href="…"></a> | Normal, Lax |
Perender | <link rel=“prerender” href=".."/> | Normal, Lax |
Form GET | <form method=“GET” action="…"> | Normal, Lax |
Form POST | <form method=“POST” action="…"> | Normal |
iframe | <iframe src="…"></iframe> | Normal |
AJAX | $.get("…") | Normal |
Image | <img src="…"> | Normal |
Table from here
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/). 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.
This avoids the client to access the cookie (Via Javascript for example: document.cookie
)
The request will only send the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTPS).