There is a reflected XSS flaw in an application I am testing. Initially, the payload is sent in POST request as value of a JSON key and the response is also a JSON object. The returned value in the JSON object is directly used by client side Javascript and hence the flaw. My questions is, I tried all ways given on this page to send a JSON payload through HTML form but I failed as the server is properly validating the input. Is there any way this XSS flaw can be exploited? Also, GET method on same URL does not work.
1 Answer
The article is proving that an HTML form can be used to send a JSON object via CSRF, even if the server-side is only accepting text/plain requests expecting JSON.
(instead of the typical application/x-www-form-urlencoded) requests.
I've included the linked example on this site, because we do not allow link-only content.
<html>
<form action=http://192.168.1.41:3000 method=post enctype="text/plain" >
<input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>
<input type=submit>
</form>
</html>
results in a request looking like
Based on your comments I now understand that you are asking about Reflected XSS attacks.
The payload is returned unchanged in a JSON response.
Is there any HTML involved?
If so, then it all depends on how it is encoded as to whether you have an XSS vulnerability.
On the other hand, if this is simply an "echo" with no added HTML, then it depends on your response headers. Content-Type: text/html should be sufficient to keep the response from being executed as code, but in some browsers, it would still be vulnerable. Content-Disposition: attachment would solve the problem assuming the filename extension and content types are safe. (i.e. txt)
if the payload can't be sent via HTML forms, does that mean XSS is not "exploitable" ?
if one can't create an HTML form (with JSON payload which is accepted by server) , then this XSS is not exploitable right ?
However, with a question like that, it sounds like you are about to 'shoot yourself in the foot' by locking into an 'easy' answer. I am worried just because I don't understand why you are asking that question.
- Warning: With an HTML form it may be possible to send the required JSON payload based on the specifics of the server validation you are using.
I'll answer you anyway:
Supposing that an HTML form is insufficient (meaning you've already disproved my warning), and Query String is also not sufficient (true in your case); then Reflective XSS attacks would not be possible.
- The attacker would be left only with AJAX as a possibility, as well as various plugins that might be able to initiate CSRF. Stored XSS might still be possible in that situation, if your server has more advanced features beyond "echo" of the request.
Additional info:
There are three avenues that come to mind for XSS. Only items 2 and 3 require 'payload of your choice' to be uploaded via CSRF.
Items 1 and 2 apply to a Stored XSS attack which involves inserting code into one of the text fields of the server's database, such that when the server shows the results later it might be executed in the Browser due to missing/improper encoding (XSS vulnerability) by the server.
If you have appropriate credentials, or it is a public facing site (i.e. Stack Exchange comments), then anyone (even the attacker) can insert the code directly.
Then if the system were vulnerable (incorrect/missing encoding) then future visitors viewing the submitted content would be victims of the attack.
If this was a closed system, such that the attacker would not have the appropriate login credentials for the submitted data to be accepted into a database, then the attacker would have to use a CSRF to take advantage of another user's credentials (assuming the user is already logged in to the target system when visiting the attacker's site)
For Reflective XSS, you would need #2 CSRF for this. In this case the data need not be stored, but you are taking advantage of a situation where input data is returned back to the user.
- i.e. a Preview page,
- or a refreshed form with values pre-filled
- an error page that includes user content (i.e. X is an invalid email address)
Stored XSS may be preferable for the attacker to reach a broader audience. There is the possibility also that a given system is not vulnerable to Stored XSS, but still may be vulnerable to Reflective XSS.
answered Jun 16, 2016 at 14:17
-
Hi , I am aware that the article is about CSRF. My point here is, to execute the XSS attack, the victim needs to send a payload of my choice. This payload needs to be sent via JSON. So, the question is , if the payload can't be sent via HTML forms, does that mean XSS is not "exploitable" ?– entropyCommented Jun 16, 2016 at 14:48
-
1"An XSS attack involves inserting code into one of the text fields of the server's database"- That is stored XSS. I think the OP is trying to do reflected XSS, but since the vector is POST and not GET a form needs to be involved.– AndersCommented Jun 16, 2016 at 21:19
-
@Anders I think you understodd my question.Let me clarify things a little bit: 1. Payload is sent via JSON in POST paramaters. 2. The payload is returned unchanged in a JSON response. 3. JSON value is used by client side javascript directly and the payload gets executed . In my opinion, this is a DOM based XSS ( as the reflecttion of payload in response does not cause the execution of script, handling of payload by javascript does. ) SO, if one can't create an HTML form (with JSON payload which is accepted by server) , then this XSS is not exploitable right ?– entropyCommented Jun 17, 2016 at 13:35
-
@entropy, I apologize I did not catch onto "payload is returned unchanged " earlier. I've updated my question. See just below the screenshot for your answers. Commented Jun 17, 2016 at 14:20
-
@GeorgeBailey Of course JSON payload can be sent via HTML form. The problem here is that it is not accepted by the server (see why the techniques fail in the link in original post) . SO , my concern is , XSS not exploitable ( as the JSON payload sent via custom HTML form using tricks given in the link is not accepted by the server )– entropyCommented Jun 17, 2016 at 14:28
application/json, which cannot be sent cross-domain without enabling CORS, therefore it may not be exploitable unless you have another way of manipulating the input sent.