147813 - Any Windows/IIS installation automatically reveals the db password

Status: RESOLVED FIXED

(Bugzilla :: Documentation, enhancement, P1)

Description

[Jouni Heikniemi]

Ooph. I just realized that any installation running on Win32/IIS automatically
reveals the db password to anyone who asks it using a browser, since localconfig
is by no means protected (IIS doesn't do .htaccess). Actually, I think the same
goes for any other web server without htaccess support, too. 

Good ideas, anyone? I think this could be acceptable if we did warn the user
about this somewhere (checksetup.pl?), but to avoid annoying the Apache masses
we should somehow be able to detect the web server used... Which sounds
nigh-impossible to do. A documentation note?

Comment 1

[Dave Miller [:justdave]]

I'm pretty sure this is in the docs.  Yep:

http://www.bugzilla.org/docs216/html/security.html   5.6.5
http://www.bugzilla.org/docs/html/security.html   4.4.5

It's also in the release notes, right near the top. (5th paragraph under
"recommended practice for the upgrade")

http://www.bugzilla.org/docs216/rel_notes.txt
http://www.bugzilla.org/docs/rel_notes.txt

Comment 2

[Dave Miller [:justdave]]

I think since this is already noted in the docs and in the release notes, that
makes this WORKSFORME unless someone comes up with a way for us to set IIS's
ACLs from checksetup.pl...  :-)

Comment 3

[Jouni Heikniemi]

I stand corrected. The documentation thing sucks but does the job, and I don't
have a better proposal at hand. But despite the fact that mistake was mine, what
can we learn from this? 

When I first installed Bugzilla on Win32, I _did_ read through the manual. Not
all the sections, but security certainly was one of those I did read. I
apparently missed the documentation note because it was a small paragraph buried
in a load of stuff that didn't apply to me. I _did_ see the release note, but
seeing that it only referred to documents I read earlier, I must've somehow
skipped it again.

Even in the 2.16 docs, this security issue doesn't have visibility in proportion
to its importance. I mean, hey, the security section starts by talking about
MySQL versions and removing inetd:s - issues that can be covered by proper
firewalling etc. Something this important should not be buried below generic
unix securing measures.


I agree with justdave that this is WORKSFORME as it is. Unless somebody objects,
I'll morph this into a 2.18 documentation RFE.

Comment 4

[Bradley Baetz (:bbaetz)]

Well.

There isn't any reason that the data dir (into which localconfig really belongs)
has to be readable from the web at all. The webdot stuff is it, really, and that
can (And probably should) go somewhere else anyway.

We should move the db stuff into params, and then have localconfig give us the
path to the datadirectory.

Comment 5

[Dave Miller [:justdave]]

Yeah, but there's already another bug for that (moving the localconfig params
around).  If there isn't, there should be.  Seems like that's been discussed in
one of the Makefile bugs at least if not on its own somewhere.

Comment 6

[Matthew Barnson]

In the meantime, the short-term fix is to make sure installation instructions
for UNIX and Win32 are self-contained.  We risk data duplication with this
setup, but I can simply make the sections that bear repeating (platform-agnostic
security information) a macro and invoke them from the appropriate sections.

Thanks for the bug submission.  The layout of those installation sections
(particularly, the huge errata section) has been bugging me for a while.  This
is a good excuse to clean it up.

Comment 7

[Jacob Steenhagen]

The security page has been revised quite heavily.  About half the page now talks
about restricting access to file such as localconfig and data/.  It also
contains the Apache specific .htaccess we use in checksetup.pl, but with a not
that you should do similar with whatever your webserver is.

Comment 8

[Dave Miller [:justdave]]

-> jake

Comment 9

[Jacob Steenhagen]

The security section has changed again... now it has a specific list of what
should not be accessable. It also has links to the webserver specific section,
but that section does not contain instructions for configuring IIS (because none
have been submitted).