6

I am testing out the tool CSP Evaluator, and have a question regarding the following content-security-policy:

default-src https://maps.googleapis.com

The tool consider this as a high risk:

maps.googleapis.com is known to host JSONP endpoints which allow to bypass this CSP.

My question is, how can a trusted maps.googleapis.com be exploited to perform an XSS attack?

7

Consider if something like this was attempted by an attacker injecting XSS:

<script src="https://maps.googleapis.com/foo?callback=alert"></script>

This would execute the foo function from the Google APIs JavaScript SDK, and upon it's return would call the alert. This demonstrates that an attacker would be able to inject inline code into the page, which would be executed. Therefore XSS is achieved which bypasses the blocking of unsafe-inline code.

Of course, what can be called would depend on the arguments passed and how exactly Google sanitise the callback parameter. It appears that CSP Validator just has a simple rule to flag these in the form "does the domain in the CSP support JSONP?" which does not take into account how the callback is executed.

This seems fair, as CSP Validator will never know if any code alterations on the external domain ever introduce or patch such vulnerabilities so I think it is correct that this is flagged.

  • 1
    Thanks, this explains it. I was thinking why google maps would not sanitize that callback argument, but given that they have no insight in the applications namespace, they are not able to tell what is good or bad callback function. – Dog eat cat world Sep 29 '16 at 11:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.