Comments on: A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written

By: PHPMailer - serverseitiges validieren der Eingabedaten nötig? - Seite 2 - php.de

PHPMailer - serverseitiges validieren der Eingabedaten nötig? - Seite 2 - php.de — Mon, 06 Feb 2012 14:28:57 +0000

[...] Warum wird $_SERVER['PHP_SELF'] immer als Standard für das Affenformular angegeben? Unter http://www.webadminblog.com/index.ph…-ever-written/ wird $_SERVER['SCRIPT_NAME'] als Alternative vorgeschlagen. Für einen Anfänger nur Mit leerem [...]

By: meh

meh — Tue, 10 Jan 2012 21:14:57 +0000

or just simply use

By: Josh

Josh — Fri, 13 May 2011 15:03:12 +0000

Lea, some of the newer browsers have built in some XSS defenses. The newer versions of IE, for example, will display a message in the bar at the top saying that it blocked a potential XSS attack. Also, my example is just a sample of what a URL would look like but it does not actually exist which could also be creating issues. In any case, yes there are browsers that are vulnerable to XSS and the only way to completely prevent a XSS exploit from an end-user perspective is to turn off JavaScript in your browser. Unfortunately, that breaks a good portion of other web functionality as well.

By: Max

Max — Wed, 11 May 2011 19:21:07 +0000

Thanks for the “$_SERVER['SCRIPT_NAME']” pointer – so simple – cannot believe that had not occurred to me…

By: Ben Johnson

Ben Johnson — Fri, 29 Apr 2011 22:06:31 +0000

Right, I get it now, thanks for the clarification. Very dangerous stuff.

By: Lea

Lea — Wed, 27 Apr 2011 01:03:04 +0000

Not following this at all – when I tried it, the page failed to load as that url didn’t exist.
Did you mean to make it a parameter?
eg
http://www.webadminblog.com/example.php?“>alert(‘xss’);
But when I tried that, the browser encoded the brackets. Are there browsers that don’t do that?

Fortunately, I still know I haven’t made this mistake – the first thing I do is check that the path is the correct one, and 301 to the proper page if it isn’t. I do this for SEO reasons; its nice to know its helped security

By: Josh

Josh — Tue, 26 Apr 2011 20:49:48 +0000

Ben, the idea behind reflected cross-site scripting is that the attacker crafts a malicious URL and then tries to manipulate the victim (usually via some form of social engineering) into clicking on the link. So if you take my example above using http://www.webadminblog.com/example.php“>, you’d see that if someone were tricked into going to that URL, they would indeed trigger the JavaScript which was embedded into the link. So the user is not falling into their own XSS as you put it, they are falling into the attackers. The real issue behind this attack, however, is that the script gets executed within the victim’s browser. This means that the attacker could steal the victim’s cookies, use their login credentials to make requests (CSRF), create fake login forms, change page content, etc. Does that make sense?

By: Ben Johnson

Ben Johnson — Tue, 19 Apr 2011 22:44:35 +0000

Am I missing something?

If the user knowingly manipulates $_SERVER['PHP_SELF'] in the context of submitting a form then all they can do is inject Javascript into a page that only they themselves are viewing.

That must be a proud moment when you fall to an XSS attack of your own doing?

By: Matt Smith

Matt Smith — Mon, 22 Nov 2010 00:26:04 +0000

Great post, very helpful. I have created several projects in much the same way. Thanks for the insight regarding $_SERVER['SCRIPT_NAME']. There are a lot of similar posts out there, but very few of them explain or even suggest using SCRIPT_NAME instead of PHP_SELF.

By: Josh

Josh — Fri, 12 Nov 2010 14:43:17 +0000

I’m not exactly sure why a script having a form that posts to itself would be considered a vulnerability in and of itself, but without proper input validation and output encoding, there’s a high likelihood that you’ll find actual vulnerabilities in that script.

~josh