Securing your website: A tough job, but someone’s got to do it

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.

Credit: ~AbhishekKr

According to the most recent ranking of the top 10 vulnerabilities by the Open Web Application Security Project, the most common website threats include:

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.

Security misconfiguration

These bugs often give attackers unauthorized access to powerful system functionality or sensitive data. They result from misconfigurations to Web servers, apps, or custom code. They can be avoided by hardening Web environments, including keeping operating systems, apps, and all other software up to date, disabling or uninstalling unused services, and disabling any default accounts or account passwords.

Insecure cryptographic storage

This is a series of sins and omissions that some security experts have recently leveled at Kim Dotcom’s Mega cloud storage service. Insecure cryptographic storage can take many forms, from failing to encrypt credit card data or other sensitive information, to using insecure cryptographic implementations that allow attackers to decrypt encrypted contents. Mega provided Web developers with an object lesson in cryptographic storage by failing to secure the key used in an algorithm in some of its crypto code. Another serious omission in this category is the failure to adequately protect databases of user passwords in the event that a site is compromised. While cryptographically hashing passwords is crucial, it’s not enough. It’s also important that the algorithm employed is designed specifically for password storage. Bcrypt, PBKDF2, or SHA512crypt are excellent choices. SHA1, SHA3, and MD5, not so much.

Update: As several Ars readers have pointed out, another key defense is securely discarding credit card data and sensitive information if it’s not mission critical.

Failure to restrict URL access

These errors happen when an application doesn’t protect page requests properly. They allow unauthorized users to access restricted pages by manipulating the URL. Once exploited, these flaws allow an attacker to do anything the privileged user can do. There are a variety of approaches to fixing these problems, including using authorization components that are external to the Web application.

Insufficient transport layer protection

Secure sockets layer and its sister protocol, transport layer security, are the basis for virtually all encryption used to authenticate websites and to encrypt data traveling between them and end users. And yet it’s surprising how sparingly and incorrectly they’re often used. It was only in November, for instance, that Microsoft’s Hotmail service allowed users to SSL-protect their entire Web mail sessions. Prior to that, users had no way of protecting their sessions from man-in-the-middle attacks once they proceeded past the login screen. But a lack of end-to-end SSL or TLS protection is only one example of insufficient transport layer protection. Browser cookies used for authentication and other sensitive purposes must contain a secure flag. And certificates should never be self-signed or allowed to expire. Most importantly, SSL and TLS implementations must be hardened to withstand several new attacks that have been developed over the past few years, including renegotiation attacks and an exploit known as Beast. Sadly, an estimated two-thirds of SSL-or TLS-enabled websites still aren’t protected against Beast, according to SSL Pulse, a website that is sponsored by security firm Qualys and monitors the effectiveness of the 200,000 most popular websites that use SSL.

Unvalidated redirects and forwards

Bugs in this category cause visitors to be redirected to other parts of a site or to different sites altogether. They’re frequently exploited by phishers or malware purveyors who lure would-be victims with a link to a trusted site like Google or Bank of America that then redirects to a malicious site.

Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may or may not be serious enough to warrant attention.

Credit: Jeff Williams, Aspect Security

Assume you’re vulnerable

With the growing complexity of Web servers and applications, readers should presume their sites are at-risk to at least some of the vulnerabilities described above. And that means your business’ most precious assets could literally be a few clicks away from being downloaded by hardened criminals or script kiddies. If that sounds like an exaggeration, consider the cautionary tale of HBGary Federal, the firm that two years ago was ransacked by members of the Anonymous hacking collective.

Although the firm provided security services for Fortune 500 companies and government agencies, it never bothered to adequately secure its own website. Its content management system was vulnerable to a SQL injection attack that allowed an innocuous-looking link like http://www.hbgaryfederal.com/pages.php?pageNav=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. The data breach probably wouldn’t have been possible—or at least as devastating—had the CMS been audited for injection vulnerabilities.

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. That makes the task of cracking the hashes considerably easier.

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.

In addition to putting trade secrets and other proprietary data at risk, website flaws also tarnish a company’s reputation—and for good reason. Besides the damage an unsecured site can inflict on its visitors, it also poses a threat to untold numbers of Internet users who have never heard of your site. That’s because vulnerable sites are frequently used in phishing, malware, and sundry other attacks.