Not if you value any of the ASP code they contain. There are sites all over the web that use .inc file to hold their database connection info and other data that should remain on the server side; they think that information is safe because they haven't told anybody where it is. Well, I remember several times I would get an error on someone's site, and the error message would tell me:
Error Type: Microsoft VBScript runtime (0x800A01B6) Object doesn't support this property or method: 'rs.moveOver' /includes/database.inc, line 3 |
So, I would type in the URL to /includes/database.inc file and, lo and behold, the browser would dump out the ASP code (in a few cases, with sa passwords!). In fact just now, it took me all of five minutes to find a username / password through a search on Google, register the server in SQL Enterprise Manager, and be tempted to execute a command like:
| TRUNCATE TABLE master..sysobjects |
Of course I didn't do this, and promptly informed the server's owner about the hole (and that they should change their password, pronto).
There are two decent workarounds that will prevent this from happening to you. One way is to leave your .inc files alone, and simply map .inc extension to asp.dll (as described in
Article #2124). The other is to simply use the .asp extension on all files that include ASP code. If you need to differentiate between "includes" and normal interface pages, simply change your naming scheme a bit. In one project I was involved in, the authors had realized the security concerns and quickly renamed all files such as "include.inc" to "include.inc.asp" - so the files were still easily identifiable as includes, but they were protected from casual viewing.
One concern people have raised in the past about the extension workaround is that now asp.dll will have to process all "includes" as ASP files... even the ones that don't contain ASP code. Never fear, IIS 5.0 and above have much smarter interpreters that only invoke the ASP engine when necessary.