12
An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.
So you don't just need to look at what the server does, you also need to look at the application which consumes that JSON response.
Is there a ...
11
This isn't vulnerable to XSS since the Content-Type is set to application/json and thus no Javascript will be executed by all major modern browsers. If you do some fancy Javascript stuff with the JSON response, it could become a DOM XSS (but this doesn't seem to be the case here from what you shared).
A more detailed answer can be found here.
5
Creating the DOM as string and using append or html indeed leads to DOM-based XSS. What you should do instead is to built the DOM elements using the proper functions and only inserting user-supplied input as text. Example:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
<ul id=my_list class=my_list>&...
5
This looks like a finding that many automated scanners will find: they put something in the URL and see it reflected back in the response body.
In your case, this is reported back in valid JSON and therefor this is not an issue. While not clean as a whistle, you'll be hard pressed to find a browser or API consumer that fails on the text in there. For all ...
3
As it is right now, no. All that has happened is a client placed a bespoke string in a JSON response. For XSS to occur, a bespoke string must be written to an unsafe resource (an HTML file).
If you have a webpage which for whatever reason prints the path of this request (maybe a request logging page), you could have something nasty. For example, this code ...
2
Well, this regex is simple enough to be sure that you won't be able to inject any special character in your input. You won't be able to perform any XSS, unless there is another vulnerability elsewhere.
1
From your description, it seems that example.com is properly handling the user-supplied value (ie you are not injecting into the given script / e.src, which is why what you tried didn't work). You can inspect the DOM of example.com to verify this.
Instead, example.com treats the value properly as string and passes it on to tracking.com which in turn handles ...
1
Unfortunately since it is prepending a path, there's not much which can be done if you can't escape from the tag. If you had FULL control over the input to the action parameter, then it'd be a different story.
You could achieve XSS here by injecting javascript URI. Here's an example:
javascript:alert(document.cookie);
Here's an example code snippet to ...
Only top voted, non community-wiki answers of a minimum length are eligible
