Many problems security, to systems that are accessible via Web applications. One example Cross-Site Scripting attacks (XSS), wherein a script is injected into an application and executed by the browser or server, granting a malicious user unauthorized access to system resources or sensitive information. On the Top10 2010 list published by Open Web Application Security Project (OWASP), XSS attack is listed as number two. “Cross-Site Scripting (XSS) attacks occur when: 1. Data enters a Web application through an untrusted source, most frequently a web request. 2. The data is included in dynamic content that is sent to a web user without being validated for malicious code” [1].XSS attacks of type 1 are commonly referred to as First Order, or reflected, XSS attacks. This type of attack reflects information immediately from the server. The user is either the attacker himself or the victim of a social engineering ruse (e.g., an emailed link containing the attack). Second Order, or stored, XSS attacks are first stored permanently on the server, then later launched by an unsuspecting user. In both cases, the XSS attacks are successful only when certain vulnerabilities exist in the application; more precisely, when such vulnerabilities remain unresolved. These vulnerabilities primarily involve allowing executable inputs from users (First Order XSS attack) or other applications or existing database elements (Second Order XSS attack) to be directly or indirectly assigned the outputs of Web application without proper sanitization. As outputs of Web applications are executed by the browser, inputs that influence the output scan inject unwanted/malicious codes that are then executed. This classification of XSS injection attacks aligns with the Code Injection Attack definition provided by Ray and Ligatti [2].Research on XSS aims to find vulnerabilities and/or prevent attacks. One challenge in attack prevention is discerning which inputs will result in attacks. Some basic approaches have been deployed to detect and stop attacks by checking for script tags and same-origin verification via HTML “referer” tags1[3]. However, these techniques may not be effective, as sophisticated attacks can easily circumvent tag-based detection and HTML “referer” tags are optional and possibly unavailable. In the recent past, a number of more complex detection techniques [4]–[11] have been proposed that are either based on static analysis or runtime monitoring. Static analysis uses traditional program analysis techniques to identify vulnerable code segments via taint analysis and instruments these segments to avoid their exploitation at runtime. Typically, they are not suited to find exploitation of vulnerabilities resulting from conditional copy. Conditional copy is a technique used in code-interference based injection attacks, wherein one variable value is transferred into another (e.g., character-by-character in a conditional code segment) with direct dependency of the copies or other data operations. Runtime monitoring, on the other hand, relies on a library. of attack patterns or specification of non-attack (allowable)patterns to detect potential attacks. As a result, runtime monitoring can incur prohibitively large overhead if non-vulnerable variables are unnecessarily monitored against attack patterns. Our two-phase method employs both static analysis and runtime monitoring. The static analysis phase includes application translation and concolic unit testing techniques. The runtime monitoring phase uses the facts learned from static analysis to monitor the relevant variables in the application. Any existing runtime monitoring method can be used in ourruntime monitoring phase as long as it is coupled with the information generated in our static analysis phase. Therefore, in this paper, we emphasize the static analysis phase.
Method
Our method consists of the following steps:
1)Preprocessing: Determine the inputs and outputs ac-cording to the grammar of the Web application language (JSP in our case). We statically process the JSP Web application one file at a time to identify the inputs and outputs of each page generated from the files. We define a grammar based on the application language to capture all variables, request and response parameters, session variables, tags, etc. They are easily enumerated from constructs of JSP (or any Web application language) which includes HTML tags and embedded Java code. Any information that the application expects from other pages within the application (e.g., session variables)is also identified as input, since we treat the JSP file as an atomic unit. This aligns with Wu and Offutt [18]; the authors consider “HTML file or section of a server program that prints HTML” as an atomic section in modeling and testing Web-based applications.
2)Translation: Convert relevant parts of the Web application to a test-program (Java in our case) that can be tested easily using existing concolic testing engines. Once preprocessing is complete, the file translation is performed. Note that the result of translation, the Java program, maintains the following aspects of the original JSP application: the relationships between program variables, inputs and outputs, and control flow of the application. Finite state automaton representing vulnerable output All other elements of the JSP application, that relates to generating the HTML page are discarded (commented or put in print statements in the result of translation).The JSP application of Figure 1(a) is translated to the resulting Java program as shown in Figure 1(b). The in-puts, outputs, and the JSP application variables are also present in the Java program. The string variables are con-verted to character arrays, as concolic testing cannot handle strings; however, this does not result in any over/under-approximation in the context of vulnerability detection. Lines 1–8 in Figure 1(b) encode a constructor which mimics external input (in this case, username parameter in JSP application). Line 13 in Figure 1(b) is the translation of Line 3 of JSP application in Figure 1(a). Lines 15–18 are the translation of conditional copy if the JSP application, and Line 19 corresponds to assignment of unameto session variable uName in the JSP application.
3)Testing: Execute the test-program in a testing engine which automatically generates test cases determining vulnerabilities in original Web applications in term sof input/output dependencies. We use the concolic testing tool jCute [12] to automatically generate input test cases that determine vulnerable outputs: outputs that are directly or indirectly assigned from inputs and can contain scripting tags. Concolic testing utilizes a combination of concrete and symbolic execution to generate test cases and to effectively guide exploration of the new program paths, respectively. The method relies on careful placement of assertion statements and identifies testcases that can violate the assertions. As our focus is injection attacks, we check whether the output of the Java program can evaluate to a sequence of characters representing a script. In other words, we need to check whether the sequence contains “<” proceeded by a“>”. The finite state automaton (FSA) in Figure 2 represents such a sequence; zero or more characters followed by “<”,followed by a finite sequence of characters, followed by “>”,and finally, followed by zero or more characters
4)Instrumentation: Insert calls to a monitor (Java class in our case) in the original Web application at pro-gram points before vulnerable outputs are used. This monitor detects potential attacks. Applying jCute, we automatically obtain test cases for which some output variable can be assigned to a three-character sequence starting with “<” and ending with “>”.These are the outputs that can be exploited by injection attacks, and therefore their valuation must be monitored at runtime. We refer to these outputs as vulnerable outputs. Note that there can be many outputs in the application and a small number of them may be vulnerable. By utilizing jCute, we minimize the number of outputs that need to be monitored.
