Determining user/owner id when using UNSIGNED makeRequest() calls

[Chak Nanga <my...@gmail.com>]

Hi,

Need some clarification on what opensocial_* params, if any,  the
container/proxy is supposed to append to the outgoing URL in response to
makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id
params to the outgoing UNSIGNED request, how does the 3rd party site know
the owner/viewer info if it needs to fetch user specific data?

It¹s fairly clear that the proxy is supposed to add
opensocial_owner/viewer/app_id params and oauth_* params.

Also, I noticed that the current proxy code does not remove opensocial_* and
oauth_* if they are present in the incoming makeRequest() calls. I can file
a JIRA issue, if this is indeed a bug.

Thanks
Chak

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[Kevin Brown <et...@google.com>]

Redirecting this discussion to the appropriate list. If you're not
subscribed to opensocial-and-gadgets-spec@googlegroups.com, please do so.
Shindig hasn't actually implemented OAuth yet, but when we do so we will do
whatever the spec requires.

On Fri, Mar 7, 2008 at 11:40 AM, Arne Roomann-Kurrik <ku...@google.com>
wrote:

> True, I suppose that if they don't bother validating the request, they
> won't
> bother seeing where the request comes from.
>
> ~Arne
>
>
> On Fri, Mar 7, 2008 at 11:20 AM, Brian Eaton <be...@google.com> wrote:
>
> > On Fri, Mar 7, 2008 at 10:47 AM, Arne Roomann-Kurrik <ku...@google.com>
> > wrote:
> > >  Naturally, servers should always validate all signed data, but should
> > >  shindig take the precaution of clearing all user-supplied
> opensocial_*
> > >  querystring values from unsigned requests?
> >
> > Nah, it would be pointless.  What would stop an attacker from
> > bypassing Shindig completely?
> >
>



-- 
~Kevin

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[Arne Roomann-Kurrik <ku...@google.com>]

True, I suppose that if they don't bother validating the request, they won't
bother seeing where the request comes from.

~Arne


On Fri, Mar 7, 2008 at 11:20 AM, Brian Eaton <be...@google.com> wrote:

> On Fri, Mar 7, 2008 at 10:47 AM, Arne Roomann-Kurrik <ku...@google.com>
> wrote:
> >  Naturally, servers should always validate all signed data, but should
> >  shindig take the precaution of clearing all user-supplied opensocial_*
> >  querystring values from unsigned requests?
>
> Nah, it would be pointless.  What would stop an attacker from
> bypassing Shindig completely?
>

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[Brian Eaton <be...@google.com>]

On Fri, Mar 7, 2008 at 10:47 AM, Arne Roomann-Kurrik <ku...@google.com> wrote:
>  Naturally, servers should always validate all signed data, but should
>  shindig take the precaution of clearing all user-supplied opensocial_*
>  querystring values from unsigned requests?

Nah, it would be pointless.  What would stop an attacker from
bypassing Shindig completely?

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[Arne Roomann-Kurrik <ku...@google.com>]

I think the issue is that if an attacker somehow determined that a third
party server was accepting signed request calls but not actually performing
validation on the parameters, the attacker could just forge an unsigned
request with all the appropriate oauth_* and opensocial_* data (but an
invalid signature) and request arbitrary data from the third party server.

Naturally, servers should always validate all signed data, but should
shindig take the precaution of clearing all user-supplied opensocial_*
querystring values from unsigned requests?

~Arne


On Fri, Mar 7, 2008 at 10:33 AM, John Panzer <jp...@google.com> wrote:

> The intent is that the container only provides signatures for opensocial_*
> things it can vouch for.  A container can't vouch for an arbitrary
> parameter
> sent from gadget JS, so that sounds like a bug.
>
> WRT the first question, wouldn't the 3rd party site need a signature in
> order to trust the owner/viewer info?
>
> On Fri, Mar 7, 2008 at 10:16 AM, Chak Nanga <my...@gmail.com> wrote:
>
> > Hi,
> >
> > Need some clarification on what opensocial_* params, if any,  the
> > container/proxy is supposed to append to the outgoing URL in response to
> > makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id
> > params to the outgoing UNSIGNED request, how does the 3rd party site
> know
> > the owner/viewer info if it needs to fetch user specific data?
> >
> > It¹s fairly clear that the proxy is supposed to add
> > opensocial_owner/viewer/app_id params and oauth_* params.
> >
> > Also, I noticed that the current proxy code does not remove opensocial_*
> > and
> > oauth_* if they are present in the incoming makeRequest() calls. I can
> > file
> > a JIRA issue, if this is indeed a bug.
> >
> > Thanks
> > Chak
> >
> >
>

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[Chak Nanga <my...@gmail.com>]

> WRT the first question, wouldn't the 3rd party site need a signature in
> order to trust the owner/viewer info?

Hi John: Agreed on your point above.

I'm mainly thinking from a container implementers' point of view -
mainly in terms of security.

Assuming that if I'm implementing a container/proxy, what should the
proxy do when it sees opensocial_* params for an UNSIGNED
makeRequest() call? Should it just pass them along to the 3rd party
site? I'm  mainly thinking of a case where in a malicious user forges a
signed request by passing (false) signed parameters in an unsigned request

It's pretty clear in the case of SIGNED requests that the proxy is
supposed to strip out the opensocial_* and oauth_* params before the signing
operation.

Thanks
Chak 


On 3/7/08 10:33 AM, "John Panzer" <jp...@google.com> wrote:

> The intent is that the container only provides signatures for opensocial_*
> things it can vouch for.  A container can't vouch for an arbitrary parameter
> sent from gadget JS, so that sounds like a bug.
> 
> WRT the first question, wouldn't the 3rd party site need a signature in
> order to trust the owner/viewer info?
> 
> On Fri, Mar 7, 2008 at 10:16 AM, Chak Nanga <my...@gmail.com> wrote:
> 
>> Hi,
>> 
>> Need some clarification on what opensocial_* params, if any,  the
>> container/proxy is supposed to append to the outgoing URL in response to
>> makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id
>> params to the outgoing UNSIGNED request, how does the 3rd party site know
>> the owner/viewer info if it needs to fetch user specific data?
>> 
>> It¹s fairly clear that the proxy is supposed to add
>> opensocial_owner/viewer/app_id params and oauth_* params.
>> 
>> Also, I noticed that the current proxy code does not remove opensocial_*
>> and
>> oauth_* if they are present in the incoming makeRequest() calls. I can
>> file
>> a JIRA issue, if this is indeed a bug.
>> 
>> Thanks
>> Chak
>> 
>> 

Re: Determining user/owner id when using UNSIGNED makeRequest() calls

[John Panzer <jp...@google.com>]

The intent is that the container only provides signatures for opensocial_*
things it can vouch for.  A container can't vouch for an arbitrary parameter
sent from gadget JS, so that sounds like a bug.

WRT the first question, wouldn't the 3rd party site need a signature in
order to trust the owner/viewer info?

On Fri, Mar 7, 2008 at 10:16 AM, Chak Nanga <my...@gmail.com> wrote:

> Hi,
>
> Need some clarification on what opensocial_* params, if any,  the
> container/proxy is supposed to append to the outgoing URL in response to
> makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id
> params to the outgoing UNSIGNED request, how does the 3rd party site know
> the owner/viewer info if it needs to fetch user specific data?
>
> It¹s fairly clear that the proxy is supposed to add
> opensocial_owner/viewer/app_id params and oauth_* params.
>
> Also, I noticed that the current proxy code does not remove opensocial_*
> and
> oauth_* if they are present in the incoming makeRequest() calls. I can
> file
> a JIRA issue, if this is indeed a bug.
>
> Thanks
> Chak
>
>