On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Using JSON in the end-user authorization endpoint response is still
> something we need to discuss. In the web server flow, it makes more sense to
> use form-encoded because the URI is processed by a typical query processor
> (automatic in every web server). In the fragment, it is a question of
> preference, and I was told that there are many benefits to using JSON. I
> think Facebook uses JSON in such a way.
>
>
>
> However, there is still value in using JSON across all server responses
> because it allows returning the same structured data.
>
>
>
> Can you explain the XSS hole from parsing a random JSON string?
>
Naive processor calls:
var href = document.location.href;
var jsonBlob = href.substring(href.indexOf('#'), href.length)
var userData = eval(jsonBlob);
This code would allow executing arbitrary code by sending a user a link,
which could, for example, steal your cookies on a site.
The fix is just a really complicated RegEx match - here is sample
code<http://www.google.com/codesearch/p?hl=en#MSH8LMSqi38/trunk/features/core/json.js&q=parse%20gadgets.json%20shindig%20package:%22http://svn.apache.org/repos/asf/incubator/shindig/%22&sa=N&cd=1&ct=rc&l=141>from
Shindig that does this correctly - but I would worry that implementers
would do the simple thing and just eval the JSON. It also seems like a sign
of a design issue if the spec requires this regex.
>
> If all server responses are JSON, why does the client have to do
> form-decoding?
>
Redirect_uri needs to be put into a URL somehow, and the URL may have other
query parameters or other content in the fragment. I'm making the assumption
that we would put this into a query parameter - otherwise we need to specify
ourselves how to encode the JSON to be URL-safe and not conflict with other
parameters.
>
>
> What simple model? Format isn’t a model.
>
Sorry, the statement about "simple model" wasn't that helpful without
context. Here's the context:
- We currently have listed 4 named parameters that may be returned.
- Using query parameters is an obvious / clear way to return these
parameters when encoded in a URL (in the fragment, a common practice is to
use the same query parameter format, but after the hash).
- All modern coding environments I know of can pull out simple key /
value pairs encoded in URL parameters. Issues I've heard with URL parameters
are all around:
1. Canonicalization of parameters for signing, and
2. Parameters that are not simple key/value pairs (i.e. how do you
encode a linefeed.
- The data returned on a URL should probably *not* be the same as what
you would return on the server. This is because the data is untrusted -
evildoers can construct a URL with the wrong JSON data.
So my preference would be to leave the redirect URI as simple key/value
pairs and actively try to discourage adding structured / complex content. We
can use a followup call to the AS with the access token on the server side
for complex data, and JSON is the right response format for this followup
call.
>
>
> EHL
>
>
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Evan Gilbert
> *Sent:* Sunday, June 13, 2010 2:47 AM
> *To:* Robert Sayre
> *Cc:* OAuth WG (oauth@ietf.org)
> *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format
>
>
>
> -1
>
>
>
> I disagree very strongly with this approach if I'm understanding
> correctly. Let me paraphrase to make sure I understand:
>
>
>
> All responses, even those encoded in a browser URL redirect back from the
> AS (redirect with verification code in the web server flow and the redirect
> with token in the user-agent flow) will be JSON
>
>
> This means that we will have a URL-encoded JSON blob as a form parameter
> (as it has to play nicely with existing URL parameters). So the response
> back in the web server flow would be:
>
> https://client.com/receiveVerificationCode?existingParam=value&oauth2=%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D
>
> and the response back in the user-agent flow would be
>
> https://client.com/page?existingParam=value&oauth2=%7Baccess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D
>
>
>
> Reasons why this is of concern:
>
> - Requires clients to do URL decoding *and* JSON decoding
>
> - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) = XSS
> hole)
>
> - Breaks the simple model we've been creating in these flows.
>
>
>
> Evan
>
>
>
> On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre <say...@gmail.com> wrote:
>
> +1
>
>
> On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n...@daaku.org> wrote:
> > +1
> >
> > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshep...@facebook.com>
> wrote:
> >>
> >> +1
> >>
> >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
> >>
> >> > +1
> >> >
> >> > --
> >> > James Manger
> >> >
> >> > ----------
> >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> Behalf
> >> > Of Eran Hammer-Lahav
> >> > Sent: Friday, 11 June 2010 6:29 AM
> >> > To: OAuth WG (oauth@ietf.org)
> >> > Subject: [OAUTH-WG] Proposal for single JSON response format
> >> >
> >> > - Support a single response format (including in the user-agent
> >> > fragment) using JSON.
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>
> --
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
