Microsoft Web Services Security Recommendation: Disable HTTP-GET

Mr. FoRK fork_list@hotmail.com
Tue, 19 Mar 2002 20:33:15 -0800


And we all thought GET was safe...

--

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/ht
ml/disHTT.asp?frame=true

Security Recommendation: Disable HTTP-GET and HTTP-POST Protocols for
Production XML Web Services

February 2002

Summary: For security reasons, Web service operators may want to disable the
HTTP-GET and HTTP-POST messaging protocols for XML Web services. Disabling
these protocols will help prevent external Web sites from maliciously
communicating with XML Web services on your intranet. (5 printed pages)

Contents
Introduction
Disabling HTTP-GET and HTTP-POST Protocols for ASP.NET-based XML Web
Services
Effects of Disabling HTTP-GET and/or HTTP-POST
Conclusion

Introduction
Due to the inherent functionality of HTTP-GET and HTTP-POST messaging
protocols, it is possible under certain conditions for a malicious Web page
to invoke an XML Web service running behind a firewall using parameters
defined by the malicious Web page. This is similar to other issues involving
malicious redirects based on the HTTP-GET. This can occur if the XML Web
service supports communication using the HTTP-GET or HTTP-POST messaging
protocols, which are enabled by default for XML Web services created using
ASP.NET.

Although it is not easy to create a malicious Web page using HTTP-POST,
support for the HTTP-GET and HTTP-POST messaging protocols should be
disabled on production machines hosting XML Web services created using
ASP.NET if they are not being used by the service.



Figure 1. Common Incident of Malicious Communication

Step Description
1 An HTTP client, such as Microsoft® Internet Explorer, sitting behind a
firewall browses to a malicious Web page containing a link.
2 The Web server returns to the client a Web page containing a malicious
link. When the user clicks the link, a request is made (unbeknowst to the
user) to an XML Web service hosted on the client's intranet.
3 A request is made by the malicous Web page to the XML Web service based on
the parameters provided by the Web page and under the client's credentials.

The Figure 1 scenario can only happen if:

The XML Web service supports communication using the HTTP-GET or HTTP-POST
messaging protocol. (The case for HTTP-POST is a little more complex; see
the code example below for HTTP-POST.)
The external developer of the malicious Web page has internal knowledge of
the XML Web service's existence and invocation details.
The client has access permissions to execute the internal XML Web service.
Although this scenario outlines how the XML Web service can be maliciously
invoked using HTTP-GET, the same issue applies for HTTP-POST. For the XML
Web service to be similarly executed using HTTP-POST, the Web page must
contain script redirecting the client to the XML Web service when the user
clicks anywhere that causes a post back to the external Web server.

The following code example is a Web page containing a malicious link to an
XML Web service running on the client's intranet that uses the HTTP-GET
protocol. In this example, the user must click the link; however, it is
possible for the Web page to contain script that performs a redirect,
bypassing the need for user interaction.


To Get Rich Quick!


Likewise, the following code example is a Web page containing a malicious
button that communicates with an XML Web service running on the client's
intranet using the HTTP-POST protocol.

<form method="POST"
action="http://AnIntranetServer/401K.asmx/ChangeWithholding">
  <input type="hidden" name="pretax" value="2.5">
  <input type="hidden" name="posttax" value="3.5">
  <input type="submit" value="Get Rich Quick.  Click here for more
details." ></p>
</form>

It should be noted that this scenario does not apply to an XML Web service
that only allows the SOAP over HTTP protocol to communicate with it. SOAP
requests require the SOAPAction HTTP header, which a Web page does not have
the capability to include in a redirect using a link.

Disabling HTTP-GET and HTTP-POST Protocols for ASP.NET-based XML Web
Services
By default, clients can communicate with XML Web services created using
ASP.NET by using three protocols: HTTP-GET, HTTP-POST, and SOAP over HTTP.
Using the configuration system supported by the Microsoft .NET Framework,
you can modify the protocols supported by XML Web services within an
individual Web application or for the whole machine.

Whether you disable HTTP-GET and HTTP-POST at the machine or Web application
level, it is just a matter of modifying a configuration file, which in the
.NET Framework is simply a text file. The default configuration for the
machine is set in the Machine.config file, which then can be overridden for
each Web application by modifying a Web.config file within the root
directory of that Web application.

It is a good practice to disable support for both the HTTP-GET and HTTP-POST
messaging protocols at the machine level on production machines that do not
require them. For special cases in which XML Web service clients communicate
with an XML Web service using either HTTP-GET or HTTP-POST, you can add
support for those protocols for the Web application hosting them.

Disabling HTTP-GET and HTTP-POST protocols for the whole machine
(recommended)
Open the Machine.config file in your favorite text editor. (The default
installation places Machine.config in the
C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\CONFIG folder.)
Comment out the lines within the webServices section that add support for
HTTP-GET and HTTP-POST. After doing so, the webServices section should look
like the following:
<webServices>
    <protocols>
      <add name="HttpSoap"/>
         <!-- <add name="HttpPost"/> -->
         <!-- <add name="HttpGet"/>  -->
      <add name="Documentation"/>
    </protocols>
</webServices>

Save Machine.config.
This configuration change will take effect on the next request to an XML Web
service hosted on that machine.

Disabling HTTP-GET and HTTP-POST protocols for an individual Web application
Open the Web.config file in the root directory of the Web application with
your favorite editor. (If a Web.config file does not exist, create one.)
Modify the webServices section of Web.config to explicitly remove the
HTTP-POST and HTTP-GET protocols using the following format (add this
section to Web.config if it does not contain a webServices section):
<webServices>
     <protocols>
       <remove name="HttpPost" />
       <remove name="HttpGet" />
     </protocols>
</webServices>

Save Web.config.
This configuration change will take effect on the next request to an XML Web
service hosted by the Web application.

Adding support for the HTTP-GET and HTTP-POST protocols for individual Web
applications
Open the Web.config file in the root directory of the Web application with
your favorite editor. (If a Web.config file does not exist, create one.)
Modify the webServices section of Web.config to add the HTTP-POST and
HTTP-GET protocols using the following format (add this section to
Web.config if it does not contain a webServices section):
<webServices>
     <protocols>
       <add name="HttpPost" />
       <add name="HttpGet" />
     </protocols>
</webServices>

Save Web.config.
This configuration change will take effect on the next request to an XML Web
service hosted by the Web application.

Effects of Disabling HTTP-GET and/or HTTP-POST
The drawbacks of disabling HTTP-GET and HTTP-POST are likely minimal for a
production machine. The drawbacks are as follows:

The default service help page for the XML Web service will continue to work,
but a prospective client will not be able to test the XML Web service using
the Invoke button on the service help page.
To debug the XML Web service in Microsoft Visual Studio® .NET, you must
create a test client program.
For a production XML Web service, both of these drawbacks are easily
overcome because Visual Studio .NET makes it easy to create a client to an
XML Web service with the Add Web Reference command.

Conclusion
Production machines hosting XML Web services created using ASP.NET should
disable the HTTP-GET and HTTP-POST messaging protocol support at the machine
level in order to avoid a potential security breach in many situations. For
early-stage development, you may want to leave these protocols enabled on
developer machines; this will enable the developer machines to use the
service help page to test XML Web services. Once the machine is placed in
production, alter the .config files to disable HTTP-GET and HTTP-POST.

It should be noted that this is not the only security option that XML Web
service developers should take. This is just one of many steps and issues
involved in securing an XML Web service.