How to use XSSaminer to mine XSS vulnerabilities in PHP source code

How to use XSSaminer to mine XSS vulnerabilities in PHP source code when you want to discover cross-site scripting vulnerabilities in the open source script code on the server, static analysis can simplify and automate our analysis process. In addition, many related tools can be found online.

I recently discovered a simple method to discover cross-site scripting vulnerabilities in the PHPsource code by finding common pattern. This method uses a tool named XSSaminer, which is created based on grep and written in bash.

Tool introduction

It first checks the script parameters:

if [ -z $1 ]then   echo -e "Usage:\n$0FILE\n$0 -r FOLDER"   exitelse   f=$1fi

Code Analysis: If the parameter $1 in the first line is null, the use case with $0 as the script name is displayed and the program is terminated. otherwise, this parameter is assigned to the f variable used in the main function.

sources=(GET POST REQUEST "SERVER\['PHP""SERVER\['PATH_" "SERVER\['REQUEST_U")sinks=(echo die printprintfprint_rvar_dump)

Next, the source and sink with incomplete strings are incomplete because they are only used for matching. Sink uses source. if it can match each other (without any filtering), we need to consider whether user input is injected into the generated HTML code.

If the sink uses GET, POST, or REQUEST global variables, this is obviously an injection problem. However, the SERVER has some special features. assume that you enter the following URL (injection with HTML attributes broken ):

http://domain/page.php/">
 

Although only three serversources are mentioned above, we can find four servers in the above code, as shown below:

$_SERVER[‘PHP_SELF’] – returns the current URL decodedhttp://domain/page.php/">
 
  $_SERVER[‘PATH_TRANSLATED’] – returns file path on the system/var/www/html/page.php/">
  
   $_SERVER[‘PATH_INFO’] – returns info between page name and querystring (?)/">
   
    $_SERVER[‘REQUEST_URI’] – returns the current URLhttp://domain/page.php/">
    
   
  
 

Last, REQUEST_URI does not decode the special characters of the URL into double quotation marks (") or signs smaller than (<). However, this is a hidden danger because the browser creates a request using these encoded characters. However, it is only applied to stored XSS and is used to intercept and edit browser requests (or use other HTTP clients), or decode PHP code elsewhere before loading the sink.

xssam(){        fori in ${sources[@]}        do               a=$(grep-in "\$_${i}" $f | grep -o "\$.*=" | sed "s/[]\?=//g" | sort -u)                forj in ${sinks[@]}               do                       grep--color -in "${j}.*\$_${i}" $f                        fork in $a                       do                               grep--color -in "${j}.*$k" $f                       done               done        done}

The Xssam function is used in combination with source and sink to find the direct hidden danger location through the first two "for" loops. The "a" variable is used to obtain the variable name that receives the insecure global value (source. The third "for" loop is used to track script variables at a level.

if [ $f != "-r" ]then        xssamelse        for i in $(find $2 -type f -name "*.php")        do               echo "File: $i"               f=$i               xssam        donefi

In the main code, this script is used to select whether a single file calls the xssam function or enters the recursive mode. This process satisfies the same function call in another "for" loop by using the folder ($2) with the-r option (replace the file name) provided in the command line.

Use case:

./XssaminerFILE (single file)./xssaminer-r FOLDER (recursive mode, all. php files in the FOLDER)

The main objective of XSSaminer is to implement XSS easily, and there are often false positives, but its LoC/result rate is very high.

Test instance

The following is the test result of the tool on the WordPress topic Rational Lite:

It found 3 XSS vulnerabilities in 2 different files, but the second was a false positive. The first was confirmed:

By tracking the vulnerability code in the entire module file, it is found that when the dismiss_id GET parameter is used to call back unauthenticated ajax operations, a warning is displayed, and a 0-day vulnerability occurs.