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.
Adam Barth wrote:
I've taken the liberty of sketching out a straw-man XSSModule for CSP
on the Mozilla wiki:
https://wiki.mozilla.org/Security/CSP/XSSModule
I welcome your feedback,
Adam
Hi Adam,
I'm not sure if hacking at the straw man should occur on the list or on
the wiki. Please let
On Tue, Oct 20, 2009 at 1:26 PM, Mike Ter Louw mter...@uic.edu wrote:
I'm not sure if hacking at the straw man should occur on the list or on the
wiki. Please let me know if it should go to the wiki.
I've be inclined to discuss feedback on the mailing list where others
can see and comment most
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
23 matches
Mail list logo
