How do I holistically protect a web service from network and MITM attacks?

Question

I have several financial web services that are accessed over HTTPS, however the client devices may be accessing the web services over untrusted WiFi, through questionable proxies, and possibly ToR exit nodes.

Question

How can I protect the Javascript API call, the response, and the user's identity?

Specifically I'm interested in ensuring holistic non-repudiation, confidentiality, integrity of the end to end connection.

My goal is to make a web service available that can be used from desktop-based websites, and also mobile apps.

Answer 1

TLS / SSL

The bare minimum of security a webservice should have is to be available over a HTTPS connections. The certificate should be valid (not expired, not self signed).

Ideally the HTTP service is disabled.

Use HTTPSTS headers

The HTTP Strict Transport Security header should be added to ensure that all future requests to that host occur over HTTPS. This technology helps prevent man in the middle attacks with attack tools such as SSLStrip.

Ensure TLS is correctly configured

Test the server's TLS configuration and resolve any critical warnings as appropriate.

Add cruft to JSON responses

Unparsable cruft is used by Google, Facebook and others to prevent certain javascript attacks.

Set the secure flag on all cookies

Setting the secure flag on all cookies prevents the inadvertent "leaking" of valuable data to would-be attackers.

Set HTTP Only for all authentication cookies

The HTTP Only flag is a misnomer and doesn't mean the cookie will be sent unsecurely, rather it means that the cookie is unavailable to Javascript and only available for consumption by the server.

Lock down usage by IP address

Depending on the target audience, restrict the usage of the service by source IP.

Monitor

Monitor the requests per second, per user, and failures per second, per user.

Answer 2

The following are less commonly used, but improve on my prior answer

Client certificates

A client certificate will encrypt the entire TLS session with "mutual authentication" and will protect the session from MITM attacks and can be used over untrusted networks.

Use DNSSec

Use DNSSec for all DNS domains used in the application, namely the location of the service, and all CRLs, AIAs, and OCSP paths in the chain

VPN

API calls over a VPN may improve security, and if the VPN requires locally deployed certificates the security benefit may be the same as client certificates.

A variation of this answer is to use ToR with the target server having a .onion address, but isn't recommended for the general public.

---

If the web service is using SOAP, or WS-Security consider using message security. Message security has been described as the WS-* interpretation of TLS but within an XML payload. That means that these SOAP calls can be used over plain HTTP and relayed over several untrusted intermediaries.

Warning for Javascript users

Don't attempt to use SOAP with message security with Javascript. There is no way to securely create and manage the key pair that is needed for SOAP messages. In addition there are several other concerns such as cross-domain usage, XML parsing, etc.