Published: Friday, February 04, 2000
Security Alert - Using includes Improperly from non-Debugged ASP Pages can allow Visitors to View your souce code
By Jerry Walsh
Security Flaw
If you use include files improperly, you may be in for a nasty surprise.
By improperly, I mean that you give include files an extension other than
.asp. For example, say that you have an include file named
dbConn.inc, which established a connection to your Access database.
Imagine that dbConn.inc had the following code:
<%
Dim objConn
Set objConn = Server.CreateObject("ADODB.Conection")
objConn.ConnectionString = "DRIVER={Microsoft Access (*.mdb)};" & _
"DBQ=" & Server.MapPath("/MyDatabase.mdb")
objConn.Open
%>
|
The above snippet of code, I'd assume, is common on many ASP sites. The problem is that
the file has a .inc extension. So, if someone entered into their browser,
http://www.yourserver.com/dbConn.inc, they could view the source code of
dbConn.inc, which could be disastrous, since dbConn.inc
indicates the location of an Access database file on the Web server that could also
be easily downloaded by anyone (http://www.yourserver.com/MyDatabase.mdb).
Now, you may not be worried, thinking that no one could guess the filename
dbConn.inc. Perhaps you're right. However, look closely at the code
above, specifically on line 3. Note that the class string, ADODB.Connection,
is spelled incorrerctly, missing a second n in Connection.
This will cause an error.
Again, you may think, "So what?" Well, say that from somePage.asp you
include dbConn.asp, like so:
<!--#include virtual="/dbConn.inc"-->
<%
'Do stuff with the database
%>
|
Now, when you visit somePage.asp, you will get an error, reading
along the lines of:
Microsoft VBScript runtime error '800a004'
Invalid Class String
/dbConn.inc, line 3
|
Again, you may be thinking, "So what?" Well, if this ASP page is not debugged, and
someone visits it, now they know how to get to see the source code for dbConn.inc!
You may decide not to link to somePage.asp until you have it debugged, but
you still run the following risk
that one of the major search engines may index them.
These indexed ASP pages can be then located
with a simple search, and the source code for the include file viewed!
To view some of these security holes, use the following procedure:
- In the Altavista search engine
execute a search for +"Microsoft VBScript runtime error" +".inc, ". This
will look for files that have some sort of error in an included
.inc file.
- Look for search results that include the full
path and filename for an include (.inc) file. You'll see the
description of the search result as something like:
Microsoft VBScript runtime error '800a004c' Path not found. /NewSite/header.inc, line 94
|
- Append the include filename to the host name of the returned search hit,
and call this up in a web browser. There are even some very large web sites with this flaw!
Example: AltaVista's Shopping Site - http://shopping.altavista.com/inc/lib/prep.lib
Example: Microsoft - http://www.microsoft.com/windows/downloads/inc/global.inc (be sure to do View/Source to see the code)
Note: these files, which are suppose to be hidden, expose
database connections and properties, resource locations,
cookie logic, server IP addresses, business logic, and other, similar, pieces of information!
There are many examples you can find of this just by searching through AltaVista!
Many of these sites reveal important business logic code, database connection information,
and other sensitive information.
Resolution
To avoid this fate for your Web site, be sure to
fully debug your ASP scripts before publishing them on the web! Furthermore,
security administrators need to secure the ASP include files so that external users
can not view them. You can do this in two ways:
- Give your
include files an extension that external viewers cannot see
(such as .asp).
- Place all of your
included files into a single directory, and turn off
Read permissions for that directory.
To learn more about include files, be sure to read
The low-down on
includes.
