How to verify if the Web Service caller is my web site?

For security reason, i need to garantee that only web client running an specif web site can access the web service. I'm doing verification over the domain request only, but i need to do some more robust. I thin开发者_如何学JAVAk is too easy to break my security check.

Sign a token (I recommend using HMAC with at least SHA-1). This site provides sample code for ASP.NET; I don't use .NET, so I can't verify this code.

Provide the token, along with its HMAC signature, to the client. Have the client pass it back to the web service with every request.

In the web service, simply verify the HMAC signature.

If your token never changes, though, some malicious user could observe it in the client's code and copy it. You can circumvent this by making the token a timestamp and only allowing tokens to be valid if they are within a certain period of time, or by tying the token to the specific user in some way.

Referers are insufficient as a security measure; they can be stripped by proxies or forged by malicious clients.

As noted you can check the HTTP referer but this method of validation is ridiculously easy to spoof using a tool like Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/966

A better option would be to manage sessions using cookie data, rejecting requests that don't have a valid session token.

You could protect in with a reverse proxy - which only lets traffic from a specific IP address through (or something along those lines).

Or maybe check for the presence of a specific digital certificate - I don't know exactly how you'd do that but I'm pretty sure its possible.

Can you protect the webservice with Forms Authentication? Only let known enities through?

@powtac has the right idea as well, although I'm not a security expert - I'm not sure how spoof-proof that would be, I guess it depends on your level of risk.

If you need a truly secure solution you might want to talk to a security specialist - assuming you don't get a good response here; making things work is one thing - keeping bad guys out is a different matter :)

I would not let the web browser call into the service at all.

You can have the web site proxy all requests to the web service. The web site would then provide authentication directly to your web service (basic auth under SSL, certificates, a shared secret, or some other scheme).

I'm not sure if this is practical in your situation but it enhances the security. It limits the ability of users to craft malicious requests to the web service by hacking the HTML served to them since. e.g. viewing security tokens, seeing the web service end point and data structures, etc. The weak link in the security chain is the web site. If they are not properly authenticating and authorizing their users then the security model breaks down.

I don't know what kind of web service this is, but what about either actively pushing content to the client (probably not practical) or, if you really want to make sure, actively pushing a passkey to the client every x hours/days/weeks? The passkey would be used as authentication for each request.

Since you're using ASP.NET, one easy route you can take is the built-in Forms Authentication. Since that depends on a cookie set on the same domain as the web service, a side-effect of using it is that only requests from the same domain will successfully authenticate.

Check the referer string of the clients browser.

fixed typo, thanks Nosredna