XSS when content type is application/javascript

1,608 views
Skip to first unread message

Anirudh Anand

unread,
Dec 23, 2015, 8:48:56 AM12/23/15
to null-...@googlegroups.com
Hello team,

Recently, when I was testing one application, I noticed a behavior like the following:

URL looks like this: something.json?include=true&callback=reflective-userinput

What ever user input I give to the callback parameter, its getting reflected in the JSON response without any type escaping or encoding but I couldn't trigger an XSS because I noticed that the content-type is set to application/javascript and from what I understand the browsers will print the response in raw if the content type is set to application/javascript. If the content type is text/html, this is definitely an XSS vulnerability but can an XSS be triggered in the above case ?

Is this a proper way to prevent XSS when we deal with simple JSON data in response (like in the cases of API responses) ?Or is there a way I can actually trigger an XSS here ? If this is a proper way to prevent XSS, why isn't widely used especially when we deal with JSON responses (atleast for me, I rarely come across application/javascript )?

--

Anirudh Anand
bi0s@AMRITA
www.securethelock.com

"Those who Say it cannot be done, should not interrupt the people doing it"

Sharath Unni

unread,
Dec 24, 2015, 2:21:25 AM12/24/15
to null-...@googlegroups.com

--
______________________________________________________________________________
null - Spreading the right Information
null Mailing list charter: http://null.co.in/section/about/null_list_charter/
______________________________________________________________________________
Do you trust your hardware?
http://hardwear.io
---
You received this message because you are subscribed to the Google Groups "null" group.
To unsubscribe from this group and stop receiving emails from it, send an email to null-co-in+...@googlegroups.com.
Visit this group at https://groups.google.com/group/null-co-in.
For more options, visit https://groups.google.com/d/optout.

Mahesh Mahi

unread,
Dec 24, 2015, 7:01:32 AM12/24/15
to null-...@googlegroups.com
Hi Anirudh,

Did you check what's the application response/behaviour when you access the URL on IE?
If the behaviour is different compared to FF/Chrome, then it might be vulnerable to RFD - https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/ 

Anirudh Anand

unread,
Dec 24, 2015, 8:09:41 AM12/24/15
to null-...@googlegroups.com
Thanks for the link Sharath. I really helped clearing some concepts !

@Mahesh, Yes it is anyway vulnerable to RFD (I can control the path parameter also and since content-type is application/javascript, the best case RFD). I wanted to know if its a good way of protecting against XSS !

The application is vulnerable to XSS but only in IE as IE gives more important to extensions (which I could control) and not content-type like firefox and chrome !

Venkat Sanaka

unread,
Dec 25, 2015, 6:12:41 AM12/25/15
to null-...@googlegroups.com

Hey,

Not related to your question. But from your explanation, it looks like it is also vulnerable to CSRF bypassing same-origin policy: https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

Thanks
Venkat

Anirudh Anand

unread,
Dec 25, 2015, 7:35:23 AM12/25/15
to null-...@googlegroups.com
Hey Venkat,

Thanks for the suggestions but I already checked the possibility of rosetta flash and it didn't work because they use X-Content-Type-Options: nosniff in HTTP headers !

Thanks anyway,

Venkat Sanaka

unread,
Dec 25, 2015, 8:04:00 AM12/25/15
to null-...@googlegroups.com

OK cool. But are you sure if it is this x-content-type-options header that is preventing the rosetto flash kind of vuln. AFAIK, this header is supported by only few browsers and only in certain cases. I don't think flash plugin obeys this header.

Thanks
Venkat

Reply all
Reply to author
Forward
0 new messages