i Finding vulnerabilities in source code(Java) – All things in moderation

Finding vulnerabilities in source code(Java)

1. Introduction

We will then look at some of the most popular web development languages to identify the ways in which an application acquires user-submitted data (through request parameters, cookies, and so on). We will also see how an application interacts with the user session, the potentially dangerous APIs that exist within each language, and the ways in which each language’s confi guration and envi-ronment can affect the application’s security. This will provide a way to traceuser-controllable data from its entry point to the application as well as provide some per-language context to assist with the other methodology steps.
Finally, we will discuss some tools that are useful when performing code review.

2. The Java Plaform

* Identifying User-Supplied Data

Java applications acquire user-submitted input via the javax.servlet.http. HttpServletRequest interface, which extends the javax.servlet.ServletRequest interface. These two interfaces contain numerous APIs that web applications can use to access user-supplied data. The APIs listed in Table below can be used to obtain data from the user request.

API Description
getParameter
getParameterNames
getParameterValues
getParameterMap
Parameters within the URL query string and the body of a POST request are stored as a map of String names to String values, which can be accessed using these APIs.
getQueryString Returns the entire query string contained within the request and can be used as an alternative to the getParameter APIs.
getHeaders
getHeaderNames
getRequestURI
getRequestURL
HTTP headers in the request are stored as a map of String names to String values and can be accessed using these APIs.
getRequestURI
getRequestURL
These APIs return the URL contained within the request, including the query string.
getCookies Returns an array of Cookie objects, which contain details of the cookies received in the request, includ-ing their names and values.
getRequestedSessionId Used as an alternative to getCookies in some cases; returns the session ID value submitted within the request.
getInputStream
getReader
These APIs return different representations of the raw request received from the client and there-fore can be used to access any of the information obtained by all the other APIs.
getMethod Returns the method used in the HTTP request.
getProtocol Returns the protocol used in the HTTP request.
getServerName Returns the value of the HTTP Host header.
getRemoteUser
getUserPrincipal
If the current user is authenticated, these APIs return etails of the user, including his login name. If users can choose their own username during self-registra- tion, this may be a means of introducing malicious input into the application’s processing.
– Session Interaction

Java Platform applications use the javax.servlet.http.HttpSession interface to store and retrieve information within the current session. Per-session storage is a map of string names to object values. The APIs listed in Table 2 are used to store and retrieve data within the session.

API Description
setAttribute
putValue
Used to store data within the current session.
getValue
getAttributeNames
getValueNames
Used to query data stored within the current session.
* Potentially Dangerours APIs

This section describes some common Java APIs that can introduce security vulnerabilities if used in an unsafe manner.

– File Access

The main class used to access files and directories in Java is java.io.File .
Whichever form of the constructor is used, path traversal vulnerabilities may exist if user-controllable data is passed as the fi lename parameter without checking for dot-dot-slash sequences. For example, the following code opens a fi le in the root of the C:\ drive on Windows:

String userinput = “..\\boot.ini”;
File f = new File(“C:\\temp”, userinput);

The classes most commonly used for reading and writing fi le contents in Java are:

 java.io.FileInputStream
 java.io.FileOutputStream
 java.io.FileReader
 java.io.FileWriter

Code vulnerable path traversel:

String userinput = “..\\boot.ini”;
FileInputStream fis = new FileInputStream(“C:\\temp\\” + userinput);
– Database Access

The following are the APIs most commonly used for executing an arbitrary string as a SQL query:

 java.sql.Connection.createStatement
 java.sql.Statement.execute
 java.sql.Statement.executeQuery

If user-controllable input is part of the string being executed as a query, it is probably vulnerable to SQL injection. For example:

String username = “admin’ or 1=1--”;
String password = “foo”;
Statement s = connection.createStatement();
s.executeQuery(“SELECT * FROM users WHERE username = “’ + username +
“’ AND password = “’ + password + “’”);

The following APIs are a more robust and secure alternative to the ones previ-ously described. They allow an application to create a precompiled SQL statement and set the value of its parameter placeholders in a secure and type-safe way:

java.sql.Connection.prepareStatement  
java.sql.PreparedStatement.setString  
java.sql.PreparedStatement.setInt  
java.sql.PreparedStatement.setBoolean  
java.sql.PreparedStatement.setObject  
java.sql.PreparedStatement.execute  
java.sql.PreparedStatement.executeQuery

If used as intended, these are not vulnerable to SQL injection. For example:

String username = “admin’ or 1=1--”;
String password = “foo”;
Statement s = connection.prepareStatement(
“SELECT * FROM users WHERE username = ? AND password = ?”);
s.setString(1, username);
s.setString(2, password);
s.executeQuery();

results in a query that is equivalent to the following:

SELECT * FROM users WHERE username = ‘admin’’ or 1=1--’ AND
password = ‘foo’
– Dynamic code execution

The Java language itself does not contain any mechanism for dynamic evaluation of Java source code, although some implementations (notably within database products) provide a facility to do this.

– OS command

The following APIs are the means of executing external operating system commands from within a Java application:

 java.lang.runtime.Runtime.getRuntime
 java.lang.runtime.Runtime.exec

If the user can fully control the string parameter passed to exec , the application
is almost certainly vulnerable to arbitrary command execution. For example,
the following causes the Windows calc program to run:

String userinput = “calc”;
Runtime.getRuntime.exec(userinput);

However, if the user controls only part of the string passed to exec , the appli-cation may not be vulnerable. In the following example, the user-controllable data is passed as command-line arguments to the notepad process, causing it to attempt to load a document called | calc :

String userinput = “| calc”;
Runtime.getRuntime.exec(“notepad “ + userinput);

The exec API itself does not interpret shell metacharacters such as & and | ,so this attack fails.

– URL Redirection

The following APIs can be used to issue an HTTP redirect in Java:

javax.servlet.http.HttpServletResponse.sendRedirect
 javax.servlet.http.HttpServletResponse.setStatus
 javax.servlet.http.HttpServletResponse.addHeader

You should also be sure to review any uses of the setStatus and addHeaderAPIs. Given that a redirect simply involves a 3xx response containing an HTTP Location headeran application may implement redirects using these APIs.

– Configuration the Java Environment

The web.xml fi le contains confi guration settings for the Java Platform environment
and controls how applications behave.
If an application is using container-man-aged security, authentication and authorization are declared in web.xml against each resource or collection of resources to be secured, outside the application code.

Source : the web apllication hacker handbook.

Leave a Reply