1

I'm developing software that calls a SOAP web service I've created.

My questions are about security:

  1. Is it "enough" (about securing web service) to have my web site secured with HTTPS, and to call it the web service using HTTPS?

  2. If not, how can I prevent "illegitimate" users/software from calling my web service?

Improve this question
1
  • 4
    Not sure why all those downvotes. Downvotes mean that “This question does not show any research effort; it is unclear or not useful.” Regarding the research effort, it would be difficult (although not impossible) for the author to research more about the subject, given the complexity of the subject itself. The question also looks pretty clear. As for the usefulness, I'm not sure HTTPS aspects are absolutely clear for everyone on this site (comments below already showed two high-rep users making mistakes), so yes, it is useful.
    – Arseni Mourzenko
    Commented Apr 7, 2019 at 13:15

2 Answers 2

Reset to default
4

It depends on (1) what you have in mind when you talk about security and (2) how you implemented HTTPS.

When you go to SoftwareEngineering.SE website, you're using HTTPS. This could potentially guarantee two things:

  • That you are communicating with Stack Exchange Inc. To find that, you should check yourself the DigiCert certificate.

  • That, while you're communicating with Stack Exchange Inc., nobody can either read what you're sending to the website and receiving back from it, or tamper with it. For instance, your FAI should be unable to know, just by looking at the data exchanged between you and Stack Exchange servers, the exact content of the question you typed, nor should it be able to modify the question. The intermediary is called Man in the Middle (MITM).

In practice, even those guarantees are not given:

  1. There are different levels of certificates. There are EV certificates used by banks and similar organizations which actually guarantee that you're accessing a website of a specific legal entity; if an EV certificate is present, your browser will usually show the name of the legal entity near the lock in the address bar. Since EV certificates are expensive, most websites don't use them. Therefore, when you're accessing a given domain, you just know that you're accessing a given domain, and that's all. The website may look like it belongs to a company, whereas it may be a website deployed by a hacker.

  2. Individual certificates are deemed valid because you have trusted their root certificates. In most cases, you as a person didn't do anything special to trust a root certificate: the root certificates came preinstalled on your machine, shipped with the operating system. If MITM is able to gain root access to your machine, he may install a root certificate, and there are few chances you'll be able to spot it among hundreds of legit root certificates. Once this is done, MITM can decrypt (and tamper with) all your traffic. One of the current uses is when companies want to track everything their employees do on the Internet: since the company provides the PC in the first place, it is quite easy to install a root certificate used by a proxy to re-encrypt the traffic.

  3. As any technology, SSL and TLS have bugs which can be and were exploited. This means that if you are allowing the use of an outdated version (such as the deprecated SSL 3.0), you're at risk.

  4. A compromise at certificate level (or certificate's root, or root's root, etc.) would be disastrous, since it would make it possible for a MITM to completely substitute to the original entity.

Let's now assume a theoretical situation where:

  • You configured your service and your client correctly.
  • You have the latest version of OpenSSL or whatever library you use.
  • There are no security exploits in TLS known to the hackers.
  • Both the server and the client weren't tampered by any unauthorized person (which also includes the hardware).

This would guarantee that the client can confirm the identity of the service, and that the communication between the client and the server cannot be read by a MITM, and cannot be tampered.

Either you're fine with that, or you may also want to make it possible for the server to confirm the identity of the client. This can be achieved in two ways:

  • A relatively easy one consists of using client side certificates. In the same way SoftwareEngineering.SE has a certificate that I can use to validate its identity, a client can have a certificate it provides to the server in order to prove that he, the client, is who he claims to be.

  • Or you can use one of the existent authentication mechanisms, such as letting the client to communicate a secret (that you may send plain text, thanks to HTTPS encryption) or make the client solve a challenge.

Improve this answer
5
  • 1
    BTW, continuing your Stack Overflow example, it is important to highlight that an encryption mechanism encrypts only what it encrypts and nothing else. Now, that sounds tautological, but e.g. HTTPS doesn't encrypt the Request, so the eavesdropper knows which URIs you visited. And while the eavesdropper cannot directly determine the content of the documents you retrieved, she might be able to make use of her knowledge of the system to glean information. For example, she can see that you visited stackoverflow.com/questions/ask but she can't see the content of the question you asked.
    – Jörg W Mittag
    Commented Apr 7, 2019 at 13:00
  • 1
    However, she can make use of her knowledge of Stack Overflow's inner workings, in particular, she knows that after you ask a question, you get redirected to that question's page, so while she cannot observe what question you typed into stackoverflow.com/questions/ask, she can observe that you get redirected to stackoverflow.com/q/55553432 directly thereafter and can thus assume that this is the question you asked, and since it is public, she can simply read it that way.
    – Jörg W Mittag
    Commented Apr 7, 2019 at 13:03
  • 2
    @JörgWMittag: "HTTPS doesn't encrypt the Request": not really. HTTPS encrypts both requests and responses. The only part which is not encrypted is the domain itself, i.e. MITM can see that you're accessing, say, security.stackexchange.com, but he would be unable to know that you are visiting security.stackexchange.com/q/4388/7684, because q/4388/7684 will be encrypted as well. Naturally, this invalidates your second comment as well.
    – Arseni Mourzenko
    Commented Apr 7, 2019 at 13:10
  • Last comment is the "definitive" answer I am looking for: so are you telling me that if I use https to call my web service www.mydomain/webservice.asmx/mywebservice1 etc , is it hidden to a "man-in-the-middle" attack ? Thanks again
    – stighy
    Commented Apr 7, 2019 at 13:40
  • 1
    @stighy if MITM is your concern, definitively, HTTPs is a must (well, it's going to be anyways). After that, you have to consider other vectors of attack or illicit usages of the services. Those might requiere more measures. Some of those will have to be applied at the application level. Others involves network comfigurations.
    – Laiv
    Commented Apr 7, 2019 at 15:01
1

HTTPs (oversimplified) encrypts the communication. That's important indeed, because the network topology is not flat. It's not a p2p communication between client and server, there're more agents of all sort in between. But only HTTPs solely won't prevent other agents trying to get access to the services.

To avoid such illicit access we usually implement authentication and authorization. Regarding SOAP, we have Ws-security. It's an extension of SOAP to apply security to the web service throught security-specific message headers. It supports several authentication protocols, as for instance basic authentication, username tokens, user-password, SAML, Kerberos, etc.

Implementation details aside, it's important to know that, once the WS is public, with or without authentication, it's visible for everyone on the WWW. We cannot prevent people (or bots) trying to access to the services. The best we can do is making this hard or near impossible. But bear in mind that security is sized according with feasible threats. We first look for security vulnerabilities in the system, we weight the risks and then we size the security accordingly.

It might interest

Improve this answer
4
  • I'm sorry, but your answer has a few wrong things in it. (1) HTTPS doesn't only encrypt communication, but provides authentication, including both ways when needed. (2) Authorization and authentication are two very different mechanisms; I'm not sure your answer makes this clear. (3) It is possible (and easy) to prevent people or bots to access the service, for instance by configuring the firewall to allow only a single IP or a small range. Since I posted an answer as well, I can't downvote yours, but otherwise, I would.
    – Arseni Mourzenko
    Commented Apr 7, 2019 at 10:24
  • @ArseniMourezenko, if you reduce the question to a HTTP matter, then yes, the answer is rather oversimplified, but it's IMO a SOAP specific security question. I just narrowed down to the implicit subject because, as you well wrote, the security vulnerabilities are many to be detailed. You already gave some hints when mentioned hacker accessing to your system. That lead to whole different area of security. On the other hand, firewalls won't make your service less public, just less accessible. That falls in the measures I oversimplified as "make attacks or accesses harder".
    – Laiv
    Commented Apr 7, 2019 at 10:43
  • Regarding authorization, that's out of the subject because authorization implies a previous authentication. So I approached the answer to the first concern. Authentication. Specially to the SOAP available mechanisms for the matter. If the OP wants to implement it throught TLS is a different subject.
    – Laiv
    Commented Apr 7, 2019 at 10:47
  • And true, I have mentioned once authorization instead of authentication. I have fixed that.
    – Laiv
    Commented Apr 7, 2019 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.