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 /data
responds 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="{"data": "<script>alert(123)</script>" }//" 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.