4

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.

entropy
  • 362
  • 3
  • 10
  • 2
    "Properly validating the input"? What have you tried, and how exactly does it fail? It could be that the handler is explicitly checking for content-type `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. – SilverlightFox Jun 17 '16 at 09:05
  • @SilverlightFox Yes, the server is properly validating the input. In other words, I failed to send a JSON payload using HTML form as given in the article in my original question. ALso, I can't send AJAX request as CORS doesn't allow it. Does it mean that XSS is not "exploitable" ? – entropy Jun 17 '16 at 14:30
  • If it's reflected XSS, then no it doesn't appear so from the information given. – SilverlightFox Jun 17 '16 at 14:33
  • @SilverlightFox server is not checking for content-type but it is properly checking the JSON input format. Please see the article in my question to understand why the techniques might fail. :) – entropy Jun 17 '16 at 14:36
  • @SilverlightFox Would this flaw fit in exact definition of reflected XSS ? or can we call it combination of DOM based and reflected XSS ? – entropy Jun 17 '16 at 14:44

1 Answers1

2

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.

  1. 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.

  2. 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)

  3. 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.

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • 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" ? – entropy Jun 16 '16 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. – Anders Jun 16 '16 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 ? – entropy Jun 17 '16 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. – 700 Software Jun 17 '16 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 ) – entropy Jun 17 '16 at 14:28
  • @GeorgeBailey you need to see that article again. In scenario 1, a "=" is appended at the end while in scenario 2 an extra parameter is added . Both inputs are not accepted by server. I mean no offense, but you should try to understand the question completely before trying to answer. – entropy Jun 17 '16 at 14:33
  • @entropy, Thank you for you understanding. *"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"* Just because **you failed when you tried** doesn't mean **it's not possible**. So, I can't guarantee that you are secure without understanding the validation you are using. But if you want me to just 'take your word for it' that the validation is sufficient, then you can use the "I'll answer you anyway" section I posted above. – 700 Software Jun 17 '16 at 14:36
  • @GeorgeBailey I don't understand what do you mean by Stored AJAX ? Also, why did you bring CSRF into this scenario ? Although the article refers to CSRF attacks, I was just referring to techniques given to defeat input validation. and YES, I am quite confident that the server's input validation can;t be defeated. I was hoping I could get some novel techniques to defeat that in answers. – entropy Jun 17 '16 at 14:40
  • @entropy, I meant to say Stored XSS. – 700 Software Jun 17 '16 at 14:42
  • @entropy, Your question was not very clear. I hope you understand that. I've included a large amount of details, but without proper restrictions on what you wanted me to cover, I have to play it safe and avoid giving a false sense of security. – 700 Software Jun 17 '16 at 14:42
  • @entropy, I mention CSRF, because that was referenced in the linked article. If you do not care about CSRF causing Stored XSS attacks then that is of no importance to you. – 700 Software Jun 17 '16 at 14:43
  • @entropy, *"I was hoping I could get some novel techniques to defeat that in answers."* If you want this, then please start a new question, and be very specific about what you are and are not interested in as an answer. Things like "I tried and couldn't" are very different from "I'm confident it's not possible". I'm asking you to start a **New Question with very specific requirements** if you need more details, because it gives you a clean slate and keeps me from having to delete the work I've done thus far. – 700 Software Jun 17 '16 at 14:44