- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Feb 2011 00:57:57 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912
--- Comment #10 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-02-04 00:57:56 UTC ---
(In reply to comment #9)
> You do? I'm happy to keep up the debate; I'm just worried about the half-dozen
> people who get CC'ed every time we post a reply.
Phooey, they can unsubscribe themselves if they object. We're talking about
the merits of your proposed spec changes, so it's not like it's off-topic.
Technically.
> But they do, because while HTTP authentication is more or less
> complete from a *technical standpoint*, it's incomplete from a *user
> experience* standpoint. And that is what we have an opportunity to fix in
> HTML5. Isn't one of the goals of the new standard to improve user experience
> for existing technologies? And to improve security on the web? Most people
> don't use HTTP auth because the user experience is inferior.
Well, the question is a cost-benefit tradeoff for browser implementers.
Realistically this has no chance of happening because web developers almost
exclusively use cookies, so implementers have no incentive to improve HTTP auth
-- they have other things to spend their limited time on that their users are
more concerned with. I mean, if they cared about HTTP auth even slightly, they
could start by making the UI for it not completely horrible, but evidently they
don't. So your proposal is certainly a non-starter, since it doesn't even have
guaranteed returns (authors might not use it).
> And yes, I use the credential forwarding system I spoke of before. I may not
> have quite as many users as Wikipedia, but my database doesn't seem to have a
> problem with it (PostgreSQL). I also don't have *nearly* as much hardware as
> Wikipedia has.
Wikipedia has less hardware than you'd think. Less than a thousand servers
last I checked, only a few dozen database servers. (Granted, probably more
than you.) Anyway, I have heard that PostgreSQL is designed for much more
granular permissions than MySQL, so I wouldn't be surprised if something like
this were doable using it.
> My shared host (a very popular one) has PHP set up with the *default* session
> store, which is flat files in /tmp. This directory is readable to anyone.
> Usually, the flat files themselves are only readable to the user that created
> them. But for the case where someone wants mod_php for their domain instead of
> FastCGI, the files must be created as the apache user. Despite warnings about
> the security implications of this, mod_php is a popular choice, because it's
> the only simple way to get certain features like full header and environment
> information. And this is not hypothetical; I can easily see that a lot of
> people on my shared box are, *in fact and in the real world* using mod_php.
If you use FastCGI, they have to be created as the FastCGI user, so it's really
no different. The way to get around it is to use CGI, but shared hosts often
don't do that because it's inefficient, since it has to fork() on each request.
(But some do use CGI, like 1&1.) Most hosts that use mod_php also use
open_basedir and friends, so you can't open other people's files anyway in
practice in most cases, to be fair.
But yes, this is definitely a real-world scenario. I'd say it's not an issue
because if you can read the files in /tmp, you can read MediaWiki's
configuration too, and so connect to the database directly. But you'd counter
that if MediaWiki used your auth forwarding scheme, it wouldn't have to store
the database passwords anywhere. Clever. I guess there would be no obstacles
if you move enough of the processing logic to the database servers.
I will point out that the attack scenario only works if the attacker has the
right only to run PHP code, not arbitrary code. Like if PHP is configured with
exec() and friends disabled, but not open_basedir for some reason. If you can
run arbitrary code as the Apache user, you can attach a debugger to all the
Apache children and grab the HTTP headers off the wire to get the passwords.
This is a bit harder than using a cookie from a plaintext file, but still easy,
script-kiddie stuff -- strace on Linux should be enough if you can get it not
to truncate the syscall arguments (I assume there's some option).
Okay, so it's possible in real life to design such a system. Practically
speaking, though, very few people do or will, even if HTTP auth worked better.
It's much easier to just keep off-site backups and assume that your database
servers are compromised if your application servers are. Elaborate privilege
separation tends to only be found in a minority of applications in any field
(Chrome, postfix, . . .) because it takes a lot of effort. Unfortunately for
you, web standards only try to cover the most common use-cases, so you're out
of luck. (That's a prediction, not an assurance, but I'd bet you ten bucks.)
> I'm not sure I agree with this. In the attack I executed above, I am now
> logged in as WikiSysop without entering his password. I can do pretty much
> anything he can do, short of changing his password (since that requires the old
> password - good move). But by the time that cookie expires or is "canceled"
> (not sure how you would figure out that you need to cancel it, "in the real
> world"), I can do a lot of damage since I am logged in as what basically
> amounts to the root user for that MediaWiki install.
Actually, as it happens, MediaWiki users can't really do any damage even if
they have full privileges. Even privileged operations are all logged and
reversible. (If you're sufficiently creative you can make them a real pain in
the neck to reverse, granted.) The only way to do real damage is to edit
LocalSettings.php or directly access the database. But that's a side point.
:)
By default, MediaWiki expires cookies after thirty days. So you have that long
at most. This still allows a short-term vandalism spree, but stops you from
doing any kind of subtle long-term attacks, like snooping indefinitely on a
private wiki. So that's a security win, even if there's no explicit way to
expire cookies prematurely (not sure offhand).
> I agree that a leaked password is far more damaging, but to use your own
> argument, you haven't provided a "real-world" situation where HTTP auth
> invariably leads to a leaked password.
How about: <http://codebutler.com/firesheep>. Anyone on an unsecured wireless
connection to a non-HTTPS website will leak all their HTTP requests in full.
Since sites generally use cookies, Firesheep can only reliably hijack current
sessions, not permanently take over accounts. If you had a specific site you
were targeting, you might be able to launch an active attack that inserted
malicious JavaScript to lure the user into entering their password, but that's
much harder to pull off and easier to detect than just snooping on HTTP
headers, and it requires user interaction no matter what.
Of course, this doesn't happen if you use HTTPS. But there are lots of
practical reasons why that's a pain, both logistic ("oops, I mistyped a line
and now all my users are getting scary cert errors") and performance (extra
RTs, much more expensive for caching proxies). Hopefully DNSSEC will make this
easier, but I'm not going to hold my breath on most sites switching to HTTPS
anytime soon.
> I know you're going to say that the shared host and the site operator are at
> fault for allowing that attack
Of course not, that's silly. The goal is to prevent attacks, not to say we
don't have to worry about particular classes of attacks because they're someone
else's fault. As far as possible, web standards are designed to remain
functional and secure even in the hands of authors and site admins whose idea
of a development process is to copy-paste code you found on Google and tweak it
until it seems to do what you want.
> Somehow, I have a feeling that my descriptions aren't real-world enough; or
> that even though I've basically written a dissertation on this by now, you're
> going to say I wasn't specific enough about something.
Nope, I'm happy to concede at this point that what you describe is *possible*
in practice. But it's just not practical for the large majority of websites.
The security benefit is greatly outweighed by the added development costs.
Certainly for most websites, where the worst case is that a bunch of pimply
teenagers have to temporarily switch to Facebook to coordinate their WoW raids
until the host has reinstalled the software for them. I suspect it's actually
not economical for any website, but I can't make an informed claim on that
score, since I'm not involved in high-stakes websites. (Downtime is when
Wikipedia gets the most donations!)
> But, as you've probably
> figured out already, I love the sound of my own voice and I'm happy to continue
> debating the details for as long as you can stand it ;)
Glad to see I'm not alone! I should have spent the last 45 minutes or so
working on the DOM Range spec for Google instead of arguing with you. But
hopefully now we agree, although our opinions are completely irrelevant because
this is going to be WONTFIX with boilerplate "get implementers to express
interest first" anyway.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 4 February 2011 00:57:59 UTC