views:

120

answers:

7

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 think is too easy to break my security check.

A: 

Check the referer string of the clients browser.

fixed typo, thanks Nosredna

powtac
And note that the HTTP header is tragically misspelled as "referer". Ugh.
Nosredna
Referers can be very easily spoofed.
Joe
If I understand the question correct, then there is no other solution, except session cookies. You can never know who is knocking at your server. This is the internet.
powtac
Referers are too easily spoofed and should *never never* be used for any kind of authentication. IP addresses can be spoofed as well, but that takes a completely different level of expertise and effort.
Pekka
+1  A: 

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.

inklesspen
I would avoid the use of SHA-1 as that is a hacked algorithm. Same goes for MD5.
jrista
"A hacked algorithm"? SHA-1 has some weaknesses (collision attacks which currently require massive computing power to use), but due to the way a HMAC works, collision attacks do not compromise the security of the HMAC itself. That said, I think it's fine advice to recommend SHA-256 or SHA-512 (variants of SHA-2), provided the user's system has support for this. (He should never implement HMAC or a cryptographic hash by himself; there's too much room for error.)
inklesspen
A: 

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.

pygorex1
A: 

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 :)

Adrian K
A: 

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.

Tuzo
A: 

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.

Pekka
A: 

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.

Dave Ward