It wouldn't be the new year without a "best of" or a "top ten" list.
For my list, I’ve chosen to expand upon OWASP's (Open Web Application Security Project) recap of the top application security threats to look out for next year.
So here they are, the top five application-security risks for 2010.
1. Injection Attack
All web applications that collect and transmit data (using forms, for example) are susceptible to injection attacks. By sending specific commands through your application's forms, hackers can modify various elements of the code. In extreme cases, injection attacks could allow attackers to penetrate a firewalled environment, such as a network or database.
SQL injections like the ones that compromised Symantec and NASA this year dominate this attack category, but there are many additional varieties to which you could fall prey.
Some of the best protective measures for injection attacks include:
- Input Validation. Cleanse your input data.
- Human Verification.
- Restrictive Privileges. When connecting applications to databases and other proprietary systems.
- Vague Error Messages. Gives attackers little detail to go on and can help defray an onslaught
2. Cross-site Attack
Cross-site scripting (XSS) attacks steal private information like cookies or session tokens that unsuspecting users have associated with a particular website. XSS exploits can also redirect victims to familiar-looking web content that has been devised by the attacker to steal personally identifiable information or install malware.
Hackers deliver the malicious XSS-laden content that makes these exploits possible in the form of JavaScript, HTML, Flash or any executable code format for that matter. Any web application that compiles user-generated content without validating or encoding it first could fall prey to an XSS exploit. Social media hubs and blogs that allow users to post un-moderated comments are extremely susceptible to malicious XSS exploits (as was the case with Reddit's stored XSS attack earlier this year). This can include customer reviews and comments.
Reflected XSS exploits can be combined with phishing techniques to invade private information systems like email. Lance James and his team of experts reveal how easily they exploited an XSS vulnerability to win Strong Webmail's $10,000 challenge in a quick two weeks.
Developers can help prevent XSS Attacks by deploying code that:
- Validates user input.
- Does not give a site or page "full trust" simply because HTTPS is present.
- Is heavily tested. Test, test, test, and then test again before launching or introducing website enhancements.
3. Cross-site Request Forgery
Cross-site request forgery (CSRF) exploits force unknowing users to carry out any number of malicious activities as long as the action is allowable within their permission set during an authenticated user session. If a web application administrator's credentials are compromised for example, CSRF could overtake the entire website.
Here's a short list of some common (and catastrophic) CSRF capabilities:
- Force a user to post an insulting comment or malicious link on a blog, forum, or product review.
- Change passwords, emails, and login credentials, effectively terminating access.
- Submit a user's email address and sign up for a newsletter.
- Make a purchase and use the hacker's shipping address.
CSRF capabilities are so powerful, you can understand why banks, financial brokers, bill pay services, and basically any institution that ties user credentials to money would need to approach each day with extreme caution and oversight. In a blog post this year, SECCOM Labs demonstrated how easily a CSRF banking scheme could be carried out.
Prohibiting users from submitting HTML code is one way help prevent CSRF. In many cases; however, that's not feasible because sites containing blogs, product reviews, and social media rely heavily on user-generated content. If your application has social web components like product reviews or comments, be aware that extremely effective, proprietary tools capable of disarming security features of even the most popular social vehicles like Twitter and Facebook do exist.
Protect applications from CSRF vulnerabilities by:
- Only accepting POST transactions.
- Create unique token values for each request.
- Re-authenticate based on the unique token or a password.
4. Insecure Direct Object References
Insecure direct object reference flaws allow attackers access to private directories, for example, by manipulating the URL to gain access. The primary risks with insecure direct object references include data leakage and identity theft. Adobe Flash Player fell victim to this type of flaw last year, and the company has since addressed and patched the vulnerability.
Developers with expertise in securing applications can help prevent insecure direct object references by:
- Creating a schema to protect and identify each object accessible by users.
- Using indirect reference maps in code when referring to file names, URLs and database keys.
- Ensuring the session is authenticated to view the requested information or files and only grant access for that specific request when direct references are required.
5. Broken Authentication and Session Management
Because all web applications have (at least) an administrator account, every website is susceptible to authentication and session management flaws. All too often, fingers point toward typical website functions like logout, forgotten password retrieval, and account update procedures when problems with authentication and session management arise.
Custom applications have increased risk. In fact, many instances of authentication and session management flaws occur when the code includes custom methods for validating user names and passwords and/or homegrown techniques for handling cookies or session tokens. Session hijacking is a good example of the trouble that can crop up when authentication and session management flaws reside within your application.
Using widely accepted mechanisms for user authentication and session management is a good, preventative start. Additionally, you can take these steps to protect your application from these vulnerabilities.
- Use https:// encryption on every page with form fields and store credentials in encrypted format and limit browser caching so hitting the back button doesn't grant unwanted parties access or visibility.
- Make sure users can logout from every page within the application and set short visitor sessions and force visitors to time out more often.
- Limit unsuccessful login attempts and require users to verify old password credentials when establishing new ones.
Related Articles
This article is filed under PCI Compliance & Security and has the following keyword tags: secure, hacking, SQL, security risk.
