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
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
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
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
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 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
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
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 m
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 ot
Would it be helpful to use some form of syntax highlighting, so at least
the more critical user can see which characters are URI component
separators/delimiters? This wouldn't prevent attacks that mimic domain
names using I18N characters (e.g., Johansen's pŠ°ypal.com), but can
be a non-intrusi
Gervase Markham wrote:
Sid Stamm wrote:
What worries me is that with no assurance that they're enforced, CSP
policies won't be provided by web sites since it takes time (granted,
not much of it) to compose them. It's likely that a profit-driven
company might rather have their engineers spend ti
Gervase Markham wrote:
> Robert O'Callahan wrote in mozilla.dev.planning:
>> 3) Some kind of dynamic anti-XSS filter that monitors browser traffic
>> and blocks stuff. Not many details about that yet.
>
> This latter is an interesting idea, but it sounds to me like a recipe
> for hard-to-understan
Hi Brendan, List
Thank you so much. The slides you pointed to are really interesting. I
agree that JavaScript is difficult to analyze statically, at least to
the level of completeness required to provide meaningful assurances
about security.
The work I've done so far is intended to put the e
roject
details would be helpful with this inquiry.
Sincerely,
Mike Ter Louw
Ph.D. Candidate, Computer Science
University of Illinois at Chicago
[EMAIL PROTECTED]
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
15 matches
Mail list logo
