This is not a cross-site script (XSS) attack. This is you editing the page inside your own browser to attack yourself. You can try to write down and publish the necessary instructions how each victim can attack itself but this is not cross-site and not even a real attack. This is more like telling someone how he can shoot himself.
A URL cannot run anything. A URL is just a string. How an URL can be used or abused depends on the context and application where it is used.
Your specific case is about an XSS vulnerability in the web application where parts of the URL where embedded in the HTML page in a context which triggered the ...
tl/dr: You simply can't protect other systems from malicious input.
Protecting against injection attacks depends too strongly on the way
in which the data is used. The best you can do is try to prevent
obvious malicious payloads from sneaking in, but even your proposed
white list can leave severe vulnerabilities if the application on the
As you pointed out, it is also ...
For this case the main solution is to bypass the filter in the web page, encoding then pushing the payload into the URL will not work as I tried too many times and mainly the the script that will be decoded will be an printed in the web page and stored as a comment.
The filter as it filter any payload injected after the 'p=', even double encoded payload ...
First method :
To bypass this filter you need to comment the rest of your request at the end by adding //, However, in some XSS challenge they add '\' before '/' so you cannot bypass the filter using this method ("http://sudo.co.il/xss/level5-2.php?p=test") :
To get the following :