Re: Comments on the Content Security Policy specification
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From experience, that's what happens with technologies that are too complex. A simpler syntax for simple case really would help, it's just that Ian is coming a bit late for this. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From experience, that's what happens with technologies that are too complex. A simpler syntax for simple case really would help, it's just that Ian is coming a bit late for this. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
Daniel Veditz wrote: CSP is designed so that mistakes of omission tend to break the site break. This won't introduce subtle bugs, rudimentary content testing will quickly reveal problems. But won't authors fail to understand how to solve the problem, and open everything wide ? From experience, that's what happens with technologies that are too complex. A simpler syntax for simple case really would help, it's just that Ian is coming a bit late for this. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
Bil Corry wrote: CSP is non-trivial; it takes a bit of work to configure it properly and requires on-going maintenance as the site evolves. It's not targeted to the uninformed author, it simply isn't possible to achieve that kind of coverage -- I suspect in the pool of all authors, the majority of them don't even know what XSS is, let alone ways to code against it and using CSP to augment defense. But did you try to get feedback, not from the average site author, but from those who have experience at successfully protecting against XSS large sites that evolve frequently ? If the syntax has to be ugly, then there should be a tool that takes a site and calculates the appropriate CSP declarations. In fact a solution could be that everytime the browser reject downloading a ressource due to CSP rules, it spits out a warning on the javascript console together with the minimal CSP authorization that would be required to obtain that ressource. This could help authors to write the right declarations without understanding much to CSP. PS : Sorry for the multi-posting earlier, I was trying to cross-post to www-arch...@w3.org but it didn't work and I did not know it had sent the message to the group. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
On 7/17/09 8:40 AM, Bil Corry wrote: An external validation tool could help authors understand what their CSP rules are actually allowing/preventing (maybe something similar to validator.w3.org). To compliment it, another handy tool would be a browser plug-in that could help create CSP rules based on how the site actually works. These are great ideas. We are currently working on some how to documents with the spec for CSP that cover things such as how to create a policy for my site, and would love to see such tools come out of all this. -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
On 7/16/09 8:17 PM, Ian Hickson wrote: On Thu, 16 Jul 2009, Daniel Veditz wrote: Ian Hickson wrote: * The more complicated something is, the more mistakes people will make. We encourage people to use the simplest policy possible. The additional options are there for the edge cases. It doesn't matter what we encourage. Most authors are going to be using this through copy-and-paste from tutorials that were written by people who made up anything they didn't work out from trial and error themselves. Dan's point is absolutely true. The majority of sites will be able to benefit from simple, minimal policies. If a site hosts all its own content then a policy of X-Content-Security-Policy: allow self will suffice and will provide all the XSS protection out of the box. I tend to think this will be the common example that gets cut-and-pasted the majority of the time. Only more sophisticated sites will need to delve into the other features of CSP. Content Security Policy has admittedly grown more complex since it's earliest design but only out of necessity. As we talked through the model we have realized that a certain about of complexity is in fact necessary to support various use cases which might not common on the Web, but need to be supported. I believe that if one were to take a typical Web developer, show him this: X-Content-Security-Policy: allow self; img-src *; object-src media1.com media2.com; script-src trustedscripts.example.com ...and ask him does this enable or disable data: URLs in embed or would an onclick='' handler work with this policy or are framesets enabled or disabled by this set of directives, the odds of them getting the answers right are about 50:50. Sure, if you confuse them first by asking about disabling. _everything_ is disabled; the default policy is allow none. If you ask What does this policy enable? the answers are easier. I was trying to make the questions neutral (enable or disable). The authors, though, aren't going to actually ask these questions explicitly, they'll just subconsciously form decisions about what the answers are without really knowing that's what they're doing. I don't think it makes sense for sites to work backwards from a complex policy example as the best way to understand CSP. I imagine sites starting with the simplest policy, e.g. allow self, and then progressively adding policy as required to let the site function properly. This will result in more-or-less minimal policies being developed, which is obviously best from a security perspective. data URLs? nope, not mentioned inline handlers? nope, not mentioned How is an author supposed to know that anything not mentioned won't work? And is that really true? X-Content-Security-Policy: allow *; img-src self; Are cross-origin scripts enabled? They're not mentioned, so the answer must be no, right? This isn't intended to be a gotcha question. My point is just that CSP is too complicated, too powerful, to be understood by many authors on the Web, and that because this is a security technology, this will directly lead to security bugs on sites (and worse, on sites that think they are safe because they are using a Security Policy). I don't think your example is proof at all that CSP is too complex. If I were writing that policy, my spidey senses would start tingling as soon as I wrote allow *. I would expect everything to be in-bounds at that point. This is a whitelist mechanism after all. X-Content-Security-Policy: allow https://self:443 Using self for anything other than a keyword is a botch and I will continue to argue against it. If you mean myhost at some other scheme then it's not too much to ask you to spell it out. I kind of liked Gerv's suggestion to syntactically distinguish keywords from host names, too. The examples I gave in the previous e-mail were all directly from the spec itself. I also agree that this example is awkward. In fact, the scheme and port are inherited from the protected document if they are not specified in the policy, so this policy would only make sense if it were a non-https page which wanted to load all its resources over https. I don't feel strongly about keeping that feature. Perhaps we should allow self to be used not-in-conjunction with scheme or port as Dan says. ...I don't think a random Web developer would be able to correctly guess whether or not inline scripts on the page would work, or whether Google Analytics would be disabled or not. Are inline scripts mentioned in that policy? Is Google Analytics? No, so they are disabled. _I_ know the answer. I read the spec. My point is that it isn't intuitive and that authors _will_ guess wrong. Sorry, but I think this is also weak evidence for too much complexity. This is a whitelist technology so if a source isn't whitelisted, it won't be
Re: Comments on the Content Security Policy specification
Jean-Marc Desperrier wrote: In fact a solution could be that everytime the browser reject downloading a ressource due to CSP rules, it spits out a warning on the javascript console together with the minimal CSP authorization that would be required to obtain that ressource. This could help authors to write the right declarations without understanding much to CSP. Announcing rejected resources is an important part of the plan. The spec has a reportURI for just this reason, and the Mozilla implementation will also echo errors to the Error Console. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
Moving discussion to mozilla.dev.tech.crypto, but do go ahead and file bugs. I doubt 3.5 behaves any differently than 3.0 (you did mean 3.0.10, right? If you're using Firefox 2 please stop). nk wrote: Hi all, I am researching the window.crypto.generatedCRMFRequest() function available on FireFox (I am using FF 2.0.10). Now, if requested keys are for signing - everything looks good. But if requested keys are for key exchange (e.g. rsa-ex), the generated CRMF request structure has a number of issues. Here are the issues I am facing: 1) A PKIArchiveOptions control is included (http://www.ietf.org/rfc/ rfc4211.txt, section 6.4). The EncryptedKey structure in it is encoded as a SEQUENCE while it actually is a CHOICE. Our CRMF decoder is throwing as soon as it sees this structure. Shall I raise a bug ? 2) The EncryptedKey is encoded as the now deprecated EncryptedValue structure. Is there a plan to encode the value with EnvelopedData structure any time soon ? 3) Finally, the ProofOfPossession structure looks broken in this scenario as what we see is: A2 05 80 03 00 03 00, which does not seem to relate to any of the permitted options desrcibed in RFC 4211, section 4. FYI: If CRMF request contains cert request for a signing key pair the ProofOfPossession is valid (a correct instance of POPOSigningKey) and is correctly verified by our decoder. Does anyone know if these issues have been addressed in FF 3.5 and if not, will they be addressed in the next releases of FF ? Many thanks in advance, Nikolai Koustov. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
