# VulEye: A Novel Graph Neural Network Vulnerability Detection Approach for PHP Application
## 4 Proposed Approach
### Stage I: Graph Composition  
Most web vulnerabilities include, but are not limited to, XSS (cross-site scripting), OSCI (OS command injection), SQLI (SQL injection), etc. They are all caused by the user's input not being safely sanitized and directly fed to the dangerous function. Some conditional statements will change the command execute route, making the vulnerable code line run on a specific condition. To this end, we introduce a new graph structure named SDG, which is  
Figure 1: VulEye overview. a sub-graph of PDG (Program Dependence Graph) and only contains the nodes and edges closely related to vulnerability. The procedure of the SDG constructor includes two steps: PDG extraction and PDG slicing. **PDG extraction. ** We use the open-source tool _PHP-parser_[44] to obtain the AST of PHP source code and analyze the control dependence and data dependence to construct the PDG, the same as in paper [12]. Figure 2 shows the example procedure of PDG extraction with code Listing 1. We extract the CFG (Control Flow Graph) of the source code according to the code execution order and branch relationship. Then, we analyze the \"define-use\" relationship of variables in the code to obtain the DFG (Data Flow Graph) of the source code, where the use of the _$name_ variable of nodes 3, 4, and 6 is defined by node 1. Finally, we combine the above two diagrams into one graph, the so-called PDG. In this step, we extend PDG with a graph attribute _sensitive_call_funcs_ to save all the sensitive call functions in the source code. Table 1 shows the dangerous API calling functions concerned by different vulnerabilities in PHP vulnerability. There are some other API functions that can sanitize the special chars of user input that will prevent evil things from occurring. Table 2 shows the standard sanitizer functions. These two types of API functions are all the sensitive functions we focus on, because they are the key to deciding whether the source code is vulnerable. **PDG slicing. ** When slicing the vulnerable code, we focus on the functions or API calls that can trigger vulnerability execution, usually called _sink_ point/function. Unlike the traditional way of manually slicing source code according to the specified code line, we adopt an improved automatic code-slicing method. In the previous step of AST (Abstract Syntax Tree) analyzing, we reserve the names and types of all API calling functions in source code, pick up the sensitive function calls as a list, then save it as PDG graph attribute _sensitive_call_funcs_. With this sensitive call functions list, we can quickly locate dangerous sink points during subsequent slicing. When the sink point is determined, we reverse search all the paths that can reach the sink point by using the connectivity of the nodes in PDG, then collect all nodes on these paths as a set \(V\). We use it to segment the PDG obtained in the previous step into an SDG, leaving only the nodes in the set \(V\) and the corresponding edges. Moreover, we retain the source code represented by nodes in the SDG node attribute, because these codes are code slices closely related to vulnerabilities. \begin{table}
\begin{tabular}{c c} \hline \hline
**Vulnerability** & **Sensitive Function** \\ \hline OSCI & System, exec, passthru, shell\_exec, \\ (CWE-78) & popen, proc\_open, pcntl\_exec \\ \hline XSS & echo, print, printf, vprintf, trigger\_error, user\_errorm, die, \\ (CWE-79) & exit, var\_dump, odbc\_result\_all, ifx\_htmltbl\_result \\ \hline SQLI & mysql\_query, odbc\_exec, mysqli\_query, mysql\_db\_query, \\ (CWE-89) & pg\_query, pdo::query, pg\_send\_query, mysqli::query, \\  & mysql\_unbuffered\_query, sqlsrv\_query, \\  & SQLIte3::query, pg\_query\_params, pg\_send\_query\_params, SQLIte3::exec \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Common PHP Sensitive API functions.