An XSS vulnerability attack caused by PHP's $_server[' php_self ' and its solutions

$_server[' php_self ' introduction

$_server[' Php_self ') represents the location address of the current PHP file relative to the root of the Web site, and is related to document root.

Suppose we have the following URLs, $_server[' php_self ') results are:

http://www.php-note.com/php/:/php/test.php
http://www.php-note.com/php/test.php:/php/test.php
Http://www.php-note.com/php/test.php?test=foo:/php/test.php
Http://www.php-note.com/php/test.php/test/foo:/php/test.php/test/foo

Therefore, it is convenient to get the address of the current page using $_server[' php_self '):

$url = "http://". $_server[' Http_host '. $_server[' php_self '];

Above is the simple get HTTP protocol of the current page URL, just to note that the address is not included in the URL of the requested parameters (? and subsequent strings). If you want the full URL address that contains the request parameters, use $_server[' Request_uri '].

PHP $_server[' php_self ' security

Since the current page address can be easily obtained by using $_server[' php_self ', some programmers tend to use the following method when submitting form data to the current page for processing:

<form method= "POST" action= "<?php echo $_server[' php_self '];?>" >

Assume that the page address is:

http://www.php-note.com/php/test.php

To access this page, get the form HTML code as follows:

<form method= "POST" action= "/php/test.php" >

This code is correct, but when the access address becomes:

Http://www.php-note.com/php/test.php/test/foo/a=1

The page executes properly and the form HTML code becomes:

<form method= "POST" action= "/php/test.php/test/foo/a=1" >

Obviously, this has exceeded our expectations, the Web server actually did not produce errors such as 404 , the page was executed properly, and in the generated HTML code there is actually a user can enter the part of the scary place is here. Do not underestimate the "a=1", if you replace it with a JS code, it is more dangerous, such as call:

Http://.../test.php/%22%3E%3Cscript%3Ealert (' XSS ')%3c/script%3e%3cfoo

Did you see the effect of JS's alert function? Check the generated HTML source code to find out why.

Through this method of embedding JS code, the attacker can get 512~4k code space, and even can connect the external Web site's JS code or through the image to disguise the way JS code, so the length of JS code is unrestricted, and then through JS, They can easily get the user's cookie, or change anything on the current page, such as changing the destination of the form submission, changing what is displayed (such as adding a onclick= to a link address ...). Properties, so that when the user clicks on the execution of the attacker-specified code, or even to the site not the link itself, or even to make an Ajax effect is not necessarily, in short, do not ignore the power of JS.

Then, to look at the principle of this loophole, first test.php/.... This kind of call is allowed by the Web server, many CMS systems, such as the plog I used before, it seems to be in this way, in the case of the server does not support rewrite implementation such as http://. index.php/archive/999 such a fixed URL (I thought it was on the 404 error page under the hand), so the address with "/" cannot be banned from the Web server. Then look at the recognition of $_server[' php_self ' in PHP, he is a global variable containing the current URL value, God knows what user will enter what kind of URL, in the above example is malicious, but on Wikipedia such as the website, It is the address that can be used normally in this way. So, the final conclusion falls on the developer and does not have a good handle on the data that interacts with the user.

From a security point of view, in the development of applications, especially Web applications, all users submit data is not safe, this is the basic principle, so we have to bother with the client authentication is also server-side validation. In terms of this security vulnerability, there is a "url" added to the unsafe content. To solve the $_server[' php_self ' security risks, there are 2 main ways:

1, Htmlentities

Use Htmlentities ($_server[' php_self ') to replace the simple $_server[' php_self '], so that even if the URL contains malicious code, it will be "converted" To display the HTML code, Instead of being directly embedded in the HTML code to execute, simply say, "<" will become "&lt;" and become harmless.

2, Request_uri

Replace $_server[' php_self ' with $_server["Request_uri") and you can see the difference between the two variables in Phpinfo ():

$_server["Request_uri"]:/fwolf/temp/test.php/%22%3e%3cscript%3ealert (' XSS ')%3c/script%3e%3cfoo
$_server["Php_self"]:/fwolf/temp/test.php/">

$_server["Request_uri" will reflect the URL itself, if there is%3c in the URL, then you will be%3c, and $ _server[' php_self ' will be a urldecode operation of the site, the URL of the% 3 C will become the character "<", so a loophole is created. It is important to note that in many cases, the browser will encode the content that the user enters to submit to the Web server, and then the server-side program will automatically decode to get the corresponding reference, which is the case when we perform a post or get operation.

There are two points to be pointed out, the first is that this type of writing, although not directly used $_server[' php_self ', but the actual effect is the same, only the time of the error after the user submitted to the next page, so, the action of the form is not left blank. 2nd, in addition to php_self, other $_server variables may have similar vulnerabilities, such as Script_uri, Script_url, Query_string, Path_info, path_translated, etc. Be sure to make htmlentities or something before using them.

Extended reading:

$_server["Script_name"], $_server["php_self"], $_server["query_string"], $_server["Request_uri"]

An XSS vulnerability attack caused by PHP's $_server[' php_self ' and its solutions