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?

  • 1
    Note that the attacker can also set the url to javascript:alert(966)
    – oriadam
    Jul 9, 2017 at 10:53
  • XSS in “the URL” is usually referred to as XSS through GET parameters.
    – CoderPE
    Nov 15, 2018 at 21:22

2 Answers 2


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:

$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 &quot; so with:

$var = htmlspecialcharacters($_GET['m']);  
echo '<a href="$var">something</a>';

the rendered HTML will be:

<a href="forgotten&quot; onload=alert(966) bad=&quot;">something</a>';

which your browser will interpret as one giant link to forgotten&quot; onload=alert(966) bad=&quot;, 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.

  • 1
    This does not prevent an XSS attack like 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/…
    – baptx
    Jul 20, 2019 at 11:36

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.

  • I apologize for that.My code is written in PHP. I think the vulnerable code is <form accept-charset="UTF-8" action="?s=login&amp;m=forgotten" method="post" id="form_forgotten" class="form">. Can i do anything here?
    – Vishal
    Apr 2, 2014 at 15:02
  • what you showed is HTML (good), but how is that HTML generated is what's important. Can you amend your post with php code that generates that HTML. (b/w I've never code in PHP, so others may need to give input on proper escaping functions)
    – LB2
    Apr 2, 2014 at 16:05
  • The html code mentioned in the comment is used to generate form.so it is html not php that is generating the form.
    – Vishal
    Apr 2, 2014 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .