On 27/10/09 09:33, Adam Barth wrote:
My technical argument is as follows. I think that CSP would be better
off with a policy language where each directive was purely subtractive
because that design would have a number of simplifying effects:
CSP's precursor, Content Restrictions
On 28/10/09 16:23, Gervase Markham wrote:
On 27/10/09 09:33, Adam Barth wrote:
My technical argument is as follows. I think that CSP would be better
off with a policy language where each directive was purely subtractive
because that design would have a number of simplifying effects:
CSP's
On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz dved...@mozilla.com wrote:
They have already opted in by adding the CSP header. Once they've
opted-in to our web-as-we-wish-it-were they have to opt-out of the
restrictions that are too onerous for their site.
I understand the seductive power of
Hi
There are two threads running in parallel here:
1) Should blocking XSS be default behaviour of adding a
X-Content-Security-Policy? (instead of the straw man proposal where a
additional 'block-xss' would be required )
2) Should the result of blocking XSS also cause eval and inline
scripts to
On 10/27/09 2:33 AM, Adam Barth wrote:
I understand the seductive power of secure-by-default here.
If only she loved me back.
This statement basically forecloses further discussion because it does
not advance a technical argument that I can respond to. In this
forum, you are the king and I
On Tue, Oct 27, 2009 at 12:39 PM, Daniel Veditz dved...@mozilla.com wrote:
I don't think we're having a technical argument, and we're not getting
the feedback we need to break the impasse in this limited forum.
I agree that we're not making progress in this discussion.
At a high level, the
On 10/27/2009 02:33 AM, Adam Barth wrote:
My technical argument is as follows. I think that CSP would be better
off with a policy language where each directive was purely subtractive
because that design would have a number of simplifying effects:
I couldn't find a comment that summarizes the
On 10/22/09 6:09 PM, Adam Barth wrote:
I agree, but if you think sites should be explicit, doesn't that mean
they should explicitly opt-in to changing the normal (i.e., non-CSP)
behavior?
They have already opted in by adding the CSP header. Once they've
opted-in to our web-as-we-wish-it-were
It seems reasonable to mitigate both of those without using CSP at all.
+1.
But the current spec was trying to address them. For e.g all the
img-src, frame-src , frame-ancestor, font-src, style-src isn't really
needed for preventing XSS (afaik). My view is that there is not
problem with
On 23/10/09 01:50, Daniel Veditz wrote:
blocking inline-script is key to stopping XSS. We added the ability to
turn that bit of CSP off as an interim crutch for complex sites trying
to convert, but if our proof-of-concept site has to rely on it we've
clearly failed and will be setting a bad
On 21/10/09 17:25, Sid Stamm wrote:
Additional Directives are not a problem either, unless they're mandatory
for all policies (which is not the case ... yet). I'm still more in
favor of extension via new directives than extension by modifying
existing ones: this seems more obviously backward
Gervase Markham wrote:
I think it would be good if we didn't have to invent a new header for
each idea of ways to lock down content. I think it would be great if
people could experiment with Content-Security-Policy: x-my-cool-idea,
and see if it was useful before standardization. Any idea
On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw mter...@uic.edu wrote:
I've added a CSRF straw-man:
https://wiki.mozilla.org/Security/CSP/CSRFModule
This page borrows liberally from XSSModule. Comments are welcome!
Two comments:
1) The attacker goal is very syntactic. It would be better to
Adam Barth wrote:
2) It seems like an attacker can easily circumvent this module by
submitting a form to attacker.com and then generating the forged
request (which will be sent with cookies because attacker.com doesn't
enables the anti-csrf directive).
I agree. It seems anti-csrf (as
On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote:
I agree. It seems anti-csrf (as currently defined) would be most beneficial
for defending against CSRF attacks that don't require any user action beyond
simply viewing the page (e.g., img src=attack).
Maybe we should focus
Adam Barth wrote:
On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote:
I agree. It seems anti-csrf (as currently defined) would be most beneficial
for defending against CSRF attacks that don't require any user action beyond
simply viewing the page (e.g., img src=attack).
Maybe we should focus the module on this threat more specifically. My
understanding is that this is a big source of pain for folks who
operate forums, especially for user-supplied images that point back to
the forum itself. What if the directive was something like
cookieless-images and
On Thu, Oct 22, 2009 at 10:15 AM, Mike Ter Louw mter...@uic.edu wrote:
I think this is a good start, and should be an option for sites that don't
want CSP to provide any other CSRF restrictions. I've added an additional
directive to the wiki, but it needs further definition.
I think it might
Adam Barth wrote:
I think it might be better to focus this module on the forum poster
threat model. Instead of assuming the attacker can inject arbitrary
content, we should limit the attacker to injecting content that is
allowed by popular form sites (e.g., bbcode). At a first guess, I
would
Mike Ter Louw wrote:
There is a usability issue here: is it more usable (w.r.t. the web
developer) to:
(1) support a declaration of anti-csrf and enable the widest default
set of protections that could be offered against CSRF (without being too
strict as to break the most common use cases),
On Thu, Oct 22, 2009 at 12:36 PM, Mike Ter Louw mter...@uic.edu wrote:
In this case, this boils down to: should CSP directives be threat-centric or
content-type-centric? Alternatively, this may be an example of CSP being
too granular.
I suspect we'll need to experiment with different
I'd like to take a quick step back before we proceed further with the
modularization discussion. I think it is fine to split CSP into
modules, but with the following caveats:
1. Splitting the modules based upon different threat models doesn't seem
to be the right approach. There are many
On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne bste...@mozilla.com wrote:
1. Splitting the modules based upon different threat models doesn't seem to
be the right approach. There are many areas where the threats we want to
mitigate overlap in terms of browser functionality. A better
Brandon Sterne wrote:
I'd like to take a quick step back before we proceed further with the
modularization discussion. I think it is fine to split CSP into
modules, but with the following caveats:
1. Splitting the modules based upon different threat models doesn't seem
to be the right
On 10/22/09 10:31 AM, Mike Ter Louw wrote:
Any ideas for how best to address the redirect problem?
In the existing parts of CSP the restrictions apply to redirects. That
is, if you only allow images from foo.com then try to load an image from
a redirector on foo.com it will fail if the
On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne bste...@mozilla.com wrote:
Take XSS and history stealing for example. Assume these are seperate
modules and each is responsible for mitigating its respective threat.
Presumably the safe history module will prevent a site from being able
to do
On 20/10/09 21:20, Sid Stamm wrote:
While I agree with your points enumerated above, we should be really
careful about scope creep and stuffing new goals into an old idea. The
original point of CSP was not to provide a global security
infrastructure for web sites, but to provide content
On 10/21/09 2:49 AM, Gervase Markham wrote:
I think we need to differentiate between added complexity in syntax and
added complexity in implementation.
If we design the syntax right, there is no need for additional CSP
directives to make the syntax more complicated for those who neither
I put together a brief description of the history module proposal on the wiki:
https://wiki.mozilla.org/Security/CSP/HistoryModule
On Tue, Oct 20, 2009 at 10:03 AM, Collin Jackson
mozi...@collinjackson.com wrote:
If you want to make a module that prevents history sniffing completely
against
Collin Jackson wrote:
If you want to make a module that prevents history sniffing completely
against specific sites and avoids assuming the user never interacts
with a bad site, you could have a CSP module that allows a server to
specify whether its history entries can be treated as visited by
class) can give people power to do surprising things (e.g. internal
network ping sweeping, user history enumeration respectively).
Isn't the ping sweeping threat already taken care of by CSP? No
requests to internal networks will be honored as they won't be allowed
by the policy. (although its
On Tue, Oct 20, 2009 at 12:47 PM, Mike Ter Louw mter...@uic.edu wrote:
The threat model of HistoryModule, as currently defined, seems to be
precisely the threat model that would be addressed by a similar module
implementing a per-origin cache partitioning scheme to defeat history timing
On 10/20/09 12:58 PM, Adam Barth wrote:
I think one of the goals of CSP is to avoid having one-off HTTP
headers for each threat we'd like to mitigate. Combining different
directives into a single policy mechanism has advantages:
1) It's easier for web site operators to manage one policy.
In the modular approach, this is not true. You simply send this header:
X-Content-Security-Policy: safe-history
The requirements to remove inline script, eval, etc aren't present
because you haven't opted into the XSSModule. You can, of course,
combine them using this sort of policy:
On Tue, Oct 20, 2009 at 1:42 PM, Collin Jackson
mozi...@collinjackson.com wrote:
I think we're completely in agreement, except that I don't think
making CSP modular is particularly hard. In fact, I think it makes the
proposal much more approachable because vendors can implement just
BaseModule
Hi
Sorry, I didn't read your modular approach proposal before sending the
email.
Cheers
Devdatta
On Oct 20, 2:03 pm, Adam Barth abarth-mozi...@adambarth.com wrote:
In the modular approach, this is not true. You simply send this header:
X-Content-Security-Policy: safe-history
The
I'm not sure that providing a modular approach for vendors to
implemented pieces of CSP is really valuable to our intended audience
(web developers). It will be hard enough for developers to keep track
of which user agents support CSP, without requiring a matrix to
understand which
Why do web developers need to keep track of which user agents support
CSP? I thought CSP was a defense in depth. I really hope people don't
use this as their only XSS defense. :)
On Tue, Oct 20, 2009 at 2:25 PM, Lucas Adamski lu...@mozilla.com wrote:
I'm not sure that providing a modular
We should think ahead, not just a year or two but to the point that
all current browsers will be EOL and (just like every other feature
that is currently in HTML5) this will be widely adopted and reliable.
Lucas.
On Oct 20, 2009, at 2:30 PM, Collin Jackson wrote:
Why do web developers
It seems to me that thinking ahead would tend to favor the modular
approach, since we're unlikely to guess the most compelling use cases
on the first try, and modules will provide a backwards-compatible
means of evolving the spec to what web authors actually need.
On Tue, Oct 20, 2009 at 2:49 PM,
I actually think the modular approach is better for the web developer
as the policy is easier to write and understand.
But I do share your concern, Atleast right now, it is pretty easy to
say -- user agents that support XSSModule are protected against XSS
and user agents that support history
I've been a firm believer that CSP will evolve over time but that's an
argument for versioning though, not modularity. We are as likely to
have to modify existing behaviors as introduce whole new sets. It's
also not a reason to split the existing functionality into modules.
Lucas
On Oct
On Tue, Oct 20, 2009 at 3:21 PM, Lucas Adamski lu...@mozilla.com wrote:
I've been a firm believer that CSP will evolve over time but that's an
argument for versioning though, not modularity. We are as likely to have to
modify existing behaviors as introduce whole new sets. It's also not a
I'm confident we can figure out how best to communicate CSP use cases
to developers independent of implementation. What we should have are
documentation modules that walk a web dev through specific goal-driven
examples, for example.
The problem with modules I see is they will complicate
I'm not a fan of it but it's unavoidable for a security mechanism. We
already had bugs filed against CSP that would result in content
impacting behavioral changes. Not to mention that even module-centric
functionality would have to be revised to govern new APIs and new
types of attacks
The reporting infrastructure does seem pretty easy to modularize but
it's also a bit exceptional as it doesn't drive any actual content
behaviors. I'm going to have to chew on this some more but my primary
concern remains that this approach could increase complexity and
reduce reliability
On a related note, just to have one more example (and for my learning)
, I went ahead and wrote a draft for ClickJackingModule.
https://wiki.mozilla.org/Security/CSP/ClickJackingModule
In general I like how short and simple each individual module is.
Cheers
Devdatta
2009/10/20 Lucas Adamski
Thanks Devdatta. One of the nice thing about separating the
clickjacking concerns from the XSS concerns is that developers can
deploy a policy like
X-Content-Security-Policy: frame-ancestors self
without having to make sure that all the setTimeout calls in their web
app use function objects
Note that the XSS mitigations can be opted out of, so we shouldn't
assume that mitigating something specific like clickjacking requires
XSS mitigations in the current proposal.
Lucas.
On Oct 20, 2009, at 6:50 PM, Adam Barth wrote:
Thanks Devdatta. One of the nice thing about separating
On 19-Oct-09, at 7:34 AM, Gervase Markham wrote:
On 15/10/09 22:20, Brandon Sterne wrote:
IOW, we need to decide if webpage defacement via injected style is in
the treat model for CSP and, if so, then we need to do B.
Is it just about defacement, or is it also about the fact that CSS
can
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
On 07/30/2009 07:06 AM, Gervase Markham wrote:
On 29/07/09 23:23, Ian Hickson wrote:
* Combine style-src and font-src
That makes sense.
I agree. @font-face has to come from CSS which is already subject to
style-src restrictions. I don't think there are any practical attacks
we are
On 10/08/09 19:50, Brandon Sterne wrote:
Working examples will be forthcoming as soon as we have Firefox builds
available which contain CSP.
We shouldn't need to wait for working builds to try and work out the
policies, should we? Although perhaps it would be a lot easier if you
could test
On Thu, 30 Jul 2009, Gervase Markham wrote:
On 29/07/09 23:23, Ian Hickson wrote:
* Remove external policy files.
I'm not sure how that's a significant simplification; the syntax is
exactly the same just with an extra level of indirection, and if that
makes things too complicated for
On a related note (to Ian's initial message), I'd like to ask again to
see some real-world policy examples. I suggested CNN last time, but
if something like Twitter would be an easier place to start, maybe we
could see that one? Or see the example for mozilla.org, maybe? Or
even just some toy
On 8/10/09 10:27 AM, TO wrote:
I'd like to ask again to
see some real-world policy examples. I suggested CNN last time, but
if something like Twitter would be an easier place to start, maybe we
could see that one? Or see the example for mozilla.org, maybe? Or
even just some toy problems to
On 8/10/09 5:00 AM, Gervase Markham wrote:
On 30/07/09 18:51, Daniel Veditz wrote:
* Move inline and eval keywords from script-src to a separate
directive, so that all the -src directives have the same syntax
I've argued that too and I think we agreed, although I don't see that
reflected in
On 29/07/09 23:23, Ian Hickson wrote:
* Remove external policy files.
I'm not sure how that's a significant simplification; the syntax is
exactly the same just with an extra level of indirection, and if that
makes things too complicated for you, don't use them.
* Removemeta policies.
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Bil Corry wrote:
CSP is non-trivial; it takes a bit of work to configure it properly
and requires on-going maintenance as the site evolves. It's not
targeted to the uninformed author, it simply isn't possible to
achieve that kind of coverage -- I suspect in the pool of all
authors, the majority
On 7/17/09 8:40 AM, Bil Corry wrote:
An external validation tool could help authors understand
what their CSP rules are actually allowing/preventing (maybe
something similar to validator.w3.org). To compliment it,
another handy tool would be a browser plug-in that could help
create CSP
On 7/16/09 8:17 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Daniel Veditz wrote:
Ian Hickson wrote:
* The more complicated something is, the more mistakes people will
make.
We encourage people to use the simplest policy possible. The additional
options are there for the edge cases.
It
Jean-Marc Desperrier wrote:
In fact a solution could be that everytime the browser reject
downloading a ressource due to CSP rules, it spits out a warning on the
javascript console together with the minimal CSP authorization that
would be required to obtain that ressource.
This could help
Ian Hickson wrote on 7/16/2009 5:51 AM:
I think that this complexity, combined with the tendency for authors to
rely on features they think are solvign their problems, would actually
lead to authors writing policy files in what would externally appear to be
a random fashion, changing them
66 matches
Mail list logo
