On Aug 14, 4:23 am, "Michael Geary" <[EMAIL PROTECTED]> wrote:
> Hector, the example URL below is just the JSONP Flickr feed URL. It's not a
> complete example, so it doesn't show the cross-site JSON download in action.
>
> Here are a couple of more complete examples that do a cross-site JSON
> download of that feed:
>
> http://mg.to/test/flickr/jsonp/static.html
> http://mg.to/test/flickr/jsonp/dynamic.html
Ahhhh, I see now. hmmmmmmm, I would debate the following:
1) From an application standpoint, there is no XSS violation here. It
is not XSS loophole.
2) From a technical standard, it offers a way to make a safe and far
call, that is not currently allowed with XMLHttpRequest(). But the
key word here is "safe"
The key point I am making here is that there is no "unsolicited" or
"unexpected" design flow here, not at the original site nor the remote
site providing the serviice, hence there is no XSS violation.
This is more of a DATA manipulation technique based on two ideas:
- getting "DATA" and putting in into a script container
- and the user browser has scripting enabled.
Yes, I can see the JSON "cleanness" in this code, especially the very
nice JS code in how JSON can be mapped into a function. Very cool. I
like that.
But in my technical opinion, it has nothing to do with JSON or
callbacks whatsoever. I can reproduce the design intention shown here
with any data format. The only requirement is JS being enabled.
Here an perfect example. Add this to any web site:
<script type='text/javascript' src="http://beta.winserver.com/public/
js/mike.data">
</script>
alert(mike); /// "Say hello to my little Friend!"
</script>
and it will display the "mike" string defined in some "mike.data"
stored a remote site, that has one line:
var mike="Say hello to my little friend!";
It isn't a XSS violation because it won't work unless a) you add it to
your web site and b) you would only do with all intentions knowing
that it will do, and in addition, you are wriite code to manipulate
the data.
XSS vulnerabilities is about losing control of "behavior" or in
short:
Real Local Execution of Remote Generated Code
which is a engineering taboo that dates back to the beginning to
telecommunications.
<SOAPBOX>
If I may go into a soapbox here because this whole idea is one of my
pet peeves with the direction of the software industry in the past 30
days.
I am in telecomputing, hosting and email/file distribution business
and have been since the early 80s.
The idea of running email or remote generated data as code is an
engineering taboo. It is a powerful concept and a very tempting
concept, but real socially conscious engineers simply didn't do it.
They had all the opportunity to do so in their product offerings but
they simply didn't open Pandora's Box. And most companies at the
time, vehemently fought any rumor or insinuations that we allowed
"back doors" to occurs.
Of course, there was an unfortunate exception to the rule - In the
name of OLE automation, Microsoft and its team of young, possibly
socially untrained engineers violated many basic ethical telecomputing
social engineering principles and as a result, I don't need to tell ya
about all the world wide security repercussions.
But thats reallly the bottom line. Its natural law, an engineering
taboo:
Do not create software that automates the execution of
remote generated data as code.
Yet, even with all the lessons of the past, the younger "always
connected, P2P, web born" new generation of engineers are doing it
just that and are not looking back, and we wonder why we have so many
major security/privacy problems.
Just yesterday, I read a blog from saying he was just JSONP because he
felt constraint with XSS restrictions and felt that one day, that
restriction will be removed from all browsers.
It is this type of thinking that concerns me.
</SOAPBOX>
> There's no formal specification for JSONP, in fact many web services offer
> it without calling it that (they just call it "JSON with a callback
> function" or the like).
Yesterday, in trying to figure out what you were saying, I saw a web
site that was trying to put it together but it was incomplete with
only top level descriptions.
> There's not much to it, just JSON data wrapped
> inside a callbackFunction().
I see, with the help of the URL example, I see exactly what you mean
now. Thanks. -)
But its nothing knew. As I showed, you can do the same without JSON.
JSON just makes it cleaner the DATA structure as a function so that
you get access to it via DOM.
As a suggestion, if you want to describe JSONP in the future to other
future jQuery/JSON morons like me, <g> just say that the name of a
JSON data structure can be mapped as the name of a function and called
under the same name. I like that. but IMO, not the key idea here you
wre trying to convey. Unless I totally missed the boat here, its not
remotely close to a unsolicited security violation XSS loophole.
Thanks for your patience with me Mike. :-)
