1

So I am pretty sure I know the answer to this question but I want to be 100% sure so I am looking for some input here. A vulnerability was reported to a site of mine that looks something like this:

GET mysite.com/page<script>alert('XSS');</script>

If you use curl you can see the payload in the response, likewise, if you intercept a browser request with a proxy and edit it to the above payload it will execute.

However, the backend isn't decoding the URL. If this link is posted on some forum and clicked, the browser will encode the url and the response will look like this:

.... mysite.com/page%3Cscript%3Ealert(%27XSS%27)%3B%3C%2Fscript%3E ....

This obviously does not execute. To me, this poses no threat whatsoever because the only way to execute it successfully is with a MITM attack. If there is somebody sitting on the network that can see the traffic and edit it, there would be no point in exploiting XSS because you have everything you want anyway.

Is this a correct analysis? Is there anyway to get a user to click on a link or post some form that doesn't encode the URL that I am not aware of?

user3632719
  • 129
  • 4
  • 1
    To rely on implementation details (whether or not all browsers encode all urls they open) of other products is not "my product is not vulnerable". How about just fixing the problem you're obviously having? – Tobi Nary Mar 31 '16 at 19:20
  • What I'm wondering is if there is some way to make an ajax call or something like that which can make this execute. It will be fixed and addressed. I like to fully understand the potential impact of things. This is where the question is coming from. It is not process-oriented. – user3632719 Mar 31 '16 at 19:21

2 Answers2

2

Your analysis is incorrect.

Not all browsers do that, as some googling spits out an excessive blog post that seems relevant.

The blog post is old and IE is old, but this should be enough proof that not all browsers encode this, as you expect.

So: it is a real vulnerability, it poses a thread to your users.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • Thank you. This is exactly what I was looking for. Much appreciated! – user3632719 Mar 31 '16 at 19:29
  • Great answer. I was wondering how to exploit this myself since my answer [here](http://security.stackexchange.com/a/98111/8340) and have since come across it professionally. Edit: Actually the question on my linked answer says it does work on IE. Thanks for reminding me. – SilverlightFox Apr 01 '16 at 09:16
-1

You're confusing what XSS is, and what it does, I suggest reading the following. The XSS is being executed on the viewer's system, not the server. The goal is to leverage your server to disaffect whoever visits it. Let's explain with an example: An attacker injects malicious code to exploit say IE8. When someone visits your server, or a forum, or gets tricked into opening the link (if they trust your site/visit your site) code will be run on their system, and if their browser is vulnerable, they can now be exploited because of your site.

Now, let's further refine this into weaponizing it, to where you don't need someone to click a link. Older versions of Macromedia Flash had a command called "getURL" which would force a browser to open a page period. Unlike java/javascript, it did not warn you a page would open. What does that mean? If your website allowed for say animated flash embedding, an attacker could easily trigger this without any user intervention.

The attack (XSS) isn't aimed at your server, it is aimed at someone who is visiting your server.

munkeyoto
  • 8,682
  • 16
  • 31
  • 1
    Thank you. I do fully understand this. The situation here is that the server responds with something that won't be executed in the browser. I'm wondering if there is a way to change that in a real world scenario. – user3632719 Mar 31 '16 at 19:27
  • 1
    I don't think this is an answer to OPs question. Consider removing it:) – Tobi Nary Mar 31 '16 at 19:29