httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haskovec <>
Subject Re: ASP vulnerability with Alternate Data Streams (fwd)
Date Thu, 02 Jul 1998 02:39:50 GMT
Apparently the fix for this (at least under the Netscape httpd) is to
remove read permission and allow only execute permission on the scripts.

Here's, fwiw:

Response.Expires = 0 
If Not Request.QueryString("MSDPWD") = "MSCOMPRO" Then On Error Resume
If InStr(Request.ServerVariables("HTTP_USER_AGENT"), "MSIE 4") = 0 Then


On Wed, 1 Jul 1998, Marc Slemko wrote:

> Damn it.
> Note that I do _NOT_ feel at all sorry that these problems are likely in
> Apache as well on NT because it really isn't our fault.
> ---------- Forwarded message ----------
> Date: Tue, 30 Jun 1998 15:27:32 +0200
> From: Paul Ashton <paul@ARGO.DEMON.CO.UK>
> Subject: ASP vulnerability with Alternate Data Streams
> Following on from the last .asp vulnerability which applied to
> URLs ending in spaces, and the previous that allowed .asps to
> be read if they end in ".", it turns out that there is yet
> another due to Alternate data streams.
> The unnamed data stream is normally accessed using the filename
> itself, with further named streams accessed as filename:stream.
> However, the unnamed data stream can also be accessed using
> filename::$DATA.
> If you open http://somewhere/something.asp::$DATA it turns out
> that you will be presented with the source of the ASP instead
> of the output. Deja vu?!
> It is left as an exercise for the reader to thing of further
> implications in other programs running on NT. Obviously,
> anything that to tries to restrict access based on filename
> instead of ACLs is going to have a hard time after this and
> the other recent revelations.
> Paul

View raw message