W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: Redirects continued -- was: Problem with certificate on home-grown WebID

From: Mo McRoberts <mo.mcroberts@bbc.co.uk>
Date: Wed, 21 Dec 2011 17:51:02 +0000
Cc: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Sebastian Trüg <sebastian@trueg.de>, public-xg-webid XG <public-xg-webid@w3.org>, Carvalho Melvin <melvincarvalho@gmail.com>, "foaf-protocols@lists.foaf-project.org" <foaf-protocols@lists.foaf-project.org>
Message-Id: <FCEA0C72-2382-458E-8ECB-29BF513607C9@bbc.co.uk>
To: Henry Story <henry.story@bblfish.net>

On 21 Dec 2011, at 17:46, Henry Story wrote:

> Ok. Lots of good reasons for redirects then in ISSUE-64 :-)  Now we just should look at security issues.
> I remember Peter Williams bringing up infinite redirects, max number of redirects, ... But perhaps there are also other scenarios which evil characters can use to waylay people. 

There are three common scenarios I can think of, but there may be others:—

Infinite redirects is the usual one (limited by a 'max redirects' setting in many UAs)

There’s also 'redirecting to things which you wouldn't ordinarily allow navigation to without direct user intervention' (e.g., about:config or telnet: URIs) — only affects same UAs, but is important nonetheless.

If you’re making use of information delivered by transport-layer security to help validate the resource, then if that secured resource redirects you to an unsecured resource, you need to act accordingly (e.g., just because it starts off as HTTPS with DNSSEC verifiable for the hostname doesn't mean it'll end up that way — you treat the whole chain as being as secure as the weakest link along it).


Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
Received on Wednesday, 21 December 2011 17:52:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC