Ранее спрашивал здесь. Снова спрашивал у SO, чтобы попытаться получить лучший набор ответов.
У меня есть служба, которая позволяет пользователю указывать имя функции обратного вызова, которая упаковывает возвращаемые данные для поддержки обратных вызовов jsonp. Я хочу убедиться, что я покрываю все свои базы в отношении предотвращения атак XSS.
Обратите внимание, что я прочитал контрольный список безопасности OWASP , но ни одна из рекомендаций, похоже, не имеет прямого отношения к этому вопросу.
Это поддерживаемые в настоящее время методы для указания функции jsonp, в которой имя функции равно cbFn
, а cbFn
объявлен сам по себе, метод объекта или доступен из объекта / массива:
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]
Эти возвращают:
cbFn({data: 'data being returned'})
obj.cbFn({data: 'data being returned'})
obj['cbFn']({data: 'data being returned'})
obj[1]({data: 'data being returned'})
Однако следующие запросы также работают и являются известными проблемами XSS, которые я хочу обойти:
// 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)})
Достаточно ли просто заменить / удалить символы ()=>
в имени обратного вызова, чтобы предотвратить уязвимости XSS? Я хочу разрешить полный допустимый набор символов javascript для имен функций, поэтому ограничение допустимого диапазона символов до /[$_\w]+/
(алфавитно-цифровые символы плюс $ и _) не является хорошим вариантом.