XSS attacks against $ _ server ['php _ Self ']

Although the current web servers and development tools will not show any obvious vulnerabilities like ASP's % 81, however, some strange vulnerabilities caused by developers' negligence and combinations of various language features still exist. The XSS woes that we accidentally read today details a dangerous vulnerability related to $ _ server ['php _ Self.

$ _ Server ['php _ Self '] is often used during development. It is generally used to reference the current webpage address and is a global variable automatically generated by the system. Is there any problem? Let's take a look at the following code:

<Form action = "<? PHP echo $ _ server ['php _ Self '];?> ">
<Input type = "submit" name = "submit" value = "submit"/>
</Form>
This code is very simple. We want to use $ _ server ['php _ Self '] to submit a webpage to itself when submitting the code. Suppose the code file name is test. PHP, will we get the desired address during execution? First try the address http ://... /Test. php, the result is certainly correct. Don't worry, visit http ://... /Test. php/a = 1, the following client code will be obtained:

<Form action = "/fwolf/temp/test. php/a = 1">
<Input type = "submit" name = "submit" value = "submit"/>
</Form>
Obviously, this is beyond our expectation. The web server does not produce errors such as 404, and the page is executed normally, in addition, the generated HTML code contains some parts that can be entered by the user. This is where the terror lies. Don't underestimate the "A = 1". If you replace it with a piece of js code, it is more dangerous, such as calling this method:

Http ://... /Test. php/% 22% 3E % 3 cscript % 3 ealert ('xss') % 3C/script % 3E % 3 cfoo
Have you seen the effect of alert function execution in JS? Check the generated HTML source code to find the cause.

By embedding JavaScript code, attackers can obtain 512 ~ 4 K code space, you can even connect to the JS Code of an external website or disguise the JS Code through image calling. In this way, the js code length is not limited, and then through JS, they can easily retrieve users' cookies or change any content on the current page, such as changing the form submission destination, change the displayed content (for example, add an onclick =... In this way, the user will execute the code specified by the attacker, or even connect to a website that is not the link address itself), or even make an Ajax effect. In short, do not ignore the power of Js.

So let's take a look at how this vulnerability works. First, test. php /.... This kind of call is allowed by the Web server. Many CMS systems, such as the plog I used previously, seem to adopt this method. When the server does not support rewrite, implement such http: //... /Index. fixed URLs such as PHP/archive/999 (I used to think it was for the hand under the 404 error page), so the address with "/" cannot be banned from the web server. Then let's take a look at the recognition of $ _ server ['php _ Self '] in PHP. It is a global variable that contains the current URL value. God knows what kind of website the user will enter, in the above example, It is malicious, but on websites such as Wikipedia, this method of address can be used normally. Therefore, the final conclusion falls on the developer, and the data that interacts with the user is not well processed.

From a security perspective, when developing applications, especially web applications, data submitted by all users is insecure. This is the basic principle, therefore, we are not tired of client verification and server verification. In terms of the security vulnerability mentioned above, the "website" will be added to the insecure content. To solve the security risks of $ _ server ['php _ Self '], there are two main methods:

1. htmlentities
Use htmlentities ($ _ server ['php _ Self ']) to replace simple $ _ server ['php _ Self'], so that even if the website contains malicious code, it will also be converted to HTML code for display, rather than directly embedded into HTML code for execution. Simply put, "<" will become "& lt ;", it becomes harmless.

2. request_uri
Use $ _ server ['request _ url'] to replace $ _ server ['php _ Self ']. You can see the differences between the two variables in phpinfo:

_ Server ["request_uri"]/fwolf/temp/test. php/% 22% 3E % 3 cscript % 3 ealert ('xss') % 3C/script % 3E % 3 cfoo
_ Server ["php_self"]/fwolf/temp/test. php/"> <SCRIPT> alert ('xss') </SCRIPT> <foo
$ _ Server ['request _ URI '] does not cover the website itself. If % 3C exists in the website, you will also get % 3C, $ _ server ['php _ Self '] performs a urldecode operation on the URL. The % 3C character in the URL is changed to the character "<", which leads to a vulnerability. Note that, in many cases, the browser will encode the content that the user inputs to be submitted to the Web server, and then the server-side program will automatically decode to obtain the corresponding original meaning, this is the case when we perform post or get operations.

There are also two points to note: the first is <form action "> although this method does not directly use $ _ server ['php _ Self '], the actual effect is the same, only when an error occurs, the next page after the user submits the request. Therefore, do not leave the form action blank. Second, 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, before using them, you must perform conversions such as htmlentities.

Finally, provide an address with many XSS examples, which can be used as a negative teaching material or test tool:
XSS (Cross Site Scripting) cheat sheet
Http://ha.ckers.org/xss.html