1

My question is about the difference between usual security expectations from a web application (intended to browser navigation) vs SOAP web service.

For a web application, an acceptable solution for secure communication is HTTPS (tranport level). However, in large companies, the web application is behind a reverse-proxy/load-balancer (and a web application firewall on top of it). The reverse-proxy is able to decrypt the communication, and we expect it to decrypt the communication so as to analyse the traffic. Then it sends it to the web application in the private lan (sometimes in plain HTTP).

For secure SOAP web service, HTTPS can be used, but as explained in http://msdn.microsoft.com/en-us/library/ms977358.aspx, XML encryption (message level) is promoted so as to prevent intermediary points, such as the SOAP message router, to have access to the message. Then the SOAP message is sent (still encrypted) to the right service provider in the private lan (only then the message can be decrypted).

In my eyes, the reverse proxy has the same position as the SOAP message router.

In this case, why would there be stronger security expectations to SOAP web services ? Or am I wrong and has my vision of web application architecture a weak security?

Improve this question

2 Answers 2

Reset to default
1

For a web application, an acceptable solution for secure communication is HTTPS (tranport level).

It is only acceptable if it provides adequate security for the application. It might be the case if you're talking about a control channel but it might be insufficient if you're exchanging messages (these are just examples, there are many other possible cases).

In my eyes, the reverse proxy has the same position as the SOAP message router.

That is incorrect: a reverse proxy will see the raw, unencrypted traffic between the endpoints and everything that happens "behind" it will also have access to the messages cleartext. Using SOAP encryption you can preserve all the benefits of using a reverse proxy while maintaining end-to-end message security.

In this case, why would there be stronger security expectations to SOAP web services ? Or am I wrong and has my vision of web application architecture a weak security?

It's not a question that can be answer in general: the type (and level) of security that is required will depends on what the application is doing.

One important different between using HTTPS security only or SOAP security is that you can maintain the security of the SOAP message much monger and further away than simply the TCP connection. You can save the SOAP message to a database directly and it will still retain all its security properties.

Improve this answer
4
  • could you please provide an example for securing web application communication where HTTPS is not sufficient and another security feature is in place ?
    – someone
    Commented Jul 4, 2013 at 13:52
  • The reverse proxy and the SOAP message router are both in a "gateway position". Why would we require the latter not to be able to see the communication if the former is? Besides, is there an equivalent of XML encryption for usual HTTP web application to achieve the same security level or is it useless?
    – someone
    Commented Jul 4, 2013 at 13:59
  • Sure: if you upload a payment order to a processing bureau, using HTTPS will not protect your order once the connection has not been established and proving that you where really the originator of that payment order will be difficult at best for the service bureau. Adding encryption and digital signature to the mix will make sure that your order stay confidential and allow the recipient to prove he acted upon your instructions.
    – Stephane
    Commented Jul 4, 2013 at 14:03
  • How would you implement encryption and digital signature using only web technologies for a web application (intended to browser navigation)? I don't notice any of this when accessing banking websites for example. Put in other words, how is it possible to implement the same security features available (and promoted as security standards) in web services (such as XML encryption, signatures, etc.) in a web application (intended to browser navigation)?
    – someone
    Commented Jul 5, 2013 at 6:56
0

For a web application, an acceptable solution for secure communication is HTTPS (tranport level). However, in large companies, the web application is behind a reverse-proxy/load-balancer (and a web application firewall on top of it). The reverse-proxy is able to decrypt the communication, and we expect it to decrypt the communication so as to analyse the traffic. Then it sends it to the web application in the private lan (sometimes in plain HTTP).

Although sometimes it is necessary to decrypt the traffic on the reverse proxy to perform deep packet inspection (e.g., with WAF), it is a good practice to encrypt it again before forwarding the request to the destination server (even within LAN) – so that no one can see or modify it in the process. Ideally, packets should never be sent in clear text, even within LAN. (see https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)

For secure SOAP web service, HTTPS can be used, but as explained in http://msdn.microsoft.com/en-us/library/ms977358.aspx, XML encryption (message level) is promoted so as to prevent intermediary points, such as the SOAP message router, to have access to the message. Then the SOAP message is sent (still encrypted) to the right service provider in the private lan (only then the message can be decrypted).

These days, it is very rare for applications to encrypt the XML message itself. Instead, they are occasionally signed to prove their integrity (see: https://www.w3.org/TR/xmldsig-core2/) and are transmitted over SSL/TLS connection for confidentiality. In case of apps and services handling very sensitive data, you might also want the communication to be performed in a way that both parties authenticate themselves to each other (mTLS) for additional security.

As a general rule, it is critical to avoid creating any cryptographic algorithms yourself but instead rely on the ones defined in the RFCs and considered secure as of writing the application or service. Luckily, most modern frameworks make use of those safe algorithms within built-in functions, so it's usually more secure to use them instead of coding anything from scratch. Also, regardless of the exact technology we are using for services, it is very important to remember about security of the API itself (see: https://owasp.org/www-project-api-security/)

So to answer the question – there is usually not a big difference between an application and service in terms of security except when we are dealing with very sensitive data. In such cases, some additional measures, i.e., mTLS or message signing, can be employed.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .