Bugtraq mailing list archives

Re: ASP Security Hole (PHP Too)


From: daniel () PRIMEDIA CO UK (Daniel Austin)
Date: Thu, 17 Feb 2000 09:50:51 +0000


I overcame this problem in PHP by just not putting the .inc files in
available webspace - i put it up 1 directory and in a seperate folder.

for example...

In Apache on a FreeBSD machine...

a user's webspace is /home/user/public_html/
i would put the include files in /home/user/phpinc/

simple fix to the problem - the other thing i have as a safe guard is an
Apache Define that denies access to .inc files.

Daniel Austin

System Administrator,
Primedia Internet Limited.
http://www.primedia.co.uk/

On Tue, 15 Feb 2000, Joshua J. Drake wrote:

The following is also true for PHP.  Naming PHP include files .inc gives
anyone full-read access to the files by simply requesting them by name.

The solution of course is to do one of the following:

  a.  name php include files with a PHP extension (.php, .php3, etc) that is
      associated with PHP parsing them
  b.  associate .inc files with PHP so that they are parsed and not displayed

It has been preached by the ASP industry professionals for as long as I've
been in it, that ALL included files MUST have a ".asp" extension and that
ASP debugging should be disabled on all production servers in order to keep
all code out of evil hands.

The problem here is 100% between the chair and the keyboard.

 -----Original Message-----
From:       bgreenbaum () SECURITYFOCUS COM [mailto:bgreenbaum () SECURITYFOCUS COM]
Sent:       Wednesday, February 09, 2000 7:22 PM
To: BUGTRAQ () SECURITYFOCUS COM
Subject:    ASP Security Hole (fwd)

Forwarded with permission of the author. Please direct all replies to
jwalsh () jwsg com.

Ben Greenbaum
Director of Site Content
Security Focus
http://www.securityfocus.com

---------- Forwarded message ----------
Description:
============
Active server pages (ASP) with runtime errors
expose a security hole that publishes
the full source code name to the caller.
If these scripts are published on the
internet before they are debugged by
the programmer, the major search
engines index them.  These indexed
ASP pages can be then located with a
simple search.  The search results publish
the full path and file name for the ASP
scripts. This URL can be viewed in a browser
and may reveal full source code with
details of business logic, database location
and structure.

Procedure:
==========
- In the Altavisa search engine execute a search for
+"Microsoft VBScript runtime error" +".inc, "

- Look for search results that include the full
path and filename for an include (.inc) file.

- Append the include filename to the host name
and call this up in a web browser.
Example:  www.rodney.com/stationery/browser.inc

Examples:
=========
http://shopping.altavista.com/inc/lib/prep.lib
Exposes database connections and properties, resource locations,
cookie logic, server IP addresses, business logic

http://www.justshop.com/SFLib/ship.inc
Exposes database properties, business logic

http://www.bbclub.com:8013/includes/general.inc
Exposes cobranding business logic

http://www.salest.com/corporate/admin/include/jobs.inc
Exposes datafile locations and structure

http://www.bjsbabes.com/SFLib/design.inc
Exposes source code for StoreFront 2000 including
database structure

http://www.ffg.com/scripts/IsSearchEngine.inc
Exposes search engine log

http://www.wcastl.com/include/functions.inc
Exposes members email addresses and
private comments file http://www.wcastl.com/flat/comments.txt

http://www.traveler.net/two/cookies.inc
Exposes cookie logic

Resolution:
===========

- Search engines should not index pages that
have ASP runtime errors.

- Programmers should fully debug their ASP
scripts before publishing them on the web

- Security administrators need to secure
the ASP include files so that external users
can not view them.




===========================
Jerry Walsh
JW's Software Gems
Email  jwalsh () jwsg com
Phone  (949) 855-0233
Website http://www.jwsg.com
===========================




Current thread: