Hoster Poster

Atlas makes it possible to easily take advantage of AJAX techniques on the Web and enables you to create ASP.NET pages with a rich, responsive UI and server communication.  The March Atlas CTP (Customer Technology Preview) is released with a "go live license" which means developers can deploy applications built with this technology on production servers.  

There is a ton of great information (download, samples, videos, walkthroughs, etc) about Atlas at http://atlas.asp.net  so instead of duplicating that information I am going to focus on the few things that are relevant to you as a hoster:

• Atlas has friction free deployment, so developers with FTP access to the server will be able to deploy the Atlas code and their applications the same way they would any other ASP.NET application.
• The Atlas code will run in Medium trust. However, a primary usage of Atlas is to build mash-ups which typical involve calling web services on remote machines.  To enable web service calls, outside of the requesting application, requires a modification to medium trust.  Find out how to do this by reading Enabling WebPermission in Medium Trust.
• Some of the samples distributes with the Atlas CTP rely on the XMLField in SQL Server 2005. As a result these samples will not function properly on SQL Server 2000.
• The Building Mash-Ups with Atlas walkthrough explains how to enable the .asbx file extension on IIS.  Check out the Tunneling the Bridge Calls with .axd Extension article for an alternative solution with the .axd extension.

Please let us know if you find any additional issues with Atlas running in your hosted environment.

The goal of Code Access Security (CAS) is to reduce the attack surface by enabling applications to run with minimum required permissions to function. In ASP.NET 1.1 there were some limitations in enabling oleDB access in a partial trust setting based on medium trust, this limitation has been resolved in ASP.NET 2.0. For more general information about using CAS with ASP.net 2.0 see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh19.asp.

We recommend that hosters run in Medium trust because most applications will function correctly and provide a good level of protection to your server and other applications on your server by restricting certain functionality. However, we know that some common functionality used by web developers requires additional permissions to be enabled in medium trust. For example, to enable Access database to be called you must create a custom trust setting that enables OldDb access. We are increasingly seeing web applications need to make cross application web service calls. For example, an ecommerce web site that needs to make a web service call to get a credit card authorization.  To enable this scenario the WebPermission which is locked down in Medium trust to only allow calls to $OriginHost$ needs to be expanded to allow calls to other sites.

But an application with expanded WebPermission access could also make requests that are malicious or dangerous. For example:

·          An application could make a call to administrative web services on the internal network. If your administrative web services are not locked down (and especially if they run in Full trust), you need to ensure that other applications on the network cannot reach them.

·          An application could launch a denial of service (DOS) attack against other web servers on your network or the internet.

·          Depending on how you track bandwidth, if the application is making requests through a proxy server, it may not be tracked.

·          An application could bypass customErrors restrictions and might be able to obtain detailed error information, including a stack trace and the physical path, for another application on the server.

However, there are mitigations for these risks, including:

·          Ensure that your firewall prevents outbound HTTP/HTTPS traffic from the web server. This means that an application cannot make a direct call to a server or site on the internet.

·          Add or configure your proxy server to allow requests from the web servers to internet resources. Be sure that you log requests from the web servers. 

·          Only allow the web server to make proxy requests to the internet, not to the internal network. So, if the destination of the request is the internet, it should be allowed to go through proxy. But if the application is trying to request a resource or server on the internal network, it should be prevented.

·          Throttle the number of requests that can go through the proxy server. This is important because even if you force all outbound web requests to go through the proxy server, if you do not throttle the number of requests, you could still have a DOS attack launched from your web server by a hosted application.

·          Set a default proxy server in your web server’s root level Web.config and do not allow applications to override this setting. This would prevent applications from making direct web service calls to other machines on the network and bypassing the proxy server. It would also prevent requests to other applications on the server appearing to originate from localhost and being able to obtain detailed error information.

Because there is a risk associated with enabling WebPermission, it is not enabled by default and should be enabled by a hoster only after they’ve made an assessment to determine how the risks will affect them and what mitigations are sufficient for their environment.

How to Enable WebPermission and defaultProxy

To configure a default proxy server and prevent overrides

1.      Open the machine-level Web.config file in Notepad (this file is located in %windir%\Microsoft.NET\Framework\{version}\CONFIG\.)

2.      Find the defaultProxy element in the Web.config.

    <system.net>

        <defaultProxy>

            <proxy usesystemdefault="true" />

        </defaultProxy>

    </system.net>

3.      Set the child element usesystemdefault to false, then add and set the child elements proxyaddress and bypassonlocal, as shown in the following example.

    <system.net>

        <defaultProxy>

            <proxy usesystemdefault="false"
             proxyaddress=http://proxyserver
             bypassonlocal=”false” />

        </defaultProxy>

    </system.net>

4.      Add a <location> tag, set the allowOverride attribute to false. This prevents an application from changing or setting defaultProxy in their own Web.config.

<location allowOverride=”true”>
     <system.net>

        <defaultProxy>

            <proxy usesystemdefault="false"
             proxyaddress=http://proxyserver
             bypassonlocal=”false” />

        </defaultProxy>

    </system.net>
</location>

For more information about the defaultProxy element, see defaultProxy Element (Network Settings), at http://msdn2.microsoft.com/en-us/library/kd3cf2ex(VS.80).aspx.

To enable WebPermission in a custom trust level

1.      This example assumes that you have already created a custom trust level based on Medium trust, as described in the ASP.NET 2.0 Server Setup and Deployment section of the ASP.NET 2.0 Deployment Guide. If not, you should follow those instructions to create a custom policy that you will then edit in this example.

The ASP.NET 2.0 Deployment guide is located at http://www.microsoft.com/downloads/details.aspx?FamilyID=9e33ea25-666c-47fa-ac52-8d04785c4bd2&displaylang=en.

2.      Open the web_CustomTrust.config file in Notepad (this file should be located in %windir%\Microsoft.NET\Framework\{version}\CONFIG\).

3.      Add the additional permission to the custom policy.

a)   Find the WebPermission in the web_CustomTrust.config file, as shown in the following example.

...

     <IPermission class="WebPermission"

                  version="1"

             <ConnectAccess>

                <URI uri=”$OriginHost$” />

             </ConnectAccess>

</IPermission>

...

b)   Edit the WebPermission so that the ConnectAccess element is removed and Unrestricted is set to true, as shown in the following example.

...

     <IPermission class="WebPermission"

                  version="1"

                  Unrestricted="true"/>

     ...

Setting WebPermission unrestricted to true enables all web requests to any destination. But by also configuring defaultProxy and adding other restrictions into your network infrastructure, you are adding layers of defense to help prevent misuse of the WebPermission.

For more information about WebPermission, see WebPermission Class, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnetwebpermissionclasstopic.asp.

Note: We are planning to update the ASP.NET 2.0 Hosting Deployment Guide with this information, so please send us your feedback and comments.

Some of the information will be links to great resources (QFEs, whitepapers, web casts etc) directly relevant to hosters, some will be quick snippets of information that don’t warrant a full whitepaper and some might be topics for discussion when we ask you what you are thinking.  I am sure that over time this list will grow and expand based largely on your feedback.

A word about feedback - we will do our best to respond to questions on the blog but don’t forget that the hosting forums are a great way to get your questions answered.

Thanks

The Hoster Poster Team