3

A logged in user can get to a page https://example.com/some/page which has an input field and some buttons. When user enters something into this field and clicks away on anything, the page makes requests to https://example.com/data to check if requested object is available and returns false if not.

In this case the page renders warning like Can't find $User Input$. So if users enters something like <script>alert(1)</script> it will indeed attempt to render it and display an alert. What is called "reflected XSS", I believe.

So here is the question. In the described example were

  1. We clearly have unfiltered input field exposing reflection XSS vulnerability.
  2. However, user explicit input is required (since no url can populate this field, for example), how should we evaluate the severity of this issue?

My general understanding is that even if I personally don't know how (if possible) one can use this exploit, I still should treat it as a critical vulnerability. But I lack I arguments to prove it for triage.

Improve this question

4 Answers 4

Reset to default
1

There's not enough information provided to correctly diagnose whether this is a vulnerability or not.

If it was possible to trick a user into making the request directly to /data and include the malicious payload (<script>alert(1)</script>), then yes it would be a vulnerability if the alert box appeared.

For example by tricking the user into visiting the attacker's site which contains a redirect to https://example.com/data?<script>alert(1)</script> or contains a form that POSTs to https://example.com/data with the request body set to data=<script>alert(1)</script>.

This would hinge on whether /dataresponds to none-AJAX requests also. Additionally, the content type returned would need to be text/html for any script to be rendered and executed by the browser.

Also, your payload might only be rendered with a form encoding type of application/json. If the /data handler only responds to requests with this encoding type then it is impossible to make these requests with a <form> tag.

If it is still renders the response with a different content-type specified, then you may be able to get it to render by "tricking it" with a text/plain form:

<form enctype="text/plain" method="post"> <input type="hidden" name="{&quot;data&quot;: &quot;<script>alert(123)</script>&quot; }//" value="" /> <input type="submit" /> </form>

The other avenue to explore is whether you can get /some/page to pre-populate the textbox with your payload. Try common parameters such as:

  • https://example.com/some/page?data=<script>alert(123)</script>
  • https://example.com/some/page?value=<script>alert(123)</script>
  • https://example.com/some/page?<script>alert(123)</script>
  • https://example.com/some/page?debug=<script>alert(123)</script>
  • https://example.com/some/page?test=<script>alert(123)</script>
  • https://example.com/some/page?id=<script>alert(123)</script>
  • https://example.com/some/page?etc=<script>alert(123)</script>

Have a look what you've observed on the rest of the site (e.g. check Burp's sitemap) and make a list of commonly used parameter names.

See here for my answer to a similar question.

If you cannot check these things yourself then you would need somebody with web security skills to verify whether this is a vulnerability or not. If it is not possible to hire somebody, then you would be best hedging your bets and fixing it anyway.

Improve this answer
1
  • Thanks for the comment. Got some good ideas from it. The specifics of the this page is that the page by itself (example.com/some/page) does not accept any parameters - I tried your examples as well just in case. And data request from this page to example.com/data is pretty solid, it does not returns any user input. So the only way to expose it is to manually enter "bad input" to the field so that JS on the page generate error message with user's input. From your answer it looks like one would not be able to exploit it indeed. Commented Jul 10, 2015 at 21:15
0

Something to think about is whether a malicious person could essentially trick the user into visiting a site which would mimic/cause the form to be submitted with the malicious user's input of choice (say, exploiting a cross-site request forgery vulnerability at the same time). It's not all about just generating a URL. In that case, the user could be tricked into running a dangerous piece of code in their browser. I am not sure what your app looks like or does, but for the sake of your assessment & recommendation, consider whether there are other vulnerabilities present that might exacerbate the issue.

Improve this answer
0

The biggest risk I see is if alert(1) can be crafted inside an url.

  1. User logs in at https://example.com/some/page
  2. While session at example.com is still valid user clicks a random link from a forum that goes to: https://example.com/some/page?action=alert(1)
  3. User executes potentially malicious code in the context of your website
Improve this answer
0

This allow the user to execute js as anyone who will see the message unfiltered, so in theory if he is the only one who will be able to see this message this isn't a problem but for any form which store data visible by other user it is a problem.

But like said before it permit to any site your client will visite to execute js code inside your client session for your website. how to do this :

  1. link with param for get
  2. 303 with location = get with param
  3. html form post ( you can post on any domain using html form)
  4. ajax call if client set same origin policy off
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.