Created by James Hurrell on Apr 16, 2021

User Input Security tab

Note that in CAST AIP 8.3.0 - 8.3.9, the User Input Security tab contains options that enable you to add custom sanitization, input and target methods. Even though these options exist and can be used, they do not function and any custom methods that are added will be ignored in an analysis. The options will be removed in CAST AIP 8.3.10.

Notes

  • The options in this tab are valid for ALL Analysis Units defined in the current Application.
  • User Input Security is only run when you Generate a Snapshot.
Introduction

In order to detect User Input Security flaws, CAST provides an optional analysis feature that implements a dataflow algorithm to detect variables that flow from the user down to a critical resource without prior sanitization, allowing hackers to send them data that will harm IT applications (security vulnerabilities).

As mentioned by the Common Weakness Enumeration (CWE), SANS Institute and OWASP, Improper Input Validation is the top group of web programming errors that can lead to security vulnerabilities.

Improper Input Validation is defined by the CWE follows:

"When software fails to validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution."

The User Input Security feature in the CAST Management Studio enables users to detect improper user input validation in the application's source code, which can lead to the following security vulnerabilities:

  • SQL Injection (CWE-89)
  • Cross-Site Scripting (CWE-79)
  • LDAP Injection (CWE-90)
  • OS Command Injection (CWE-78)
  • XPath Injection (CWE-91)
  • Path Manipulation (CWE-99)
  • Avoid Log forging vulnerabilities (CWE-117)
  • Avoid uncontrolled format string (CWE-134)
  • Trust Boundary Violation (CWE-501)
  • Sensitive Cookie in HTTPS Session Without 'Secure' Attribute (CWE-614)
  • Use of hard-coded credential (java, C#, VB.Net languages) (CWE-798)

Once the source code analysis is complete, the results (i.e. the security vulnerabilities) can be viewed in the CAST Engineering Dashboard as standard Quality Rules. As dataflow-based Quality Rules, the flow of the user input can be tracked in the CAST Engineering Dashboard with bookmarked source code.

CAST currently supports User Input Security checks for the following technologies:

  • JEE (using the JEE Analyzer extension)
  • .NET (using the .NET Analyzer extension)
Enabling User Input Security checks

To enable User Input Security checks in your application analysis simply add in the technology you want to target:

This is all that is required in order to obtain results at the end of an analysis - this is due to the predefined methods that are supported out of the box and the automatic blackboxing that is used. Please see doc.castsoftware.com (search for "User Input Security - Predefined Methods" for more information about these methods).

Configuring blackbox methods

Please see doc.castsoftware.com (search for "User Input Security - configuring blackbox methods" for more information about how to configure the User Input Security feature to correctly take into account data flow to blackboxed methods (i.e. to methods that reside in code that is "outside" the scope of the analysis).

Notes
  • Please note the following behavior of the User Input Security feature when working with ASP.NET:
    • ASP.NET page validation mechanism (<%@ Page validateRequest="true" %> etc) is not taken into account. Therefore inputs can be considered as dangerous for CSS although they are not. Note that even if they are not dangerous, Microsoft recommends validating all entries:
      "It is strongly recommended that your application explicitly check all inputs it uses in addition to the request validation performed by ASP.NET. The request validation feature cannot catch all attacks, especially those crafted specifically against your application logic.
      http://msdn.microsoft.com/en-us/library/system.web.httprequestvalidationexception.aspx"
    • <asp:RegularExpressionValidator> and <asp:CustomValidator> applied to the control are considered as sanitization methods. The actual control is not validated, i.e. there is no check that the control is actually correct.
    • If textbox and validators of this textbox are not in the same aspx or ascx page, the User Input Security  feature will not find any security issue.
  • Data flow paths - please remember that data can flow via a variety of different paths as such multiple violations may be flagged.
  • Missing .NET dependencies - Please ensure that you have resolved all missing .NET dependencies in the CAST Delivery Manager Tool, otherwise User Input Security results may be erroneous or missing.
  • Cross site scripting vulnerabilities in J2EE - Cross-site scripting vulnerabilities due to dynamic expressions can be detected correctly by CAST - this is specifically with regard to the use of the <%= syntax as shown below:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head> <meta http-equiv="content-type" content="text/html; charset=windows-1250">  <meta name="generator" content="PSPad editor, www.pspad.com">  <title></title>   </head> <body>  <p>You have choosen author <%= request.getParameter("author") %></p></body></html>
  • Security vulnerabilities in Java code embedded in JSP files can be detected correctly by CAST. Take for example the scriptlet embedded in the following JSP file. This is detected by CAST as an SQL injection flaw:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"            pageEncoding="ISO-8859-1"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><%@page import="java.sql.Connection"%><%@page import="java.sql.DriverManager"%><%@page import="java.sql.ResultSet"%><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Example 4 in Tutorial for Visual Builder</title></head><body><%String sName = request.getParameter("website");out.print(sName);Class.forName("oracle.jdbc.OracleDriver");Connection connection=DriverManager.getConnection("jdbc:oracle:thin:@CASTASRV:1521:O92CASTA"  ,"CASTPUBS", "CASTPUBS");ResultSet rs=connection.createStatement().executeQuery(sName); %></body></html>
  • Security vulnerabilities located in code that is split across Analysis Units can be detected correctly by CAST. If the dependency between these Analysis Units is configured correctly, then the User Input Security feature can follow the call stack between these Analysis Units and detect the vulnerabilities.

    Take for example the situation where you have two Analysis Units containing your J2EE application code: Callee and Caller. In Caller, there is an invalidated user input value concerning the username which invalidates the query. This invalidated query has been propagated to the Callee Analysis Unit which results in a flaw in the Callee Analysis Unit:
// Callerimport java.sql.SQLException;import javax.servlet.ServletRequest;public class Caller {public static void main(String[] args){Callee.main(args);}void mySqlInjection(ServletRequest req) throws SQLException{String username=req.getParameter("username");String query= "select * from Users where username='"+username +"'";new Callee().exec(query);}}// Calleeimport java.sql.SQLException;import java.sql.Statement;public class Callee {public Statement statement= null;public static void main(String[] args){Callee.main(args);}void exec(String query) throws SQLException {statement.executeQuery(query);}}
  • Security vulnerabilities in "blackbox" methods (for example javax.servlet.ServletRequest.getParameter) are detected even when the name of the JAR providing the method (and which is defined in an Using the Environment Profile Manager) is altered - in the above example method, changing the servlet-api-2.5.jar to servlet-api-test.jar will not affect the result.
  • JSP inclusions: when a violation is detected in the code of an included file, the User Input Security feature will identify the position of the violation as being inside the included file but will attach the violation to the container file.

    As such, the source code displayed in the CAST Engineering Dashboard is from the included file, but the steps (in the path browser) are related to the container file. For example:

    Example_Main.jsp--> <%@ include file='Example_include.jsp' %>

    If the User Input Security feature detects the violation in the 'Example_include.jsp' file, the container Example_Main.jsp will be reported as containing a violation, but the source code displayed in the CAST Engineering Dashboard will be the content of Example_include.jsp.

  • It is no longer necessary to activate the Inference Engine when using the User Input Security feature: - the same results will be achieved. This is particularly useful for large analyses which can hit an out of memory error.

CAST Website