27 March 2017

The other day I noticed something cool in Chrome. I can disable JavaScript and cookies + local storage on HTTP!

To set this up, just navigate to settings, + Show advanced settings then content settings, manage exceptions and add 'http://*' as a blocking entry under Cookies and JavaScript.

Why do this?

PoisonTap and attacks like it that can occur on untrusted networks (e.g. hotel, or coffee shop wifi) can be severely handicapped by these settings.

Protecting Cookies

While I can't stop a website sending me cookies while on HTTP, this does prevent me sending them back.

This means that if I log in to https://example.com and receive cookies securely, my browser will then make sure that does not send any cookies it received to http://example.com, even if the cookies were not sent to me with the Secure flag. I.e. this works as if https://example.com had sent me a cookie with the secure flag, even if it did not.

Let's see this in action:

Setting a cookie on HTTPS

Setting a cookie on HTTPS

Cookie is sent back over HTTPS

Cookie is sent back over HTTPS

Cookie is not sent over HTTP

Cookie is not sent over HTTP

In addition to this, if a website sends me cookies over HTTP, Chrome will simply ignore it (prevents poisoning of cookies via dirty HTTP traffic).


JavaScript is great, but it can also be very dangerous if an attacker can inject some. Except, if you visit a site via HTTP, or even request a script over HTTP then an attacker on the network can send whatever they like back and have it execute on the current origin. So using the same method as above, I've banned JavaScript if I can't guarantee the service I'm using sent it to me.

What if you need insecure JavaScript or cookies temporarily?

While enabling these things again as soon as a site tells you it needs them really just thwarts the protection, there will certainly be situations where you have no choice 😢. So the next best bet is adding a temporary exception if we don't feel like we're on a hostile network (at your own risk etc, etc...). Regardless, having a temporary exception is much better than a permanent one.

Let's look at our options:

block or permanent exception

Hmm... not looking so good. I might forget to delete that later. This might be a better solution though...

block or permanent exception in incognito mode

If you add the exception in an incognito window, you get a fresh browsing session (JS and cookies don't have access to already existing ones), your session will be cleared on exit (any poisoned cookies, local storage, or cached scripts will be deleted on exit), and the exception will be cleared on exit too:

dialogue stating that exceptions will be cleared on destruction of incognito session


Since enabling these settings, on most sites I do not see warnings about cookies and javascript being blocked (thankfully many sites are moving to https now). On the sites that I do see the warnings on, well, they can have their toys back when they decide to support HTTPS.

It would be great to see a major browser hint at defaulting to similar settings after a warning period. If websites enjoy using features like scripts, cookies, and local data storage then they should make sure they're using them securely and responsibly.

16 May 2017

Leveraging the new RPi0w to build a WiFi enabled keystroke injection tool (a.k.a. USB Rubber Ducky with WiFi)...[read more]

27 March 2017

The other day I noticed something cool in Chrome. I can disable JavaScript and cookies + local storage on HTTP!...[read more]

1 January 2017

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP.

By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project.

The project, SecureHeaders is available on GitHub.


If you're familiar with PHP, you'll know that...[read more]

26 August 2016

Disclosure and Google's Response

This one feels very strange writing, because the vulnerability detailed below is currently exploitable. Google has been notified of this vulnerability, yet they have chosen to do nothing.
GoogleThanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
In hope that public disclosure will encourage Google to do otherwise, here goes.
...[read more]
1 May 2016
In this post I'll address one specific task: obtaining a manual certificate from Let's Encrypt.

Who is this for?

If you don't have direct command line access, or the necessary permissions to install Let's Encrypt on your webserver; then you won't be able to obtain a certificate using the automated process.
If you can install Let's Encrypt on your webserver, you should. It simplifies the process down to a single command. You'll also enjoy the benefits of being able to setup an auto renew process directly on the machine serving the certificate.
...[read more]