Reta is dismayed to learn that a malicious hacker managed to download a chunk of the company's database, containing personal details of all the customers in her store. Fortunately, she also learns that the pass-phrase she always entered was actually used to encrypt the all that data, so the hacker won't be able to make sense of any of the contents.

How can you mitigate the effects of unauthorised access to your application data?

Host sensitive data in encrypted form, so that clients can only access and manipulate it by providing a pass-phrase which is never transmitted to the server. The server is limited to persisting and retrieving whatever encrypted data the browser sends it, and never actually sees the sensitive data in its plain form. All encryption and decryption takes place inside the browser itself.

Just what does secure hosting have do with Ajax? The Ajaxian twist comes in the maintenance of the pass-phrase. You could use the browser-side encryption with a conventional application, but the pass-phrase would have to be entered upon each page refresh, since no Javascript state survives a reload. With page refreshes occurring every few seconds, it's completely unusable. However, using Ajax to avoid page refresh means you can retain all session state in the browser, so the pass-phrase need only be entered at the start. After being entered, it can be retained as a standard Javascript string and will disappear from the browser when the user quits the browser or visits another site. Suddenly, Host-Proof Hosting becomes usable.

Incidentally, don't take this pattern to be a new "Ajax-HTTPS" protocol - the idea here is about how the data's actually stored, not how it's transmitted. In theory, the data itself need not travel over a secure connection, because it's already encrypted. In practice, a secure connection might be worthwhile in order to reduce some of the vulnerabilities described below.

Before you rush off to upload all your trade secrets to Shonky Hosting Inc., you should be aware this idea isn't foolproof. On the one hand, the host is assumed inherently untrustworthy. But on the other hand, the script for the browser application is held right there on the server, and the browser runs whatever scripts come down from that URL. This leaves open the possibility of the host tampering with either the code itself, or the outgoing HTML and Javascript, to evil ends.

What if a rogue administrator from the hosting company decided to quietly add a little monitoring function to a Javascript file, and append its execution to a window.onload function. Then, the evil monitoring function could be made to run once a minute within the browser. It might for instance, serialise the entire DOM, and upload a summary back to the server with ???, where more malicious code will log it somewhere convenient. A third-party hacker sitting between the browser and the server could also inject a script, and could upload data to a remote site with one of several established techniques. For instance, exporting browser data as CGI variables on the source URL of an external image under the hacker's control. In both scenarios, the application can continue as normal, the poor user none the wiser.

The threat of script injection certainly weakens the claim for this pattern, but doesn't invalidate it altogether. While script injection is theoretically possible, it does require some skill on the host's part and is also detectable if you know what the code should and should not be doing. If you happened to discover your application uploading DOM details every sixty seconds (using a tool like those described in “Traffic Sniffing”), there's a good chance that something's blatantly wrong.

As a further practical consideration, consider what happens if a hacker gains unauthorised access for a short time. They might well grab as much data as possible, but the data will be safely encrypted. In the unlikely event they were sophisticated enough to use script injection, they would only be able to gain pass-phrases of users who happen to be logged in during the time the hacker controls the server.

So pragmatic considerations suggest that the technique is safer than hosting the data in plain form, though by no means perfect. Is it so much safer to warrant the extra performance overhead, coding effort, and the constraint of zero page refreshes? That's a decision you'll need to make on a case-by-case basis, bearing in mind the criticality of the data, the likelihood of the various types of attack.

In theory, there's an even stronger claim in favour of this approach. It might be possible to develop a general-purpose plugin precisely for detection of script injection. For a given application, such a plugin would have access to a certified copy of the source code. Then, it could monitor traffic and caution about any unexpected activity. If such a plugin could be developed, the only way for script injection to succeed would be a conspiracy between the host, the code certifier, and the plugin manufacturer.

There are no public real-world examples to my knowledge. One precedent is Hushmail, which uses a Java applet to allow access to email encrypted on the server.

Richard Schwartz provides a proof-of-concept demo (Figure 1.92, “Host-Proof Hosting”). For encryption, it delegates to a Javascript Blowfish library. The application accepts a pass-phrase, a message key, and some message content. It then encrypts the message and uploads it. It also uploads the key along with an encrypted version of the key, which can be used later on to check that the user has the correct pass-phrase. The application then shows how the server is holding only the encrypted content and the key. You can then pull the encrypted content back down and decrypt it with the original pass-phrase.

Figure 1.92. Host-Proof Hosting

The application itself is quite simple: it presents a series of forms by manipulating their "display" style settings, to show and hide them. Thus, the user's pass-phrase remains in the pass-phrase input field at all times. This is the important thing about the demo: there's no form submission, so the pass-phrase only needs to be entered once.

When the application's ready to upload the encrypted data, it sets up the global variables required by the Blowfish library (ideally, the library would accept these as parameters). encodetext() is called (with "2" to specify the Blowfish algorithm) and it outputs the encrypted version in the form of a global variable:

    saveCryptoText() {
      ...
      inpdata=window.document.inputForm.plaintextInput.value;
      passwd=window.document.inputForm.password.value;
      // invoke blowfish
      encodetext(2);
      data = data + "&check=" + outdata ;
      ...
    }

The encrypted key is also attached:

    inpdata=window.document.inputForm.check.value;
    encodetext(2);
    data = data + "&check=" + outdata ;

The data can now be sent over to the server ^[19]:

    url = "http://smokey.rhs.com/web/test/AjaxCryptoConceptProof.nsf/SaveBlowfishDoc?OpenAgent" + data

    httpPost(url)	

Later on, the application provides a list of message keys that have been sent to the server. When the user chooses one, the application requests an XML document from the server, containing the message and key details (in practice, the message key could be verified first, before the body is downloaded). It first performs a check that the key is valid for this pass-phrase, then decrypts the message itself. Finally, a DOM object is morphed to display the decrypted text:

    inpdata = "";
    inpdata = getElementText(valuenode);
    outdata = ""
    decodetext(2);
    ...
    window.document.all.decryptedText.innerHTML = stripNulls(outdata);	

Ceasar wonders whether he can entrust his aide to retain the top-secret recipe for victory wine. Fortunately, he's a pioneer of cryptography, so he just hands over the recipe in encrypted form.

Richard Schwartz's blog entries provided the idea for this pattern and the name is attributed to Richard, Michael Griffes, and their colleagues at eVelocity. I am also grateful to others who have commented on the approach, notably Alex Russell who has cautioned on the vulnerabilities of this approach, such as script injection.