Should makeRequest follow redirects?

[Jon]

Should makeRequest, HttpRequest and other related queries follow
redirects?

Shindig, by default does not, but our extension did, and the spec does
not really state a behavior. It seems to be a simple option for
various http utilities.

How have others implemented their servers?

[Paul Lindner]

You have to be very careful with redirects.  If your http client library follows redirects you can open potential security holes.

Consider the following scenario:

1. Your fetch client forbids requests to internal networks like 127.0.0.1

2. A malicious user creates a public endpoint that redirects to 127.0.0.1

3. Your http client implementation blindly follows redirects.

By following redirects you negate all your careful checking in step 1.

Even worse if you have a stupid fetch library you could follow a redirect to file:///etc/passwd 

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=.

[Randy Hudson]

> Consider the following scenario:
>
> 1. Your fetch client forbids requests to internal networks like 127.0.0.1
> 2. A malicious user creates a public endpoint that redirects to 127.0.0.1
> 3. Your http client implementation blindly follows redirects.
>
> By following redirects you negate all your careful checking in step 1.

Exactly. One might even argue that 3 implies your failed to do 1 ;-)

I'd like to argue that makeRequest should behave the same way that
XMLHttpRequest does, meaning it should follow redirects by default,
perhaps with the restriction that the redirect be to an address on the
same site.

[Randy Hudson]

> Consider the following scenario:
>
> 1. Your fetch client forbids requests to internal networks like 127.0.0.1
> 2. A malicious user creates a public endpoint that redirects to 127.0.0.1
> 3. Your http client implementation blindly follows redirects.
>
> By following redirects you negate all your careful checking in step 1.

[Jon]

One possible method to eliminate redirects behind your firewall is to
ensure that your fetch client uses a proxy server that would forbid
the malicious redirect.

On Nov 14, 11:59 pm, Paul Lindner <lind...@inuus.com> wrote:
> You have to be very careful with redirects.  If your http client library
> follows redirects you can open potential security holes.
>
> Consider the following scenario:
>
> 1. Your fetch client forbids requests to internal networks like 127.0.0.1
> 2. A malicious user creates a public endpoint that redirects to 127.0.0.1
> 3. Your http client implementation blindly follows redirects.
>
> By following redirects you negate all your careful checking in step 1.
>
> Even worse if you have a stupid fetch library you could follow a redirect to
> file:///etc/passwd
>

> On Wed, Nov 11, 2009 at 3:44 PM, Jon <jon.weyga...@gmail.com> wrote:
> > Should makeRequest, HttpRequest and other related queries follow
> > redirects?
>
> > Shindig, by default does not, but our extension did, and the spec does
> > not really state a behavior. It seems to be a simple option for
> > various http utilities.
>
> > How have others implemented their servers?
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "OpenSocial and Gadgets Specification Discussion" group.
> > To post to this group, send email to
> > opensocial-an...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>
> > .