What kind of security threat i could face using web services?

Question

In regards to my this question, I got this following answer to add this to the web config file. And it also resolved the issue i was facing. But now my question is that is there any kind of security threat? if yes, how severe it could be? what kind of threat it could be? Do you suggest something else here.

<configuration>
    <system.web>
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
    </system.web>
</configuration>

Answer 1

In general, when you implement a basic SOAP web service, you are exposing the service to the world, good and bad. The main worry you have to consider in your code is validating inputs. Naively accepting strings in particular can be very damaging. If there is ANY value a number can be that you can't handle, look for it and don't continue. If you accept strings, make sure you thoroughly sanitize them (look for and be very suspicious of semicolons, and escape every "special character" you see).

A common attack on a naive service that uses unsanitized strings in a SQL query might look like "ABC'; drop database master;". If your code injected that into a SQL query without noticing the artificial query termination and malicious script, you could be cleaning out your desk the next day. The solution is very simple; escape the single quote, replace the semicolon with an ASCII or Unicode representation that you can translate back from (or simply strip it out), and the service call will treat it like the garbage it is.

That brings up a second point; your web services, even though they're your code, should be the subject of great suspicion in the rest of your system. Web services should use DB authentication that provides the least possible permissions to do their job. If your service uses an administrator or DBO login, you are almost certainly wrong; the above query, if it went through, would actually be executed, and your master DB is gone rendering your DB server inoperable. If your service used a login that very strictly controlled the permissions to only what the service needed, SQL Server would barf, but that is infinitely preferable to losing your master DB.

Also, be very careful about exception handling. A poorly-formed exception, which will be returned through SOAP much like a valid result, can include confidential information, encouraging an attacker to try to make your service throw an exception that has useful information about the implementation behind the service. SQL/ADO exceptions are particuarly over-helpful to attackers because they provide information about your data structure that could be exploited to cause trouble. Look for things that could throw exceptions beyond your control, and handle the situation gracefully before the CLR or other layers deeper than your code can barf. Trapping all exceptions is generally bad practice elsewhere, but "catch-and-release" with some sanitization could be a good idea here, and very generic 500 error redirects, which usually indicate exception trapping, are common practice in the webosphere. If you want or have to throw an exception in your code, craft it carefully and don't include any information you don't want the world knowing.

From an architectural standpoint, think of your services like an electrical outlet in the wall. The plugs are the ONLY way to get what you want (power) out of the wall. You know there are J-boxes, conduit, switches, etc. but you can't access them without a lot of (literal) hacking. Following this analogy, your endpoints should be set up to listen on specified, known ports, and the rest of the system should look like a wall from the outside; all other ports should be closed.

Answer 2

The reason that HttpGet and HttpPost are disabled by default are that hey can easily be used for XSS attacks. From http://msdn.microsoft.com/en-us/library/ff648667.aspx:

By disabling unnecessary protocols, including HttpPost and HttpGet, you reduce the attack surface area. For example, it is possible for an external attacker to embed a malicious link in an e-mail to execute an internal Web service using the end user's security context. Disabling the HttpGet protocol is an effective countermeasure. In many ways, this is similar to an XSS attack. A variation of this attack uses an tag on a publicly accessible Web page to embed a GET call to an intranet Web service. Both attacks can allow an outsider to invoke an internal Web service. Disabling protocols mitigates the risk.

For more about XS attacks, see http://en.wikipedia.org/wiki/Cross-site_scripting .

I usually avoid using HttpGet and HttpPost is possible. If it is a web service that in any way manage money, I avoid it at all costs. Use SOAP web services whenever possible.

Answer 3

I think you should migrate to WCF based web services. Apart from all other benefits that WCF has over asmx, WCF 4 has automatic response format selection (json or xml) based on HTTP accept header or in absence same as the request message format.

In general if you have public facing web services then DOS attack is something that you should worry about. At worst it can crash your service, at best it will deny legitimate callers of your WS. Malformed SOAP messages, XML bombs can be used for DOS attack.