On Sat, 2012-02-25 at 16:21 +1100, Tankred Hase wrote:
> > XSS Problem: Any XSS flaw can poison the runtime
>
> That's definitely a possible risk. I am not an expert in that field.
> So a code review might make sense here. If anyone can point me in the
> direction of some good literature which explains what to look for, I
> would be very grateful.
In these days I'm reading "JavaScript: the Good Parts", and I'm learning
a lot of peculiar JS features, among those there are private variables.
With private variables we could keep keys protected from XSS attacks,
given a not compromised startup.
For instance:
var myPgpObject = (function (key) {
var _key = key;
// We return the public API
return {
encrypt: function (input) {
// work with _key
return encryptedText;
},
decrypt: function (input) {
// ...
}
}
})("supersecretkey");
// ...
myPgpObject.encrypt("test");
// From myPgpObject you can't access _key
Still with an XSS you could use the public API, but the private key
wouldn't be compromised. AFAIK from outside the object there's no way to
get the value of _key.
About the fact that one could alter some basic objects like Math.random,
or similar, we could take a reference to the functions/objects we need
in this startup (non-compromised) phase and then reuse them. For
instance:
var myPgpObject = (function (...) {
var myRandom = Math.random;
})(...);
Now, even if with an XSS an attacker si able to change
windows.Math.random, inside our object we still have the reference to
the correct native function.
I'm making it simple, and the matter should be better investigated.
Maybe you can think a situation where this doesn't work.
venom00
_______________________________________________
http://openpgpjs.org
