On Wed, 2008-07-09 at 17:33 -0700, Dan Fandrich wrote:
> That's not quite the scenario I was thinking about. A malicious server
> could redirect a browser to a device on an interface that data would not
> normally be sent on just through a normal 302 redirect, e.g.
>
> HTTP/1.1 301 Moved Permanently
> Location: http://[fe80::1234%251]/operation.cgi?request=reboot
>
> which would cause a browser request like:
>
> GET /operation?request=reboot HTTP/1.1
> Host: [fe80::1234]
>
> Sure, the scope ID is stripped off, but that doesn't really matter since
> it has already contacted the forbidden server on the local LAN. Again, I'm
> not convinced this is much worse than the equivalent IPv4 case.

I agree, it doesn't seem much worse than the equivalent IPv4 case.
However, my inclination would be to ignore any incoming scope ID for
redirects, and instead use the interface ID that the 302 response came
in on as the scope for the redirected request. (Or, easier and nearly
as good, just re-use the scope ID that was specified on the original
request.)

By way of rationale, consider the following case:

Client requests http://[fe80::1234%251]/index.htm

Server wants to redirect this to another host on the same link:

Location: http://[fe80::4321]/index.htm

But, the server doesn't have any way of knowing what interface index the
client needs to use to access this link-local scope. (It could perhaps
infer it from the Host header if the scope were included there, but the
MS scope-stripping behaviour that Yang Tse mentions would make this
impossible.) So, the only useful behaviour would seem to be for the
client to figure out the intended scope for itself based on its
knowledge of where the original server is located.

Re-using the scope ID from the original request seems like it will
produce the right answer in nearly all cases. The only situation I can
think of where it would fail is if the original request was sent to a
global address and hence didn't have a scope ID, but the server
responded with a redirect to a link-local address. Using the interface
index that the response was received on would avoid this problem at the
cost of a little bit more code.

p.
Received on 2008-07-10