Hackers Think Cookies Are Tasty, Too

It may not surprise you that one of the most common threats we see here at Tinfoil is Cross-Site Scripting (XSS), but what may surprise you is the location in which we find many of them: cookies.

Most web developers don’t usually think of cookies as potentially dangerous data, but they certainly can be. Consider the following scenario: you have a cookie that stores a nickname, and you read that same cookie using JavaScript to use your customers’ nickname and dynamically update the page with it so it feels more personalized.

The problem is that there is no way to “lock down” a cookie from being edited; a user can happily change the contents of the cookie to read something like the following:

When the value of the cookie is read by the page and used in the JavaScript, the cookie value is trusted (after all, it was set by the server, right?) and thus escapes out of the existing JS and runs its own arbitrary, potentially much more malicious JavaScript instead.

And it’s not just XSS. Often, cookie values are used in database lookups, like SQL queries on the server side for a user id or session parameter. These cases are often far worse because they result in unfettered access to the database running behind the website, allowing hackers to wreak far greater havoc.

So what’s the takeaway, here? In short, treat all cookies as user-generated content, even if you originally set them. Despite your best efforts, their contents may still be malicious in nature and as such they should always be properly escaped and handled before you use them in any way.

As always, we’re more than happy to provide feedback or tips on best practices for these sort of issues, so feel free to get in touch either via email or in our support chat.