2

On the OWASP site on XSS it says that it is safe to put userdata in GET parameter values when encoded.

However, userdata should not be used anywhere else, so not in the scheme, the domain or parameter names. Unfortunately I can't find any clues why it would be unsafe in parameter names.

Can anyone show me an example or explanation of what might happen if you do? Obviously I would still use url encoding on the parameter name.

5
  • Well parameters are stored in browser history, visible in server logs and shown in the referer header (which may be populated if you click on a favorite in your browser from the actual page). – Tensibai Jul 21 '17 at 8:01
  • Found back a blog post about it: blog.httpwatch.com/2009/02/20/… – Tensibai Jul 21 '17 at 8:03
  • Perhaps I should clarify the question: I'm not talking about sensitive data in URL's. I know that that's a bad idea. It more about the server creating a webpage that contains an a tag and in the href a URL which contains user data. The owasp page says it's safe to use user submitted data for the parameter values when encoded properly, but apparently it's not recommended to use user data in other parts of the URL. I want to know why that is. Is there a risk of XSS when putting user data elsewhere in the URL? – Myrddin81 Jul 21 '17 at 8:31
  • If it's a href, it can be abused, the user may enter a '/><?php mailicous code ?> which will be evaluated by the server (php is the first coming to my mind but other code may work if they are nothing preventing a well crafted input to be executed) if they are not just the values of parameter but 'free form'. – Tensibai Jul 21 '17 at 8:41
  • If I put the URL in a href I would also html encode the url, avoiding this type of attack. – Myrddin81 Jul 21 '17 at 11:40
1

In the scheme, an attacker could use the javascript protocol to perform XSS:

<a href="javascript:alert(1)">click</a>

The data protocol could also be used in attacks.

Apart from that, OWASP is not really talking about domain or parameter names here, as this guide is strictly about defending against XSS in different contexts. Depending on your application, you might still want to have control over it though, but that's not relevant to XSS.

Regarding XSS, parameter names are not special and can be treated the same way as parameter values. OWASP probably does not mention them explicitly because user-supplied parameter names are not very common.

1
  • Your explanation makes sense. OWASP could be more specific in their explanation on where is it safe to use (encoded) user data, and where not. As long as I don't see any exploits in parameter names, I'll just assume it's bad practice or uncommen and not necessarily unsafe. – Myrddin81 Jul 21 '17 at 11:39
0

The userdata will be visible in the url, if any crutial data was passed within any control then it's not secure.

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.