There are two worlds, the web and the disk. The assumption is that the web is "untrusted" and the disk is "trusted" **.
Rather, there are two security models with different goals. Each model provides trust of the kind its users need.
I said neither is necessarily less trusted than the other, just that it's easier to go browser->disk than vice versa.
In such a circumstance, I can't see that "credentials" do anything for us. It isn't the source of the file that is the danger, it's the fact that it crossed the border without notice.
I'm using "credentials" in its general meaning. As you point out, crossing a border without notice is the problem. The way that's handled in the real world(tm) is to scrutinize the party doing the crossing, or rely on a handshake such as "diplomatic immunity".
So the essence of the security problem remains at the border. It seems that the analogy best suited is one of viruses.
Virus border checks are an example of a credential driven best-effort system; that's how pattern matching virus checkers work - they check the credentials of the suspect document using content tests. But such checkers aren't as robust as my proposal, because they're statistical/probabilistic in nature: "this might be a virus". I'm proposing a rule-driven solution that's 100% reliable in the 95% of cases where the rules can be applied. The other 5% falls back to a robust warning.
So maybe the answer is that if the user chooses to save the file, the save process checks to see if any javascript is in there, and then warns the user.
That's certainly an improvement for the browser->disk case. "defense in depth". That could be added for the benefit of users. Doesn't affect developers.
After saving it, any viewing of the saved page will cause it to run with full privileges!
You've gone wrong here. I think. The browser can't make assumptions about an asset once its passed to another security model, unless trusted information from the browser's own security model is exported with it. Refer back the options I outlined.
Or. possibly one could strip the code out of it.
A bad user experience would result, when the page reloaded, I imagine. I suppose the user could be given a generic "Safe Save" option. But the natural question then is: why isn't my Firefox browser safe in the first place? Better to guarantee that much rather than force the user to make spot decisions each time they save.
In summary, I think you've identified some possible enhancements to the browser->disk case. For the disk-> browser case, I'm not so sure what you've added.
- N. _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
