We have silverlight application which consume WCF services. During penetration test we found few issues. One of the suggestion is to scramble / encrypt the WCF service address in silverlight side.
Is this a standard practice or does it have any value? Will the user be able to gain any information by knowing the WCF service location if the serivce is secured. Because the user can always decompile the silverlight xap and understand how we have encrypted WCF address.
Hiding secrets in data that you give out (e.g. in client-side code) is a notoriously difficult problem. Basically, this is what DRM systems try to do, and none of them are hacker-proof. If you give someone both the secret and the code that retrieves that secret, someone will figure the secret out. And as JeffN825 pointed out, you could always use wire monitoring tools to figure out the address (a bit more difficult with HTTPS addresses, but still possible). So, I would not put much effort into hiding the address, it's just security-by-obscurity that only delays a would-be attacker. If the service requires user authentication, I would just focus on making that part secure. If you're trying to authenticate the app, not the user, it's a much more difficult problem that requires a whole separate discussion, but it's not solved by address hiding.
Related
Secure webservices in WCF
Background
We want to create a secure WCF service that has does encryption/decryption of data. The nature of data that will be encrypted and decrypted requires the highest level of security possible.
Consumers of this service will be applications within our network. The will be asp.net websites, other wcf services, console applications and possibly java based applications running on linux
Consumers will be running on local computer accounts that dont have any domain membership.
I have done a lot of reading about wcf security and do understand the concepts to a large extent. I am looking for a reference architecture that has worked well for others with similar needs.
Question
What authentication method should i use given that the new wcf service cannot depend on any database etc to store credentials, and also cannot depend of consumers to be members of a windows domain. I should be able to identify the consumer correctly within the service because the functionality will change slightly depending on who is the consumer.
What type of transfer security should i use- transport/message/mixed? Do any of these have performance considerations?
What else should i be thinking about?
Use client certificates for authentication. To identify a customer use message contracts with a custom header. Each client should put some unique value into the header.
I suggest using transport security in your case. There are two main drawbacks of using message security: Performance and which is more important to you Interoperability as you said you may need to support Java clients. You said you already read a lot about WCF security but just in case you missed it, here is a good article on Transport and Message security.
Pay attention to your service binding. I suggest using basicHttpBinding taking into account possible Java clients.
Hope it helps!
EDITED:
The header value should be a private one. Only you and your client should know about it. It's like what if I know your Gmail password, it will not take long to find out your login.
If you don't think it is secure enough you may skip custom header and map each client to an IP or a set of IPs. For example, IP 12.32.456.10 corresponds to client A. Then you can store this mappings in custom config file section and you can encrypt this section so that even people who has access to your service files can't get the mappings.
Don't forget to mark the answer as helpful if it is ;)
For the sake of argument, lets say that I've got a basicHttp WCF service. Besides implementing authentication (login/logout methods), what is stopping someone from just cracking open Visual Studio, adding a web reference to my website's service, and then playing playing around with my service? I'm not familiar with a method of stopping someone from doing this. The idea of someone downloading all of my Data/Operation contracts and then start playing around is keeping me up at night, and I like my sleep!
Discoverability is the driving factor behind Web Services and especially SOAs. The ability of anyone at all who can reach the service to pull up the WSDL, generate a proxy in Visual Studio (or some other tool), and start using the service is one of the main reasons to create a web service!
I suppose you could generate all the client proxies and then disable the mex endpoint, but that pretty much cripples WCF, and even then it's only security through obscurity.
If you don't want any miscreant to start hitting your web service then either don't use the basicHttpBinding (which is designed for the express purpose of immediate and anonymous consumption) or host the service on a private network which only trusted clients can reach.
Some form of authentication or encryption is the only thing that can prevent this. You have to distinguish between those you want give access to, and those you don't. Give the ones you want to have access the certificate necessary to do encryption, or the username and password.
Don't give anything to the others.
I am implementing wcf web service hosting in IIS with basicHttpBinding those should be accesseble by .net 2.0 client like accessing ASMX services.
Any body can help with details & with few example/sample code.
thanks
nRk
WCF is more secure than ASMX and insists the basic fact that it never allows you to send plain-text credentials without encrypting those.
You need to ask yourself a few qusetions here:
how do I protect my messages going from the client to the server, so that the username/password is not sent as plain text?
how do I check the validity of the username/password once the message arrives at the server?
For the first point, you can do a number of things:
secure the transport layer, e.g. use HTTPS (with SSL) to protect the entire pipe going from the client to the server. In that case, you don't have to do much else - the whole communication channel is protected
secure the message (at least the username/password part) using encryption. In that case, you need to have at least a service certificate on the server, so that the calling client has a shared secret to encrypt the message - or you need to install a certificate on the client (usually not a good idea if you want everyone to call your service)
For the authentication part, you need to decide on:
using the ASP.NET membership subsystem which already has a user table against which you can validate the credentials provided
or roll your own from scratch - not recommended unless you really really have to and have a very specific need
WCF security is not an easy topic - you can find helpful information and scenarios on how to do certain things here:
WCF Security by the MIcrosoft Patterns & Practice group
Declarative WCF Security by Juval Lowy
With just the few pieces of information you provided, one cannot really give a "do this and that" kind of answer. You need to read up on WCF security and decide on what scenario you want to implement. I'm sure folks here can help you with more specific questions about how to achieve certain things in WCF security, if your questions are more focused on a particular problem / issue.
I am writing a Silverlight application that will be both reading and writing data to a serverside database via some WCF web services.
What is the best way to secure these web services?
My goal is to make sure the services can't be called by other applications and potentially spammed with requests to add items to the database. Only the Silverlight application needs to be able to access them.
Don is absolutely right that there's no foolproof way of making sure that the client is a Silverlight application.
However, I think you're asking more about the following: Can I make sure that only people I trust connect to the service.
The answer here is (basically) a yes, or at least we have standardized ways of doing this.
You're typically going to want to consider a couple of different approaches:
Transport level security. Has somebody tampered with the traffic? We use SSL for this.
Authentication. Am I talking to someone I trust? Here, we'll typically use one of the authentication mechanisms (Forms Auth, say). You can use Forms Authentication to secure both Silverlight (actually the page that Silverlight resides on) and the WCF services. Confusingly, SSL can be used (though rarely is because it's a pain in the neck) for authentication.
In general, you can't assume anything about the client. If you try to keep non-Silverlight apps from hitting your site, a malicious client can easily pretend to be a Silverlight app, and you're back to square one.
That is to say, this is not an effective way to secure a server. To secure your server, assume that any and all clients will hit your site, and start from there.
Edit:
Let me amend that to say that if you want to get into the world of mutual authentication, you can set up a PKI to manage certs, issue user certs for all your users, and then you know who your users are. Still, one of them might be malicious (and talented) and inject a cert into another client.
I need to protect my WCF web services and was thinking what is the best way of doing this. Its not really a ROLE / User situation - more of a "WHO CAN CALL THE WEB SERVICE".
I was thinking that i could use an IP? Is this the recommended way?
Anybody have any experience with this, I was thinking of have a table (sql) with all IPs that can access the web service but i didn't want to reinvent the wheel if something exists already.
I presume there is an event or similar when somebody access the webservice so i can check there ip? - Anybody have an example?
And i presume this can be accomplished with standard HTTP binding ?
I would appreciate any input anybody has
You can pretty easily restrict the calling IP's in your service using a service behavior.
There's an excellent CodeProject article including source code that shows how to do this. Since it's WCF and a WCF behavior, it's pluggable, too - you can add or remove it from your service as needed.
Marc
Really depends on the security level of the service. IP addresses alone are quite easily spoofed by a knowledgeable caller, so if it's a service that deals with sensitive information, I'd recommend something a little harder to break, like transport security (eg SSL) with client certificates. Very well supported by WCF and not as scary or expensive to use as you might think, especially if you control both the client and server (that way you can configure the client to ignore the cert's "trusted" status so you don't have to buy a commercial server cert).