You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Dan Dumont <dd...@us.ibm.com> on 2011/09/21 00:32:59 UTC
Locked domains and spoof protection in shindig
I'm trying to understand a bit more about the locked domain feature
implementation in shindig, if someone familiar with the process could take
some time to answer these questions, I'd appreciate it.
Most of the checking seems to happen around 2 classes, an enum defined in
UriStatus and the implementation of DefaultIframeUriManager.
validateRenderingUri. What I'm not finding is anything keying off of the
status to ensure that statuses of INVALID_DOMAINare not allowed to render.
Seems like the status request is mostly used for caching based on
versioning or lack of versioning. When I search for references for
INVALID_DOMAINthe only thing that really uses it to prevent activity is
ProxyUriBase.translateStatusRefresh and that happens much later after the
render.
So here are my questions:
What are we really trying to protect against with locked domains?
Is there a concern in allowing a gadget to render on the domain of another
locked-domain gadget? (the check is there in shindig right now but I can't
find anything that's enforcing the status that's returned for render
calls)
Is the render an important thing to protect, or is it mostly for requests
through the proxy?
RE: Locked domains and spoof protection in shindig
Posted by Dan Dumont <dd...@us.ibm.com>.
There is apparently a lot of duplicate code doing much of the same thing
in a few different places.
I'm hoping to clean most of it up and will include you on the review. We
do stop gadgets from spoofing the locked domain, that case seems pretty
clear now that I've found the code. Anything involved with the UriStatus
and INVALID_DOMAIN constant are pretty suspicious. Because the ProxyUri
class relies on it, I have a feeling it may be vulnerable, but I haven't
gotten that far yet.
From: "Ciancetta, Jesse E." <jc...@mitre.org>
To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
Date: 09/21/2011 12:34 PM
Subject: RE: Locked domains and spoof protection in shindig
>Right, but from reading the shindig code, you might come to other
>conclusions. Is there anyone involved with the locked domain code that
is
>still on this list?
I didn't write any of the Shindig locked-domain code, but I have worked
with it for our internal Shindig 2.x based deployment and will be working
with it again with Shindig 3.x for our Rave deployment.
More comments inline below.
>From: Christiaan Hees <ch...@q42.nl>
>To: dev@shindig.apache.org,
>Date: 09/21/2011 04:53 AM
>Subject: Re: Locked domains and spoof protection in shindig
>
>
>
>When you have a page with 2 gadgets on it and those gadgets both have
>the same domain, those gadgets can affect eachother. One gadget could
>insert code or change the look of the other for example.
>So it's important to render each gadget on a seperate subdomain when
>you allow 3rd party gadgets.
>
>
>On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <dd...@us.ibm.com>
>wrote:
>> I'm trying to understand a bit more about the locked domain feature
>> implementation in shindig, if someone familiar with the process could
>take
>> some time to answer these questions, I'd appreciate it.
>>
>> Most of the checking seems to happen around 2 classes, an enum defined
>in
>> UriStatus and the implementation of DefaultIframeUriManager.
>> validateRenderingUri. What I'm not finding is anything keying off of
>the
>> status to ensure that statuses of INVALID_DOMAINare not allowed to
>render.
>> Seems like the status request is mostly used for caching based on
>> versioning or lack of versioning. When I search for references for
>> INVALID_DOMAINthe only thing that really uses it to prevent activity is
>> ProxyUriBase.translateStatusRefresh and that happens much later after
>the
>> render.
>>
>> So here are my questions:
>>
>> What are we really trying to protect against with locked domains?
I think the what is as Christiaan pointed out -- preventing gadget code in
gadget A from accessing/manipulating gadget B or the parent container
page. There are also cookies to keep in mind here as well -- like SSO
cookies that might be set for *.yourdomain.com -- you wouldn't want
untrusted gadgets running on some.yourdomain.com and snatching up your SSO
session tokens.
>> Is there a concern in allowing a gadget to render on the domain of
>another
>> locked-domain gadget? (the check is there in shindig right now but I
>can't
>> find anything that's enforcing the status that's returned for render
>> calls)
>> Is the render an important thing to protect, or is it mostly for
>requests
>> through the proxy?
I think it's important to protect both cases.
If we don't ensure that a render request has arrived on the right locked
domain for the gadget being rendered then there is nothing stopping gadget
A from immediately changing its location onload to the locked domain of
gadget B -- and at that point gadget A can do whatever it wants with
gadget B.
I think it's also important to protect the various proxy mechanisms
because I believe (have heard mentioned, but I haven't thought through the
implications myself) that if you can get a resource loaded (like a JS
file) from another gadgets domain then you could also potentially start to
access the other gadgets contents.
Shindig 2.x protects against both cases -- if I try to render or hit one
of the proxies on the wrong locked domain I immediately get back an HTTP
400 with "Invalid domain" in the response.
If this is no longer the case with Shindig 3.x then it sounds like a bug
that we need to resolve.
I haven't done any locked domain work with Shindig 3.x yet but will be
soon(ish) -- if this isn't resolved by the time I get to it I'd be happy
to look into it further.
RE: Locked domains and spoof protection in shindig
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>Right, but from reading the shindig code, you might come to other
>conclusions. Is there anyone involved with the locked domain code that is
>still on this list?
I didn't write any of the Shindig locked-domain code, but I have worked with it for our internal Shindig 2.x based deployment and will be working with it again with Shindig 3.x for our Rave deployment.
More comments inline below.
>From: Christiaan Hees <ch...@q42.nl>
>To: dev@shindig.apache.org,
>Date: 09/21/2011 04:53 AM
>Subject: Re: Locked domains and spoof protection in shindig
>
>
>
>When you have a page with 2 gadgets on it and those gadgets both have
>the same domain, those gadgets can affect eachother. One gadget could
>insert code or change the look of the other for example.
>So it's important to render each gadget on a seperate subdomain when
>you allow 3rd party gadgets.
>
>
>On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <dd...@us.ibm.com>
>wrote:
>> I'm trying to understand a bit more about the locked domain feature
>> implementation in shindig, if someone familiar with the process could
>take
>> some time to answer these questions, I'd appreciate it.
>>
>> Most of the checking seems to happen around 2 classes, an enum defined
>in
>> UriStatus and the implementation of DefaultIframeUriManager.
>> validateRenderingUri. What I'm not finding is anything keying off of
>the
>> status to ensure that statuses of INVALID_DOMAINare not allowed to
>render.
>> Seems like the status request is mostly used for caching based on
>> versioning or lack of versioning. When I search for references for
>> INVALID_DOMAINthe only thing that really uses it to prevent activity is
>> ProxyUriBase.translateStatusRefresh and that happens much later after
>the
>> render.
>>
>> So here are my questions:
>>
>> What are we really trying to protect against with locked domains?
I think the what is as Christiaan pointed out -- preventing gadget code in gadget A from accessing/manipulating gadget B or the parent container page. There are also cookies to keep in mind here as well -- like SSO cookies that might be set for *.yourdomain.com -- you wouldn't want untrusted gadgets running on some.yourdomain.com and snatching up your SSO session tokens.
>> Is there a concern in allowing a gadget to render on the domain of
>another
>> locked-domain gadget? (the check is there in shindig right now but I
>can't
>> find anything that's enforcing the status that's returned for render
>> calls)
>> Is the render an important thing to protect, or is it mostly for
>requests
>> through the proxy?
I think it's important to protect both cases.
If we don't ensure that a render request has arrived on the right locked domain for the gadget being rendered then there is nothing stopping gadget A from immediately changing its location onload to the locked domain of gadget B -- and at that point gadget A can do whatever it wants with gadget B.
I think it's also important to protect the various proxy mechanisms because I believe (have heard mentioned, but I haven't thought through the implications myself) that if you can get a resource loaded (like a JS file) from another gadgets domain then you could also potentially start to access the other gadgets contents.
Shindig 2.x protects against both cases -- if I try to render or hit one of the proxies on the wrong locked domain I immediately get back an HTTP 400 with "Invalid domain" in the response.
If this is no longer the case with Shindig 3.x then it sounds like a bug that we need to resolve.
I haven't done any locked domain work with Shindig 3.x yet but will be soon(ish) -- if this isn't resolved by the time I get to it I'd be happy to look into it further.
Re: Locked domains and spoof protection in shindig
Posted by Dan Dumont <dd...@us.ibm.com>.
Right, but from reading the shindig code, you might come to other
conclusions. Is there anyone involved with the locked domain code that is
still on this list?
From: Christiaan Hees <ch...@q42.nl>
To: dev@shindig.apache.org,
Date: 09/21/2011 04:53 AM
Subject: Re: Locked domains and spoof protection in shindig
When you have a page with 2 gadgets on it and those gadgets both have
the same domain, those gadgets can affect eachother. One gadget could
insert code or change the look of the other for example.
So it's important to render each gadget on a seperate subdomain when
you allow 3rd party gadgets.
On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <dd...@us.ibm.com> wrote:
> I'm trying to understand a bit more about the locked domain feature
> implementation in shindig, if someone familiar with the process could
take
> some time to answer these questions, I'd appreciate it.
>
> Most of the checking seems to happen around 2 classes, an enum defined
in
> UriStatus and the implementation of DefaultIframeUriManager.
> validateRenderingUri. What I'm not finding is anything keying off of
the
> status to ensure that statuses of INVALID_DOMAINare not allowed to
render.
> Seems like the status request is mostly used for caching based on
> versioning or lack of versioning. When I search for references for
> INVALID_DOMAINthe only thing that really uses it to prevent activity is
> ProxyUriBase.translateStatusRefresh and that happens much later after
the
> render.
>
> So here are my questions:
>
> What are we really trying to protect against with locked domains?
> Is there a concern in allowing a gadget to render on the domain of
another
> locked-domain gadget? (the check is there in shindig right now but I
can't
> find anything that's enforcing the status that's returned for render
> calls)
> Is the render an important thing to protect, or is it mostly for
requests
> through the proxy?
>
>
>
>
>
Re: Locked domains and spoof protection in shindig
Posted by Christiaan Hees <ch...@q42.nl>.
When you have a page with 2 gadgets on it and those gadgets both have
the same domain, those gadgets can affect eachother. One gadget could
insert code or change the look of the other for example.
So it's important to render each gadget on a seperate subdomain when
you allow 3rd party gadgets.
On Wed, Sep 21, 2011 at 12:32 AM, Dan Dumont <dd...@us.ibm.com> wrote:
> I'm trying to understand a bit more about the locked domain feature
> implementation in shindig, if someone familiar with the process could take
> some time to answer these questions, I'd appreciate it.
>
> Most of the checking seems to happen around 2 classes, an enum defined in
> UriStatus and the implementation of DefaultIframeUriManager.
> validateRenderingUri. What I'm not finding is anything keying off of the
> status to ensure that statuses of INVALID_DOMAINare not allowed to render.
> Seems like the status request is mostly used for caching based on
> versioning or lack of versioning. When I search for references for
> INVALID_DOMAINthe only thing that really uses it to prevent activity is
> ProxyUriBase.translateStatusRefresh and that happens much later after the
> render.
>
> So here are my questions:
>
> What are we really trying to protect against with locked domains?
> Is there a concern in allowing a gadget to render on the domain of another
> locked-domain gadget? (the check is there in shindig right now but I can't
> find anything that's enforcing the status that's returned for render
> calls)
> Is the render an important thing to protect, or is it mostly for requests
> through the proxy?
>
>
>
>
>