0

Previously asked here. Asking again on SO to try getting a better set of responses.

I have a service which allows the user to specify a callback function name that wraps the data being returned to support jsonp callbacks. I want to make sure that I am covering all of my bases in regards to preventing XSS attacks.

Note, I have read through the OWASP security checklist but none of the recommendations seem to directly address this question.

These are the currently supported methods for specifying the jsonp function where the function name is cbFn and cbFn is declared on its own, a method on an object, or being accessed from an object/array:

https://service.com/cbFn
https://service.com/?callback=cbFn
https://service.com/?callback=obj.cbFn
https://service.com/?callback=obj['cbFn']
https://service.com/?callback=obj[1]

These return:

cbFn({data: 'data being returned'})
obj.cbFn({data: 'data being returned'})
obj['cbFn']({data: 'data being returned'})
obj[1]({data: 'data being returned'})

However the following requests also work and are the known XSS issues I want to circumvent:

// executes an anonymous function
https://service.com/?callback=(()=%3E{alert(1)})
// replaces the user's callback function with our own
https://service.com/?callback=cbFn=((data)=>{alert(data)})

Is it enough to just replace/remove the characters ()=> in the callback name to prevent XSS vulnerabilities? I want to allow the full valid javascript character set for function names, so restricting the valid character range to /[$_\w]+/ (alphanumeric plus $ and _) doesn't seem to be a good option.

Geuis
  • 41,122
  • 56
  • 157
  • 219
  • [here](https://stackoverflow.com/questions/1661197/what-characters-are-valid-for-javascript-variable-names) is literally the (long) whitelist regex. And well, I would definitly go with a whitelist not a blacklist. You never know about future features! Also: don't use jsonp at all! And *if* you do so then stay with alphanumeric characters. But really dont use jsonp. Do you *really* have to support IE7? (the only reason to use JSONP) – Lux Aug 25 '18 at 21:52
  • Thanks @Lux. I ran across that regex too. The service already supports CORS but a surprisingly large amount of users still access it via jsonp (mainly jquery users). I have a rather large user base already, so when I discovered this the other day it immediately raised many red flags. I’m thinking after researching today it will be better just to filter out characters like (){}=><+- and their escapes forms. That should get the job done and not have a huge impact on existing users. – Geuis Aug 25 '18 at 22:14
  • you could monitor what people actually use and build a good whitelist. But using cors almost always means autogenerating the function name, so `/[$_\w]+/` should be good. – Lux Aug 25 '18 at 22:24

0 Answers0