What's the best way to secure the responses in a single page web app after logout?

Question

I've read some of the great responses to storing and passing session keys in a single page web application (i.e., a web "site" that runs mostly on the client-side, getting data from the server by using an API). But my question is about securing (after logout) the data which comes back in the response, of which I've seen no mention.

This data is directly accessible by just about any modern browser by clicking on the developer tools view (even when using HTTPS). Thus, the following can happen:

1. Authenticated User (AU) uses the application and downloads secured information.
2. AU logs out or is logged out automatically.
3. Application returns to "Login" page. It looks secured, so AU does not close the tab/page.
4. However, Unauthenticated (malicious) User (UU) sits at desk and opens up Developer tools. In the Network section, UU can see structured JSON objects with lots of juicy information.

This does not happen in a more traditional web application, because the data is embedded in the HTML page, which is gone when the browser redirects to the login page.

We are using AngularJS for our single page web app, which recommends using a location change feature for logout, which I have confirmed does not do an actual redirect (by design); therefore the page is not refreshed; therefore the network requests can be found in the developer section.

It seems that the way to go is to NOT use the AngularJS method, and instead to break the model and to use the pure javascript redirect to refresh the site onto the Login page. This does seem to clear the network requests. Is this the recommended method?

I realize that having access to the browser means that the UU can install keylogging, screen grabbing and all sorts of things that are even worse than this scenario, and there's nothing we can do about that, but the scenario I am describing here is a very common office scenario where casual users can sit down at a browser quickly and spy some info without really doing much work. Given that we're dealing with protected health information, it remains a concern.

Answer 1

Encrypt the content using a session key while in transit. Decrypt the content in-memory using a variable. At logout, explicity clear the variables containing keys and decrypted information. Also explicity clear any variables containing authentication information and any information that was used to generate the session key. The session key can be generated out of authentication information like hash of username/password and other information accessible to both client and server, but NOT someone watching the decrypted network traffic inside a SSL session (which the developer Tools do). Also beware of "pass-the-hash" attacks on the authentication scheme - eg if you hash username/password on client side, beware that someone might find the password hash inside developer Tools and then send the hash itself to login - without knowing the password.

A suggestion is following:

---

1: User logs in with username and password.

2: Application sends Username, H(Username, H(Password, T), T) where H() is a hash function and T is a timestamp. Read more in 3 how the timestamp is constructed.

3: Server checks that the record is valid. This is accomplished by having T to be a timestamp that has a granularity of 1/2 of the expected validity time. This is generated by cutting off bits from a standard unix epoch timestamp. Eg, if you want validity of 5-10 minutes, remove the last 8 bits from the timestamp. At validation, check if the hash match with T=current_timestamp, T=current_timestamp-1 or T=current_timestamp+1 to compensate for a client Clock that is slightly off. This gives a validity of 256-768 seconds, which is roughtly 4-12 minutes.

4: Application now generates a session key, using H(Username,Password,T,Static salt). Save session key in variable. (this ensures session can be used for longer than 4-12 minutes). NOTE: You CANNOT use a timestamp to expire a session, you HAVE to clear the variables if you want to expire the session due to inactivity. Remember that variables are accessible to a malicious indivual if not cleared - timestamp is only used to expire a used password hash so it cannot be reused.

5: The server script generates a session key in the same way, ensuring to use only the T that was found out to be correct during validation at 3.

6: Use the session key to encrypt information in the JSON structures.

7: at logout, delete session key, username, password, H(Password, T), and H(Username, H(Password, T), T) and also any information that was transferred during session. This is accomplished by simply setting the variable to nothing, eg key = "";

---

The above login scheme makes Everything secure both against pass-the-hash attacks and also secures information in-transit using a unique session key. Also session keys from a Another session cannot be used to decrypt previous sessions.

This ensures information is encrypted when its visible in developer Tools. Its not possible to gain the values of variables in developer Tools after they have been cleared, ensuring no access to data.

If the computers are in a controlled segment, which they should be if you developing a Health record application that is accessed by doctors, you SHOULD disable all debug/developer functions via a Group policy. But that is hard to do if the application is accessed by patients.

Answer 2

I firmly believe in a completely separate login/logout page. It's better for conveying to the user they have been logged out. If only one part of the page changes, then it would be easy to overlook if a user didn't successfully log out.

Answer 3

You've nailed it.

It seems that the way to go is to NOT use the AngularJS method, and instead to break the model and to use the pure javascript redirect to refresh the site onto the Login page. This does seem to clear the network requests. Is this the recommended method?

You're best assurance is to leave the page. After you've deleted the login cookie, You can send the user anywhere. Redirect them to your home page, stack overflow, this question even, or to google. You could create a login-only page that you use simply to redirect the user somewhere useful after they log out.