XSS (Cross-Site Scripting) has always been the browser issue, where
the malicious website can craft a URL to a website that the victim
browser trusts and make the victim browser execute script code of the
malicious website's intent.
What you are talking about is not a security vulnerability for the web
server but rather an issue of isolation for webhosters. Application
Isolation has always been controlled by the NT User Token used to
execute requests for that website. If site1.com uses the same NT User
Token (such as anonymous user account) as site2.com, then any page in
site1.com executing as that NT User account can access anything
site2.com can access. NTFS ACLs only check against the NT User
account, not from which website. The only way to isolate the two
websites on a Windows platform is by changing the NT User Token used
to execute code of each website.
As far as #include or ParentPaths or <% %> is concerned, they are just
different ways of providing a file or URL path to the system to open
up a file. The functionality were never partitioned or isolated to any
website (unlike .Net Code Access security). IIS6 introduced some
simple changes to improve isolation, such as disallowing ParentPaths
in ASP. However, any user can still use FileSystemObject from an ASP
page to read and browse the webserver's directories limited only by
the user's knowledge of the server's drive/directory layout, the user
identity configured to run the ASP page on the server, and the ACLs on
the FileSystem.
Thus, if you have code on site #1 and you know where site #2's content
is on disk, nothing ever stops you from reading/using that content,
unless site #1 is constrained with a user identity that does not have
ACLs to site #2's content.
In other words, what you want to do can be done by default, without
requiring any configuration change in IIS.
//David
http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang //
On Apr 29, 6:48=A0am, "Travis McGee" <travisGatesMc...@hotmail.com>
[quoted text, click to view] wrote:
> ok, perhaps mistake.
> I thought it was XSS was meant Cross-Site Scripting on the same web server=
,
> NOT Cross-Browser Scripting
>
> This cannot be that difficult to understand - here is what I need to do
> Imagine a web hoster: has ...
www.Site1.comfor customer1 =A0located at =A0c=
:\wwwroot\Customer1's website
www.Site2.comfor customer2 =A0located at c:\www=
root\Customer2's website
[quoted text, click to view] >
> Customer1's site cannot map an <!-- include filename=3D"Customer2's websit=
e's
> path" =A0.... due to IIS security (not personal login ID's for Customer1 a=
nd
> Customer2)
> But I want it to work.... =A0<% %> asp script in one website needs to acce=
ss
> "cross-sites" or "cross-path's"
>
> "Travis McGee" <travisGatesMc...@hotmail.com> wrote in message
>
> news:e098DfYqIHA.3548@TK2MSFTNGP06.phx.gbl...
>
>
>
> > I know you could do XSS in the past with IIS 5.0 until it got plugged, b=
ut
> > now I have a "real need".
>
> > Is it possible to loosen up the security in a control fashion?- Hide quo=
ted text -
>
> - Show quoted text -
[quoted text, click to view] > This cannot be that difficult to understand -
Actually, it is , because it's really unclear what you want to do.
You are saying: "<% %> asp script in one website needs to access
"cross-sites" or "cross-path's"" yet you are talking about using <!--
#include --> directives.
ASP doesn't know anything about #include directives. They are processed
before the ASP code is run.
So, depending on what you want to do - because it's really not clear at all:
1) If you want ASP to access pages in another site, then use ServerXMLHTTP
object to make requests to the other site
2) If you want #include directives to be able to access some kind of shared
content, then create a folder that contains the shared content, and then map
a virtual directory within each site to this shared content folder. Then
#include directives in each website can get access to all the shared files.
3) The option you were probably thinking of was Parent Paths. The default
was changed from enabled in IIS5 to disabled in IIS6. You really do not want
to enable this.
Cheers
Ken
[quoted text, click to view] "Travis McGee" <travisGatesMcGee@hotmail.com> wrote in message
news:%23nqFR$fqIHA.3548@TK2MSFTNGP06.phx.gbl...
> ok, perhaps mistake.
> I thought it was XSS was meant Cross-Site Scripting on the same web
> server, NOT Cross-Browser Scripting
>
> This cannot be that difficult to understand - here is what I need to do
> Imagine a web hoster: has ...
>
www.Site1.com for customer1 located at c:\wwwroot\Customer1's website
>
www.Site2.com for customer2 located at c:\wwwroot\Customer2's website
>
> Customer1's site cannot map an <!-- include filename="Customer2's
> website's path" .... due to IIS security (not personal login ID's for
> Customer1 and Customer2)
> But I want it to work.... <% %> asp script in one website needs to access
> "cross-sites" or "cross-path's"
>
>
> "Travis McGee" <travisGatesMcGee@hotmail.com> wrote in message
> news:e098DfYqIHA.3548@TK2MSFTNGP06.phx.gbl...
>> I know you could do XSS in the past with IIS 5.0 until it got plugged,
>> but now I have a "real need".
>>
>> Is it possible to loosen up the security in a control fashion?
>>
Don't see what you're looking for? Try a search.
