Two common Web application attacks illustrate security concerns
RISK BULLETIN |
If you rely on the press coverage about hacking, you might end up focusing on the wrong enemy. Recent attacks on Facebook, Twitter, The New York Times and numerous governmental agencies worldwide have garnered significant attention in the media. But all these attacks had certain things in common. They were all long-term, determined efforts by hackers using sophisticated tools and approaches.
The problem, from an IT security planning perspective, is that such attacks account for a tiny minority of hacking attempts. A 2012 report by Verizon Business Services found that 95 percent of breaches from external attacks used simple schemes that could have been easily prevented. By concentrating your security efforts on these more common types of attacks, you will do far more to protect your systems – and your organization.
To illustrate this point, let's consider two of the most common types of attacks:
- Broken authentication
Injection attacks occur when malicious users take advantage of their ability to interact with your systems to insert commands that give them unauthorized access. Injection attacks are among the most common breaches. Over the past few years, high-profile injection attacks have resulted in the PBS website being defaced, one million records and passwords being stolen from Sony Pictures, 450,000 user credentials being stolen from Yahoo!, and personal records being accessed at 53 different universities. Fortunately, these are often among the easiest attacks to prevent.
Let's consider an example.
A manufacturer offers its customers an automated system to handle returns. As part of the return process, customers are asked to upload electronic copies of their receipts. That copy is then uploaded into the manufacturer's system as part of the process.
The problem is the manufacturer did not restrict and filter what could be uploaded. As a result, a hacker was able to upload their own code to the site, allowing them to modify the manufacturer's page. The hacker proceeded to modify the page by inserting links to sites they control. Though this modification was not visible to a website visitor, Web search engines such as Google identified this change and as a result, the manufacturer's search engine rankings plummeted while other websites inserted by the hacker had their rankings boosted.
In this case, the attack could have been thwarted by examining the file type during the receipt upload process. This would still offer users all the utility they needed to upload a receipt. And, by implementing that filter, the company would block attempts to upload malicious content.
Broken authentication attacks
Broken authentication attacks occur when hackers use flaws in authentication functions to gain access to passwords, session information or user accounts. Often, these attacks begin with injection attack tactics. Sometimes, though, simple brute force is enough.
Consider the example of a university system that asks students to use the last four digits of their Social Security numbers as identifiers to manage their account. Using automated tools, even a less sophisticated hacker could enter the 10,000 possible combinations in minutes to determine the last four digits of a user's Social Security number. As with our last example, this attack, too, could easily have been prevented.
No system should allow 10,000 login attempts for one account within one minute– or at all. Limit your users' login attempts to a reasonable number, say five, before they are locked out. Actual users are then redirected to provide answers to secret questions or other account verification data to which only they will have ready access. Restoring locked-out accounts presents a minor inconvenience for users that can prevent many broken authentication attacks.
Many systems now routinely require users to always or occasionally provide secondary security information, like answers to secret questions, even when their appropriate passwords and other account information are entered correctly. Again, a minor inconvenience for users that provides a huge return in security.
Finally, it is a best practice to avoid using whole or partial Social Security numbers as identifiers. That makes the pattern of the information a hacker must uncover easy to identify. Moreover, by forcing your users to reveal sensitive information, you risk opening them up to identify theft – and opening your organization up to potential liability should such theft occur.
Build security into the application development process
Sophisticated attacks can present a significant, but uncommon, threat to your business. Businesses should take a disciplined approach to Web application security that focuses first on the most common security concerns.
That starts with direction from management. For too many organizations, application security isn't truly considered after an application is developed. Organizations that wait until then to identify and address security issues are going at it backwards and often end up with a circular problem--fixing issues only to have them reappear. Security should be built into the application development process. A security requirements analysis should be an integral part of the initial design of an application. Developers should have solid security training that is continually updated as new threats emerge. Finally, every organization should conduct regular security maintenance and testing that focuses first on the most common threats to its applications.