Checker Injection

belongs to group Advanced
Identify potential 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 ]
  • AddressInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @AddressTrusted [ CWE74 ]
  • AddressInjectionWarning: tainted data might flow into the creation of an Internet address [ CWE74 ]
  • AddressInjectionWarningWithFlow: tainted data might flow into the creation of an Internet address [ CWE74 ]
  • CodeInjectionIntoFieldWarning: tainted data flows into a field annotated as @CodeTrusted [ CWE94 ]
  • CodeInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @CodeTrusted [ CWE94 ]
  • CodeInjectionWarning: tainted data might flow into a script execution routine [ CWE94 ]
  • CodeInjectionWarningWithFlow: tainted data might flow into a script execution routine [ CWE94 ]
  • CommandInjectionIntoFieldWarning: tainted data flows into a field annotated as @CommandTrusted [ CWE78 ]
  • CommandInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @CommandTrusted [ CWE78 ]
  • CommandInjectionWarning: tainted data might flow into a command execution routine [ CWE78 ]
  • CommandInjectionWarningWithFlow: tainted data might flow into a command execution routine [ CWE78 ]
  • ControlInjectionIntoFieldWarning: tainted data flows into a field annotated as @ControlTrusted [ CWE74 ]
  • ControlInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @ControlTrusted [ CWE74 ]
  • ControlInjectionWarning: tainted data might flow into a control modifying method [ CWE74 ]
  • ControlInjectionWarningWithFlow: tainted data might flow into a control modifying method [ CWE74 ]
  • DOSInjectionIntoFieldWarning: tainted data flows into a field annotated as @DenialTrusted [ CWE74 ]
  • DOSInjectionIntoFieldWarningWithFlow: 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 ]
  • DOSInjectionWarningWithFlow: tainted data might flow into a method that makes the computer sleep or wait [ CWE74 ]
  • DeviceInjectionIntoFieldWarning: tainted data flows into a field annotated as @DeviceTrusted [ CWE74 ]
  • DeviceInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @DeviceTrusted [ CWE74 ]
  • DeviceInjectionWarning: tainted data might flow into a property of the hardware device [ CWE74 ]
  • DeviceInjectionWarningWithFlow: tainted data might flow into a property of the hardware device [ CWE74 ]
  • EvalInjectionIntoFieldWarning: tainted data flows into a field annotated as @EvalTrusted [ CWE95 ]
  • EvalInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @EvalTrusted [ CWE95 ]
  • EvalInjectionWarning: tainted data might flow into code that dynamically evaluates an expression [ CWE95 ]
  • EvalInjectionWarningWithFlow: tainted data might flow into code that dynamically evaluates an expression [ CWE95 ]
  • GenericInjectionIntoFieldWarning: tainted data flows into a field annotated as @Trusted [ CWE74 ]
  • GenericInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @Trusted [ CWE74 ]
  • GenericInjectionWarning: tainted data might flow into a trusted parameter [ CWE74 ]
  • GenericInjectionWarningWithFlow: tainted data might flow into a trusted parameter [ CWE74 ]
  • HttpResponseInjectionIntoFieldWarning: tainted data flows into a field annotated as @HttpResponseTrusted [ CWE113 ]
  • HttpResponseInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @HttpResponseTrusted [ CWE113 ]
  • HttpResponseSplittingWarning: tainted data might flow into an HTTP response [ CWE113 ]
  • HttpResponseSplittingWarningWithFlow: tainted data might flow into an HTTP response [ CWE113 ]
  • LDAPAttributeInjectionIntoFieldWarning: tainted data flows into a field annotated as @AttributeTrusted [ CWE90 ]
  • LDAPAttributeInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @AttributeTrusted [ CWE90 ]
  • LDAPAttributeInjectionWarning: tainted data might flow into an LDAP attribute [ CWE90 ]
  • LDAPAttributeInjectionWarningWithFlow: tainted data might flow into an LDAP attribute [ CWE90 ]
  • LDAPFilterInjectionIntoFieldWarning: tainted data flows into a field annotated as @FilterTrusted [ CWE90 ]
  • LDAPFilterInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @FilterTrusted [ CWE90 ]
  • LDAPFilterInjectionWarning: tainted data might flow into the filter of an LDAP search [ CWE90 ]
  • LDAPFilterInjectionWarningWithFlow: tainted data might flow into the filter of an LDAP search [ CWE90 ]
  • LogForgingWarning: tainted data might flow into a log [ CWE117 ]
  • LogForgingWarningWithFlow: tainted data might flow into a log [ CWE117 ]
  • LogInjectionIntoFieldWarning: tainted data flows into a field annotated as @LogTrusted [ CWE117 ]
  • LogInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @LogTrusted [ CWE117 ]
  • MessageInjectionIntoFieldWarning: tainted data flows into a field annotated as @MessageTrusted [ CWE319 ]
  • MessageInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @MessageTrusted [ CWE319 ]
  • MessageInjectionWarning: tainted data might flow into a message sent by the device [ CWE319 ]
  • MessageInjectionWarningWithFlow: tainted data might flow into a message sent by the device [ CWE319 ]
  • PathInjectionIntoFieldWarning: tainted data flows into a field annotated as @PathTrusted [ CWE22 ]
  • PathInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @PathTrusted [ CWE22 ]
  • PathInjectionWarning: tainted data might flow into a file path creation method [ CWE22 ]
  • PathInjectionWarningWithFlow: tainted data might flow into a file path creation method [ CWE22 ]
  • ReflectionInjectionIntoFieldWarning: tainted data flows into a field annotated as @ReflectionTrusted [ CWE470 ]
  • ReflectionInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @ReflectionTrusted [ CWE470 ]
  • ReflectionInjectionWarning: tainted data might flow into a reflection method [ CWE470 ]
  • ReflectionInjectionWarningWithFlow: tainted data might flow into a reflection method [ CWE470 ]
  • ResourceInjectionIntoFieldWarning: tainted data flows into a field annotated as @ResourceTrusted [ CWE74 ]
  • ResourceInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @ResourceTrusted [ CWE74 ]
  • ResourceInjectionWarning: tainted data might flow into a variable annotated as @ResourceTrusted [ CWE74 ]
  • ResourceInjectionWarningWithFlow: tainted data might flow into a variable annotated as @ResourceTrusted [ CWE74 ]
  • SessionInjectionIntoFieldWarning: tainted data flows into a field annotated as @SessionTrusted [ CWE501 ]
  • SessionInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @SessionTrusted [ CWE501 ]
  • SessionInjectionWarning: tainted data might flow into a session [ CWE501 ]
  • SessionInjectionWarningWithFlow: tainted data might flow into a session [ CWE501 ]
  • SqlInjectionIntoFieldWarning: the request of a servlet might flow into a field annotated as @SqlTrusted, unsanitized [ CWE89 ]
  • SqlInjectionIntoFieldWarningWithFlow: 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 ]
  • SqlInjectionWarningWithFlow: tainted data might flow into an sql query, unsanitized [ CWE89 ]
  • TrustBoundaryViolationIntoFieldWarning: tainted data flows into a field annotated as @BoundaryTrusted [ CWE501 ]
  • TrustBoundaryViolationIntoFieldWarningWithFlow: 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 ]
  • TrustBoundaryViolationWarningWithFlow: 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 ]
  • URLInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @UrlTrusted [ CWE74 ]
  • URLInjectionWarning: tainted data might flow into a URL creation [ CWE74 ]
  • URLInjectionWarningWithFlow: tainted data might flow into a URL creation [ CWE74 ]
  • XPathInjectionIntoFieldWarning: tainted data flows into a field annotated as @XPathTrusted [ CWE643 ]
  • XPathInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @XPathTrusted [ CWE643 ]
  • XPathInjectionWarning: tainted data might flow into an xpath creation method [ CWE643 ]
  • XPathInjectionWarningWithFlow: tainted data might flow into an xpath creation method [ CWE643 ]
  • XSSInjectionIntoFieldWarning: tainted data flows into a field annotated as @CrossSiteTrusted [ CWE79 ]
  • XSSInjectionIntoFieldWarningWithFlow: tainted data flows into a field annotated as @CrossSiteTrusted [ CWE79 ]
  • XSSInjectionWarning: tainted data might flow into a script execution routine [ CWE79 ]
  • XSSInjectionWarningWithFlow: tainted data might flow into a script execution routine [ CWE79 ]

Options accepted by this checker

  • dumpAnalysis: dump extensive (very large!) log information about the analysis
    Only useful for debugging the analyzer
  • dumpCompleteGraphs: dump the complete backward flow graph derivated from a sink
    If set to true, it produces an archive with the complete backward flow graphs that are used for the extraction of source-sink subgraphs
  • dumpDotWithInvariants: dump the analysed code in dot format, with flow information
    This option dumps a dot file for each method or constructor that is reachable from the entry points of the analysis. At the beginning of each code, a flow invariant is reported
  • flow: where possible, reconstructs the instruction flows leading to injection issues
    If true, it reconstructs the flow and provides detailed information on the warning if successful.
  • flowComputingSpeed: efficiency of the flow reconstruction
    This speciefies the efficiency of the flow reconstruct. Interesting only if option flow is set to true. (AVERAGE by default)
    • AVERAGE: reconstruct graphs until max of 2000 nodes
    • FAST: reconstruct graphs until max of 1000 nodes
    • FASTEST: reconstruct graphs until max of 500 nodes
    • SLOW: reconstruct graphs until max of 4000 nodes
    • SLOWEST: reconstruct graphs until max of integer limit nodes
  • fullJaif: dump a jaif file with the information flow information of the program, containing both the selected properties of interest and their complement
    The generated jaif file is a compact report of the program places that might contain a secret (tainted) value. Differently from the -jaif option, this generates explicit information for the places that contain a non-secret value as well and is hence a more verbose version of the same information
  • fullyQualifiedNames: use fully qualified class names in the jaif files
    The generated jaif file is a compact report of the program places that might contain a secret (tainted) value. This option forces the use of fully qualified class names in the jaif file, also when referring to classes in the same package that is being reported
  • jaif: dump a jaif file with the information flow information of the program
    A jaif file is a compact report of the program places that might contain a secret (tainted) value. It can be used for reference and documentation, but can also be imported in the source code of the program by using the annotation file utilities (see http://types.cs.washington.edu/annotation-file-utilities)
  • mergeCreations: merge the creation points for the same type inside the same class
    This enhances the efficiency of the creation points analysis performed as part of flow analysis but, in general, reduces the precision of the analyzer. However, it can be an important option to select for the analysis of very large applications and in library mode, in the rare cases when the creation points analysis takes too long to complete. This option is automatically selected for large programs
  • noOracle: do not use an oracle semantics for the fields
    This largely reduces the precision of the analysis, since Julia will not track anymore the fields that are definitely initialized to a non-secret (non-tainted) value before being accessed. Mainly useful for profiling and statistics
  • noUnreachable: do not dump information on unreachable code
    By selecting this option, the jaif files become smaller
  • reportLocals: dump information on local variables
    By selecting this option, the jaif file contains information on local variables as well and consequently becomes larger
  • 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.injection.AddressTrusted
  • @com.juliasoft.julia.checkers.injection.AttributeTrusted
  • @com.juliasoft.julia.checkers.injection.BoundaryTrusted
  • @com.juliasoft.julia.checkers.injection.CodeTrusted
  • @com.juliasoft.julia.checkers.injection.CommandTrusted
  • @com.juliasoft.julia.checkers.injection.ControlTrusted
  • @com.juliasoft.julia.checkers.injection.CrossSiteTrusted
  • @com.juliasoft.julia.checkers.injection.DenialTrusted
  • @com.juliasoft.julia.checkers.injection.DeviceTrusted
  • @com.juliasoft.julia.checkers.injection.EvalTrusted
  • @com.juliasoft.julia.checkers.injection.FilterTrusted
  • @com.juliasoft.julia.checkers.injection.HttpResponseImmediatelyTrusted
  • @com.juliasoft.julia.checkers.injection.HttpResponseTrusted
  • @com.juliasoft.julia.checkers.injection.LogTrusted
  • @com.juliasoft.julia.checkers.injection.MessageTrusted
  • @com.juliasoft.julia.checkers.flows.OsTrusted
  • @com.juliasoft.julia.checkers.injection.PathTrusted
  • @com.juliasoft.julia.checkers.injection.ReflectionTrusted
  • @com.juliasoft.julia.checkers.injection.ResourceTrusted
  • @com.juliasoft.julia.checkers.injection.SessionTrusted
  • @com.juliasoft.julia.checkers.injection.SqlTrusted
  • @com.juliasoft.julia.checkers.injection.Trusted
  • @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
  • @com.juliasoft.julia.checkers.injection.UrlTrusted
  • @com.juliasoft.julia.checkers.injection.XPathTrusted


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.
Specification of source locations
Normally, you needn't specify any source location, since Julia will recognize the most frequent locations automatically (see the list of sources natively recognized by Julia). For special experiments or for frameworks not recognized by Julia, please use the following code annotations.

Julia has a built-in mechanism that identifies standard source locations from where user input can be provided to a program. These belong to the following five classes:

  • Request objects to servlets and input read from console are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the @UntrustedUserInput annotation. This class is turned off if the trustUserInput option is flagged
  • Input streams from sockets or URL are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the @UntrustedExternalStream annotation. This class is turned off if the trustExternalStreams option is flagged
  • Files from the file system, system properties and arguments to main methods are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the @UntrustedEnvironment annotation. This class is turned off if the trustEnvironment option is flagged
  • The results of database queries are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the @UntrustedDatabase annotation. This class is turned off if the trustDatabase option is flagged
  • Data about the specific device where the program is running, such as its phone number, its geographical location and its IMEI code, is considered as untrusted. The programmer can specify further method parameters as source locations of this class, through the @UntrustedDevice annotation. This class is turned off if the trustDevice option is flagged


Specification of sink locations
Normally, you needn't specify any sink location, since Julia will recognize the most frequent locations automatically. (see the list of sinks natively recognized by Julia). For special experiments or for frameworks not recognized by Julia, please use the following code annotations.

Julia has a built-in specification of sink locations where untrusted data should not flow into. These include:

  • Parameters passed to SQL database query methods. If untrusted data flows here, an SQL-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @SqlTrusted annotation
  • Parameters passed to IP address factory methods such as Inet6Address.getByAddress(). If untrusted data flows here, an address-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @AddressTrusted annotation
  • Parameters passed to value/attribute manipulation methods of servlet session objects. If untrusted data flows here, a session-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @SessionTrusted annotation
  • Parameters passed to constructors, bind and connect methods of sockets. If untrusted data flows here, a resource-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @ResourceTrusted annotation
  • Parameters passed to reflection methods. If untrusted data flows here, a reflection-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @ReflectionTrusted annotation
  • Parameters passed as names to file or file stream constructors. If untrusted data flows here, a path-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @PathTrusted annotation
  • Parameters passed to logging functions. If untrusted data flows here, a log-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @LogTrusted annotation
  • Parameters passed to the output stream of servlets. If untrusted data flows here, a cross-site-scripting-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @CrossSiteTrusted annotation
  • Parameters passed to the http response object of servlets. If untrusted data flows here, an http-response-injection warning is reported. This encompasses open redirection attacks. The programmer can specify extra locations of this class where untrusted data should not flow, through the @HttpResponseTrusted annotation
  • Parameters passed to the xpath compilation and evaluation methods. If untrusted data flows here, an xpath-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @XPathTrusted annotation
  • Parameters passed as addresses to URL constructors or to Class.getResource(). If untrusted data flows here, a resource-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @UrlTrusted annotation
  • Parameters passed to methods that might induce an indefinite wait and consequently a denial-of service, such as Thread.sleep(). If untrusted data flows here, a denial-of-service-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @DenialTrusted annotation
  • Parameters passed as filters to javax.naming.directory.DirContext methods, that might induce unconstrained listing of files. If untrusted data flows here, a filter-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @FilterTrusted annotation
  • Parameters passed as values of javax.naming.directory.BasicAttribute's. If untrusted data flows here, an attribute-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @AttributeTrusted annotation
  • Parameters passed to selected methods of javax.script.ScriptEngine objects. If untrusted data flows here, a code-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @CodeTrusted annotation
  • Parameters passed to command or process execution methods. If untrusted data flows here, an OS-command-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @CommandTrusted annotation
  • Parameters passed as names of native libraries loaded at runtime. If untrusted data flows here, a control-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the @ControlTrusted annotation
The programmer can also specify a generic location where untrusted data should not flow, through the @Trusted annotation.


Track the injection flow

The injection checker with the option flow=true is able to generate graphs from the source location to sink location. This allows to better understand which software components are involved and how they could lead to an injection attack.

For efficiency reason, Julia could not reconstruct any flow graphs involved in potential injection attacks, but always triggers a warning with the sink location that can be manually checked.
In the analysis result of Web Console, it is possible view the graphs associeted with warnings
GraphInjectionWebConsole
Example of flow graph extracted from the analysis:
GraphInjection
The graph starts from the source locations (yellow triangles) and step by step up to the sink location (red hexagon). The graph contains different level of details, in fact there is information on packages, classes, methods, lines of code (rectangular sets) and instructions (gray circle). Note the instructions are in bytecode, then when working with bytecode level the normal instructions, that usually are implicit, intend are explicit.

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.
Specification of source locations
Normally, you needn't specify any source location, since Julia will recognize the most frequent locations automatically (see the list of sources natively recognized by Julia). For special experiments or for frameworks not recognized by Julia, please use the following code annotations.

Julia has a built-in mechanism that identifies standard source locations from where user input can be provided to a program. These belong to the following five classes:

  • Request objects to servlets and input read from console are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the [UntrustedUserInput] annotation. This class is turned off if the trustUserInput option is flagged
  • Input streams from sockets or URL are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the [UntrustedExternalStream] annotation. This class is turned off if the [trustExternalStreams] option is flagged
  • Files from the file system, system properties and arguments to main methods are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the [UntrustedEnvironment] annotation. This class is turned off if the trustEnvironment option is flagged
  • The results of database queries are considered as source locations of untrusted data. The programmer can specify further method parameters as source locations of this class, through the [UntrustedDatabase] annotation. This class is turned off if the trustDatabase option is flagged
  • Data about the specific device where the program is running, such as its phone number, its geographical location and its IMEI code, is considered as untrusted. The programmer can specify further method parameters as source locations of this class, through the [UntrustedDevice] annotation. This class is turned off if the trustDevice option is flagged


Specification of sink locations
Normally, you needn't specify any sink location, since Julia will recognize the most frequent locations automatically. (see the list of sinks natively recognized by Julia). For special experiments or for frameworks not recognized by Julia, please use the following code annotations.

Julia has a built-in specification of sink locations where untrusted data should not flow into. These include:

  • Parameters passed to SQL database query methods. If untrusted data flows here, an SQL-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [SqlTrusted] annotation
  • Parameters passed to IP address factory methods. If untrusted data flows here, an address-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [AddressTrusted] annotation
  • Parameters passed to value/attribute manipulation methods of servlet session objects. If untrusted data flows here, a session-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [SessionTrusted] annotation
  • Parameters passed to constructors, bind and connect methods of sockets. If untrusted data flows here, a resource-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [ResourceTrusted] annotation
  • Parameters passed to reflection methods. If untrusted data flows here, a reflection-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [ReflectionTrusted] annotation
  • Parameters passed as names to file or file stream constructors. If untrusted data flows here, a path-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [PathTrusted] annotation
  • Parameters passed to logging functions. If untrusted data flows here, a log-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [LogTrusted] annotation
  • Parameters passed to the output stream of servlets. If untrusted data flows here, a cross-site-scripting-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [CrossSiteTrusted] annotation
  • Parameters passed to the http response object of servlets. If untrusted data flows here, an http-response-injection warning is reported. This encompasses open redirection attacks. The programmer can specify extra locations of this class where untrusted data should not flow, through the [HttpResponseTrusted] annotation
  • Parameters passed to the xpath compilation and evaluation methods. If untrusted data flows here, an xpath-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [XPathTrusted] annotation
  • Parameters passed as addresses to URL constructors or to Class.getResource(). If untrusted data flows here, a resource-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [UrlTrusted] annotation
  • Parameters passed to methods that might induce an indefinite wait and consequently a denial-of service, such as Thread.Sleep(). If untrusted data flows here, a denial-of-service-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [DenialTrusted] annotation
  • Parameters passed as filters to System.DirectoryServices.DirectorySearcher, that might induce unconstrained listing of files. If untrusted data flows here, a filter-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [FilterTrusted] annotation
  • Parameters passed as values where, if untrusted data flows here, an attribute-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [AttributeTrusted] annotation
  • Parameters passed to selected methods of System.Web.HttpServerUtility objects. If untrusted data flows here, a code-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [CodeTrusted] annotation
  • Parameters passed to command or process execution methods. If untrusted data flows here, an OS-command-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [CommandTrusted] annotation
  • Parameters passed as names of native libraries loaded at runtime. If untrusted data flows here, a control-injection warning is reported. The programmer can specify extra locations of this class where untrusted data should not flow, through the [ControlTrusted] annotation
The programmer can also specify a generic location where untrusted data should not flow, through the [Trusted] annotation.


Track the injection flow

The injection checker with the option flow=true is able to generate graphs from the source location to sink location. This allows to better understand which software components are involved and how they could lead to an injection attack.

For efficiency reason, Julia could not reconstruct any flow graphs involved in potential injection attacks, but always triggers a warning with the sink location that can be manually checked.
In the analysis result of Web Console, it is possible view the graphs associeted with warnings
GraphInjectionWebConsole
Example of flow graph extracted from the analysis:
GraphInjection
The graph starts from the source locations (yellow triangles) and step by step up to the sink location (red hexagon). The graph contains different level of details, in fact there is information on packages, classes, methods, lines of code (rectangular sets) and instructions (gray circle). Note the instructions are in bytecode, then when working with bytecode level the normal instructions, that usually are implicit, intend are explicit.


Examples

Consider the following program:

import java.io.IOException;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.juliasoft.julia.checkers.flows.UntrustedUserInput;
import com.juliasoft.julia.checkers.injection.SqlTrusted;
import com.juliasoft.julia.checkers.injection.Trusted;
import com.juliasoft.julia.extraction.EntryPoint;

public class SqlInjection extends HttpServlet {
  private @SqlTrusted Object sqlTrusted;
  private @Trusted Object trusted;

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

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

  public @EntryPoint void test1(@UntrustedUserInput String user) {
    Connection conn = null;
    String url = "jdbc:mysql://192.168.2.128:3306/";
    String dbName = "anvayaV2";
    String driver = "com.mysql.jdbc.Driver";
    String userName = "root";
    String password = "";
    // with the following assignment, there is no injection anymore at line 48
    // user = "erasmus";

    try {
      Class.forName(driver).newInstance();
      conn = DriverManager.getConnection(url + dbName, userName, password);

      Statement st = conn.createStatement();
      String query = "SELECT * FROM  User where userId='" + user + "'";
      System.out.printf(query);
      st.executeQuery(query);

      // Julia does not like these
      test2(query + " extra characters");
      test3(query + " hello");

      // while Julia likes this!
      test2("driver".substring(3, 5));

      conn.close();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

  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");
    String url = "jdbc:mysql://192.168.2.128:3306/";
    String dbName = "anvayaV2";
    String driver = "com.mysql.jdbc.Driver";
    String userName = "root";
    String password = "";

    try {
      Class.forName(driver).newInstance();
    }
    catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) {
      return;
    }

    try (Connection conn = DriverManager.getConnection(url + dbName, userName, password);
         PrintWriter out = response.getWriter()) {

      Statement st = conn.createStatement();
      String query = "SELECT * FROM  User where userId='" + user + "'";
      out.println("Query : " + query);
      System.out.printf(query);
      ResultSet res = st.executeQuery(query);
      trusted = query.substring(5, 7);
      sqlTrusted = query;

      out.println("Results");
      while (res.next()) {
        String s = res.getString("address");
        out.println("\t\t" + s);
      }
    }
    catch (SQLException e) {}
  }
}

This checker issues the following warnings:

SqlInjection.java:48: [Injection: SqlInjectionWarning] possible SQL-injection through the 0th actual parameter of executeQuery
SqlInjection.java:51: [Injection: SqlInjectionWarning] possible SQL-injection through the 0th actual parameter of test2
SqlInjection.java:52: [Injection: GenericInjectionWarning] possible injection of tainted data through the 0th actual parameter of test3
SqlInjection.java:91: [Injection: XSSInjectionWarning] possible XSS-injection through the 0th actual parameter of println
SqlInjection.java:93: [Injection: SqlInjectionWarning] possible SQL-injection through the 0th actual parameter of executeQuery
SqlInjection.java:94: [Injection: GenericInjectionIntoFieldWarning] possible injection of tainted data into field trusted
SqlInjection.java:95: [Injection: SqlInjectionIntoFieldWarning] possible SQL-injection into field sqlTrusted
SqlInjection.java:100: [Injection: XSSInjectionWarning] possible XSS-injection through the 0th actual parameter of println

Let us discuss the motivation of such warnings. At lines 48 and 93, the query to the database is partially built from user input passed as a parameter to the servlet. Hence there might be an SQL-injection there. At line 51, user input is passed to test2(), which requires its parameter to be @SqlTrusted instead. Hence Julia issues a warning there. The situation at line 52 is similar, but for the kind of annotation, which is @Trusted for the parameter of test3(). At line 91, user input is sent to the servlet output stream and might hence allow a cross-site scripting attack. At lines 94 and 95, data built from user input is written into fields annotated as @Trusted and @SqlTrusted, respectively. Hence, Julia issues a warning there. At line 100, data derived from the result of a database query is sent to the output stream of the servlet. Julia issues a cross-site scripting warning there since the query depends from user input and hence its result as well.

In this example, the programmer should avoid a direct flow of user input into database queries or into the output stream of the servlet. The solution is to use a sanitizing method that guarantees the correct handling of user input, so that it becomes harmless (see the list of sanitizing methods natively recognized by Julia), or to use prepared statements for database queries, or to implement proprietary sanitizing methods. For an example of the last case, the query might be passed through a sanitizing method such as query = clean(query) just after line 48, where:

private @Trusted String clean(String query) {
  return ...sanitized query
}

The @Trusted annotation is needed here to suggest to Julia the fact that this is a sanitizing method, whose result is always trusted. Julia is not able to infer such complex property by itself.

Consider the following program:

using com.juliasoft.julia.checkers.flows;
using com.juliasoft.julia.checkers.injection;
using System;
using System.Data;
using System.Data.SqlClient;
using System.IO;
using System.Web;
using System.Web.UI;

namespace DocumentationExamples
{

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

        [SqlTrusted]
        private object sqlTrusted;
        [Trusted]
        private object trusted;

        public void Page_Load(object source, EventArgs e)
        {
            ProcessRequest(Request, Response);
        }

        public void Test1([UntrustedUserInput] string user)
        {
            SqlConnection sqlConnection1 = new SqlConnection("Your Connection String");
            SqlCommand cmd = new SqlCommand();
            SqlDataReader reader;

            string query = "SELECT * FROM  User where userId='" + user + "'";


            cmd.CommandText = query;
            cmd.CommandType = CommandType.Text;
            cmd.Connection = sqlConnection1;

            sqlConnection1.Open();

            reader = cmd.ExecuteReader();
            Console.WriteLine(cmd.CommandText);

            // Julia does not like these
            Test2(query + " extra characters");
            Test3(query + " hello");

            // while Julia likes this!
            Test2("driver".Substring(3, 5));

            sqlConnection1.Close();
        }

        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 (SqlConnection conn = new SqlConnection("Connection String"))
            using (TextWriter p = response.Output)
            {
                SqlCommand st = conn.CreateCommand();
                string query = "SELECT * FROM  User where userId='" + user + "'";
                p.WriteLine(query);
                st.CommandText = query;
                st.CommandType = CommandType.Text;
                SqlDataReader reader = st.ExecuteReader();
                trusted = query.Substring(5, 7);
                sqlTrusted = query;

                p.WriteLine("Results");
                while (reader.NextResult())
                {
                    string s = reader["address"] as string;
                    p.WriteLine("\t\t" + s);
                }
            }
        }
    }
}

This checker issues the following warnings:

DocumentationExamples.cs:37: [Injection: SqlInjectionWarning] Possible SQL-injection into the 0th actual parameter of method "set_CommandText"
DocumentationExamples.cs:47: [Injection: SqlInjectionWarning] Possible SQL-injection into actual parameter "s" of method "Test2"
DocumentationExamples.cs:48: [Injection: GenericInjectionWarning] Possible injection of tainted data into actual parameter "s" of method "Test3"
SqlInjection.java:71: [Injection: XSSInjectionWarning] Possible XSS-injection into actual parameter "value" of method "WriteLine"
SqlInjection.java:72: [Injection: SqlInjectionWarning] Possible SQL-injection into the 0th actual parameter of method "set_CommandText"
SqlInjection.java:75: [Injection: GenericInjectionIntoFieldWarning] Possible injection of tainted data into field "trusted"
SqlInjection.java:76: [Injection: SqlInjectionIntoFieldWarning] Possible SQL-injection into field "sqlTrusted"
SqlInjection.java:82: [Injection: XSSInjectionWarning] Possible XSS-injection into actual parameter "value" of method "WriteLine"

Let us discuss the motivation of such warnings. At lines 37 and 72, the query to the database is partially built from user input passed as a parameter to the servlet. Hence there might be an SQL-injection there. At line 51, user input is passed to Test2(), which requires its parameter to be [SqlTrusted] instead. Hence Julia issues a warning there. The situation at line 48 is similar, but for the kind of annotation, which is [Trusted] for the parameter of Test3(). At line 71, user input is sent to the servlet output stream and might hence allow a cross-site scripting attack. At lines 75 and 76, data built from user input is written into fields annotated as [Trusted] and [SqlTrusted], respectively. Hence, Julia issues a warning there. At line 82, data derived from the result of a database query is sent to the output stream of the servlet. Julia issues a cross-site scripting warning there since the query depends from user input and hence its result as well.

In this example, the programmer should avoid a direct flow of user input into database queries or into the output stream of the servlet. The solution is to use a sanitizing method that guarantees the correct handling of user input, so that it becomes harmless (see the list of sanitizing methods natively recognized by Julia), or to use prepared statements for database queries, or to implement proprietary sanitizing methods. For an example of the last case, the query might be passed through a sanitizing method such as query = Clean(query) just after line 48, where:

[Trusted]
private string clean(string query) {
	return ...sanitized query
}

The [Trusted] annotation is needed here to suggest to Julia the fact that this is a sanitizing method, whose result is always trusted. Julia is not able to infer such complex property by itself.