On 19-Oct-09, at 5:39 PM, Adam Barth wrote:
On Mon, Oct 19, 2009 at 6:43 AM, Johnathan Nightingale
<john...@mozilla.com> wrote:
Not as limited as you might like. Remember that even apparently
non-dangerous constructs (e.g. background-image, the :visited pseudo class) can give people power to do surprising things (e.g. internal network ping
sweeping, user history enumeration respectively).

I'm not arguing for or against providing the ability to
block-inline-css, but keep in mind that an attacker can do all those
things as soon as you visit attacker.com.

Yeah, I think you're absolutely right that CSP is primarily about preventing attackers from exploiting your browser's trust relationship with victim.com, and the examples I offered are (for lack of a better term), victim-agnostic. They don't steal victim.com credentials or cause unwanted changes to, or transactions with, your victim.com presence.

I do think, though, that a helpful secondary effect of CSP is that it reduces attackers' ability to amplify the effect of their attacks. You're right that it doesn't take much to get users to click on a link, but I think it is nevertheless the case that a good history enumerator or ping sweep which happens in the background while you're reading a NYTimes article will have a substantially higher success rate than a link in the comment section that says "Click here for free goodies." Basically by definition, link-clickers are a subset of your total prospective victim pool.

I think this is more specifically what makes me feel like there's still value to locking down all inline styling, or at least providing that facility, but I appreciate you forcing me to refine my thinking a little more.

  In the past, I've found it helpful to simply assume the
user is always visiting attacker.com in some background tab.  After
all, Firefox is supposed to let you view untrusted web sites securely.

Yes, absolutely so. We should continue to try to bend smarts towards fixing :visited and other nasty sleights-of-hand. But the one course of work doesn't preclude the other (and I don't think you were saying that it did).


Johnathan Nightingale
Human Shield

dev-security mailing list

Reply via email to