OWASP Top Ten: What you need to know Part 2

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

Last week, we looked at how Klocwork handles three items on the OWASP Top 10, today we’ll examine two more...

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

[Read the first part here]

The OWASP Top 10 is a list of common and exploitable security vulnerabilities in code that’s derived from over five hundred thousand issues being researched today. Knowing this list and how to protect your code helps minimize risk for both yourself and your users. Last week, we looked at how Klocwork handles three items and today, we’ll examine two more.

A5 – Security Misconfiguration

If your application reveals information about itself, such as account information, stack traces, or unused web pages, then it falls under this type of vulnerability. Typically, these issues are related to how your application handles software errors: if exception handling is too generic or, even worse, used to control the flow of your application, it’s possible that sensitive information can “bubble up” to the UI. This issue is particularly troublesome as it requires explicit testing across all potential attack vectors to discover and neutralize.

Klocwork has several ways of reducing your time testing for this, including finding code that prints data to System.err, has a return statement in a finally block, or contains this type of issue:

protected void doPost(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, IOException
    String debug = req.getParameter("debug");
    File file = File.createTempFile("tempfile", ".tmp");
    if (debug.equals("true")) {
        resp.getOutputStream().print("Using " + file.toString());

The name of the temporary file, tempfile, is printed to the output stream within the if block. The SV.IL.FILE checker reports this as a potential leak of sensitive information since an attacker can use the file name to predict the location of other files on the system.

A6 – Sensitive Data Exposure

This vulnerability occurs when sensitive data is left open for access due to weak cryptographic keys and passwords, unencrypted data, or the transmission of data in clear text form. For example, an attacker could monitor an open wireless network to steal a user’s session cookie from a site that doesn’t use SSL encryption, allowing the hijacking of that user’s session.

Klocwork checks against different causes of this vulnerability, such as empty passwords or plain-text passwords, including one most people don’t think of: random number generation:

public String generateRandomSessionId() {
    Random random = new Random();
    return ("sessionId=" + random.nextInt(2000000000));

public String generateRandomNumberUsingMath() {
    double randomNum = Math.random();
    return (String.valueOf(randomNum));

In the first method, a random number is used to generate a session ID. The second method generates a random number for use elsewhere. The issue with using java.util.Random() in this way is that if two instances of Random are created with the same seed and sequence of calls, both instances will generate the exact same results. An attacker can use this determinism to create an attack vector, counting on finding the same number that the application is using. Klocwork reports an SV.RANDOM issue in both methods so that you can choose to find a more secure way of generating random numbers, such as using java.security.SecureRandom() instead.

Next week, we’ll wrap up this series with the final items on OWASP’s list and provide some additional resources for you to improve the security of your code. Read the next part here.

Related Posts

Leave a Reply

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

Scroll to top