Checker BasicInjection

belongs to group Basic
Identify simple security injections

Frameworks supported by this checker

  • java up to 11
  • android up to API level 28
  • dotnet

Warnings generated by this checker

  • AddressInjectionIntoFieldWarning: tainted data flows into a field annotated as @AddressTrusted [ CWE74 ]
  • AddressInjectionWarning: tainted data might flow into the creation of an Internet address [ CWE74 ]
  • CodeInjectionIntoFieldWarning: tainted data flows into a field annotated as @CodeTrusted [ CWE94 ]
  • CodeInjectionWarning: tainted data might flow into a script execution routine [ CWE94 ]
  • CommandInjectionIntoFieldWarning: tainted data flows into a field annotated as @CommandTrusted [ CWE78 ]
  • CommandInjectionWarning: tainted data might flow into a command execution routine [ CWE78 ]
  • ControlInjectionIntoFieldWarning: tainted data flows into a field annotated as @ControlTrusted [ CWE74 ]
  • ControlInjectionWarning: tainted data might flow into a control modifying method [ CWE74 ]
  • DOSInjectionIntoFieldWarning: tainted data flows into a field annotated as @DenialTrusted [ CWE74 ]
  • DOSInjectionWarning: tainted data might flow into a method that makes the computer sleep or wait [ CWE74 ]
  • DeviceInjectionIntoFieldWarning: tainted data flows into a field annotated as @AddressTrusted [ CWE74 ]
  • DeviceInjectionWarning: tainted data might flow into the creation of an Internet address [ CWE74 ]
  • EvalInjectionIntoFieldWarning: tainted data flows into a field annotated as @EvalTrusted [ CWE95 ]
  • EvalInjectionWarning: tainted data might flow into code that dynamically evaluates an expression [ CWE95 ]
  • GenericInjectionIntoFieldWarning: tainted data flows into a field annotated as @Trusted [ CWE74 ]
  • GenericInjectionWarning: tainted data might flow into a trusted parameter [ CWE74 ]
  • HttpResponseInjectionIntoFieldWarning: tainted data flows into a field annotated as @HttpResponseTrusted [ CWE113 ]
  • HttpResponseSplittingWarning: tainted data might flow into an HTTP response [ CWE113 ]
  • LDAPAttributeInjectionIntoFieldWarning: tainted data flows into a field annotated as @AttributeTrusted [ CWE90 ]
  • LDAPAttributeInjectionWarning: tainted data might flow into an LDAP attribute [ CWE90 ]
  • LDAPFilterInjectionIntoFieldWarning: tainted data flows into a field annotated as @FilterTrusted [ CWE90 ]
  • LDAPFilterInjectionWarning: tainted data might flow into the filter of an LDAP search [ CWE90 ]
  • LogForgingWarning: tainted data might flow into a log [ CWE117 ]
  • LogInjectionIntoFieldWarning: tainted data flows into a field annotated as @LogTrusted [ CWE117 ]
  • MessageInjectionIntoFieldWarning: tainted data flows into a field annotated as @MessageTrusted [ CWE319 ]
  • MessageInjectionWarning: tainted data might flow into a message sent by the device [ CWE319 ]
  • PathInjectionIntoFieldWarning: tainted data flows into a field annotated as @PathTrusted [ CWE22 ]
  • PathInjectionWarning: tainted data might flow into a file path creation method [ CWE22 ]
  • ReflectionInjectionIntoFieldWarning: tainted data flows into a field annotated as @ReflectionTrusted [ CWE470 ]
  • ReflectionInjectionWarning: tainted data might flow into a reflection method [ CWE470 ]
  • ResourceInjectionIntoFieldWarning: tainted data flows into a field annotated as @ResourceTrusted [ CWE74 ]
  • ResourceInjectionWarning: tainted data might flow into a variable annotated as @ResourceTrusted [ CWE74 ]
  • SessionInjectionIntoFieldWarning: tainted data flows into a field annotated as @SessionTrusted [ CWE501 ]
  • SessionInjectionWarning: tainted data might flow into a session [ CWE501 ]
  • SqlInjectionIntoFieldWarning: the request of a servlet might flow into a field annotated as @SqlTrusted, unsanitized [ CWE89 ]
  • SqlInjectionWarning: tainted data might flow into an sql query, unsanitized [ CWE89 ]
  • TrustBoundaryViolationIntoFieldWarning: tainted data flows into a field annotated as @BoundaryTrusted [ CWE501 ]
  • TrustBoundaryViolationWarning: tainted data might flow into a bundle of information that should not contain tainted pieces of information [ CWE501 ]
  • URLInjectionIntoFieldWarning: tainted data flows into a field annotated as @UrlTrusted [ CWE74 ]
  • URLInjectionWarning: tainted data might flow into a URL creation [ CWE74 ]
  • XPathInjectionIntoFieldWarning: tainted data flows into a field annotated as @XPathTrusted [ CWE643 ]
  • XPathInjectionWarning: tainted data might flow into an xpath creation method [ CWE643 ]
  • XSSInjectionIntoFieldWarning: tainted data flows into a field annotated as @CrossSiteTrusted [ CWE79 ]
  • XSSInjectionWarning: tainted data might flow into a script execution routine [ CWE79 ]

Options accepted by this checker

  • trustDatabase: consider data coming from a database query as trusted
    This option lets Julia consider data coming from database queries as untainted and hence trusted. This is false by default
  • trustDevice: consider data about the specific device as trusted
    This option lets Julia consider data about the specific device running the application as untainted and hence trusted. This is false by default
  • trustEnvironment: consider data coming from the running environment as trusted
    This option lets Julia consider data coming from files or properties as untainted and hence trusted. This is true by default
  • trustExternalStreams: consider data coming from external streams as trusted
    This option lets Julia consider data coming from external streams and sockets as untainted and hence trusted. This is true by default
  • trustUserInput: consider data from servlet requests and console as trusted
    This option lets Julia consider data coming from servlet requests and console input as untainted and hence trusted. This is false by default

Annotations understood by this checker

  • @com.juliasoft.julia.checkers.flows.UntrustedDatabase
  • @com.juliasoft.julia.checkers.flows.UntrustedDevice
  • @com.juliasoft.julia.checkers.flows.UntrustedEnvironment
  • @com.juliasoft.julia.checkers.flows.UntrustedExternalStream
  • @com.juliasoft.julia.checkers.flows.UntrustedUserInput


Description

The most dangerous software errors are due to the injection of user data into sensitive routines, such as database queries, html output to the client or file system access. These attacks are generally known as injection attacks and there is large literature about the risk that they pose to software exposed to uncontrolled user input. The list available at cwe.mitre.org reports explicit examples of such security issues, for instance SQL-injection, OS-command injection, cross-site scripting and open redirect. The unifying aspect of these errors is that user input can flow, unconstrained, into sensitive routines. Hence Julia provides this checker in order to track explicit information flow in the program, from automatically or manually selected source locations into automatically or manually selected sink locations. In this way, Julia allows one to identify potential security errors of the above categories, with a soundness guarantee derived from the use of abstract interpretation, and with the freedom to bend the analysis to specific needs, through the use of code annotations.

Action: Verify that a security error actually corresponds to unconstrained information flow from source locations into sink locations. If this is the case, add a sanitizing algorithm to clean data before it flows into sinks, or use prepared statements for SQL queries rather than free queries built from string concatenation.

This checker is a simpler and faster version of the Injection checker. In particular, this checker is unsound since it finds the most apparent injection attacks, but might miss some complicated attack. If you need to find all possible attacks, please use the sound Injection checker instead. If you only need to find some attacks in short time or for very large programs, then this checker is the right choice.

Specification of source and sink locations
Please refer to the same topic for the Injection checker. Normally, you needn't specify any source or sink location, since Julia will recognize the most frequent locations automatically (see the list of sources natively recognized by Julia).

The most dangerous software errors are due to the injection of user data into sensitive routines, such as database queries, html output to the client or file system access. These attacks are generally known as injection attacks and there is large literature about the risk that they pose to software exposed to uncontrolled user input. The list available at cwe.mitre.org reports explicit examples of such security issues, for instance SQL-injection, OS-command injection, cross-site scripting and open redirect. The unifying aspect of these errors is that user input can flow, unconstrained, into sensitive routines. Hence Julia provides this checker in order to track explicit information flow in the program, from automatically or manually selected source locations into automatically or manually selected sink locations. In this way, Julia allows one to identify potential security errors of the above categories, with a soundness guarantee derived from the use of abstract interpretation, and with the freedom to bend the analysis to specific needs, through the use of code annotations.

Action: Verify that a security error actually corresponds to unconstrained information flow from source locations into sink locations. If this is the case, add a sanitizing algorithm to clean data before it flows into sinks, or use prepared statements for SQL queries rather than free queries built from string concatenation.

This checker is a simpler and faster version of the Injection checker. In particular, this checker is unsound since it finds the most apparent injection attacks, but might miss some complicated attack. If you need to find all possible attacks, please use the sound Injection checker instead. If you only need to find some attacks in short time or for very large programs, then this checker is the right choice.

Specification of source and sink locations
Please refer to the same topic for the Injection checker. Normally, you needn't specify any source or sink location, since Julia will recognize the most frequent locations automatically (see the list of sources natively recognized by Julia).

Examples

Consider the following program:

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.juliasoft.julia.checkers.injection.SqlTrusted;
import com.juliasoft.julia.checkers.injection.Trusted;

@SuppressWarnings("serial")
public class BasicInjection extends HttpServlet {
  private @SqlTrusted Object sqlTrusted;
  private @Trusted Object trusted;
  public String a = "my friend";

  @Override
  protected final void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    processRequest(request, response);
  }

  private void test2(@SqlTrusted String s) {}

  private void test3(@Trusted String s) {}

  private void processRequest(HttpServletRequest request, HttpServletResponse response) throws IOException {
    response.setContentType("text/html;charset=UTF-8");

    String user = request.getParameter("user");

    try (PrintWriter out = response.getWriter()) {
      out.println("User : " + user);
      out.println(user);
      out.println("hello");
      out.println("hello " + a);
    }

    if (user != null)
      test2(user);
    test2("User: " + user);
    test2("hello");
    test2("hello " + a);
    test3(user);
    test3("User: " + user);
    test3("hello");
    test3("hello " + a);
    sqlTrusted = user;
    trusted = user;
    sqlTrusted = "User: " + user;
    trusted = "User: " + user;
    sqlTrusted = "hello";
    trusted = "hello";
    sqlTrusted = "hello " + a;
    trusted = "hello " + a;
  }
}

This checker issues the following warnings:

BasicInjection.java:32: [BasicInjection: XSSInjectionWarning] possible XSS-injection from line 29 into the 0th actual parameter of println
BasicInjection.java:33: [BasicInjection: XSSInjectionWarning] possible XSS-injection from line 29 into the 0th actual parameter of println
BasicInjection.java:39: [BasicInjection: SqlInjectionWarning] possible SQL-injection from line 29 into the 0th actual parameter of test2
BasicInjection.java:40: [BasicInjection: SqlInjectionWarning] possible SQL-injection from line 29 into the 0th actual parameter of test2
BasicInjection.java:43: [BasicInjection: GenericInjectionWarning] possible injection of tainted data from line 29 into the 0th actual parameter of test3
BasicInjection.java:44: [BasicInjection: GenericInjectionWarning] possible injection of tainted data from line 29 into the 0th actual parameter of test3
BasicInjection.java:47: [BasicInjection: SqlInjectionIntoFieldWarning] possible SQL-injection from line 29 into field sqlTrusted
BasicInjection.java:48: [BasicInjection: GenericInjectionIntoFieldWarning] possible injection of tainted data from line 29 into field trusted
BasicInjection.java:49: [BasicInjection: SqlInjectionIntoFieldWarning] possible SQL-injection from line 29 into field sqlTrusted
BasicInjection.java:50: [BasicInjection: GenericInjectionIntoFieldWarning] possible injection of tainted data from line 29 into field trusted

Let us discuss the motivation of such warnings. The parameter read at line 29 is considered as user input. This checker tracks its propagation along the statements of the program and finds out that that user input is printed at lines 32 and 33. Instead, the text printed at lines 34 and 35 does not contain user input, although it is not necessarily a hardcoded constant string. Same reasonings apply to the other warnings.

In this example, the programmer should avoid a direct flow from user input to servlet output, since this allows a cross-site scripting (XSS) attack. User input should never be printed to the servlet output, or at least it must be previously sanitized.

Consider the following program:

using com.juliasoft.julia.checkers.injection;
using System;

using System.IO;
using System.Web;
using System.Web.UI;


namespace DocumentationExamples
{

    public class BasicInjection : Page
    {
        public static void Main(string[] args)
        { }

        [SqlTrusted]
        private object sqlTrusted;
        [Trusted]
        private object trusted;
        public string a = "my friend";
        protected void Page_Load(object sender, EventArgs e)
        {
            ProcessRequest(Request, Response);
        }
        private void Test2([SqlTrusted] string s) { }
        private void Test3([Trusted] string s) { }
        private void ProcessRequest(HttpRequest request, HttpResponse response)
        {
            response.ContentType = "text/html;charset=UTF-8";
            string user = request.Params["user"];
            using (TextWriter p = response.Output)
            {
                p.WriteLine("User : " + user);
                p.WriteLine(user);
                p.WriteLine("hello");
                p.WriteLine("hello " + a);
            }
            if (user != null)
                Test2(user);
            Test2("User: " + user);
            Test2("hello");
            Test2("hello " + a);
            Test3(user);
            Test3("User: " + user);
            Test3("hello");
            Test3("hello " + a);
            sqlTrusted = user;
            trusted = user;
            sqlTrusted = "User: " + user;
            trusted = "User: " + user;
            sqlTrusted = "hello";
            trusted = "hello";
            sqlTrusted = "hello " + a;
            trusted = "hello " + a;
        }
    }
}

This checker issues the following warnings:

DocumentationExamples.cs:34: [BasicInjection: XSSInjectionWarning] Possible XSS-injection from line 31 into actual parameter "value" of method "WriteLine"
DocumentationExamples.cs:35: [BasicInjection: XSSInjectionWarning] Possible XSS-injection from line 31 into actual parameter "value" of method "WriteLine"
DocumentationExamples.cs:40: [BasicInjection: SqlInjectionWarning] Possible SQL-injection from line 31 into actual parameter "s" of method "Test2"
DocumentationExamples.cs:41: [BasicInjection: SqlInjectionWarning] Possible SQL-injection from line 31 into actual parameter "s" of method "Test2"
DocumentationExamples.cs:44: [BasicInjection: GenericInjectionWarning] Possible injection of tainted data from line 31 into actual parameter "s" of method "Test3"
DocumentationExamples.cs:45: [BasicInjection: GenericInjectionWarning] Possible injection of tainted data from line 31 into actual parameter "s" of method "Test3"
DocumentationExamples.cs:48: [BasicInjection: SqlInjectionIntoFieldWarning] Possible SQL-injection from line 31 into field "sqlTrusted"
DocumentationExamples.cs:49: [BasicInjection: GenericInjectionIntoFieldWarning] Possible injection of tainted data from line 31 into field "trusted"
DocumentationExamples.cs:50: [BasicInjection: SqlInjectionIntoFieldWarning] Possible SQL-injection from line 31 into field "sqlTrusted"
DocumentationExamples.cs:51: [BasicInjection: GenericInjectionIntoFieldWarning] Possible injection of tainted data from line 31 into field "trusted"

Let us discuss the motivation of such warnings. The parameter read at line 31 is considered as user input. This checker tracks its propagation along the statements of the program and finds out that that user input is printed at lines 34 and 35. Instead, the text printed at lines 36 and 37 does not contain user input, although it is not necessarily a hardcoded constant string. Same reasonings apply to the other warnings.

In this example, the programmer should avoid a direct flow from user input to servlet output, since this allows a cross-site scripting (XSS) attack. User input should never be printed to the servlet output, or at least it must be previously sanitized.