In Chapter 3 we have explained security slicing, which is a technique that extracts all the pro- gram statements required for auditing the security of a given sink. A security slice is a concise and minimal sequence of program statements necessary to determine the vulnerability of a sink. To identify sources and sinks in the Web application under test, security slicing relies on a vulnerability catalogue, i.e., a predefined set of sink and source signatures, which can be easily extended by adding new signatures. We preconfigured a default vulnerability catalogue that contains a rich set of commonly used API signatures.
Security slicing performs symbolic execution on each path in a security slice to extract the path condition(s) characterizing the path. However, from a security auditing standpoint it is also necessary to understand the context of a sink, i.e., how the input data is used in a sink. Ex- amples of possible contexts are the content or an attribute of an HTML tag, as well as a quoted value of an SQL query. This information can be computed through context analysis (see Sec- tion 3.2.2.2) which identifies the context (within a sink) in which the data of an input source is used. More specifically, context analysis traces the values of the variables used in the sink along the path, to reconstruct the query (e.g., SQL/XPath/LDAP query) or the document part (e.g., HTML/XML fragment) that is being generated at the sink. Context information is computed by matching the reconstructed query or document part against some predefined patterns (shown in the “Context” column of Table 2.1).
in Listing 3.1. Besides the XPath vulnerability that we used as an example in Section 4.2, the program is also vulnerable to XSS. The sink at Line 30 is vulnerable to XSS because of the inadequate sanitization procedure applied to variable sid, which contains a user input. More specifically, it is sanitized by applying a custom function customSanit (Line 27), which removes the meta-characters <, >, and / from the input string variable sid. string replacement operation. However, in this operation variable sid is used in two different contexts: as an URL parame- ter value (...com?id=sid) and as the content of an HTML element <a href>...sid</a>. The sanitization procedure used is appropriate for the second context since it prevents the injection of additional HTML tags like <script>. However, it is not appropriate for the first one, which would have required URL encoding (also called percent-encoding).
Figure 3.4a shows the corresponding security slice for the (XSS) sink at Line 30 in Listing 3.1. The security slice shown in Figure 3.4a contains only two paths leading to the sink. The first path is characterized by path condition PC1, which corresponds to the path that follows the true branch of the selection statement at Line 18 in Figure 3.4a and leads to the execution of the sink; this path condition is:
PC1 ≡ Integer.parseInt(MAX ) > 20 ∧
OP .trim().equalsIgnoreCase("GradeQuery") ∧ SID.length() > 20
The second path is characterized by path condition PC2, which corresponds to the path that follows the false branch of the selection statement at Line 18 in Figure 3.4a and leads to the execution of the sink; this path condition is:
PC2 ≡ ¬(Integer.parseInt(MAX ) > 20) ∧
OP .trim().equalsIgnoreCase("GradeQuery") ∧ SID.length() > Integer.parseInt(MAX )
For both paths, our context analysis procedure (see Chapter 3) identifies the following two con- texts: CTX1, in which the symbolic expression customSanit(SID) is used as a URL parameter value in an XSS sink; CTX2, in which the symbolic expression customSanit(SID) is used as an element content in an XSS sink. Note that the symbolic expression customSanit(SID) repre- sents the values of variable sid used at the sink.
The output of security slicing—path conditions and context information—is used to gener- ate attack conditions, represented as constraints. A new constraint is generated for each context identified for each path, based on the threat model characterizing the security threat in that specific context. The Attack Condition Generation (ACG) process follows three steps:
ACG1 Since different contexts require different threat models, the procedure determines the appropriate threat model for a given context by looking up the list of threat models provided as input. The identification of the threat model is a fully automated proce- dure that matches the context returned by security slicing with one of the entries in the threat models list. The predefined version of this list is presented in Section 2.1.3; though not showed in Table 2.1, the predefined list also contains catch-all entries1 for
1The catch-all entries for threat models are more generic and might lead to false positives in terms of vulnera-
5.3. Approach each type of vulnerability, which are used as fallback mechanism when there is no context matching pattern. Furthermore, the structure of the list guarantees that there is always only one applicable threat model for a given context. For example, the threat model for context CTX1 is #7 in Table 2.1; likewise, the threat model for CTX2 is #1. ACG2 In the constraint corresponding to each identified threat model, the symbol input is
replaced with the actual symbolic expression of the input. This results in a constraint that checks if an input used at the sink contains a security attack. For example, the constraint input.matches(".*[’\"=<>/,;+-&\*\[\] ].*") —corresponding to threat model #7 (see Table 2.1)— results in the following constraint ATTK1, related to context CTX1:
ATTK1 ≡ customSanit(SID )
.matches(".*[’\"=<>/,;+-&\*\[\] ].*") Likewise, the constraint ATTK2 related to CTX2 is:
ATTK2 ≡ customSanit(SID ).matches(".*[<>/].*")
ACG3 For each constraint generated in the previous step and a given path condition, the attack conditions are generated by simply conjoining the path condition with the con- straint. For example, the attack condition SEC1 is the constraint conjoining PC1 and ATTK1: SEC1 ≡ Integer.parseInt(MAX ) > 20 ∧ OP .trim().equalsIgnoreCase("GradeQuery") ∧ SID .length() > 20 ∧ customSanit(SID ) .matches(".*[’\"=<>/,;+-&\*\[\] ].*") Likewise, attack condition SEC4 conjoins PC2 and ATTK2:
SEC4 ≡ ¬(Integer.parseInt(MAX ) > 20) ∧
OP .trim().equalsIgnoreCase("GradeQuery") ∧ SID .length() > Integer.parseInt(MAX ) ∧ customSanit(SID ).matches(".*[<>/].*")
Similar attack conditions (omitted for space reasons) are computed by conjoining PC1 and ATTK2, as well as PC2 and ATTK1.
More details on security slicing and context analysis are available in Section 3.2.2.2.