It just wouldn’t be the new year without a “best of” or “top ten” list, and we’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.
Before you stop reading and get back to your _____ (insert whatever project you had planned for today), wait! You have our assurance that this won’t be too jargon-y. We’ve deliberately stopped the heavy tech talk here, and we’ll translate all the application security risk verbiage into usable, understandable terms for your growing enterprise.
So here they are, without further ado, 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 the network environment 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. Impress your IT staff by nodding knowingly if he mentions a Code Injection, Command Injection, or XPATH Injection around the water cooler.
Some of the best, protective measures (ask your security expert about these) for Injection Attacks include:
- Input Validation – cleanse your input data
- Human Verification ie CAPTCHA
- Restrictive Privileges when connecting applications to DBs and other proprietary systems
- Vague Error Messages give 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 Web site. 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).
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 tested. Test, test, test, and then test again before launching or introducing Web site enhancements
3) Cross Site Request Forgery – CSRF
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 Web site.
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 or forum
- Change passwords, emails, login credentials effectively terminating access
- Submit a users email 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 and social media rely heavily on user-generated content. If your application has Social Web components, 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 DB 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, each and every Web site is susceptible to authentication and session management flaws. All too often, fingers point toward typical Web site 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 code includes custom methods for validating user names and passwords and/or “home grown” 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 grand 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
That’s your top five for 2010. From our company to yours – happy holidays and a hack-free New Year!
A version of this article was published in eCommerceDeveloper on 12/23/09.
This entry was posted on Wednesday, December 23rd, 2009 at 8:00 am and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
