Blogroll

Meta

Tag: cookie

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.

Older versions of Apache Tomcat, as well as the older servlet specifications required that several configuration values need to be set. With servlet 3, you can now modify the name of the session cookie (as well as the ‘rewriting’ attribute name) in the web.xml file

Obviously “Cookies” have a lot of advantages in web applications to maintain “state”, unfortunately using standard server configurations leads to even static content serving them up un-necessarily wasting some (minimal) bandwidth.

Adding the following to the Apache httpd.conf file is a start:#Remove Cookie from all static content (except HTML as javascript could use it)
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset Cookie
</IfModule>
</FilesMatch>

This topic, and Firefox add-on have received a lot of press lately, as such I figured that I’d capture some comments on the topic. HTTP Session hijacking is nothing new, anyone with the ability to monitor your non-secured network traffic can do this with little effort… what’s happened here is that there are now some really simple to use tools to do the job.

In the past, someone would have to passively monitor your network traffic with a tool like WireShark, and all they’d really have to do is wait for you to access a website to watch the ‘HTTP Cookies’ (or even a URL that contains a ‘session id’). With that information, they simply need to use the same value that you do to essentially take over your session and your current state. Banks are particularly at risk for this, but in most cases they use HTTPS/SSL for all secure data including logins. Social websites such as Facebook and even GMail, often default to non-secure logins to maximize their server and network performance.

Best defense here… never use non-secure login forms, especially when using a public wireless (or wired) network.

Interesting enough, there’s now a Firefox add-on that monitors for usage of Firesheep on the network, unfortunately neither of these currently work in Linux… links below!

If you’ve been online at all in the last decade, you’ve heard of the “dangers” of HTTP Cookies. More nefarious and harder to remove are Flash Cookies as they are handled by a plugin/extension/addon to the browser and exist outside of the normal security settings.

I’ve found that a large percentage of Internet users don’t realize just how they are being tracked on a website. Most people are aware of HTTP Cookies, but very few realize that browser plugin technologies like Adobe Flash also maintain data about a user’s activities. Worse yet, while HTTP Cookies are limited to 4k, Flash can store up to 100k per website.

Clearing of standard HTTP cookies is relatively easy to do in mainstream browsers. However, while Flash is almost ubiquitous, it’s settings are not easy to locate… in fact you cannot even find them in your browser or computer settings, you have to visit a website!

Other tabs will allow you to control various settings related to updates and global security settings, as documentation is provided for each tab it should be relatively easy for you to decide which configuration you prefer in each case.

FYI – I can see some real potential for misuse of these settings if they could be altered externally by a motivated hacker.