Reputation: 61473
It's pretty well known that overridden objects in Javascript can cause security issues, or just development bugs. I'm concerned about the security here.
Suppose I have a sensitive JSON result that will be saved in a variable... and that variable has either been previously defined with a _prototypes, getter/setter. Further assume that instead of just being a memory allocation, the result was sent to a function that sent it to a "bad guy". Now my sensitive data is outside my application.
My intent is to find a way to "clean" Javascript, cookies, SOP, and memory back to it's original state prior to be starting a session within a given browser.
I know I mentioned a few tricky components here, but is any cleaning or validation possible?
Is it possible to reset the in-memory status to a known good state?
Upvotes: 1
Views: 737
Reputation: 4074
You can detect if the variable has a getter/setter
and assume that it's dirty if true:
var data = {hacked:1};
if(Object.getOwnPropertyDescriptor(data, "hacked").value === data.hacked) {
//clean
}
Upvotes: -3
Reputation: 3604
The First Question in security is: What is your threat model? When someone asks you that question, it is a hint that you haven't thought through what threats you are trying to defend against. If you haven't thought that through, you're not in a good position to construct effective defenses.
Your question doesn't explain the threat model. What are you trying to defend against? You're worried about malicious Javascript running on your page?
If that's the threat, the best answer is to un-ask the question. The best solution is to ensure you never end up in a situation where malicious Javascript is running on your page. Maybe you need XSS defense, to ensure no one can inject malicious Javascript into your page. Maybe you need a secure Javascript sandbox (like Caja, MS Web Sandbox, Caja, ADsafe, FBJS, ...), if you truly need to run Javascript from an untrusted source, to limit what that Javascript can do. I don't know how we can tell; you haven't provided us enough information to solve your problem.
As a general rule of thumb, you need to keep in mind that the client execution platform is controlled by the client, not you. Therefore, you must not trust the client. If you have confidential data that the client isn't supposed to know, don't send it to the client! Don't let client-side Javascript ever see it. There's no amount of resetting or rewiping or reloading that will save you if you violate this rule.
If a secure Javascript sandbox is what you need, make sure to read these questions on IT Security stack exchange:
You might get better answers over on IT Security.
Upvotes: 0
Reputation: 1862
In distributed computing, you must always assume that the client is in the hands of the enemy (in this case, that's the browser). And that they will do to it whatever they want. If your application's security depends on the correct execution of some code on the client's side, then it's not going to be secure.
tl;dr: No.
Upvotes: 4