Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Cookies are a core part of browser mechanics. Understanding how they work is important when escalating existing issues. In this article, the author dives into quirks of various frameworks and browsers on cookies.

First, when are cookies sent? This depends on the domain attribute of a cookie. If the domain is set for example.com, then all subdomains will send this as well. If the cookie is set from a subdomain onto the parent, it will be sent with the parent as well. It's interesting that this is allowed to be set.

Cookies are ordered on Chrome and Firefox by first the path length then the last updated time. So, if you have a vulnerability that allows you to set a cookie, you can get yours parsed first by setting it with a longer path.

Browsers allow for cookies with an empty name. For instance, =test value; is a valid cookie that can be set. When rendered, this will break the parsing of the cookies by most web servers. So, we can set arbitrary cookies that are not secure or host cookies.

A new attack vector presented in this post is cookie smuggling. The idea is to break the parsing of cookies when you have control over some of them. If you can add a double quote (") to a cookie, then some items will follow the RFC2616 standard while others will follow RFC2965. Why does this matter? The double quote changes the meaning of the cookies being parsed. Using this HTTPOnly cookies could be smuggled or some cookies could be outright set.

Going deeper into the parsing issues, we need to ensure that everything parses cookies the same. In Java Undertow, they found that that parsing for a cookie begins right after a double quote. So, if we have a cookie with double quotes, it will then parse the rest of the data as our cookie, smuggling in our cookie!

Python stdlib http.cookie.SimpleCookie and http.cookie.BaseCookie suffer from a same issue. If a space is found in the cookie, then it will start parsing this as a new cookie, using it as a delimiter. Since the Python library has this issue, all frameworks using it are vulnerable as well. Cookie injection is bad where cookie based CSRF protections are used, spoofing secure or host cookies and authorization bypasses where things check for specific cookies.

Although they contacted many of the projects, only Jetty actually responded. So, many of these issues will exist going forwards! Overall, good article on cookie quirks that I had no idea about!