Determine if a HTTP request is a soap request on HttpApplication.AuthenticateRequest

Question

I there a way to know if a request is a soap request on AuthenticateRequest event for HttpApplication? Checking ServerVariables["HTTP_SOAPACTION"] seems to not be working all the time.

public void Init(HttpApplication context) {
    context.AuthenticateRequest += new EventHandler(AuthenticateRequest);
}

protected void AuthenticateRequest(object sender, EventArgs e) {
    app = sender as HttpApplication;
    if (app.Request.ServerVariables["HTTP_SOAPACTION"] != null) {
        // a few requests do not enter here, but my webservice class still executing
        // ...
    }
}

I have disabled HTTP POST and HTTP GET for webservices in my web.config file.

<webServices>
    <protocols>
      <remove name="HttpGet" />
           <remove name="HttpPost" />
      <add name="AnyHttpSoap" />
    </protocols>
</webServices>

Looking at ContentType for soap+xml only partially solves my problem. For example,

Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 1131
Content-Type: text/xml
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: ro
Host: localhost
mymethod: urn:http://www.wsnamespace.com/myservice

Some clients instead of having the standard header SOAPAction: "http://www.wsnamespace.com/myservice/mymethod", have someting like in example above. "mymethod" represents the method in my web service class with [WebMethod] attribute on it and "http://www.wsnamespace.com/myservice" is the namespace of the webservice. Still the service works perfectly normal. The consumers use different frameworks (NuSOAP from PHP, .NET, Java, etc).

Answer 1

You could look at Request.ContentType property, which if properly set by the client should be

application/soap+xml; charset=utf-8

The utf-8 part may not be present.

Aside from that, surely you can just check the URL, and if it's a webservice one then that tells you what it is.

Answer 2

I always give web services their own port. That way I don't have to filter every HTTP request that comes across port 80. Or rather, I can filter port 80 for browser-oriented issues, and SOAP/SOA ports for other types of attacks.

IMAO, mixing (potentially) sensitive business data with public data just so you don't have to open another hole in the firewall is thumbing your nose at the very reason you have a firewall in the first place.

Answer 3

You could also go down the harder route and figure things out based on everything else that's below HTTP headers. What I mean by that is, to analyze things like below, which is the SOAP request body - part of the request...

<soap:Envelope xmlns:soap="..." soap:encodingStyle="...">

IBM