I found an XSS vulnerability which is exploited by appending attack in the URL parameters.
For eg. the original URL site.com/?s=login&m=forgotten
And the attack URL site.com/?s=login&m=forgotten" onload=alert(966) bad="
Now I would like to prevent this attack. Can anybody help me?
Sanitize your input, by escaping HTML special characters. In PHP this is done with htmlspecialcharacters. Make sure you do not supply a flag that prevents htmlspecialcharacters from escaping the type of quote you use.
Your problem is your URL is http://example.com/?s=login&m=forgotten" onload=alert(966) bad=", which your PHP code which is probably something like this:
<?php
$var = $_GET['m'];
echo '<a href="$var">something</a>';
but on straight simple substitution with the bad input becomes:
<a href="forgotten" onload=alert(966) bad=">something</a>';
The problem arises from the unescaped ". The sanitizing PHP function htmlspecialcharacters will change the " to a " so with:
<?php
$var = htmlspecialcharacters($_GET['m']);
echo '<a href="$var">something</a>';
the rendered HTML will be:
<a href="forgotten" onload=alert(966) bad="">something</a>';
which your browser will interpret as one giant link to forgotten" onload=alert(966) bad=", instead of an html tag containing the onload attribute.
Personally, I'd move away from PHP and to a web framework that starts with security in mind; e.g., automatically HTML escapes all input from database and query parameters in templates (unless specifically marked otherwise), does CSRF checks by default, use query parameters, etc.
javascript:alert(1) in href or src HTML attribute, like mentioned by @oriadam. Here is a solution for this, by checking the protocol with the parse_url PHP function: stackoverflow.com/questions/19047119/…
By prevent, do you mean a code fix, IDP rule, something else? Assuming code fix, then what language is it written in, what framework, etc?
In general, what you'd need to do in the code is everywhere where data (especially coming from user input) is written back out, that the data is properly escaped in its context (be it HTML, URL, JavaScript, etc) of where it is being written.
Looking at your attack vector, it sounds like submitted query string is automatically appended to a generated anchor tag. If so, the potential fix is to either properly parse query string context into a collection of key-value pairs, and then properly serialize collection, or properly escape all the characters that let you break out of HTML's attribute value context. That said, it really depends on the context of how the code is written, where, what, how, when, etc... So your question is a bit vague in order to provide concrete answer.
javascript:alert(966)