security

Blogposts on blog.futtta.be about IT- and more specifically web application security (e.g. about some dangers in PHP, xss, …)

Hey! Widgets! Leave our privacy alone!

by

After having NoScript disable the Facebook Like widget a couple of weeks ago, I felt really bad for Mark Zuckerberg who must have been feeling singled out by my actions. If only to make all widgets equal and as I don’t use them anyway, I’ve now told NoScript (only available in Firefox) to also block the Google+ and Twitter widgets with the following ABE User ruleset (under NoScript Advanced options):
# also stop google+ widget
Site plus.google.com
Accept from plus.google.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

# and twitter
Site platform.twitter.com
Accept from twitter.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

Who’s re-baking my cookies?

by

While tinkering with JavaScript at work for a performance-optimization, we encountered an annoying cookie-related problem. We wanted to check if a certain name/value was present in the cookie and not do “complicated and unneeded backend stuff” if it was not. But that didn’t always work, because in some browsers the cookie had the secure flag set and the JS-check was done while in HTTP.

It took some time, digging and soul-searching, but it turned out to work fine for all but me. The reason: NoScript! My favorite Firefox Addon has, so I learned, “Automatic Secure Cookie Management” as a countermeasure against HTTPS cookie hijacking (by setting cookies “secure” if they’re set in HTTPS and if they contain something resembling a session-id?). And that feature indeed can break stuff.

So if you’re using NoScript and you’re running into weird cookie-related problems: try with “Automatic Secure Cookie Management” turned off, or add the site you’re on as an exception and you might be good to go.

Learning from my mistakes about TLS, certificates and browsers

by

Well, I guess that, for those who read my previous post about SSL/TLS error messages on Mac OS X browsers, it’s abundantly clear that I don’t really know SSL/ TLS and the way browsers handle the certificates. But hey, I blog to learn from my mistakes and Philip and Peter helped me understand a bit about TLS with their useful comments.
The summary for TLS-dummies like me:

  • According to the TLS spec the server should not only provide it’s own certificate, but also any intermediate certificate between it’s own & the CA’s root
  • Browsers (or the OS’es key stores that some browsers depend upon) don’t ship with any intermediate certificate, but can and in some cases will store (cache) them when they come across them. In Firefox, cached intermediate certificates are listed as being part of the “software security device”, whereas root certificates are in the “builtin object token”.

All in all, this means that whenever you’re implementing TLS (or SSL, if you’re old-fashioned) you have  to configure your webserver to provide all intermediate certificates in a “chainfile” as (for example) per Apache’s SSLCertificateChainFile directive.

How to fix SSL errors in Mac OS X browsers

by

So you know about SSL (or rather TLS) and you prefer things secure, so you request and pay for an officially signed certificate and configure your Apache to use it. The next days you’re feeling very Kevin Mitnicky, until some nitwit on Twitter trashes you for the ugly error-message he sees when trying to visit your supposedly “secure” site that is. What’s up with that?
Well, chances are that your disgruntled visitor was using a browser you didn’t test on, like Chrome on Mac for example? Because there is a small issue you have to take into account when “doing https”; both Chrome and Safari (but not Firefox) on Mac use OS X’s keychain, which does not have some of the intermediate certificates needed to establish the trust relationship between your signed certificate and the certificate authority’s root certificate.
As you can’t expect Apple to add intermediate certificates to their keychain by default (which Firefox does a pretty good job though) and you can’t ask all your OS X users to add the intermediate certificate by hand either,  you’ll have to solve this yourself. A good thing Apache can help you in that department with it’s SSLCertificateChainFile directive, which

sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of the server certificate and can range up to the root CA certificate.

If there’s only one intermediate certificate missing between your’s and the CA’s, you can export it in good old Firefox (as a pem-file), place it in the same directory as the actual certificate and use SSLCertificateChainFile to tell Apache where to find it and that should solve the nasty errors those Twittering Mac-heads get.

Follow-up Friday: Ubuntu Unity, Android security & WordPress Stats

by

Just a couple of small updates on previous stories to keep you posted really.
We’ll start of with Ubuntu Natty Narwhal; beta 2 has been released earlier today. I’ve downloaded a lot of updated packages over the last few days, so I guess I’m on the second beta as well. The Unity launcher now comes out of hiding perfectly and it scrolls down automatically to show items at the bottom as well. There also was a bug with the menu-items of some applications (e.g. Firefox 4) disappearing which seems fixed. Hope they can get the launcher to behave with Java apps (e.g. my favorite mindmapping application) soon.
On another note: Lookout, the Android app that allows you to locate your handset and -if you have the paying version- remotely wipe it, seems to be getting some serious competition from …. Google. Enterprises who have Google Apps for Business can now locate, encrypt and wipe their Android devices. Especially the encryption is important news, but it really should be available and configurable in the Android OS itself
To finish off with some news about WordPress Stats secretive inclusion of Quantcast behavioral tracking: it seems like WordPress Stats plugin will be replaced by Automattics Jetpack, which according to the site:

supercharges your self‑hosted WordPress site with the awesome cloud power of WordPress.com

Jetpack actually is a “super-plugin” that offers functionality from Stats, Sharedaddy, After the deadline and other previously separately available Automattic plugins. The Jetpack WordPress.com stats module does still include the Quantcast “spyware”, doesn’t disclose this feature and doesn’t provide functionality that warrants Quantcast inclusion (in spite of Matt Mullenweg claiming “We’ve been using Quantcast to get some additional information on uniques that it’s hard for us to calculate”). But there is (some) good news in the Jetpack Stats source code though, because on line 145 it reads:

‘do_not_track’ => true, // @todo

This could mean that blog-owners will one day be able to opt out of 3rd party tracking or it might be that Stats will take e.g. Firefox DNT-header into account for your blog’s visitors. Having both would off course be what I will be rooting for!

Secure your smartphone

by

Your smartphone probably contains a wealth of information of personal and professional nature, which you would not want others to have access to. This is why (after losing my HTC Hero a couple of months ago) I now try to follow 2 out of these 3 simple rules:

  1. don’t lose your smartphone.
  2. if you lose your smartphone, make sure you have something in place to locate it
  3. if you lose your smartphone and you can’t locate it, make sure you can wipe it remotely

There are multiple solutions to locate & wipe smartphones (including HTC’s Sense online offering), but for my Sense-less HTC Magic I installed “Lookout“. Lookout is a free application that provides device location, contacts backup & restore and apparently also malware protection. If you’re willing to pay $3/month, you also get remote wipe, remote lock and backup/ restore of pictures and call log. If you lose your Android-phone, you just log in to the Lookout-website to locate and optionally lock or wipe your handset.
I’m happy using the free version for now; I activated Android’s pattern lock-screen to avoid anyone from accessing my handset and deactivating Lookout. Remote wipe is great, but I guess I can activate my Lookout Premium account if ever I need that feature?

3 Apache mod_cache gotchas

by

If you want to avoid the learning curve of Squid and Varnish or the cost of a dedicated caching & proxying appliance, using Apache with mod_cache may seem like a good, simple and cheap solution. Rest assured, it can be -to some extent- but here are 3 gotchas I learned the hard way:

  1. mod_cache ignores Cache-control if Expires is in the past (which it shouldn’t according to RFC2616), so you might have to unset the Expires-header.
  2. mod_cache by default caches cookies! Let me repeat; cookies are cached! That might be a huge security-disaster waiting to happen; sessionid’s (that provide access for logged-on users) are generally stored in cookies. If a logged on user that request an uncached page, then that user’s cookie will get cached and sent to other users that request the same page. Do disable this by adding “CacheIgnoreHeaders Set-Cookie” to your config
  3. mod_cache by default treats all browsers like the one that triggered the caching of the object. In the field that approach can cause problems with e.g. CSS-files that are stored gzipped (because the first browser requested with header “Accept-Encoding: gzip, deflate”). If a browser that does not support gzipped content requests the same file, the CSS will be unreadable and thus not applied. The solution; make sure the “backend webserver” sends the “Vary: Accept-Encoding” header in the response (esp. for CSS-files). This will tell mod_cache to take different Accept-Encodings into account, storing and sending different versions of the same CSS-file.

Why your WordPress blog needs DoNotTrack

by

So what’s with all that nagging about tracking and that DoNotTrack plugin, you might wonder? Well, it’s pretty simple actually.

  1. Some very popular WordPress plugins include 3rd party tracking, sometimes even without properly disclosing, often without means to disable this behavior
  2. 3rd party tracking has privacy implications: all your visitors are tracked by the 3rd party, in general for behavioral marketing purposes (depending on what data is captured, tracking might even be illegal in some countries)
  3. 3rd party tracking has a performance impact: every visit to your blog will include between 2 and 5 extra requests for the 3rd party tracking to succeed, effectively delaying full page rendering

It is my conviction that blog owners should be able to install and use WordPress plugins without having to worry about undisclosed tracking and that plugins should provide a way to disable such 3rd party tracking if included.
As this is not the case yet, we have to resort to (messy) solutions to stop unwanted tracking from happening. And that’s exactly what DoNotTrack does. It’s a small javascript-hack in a WordPress-plugin to stop 3rd party tracking introduced by some of the most popular plugins.
Some details from the readme.txt:

  • What works:
  • What does not work (yet): Tracking code added using innerHTML or appendChild/insertBefore is not yet intercepted (but I’m working a solution for that)
  • What else might be added:
  • How you can help:
    • Provide me with links to plugins that include browser-based tracking + domain where the tracking is done.
    • Provide me with known opt-out code (javascript) to disable tracking services on a site.
    • Tell plugin writers you’re not happy with 3rd party tracking!
    • Tell your visitors about tracking & privacy, link to e.g. http://www.privacychoice.org/

And remember: if you host your WordPress blog yourself, you and nobody else should be able to decide who tracks your users!

Google Analytics for the privacy aware

by

While the entire German blogosphere seems to have discovered the pretty unpleasant, secretive inclusion of Quantcast tracking in the “WordPress.com Stats” plugin, I found an article on the blog that broke the story in Germany, that explains how you can somewhat limit (valid) privacy-concerns with Google Analytics.
You just have to push “_gat._anonymizeIp” as an option in the _gaq object, as shown on line 5 in this code snippet:

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-xxxxxxx-x']);
  _gaq.push(['_trackPageview']);
  _gaq.push(['_gat._anonymizeIp']);
  (function() {
    var ga = document.createElement('script');
    ga.type = 'text/javascript';
    ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(ga, s);
  })();
</script>

According to the relevant Google Analytics docs page, this:

“Tells Google Analytics to anonymize the information sent by the tracker objects by removing the last octet of the IP address prior to its storage. Note that this will slightly reduce the accuracy of geographic reporting.”

Call me naive (or overly idealistic), but shouldn’t your Google Analytics implementation have this option on as well?