On Fri, Apr 13, 2012 at 12:42 AM, Tanvi Vyas <[email protected]> wrote: > Given recent social-engineering attacks, firefox no longer allows javascript > in the address bar (https://bugzilla.mozilla.org/show_bug.cgi?id=656433). > The same issue could exist with the Web Console. An attacker could ask a > user to use the keyboard shortcut to open the web console and copy and paste > javascript on a page that is vulnerable to DOM based or self XSS. > > To mitigate this potential attack, we are considering adding a new CSP > directive 'no-user-js' that can be set by websites being targeted by this > attack (http://incompleteness.me/mozblog/2011/12/14/combating-self-xss/): > X-Content-Security-Policy: no-user-js > > Developers who want to use the Web Console to test their sites on websites > that have set 'no-user-js' would have a preference to override the > 'no-user-js' directive. For websites that have not set 'no-user-js', > developers would see no change to Web Console. > > Thoughts?
The proposed scheme would fail to protect the long retail of sites while it would be annoying for debugging sites that use the directive. If a developer can override the directive via a preference, social engineering attack could tell excessively gullible users to flip the preference. Thus, the scheme wouldn't protect excessively gullible users. Rather than sites asking search and developer features to be turned off, I think we should find a completely browser-side mechanism for discouraging a non-developers from using the developer tools in ways they don't understand. Considering that the developer tools have keyboard shortcuts for opening them, which makes it easier to make gullible users open to the developer tools, one a possible solution would be that the first time the developer tools are opened the user has to explicitly enable the tools after reading a warning. -- Henri Sivonen [email protected] http://hsivonen.iki.fi/ _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
