My version of this document...
Any decent web programmer will hammer at his application interfaces
inputting randomly for at least an hour or so per 500 lines of code trying
to break his/her own program. That after painstakingly ensuring only certain
input is allowed to go where it needs to be, thus preventing errors from the
get-go. <hint, hint> But, as Jerry has very graciously (hate to be altavista
right now) pointed out, many applications are nowhere near flawless, from a
UI standpoint. All the examples (URLs) given were examples of not primarily
coding errors, but webserver configuration errors. Sure, the app broke, but
the webserver didn't protect the application at all...
IIS has configuration options to help keep your fallen apps from exposing
you as a lowsy coder:
App/Config in IIS4.0 MMC allows you to change the way IIS handles errors.
Choose to send simple, custom, and polite error messages instead of allowing
IIS to broadcast the address of your grossly broken code.
> - Look for search results that include the full
> path and filename for an include (.inc) file
Remember asp scripts and includes called from ASP scripts do not need IIS
read permissions
>- Security administrators need to secure
>the ASP include files so that external users
>can not view them.
"I get a chill every time my code is exposed."
-Rob Systhine <systhineat_private>
-IT/Ryno Innovate Company
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:34:56 PDT