Usage of ng-idle leaves traces of app us in the browser localStorage

[evilaliv3]

In relation to the topic of minimizing the forensic traces (#2668) left by the application on the browser of the user, i've analyzed the implementation of the ng-idle module used for detecting user idling and found out that it uses of a persistent localStorage variable to track the time of the last user action.

This causes to leave in the browser a trace that the app was used. The trace is anyhow anonymous and do not contain any information about the activities performed on the site.

This ticket is to track the activities of patching the library use in order to use a temporary variable reducing the traces left in the browser of the user.

[evilaliv3]

After looking at the implementation of the ng-idle variable i've identified that we could just drop the javascript reference to window.localStorage forcing the app to use an already existing polylfill based on a temporary implementation.

This can be achieved with the following code:
delete window.localStorage;

I've reported this to the develper of the library (@moribvndvs) asking for the possibility to patch ng-idle and ng-idle2 to offer a privacy preserving mode using this temporary polyfill implementation by default:

• Implement a privacy preserving mode functionality avoiding usage of the persistent browser localStorage moribvndvs/ng2-idle#173
• Implement a privacy preserving mode functionality avoiding usage of the persistent browser localStorage moribvndvs/ng-idle#232

[evilaliv3]

@gronke @hackademix: what do you think of such a simple fix?

1. Deleting the reference to window.localStorage will cause the library to use an internal polyfill based on a temporary javascript object; Are the guarantees that the brouwser will not restore the window.localStorage reference at runtime?
2. Deleting references to object like this seems to me really interesting as one could possibly implement a library, that launched before the application could restrict the javascript environment creating a sandbox for possible xss; in your experience is there any project doing so?

[hackademix]

1. Deleting the reference to window.localStorage will cause the library to use an internal polyfill  based on a temporary javascript object; Are the guarantees that the brouwser will not restore the window.localStorage reference at runtime?

The browser won't restore the reference at runtime, so this approach can work in this specific case of non-hostile environment (yet, I'd double check that the polyfill doesn't use cookies as a fallback persistence mechanism).
In other situations involving an adversary running scripts in your environment, you should be much more careful, e.g. to ensure that non reference to localStorage have been stored before deletion and could be restored, or retrieved from other browser contexts such as iframes or spawned windows and many other subtleties (see my answer to 2 below).

2. Deleting references to object like this seems to me really interesting as one could possibly implement a library, that launched before the application could restrict the javascript environment creating a sandbox for possible xss; in your experience is there any project doing so?

This is a case where you're assuming malicious code which you'll try to contain, and it's a much bigger fish to fry.
For an example of the challenges posed by trying to expose a controlled/sanitized environment to arbitrary JavaScript code, you may look at the source code of a project which I contribute to, JShelter, doing that for anti-fingerprinting purposes.

[evilaliv3]

Thank you for your feedback @hackademix !

Yes, considering the non-hostile environment we will proceed with this quirk.

Very interesting project JShelter. Have you evaluated to implement it as a javascript library that a project could include as first script to sandbox the entire application?