Helper API Security
This topic describes security issues associated with XMLHTTP and ServerXMLHTTP. In addition, it provides some guidance for mitigating security exposure.
XMLHTTP
The following sections provide information about Helper API security, with an emphasis on XMLHTTP.
Use XMLHTTP Only on the Client
XMLHTTP should only be used on the client. Because XMLHTTP is marked safe for scripting, you call XMLHTTP from a script that is executed in the client-side Internet browser. Remember, you can use XMLHTTP and ServerXMLHTTP in any arbitrary script, inside or outside the browser. XMLHTTP is not safe for server-side implementation. Using XMLHTTP on the server means that you would use XMLHTTP via JScript, VBScript, C++, ASP, or ASP.NET. XMLHTTP is not thread-safe - it doesn't work for multi-threaded scenarios. If you use XMLHTTP, you will not receive an error, but your script may not perform properly. If you need XMLHTTP functionality on the server, you should use ServerXMLHTTP, not XMLHTTP.
XMLHTTP Uses Cached Credentials
XMLHTTP uses cached credentials if the user does not provide new credentials for every open method call in scenarios where specific credentials are used. Kiosk-style applications using XMLHTTP for multiple users that share a single login should always ensure that they terminate the Internet Explorer process when a user finishes a session. Furthermore, kiosk-style applications should never display the address bar as part of the application.
Set the Site Object to Prevent Cross-Site and Cross-Domain Attacks
When using XMLHTTP outside of Internet Explorer, it is important to set the Site object to prevent cross-site and cross-domain access on calls to the open Method (IXMLHTTPRequest). If the Site object is set, on redirects the redirect target is automatically checked against the initial Open request, and the standard cross-zone and cross-domain checks are applied.
In Internet Explorer scripting scenarios, the Site is set by Internet Explorer.
Validate the URL Before Calling Open in XMLHTTP
You should not accept untrusted data to construct a URL when calling the Open method. You should validate the data first, making sure that the user is allowed to enter only approved addresses. This is particularly important in scenarios outside of Internet Explorer when the Site object is not set, where it is up to you to prevent cross-domain and cross-site attacks.
Spoofing and Best-Fit Character Attacks
In spoofing attacks, an attacker attempts to craft information that dupes software to accept the information, such as an HTTP request, as coming from a trusted third party. One approach is for the attacker to construct a URL, perhaps using escaped characters, so that it looks like a URL to a trusted site, when in fact it is a URL to a site that has been set up with malicious intent. Another method is to use best-fit character attacks, where higher order characters in a string resource are mapped to lower order characters by certain programming interfaces, either by accident or deliberately. For example, an attacker might submit a URL to a site micrõsoft.com, with the intent that it be interpreted as microsoft.com.
Both types of attacks might be used by an attacker to dupe host identity, probe for string processing vulnerabilities in a system, or as part of a phishing attack. A phishing attack is one where an attacker pretends to be from a trusted source. Typically, it involves an attempt to fool the user into entering user names, passwords, and other private information.
XMLHTTP and ServerXMLHTTP do not validate string input, including the HTTP Verb and URL, submitted in the Open() method call. If your application completely controls the URLs which are passed to XMLHTTP or ServerXMLHTTP methods, including request headers and query string, you might not be vulnerable to this class of attacks. You are vulnerable if you permit URLs or portions of URLs from an untrusted source, including user input.
The ServerXMLHTTP and XMLHTTP components follow strict rules to permit or deny redirects. Note that the general behaviors described below might change with Internet Explorer or Windows security settings. The principle rules are the following:
For ServerXMLHTTP, there is no zone redirect checking when in asynchronous mode.
To mitigate Redirect-based DoS attacks, XMLHTTP and ServerXMLHTTP components implement redirect limits.
Redirects are typically permitted from zones of greater security to zones of equal and lesser security. For example, a redirect from a resource in the Intranet zone to Internet zone should succeed.
Redirects are not permitted from zones of lesser security to zones of greater security. For example, a redirect from a resource in the Internet zone to the My Computer zone should fail.
Redirects are not permitted across networking protocols.
Redirects are not permitted across network domains.
Strictness in MSXML 6.0 May Prevent Some Applications from Working
IE defines five zones - MyComputer, Trusted Sites, Local intranet, Internet, and Restricted Sites. There are a number of rules regarding how a site in one zone can reference a site in another zone. For example, a site on the Internet can't reference a document on the Local intranet. In IE, and for applications that set the site explicitly, MSXML 6.0 is strict about URL redirection, and may prevent some user scenarios. In order to work around the security restrictions, the user can add the machine doing the redirection to the list of trusted sites on the machine where the redirection is taking place.
Error Messages May Reveal Data
The description of an error may reveal data. Error messages should not be exposed to callers that are not trusted. You should catch all errors and report errors with your own custom error messages.
ServerXMLHTTP
The following sections provide information specific to ServerXMLHTTP.
Use ServerXMLHTTP Only on the Server
ServerXMLHTTP should not be hosted in the browser; it is not marked safe for scripting.
Use HTTPS to Provide Encryption for Sensitive Data
ServerXMLHTTP does not provide any encryption by default. You should use HTTPS connections to encrypt sensitive data during transmission.
Response Packages Are Insecure
Response packages are generally not secure (responseXML Property (ServerXMLHTTP-IServerXMLHTTPRequest), responseBody Property (ServerXMLHTTPRequest-IServerXMLHTTPRequest), and responseText Property (ServerXMLHTTP-IServerXMLHTTPRequest)). ServerXMLHTTP is used to retrieve information from other sites on the internet. When you retrieve data using it, you should know that the source of your information is trustworthy. Further, after using a response package, you should check for malicious data (both size and content). The ServerXMLHTTP object does not check for denial of service threats or bad data returned from response packages. ServerXMLHTTP should not be used to load untrusted XML in applications where denial of service is a concern.
No Secure-Base-URL Checking for Redirects
ServerXMLHTTP does not provide secure-base-URL checking for redirects. You should be aware that, when accessing untrusted locations with MSXML 6.0 ServerXMLHTTP or MSXML 3.0 ServerXMLHTTP in asynchronous mode, there are no checks on redirects. There are checks on the initial Open (both for the Open call and for any external references within the instance).
Spoofing and Best-Fit Character Attacks
ServerXMLHTTP is vulnerable to both spoofing attacks and best-fit character attacks. For more details, see the discussion under XMLHTTP, earlier in this topic.