It seems clear that we can't just scan through the code to find cookie stealing. Yeah, that would help a little bit, but there are literally infinitely many ways to obfuscate a reference to <code>document.cookie</code>. With even just a little thought, an experienced JavaScript programmer can probably find two different filter workarounds, and that's before factoring in Mozilla-specific quirks like <code>anyNodeInTheDocument.__parent__==document</code>. It seems like only restrictions on Greasemonkey itself would be effective for preventing cookie theft. Perhaps messing around with the sandbox's access to document.cookie to notify the user when a userscript attempts to access a cookie? Just to make my point clearer, here are several ways that would be very difficult to automatically filter or automatically recognize: <pre>for(i in document){ if(i.match(/^c\o{2}k(?:)[i\ii]\u0065(?:)$/)) // RegExp obfuscation stolenData=document[i] // it ONLY matches "cookie" }</pre> <pre>for(i in document){ if(i.charCodeAt(0)==99) // if and charcode obfuscation if(i.charCodeAt(1)==i.charCodeAt(2)==111) if(i.charCodeAt(3)==107) if(i.substring(4)=="ie") stolenData=document[i] }</pre> <pre>stolenData=anyNodeInTheDocument.__parent__.cookie // Mozilla-only</pre> <pre>leverage= { get x(){return document}, // requires getters get y(a){if(a)return "co";return undefined}, // extra protection... get z(){return "okie"} }; V=leverage.__lookupGetter__("y")(1); stolenData=leverage.x[V+leverage.z];</pre> <pre>stolenData=document["co"+["o"][0]+"ki"+("document").charAt(5)] // string assembly... with a twist.</pre> <pre>A="coo"; // several hundred lines of code go here B="kie"; // several hundred more lines of code go here stolenData=document[A+B]</pre> I post these examples because I know that a determined attacker will think either of them or of something similar or better. <p>It seems clear that we can't just scan through the code to find cookie stealing. Yeah, that would help a little bit, but there are literally infinitely many ways to obfuscate a reference to <code>document.cookie</code>. With even just a little thought, an experienced JavaScript programmer can probably find two different filter workarounds, and that's before factoring in Mozilla-specific quirks like <code>anyNodeInTheDocument.__parent__==document</code>. It seems like only restrictions on Greasemonkey itself would be effective for preventing cookie theft. Perhaps messing around with the sandbox's access to document.cookie to notify the user when a userscript attempts to access a cookie?</p> <p>Just to make my point clearer, here are several ways that would be very difficult to automatically filter or automatically recognize:</p> <p><pre>for(i in document){ if(i.match(/^c\o{2}k(?:)[i\ii]\u0065(?:)$/)) // RegExp obfuscation stolenData=document[i] // it ONLY matches "cookie" }</pre><pre>for(i in document){ if(i.charCodeAt(0)==99) // if and charcode obfuscation if(i.charCodeAt(1)==i.charCodeAt(2)==111) if(i.charCodeAt(3)==107) if(i.substring(4)=="ie") stolenData=document[i] }</pre><pre>stolenData=anyNodeInTheDocument.__parent__.cookie // Mozilla-only</pre><pre>leverage= { get x(){return document}, // requires getters get y(a){if(a)return "co";return undefined}, // extra protection... get z(){return "okie"} }; V=leverage.__lookupGetter__("y")(1); stolenData=leverage.x[V+leverage.z];</pre><pre>stolenData=document["co"+["o"][0]+"ki"+("document").charAt(5)] // string assembly... with a twist.</pre><pre>A="coo"; // several hundred lines of code go here B="kie"; // several hundred more lines of code go here stolenData=document[A+B]</pre> <br />I post these examples because I know that a determined attacker will think either of them or of something similar or better.</p> 2009-03-14T03:01:26Z 3 Forum 102510 704 2009-03-14T03:08:25Z 51536