如何防范编码 URL XSS 攻击

Question

I got following 2 questions as:

1) How to protect from this kind of XSS Attacks?

https://www.example.com/index.php?&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041

If suppose for some reason, the query parameter is embedded in an image load event then it would be like this

<img src=x onload="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041">

//And browser treats as
<img src=x onload="javascript:alert('XSS')">

I am already using PHP's htmlspecialchars() and Filtar_var() with URL Sanitization, but this kind of encoded XSS will easily get pass through these functions

How can we defend such Encoded XSS or neutralize any such attack?

2) Is it necessary for an XSS attack to get embedded in HTML Page, Javascript or CSS etc in order to get triggered? or there can be a way where XSS does not need to be embedded?

Answer 1

htmlspecialchars is a perfectly good defence against XSS when you are inserting user input into an HTML document.

It stops any HTML syntax in the user input from breaking out of where you intend for it to go and being treated as JavaScript.

Your problem has nothing to do with the fact the attack is encoded. The problem is that are are putting user input somewhere that JavaScript is expected (and onload attribute) so it is already being treated as JavaScript .

json_encode is the usual solution here (and then htmlspecialchars because the JavaScript is inside an HTML attribute).

However, that only works when you are taking user input and putting it into a script to be used as data. Here it seems that you are taking user input and just treating the whole thing as a JavaScript function.

If you do that then you are going to be vulnerable to XSS. You can mitigate it to some degree by implementing defenses against CSRF, but you almost certainly shouldn't be doing this in the first place.