On 10/22/09 3:58 PM, Lucas Adamski wrote:
CSS is content importing.. oh but IE allows CSS "expressions" so its a
XSS vector too.
IE8 has killed expressions off, our CSP spec says -moz-binding has to
come from chrome: or resource: (that is, be built in).
https://wiki.mozilla.org/Security/CSP/S
Hi
(long post, like lukas very imho)
The thing that I like about modularizing based on threats is that it
is much easier to explain to the web developer. I agree that this
might make Browser vendors sad because (as Lukas said) "Threats just
don't map to API's in a remotely neat 1 to many relatio
On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne 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 getComputedStyle (
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 redire
On 8/11/09 3:19 AM, Gervase Markham wrote:
Here's some possibilities for www.mozilla.org, based on the home page -
which does repost RSS headlines, so there's at least the theoretical
possibility of an injection. To begin with:
allow self; options inline-script;
blocking inline-script is key t
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 approa
On 10/22/09 3:02 PM, Collin Jackson wrote:
> On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne 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 fu
On Thu, Oct 22, 2009 at 3:58 PM, Lucas Adamski wrote:
> The threat-model centric approach won't work in the long run for a few
> reasons:
I'm not sure what we're arguing about. Do you like Brandon's
groupings? They made sense to me. Are there concrete changes you
think we should make?
> a) th
On 23/10/2009 00:58, Lucas Adamski wrote:
[putting on my IMHO hat]
The threat-model centric approach won't work in the long run for a few
reasons:
good post!
iang
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org
[putting on my IMHO hat]
The threat-model centric approach won't work in the long run for a few
reasons:
a) threat models change over time.. nobody was even talking about
clickjacking until a few years ago, so had we designed this previously
we would have put frame controls under some oth
On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne 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 approach,
> IMHO, is to c
See inline.
On Thu, Oct 22, 2009 at 2:22 PM, 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 differen
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 are
On Thu, Oct 22, 2009 at 12:36 PM, Mike Ter Louw 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 approaches before we
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),
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
Devdatta wrote:
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-im
On Thu, Oct 22, 2009 at 10:15 AM, Mike Ter Louw 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 be better to
Devdatta 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., ).
Form actions would perhaps require some additional constraints, such as only
allowing submis
>
> 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"
>
> 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., ).
>
> Form actions would perhaps require some additional constraints, such as only
> allowing submission
Adam Barth wrote:
On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw 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., ).
Maybe we should focus the module
On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw 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., ).
Maybe we should focus the module on this threat m
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 currently
On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw 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 explain
wh
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 which
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 com
27 matches
Mail list logo
