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.

WhiteHat Security is holding a competition to find the top ten web hacking vulnerabilities of 2011. There are 50 vulnerabilities in the competition, and there is an open ballot to vote for the top 15. Those 15 finalists will then be judged by a panel of security experts and they will announce the winners.

Voting is open to anyone until 26th February.

This is an ingenious way of using search traffic to detect for malware installed on users’ computers. Kudos to Google for looking into this and being proactive about the way they handled the situation.

Google's Malware Warning

By the way, if you are not already subscribed to Google’s Online Security Blog I highly recommend it, especially if you have a Google account of some form. I’ve added it to this site’s blogroll as well.

A CAPTCHA is a type of test that attempts to verify whether a user is human or not. On the web, it usually appears in the form of an image, where the user has to enter the letters that appear in the image. This is quite easy for humans, but is very hard for computers, especially when the image letters are distorted. CAPTCHAs are useful for preventing automated posting or registrations by spambots, and over the years they have been increasing in complexity as the technology to break them becomes more successful.

So when this image popped up in my Google+ stream this morning, I could hardly believe my eyes.

Source code behind Sony's CAPTCHA images.

This is a CAPTCHA generated by Sony’s website. Whilst at first glance it appears to be an image, if you take a look at the page source code, you will see that it is actually just made up of plaintext characters, which are distorted by CSS and JavaScript.

The problem? Well, any computer can easily extract the CAPTCHA letters using regular expressions, or even by simply traversing the DOM. There is literally no security gained by having this type of CAPTCHA.

No wonder Sony kept getting hacked; they can’t even get basic security techniques right.

It seems ironic that only a day after publishing my lengthy article about the best Firefox add-ons for security and privacy, I would be publishing an article about a potential security concern with (you guessed it) a Firefox add-on. However, this opportunity seemed too good to miss.

The add-on I am talking about is called LessChrome HD, and was developed by Mozilla Labs in the midst of what could easily be described as a design war with Google over who can display the most amount of webpage in a standard window. Google leapt onto the scene with their Google Chrome browser in 2008, which featured a very streamlined interface that made Firefox look bulky and ugly at the time. Mozilla have responded time and time again, adding features that streamline the browser, hiding rarely-used menus, etc.

With LessChrome HD, Mozilla have created a way for users to temporarily hide toolbars at the top of the browser, giving you quite a bit more space in which to see whichever website you are browsing. The toolbars are visible when you are using them (i.e. when your mouse hovers over a tab) or when the browser is actively loading a page, but when the user clicks away and starts to read the page they are on, the toolbars disappear from view.

Cryptogasm.com as viewed with the LessChrome HD add-on installed in Firefox.

As you can see from the screenshot on the left, quite a bit of visual space is saved when the add-on is enabled. Those of you who follow me on twitter will probably know that I championed this add-on when I discovered it a few hours ago, but in that time I’ve thought about the security implications of hiding the current URL from users, and I am concerned about what this add-on will do to the current threat of phishing websites.

A phishing website is a site that is set up so that it looks exactly like a real website which people trust (common phishing websites mimic e-commerce sites or online banks). The idea being that users will click a link from an email or social networking site, believing it to be a genuine link to the real website, when in fact it takes them to the phishing website. The user enters their login details, which are then captured by the phishing website and used by the attackers to hijack the user’s account on the real website.

So what’s the problem? Well, there aren’t many methods in which to detect phishing websites from a web browser, which is why they are usually so good at fooling users into giving away their confidential information. However, one method which can be performed by any web user (regardless of their technical expertise) is to check the URL that is displayed in their browser, which won’t be the URL of the site they intended to visit. Take this example phishing website for instance; the website clearly is mimicking PayPal, and yet the URL displayed is a classic phishing URL, rather than “paypal.com”.

With the address bar disappearing from view once the page has loaded, most users might not check the URL as they would have before (even casually glancing at it could be enough to notice a phishing attack). As a result, I’m intrigued as to whether successful phishing attacks will increase with users who have installed this add-on in their browser. In my opinion, this is just another example of sacrificing security for usability, and in this case, security should be a top priority. I’d much rather have a smaller area in which to browse websites than become the unfortunate victim of a phishing attack, and as such, I’m uninstalling the add-on and suggesting that people who are concerned about security on the web do the same.