OWASP Top 10: Application Security Risks

Revisiting the OWASP Top 10 Application Security Risks 2013 Report

Your chance to contribute to the OWASP Top 10 2016 report expires July 20th. Don’t miss this rare opportunity to influence best practices in web operations. For those of you unfamiliar with OWASP and their report, please read on.The Open Web Application Security Project (OWASP) is a non-profit community of software developers, engineers and freelancers that provides resources and tools for web application security. Every three years, OWASP releases a report on the ten most critical web application security risks. The OWASP Top 10 raises awareness of the challenges organizations face ensuring web application security in a rapidly changing application security environment. Ahead of the new report, let’s reflect on the Open Web Application Security Project Top 10 from 2013. This is a high-level overview of what each security risk means.

OWASP Top 10: Application Security

A1 – Injection

Under the right circumstances, third parties can inject a small quantity of code to trick an application into performing unintended actions. The most common (and most well-known) injection attack is an SQL Injection, where an attacker inserts an SQL statement into an application to, for example, dump the database contents onto the attacker. OWASP recommends you check incoming requests to determine their trustworthiness, and keep untrusted data separated from the systems that run your application.

A2 – Broken Authentication and Session Management

You know the user credentials of people accessing your systems, but do you know who is actually behind the keyboard? Hackers can hijack user identities and hide behind a genuine user ID to gain easy access to your data and programs. Implement strong authentication and session management controls and ensure your users are who they say they are.

A3 – Cross-Site Scripting (XSS)

An XSS vulnerability elevates the trust a user has given to a specific site to also include a second, potentially malicious, site. When the user permits certain actions to run on a site they believe to be secure, this can allow a malicious actor to modify the intended web page in interesting ways (resulting in the dissemination of sensitive data or the spread of malware). XSS vulnerabilities are common, but should be fairly simple to remediate. Separate untrusted, user-inputted data from active content within your webpage (for example, hyperlinks and the like).

A4 – Insecure Direct Object References

Most websites store user records based on a key value that the user controls (such as a username or email address). When a user inputs their key, the system retrieves the corresponding information and presents it to the user. An Insecure Direct Object Reference occurs when an authorization system fails to prevent one user from gaining access to another user’s information. OWASP recommends you secure your authorization channels by implementing access control checks for each user-accessible object (such as files, webpages, and other information).

A5 – Security Misconfiguration

Security Misconfiguration is a general reference to application security systems that are incomplete or poorly managed. Security misconfiguration can occur at any level and in any part of an application, and thus is both highly common and easily detectable. There are myriad ways in which you may be vulnerable to software misconfiguration, so be sure to read up on OWASP’s vulnerability report.

A6 – Sensitive Data Exposure

Unintended data display is a serious problem to anyone operating a web application that contains user data. Although OWASP points out that the full perils of insecure data extend well beyond the scope of the OWASP Top 10, they do recommend a handful of minimum steps, including to encrypt all sensitive data at rest and in transit and discard sensitive data as soon as you can.

A7 – Missing Function Level Access Control

A missing or improperly configured user access control system can grant users the ability to perform functions above their level (this vulnerability has some overlap with A4 – Insecure Direct Object Reference). Although it can be difficult to avoid security vulnerabilities in function level access control systems, OWASP advocates several methods to secure your applications (including the establishment of “deny-by-default” rules to only allow function access to users you know and trust).

A8 – Cross-Site Request Forgery (CSRF)

An CSRF attack involves sending a request to a vulnerable web application using a trusted user’s credentials. Although an untrusted third party generates the request, the attacker uses the victim’s browser to piggy-back on the victim’s credibility. A CRSF attack exploits a trusted user’s authentication to trick a system into performing a malicious action. To reduce risk of forgery, OWASP suggests that you include a unique, hidden token in every web request.

A9 – Using [Open Source Software] Components with Known Vulnerabilities

Open source development practices drive innovation and reduce development costs. But despite the benefits of open source software, the 2016 Future of Open Source Survey found that significant challenges remain in security and management practices. It is critical that organizations gain visibility into and control of open source software in their applications and Docker containers.

 A10 – Un-validated Redirects and Forwards

When a web application accepts unverified input that affects URL redirects, third parties can redirect users to malicious websites. In addition, hackers can alter automatic forwarding routines to gain access to sensitive information. The Open Web Application Security Project suggests you avoid using redirects and forwards whenever possible, but if abstinence is unrealistic, don’t let users affect the destination.

All of these vulnerabilities are interwoven, and one vulnerability can lead to another. It is vital that you have an understanding of the application security landscape and are taking steps to reduce your risk. Want to know more? The OWASP website is full of useful information. Black Duck supports the open source community, and recently launched Black Duck Research and the Security Advisory Board to promote application security research world-wide.

The State of Open Source Security

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Black Duck and the Red Hat Summit 2016

| Jun 23, 2016

June 27-30 @ Moscone Center, San Francisco Next week, more than 4,000 members of the open source community will descend on San Francisco’s Moscone Center for Red Hat Summit 2016. Over the course of three jam-packed days, developers and executives from across the world will gather to view and

| MORE >

A Day In The Life Of A Black Duck Intern

| Jun 2, 2016

(Or, How I Learned to Stop Worrying and Love the Duck Suit) While applying to work as a Black Duck intern in marketing, I spoke with several employees who emphasized the sense of culture and community within the company. Everyone I spoke with at Black Duck also assured me that I’d be working on

| MORE >