OWASP Top 10: how to discover vulnerabilities in your Java applications

Securing your web application against outside threats can seem a daunting task. Where do you start? One good approach is to start with the top 10 security issues in web applications (commonly called the OWASP TOP 10). In this article, we’ll describe each vulnerability. You’ll also learn how Kiuwan uses rules to identify each of these vulnerabilities in your code.

java vulnerabilitiesWhat’s OWASP Top 10?

OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate and maintain applications that can be trusted.

OWASP is an international non-profit organization dedicated to analyzing, documenting and spreading the principles for the safe and vulnerability-free software development. They produce a document called OWASP Top 10. According to OWASP, “The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code“.

How can I detect vulnerabilities in my application?

The origin of OWASP vulnerabilities can be in any component involved in a web application production system, such as servers, network, and connection security, accesses to related systems, etc. However, most of them can be prevented by writing source code which is secure and protected against potential threats. Kiuwan may help to detect insecure code that could be corrected to prevent a security problem in the future. Let’s review the OWASP TOP TEN and see how Kiuwan rules can identify these vulnerabilities in the coding phase:

  • A1 Injection. 

    Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

In addition, there are several Kiuwan rules to verify that your code is not vulnerable to the most common security problem:

    • OPT.JAVA.SEC_JAVA.LdapInjectionRule: Avoid non-neutralized user-controlled input in LDAP search filters.
    • OPT.JAVA.SEC_JAVA.SqlInjectionRule: Avoid SQL code formed with non-neutralized user input. More.
    • OPT.JAVA.SEC_JAVA.CommandInjectionRule: Avoid non-neutralized user-controlled input composed in a SO command.


To learn more about the #1 security issue, watch this tutorial:


  • A2 Broken authentication and session management

    Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys or session tokens, or to exploit other implementation flaws to assume other users’ identities.

However, Kiuwan provides several rules to verify the correct use of Java sessions and authentication:

    • OPT.JAVA.SEC_JAVA.RequestParametersInSessionRule: Request parameters should not be passed into Session without sanitizing.
    • OPT.JAVA.SEC_JAVA.InsufficientSessionExpirationRule: Check if that session expiration interval is positive and if it does not exceed a limit.
    • OPT.JAVA.SEC_JAVA.AvoidJ2EENonSerializableObjectsStored: Avoid non-serializable objects stored in session in J2EE applications.
    • OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule: Many web sites use SSL for authentication, but then either revert back to non-SSL for subsequent communication or have parts of the site that can still be accessed via non-SSL. This leaves the session cookie (i.e. JSESSIONID) vulnerable to session hijacking attacks. To prevent this, session cookies can be created with the “Secure” flag, which ensures that the browser will never transmit the specified cookie over non-SSL.
    • OPT.JAVA.SEC_JAVA.AcegiRunAsAuthenticationReplacementRule: Using the Run-As authentication replacement feature in Acegi can lead to a privilege escalation vulnerability.


  • A3 Cross-site scripting (XSS)

    XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

So, most rules of the previous point prevent cross-site scripting problems. But Kiuwan provides more:

    • OPT.JAVA.SEC_JAVA.CrossSiteScriptingRule: Improper neutralization of input during web content generation (Cross-site Scripting, XSS).
    • OPT.JAVA.SEC_JAVA.UnsafeCookieRule: HttpOnly, for example, could mitigate some CSRF (cross-site request forgery) issues as it makes more difficult for the attacker to capture sensitive cookies from client-side code generated by exploiting an XSS vulnerability in a web application.
    • OPT.JAVA.SEC_JAVA.HttpSplittingRule: Improper neutralization of CR/LF Sequences in HTTP headers.


  • A4 Insecure direct object references

    A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory or database key. So, without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Therefore, code application should protect unauthorized data access. Kiuwan helps with these rules:

    • OPT.JAVA.SEC_JAVA.PathTraversalRule: Software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location outside the restricted directory.
    • OPT.JAVA.SEC_JAVA.AnonymousLdapBindRule: Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to access unauthorized records. Executing LDAP queries under an anonymous bind, effectively without authentication, can allow an attacker to abuse a poorly configured LDAP environment.


  • A5 Security misconfiguration

    Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. So, secure settings should be defined, implemented and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Preventing this vulnerability requires paying attention to the source code, but you can also keep in mind:

    • OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule: Avoid misconfiguring security properties in web.xml descriptor. The rule checks 7 common misconfigurations in web.xml descriptors:
      • No default error pages for 404/500 error codes and for uncaught exceptions.
      • No methods in security constraints.
      • Configure SSL for protected areas.
      • Send session ID under SSL only.
      • Send session cookies with the HttpOnly flag set.
      • Use cookies, not URL rewriting, to exchange session IDs with browsers.
      • Expire sessions with no too large timeouts.
    • OPT.JAVA.SEC_JAVA.AcegiInsecureChannelMixingRule. Acegi Misconfiguration – Insecure Channel Mixing. Allowing users to jump between HTTP and HTTPS leaves the application vulnerable to session hijacking.


  • A6 Sensitive data exposure

    Many web applications do not properly protect sensitive data, such as credit cards, tax IDs and authentication credentials. Therefore, attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

Consequently, to protect sensitive data exposure, you must use secure protocols, like HTTPS. Kiuwan can discover misconfigurations with rules like OPT.JAVA.SEC_JAVA.AcegiInsecureChannelMixingRule or OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule.

  • A7 Missing function level access control

    Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when you access each function. If requests are not verified, attackers will be able to forge them in order to access functionality without proper authorization.

Unfortunately, there is no reliable way of ensuring that each function is accessed by the appropriate user (based on their permission level), reviewing only the source code. So, this vulnerability, which depends closely on the functional requirements, shall be verified by functional and safety tests.


  • A8 Cross-site request forgery (CSRF)

    A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information to a vulnerable web application. However, this allows the attacker to force the victim’s browser to generate requests considered as legitimate requests from the victim by the vulnerable application.

In addition, as we commented in A3 and A5, Kiuwan can detect misconfigurations as:

    • OPT.JAVA.SEC_JAVA.UnsafeCookieRule: HttpOnly, for example, could mitigate some CSRF (cross-site request forgery) issues as it makes more difficult for the attacker to capture sensitive cookies from client-side code generated by exploiting an XSS vulnerability in a web application.


  • A9 Using components with known vulnerabilities

    Components, such as libraries, frameworks and other software modules, almost always, run with full privileges. When a vulnerable component exploits, such an attack can facilitate serious data loss or server takeover. To clarify, applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

Further, Kiuwan detects and informs you about the use of dangerous J2EE API:

    • OPT.JAVA.SEC_JAVA.ESAPIBannedRule: OWASP ESAPI Secure Coding Guidelines (ESAPI SCG) includes a set of banned APIs in a J2EE framework and recommends replacing them by equivalent, more secure replacements.


  • A10 Unvalidated redirects and forwards

    Web applications frequently redirect and forward users to other pages and websites, And further, they use untrusted data to determine the destination pages. However, without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.

For example, A9 uses the same rule as here:

    • OPT.JAVA.SEC_JAVA.ESAPIBannedRule: Avoid dangerous J2EE API, use replacements from security-focused libraries (like OWASP ESAPI).
      • BAN011 – ServletResponse.sendRedirect(), replace by HTTPUtilities.safeSendRedirect().
      • BAN012 – RequestDispatcher.forward(), replace by HTTPUtilities.safeSendForward().


You can start using Kiuwan without charge today. Simply request a free trial, and discover whether your code is free of vulnerabilities right away. Or, to learn more about security vulnerabilities and how to eliminate them, head over to OWASP and have a look at their insecure demo application called WebGoat. Take a shot at analyzing the Java source code of WebGoat to see how many vulnerabilities you can find.