Developers rely on the browser security model in countless ways
already. A fundamental attribute of security models is reliability.
I realize that not all browsers will have CSP in the foreseeable
future, but that is orthogonal from being able to detect & rely upon
CSP when it is present. And so no, I don't think there is an
inconsistency in my earlier statements below.
there may be a bug
- we fix it
the user may have turned it off
- that's why you need to send a CSP supported header, and not rely on
version sniffing. Furthermore, not sure why the user would turn it
off (does the user turn off same-origin restrictions, or cross-frame
navigation restrictions, or ...)
there may be a very similar attack Y using the same flaw which CSP
can't prevent, and so on.
- which is why we aren't prevent attacks, we are enforcing policies.
There is no "PREVENT XSS" switch in CSP for that reason. If
anything, this is a compelling argument for versioning because we may
have to update CSP in the future to modify existing policies or add
new ones
Lucas.
On Dec 19, 2008, at 9:35 AM, Gervase Markham wrote:
Lucas Adamski wrote:
Well, I think any security feature/model has to have some properties
that are reliable. So CSP may not prevent XSS is the blanket
sense, but
it still needs to be able to enforce some set of restrictions that
the
developer can rely upon.
Your second sentence doesn't follow from your first, in this context.
Yes, if CSP promises it'll prevent exact attack scenario X, it should
prevent X, and if it doesn't prevent X, it's a bug. (But all that's
really saying is that it's deterministic.) No, that doesn't mean that
developers should rely on a particular browser preventing attack X.
There may be a bug, the user may have turned it off, there may be a
very
similar attack Y using the same flaw which CSP can't prevent, and so
on.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
