Web applications are often notoriously insecure. With more of us migrating to web-based technologies, ridding the web of these insecurities becomes a top priority. Here are ten tips that should help you secure your web applications.

1. Send all confidential data over a secure connection.

At the very least, send user credentials (i.e. username and password) over HTTPS. At the very most, send all data over HTTPS, especially when your apps are dealing with large amounts of personal information. There are almost no excuses for not using HTTPS these days, especially when buying an SSL certificate is so cheap. Be aware that if you choose to only send credentials over HTTPS, your web application will be susceptible to session hijacking attacks.

Never send any confidential data in an email, especially password confirmation emails. Email is not a secure method of communication, and it probably never will be (PGP is not widely used at all). When dealing with passwords, always let the user set their own, as opposed to generating it for them. That way, you do not need to send their password in an email since they already know what it is.

2. Encrypt confidential data before storing it.

If your web application stores credit card numbers of users or other confidential data, make sure that this data is encrypted in whatever storage medium you are using. If your web application needs to access this data, it should be copied and decrypted in memory, before discarding the copy. At no point should the unencrypted data be stored in some permanent location.

Additionally, the key(s) used for encryption / decryption should not be stored in the same location as the encrypted data. This is to minimize damage if the storage medium is compromised (for instance, if hackers gain access to a database containing encrypted data, the decryption key should not also be compromised).

3. Salt and hash all passwords in the database.

This is possibly one of the most important things a web application designer should implement in terms of user security, but again and again we see large organizations and companies either ignoring or misunderstanding the importance of salting and hashing passwords.

There are absolutely no excuses for not salting and hashing passwords. Your web application should never be able to retrieve a user’s password, either for a comparison or for sending to the user in case they forget it. When the user first registers, their password should be concatenated with a salt (some unique random string of characters) and then hashed with a strong hashing algorithm (SHA-256 for example). PHP has a built-in function called crypt() that supports numerous hashing methods.

In the past few years I’ve switched web browser quite a few times, usually using either Firefox, Safari, or Google Chrome. One of the reasons I’ve recently switched back to Firefox 4 is the quality of add-ons aimed at keeping the user secure and protecting their privacy on the web. I’ve browsed multiple lists purporting to contain the best add-ons for security & privacy, but almost all of them are either out of date, or contain add-ons that simply do not work with the latest builds of Firefox. To that end, I have compiled a list of add-ons that I personally believe are the best around, and which all work with the latest Firefox build (at this moment in time, that would be the official release of Firefox 4).

Firstly though, readers should be aware that although I’ve made sure all these add-ons work with the latest release of Firefox, they may not be “compatible” according to the add-on author. This means you may have to disable the compatibility check that Firefox does when installing the add-on. Be warned that this can cause Firefox to become unstable, and although my installation of Firefox seems to work fine with the incompatible add-ons, it may not be the same for you. If you want to take the risk, follow this tutorial (it can easily be reversed if things go wrong). If not, be patient and wait for the add-on authors to update their add-ons to be compatible with your version of Firefox.

Without further ado, here is my list (in alphabetical order):

Anonymizer Nevercookie

Websites have always been able to track users; some do it for legitimate reasons (i.e. using login cookies, form referrals, etc), but other sites do it to try and learn more about a user’s web browsing habits, in the hopes of presenting them with targeted ads. With the invention of the evercookie, that tracking has become much easier, even when using Private Browsing.

Anonymizer Nevercookie is an add-on that extends the Private Browsing mode of Firefox, keeping an eye out for evercookies. When an evercookie is detected, it is quarantined, and then deleted when you close Firefox. In addition, the add-on makes sure to differentiate between malicious evercookies and necessary cookies that keep users logged into websites. Anonymizer Nevercookie is a must have for anyone concerned about their privacy, and requires absolutely zero configuration; just install and start using Private Browsing.

BetterPrivacy (alternative download link)

BetterPrivacy is a bit like Anonymizer Nevercookie, in that it monitors for evidence of evercookies and then quarantines and removes them at the end of a browsing session. However, the two add-ons both do different things to protect your privacy. Whilst Anonymizer Nevercookie only works in Private Browsing mode, BetterPrivacy works in both, giving you protection from evercookies even if you are browsing normally. BetterPrivacy also allows you to view the current suspected cookies, and to either remove or protect them manually; it also comes with a lot of configuration options that allow you to adapt the add-on to your needs.

So why not just install BetterPrivacy and forget about Anonymizer Nevercookie? Well, BetterPrivacy currently only protects against some of the storage options that evercookies have, focusing mainly on Local Shared Objects (LSOs) and DOM Storage. Anonymizer Nevercookie covers both of these, as well as Microsoft Isolated Storage (MIS), a feature of Silverlight. Now, BetterPrivacy may protect against this in the future, but for now, if you are concerned about the evercookie threat, I’d advise installing both.

BrowserProtect

Not all threats to security and privacy come from the web. There are newer and more dangerous threats to your web browsing in the form of software that alter your browser configurations. These changes (“hijacks“) are present in numerous pieces of software, and all re-configure your browser for their own benefit, whether by changing your homepage, or adding a new default search provider.

BrowserProtect monitors your Firefox configuration, alerting you if a rogue piece of software tries to hijack your browser.

Certificate Patrol

Every website that has HTTPS enabled requires a Certificate Authority (CA) to sign a certificate that verifies the public key used is valid. Every CA has the power to create an intermediate CA, who in turn can create other intermediate CAs (ad nauseam), all of whom can issue and sign certificates. Whilst Firefox has a built-in list of trusted Certificate Authorities (CAs) who can issue valid certificates for HTTPS enabled websites, it also trusts any certificate that is signed by an intermediate CA, as long as the certificate chain links back to one of the trusted CAs in the built-in list.

The unfortunate side-effect of this is that some intermediate CAs might be trusted by Firefox, but may well be rogue and attempt to impersonate legitimate websites using a Man-in-the-Middle attack. Certificate Patrol is an add-on that tries to help the user out by giving them information about specific changes happening to certificates. Every time you visit a HTTPS enabled website, it will store information about the certificate, and whenever this information changes, it will alert you. This isn’t an add-on for regular web users; you should really only use it if you understand how digital certificates work, but it may be helpful if you want to see how often websites change their certificate details.

Cookie Monster

No, this is not the lovable character from Sesame Street, but rather a very powerful add-on that lets you control your cookies in much the same way that NoScript lets you control your JavaScript. Clicking on the icon in the Firefox Add-on Bar will bring up an intuitive menu that shows you all the domains that have cookies active on the current webpage, allowing you to block, reject, or temporarily allow each of them. Additionally, session cookies are separated from regular cookies, meaning you can allow session cookies (so you can use login functionality) whilst blocking all others.

This add-on also has quick links to the cookie viewer that is built into Firefox, meaning the viewing and deleting of individual cookies is easier than ever.

Form History Control

A lot of your private information is typed into forms via our web browsers, and although standards exist to stop potential private data from being recorded (such as the HTML input “autocomplete” attribute), there is no guarantee that the website you are on actually uses it. Disabling autocomplete globally can be a real pain, as it is useful to have some of our regular inputs stored for later use, which is where Form History Control comes in.

This add-on will display every input that your browser has recorded for you, whether it was your username in a website, or your age in some online form. Not only that, but it will tell you the name of the field you entered it, the first and last times you used it, and how many times you’ve used it in total. If that wasn’t good enough, it also provides a much better method for deleting these entries, as you can delete based on total usage rather than the last time they were used.

FoxyProxy Standard

Using a proxy is good practice if you want to protect your privacy and do some anonymous browsing, and whilst Firefox has built-in proxy settings, you have to change them manually every time you want to use a new proxy server. This can be a real pain if you have a long list of them, or if you use programs like Paros or WebScarab to look deeper into HTTP connections (both of which require the browser to use local proxies to work).

FoxyProxy Standard is a great add-on that allows you to add multiple servers which you can easily switch between, and also lets you set up proxies that are used automatically on certain URL patterns.

Ghostery

Ever wondered how many tracking methods are installed on the websites that you visit? Ever wanted to block them all and protect your privacy? Then Ghostery is the add-on for you. Using a large database of over 500 trackers, web bugs, pixels, and beacons that are all used to track your web activity, Ghostery analyses each webpage you visit and displays a list of all detected tracking methods that are installed. You can then easily block the ones that you don’t want tracking you, or unblock any that you determine are “harmless” (FeedBurner, Google Analytics, etc).

In addition, Ghostery allows you to view information about tracking companies that it identifies, including their privacy policies, to help you make a decision on whether to allow or block the tracker. Other features include the ability to block the creation of cookies based on company identification (which is a highly experimental feature, and should only be used with moderation), and the “whitelist” feature, which overrides any blocks for sites that you trust completely.

HTTPS Everywhere

HTTPS Everywhere is an add-on that I mentioned in a previous blog post, and it is one of my favourite add-ons for Firefox, not just because it makes your web browsing much more secure, but also because it is so simple. Many popular websites are served over HTTP, but actually support HTTPS, which encrypts all data sent between the web browser and the server. This means that anyone sniffing your network traffic won’t be able to recover sensitive data (such as passwords, cookies, etc). The reasons why HTTPS isn’t enabled by default on many popular websites are numerous (and are covered in the blog post I mentioned), which is where HTTPS Everywhere comes in.

Once installed, HTTPS Everywhere will force the use of HTTPS on popular websites that are known to support it. The add-on comes with a long list of supported websites, most of which are enabled by default (although you can enable / disable websites manually in the add-on preferences). In the latest version, you can even add your own rules for websites that are not on the default list.

HTTPS Finder

So you’ve got HTTPS Everywhere up and running, and a lot of your favourite websites are being served over HTTPS, but what about websites not on the default HTTPS Everywhere list? You can add your own rules, as mentioned previously, but before you can do that, you need to know which of the websites you frequent support HTTPS. That isn’t very easy to do from a web browser, which is where HTTPS Finder steps in.

HTTPS Finder sends a quick (and small) request to each website you visit, determining if the site supports the HTTPS protocol. If the response is positive, HTTPS Finder displays a message at the top of your browser, asking you whether you’d like to switch over to HTTPS. If you choose to make the switch, a new rule is automatically created for the HTTPS Everywhere add-on as well, saving you from having to write the XML rules yourself (which is a real pain). Simply put, if you have HTTPS Everywhere installed, make sure you get HTTPS Finder as well, and start surfing the web over HTTPS easier than ever before.

LastPass (alternative download link)

Most of us are terrible at using passwords on the web. We don’t want to remember long strings of letters, numbers, and symbols, so we choose shorter ones that are easier to remember. Not only that, but we often use the same short password for multiple accounts across the web, meaning that if one account is compromised by an attacker, it is very likely that multiple other accounts could be compromised too.

Enter LastPass, which is in essence, a better password manager for Firefox. LastPass requires you to register an account (which is free), which is protected by your username (email) and your chosen “master” password. LastPass then monitors all your logins, and asks you whether you’d like to save the username / password combination. If you browse to a website which you are not signed into, and which LastPass detects a login for, it will alert you of the stored login, and you can simply click a button to login automatically.

Ok, so now we’ve sorted out the “management” part of LastPass, we can talk about the cool part. All encryption / decryption and hashing of passwords is done locally, on whichever computer you happen to be using at the time. So when you register your account for the first time, the master password you enter is encrypted and hashed in your browser, and the resultant hash is sent and stored on the LastPass servers. Similarly, when you record a new username / password combination, the data is encrypted locally using 256-bit AES and then sent to the LastPass servers. At no point is any of your sensitive data viewable or retrievable by anyone with access to the LastPass servers, not even when it is being sent (all connections to LastPass use SSL for an additional layer of protection). When you open your browser and login to LastPass, all your encrypted logins are downloaded and stored on your computer in a local cache, and as mentioned before, all decryption of your login credentials is done in your web browser.

Of course, there are still some security issues that you should be vary of when using LastPass. Obviously, the master password used to protect your passwords should be secure (i.e. longer than 8 characters, containing letters, numbers, and possibly symbols), but you should also configure LastPass so that it automatically logs you off after a certain amount of time, or when the browser is closed. This is so that if you leave your laptop unattended, an attacker can’t just open up your browser and have access to all of your logins. For additional protection, LastPass also has a secure password generator built-in, which means you can create unique passwords for each of your logins without having to remember them all.

NoScript

No list containing the “Best Security Add-ons” for Firefox would be complete without one of the first (and most popular) security add-ons out there. NoScript has grown and grown over the past 6 years, adding more and more filters for executable content that runs within webpages. NoScript does exactly what the name suggests; it disallows all scripts that are trying to run on the page (that includes JavaScript, Java, Flash, and Silverlight). Scripts can then be “allowed” by marking them as such in the context menu that appears in the Add-on Bar.

The one downside of NoScript is that it will disable a lot of features for most modern websites, since the use of JavaScript (especially through AJAX) is very popular. As such, “training” NoScript to allow perfectly valid and safe scripts will take a while when you first install it, but if you can bear it, you will be protected from a lot of scripting attacks.

Perspectives

Whilst Certificate Patrol only gives information to the user based on changes in certificates, Perspectives goes one step further, and attempts to determine the likelihood of the certificate being signed by valid Certificate Authority (CA). Each time an invalid certificate is detected in Firefox, Perspectives contacts one of many network notary servers, which also downloads the certificate and sends it back to Perspectives for comparison. If the two certificates are the same, then the likelihood is that it is valid, and not generated as part of a Man-in-the-Middle attack.

Users can configure the add-on so that it checks multiple network notary servers, which will all send back the certificate for comparison, adding more assurance of the certificate’s validity. In addition, the servers store cached certificates and check them periodically to see the frequency at which they change (another factor in determining the likelihood of an attack).

I’ve left Certificate Patrol on this list for the simple reason that it is very good at displaying useful information about certificate updates. Certificate Patrol isn’t an addon for regular web users, but with its automation features, Perspectives is.

RefControl (alternative download link)

Each time you click on a link, your browser will send a “Referer” header field in the HTTP request. This field is set to the URL of the page on which the link was displayed, which means that the site you’ve clicked to will know exactly where you came from. In most cases, this might be quite harmless information (for instance, if you came from a Google Search), and most websites probably do not even record it or use it (although it is used extensively in any website that has some form of web statistics or analytic program). However, if you are paranoid about privacy, RefControl is for you. It will allow you to block the Referer header field from all requests, set the field as something completely arbitrary, or you can set up filters so that these actions can be applied on a per-site basis.

RequestPolicy

Quite a few attacks on the web can come not from malicious cookies or scripts, but from simple requests made by your browser following HTTP specification. When parsing HTML, a browser might come across an image tag, and so will have to send a HTTP request to the source URL of the image tag in order to display the image to the user. The problem is, the source URL might not lead to an image, but instead could make a request to another website, making it appear as if the user themselves had made the request. This type of attack is known as Cross-site Request Forgery (XSRF), and I’ve used it before in my exploit of the About.com poll system.

RequestPolicy is yet another add-on (along with Cookie Monster) that takes advantage of the familiar and easy to use interface that originated in NoScript, and also provides a powerful method that blocks all requests made to websites external to the one you are currently browsing. The user can then choose to allow certain requests, or keep them blocked. When testing this add-on, some parts of the web were instantly affected for me; for instance, when making a Google search from the Firefox address bar, the redirect from google.com to google.co.uk was blocked by RequestPolicy. This was easily fixed, but users should be wary that as with NoScript, once installing this add-on, you may have to build up a good whitelist before it stops annoying you!

Well, that concludes my list of what I consider the Best Security & Privacy Add-ons for Firefox. I hope it is of use to some people out there, and I of course encourage everyone to try these add-ons and take more proactive steps to securing themselves online. Please discuss these add-ons in the comments section below, and feel free to suggest add-ons that I may have missed; if I think they are important enough, I’ll add them to the post.

Update: Added “Perspectives” thanks to a suggestion by Reddit user badblock.

Update #2: Added “HTTPS Finder” thanks to a suggestion by the Reddit user (and add-on developer) httpsfinder.

Update #3: Added “RequestPolicy” thanks to a suggestion by the Reddit user maxlevchin.

This is a very good article from Webmonkey explaining why the vast majority of the web is stuck using the HTTP protocol, which sends all information (including usernames & passwords) as plaintext, as opposed to HTTPS, which encrypts it. Whilst HTTP is fine for a lot of static websites, it is very insecure for websites that have access to personal information, or that are accessed using some kind of password.

The problem of HTTP based login sessions doesn’t stop with passwords being sent in the clear though. Whilst users usually only enter their password once per session, their associated session cookie is sent with every request, and so stealing this cookie is a lot easier than stealing the password. The stolen cookie can then be used to hijack the current session of that user.

The main reasons why most websites don’t move to HTTPS has nothing to do with complexity in setup, but rather the high cost of digital certificates, slower speeds of transfer (due to the initial key exchange), and the inability for browsers to cache web pages. So for now, it doesn’t seem likely that your favourite forum or blog (even this one!) will switch to HTTPS.

So what can you do? Well, if you do use websites that require passwords to access, or that store session cookies on your computer, make sure you are using a network that is trusted. In other words, use a network that you know (such as one at your home or work), and in the case of wireless networks, make sure it is secured by at least WPA. Public WiFi access points that are usually found in coffee shops should be avoided, mainly because they are susceptible to Evil Twin attacks.

For users of Firefox who are more concerned about security and less about speed or caching, I highly recommend HTTPS Everywhere, an addon that forces HTTPS on popular websites that are usually served over HTTP.

Any online poll that doesn’t require some form of registration is going to run into big problems when trying to limit users to one vote each. The standard procedure of many online polls is to assume that each IP address constitutes one person, and thus the poll is limited to one vote per IP address. Whilst this assumption is of course flawed in both aspects (one IP address can be assigned to multiple people, and one person may have access to multiple IP addresses), it is a good one to have when trying to limit the amount of “voter fraud” in anonymous online polls. However, relying on this assumption alone as a preventative measure is not even close to good enough.

Other methods for limiting people to one vote each usually rely on the ignorance of most internet users in terms of how browsers work. For instance, a relatively common method I have seen is to set a cookie when the user votes, and then to check the status of that cookie whenever they make a subsequent vote. If the cookie is set, the vote is disallowed (though this action may not be communicated back to the user), and if the cookie is empty or non-existent, the vote goes into the system. Since cookies are stored on the user’s computer and not the poll server, they can be easily (in most cases) deleted by the user in question. In fact, many browsers have methods built-in to them to deny cookies from certain websites¹, and some have extensions that can easily be used to perform repetitive votes in an online poll.²

If preventing as many instances of voter fraud as possible is your aim, then using methods that depend on client-side procedures is a big mistake. Limiting the poll to one vote per IP address is the best way to go if you don’t want to code a registration system, but the additional security measures should not be overlooked.

About.com is a large information & advice sourcing site owned by The New York Times Company.³

About.com’s content is provided by a large group of writers, who each write for a specific topic, ranging from African History to Yoga. According to Alexa⁴, About.com is ranked as the 64th most visited website on the internet, so you would expect their design team would know a few things about how the internet works. Sadly, when it comes to anonymous online polls, this is not the case.

Every year, About.com run a “Readers’ Choice Awards” competition, where their readers vote in various polls for each topic. The medium for most polls used appears to be a custom-made form, the processing of which is done on an About.com server. The poll I chose to do my analysis on was the “Best Web Design Overall” poll at the About.com Web Design / HTML topic. I thought it a good poll to choose given that at the time it had received relatively few actual votes, and the topic ties in nicely with the security of online polls.

Using Paros (a nifty proxy tool that allows you to view raw HTTP requests / responses), I captured the exact requests sent to the About.com server that were responsible for making a vote (my vote went to the site in last place, which at that point had only 3 votes).

GET http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: webdesign.about.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/b/2011/02/11/vote-for-the-about-com-readers-choice-awards.htm
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2; zFS=B2IB0B20B10B00B01
 
GET http://guidepolls.about.com/webdesign/6765141284/results.js?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: guidepolls.about.com
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2

For security reasons I have removed the User Agent information from the two HTTP requests above.

What is very interesting is that my vote was sent (in the first request) using a GET method rather than a POST method that is usually associated with forms. The resulting HTTP response including a call to a JavaScript file (second request), and it was this second request that seemed to do the actual vote. One thing I did notice is that the poll did not rely on Cookies, but instead seemed to record my IP address with my vote, and disallowed any subsequent votes from my connection. However, this limit of one vote per IP address was the only “security” feature in place on the poll.

Knowing that the poll used a GET request, and that I could not simply manipulate the poll by sending multiple requests from the same IP address, I set up a fake HTML image tag in the footer of a website I run. The URL of the image would be the voting URL for my chosen poll option (i.e. the one in the second request above), and I added some custom CSS to the image that would hide it from view, so that no browser would show a missing image icon and draw attention to the code. The resultant code looked like this:

This type of exploit is known as a Cross-Site Request Forgery (CSRF/XSRF), and once embedded within the website footer, it was only a matter of time before site visitors would load the page and get their browser to (unknowingly) send a vote to the About.com server. The vote would be from their IP address, and would go completely unnoticed to most web users. Sure enough, after a few minutes, the poll results had gone from this:

Before

to this:

After

With the exploit working, and the site “Fido” in the lead, I removed the malicious code from my site. I refrained from posting this blog post until the official About.com voting period was over, and the results were announced (in the end, Google won).

What should be taken away from this? Well, don’t use GET requests to add votes to polls; POST requests are trickier to force upon users, and usually either involve them clicking submit on a form, or having some JavaScript doing the action in the background. Another thing this should alert web designers to is the importance of another level of security on top of their polls. It is great if you can code a poll that works, but it is even better to code a poll that works securely, especially if there are people out there who want to manipulate your votes for reasons other than trying to demonstrate possible exploits (like myself). In my opinion, I believe that a simple CAPTCHA verification (such as the popular reCAPTCHA) should solve most problems with online polls such as this. Yes, they can get annoying, but at the end of the day, they only take up a few extra seconds of your users’ time, and they are very difficult (though not impossible) to bypass.

An example HTTP Cookie

According to this BBC News article, a new European e-Privacy directive that comes into force this year will require websites that use cookies to gather explicit consent from users before issuing them to the browser. The directive was created to try and cut down on websites that track users from site to site, and display adverts based on the information stored about them in their cookies. Cookies used for logging what people have in their shopping baskets (common in online stores like Amazon) are apparently the only use that are excluded from the directive.

Of course, this leaves the question of what will happen to the most common use of cookies, that of logging people into websites? Every time you use a username & password to log into a website, you are usually issued with a cookie that acts as your “passport” around that website. Instead of entering your username & password on every page load, the cookie is sent instead, saving you a lot of time and effort. Like a passport, the cookie is unique to each user, and usually has some form of randomness to make it near-impossible to brute-force. So if sites have to gather explicit consent before these cookies are issued, this may mean that as an addition to entering your username & password, you may have to check a box to say you agree to receiving the cookie, or in some extreme cases, have to click away a popup box in order to log on properly.

Whilst I agree that cookies have become a big privacy issue as of late, I’m not so sure I agree with the directive in this case. Something does need to be done to stop the tracking of users around the web, but I believe such a harsh directive as the one issued will do more damage to the web browsing experience than it will good. Not only will it slow down the whole process of logging into websites, but it may also lead to more confusion of the average user. It could also cause some unintended side effects, such as more people leaving their sessions open rather than logging out, meaning that any intercepted cookies would be valid for longer.

In my opinion, the issue of how to handle “malicious” cookies should be done in the browser. After all, it was browsers who started fighting the problem of malicious JavaScript, as well as dealing with the various pieces of malware that spread over the web. Indeed, only a couple of months ago the BBC reported on such moves from both Mozilla, Google, and Microsoft. Whilst this directive probably will solve a few problems with cookies, I predict it will cause more for the end user in the long run.