Hi Jesse:
All these servlets end up retrieving content through your @Inject'ed
HttpFetcher implementation. I'd recommend putting filters there. The
relevant interface is:
public interface HttpFetcher {
/**
* Fetch HTTP content.
*
* @param request The request to fetch.
* @return An HTTP response from the relevant resource, including error
conditions.
* @throws GadgetException In the event of a failure that can't be mapped
to an HTTP result code.
*/
HttpResponse fetch(HttpRequest request) throws GadgetException;
}
The HttpRequest object has a getGadget() method on it which returns the
current gadget's URL.
That said, I don't recommend using the requesting gadget for security since
the gadget parameter that ultimately is fed into this API is trivial to
spoof. Securing the proxy on a per-gadget basis is difficult. You'll need to
use a security token for that. Your container needs to mint a valid security
token for each gadget render, which contains the gadget URL in it. All such
gadgets need to <Require feature="locked-domain"/> to ensure that they are
rendered on a different, privileged subdomain than "external" gadgets are,
which could otherwise iterate over window.parent.frames[...] and sniff/use
the token. The gadget, when making makeRequest calls (the proxy isn't used
for secure data access), passes along the token which makes its way to
HttpFetcher/HttpRequest, decoded with getAppId() retrieval considered secure
at that point.
Often a simpler idea is to filter internal data access by requester IP,
which can be achieved in several ways. The MakeRequestServlet Filter you
mention could achieve this... but of course, this is a limited approach and
often difficult to implement (or contrary to your goals).
Hope this helps,
John
On Wed, Jul 1, 2009 at 10:58 AM, Jesse Ciancetta <jcian2...@gmail.com>wrote:
> Hi,
>
> I've got a Shindig deployment on my internal network that I'm using to
> render both internally and externally developed/hosted gadgets. I need to
> put some security measures in place to ensure that an external gadget can’t
> do something like makeRequest an internal resource and then push it out to
> some external server. However, internal gadgets should still be allowed to
> access internal resources.
>
> It looks like there are three endpoints I need to be concerned with --
> ProxyServlet, MakeRequestServlet and ConcatProxyServlet. I am thinking the
> easiest way for me to add this security is to write a Servlet filter to run
> in front of each of these services which will look at the http referrer,
> pull out the gadget spec URL, check to see if it’s an internal or external
> gadget, and then decide whether or not to allow the request to proceed or
> just return an HTTP 403.
>
> Does that sound like a reasonable approach? I missing any other places
> where I might need to put these restrictions in place?
>
> Thanks!
>
> --Jesse
>
