2

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?

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

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

<?php
$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.

0

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 '14 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 '14 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 '14 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.