[13827] in bugtraq
Re: ASP Security Hole (fwd)
daemon@ATHENA.MIT.EDU (Rob Systhine)
Tue Feb 15 12:56:25 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <001101bf7416$43890920$3d381c18@tampabay.rr.com>
Date: Thu, 10 Feb 2000 17:29:14 -0500
Reply-To: Rob Systhine <systhine@TAMPABAY.RR.COM>
From: Rob Systhine <systhine@TAMPABAY.RR.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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 <systhine@tampabay.rr.com>
-IT/Ryno Innovate Company
