Asktav - Latest Comments in Sanitising JSONP Callback Identifiers For Security

Re: Sanitising JSONP Callback Identifiers For Security

David Vassallo — Sun, 02 Nov 2014 09:16:57 -0000

Hi Tav

Very well written and still relevant!

Your post served as inspiration for a practical example of how JSONP and reflected file downloads can be used to harm unsuspecting users in my blog post:

http://blog.davidvassallo.m...

Re: Sanitising JSONP Callback Identifiers For Security

Kees C. Bakker »µßlg — Thu, 06 Mar 2014 09:48:08 -0000

Thanks guys! Maybe the post could link to both PHP and C# ports?

Re: Sanitising JSONP Callback Identifiers For Security

Tom — Tue, 17 Jul 2012 09:58:19 -0000

I know it is two years ago, but this is simply wrong (just to warn others).

In fact, the < symbol would not cause any problems in the callback, other than (probably) confusing JavaScript.

Re: Sanitising JSONP Callback Identifiers For Security

Daniel15 — Mon, 09 Jul 2012 01:27:31 -0000

Thanks for that! Here's a C# port of your PHP port: https://gist.github.com/307... :)

Re: Sanitising JSONP Callback Identifiers For Security

Erik Eng — Fri, 16 Sep 2011 03:03:54 -0000

Thanks for the inspiration! I ported, simplified and refined this for PHP.

https://gist.github.com/121...

Re: Sanitising JSONP Callback Identifiers For Security

Ag — Mon, 31 Jan 2011 11:50:26 -0000

Ignore me the test does appear to be passing. My lack of python expertise probably :)

Re: Sanitising JSONP Callback Identifiers For Security

Ag — Mon, 31 Jan 2011 06:01:13 -0000

Thanks for the useful code and article. I'm not a python expert but if you change the test

>>> is_valid_javascript_identifier(u'Stra\u00dfe')

>>> is_valid_javascript_identifier(r'Stra\u00dfe')

the test fails. Is this a bug or am I missing something? Shouldn't the validator deal with unicode escape sequences in ascii as well as the unicode letter itself?

Re: Sanitising JSONP Callback Identifiers For Security

Simple Xsrf — Wed, 09 Sep 2009 23:28:09 -0000

This is all that's required:

def is_valid_jsonp_callback_value(value): value.find('<') < 0

I cannot tell if your code does this or not.

Re: Sanitising JSONP Callback Identifiers For Security

Philip Hofstetter — Mon, 07 Sep 2009 17:20:12 -0000

what you are describing is just the standard case of any XSS.

But there is no difference what so ever between

and

while I agree that XSS must be avoided at all cost, this is not the job of the remote site. It's the job of the local site.

PS: let's hope my sample code goes through :-)

Re: Sanitising JSONP Callback Identifiers For Security

tav — Mon, 07 Sep 2009 13:42:54 -0000

Thanks for the comment btw -- I've updated the article in response too. Cheers!

Re: Sanitising JSONP Callback Identifiers For Security

tav — Mon, 07 Sep 2009 13:34:26 -0000

Hey Philip,

You are right, the code is executed in the context of the CALLERs page. But that is the problem...

Imagine the scenario, where a client-side web application allows arbitrary data sources to be added... it's not too implausible a future where instead of adding RSS feeds to an RSS Reader, one adds JSON feeds to such an application...

In this context, if the user is tricked into adding a maliciously crafted URL, then everything from their identity to their data is accessible... not to mention being able to abuse the account to spread a worm even...

I believe the possibilities of using JSONP haven't been explored much yet, and for it to go further in the context of interesting mashups/applications, it's important that it not be a security hole...

Hope that makes sense!

Re: Sanitising JSONP Callback Identifiers For Security

Philip Hofstetter — Mon, 07 Sep 2009 12:25:13 -0000

the problem here is the fact that whatever you pass to friendfeed is again executed in the context of your page.

This means that the alert() you so "cleverly" injected runs in the context of the CALLERs page, so the document.cookies that are alerted are the cookies on the source page (the page where the friendfeed-page is sourced on), not of the target page (friendfeed).

This also means that friendfeed doesn't have to do sanitization because whatever you are "injecting" there you could as well just put on your page to begin with.

The real problem behind JSONP is that the consumer has to trust the provider and there is no way to do ANY sanitization of that (the moment you add that "script src=" you are toast and you need to do that because requesting the script via XHR for example isn't possible due to the same origin policy).

So while this might look like a nice idea, it's completely unneeded and doesn't solve the real problem, which is, unfortunately, insolvable.