Re: Global.asa security under IIS 6.0

[gcb33 () dial pipex com]

Hi,

To block URLSCAN installed and deny that extensition for the web server myself i
only have the file types to allow on. That way it is not allowed would be
blocked. It dirty solution but can work for sites or persmissions in .NET that
can effect the application in question. if you are using wrappers for old legacy
 applications. 

as in .NET it is seperates the IIS from .NET calls as for '.aspx' will go from
IIS to .NET framework for executions same with SOAP call and other extenstion
calls this is IIS v5 with .NET framework haven't checked for IIS v6 but
typically would be:-

.jpg
.gif
.js
.aspx <- .NET
.asp  < ASP type old
.html
.css  <-style sheets
and also
.    < this is need for the GET / request

myself in the security development, pentration testing of banking sites is don't
allow in anycase unless needed.



Quoting saphyr <saphyr () infomaniak ch>:

> > Hi list !
> Hi there!
>
>
> > I am wondering about how much secure is the "global.asa"
> > file in ASP. It = seems that we can gather there most of the
> > parameters used with our ASP = pages, but it can be also
> > a weakness if a malicious guy gets access to = it !
>
> > So anyone one knows how secure is it to use global.asa, how
> > can we get = it from a website (IIS refuses access to it with
> > an = http://blahblahblah.com/global.asa)...and how can we
> > avoid people = stealing if ?
>
> I am not sure if you're dealing with the ASP engine or the recent
> ASP.Net one.
>
> In the first case, honestly, I don't know. But as aware as I am (...),
> there seems to be a pretty strong mecanism behind this implemened
> in the filter like a zero-condition: 'if the requested file has a .asa
> extension, do not deliver it'. Afterwards, the question is: how can
> we get that file without the server knowing it's actually an .asa one ?
>
> One possibility would be to interfer directly with the ISAPI handler,
> progammaticaly, and removing the .asa handler section. (can this be
> done ? i don't know)
>
> Another possibility would simple be to 'include' it or 'read it' using
> the FileSystem object.
>
> Never heard of that case anyway. But I am pretty sure of this:
>     - any request from the navigator cannot reach the .asa file
>     - any developer having access somewhere on the server should
>     be able to get it through some ASP code.
>
>
> In the second case, ASP.Net, that would be more or less the same
> stuff. I guess the .asax access prevention engine is 'maybe' stronger
> than its predecessor. However, the object oriented design of that
> file should allow access to it from the reflector/introspection classes,
> which again leads to the same risk: a developer who gets access to
> the server.
>
>
> .Antoine
>
> --
> Securité Web (swiss blog about web security)
> http://www.nxtg.net/securiteweb


--