In the following settings combination, anonymous users will have access to any files in the share to which the process account has access. The following combination of settings is not recommended because of the possibility of information disclosure:

• Anonymous access to Windows SharePoint Services 3.0 is turned on.

• You have a UNC trusted location and the Process account is turned on.

Note:
The Process account is a global Excel Services setting that affects all trusted locations.

To view the Process account option:

1. On the Start menu, click All Programs.

2. Point to Microsoft Office Server and click SharePoint 3.0 Central Administration.

3. On the Quick Launch, click your Shared Services Provider (SSP) link—for example, "SharedServices1"—to view the Shared Services home page for that particular SSP.

4. On the Shared Services home page, in the Excel Services Settings section, click Edit Excel Services settings.

5. On the Excel Services Settingspage, in the Security section, look under File Access Method for the Process account option.

In a denial of service attack against a Web service, an attacker generates very large, individual requests against the Web service. The purpose is to attempt to exploit the limits of one or more Web service input values.

It is recommended that you use the Microsoft Internet Information Services (IIS) setting to set the maximum request size for the Web service.

Use the maxRequestLength attribute in the httpRuntime element in the system.web element to prevent denial of service attacks caused by users posting large files to the server. The default size is 4096 KB (4 MB).

For more information, see <httpRuntime> Element (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfhttpruntimesection.asp) and <maxRequestLength> Element (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse/html/fd52b2c5-5014-4e6f-b869-4ea666dc83d6.asp).

If the calling application and Excel Web Services are deployed to different computers, an attacker can listen to the network traffic for data transfer between the calling application and the Web service. This threat is also called "sniffing" or "eavesdropping."

To mitigate this threat, it is recommended that you:

1. Use Secure Sockets Layer (SSL) to set up a secure channel to protect data transfer between the client and the server. SSL protocol helps to protect data from packet sniffing by anyone with physical access to the network.

2. Physically protect the relevant network if the custom application using Excel Web Services is running in a confined network—for example, if Excel Web Services is deployed on a Web front-end computer within the enterprise.

For more information, see Securing Your Network (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh15.asp) and SOAP Security (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesoap/html/ceconSOAPSecurity.asp).

For information about Excel Services topology, scalability, performance, and security, see the Office SharePoint Server 2007 TechCenter or Office Online (http://office.microsoft.com/en-us/default.aspx).

It is recommended that you use SSL to mitigate the threats of hijacked Web service Internet Protocol (IP) addresses and ports, and to prevent attackers from receiving requests and replying on behalf of the Web service.

The SSL certificate is matched against a few properties, one of which is the IP address from which the message is coming. The attacker cannot spoof the IP address if it does not have the Web service SSL certificate.

For more information, see Securing Your Network (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh15.asp).

In some cases, a UDF assembly depends on other assemblies that are deployed with it. These dependent DLLs will load successfully if they are either in the global assembly cache, or in the same folder as the UDF assembly.

In the latter case, however, the load may fail. This happens if Excel Calculation Services has already loaded another assembly with the same name (either because it is not strongly named, or because another version with the same name has been deployed and loaded).

Consider the following scenario, in which the directory structure is as follows:

1. C:\Udfs\Udf01

   The Udf01 folder contains:

   • Udf01.dll

   • dependent.dll (not strongly named)

   Udf01.dll has a dependency on dependent.dll.

2. C:\Udfs\Udf02

   The Udf02 folder contains:

   • Udf02.dll (depends on Interop.dll)

   • dependent.dll (not strongly named)

   Udf02.dll has a dependency on dependent.dll. Udf01.dll's and Udf02.dll's dependencies share the same name. But Udf02.dll's dependent.dll is not the same as Udf01.dll's dependent.dll.

Assume the following flow:

1. Udf01.dll is the first DLL to be loaded. Excel Calculation Services will look for dependent.dll and load Udf01.dll's dependency, which in this case is dependent.dll.

2. Udf02.dll gets loaded after Udf01.dll. Excel Calculation Services will see that Udf02.dll depends on dependent.dll. However, a DLL with the name "dependent.dll" is already loaded. Therefore, Udf02.dll's dependent.dll will not be loaded, and the currently loaded dependent.dll will be used as the dependency.

As a result, the objects—in this case, dependent.dll, which Udf02.dll needs—are not loaded into memory.

To avoid name collision, it's recommended that you strongly name your dependencies, and name them as uniquely as possible.

To ensure that your assembly names are unique, use the fully qualified class name, following the Namespace Naming Guidelines (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamespacenamingguidelines.asp).

For example, use CompanyName.Hierarchichal.Namespace.ClassName instead of Namespace.ClassName.