Cross-site Scripting (XSS) and exploiting $_SERVER[‘PHP_SELF’])

Cross-site Scripting (XSS) and exploiting $_SERVER[‘PHP_SELF’]) is a fascinating topic. Let’s explain it a little.

What is Cross-site Scripting (XSS)?

When we refer to XSS attack or XSS hack, we commonly talk about client-side code injection attack.

It’s a type of attack, where a hacker can find a vulnerability in our system (similar to above-mentioned unsanitized $_SERVER[‘PHP_SELF’]) and use it to inject and then execute his malicious script, often called ‘malicious payload.’


How can we use Cross-site Scripting attack to exploit $_SERVER[‘PHP_SELF’])?

$_SERVER[‘PHP_SELF’] is dangerous if misused. Especially in HTML forms, where nearly any arbitrary string can be posted to a website by using $_SERVER[‘PHP_SELF’]. This can be used by an attacker to perform XSS attacks.

To better explain it, let’s create a xssAttack.php file and add the following HTML form that uses PHP:

You may say, this is a perfect way of using PHP to ensure that form (upon submission) will always post the content to itself.

And you’d be right, if you were to visit the page at: http://localhost/xssAttack.php it would all work exactly as intended.

However, if you were to visit http://localhost/ xssAttack.php/”><script>alert(‘you were hacked’);</script> then the rendered HTML will be:

It’s very bizarre that PHP doesn’t automatically strip any malicious content that could enter PHP_SELF.

As you can see, this is exactly how $_SERVER[‘PHP_SELF’]) can be misused to allows XSS injection. As a matter of fact, this is one of the easiest way to insert an arbitrary script to any website, because site will contain not just xssAttack.php, but the entire xssAttack.php/any arbitrary_string.


How to fix $_SERVER[‘PHP_SELF’]) XSS issue?

There are a couple of ways to prevent misuse of $_SERVER[‘PHP_SELF’].


Use $_SERVER[‘SCRIPT_NAME’] instead of $_SERVER[‘PHP_SELF’].

$_SERVER[‘SCRIPT_NAME’] contains only the current script’s path. This is much more useful for pages which need to point to themselves, such as outlined in my example, and attacker wouldn’t be able to manipulate it.


Use htmlspecialchars($_SERVER[‘PHP_SELF’]).

htmlspecialchars() will convert special characters to HTML entities, escape double-quotes and prevent a user-supplied string from breaking out of an HTML attribute context.

Can I use htmlentities(), strip_tags() or stripslashes()?

If our goal is just to protect the page from Cross Site Scripting (XSS) attack, then using htmlspecialchars() is good enough, better and also faster than using htmlentities(). Note, that “when we use htmlspecialchars($s) in our code, it is automatically compatible with UTF-8 string. If we use htmlentities($s), and there happen to be foreign characters in the string $s in UTF-8 encoding, then htmlentities() is going to mess it up (unless you are specifically providing an “UTF-8” argument to it” Group, T.P. (2001)

Other functions that are available and often used are strip_tags (returns the stripped string from HTML tags) or stripslashes (returns a string with backslashes stripped off). These two are used to filter out certain characters out of a string, but you’d be generally good if you just use htmlspecialchars to escape any characters that could delimit HTML tags.



FILTER_SANITIZE_STRING filter strips away any code that could be injected into PHP by an intruder.



XSS Attack – Dangers and Prevention

A long time ago, at the time when JavaScript was first introduced, attackers had to manually find a way to inject a payload into a web page in order use XSS attack, but that has changed dramatically since then. Nowadays, attackers use automated vulnerability scanners to find the XSS and other holes in our code. And once the XSS vulnerability is found attackers often use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload.

According to the Hosted Application Scanning Management team at IBM, “17 percent of some 900 dynamic Web application scans showed a vulnerability to XSS. However, this data came from organizations with the most robust and mature security practices. A study by White Hat Security finds that nearly half of all sites (47.9 percent) are vulnerable to XSS attacks.” (Robinson, R.M., 2015)

The best idea generally to prevent these issues, is to use a Web Application Vulnerability Scanner, a tool that scans not only for XSS attacks but for all types of online attacks. “Web Application Vulnerability Scanners are automated tools that scan web applications, usually from the outside, to look for security vulnerabilities such as Cross-site Scripting, SQL Injection, Command Injection, Path Traversal and insecure server configuration.” (Vulnerability scanning tools, 2016). These tools are typically used by organizations before they deploy the code to production, as part of their vulnerability management to prevent unauthorized online access.

However, it’s not always easy to find the exposures in our code, and not everyone knows where and how to get and deploy automatic vulnerability scanning. For those of us, who suspect their system is only susceptible to XSS attack; the good idea is to use an online scanning resource such as, a website that offers free scan for XSS vulnerabilities (XSS scanner, 2016). It may not be perfect, but as “XSS is amongst the most rampant of web application vulnerabilities and occurs” (Acunetix, 2016), it could be the easiest way to run a quick scan.



Acunetix (2016) What is cross-site Scripting and how can you fix it?. Available at: (Accessed: 8 December 2016).

Robinson, R.M. (2015) Cross-site Scripting attacks pose ongoing threat. Available at: (Accessed: 8 December 2016). XSS scanner (2016)

Free online XSS scanner. Available at: (Accessed: 8 December 2016).

Vulnerability scanning tools (2016) Available at: (Accessed: 8 December 2016).

$_SERVER[’PHP_SELF’] and cross-site scripting (2009) Available at: (Accessed: 8 December 2016).

Group, T.P. (2001) PHP: Htmlspecialchars – manual. Available at: (Accessed: 8 December 2016).