XSS in PHP: htmlspecialchars or the Apache URL Rewrite rule?

Question

I am not familiar with PHP and our product is not written in PHP. We use a vendor that creates for our documentation using PHP. Recently we discover XSX attack in the PHP code. The XSS attack was produced when an attacker access to

vendor.php/%22onmouseover=%22alert%281310%29%22

The regular access is like

vendor.php?param1=val1&param2=val2

After researching of the code I have found the problematic line:

$SelfURL = $_SERVER['PHP_SELF'];

I have fixed it using this great link PHP_SELF and XSS:

$SelfURL = htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, "utf-8");

We have send the fix to the vendor and asked to fix PHP. The answer surprised me: The vendor claims that their PHP is without any problem and that we should enable on our Apache server URL Rewrite rules that will not allow to access to pages like vendor.php/.

I has tried to explain, that we do not have URL Rewrite rules and only access to his page creates the attack (due to $SelfURL = $_SERVER['PHP_SELF']) Since I am not familiar with PHP I want to recheck:

1. Is it enough to use htmlspecialchars?
2. Should we create URL Rewrite rules?

Answer 1

Important is indeed to disallow access from certain files. You can do this with the .htaccess file and rewrite rules. But also always sanitize user input! Never take the risk!

Answer 2

Is it enough to use htmlspecialchars?

To solve the HTML-injection problem, yes. But if you've found one place where they have failed to HTML-escape content in such a trivial way, it would seem they don't have a consistently-applied approach to escaping... so it's very likely there are more.

Use of an automated scanner and/or superficial code review would be a next step to assess whether this is part of a bigger problem.

The vendor claims that their PHP is without any problem

This is not a sign of a responsible attitude to security. Not encouraging at all.

we should enable on our Apache server URL Rewrite rules that will not allow to access to pages like vendor.php/

Don't you need access to that page?

If they have supplied you with a set of admin pages that is not supposed to be accessible, then they need to document what pages are involved so you can remove access to them.

You wouldn't normally use a rewrite to block access to a page. It would make more sense to use a Deny directive, or - best of all if possible - simply remove the offending page from the deployment.