{"id":693,"date":"2022-06-24T14:51:34","date_gmt":"2022-06-24T14:51:34","guid":{"rendered":"https:\/\/devbrain.com.br\/?p=693"},"modified":"2022-06-24T14:51:34","modified_gmt":"2022-06-24T14:51:34","slug":"xss-through-php_self","status":"publish","type":"post","link":"https:\/\/devbrain.com.br\/index.php\/2022\/06\/24\/xss-through-php_self\/","title":{"rendered":"XSS through PHP_SELF"},"content":{"rendered":"\n

As per https:\/\/www.php.net\/manual\/en\/reserved.variables.server.php, we can interpret PHP_SELF as:<\/p>\n\n\n\n

The filename of the currently executing script, relative to the document root. For instance, $_SERVER[‘PHP_SELF’]<\/var> in a script at the address http:\/\/example.com\/foo\/bar.php<\/var> would be \/foo\/bar.php<\/var>. The __FILE__<\/a> constant contains the full path and filename of the current (i.e. included) file. If PHP is running as a command-line processor this variable contains the script name.<\/em><\/p>\n\n\n\n

With the information above, it’s common to have such variable across different usages such as searches and web forms. However, depending on how you’re using it, it might be vulnerable to different cross-site scripting (XSS) vectors over a given app.<\/p>\n\n\n\n

Scenario:<\/h2>\n\n\n\n

Please refer to the full function below, corresponding a PHP application (i.e., IPPlan v4.92b):<\/p>\n\n\n\n

function Search() {\n\n        unset($this->vars[$this->frmvar]);\n        unset($this->vars[\"block\"]);\n        unset($this->vars[\"expr\"]);\n        \/\/    $url=my_http_build_query($vars);\n\n        \/\/ start form\n        insert($this->w, $f = form(array(\"name\"=>\"SEARCH\",\n                        \"method\"=>$this->method,\n                        \"action\"=>$_SERVER[\"PHP_SELF\"])));\n\n        insert($f, $con=container(\"fieldset\",array(\"class\"=>\"fieldset\")));\n        insert($con, $legend=container(\"legend\",array(\"class\"=>\"legend\")));\n        insert($legend, text($this->legend));\n        if ($this->expr_disp) {\n            $lst=array(\"START\"=>my_(\"Starts with\"),\n                    \"END\"=>my_(\"Ends with\"),\n                    \"LIKE\"=>my_(\"Contains\"),\n                    \"NLIKE\"=>my_(\"Does not contain\"),\n                    \"EXACT\"=>my_(\"Equal to\"));\n            if (DBF_TYPE==\"mysql\" or DBF_TYPE==\"maxsql\" or DBF_TYPE==\"postgres7\") {\n                $lst[\"RLIKE\"]=my_(\"Regex contains\");\n            }\n            \/\/ only supported by mysql\n            if (DBF_TYPE==\"mysql\" or DBF_TYPE==\"maxsql\") {\n                $lst[\"NRLIKE\"]=my_(\"Does not regex contain\");\n            }\n            insert($con,selectbox($lst, array(\"name\"=>\"expr\"), $this->expr));\n        }\n\n        insert($con,input_text(array(\"name\"=>$this->frmvar,\n                        \"value\"=>$this->search,\n                        \"size\"=>\"20\",\n                        \"maxlength\"=>\"80\")));\n\n        foreach ($this->vars as $key=>$value) {\n            insert($con,hidden(array(\"name\"=>\"$key\",\n                            \"value\"=>\"$value\")));\n        }\n\n        insert($con,submit(array(\"value\"=>my_(\"Submit\"))));\n        insert($con,block(\" <a href='#' onclick='SEARCH.\".$this->frmvar.\".value=\\\"\\\"; SEARCH.submit();'>\".my_(\"Reset Search\").\"<\/a>\"));\n\n\n    }<\/code><\/pre>\n\n\n\n
Due to the PHP action (i.e., “action”=>$_SERVER[“PHP_SELF”]), notice that we have no sanitization or validation and therefore vulnerable to XSS. That is, given the default behavior where PHP_SELF<\/strong> is copied into the value of an HTML tag, we can easily append any sort of HTML or Javascript injection within the query string. <\/p>\n\n\n\n
For evidence, refer to the prints below where I’m accessing the mentioned application with and without  our manipulation:<\/p>\n\n\n\n
Regular<\/h5>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Triggering XSS<\/h5>\n\n\n\n
\n
\"\"<\/figure>\n<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
HTTP Method<\/h3>\n\n\n\n
Also notice that according to the code’s logic, we can also specify our HTTP method (e.g., GET, POST). And although it changes nothing for the XSS flow above, certain user input sanitizations and validations might be set for specific HTTP verbs only, so controlling such parameters can also have different consequences (e.g., The app may filter any user controlled parameter via GET where we can proceed with the same task over POST where we have no filters in place),<\/p>\n\n\n\n
How to avoid it?<\/h3>\n\n\n\n
In order to avoid HTML or Javascript injections over PHP_SELF, we can simply use htlmentities()<\/strong> as it converts special characters to HTML entities and therefore it’s enough to mitigate such issue.<\/p>\n\n\n\n
Finding it – Regex<\/h3>\n\n\n\n
Even though this can be easily spotted with a SAST solution, you can also run grep\/rg recursively in order to spot any low-hanging fruit as the example below:<\/p>\n\n\n\n
rg '\\$_SERVER+.*PHP_SELF' | rg -v htmlspecialchars<\/code><\/pre>\n\n\n\n
References<\/h3>\n\n\n\n