Skip to main content
Information Security

Return to Question

added 32 characters in body
Source Link
SilverlightFox
SilverlightFox
  • 34.6k
  • 6
  • 76
  • 195

A logged in user can get to a page https://host/some/pagehttps://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 requestrequests to https://host/datahttps://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$"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 "reflection"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) but user explicit input is required (since no url can populate this field, for example), how should we evaluate the severity of this issue?

  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.

A logged in user can get to a page https://host/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 request to https://host/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 "reflection 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) but 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.

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.

Source Link
Alex F
Alex F
  • 133
  • 1
  • 3

Is it possible to exploit unescaped user input into JavaScript form which only gets data via AJAX request?

A logged in user can get to a page https://host/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 request to https://host/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 "reflection 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) but 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.