Untrusted user input is, in practice, all user input. It originates from the client but can reach the server through many different channels. Some source of user input for a JSP server include, but are not limited to:

• the parameter string portion of the request URL,
• data submitted by HTML forms through POST or GET requests,
• queries to databases,
• environment variables set by other processes.

The problem with user input is that it can be interpreted by the server-side applications and thus an attacker can craft the incoming data so as to control some vulnerable aspect of the server. These vulnerabilities often manifest themselves as points of access to data identified by user-supplied qualifiers, or through execution of external functionality.

Naturally, JSP can make calls to native code stored in libraries (through JNI) and execute external commands. The class Runtime provides the exec() method which interprets its first argument as a command line to execute in a separate process. If parts of this string must be derived from user input, this input must first be filtered to ensure that only the intended commands are executed, with only the intended arguments.

In addition, it is possible under certain circumstances for an attacker to modify environment variables in the server environment and in this way to affect the execution of external commands, for example by changing the PATH variable to point to a malicious program disguised under the name of the program called by Runtime's exec(). To avoid this risk it is advisable to always set the environment explicitly before making external calls.

In addition, access to files, databases, or other network connections must NOT depend on unvalidated user input. This is especially true for SQL queries. The following JSP construct accessing the JDBC API is highly insecure, since an attacker can embed command separation characters in the submitted input and thus execute unwanted commands on the SQL server:

<!-- Some code here to open a SQL connection -->
  <%
    Statement stmt = connection.getStatement();
    String query = "SELECT * FROM EMPLOYEE_RECORDS WHERE USER = " +
      request.getParameter("employee");
    ResultSet result = Statement.executeQuery(query); 
  %>

If employee contains a semicolon for instance, as in

  http://server/db.jsp?
    employee=bob;SELECT%20*%20FROM%20SYSTEM_RECORDS

the attacker can gain access to (or damage) parts of the database to which they are not entitled (assuming the Web server has privileges to access these parts). In the example attack above, some SQL servers will ignore the whole query, but others will proceed to execute the two commands.

Mitigation of these problems is achieved through appropriate input validation.

Page: 1 2 3 4 NEXT