Enabling WebPermission in Medium Trust

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://msdn.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.