Web Service Security

Question

We are currently designing a Web Service that returns a JSON formatted messages. The following are the planned implementation for the service's security:

• An SSL Certification to the service for the communication security over the internet.

  Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. - wikipedia.org

• Encryption of sensitive data using hashes and salt.

  Encryption is in Symmetric (Rijndael) Key - Rijndael can be specified with block and key sizes in any multiple of 32 bits, with a minimum of 128 bits. The blocksize has a maximum of 256 bits, but the keysize has no theoretical maximum. - wikipedia.org

• Client Authentication using custom username and password validator

  WCF allows for custom user name and password authentication schemes, also known as validators. - msdn.microsoft.com

The service will be consumed by different clients and the data should be secured. The following are the possible risks^[1]:

• Broken Authentication and Session Management - Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
• Insecure Direct Object References - A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
• Security Misconfiguration - Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.
• Insecure Cryptographic Storage - Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.
• Insufficient Transport Layer Protection - Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

If an attack had succeeded in penetrating in our service, a great loss will fall in our company. The following are the possible result of a successful attack:

• Any data manipulated in any malicious way might cause a great loss into our company's profits.
• Accessing of unauthenticated clients allows them to change and add malicious data and/or slow down or break the service causing the service to be inaccessible.

Is our planned implementation for the service's security sufficient enough to prevent these risks? What other security issues we need to consider?

---

^{[1] Risk name and definition are based on OWASP Application Security Risks.}

Answer 1

I suggest that you elaborate more on what is the threat model that could cause a great loss. In general, I would question whether the web is the right technology to deploy this: failures of web security are commonplace, so if any security failure could truly cause a great loss of profits, maybe you should rethink the entire initiative. But perhaps you can explain more about the highest-priority risks in your setting. I imagine there is a server, and there is a client. There are multiple threats. We could worry about a malicious client that manages to change the authoritative copy of the data on the server. Or we could worry about an attacker (perhaps a malicious client) that is able to tamper with the data that other clients see. Or we could worry about a malicious client who is able to access confidential data, without authorization. Or we could worry about break-ins to the server. What are the highest-severity risks in your setting?

I'd also say that I'm having a hard time telling what your precise plan is. I'm not familiar with what a "SSL certification" is. Do you mean that you use SSL for all connections to the JSON data? You also don't say how the encryption is done (details matter), or why you need encryption in the first place. You also don't say if there is any access control, and if so, how that is done (how is authorization and authentication done?). So there is not enough to review your system as the question currently stands.

Let me start with some general advice: given the potential for great loss to profits if there is a security failure, you need to hire an experienced security professional (perhaps as a consultant). Give them full access to your system, and ask them to review the security of your system. Ask for architectural risk analysis (threat modelling), source code analysis (e.g., for security vulnerabilities), and advice about how best to protect yourself. If great profits are at stake, you shouldn't rely upon this web site.

Without any details, it is hard to provide specific advice. But I'll make some suggestions:

• Deploy a dedicated server to provide access to this data, and use it only for that purpose. Lock it down tightly (there are many guides on this site on how to harden a server).

• Use SSL sitewide: i.e., use only HTTPS, not HTTP. Don't use HTTP for anything; use only HTTPS. Enable HSTS. Set the secure flag on all cookies.

• Think carefully about how you will authenticate users.

• Adopt good security practices, such as integrating security into the software development lifecycle. Microsoft has some excellent resources. Search on this site and you'll find more (Microsoft SDL, BSIMM, etc.).

Note that these will likely not be sufficient: it would be necessary to understand in more detail the goals and requirements for your web service to provide a more complete list. This is just a starting point.