## 3 Methodology
### XSS Triggering in Source Code  
The source of XSS triggers often comes from user input. In XSS-sensitive code blocks, the source of data flows is the user inputs, which need to be checked and sanitized [23,32]. Generally, the XSS vulnerability triggering in PHP source code is attributed to inadequate or inappropriate sanitizing (filter) of the user input (source) for a specific output (sink) location [33]. In most cases, \"source\" is usually an external input from users. What really matters in the source code is the filter-sink corresponding relationship. Evaluations need to be done to judge if the sanitizing of user input is effective, or there could be an XSS vulnerability. However, if an entire project requires auditing, the \"source-filter-sink\", i.e., the XSS triples, needs to be considered as a whole [34]. Listing 1 shows a typical code block of handing with the input. At line 6, the program takes data from the user using the $_GET array. The code that receives user input is defined as \"source\". At line 9, the program replaces single quotes in user's data by a regular expression. This is because, in many payloads that trigger XSS, quotes are used to close the original content of the document before injection. Functions that sanitize user input like this to prevent XSS triggering are represented by \"filter\"(or \"sanitizer\"). At line 11, the data processed by the filter is output in the body tag by the echo function, and the final position written into HTML document is called \"sink\". At last, the user's input is written to HTML document. As the sink is located in the BODY tag, the attacker can easily insert the script tag in the HTML document with \"get\" parameter. The way that the single quotation mark is removed does not sanitize it. For example, if the attacker writes payload \"<script>alert(document.cookie)</script>\" in the get parameter, a JavaScript bullet window with the cookie of this website will appear in the web page.  
```
1<1 DOCTYPEhtml>
2<body>
3<?php
4$array=array();
5$array[]='safe';
6$array[]=$_GET['userData'];
7$array[]='safe';
8
9$tainted=preg_replace('/\'/', '\", $tainted);
10
11 echo$tainted;
12? 13</body>
14<html>

Figure 1: The architecture of the proposed model. The source part that receives user input is easy to classify, mostly through PHP's Super Global Variables, as shown in Table 2.

To extract the \"source-filter-sink\" from source code without being interfered with by code style, we need to parse the code into another universal form. In our work, a PHP extension called VLD parses PHP source code into internal representation blocks, named OPCODEs. The output results not only show the operation sequence, but also trace and analyze the data flow, program entry, branch execution, and variable assignment in detail. Unfortunately, VLD does not provide a programming friendly output format. In the use of VLD processing bulk PHP source code, it can not acquire accurate information that we need even with the help of regular matching. In response to it, we perform a secondary development of VLD, adding a programming friendly output format branch. With the aid of the secondarily developed VLD, it is convenient to extract the opcode sequence of a code block. OPCODE removes some of the unrelated noise from the source code but does not retain the filter-sink content we need. In Figure 2, as the code section of the filter with sink, i.e., the _filter_var_ function call with the output position of the echo (in the function setinterval) is simplified for _init_fall_ and echo, missing the key information. Therefore, the subsequent detailed processing for OPCODE is necessary. In this paper, we obtain the function list directly from the supplementary information of the operands column in the VLD analysis results, which contains the filter function the code block used. However, for complex programs, OPCODE contains more function call information. Moreover, these consistent ECHOs need to be optimized detailed to classify different sinks.