The Accidental Developer

SQL Injection Goes Mainstream

Note to the web development world: even a mainstream media source like Time Magazine knows about SQL injection. Don’t you think it’s time you protected your web applications against it?

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.

Tags: lulzsec, owasp, security, sql injection, time magazine

Why I’m Not Friends with My Bank on Facebook

I received a request today from my financial institution asking me to follow them on Facebook, Twitter, Flickr, and YouTube.

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.

Tags: banking, facebook, flickr, privacy, security, social media, socialmedia, twitter, youtube

WordPress Security Tips

I attended the WordCamp Birmingham conference this past weekend to find out more about all things WordPress. WordPress is an open source blog engine/lightweight Content Management System (CMS) that has a huge community of users and developers, and an enormous repository of plugins to extend its functionality.

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:
› Continue reading

Tags: birmingham, file permissions, mod_suexec, security, security plugins, ssl, wcbham09, wordcamp, wordpress

Validating the Referer: Not as Useless as I Thought?

I used to validate the HTTP referer header to verify that users were accessing certain pages from certain other pages. For example, users accessing sampleapp/edit.cfm should be getting there from sampleapp/index.cfm. Anyone accessing sampleapp/edit.cfm without coming from sampleapp/index.cfm was probably monkeying around and should be send back to the index page, or possibly even logged out.

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?

Tags: csrf, referer, security, xsrf, xss