Securing Public Web Services - What is the best practice? [closed]

Question

There seems to be a number of ways to secure web services. OAuth, API Keys, Tokens, WIF, etc. Since security is not my area of expertise, I am asking what is the best ways to secure public web services.

Al least tell me what I should be thinking about to come to a standard way of securing the public web services.

Answer 1

As said by Tom Leek, security is a HUGE area. It covers everything from security secrets, protocols, assets, to privacy, repudiation, availability, disasters recovery etc. I know you started the question about protocols, I am going ahead with a little bit more because I do not know if your perception is that just adding these will suffice for security, or if you have everything else already secured and this is the only area left.

In addition, security is across the entire stack, anywhere from ensuring that you do not have code bugs (such as buffer overflows) to all security patches applied, to overall secure design (how do users authenticate, access control, etc.).

You will either have to narrow specifically what you are trying to secure, or if you are looking to improve security in general, try these:

• Look at ISO 27034 and Microsoft's SDL both of which give prescriptive guidance on how to push security into development process (Disclaimer: I work for Microsoft, and SDL is one of my primary sources at work and in personal projects.)
• You can also look at certification books, such as those for CISSP or CCSK from Cloud Security Alliance, which will focus more on various applicable security principles. Of course, you can search for more certifications and read reviews to pick the best one for your purpose.

Both of these, esp. SDL from Microsoft (only because I have intimate knowledge of it) will give very prescriptive guidance, and has links to it. I have studied CISSP, but that's more of a Chief Security Office level. Both are valuable though, but if I could do just one, I would go with SDL, or some resource that targets ISO 27034, or something similar.

• Lastly, no matter how much of this stuff you read, you will have to stay on top of current security issues, and make sure you keep applying fixes. For example, if you have a website, there's a plethora of attacks around XSS, XSRF, SQL injection, XML bombs, etc. that you'll have to know and depending on what technologies you use, will have to ensure are not exposed in your service.
• Like these attacks, you will also have to make sure that you know what external software you are using (including the OS), and what are the latest security issues and whether you have applied all the patches, etc. This means apache, IIS, Linux, Windows, you name it. For example, if you used OpenSSL (even if you didn't know, but your installation for example had it), you had better applied a fix to guard against Heart Bleed vulnerability.

As far as protocols are concerned, usually it comes down to your design around who is going to access, what is being secured, etc., pretty much most of the questions that Tom Leek asked. Between some protocols (such as OAUTH and SAML), it is not so much that they will differ in security (depending on your needs), rather that different ones are supported by different parties you may want to integrate with. For example, most, if not all, social IDPs (facebook, google, Microsoft account, linkedin, even stackexchange) support OAUTH, and if you were to use either of them as your identity provider, you would be forced to consume OAUTH and token formats supported by any of these.

However, if you were acting as your own IDP, then you would have more choice and you would consider whether you want to use a directory (esp. if your organization already has one, such as AD), or build your own. A directory will typically provide a set of protocols it supports for authentication. If you already have a third party service your organization is using (e.g. SAP, Salesforce, Office online), it might be possible to use authentication from there.

Hope this helps.

Answer 2

Asking for the best practice to secure some public service, without any other detail, is like asking what is the best car. The only answer can be: it depends. Do you need the car to transport heavy equipment ? To reliably go to work even in a snow storm ? To roam the streets for hours as part of a vigilante group ? To woo prospective mates ?

Since we are talking generalities, then the first thing to do is to write down the security model:

• What assets are you trying to protect ?
• What is the assumed extent of the power, motivation and patience of the attackers ?
• What is the value of that which you protect ?

In particular, for a public network-based service, you may or may not fear the following cases (non-exhaustive list):

• An attacker sends a request to your service without being authorized to do so.
• An attacker spies on the data exchanged between your service and an authorized user.
• An attacker modifies a request from an authorized user to your service, and/or modifies the response.
• An attacker poses as a fake clone of your service, and talks to your users without your service being ever made aware of it.
• An attacker disrupts your service by overloading it.
• An authorized user spies upon other authorized users accessing the service at the same time.
• Legal authorities ask you to provide the identity of the user who issued a specific request to your service, and you are legally obliged to keep such logs.
• Some local event (flood, fire,...) takes your service down and you need to activate a secondary site to maintain availability.
• Users sue you for some alleged framing and you must have a proof, convincing for judge, that the user really sent you a specific request that you could not have fabricated (a typical banking context).
• An attacker succeeded in stealing a part of your server's database, and uses it to impersonate users.

A variety of tools will be relevant, depending on the situation. In most cases, using SSL for your service will be a good idea (or, rather, not using SSL would be a spectacularly bad idea). In many cases, you will need some form of user authentication.