Last week’s issue of Time featured an article that focused on LulzSec‘s activities. In Hack Attack, author Bill Saporito went a step beyond most journalists covering web security by mentioning an actual technique: SQL injection.

SQL injection is a subclass of injection attacks, wherein a malicious user manipulates input so as to insert (or inject) a tag-along command into the application code. It’s #1 on OWASP’s Top Ten Vulnerabilities for 2010, in part because such vulnerabilities are:

• Common
• Easy to exploit
• Have a huge payoff (i.e. devastating impact)

Because it is so common and easy-to-exploit, there are a lot of automated tools that malicious users (often by way of compromised machines) use to scan sites and test them for vulnerabilities. If a vulnerability is found, the application may be targeted for further attacks. Basically, attackers are on the lookout for low-hanging fruit in the same way that thieves look for valuables sitting in plain sight in a parked car. Don’t take the car analogy too far, though: if someone breaks into your car, there will be broken glass and your iPod will be gone. If someone exploits a SQL injection vulnerability on your site, they may have all your user data (and more), with hardly a trace: entries in your access logs and error logs, which are too-often completely ignored.

As the joke goes, you don’t have to outrun the bear to avoid being mauled and eaten–you just have to outrun the other guy. One of the best ways to make sure your web application is not targeted for further attacks is to make sure the relatively simple SQL injection scanners don’t find any vulnerabilities.

SQL injection is fairly simple to defend against using parameterized input, and your development language of choice should have documentation on how to do this. OWASP also offers a SQL Injection Prevention Cheat Sheet. There are also automated tools to you can use to check your code for SQL injection flaws (such as QueryParam Scanner for ColdFusion), or test your site for vulnerabilities–also known as penetration testing or pen testing–such as the (currently out-of-date) SQL Inject Me add-on for Firefox.

Checking your web applications for SQL injection vulnerabilities is the first thing you should do, but it is hardly the last. Although fending off automated SQL injection attempts is definitely a good thing, there are many other categories of vulnerabilities, and a determined attacker will find them. Stay informed, and make sure you know what attackers are up to before you read about it in Time.

Aside from the fact that I doubt that their updates on these various services will enrich my life, there is another very good reason not to follow them:

Security.

It’s easy to trace your connections online. Most of this information, for most users, is public. If you follow Bank A, it stands to reason that you have an account at Bank A–something a malicious person would not have known before. Even if your online persona isn’t directly connected to your name, you might be surprised at how easy it is to connect the two with a Google search.

• Want to know 9000 people with Citibank accounts? Check http://www.facebook.com/citibank
• Want to know 6000 people with Wells Fargo accounts? Check http://twitter.com/#!/Ask_WellsFargo/followers
• Want to know 5 people with Bank of American accounts? Check http://www.youtube.com/user/bankofamerica/

(That last item says a lot, I think.)

Any bank that suggests you follow them on social media must be pretty confident of their security! Or, more likely, their marketing teams and their security teams don’t talk to each other.

You wouldn’t stand on a street-corner handing out cards that say, “My name is Bob Billiards and I have an account at Bank A” would you? Then don’t follow your bank on a social media site.

One of the presentations I attended, Mitch Canter‘s session on WordPress Security, had 6 good tips for making your WordPress-based site more secure:

1. Updgrade WordPress
   WordPress recently released an important security update. Making sure that you are using the most current version will ensure that you have the latest security patches. (WordPress will complain if you aren’t running the latest, greatest version, so no need to fear: you’ll know.)
2. Update your plugins
   Plugins are 3rd-party code that can have their own security flaws [a good reason, in my opinion, to do a little research before you install any old WordPress plugin you find lying around the internet]. Find out if updates are available for yours.
3. Set your file permissions
   A lot of WordPress users may not be familiar with Unix/Linux file permissions, and once they find out, they may become even more confused, as files permissions use an octal-based numeric scheme to determine who (the owner, the group, or other users) can do what (read, write, execute) with a file.

   Depending on which user your web server runs as, your files should be set to 0775, which means you (the owner of the files) and the associated group can read, write, and execute the files, but other users can only read and execute the files. With Apache 2, you can use mod_suexec and a SuexecUserGroup command to make the webserver run commands as a specific user and group, which means you should never have to make any of your files or directories world-writable.

   ["World-writable" is a misnomer here--it really means "writable by anyone who has access to the server." That means other legitimate users who may have an account on the same machine, or malicious users who have compromised someone else's account on the system.]

4. Make backups
   I was really glad this came up, because security is about much more than preventing malicious attacks. It’s about maintaining your data over time. Mitch suggested the wp-db backup
   WordPress plugin. [Although one of the options is to have WordPress send an e-mail with the compressed data, e-mail is not a secure way to transfer data, and I would recommend against it.]
5. Delete the admin account
   Every WordPress install comes with a privileged account, ‘admin’. Automated attacks can be launched against your system attempting to login as this user with a guessed password.

   Anyone that really wants to hack into your system can do a bit of sleuthing and probably guess your actual login name–but creating a new account with administrative privileges and changing the admin account should at least provide some protection against the most automated attacks.

6. Change your WordPress database table prefix.
   This setting is contained within the wp-config.php file, and it’s easiest to change it when you are first setting up a new WordPress install. Otherwise, you will need to change not only the config setting, but additionally all the table names in your database. This change will help protect you from automated SQL injection attacks.

Some additional ideas were floated during the questions and comments portion of the session, most of which included plugins, such as:

• WP Security Scan
• WP Firewall
• Stealth Login

Other ideas included:

• Restricting access to the files within wp-admin to specific IP addresses (this may not work for most people, who want to update their sites from wherever they happen to be)
• Installing a self-signed SSL certificate and requiring SSL (https instead of http) to log in. This wouldn’t be good solution if you are setting up a site for someone else, as they would get browser warnings unless they permanently accept the self-signed certificate.

I will probably be posting further updates this week with my notes from the WordCamp.

However, it is fairly trivial to modify your referer header, so anyone who wants to monkey around with sampleapp/edit.cfm can make it look like they are coming from sampleapp/index.cfm. (If you’re interested in modifying your HTTP headers, I suggest checking out the Tamper Data Firefox plugin.) The check provides absolutely no assurance that the user is really coming from the page. Therefore, I decided the check was useless.

I’ve been attending a weekly web application security study group with some of my colleagues for the past several weeks, where we’ve been reading and discussing The Web Application Hacker’s Handbook. The past couple sessions have been about cross-site scripting (XSS). Justin Klein Keane brought up a good point at today’s session: checking the referer may not keep a malicious user from altering his or her referer string, but could help identify victims of XSS attacks who were possibly directed to submit malicious data from a third-party site.

Checking the referer isn’t a sufficient protection against malicious users, by any means, but it could still be helpful. What do you think?

An encrypted string is secure as long as the key is secure, which it seems to me is both its strength and its Achilles’ heel. Since the application that accesses the database needs to use the key, that means that if both the database and the application server are compromised, the data is compromised.

It also means that if the application developers have access to the database, or if the DBAs have access to the application code, the data is available to those individuals. Even though those users are most likely trustworthy, it is perhaps an unnecessary risk–not to mention their workstations may be compromised. On top of that, you need to worry about key escrow–if you lose the key, you no longer have access to your own data.

A hashed value is secure even if the database and the application are compromised, as it is the result of a one-way function. The value is also inaccessible to either the application developers or the DBAs, which provides an additional layer of security. On the other hand, since it uses a well-known hash function, such as MD5, creating a dictionary file of hashed values is trivial, and apparently an even more effective method to reveal hashed data is to use a rainbow table (the description of which goes a bit over my head right now).

That’s where the salt comes in: concatenate the original value along with extra data before creating the hash. I can see how this would foil a simple dictionary of hashed values. From what I’ve read, the salt value can be unique for each hashed value, and can be stored alongside the hashed value in the database. I’m not sure I entirely understand how that defends against rainbow tables, but it sounds good to me.

Using a hashed value, you can’t retrieve the original data–you can only match against it. This would not work well for data that you need to access again in its original form, e.g. phone numbers. This is a drawback in some cases, but probably not for passwords.

Right now I’m leaning towards salted hash over encryption, but maybe that’s because I’m hungry and it sounds more like breakfast. I’d love to know what other people think.