In 2006, members of a notorious crime gang cased the online storefronts belonging to 7-Eleven, Hannaford Brothers, and other retailers. Their objective: to find an opening that would allow their payment card fraud ring to gather enough data to pull off a major haul. In the waning days of that year they hit the mother lode, thanks to Russian hackers identified by federal investigators as Hacker 1 and Hacker 2.

Located in the Netherlands and California, the hackers identified a garden-variety flaw on the website of Heartland Payment Systems, a payment card processor that handled some 100 million transactions per month for about 250,000 merchants. By exploiting the so-called SQL injection vulnerability, they were able to gain a toe-hold in the processor's network, paving the way for a breach that cost Heartland more than $12.6 million.

The hack was masterminded by the now-convicted Albert Gonzalez and it's among the most graphic examples of the damage that can result from vulnerabilities that riddle just about any computer that serves up a webpage. Web application security experts have long cautioned such bugs can cost businesses dearly, yet those warnings largely fall on deaf ears. But in the wake of the Heartland breach there was no denying the damage they can cause. In addition to the millions of dollars the SQL injection flaw cost Heartland, the company also paid with its loss of reputation among customers and investors.

The incident was hardly an anomaly. In the years that followed, a crop of other websites big and small have fallen victim to attacks that exploit SQL injection bugs, cross-site scripting flaws, and a series of other vulnerabilities. These small openings allow attackers to inject malicious code into an end user's browser or hijack a Web server altogether. Last month, the website for Reporters without Borders was commandeered so attackers could surreptitiously install malware on the computers of visitors. Attacks who exploit website flaws so the perpetrators can infect their visitors have grown so common they've given rise to the term watering hole attacks. The name comes because the hackers are like hunters who camp out at ponds in wait of thirsty prey in need of something to drink.

Odds are...

What all of this means is that unless you've recently had a professional security team audit your website, chances are it's susceptible to a host of vulnerabilities.

Injection

These occur when Web apps send user input and other untrusted data to an interpreter, such as a SQL database. Attackers like those working for Gonzalez find these bugs using scanners and can exploit them to steal password tables or other sensitive data. The flaws can also be milked to carry out denial of access attacks or even completely take over the underlying Web server. Individual vulnerabilities can be so numerous they're often akin to garden weeds that are hard to completely eradicate. The best way to prevent them is to rely on Web apps that sanitize user input before handing it off to a back-end server. Owasp's preferred way of avoiding injection attacks is to employ "a safe API which avoids the use of the interpreter entirely or provides a parameterized interface."

Cross-site scripting

Abbreviated as XSS, these flaws occur when Web apps send user-supplied data to a browser without properly validating or, if necessary, escaping it. Attackers exploit them to send JavaScript fragments that steal browser cookies used to authenticate an end user to an e-mail account or other restricted service. The flaws can also be exploited to deface websites, redirect users to other sites, or even use malware to hijack a user's browser. XSS bugs are avoided by ensuring that all user-supplied input returned to the browser is verified as safe or escaped so that it's no longer dangerous.

Broken authentication and session management

These errors reside in apps used to log users in to restricted parts of a site. Typically, they're found in custom-developed schemes that make some sort of critical error, such as requiring a session ID that is easy to guess or included in the URL. As their name implies, they result in such schemes not working the way they're supposed to, allowing attackers to take unauthorized control of user accounts and perform any action the valid user would, including deleting sensitive e-mail or data. The best way to keep clear of these vulnerabilities is to avoid custom-developed schemes in favor of one that has been well tested.

Insecure direct object references

These flaws stem from Web apps that use the actual name or key of an object in a URL when generating a page. In some cases, attackers can exploit these to gain powerful administrator privileges, simply by modifying some of the URL text. To prevent such errors, websites should use per-user or session indirect object references, which can't be manipulated.

Cross-site request forgery

CSRF exploits use fake websites to generate forged HTTP requests that attack end users of a vulnerable website. Attackers exploit these mistakes to force an end user to execute unwanted actions on a website she's already logged into. Exploits can force the victim to unwittingly delete e-mails or carry out any other authorized operation. Attacks can be especially devastating when the affected end user controls the administrator account. To prevent CSRF vulnerabilities, Web apps should employ unpredictable tokens in the body or URL of each HTTP request and should be unique per user session or per request.

Next, the five other major website security pitfalls and some final thoughts on precautions to take.

52 Reader Comments

" This means installing patches within 24 hours or sooner if possible. But given the complexity of most website platforms, patching isn't enough."

Sorry, given the complexity of most web applications, patching in 24 hours is not possible. My web app depends on something like 100 different libraries and frameworks. It is nearly impossible for us to keep track of all the latest updates and fixes. Even if we did, we could not possibly test and implement every critical security fix in 24 hours.

As bad as this sounds, I think your best route is to do your best to make sure that the vulnerabilities that are sure to be there are not exposed to hackers. Further design your infrastructure with the assumption that it will be compromised at some point and plan accordingly. For example, assume your web server is compromised, and additionally assume that whoever compromises it will be able to use local access to gain admin privileges. What can they do from there?

"The point isn't to shame the HB Gary admins. Rather, it's to show website sloppiness is the rule rather than the exception. If a firm dedicated to security can make these mistakes, imagine how bad things can be inside a startup in the e-commerce or mobile app industries."

Surprisingly enough, the security companies are usually the most sloppy in security (not all of them, of course), because they usually know that proper network security costs money, and sometimes a lot of money.So, they maybe do something great for her customers, because they pay for it, but are reluctant to do proper security on his own systems, because they will not get paid for that.

And for the CEO/stockholders, spending money into security is a waste, until you get *powned* (I know it is owned or pwned, but I like the sound of the POW in the face - Sorry )... Then, you will have a big budget for network security (if you are a sysadmin who don't have budget for security, try at least to make proper backup/restore and leave the global security AS IS, when a script kid found a way to destroy all the data, you will become a hero like superman)

Its content management system was vulnerable to a SQL injection attack that allowed an innocuous-looking link like http://www.hbgaryfederal.com/pages.php? ... =2&page=27 to inject an unauthorized query into the site's back-end database. As a result, the database spit out a list of usernames, e-mail addresses, and password hashes belonging to insiders of some of the world's most powerful organizations.

Wow. No session level authentication? Exposing data that should only be available to an internal network (or VPN access needed).

Also, agree with others -- those of us who are responsible for web sites know what the security threats are already, and links to tools or examples on how to eliminate these risks would be helpful.

In 9 out of 10 cases it's the fault of the administrator or website developer why a site gets hacked.Nuff said.

While it may indeed be the case for small shops, most organizations are inundated with process and procedure to the n'th degree making quick reaction difficult. Add to that the complexity of some apps mentioned by another commenter and it becomes a challenge just to GET patched much less react to a zero-day exploit in a timely manner. Your best defense is a combination of firewall (network and application layers), good patching processes that continually evolve to a point where you can react as fast as possible, given your environment, redundancy (being able to take systems offline to patch them while others remain online - business does NOT like going down to patch), and trusting in your administrators to be the experts. They know what they are doing. The business all too often fails to heed their advice and, although it is viewed as an accepted risk on the business side, the results can be catastrophic.

This article missed some pretty important vectors, and didn't in any way live up to its subtitle, "...here's how to prevent them."

Perhaps the most important missed vector is securing developer/sysadmin computers, passwords, and private keys through both technological and procedural means. On the technology side, laptops should be encrypted, private keys for source repos and server access should remain encrypted, regardless of the inconvenience. On the procedure side, passwords should not be given out over the phone, guests, including repairmen etc., should not be left alone.

The article generally frustrated me because it didn't really tell me how to fix any of these problems, or even point me at where to start. How do i configure my server to prevent BEAST-like attacks? wikipedia suggests firefox, chrome and ie are no longer susceptible. How do I find a reputable security auditors. We're looking for one right now, but there is very little information out there to help us choose. A lot of them look like snake-oil salesmen.

I realize this is an overview article, but even a couple links to more info for each vector would turn this into an ars-quality article.

The problem is that too many IT shops don't take security and coding standards seriously, and too many managers are concerned more about deliverable's and schedules than security. Everyone who touches the code needs to be adept in cyber security and how to void software vulnerabilities. Every IT shop needs someone in charge of cyber security who understands the software system and whose stamp of approval is required on every software update. This person could be anyone within your organization you choose, just as long as they are qualified.

It does not even mention the single best security practice you can implement. That is, simply deleting sensitive date as soon as you don't need it. If the CC info is not in your system, the hacker cannot get it.

This. It took me about a year to convince management here that we have no reason other than, "so the customer doesn't have to retype the CC number in to order again" to keep CC numbers. They finally gave me the green light to sanitize CC numbers (replacing all but the last 4 numbers in the DB with x's) and get rid of the CVV numbers when another company's, whose owner is friends with our CEO, website got hacked. I, in no way believe that our site is 100% safe, but I do sleep a little better at night knowing that if we do get hacked, there are no CC numbers to steal.

It does not even mention the single best security practice you can implement. That is, simply deleting sensitive date as soon as you don't need it. If the CC info is not in your system, the hacker cannot get it.

This. It took me about a year to convince management here that we have no reason other than, "so the customer doesn't have to retype the CC number in to order again" to keep CC numbers. They finally gave me the green light to sanitize CC numbers (replacing all but the last 4 numbers in the DB with x's) and get rid of the CVV numbers when another company's, whose owner is friends with our CEO, website got hacked. I, in no way believe that our site is 100% safe, but I do sleep a little better at night knowing that if we do get hacked, there are no CC numbers to steal.

Not to mention this is a part of the Data Protection Act here in the UK: "Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes." Storing CC numbers automatically for the life of the account (as compared to 28 days when the customer can legally return the product bought) breaks this rule, unless explicit permission from the customer has been given.

Commenters are frustrated that the article doesn't really explain how to prevent each type of attack. Guess what? That's an entire career's worth of explanations. Every one of these attacks can manifest in a thousand different ways, depending on the language, web app platform, web server, OS, etc. You can't explain how to deal with every one of those possibilities in a single article, or even a hundred.

Instead, the article gives two pieces of advice, which I think are both excellent:

(1) ••Start from the assumption that you are vulnerable:•• Don't presume you're secure; you're probably not. Take steps to close off attack vectors. Back up. Be ready for an attack to succeed — especially if you're a high-profile target, but even if you're just a potential member of a botnet.

(2) ••Get another pair of eyes looking for vulnerabilities:•• No, it doesn't have to be some overpriced audit from a big-name consulting farm. Just don't be so arrogant as to think that you can spot all of your own mistakes!

"Attackers exploit these mistakes to force an end user to execute unwanted actions on a website she's already logged into."

I'm no English major, so bear with me. The word "he" is the first person gender neutral pronoun. It just happens to also be the masculine. "She" is the pronoun of personification, and also happens to be the same word as the feminine. Using the correct term is not sexist, and swapping them does not display some kind of mis-placed regard for equal opportunity. Try this on for size: "Look at my boat, isn't he a beauty," said the captain.Sounds silly, doesn't it?

" This means installing patches within 24 hours or sooner if possible. But given the complexity of most website platforms, patching isn't enough."

Sorry, given the complexity of most web applications, patching in 24 hours is not possible. My web app depends on something like 100 different libraries and frameworks. It is nearly impossible for us to keep track of all the latest updates and fixes. Even if we did, we could not possibly test and implement every critical security fix in 24 hours.

As bad as this sounds, I think your best route is to do your best to make sure that the vulnerabilities that are sure to be there are not exposed to hackers. Further design your infrastructure with the assumption that it will be compromised at some point and plan accordingly. For example, assume your web server is compromised, and additionally assume that whoever compromises it will be able to use local access to gain admin privileges. What can they do from there?

If deploying is that painful, then the app must be disabled until the fix can be made. You can never know that someone didn't root your box and install a rootkit in the meantime.

Commenters are frustrated that the article doesn't really explain how to prevent each type of attack. Guess what? That's an entire career's worth of explanations. Every one of these attacks can manifest in a thousand different ways, depending on the language, web app platform, web server, OS, etc. You can't explain how to deal with every one of those possibilities in a single article, or even a hundred.

Instead, the article gives two pieces of advice, which I think are both excellent:

(1) ••Start from the assumption that you are vulnerable:•• Don't presume you're secure; you're probably not. Take steps to close off attack vectors. Back up. Be ready for an attack to succeed — especially if you're a high-profile target, but even if you're just a potential member of a botnet.

(2) ••Get another pair of eyes looking for vulnerabilities:•• No, it doesn't have to be some overpriced audit from a big-name consulting farm. Just don't be so arrogant as to think that you can spot all of your own mistakes!

Agreed. I don't expect Dan to cover it all here, but it sounds like there is a high level of interest in the topic, so perhaps he'll have some follow up posts. Maybe he can bring in one of the "experts" to give a quick summary of the basics of blocking 1 of the topics, etc... I certainly am interested and I don't even run a website, but as the survey showed, there a significant number of IT and Software Dev readers here so I'm sure interest would be high.

" This means installing patches within 24 hours or sooner if possible. But given the complexity of most website platforms, patching isn't enough."

Sorry, given the complexity of most web applications, patching in 24 hours is not possible. My web app depends on something like 100 different libraries and frameworks. It is nearly impossible for us to keep track of all the latest updates and fixes. Even if we did, we could not possibly test and implement every critical security fix in 24 hours.

As bad as this sounds, I think your best route is to do your best to make sure that the vulnerabilities that are sure to be there are not exposed to hackers. Further design your infrastructure with the assumption that it will be compromised at some point and plan accordingly. For example, assume your web server is compromised, and additionally assume that whoever compromises it will be able to use local access to gain admin privileges. What can they do from there?

If deploying is that painful, then the app must be disabled until the fix can be made. You can never know that someone didn't root your box and install a rootkit in the meantime.

Please join the real world where web apps are supposed to make money. And for that, they need to be usable, which in turn means that they should not go offline every day to accommodate the testing of another point release of a library. There's a delicate balance to be maintained here, shouting naive and idealistic slogans like Yours is not going to solve anything.

I'll give a run-down of how I designed my last system to at least be difficult to hack; it may be useful to some and I'm also interested in any feedback as I'm not a security expert.

1) The website is the porch door; don't rely on it to keep someone out. The website servers can't get to the database; they can only call the web service, which runs on separate servers with a firewall in-between them. The web service requires WCF authentication and SSL

2) The web service has its own user account on the db which only has permission to run the specific stored procedures it needs. It has no table-level permissions at all

3) Stored procedures must be called using ADO.NET's parameterised calls, which protects against SQL injection attacks. Parameters must never be concatentated into a SQL string. If you don't trust developers to get this right you can always build it into your Data Access Layer that it doesn't allow this type of query to be executed.

4) The password is checked against the username within the stored procedure rather than in the middle-tier. Therefore even if someone compromises the web service they still can't get to passwords without compromising the database

5) Credit card information is never sent to our servers. We use a (very big and hopefully very secure) third-party's system that takes the payment form from our server but the form is submitted to their server using SSL and they basically send our system an 'OK' or a 'NO'. The user can't see this; as far as they can tell it was all done on our website

6) Databases are encrypted using Redgate's SQL Storage Compress, and back-ups are encrypted using their Hyperbac product. Far cheaper than upgrading to SQL Server Enterprise and actually offers some very nice extras (e.g. compressions, which can actually increase performance)

Servers are updated promptly, and there's a firewall in front of the web servers, and another between the web servers and the main network (which are also on separate subnets). The web servers aren't part of the domain.

Obviously there's more to it, but much of that's been covered in the article and the rest is a bit specific to what we do.

We also plan to invest in an IPS (Intrusion Prevention System) to further secure the system and also help protect against a DDOS attack.

I won't pretend to be an expert but these measures certainly should make us a tougher nut to crack than most. I've seen many hack attempts logged in the five years the system's been running, but as far as we know no-one's managed to penetrate even the website servers, let alone the deeper levels.

I've always made it clear to the directors that it's impossible to make our systems invulnerable; not even the best security experts on the planet can manage that. However we should be safe against non-expert hackers, and we also limit the damage an attacker could do even if they did compromise our servers (e.g. by not having credit card details going through them).

Yep, when designing MAFIAAFire we knew we were going to get a lot of uninvited attention and thus tried to take as many precautions as possible. Is it 100% secure, I doubt it, but I also know if anyone does get it, there is very little there that they can make use of.

Was looking forward on brushing up on my security skills and see if I missed something or pick up a few tips so read the whole "securing your website" and like a lot of others came out disappointed that this article didnt really mention _how_ to secure your website

So, would it be better to have no TLS encryption at all than to potentially have a site unprotected against Beast?

I followed Lee Hutchinson's guide to setting up TLS encryption on my home-hosted Wordpress blog. Would I be better off serving unencrypted pages than pages encrypted with a free SSL certificate from StartSSL, as mentioned in Lee's article Web served, part 2: Securing things with SSL/TLS?

I'm no English major, so bear with me. The word "he" is the first person gender neutral pronoun. It just happens to also be the masculine. "She" is the pronoun of personification, and also happens to be the same word as the feminine. Using the correct term is not sexist, and swapping them does not display some kind of mis-placed regard for equal opportunity. Try this on for size: "Look at my boat, isn't he a beauty," said the captain.Sounds silly, doesn't it?

Sorry, I just had to say something, as this is one of my pet peeves.

I, too, am galled when the sound and fury of PC trumps the Received Standard. Since the days of the Bard of Avon the masculine has imputed the feminine and, likewise, the plural has imputed the singular. What was good enough for Shakespeare is certainly good enough for me.

"To make matters worse, the retrieved passwords were cryptographically hashed using the MD5 algorithm, which security experts have long cautioned isn't suitable for password storage. That's because, as explained above, such algorithms are fast and computationally undemanding."

Speed has almost nothing to do with the security. It has almost everything to do with a lack of salting and a lot to do with the cryptographical weakness of MD5.

Take a fast implementation of SHA512, a hypothetically "perfect" computer, hash a 20char strong passphrase, and no matter how fast of a computer you get, you cannot break it because there isn't enough energy in the Universe.

More about scrypt...scrypt has configurable memory hardness. You can configure it to consume something like 8KB of state, but runs quite fast.

This doesn't seem like much, but when you look at modern GPUs, they have something like 96KB of cache shared with a few hundred threads. Also the memory access done by scrypt is random. Between the lack of cache for GPUs and the random access pattern, GPUs will run quite a bit slower than a multi-core CPU.

Values can be tweaks to make it more GPU friend and less CPU friendly or visa versa.

Mmmm, I never setup a website, but if I rent a simple web server how deep I can usually touch and configure it? Some suggestion here talk about firewall (I suppose external) and different networks for separated server but I don't think it's applicable if I don't host everything myself... I saw a simple admin panel once and you could only put and remove website files, updating the server was impossible...

I, too, am galled when the sound and fury of PC trumps the Received Standard. Since the days of the Bard of Avon the masculine has imputed the feminine and, likewise, the plural has imputed the singular. What was good enough for Shakespeare is certainly good enough for me.[/quote]

Alternatively you could, just like Shakespeare often did, modify the language to suit new uses.I use "they" as a singular pronoun and although at times it seems awkward, I think that's born of unfamiliarity.

"Attackers exploit these mistakes to force an end user to execute unwanted actions on a website she's already logged into."

I'm no English major, so bear with me. The word "he" is the first person gender neutral pronoun. It just happens to also be the masculine. "She" is the pronoun of personification, and also happens to be the same word as the feminine. Using the correct term is not sexist, and swapping them does not display some kind of mis-placed regard for equal opportunity. Try this on for size: "Look at my boat, isn't he a beauty," said the captain.Sounds silly, doesn't it?

Sorry, I just had to say something, as this is one of my pet peeves.

Now you're getting into a cultural interest matters please do understand that in some cultures people most likely preferred the objects to be treated as "femine objects" Things such as "boats, ships, cars, even dimonds". "Isn't this dimond a beaty?" I don't recall any cultures that I know of using the word "beauty" on a male gender as "he is a beauty?" Well unless you are talking about these people of special interest groups within the district of Castro of city of San Francisco. I don't know if Mr. Dan Goodin belongs to these special interest groupies. If he is, he wouldn't be using "she" as opposed to what you said "he". Sighs..

<on topic>When you are an IT admin, script languages is not a job requirement but is helpful. Never depends on third party firewalls, "We required that you are to opened a port so we can get in to scan and protect your files." Doesn't sounds any convincing to me at all. While I am saying this, Windows firewall doesn't protects your "temp" user accounts. Wondering why. I for one who rather access the net with a Windows "temp" account instead of from my regular accounts.

" This means installing patches within 24 hours or sooner if possible. But given the complexity of most website platforms, patching isn't enough."

Sorry, given the complexity of most web applications, patching in 24 hours is not possible. My web app depends on something like 100 different libraries and frameworks. It is nearly impossible for us to keep track of all the latest updates and fixes. Even if we did, we could not possibly test and implement every critical security fix in 24 hours.

As bad as this sounds, I think your best route is to do your best to make sure that the vulnerabilities that are sure to be there are not exposed to hackers. Further design your infrastructure with the assumption that it will be compromised at some point and plan accordingly. For example, assume your web server is compromised, and additionally assume that whoever compromises it will be able to use local access to gain admin privileges. What can they do from there?

If deploying is that painful, then the app must be disabled until the fix can be made. You can never know that someone didn't root your box and install a rootkit in the meantime.

Makes perfect sense, doesn't it? I wish you luck making that a reality. The business thrives off of the balancing act between being secure and actually doing business. Being fully secure is pretty pricey and cumbersome, exacting expenses not all businesses can afford. So, in the end, it's a tradeoff and shutting down an app is not normally an option for any business which hopes to succeed.

Most of the recommendations look good, but one doesn't make any sense to me:

Quote:

Insecure direct object references

*snip* To prevent such errors, websites should use per-user or session indirect object references, which can't be manipulated.

This seems like bad advice to me. If a URL uses per-session references, then it can't be bookmarked. If it uses per-user references, it can't be shared. It's much better for objects to have unique canonical URL's, which are in turn secured by appropriate authentication and encryption as needed. URL's should not generally contain any information you're not willing to give an attacker, but obfuscating them by using some per-user or per-session indirection layer makes them less useful to users, and is not necessary to create a secure web app.

Putting object ID's in URL's means that attackers may be able to gather object identifiers that will in turn be useful in exploiting actual flaws. Using a server-side secret key would hide the actual values, which would make them useless for SQL injection, but still possibly useful for XSRF/CSS attacks. In the end, my sentiment is that such a risk is a reasonable sacrifice for the benefit of providing users with a sane URL schema.

It may not be politically correct, but every one of my servers (usually Debian) is setup to download an updated list of country-specific subnets every week. Requests from any East Asian country (minus Japan), and Eastern European country are stopped at the IPtables level. Of course, these servers have very specific uses and nobody from outside the United States, Canada, or the United Kingdom has need to access them. Obviously this solution won't work for everyone, but my nightly failed SSH login logs went from over 50 to pretty much nothing since implementing this.

One area the article really should spend a little time on is the availability of Web Application Firewalls.They are specifically designed to prevent SQL injection, XSS, forced browsing, command injection, session and cookie tampering, buffer overflows, XML attacks, DoS, and the list goes on and on.

They even do other cool stuff like SSL offloading, single sign on, caching/compression to not only secure your web site but also speed up the delivery of web content.

In combination with the right design, code reviews, and pen testing it is no excuse these days for high profile web sites to get hacked.

Don't forget Physical Security -- only time I've seen a database go missing was the time the electrician stole the (unsecured out-in-the-open) test server (true story. We had forensic cops in bunny suits dusting down the area). Do your developers have local copies of production data on their desktops? Do you have massive extracts of data (excel, csv, database backups, whatever) lying around?

Also don't forget to have procedures in place to prevent this old classic:

"Hey this is John from the Springfield office, our admin's away today, can you remind me what the sa password is?"

Sort of like the famous story about a monk and 'just some guy' being hunted by a tiger. The Monk looks serene, and the guy asks; how do you look so unworried. You're that confident you can outrun a Tiger?

The Monk says 'No... but I'm confident I can outrun you'.

Sort of the same principle. If it's easier, and more rewarding to hack someone else, they probably will.