W3C home > Mailing lists > Public > www-validator@w3.org > December 2001

Re: Validation broken for protected pages

From: Bud Hovell <bud@uzix.com>
Date: Mon, 17 Dec 2001 07:30:42 -0800
Message-Id: <200112171535.fBHFZc502715@glisan.hevanet.com>
To: Nick Kew <nick@webthing.com>
CC: <www-validator@w3.org>
Hi, Nick ...

> > > http://lists.w3.org/Archives/Public/www-
> validator/2001JulSep/0476.html
> Bud appears to be replying to something I haven't seen.

Sorry - your post was a reply to the one cited above, and reads:

NK= On Mon, 3 Sep 2001, Samuel[ISO-8859-1]  Rinnetmäki wrote:
NK= > 
NK= > W3C HTML Validation Service has a security issue regarding to HTTP 
NK= > Authentication.
NK= > 
NK= > I searched the archives of this mailing list for "+www-validator
NK= > +authentication" and found some disussion about HTTP Basic 
NK= > not being secure, but I think the HTML Validation Service implements 
NK= > Basic Authentication in a way that is even more insecure than the 
NK= > Basic Authentication usually. 
NK= > 
NK= It's not quite that bad.
NK= >
NK= > If I use the Validator to validate a document on a server (A) which
NK= > requires authentication, Validator asks for the credentials. If I 
then try
NK= > and validate another document on another server (B), my browser 
sends the
NK= > same credentials
NK= Yes indeed.
NK= However, server B can only use the credentials if it can identify
NK= server A, which could be anywhere on the 'net.  So it's not really
NK= adding anything further to the insecurity of HTTP Basic Authentication
NK= (and no, this is not 'security through obscurity').

That's the crux of the matter: this was never a "security problem" to 
begin with. The mouse has stampeded the elephant.

NK= > 
NK= > What the "check" script should do is to keep track of the Realms 
NK= > require authorization,
NK= That is not a cure.  There's nothing unique about a realm.
NK= I would suggest that a better option is to allow the user to enter the
NK= credentials in an HTML form, rather than use an authentication 
NK= This is the approach taken by cg-eye (see my .sig).

Regrettably, this would not satisfy our local conditions, either. We make 
available anonymous logins where the username/password are random strings 
unknown to the users logging in (who thus need not reveal any personal 
identifying information.) Once inside, such a user lacks the necessary 
password information to fulfill an authentication request. And the extra 
hand-motion required entirely defeats the immediacy of one-click 

> But since I seem to have had something to say on the subject in the
> past,
> I felt compelled to review what you're talking about.
> It is perhaps worth noting that, while my comments apply to the
> service
> running at validator.w3.org, they would not necessarily apply in
> every
> case.  For example, if you were to run the W3 validator locally on
> a company website or intranet having different protected areas, it
> could be quite a significant security risk.  In such a case you

Acceptance testing conducted under the control of the vender is invalid on 
its face. And as you say, this solution would put us in the ridiculous 
position of having to create exactly those unique conditions which might 
enlarge an otherwise insignificant risk.

> would
> definitely be better-advised to use a different approach, such as
> that adopted by relevant parts of Site Valet.

We'd certainly consider Site Valet, were it not that manual entry is 
evidently required for protected pages, which doesn't meet our needs.

> Not necessarily true.  The person doing validation could be
> ignorant of
> potential problems, and a security advisory could go straight over

Hopefully this person doesn't self-administer drugs issued by his 
physician. He'd likely misunderstand those plainly-stated warnings, too.

And the one-armed man isn't enabled by requiring everyone else to cut off 
one arm. While I agree that default protection should be provided for 
vanilla usage of any application where security is a significant issue 
(not the present case), it is wretched excess to require everyone riding a 
bike to keep both training wheels firmly attached. Such an "OSHA" approach 
creates an obstacle for everyone in order to protect the terminally 
ignorant few who will inevitably blunder their way into harm, one way or 

> their heads.  Any tool that might facilitate the circumvention of
> a standard security mechanism would be well-advised to do so with

The new "security" mechanism in the script is non-standard on two grounds:

1. It's hideously broken.
2. It's utterly gratuitous.

The only risk is that a username and password MIGHT randomly match for a 
page on another server.

After millions of page hits while the Validator has been in use, no such 
incident has ever been reported. Ipso facto, this is a threat requiring no 
response whatever -- too many zeros have already accumulated after the 
decimal point. And numbers should define risk. Not detached ruminations 
founded solely on gut feel.

But then, I'm a romantic. 

> great caution, and to present a warning (with full explanation)
> to the user in all cases.

A clear warning with full explanation of any actual danger is both 
rational and respectful of others. Abruptly crippling service with broken 
code to evade a non-danger is bizarre. And offering no alternative but to 
live with the profoundly ugly and unnecessary consequences is willful 
Bud Hovell

"We don't have to be nice, Mr. Johnson. We're the
 phone company." -- Lily Tomlin
Received on Monday, 17 December 2001 10:37:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:58:25 UTC