0day exploits that read the plain text files from a web server are the
downside of being on the Internet. 0day behavior is still "better" than
anyone being able to read some of the files with just a browser.

Agree with you that config files (if needed) should be out of the
webroot. With NT, DSNs should be configured to use low privilege users,
and the connection should be set up as "trusted". This eliminates
usernames and passwords from text files. Check out
http://www.sqlsecurity.com - Chip Andrew's excellent web site for SQL
lockdowns.

If you're doing a lot of PHP work, I also recommend everyone check out
the PHP Scarlet paper - that's excellent reading for anyone doing PHP
reviews.

http://www.securereality.com.au/studyinscarlet.txt

Answering a couple of the other e-mails:

Most .inc files aren't config files in my experience - they are usually
classes or methods that support CSS features or render a page in a
certain way. It's still important to hide these, particularly if they're
dragging stuff out of the database.

The processing overhead of a processed .asp inclusion versus a processed
.asp read is negligible. True, if you could read a file as an
unprocessed text file, there will be additional overhead of ASP
processing, but that's not how the designers wanted that file used -
they expect it to be processed.

Andrew

-----Original Message-----
From: Ryan Fox [mailto:rfoxamerisuk.com]
Sent: Wednesday, 10 July 2002 1:29 AM
To: Andrew van der Stock
Cc: webappsecsecurityfocus.com
Subject: RE: JSP (app security)

On Tue, 2002-07-09 at 03:28, Andrew van der Stock wrote:
> Kevin,
>
> It is important to reinforce the lesson of "As long as the include
file
> is not of a type that can be returned in plaintext to the server" bit
of
> your mail. I see it all the time during my code reviews, and it's
never
> a good thing.
<snip>
> If you rename 'blah.inc' to 'blah.asp', the source is processed by the
> ASP dll before being handed off to the requestor. There is no downside
> to this preferred behavior.

No downside as long as that processing happens. The downside occurs
when the latest IIS ISAPI processing exploit goes 0day and every kiddie
can retrieve that file plaintext. While I agree with you in theory, in
practice there are new exploits that cause IIS to do this every 6 months
like clockwork. IMNSHO, the place for sensitive config files is outside
the document root. A good directory layout would be:

 Web Stuff
  |
  |--Document Root
  |
   --Config Files

Setting your web server's document root to Document Root, you could set
options like PHP's open_basedir[1] to the Web Stuff directory, allowing
PHP to access the config files folder but not all the scary stuff above
it.

Cheers,
Ryan Fox

[1] http://www.php.net/manual/en/configuration.php#ini.open-basedir

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]