views:

181

answers:

3

I have a site in development with several web services (ASMX) that post important data to my database. When I navigate to the ASMX file in my browser, I can fill in the form with the parameters and post to the DB. If someone finds the URL to my WS, they can severely alter my database. I want to prevent people from being able to post to my WS publicly. So far, I've thought of two things that may help but I'd like to know if there are any other ways:

  • Check to see if the HTTP Referrer to the WS method is the domain the WS is on
  • Add an additional parameter called Key to all important WS methods and have this be an encrypted "password." Then encrypt my stored password on the WS side and compare if the keys match.

If there are any other best practices or techniques I can use to secure my WS, please share!

A: 

If the referrer is in the same domain then an easy way would be to set a cookie in the referring page and then check for the existence of the cookie in the ASMX (plus whatever other checks you want to implement). Note that the domain has to be the same otherwise this technique won't work.

Reza
+1  A: 

The easiest thing to do is to just disable that test page. You can do this by adding the following to your web.config of your web service:

<webServices>
<protocols >
<remove name="HttpGet"/>
<remove name="HttpPost"/>
<remove name="HttpPostLocalhost"/>
</protocols> 

Also, here is a decent article on other ways to secure your web service, including adding authentication in the soap header.

AaronS
Thanks! Those `web.config` changes were what I was looking for to disable the test page form fields. I'll also look into the SOAP headers moving forward with any of my web services.
Mark Ursino
+4  A: 

Some of these might be helpful to you:

Also please note that the test webpage (which shows sample tetboxes) should only be accessible from the local machine, if it is viewable from other machines there is probably a configuration issue going on.

GrayWizardx
+1 SOAP security headers are the best way to go.
Joel Etherton
Thanks for the useful links. I didn't end up marking this as the answer because the configuration changes were really what I was looking for mostly, but these links will be useful moving forward for any public-facing web services I create from now on. Thanks!
Mark Ursino