[public-webappsec] <none>

Hi Alexander,

Also trying to avoid distraction... I enjoy talking to friends/family about
the cool things that are happening in tech (limiting myself in time, as I
know it's a bit boring for some). But whenever I mention the word "nonce",
they (being non-techies) ask about it; sometimes they wonder why
paedophiles are relevant, and no one can see why "number used once" would
ever be abbreviated like that (I suspect "used for one occasion" would have
the same reaction), they will then ask why it's not something else, like
"nuo" (I'm not the person to know if that's any better, for years I didn't
give white/black lists any thought).

I'll also skip the implementation bit in browsers, but I believe it's due
to when the CSP restrictions are applied, where it's no longer a single
string at that point... e.g. "/image.jpg", "../image.jpg" "
https://example.com/image.jpg" and "https://example.com:443/image.jpg"
could all be the same.

Like you, I'm also glad to see more pressure to add/use these security
features (it was only a few years ago I would see it as a simple note in a
security test).

Back to the main point though, I think having a simple "Scripting-Policy"
would be a very easy and effective way to mitigate against most (not all)
XSS (in comparison CSP3 doesn't solve all XSS issues either).

And I think you could easily pressure developers to add a
"Scripting-Policy", even though there will still be problems with large
amounts of inline JavaScript (fortunately developers have known for years
that is a problem)... so I do think this part of the proposal is reasonable.

I just don't want us to loose the power we have in CSP when it comes
to Resource Confinement, where I think the current CSP3 syntax does this
very well (after we ignore some of the messy bits more focused on XSS).

Craig



On Wed, 24 Jul 2019 at 00:14, Alexander Forbes <axeforbes@uk.ibm.com> wrote:

> Not to distract from the meat of the conversation, but 'nonce' as as term
> is and had been used ubiquitously in cryptograpy and cryptographic
> literature for decades - if not more now.
>
> As as word it has an etymology going back to the 13th century, with its
> established meaning of 'used for one occasion' remaining consistent.
>
> Yes, languages evolve, but just because we in the UK have some who use it
> to refer to child molesters does not mean the term should be replaced.
>
> In recent vernacular I've hardly ever heard 'nonce' used outside of
> cryptographic literature. These days we tend to call child molesters and
> paedophiles well, exactly that, child molesters and paedophiles.
>
> Please let us not taint the conversation with such unpleasantness in
> future. 'Nonce' had a clear, specific, and well understood meaning and is
> the appropriate term in this context.  ('Hash' and 'cryptogrpahic digest'
> are important terms but they are semanticly different and, simply put, do
> not mean the same thing.)
>
> As to ..."The tools have changed since that research paper, but I
> *suspect* there's still a "friction" against subdomains"... I totally agree
> on a conceptual level - indeed, given the stateless nature of HTTP I see no
> reason why any response should not have the ability to restrict scripts
> (via headers - through .htaccess files or other controls such as
> meta/pramga tags in HTML), as long as the most strict intersection of all
> defined restrictions is enforced.
>
> As to  ..."sincerely complicate writing a parser"... I will defer to the
> expertise of the list here and those with development experience, but my
> initial response is surprise. As far as I can see this is simple left to
> right parsing (i.e. LR(1) grammar processing) task, hence should be both
> fast and relatively simple?
>
> As to the concerns regarding adoption, from my perspective this is not a
> technical challenge and will be driven in future more by it simply being
> best practice. Best practice tends to filter into inclusion for standards
> and eventually through enforcement via regulators and through good
> developers system administrators.
>
> As of today I see a a lot of pressure (often mandated requirements) for
> Strict-Transport-Security headers, cookies being flagged Secure and
> HttpOnly and if not covered by CSP and other controls, additional headers
> such as X-Frame-Options, X-Content-Type-Options and Referrer-Policy. There
> is even pressure (and often implementation of) SRI and non-standardised
> options like Feature-Policy from vendors I have worked with.
>
> Just as I don't subscribe to 'build it and users will come' mantra (i.e. I
> don't think people will use something that's crap), the same applies to
> security in my view:  limit it too much and trade off too much in the name
> of simplicity / ease of implementation and you risk undermining the entire
> benefit and rendering it marginal to pointless to implement. The TLS teams
> have managed to achieve both - robust cryptograpy for the time, clear
> implementation guidance and good adoption, with transition happening to
> later versions as needed (sometimes through regulatory pressure). There is
> no reason the same cannot be true for CSP3.
>
> More crudely put: if the implementation is reasonable and the need is
> there, developers who don't get it and want to ignore it will be forced to
> learn and adapt over time. This who won't will be replaced in the market by
> ones who can/will as time goes on.
>
> Regards,
>
> Alexander Forbes
> axeforbes@uk.ibm.com
> +447917158798
>
> Sent from IBM Verse
>
>
>
> Oda, Terri --- Re: A modest content security proposal. ---
>
> From: "Oda, Terri" <terri.oda@intel.com>
> To: "Craig Francis" <craig.francis@gmail.com>
> Cc: "Mike West" <mkwst@google.com>, "Devdatta Akhawe" <dev@dropbox.com>,
> "Web Application Security Working Group" <public-webappsec@w3.org>
> Date: Tue, 23 Jul 2019 23:44
> Subject: Re: A modest content security proposal.
> ------------------------------
>
>
> On Tue, Jul 23, 2019 at 12:45 PM Craig Francis <craig.francis@gmail.com>
> wrote:
>
>> On Tue, 23 Jul 2019 at 08:51, Mike West <mkwst@google.com> wrote:
>> A more typical (smaller) website probably doesn't need that many paths,
>> and if they only contain static files, then you're unlikely to find a
>> redirect in there.
>>
>> I don't have fundamental objections to including some sort of path
>>> restrictions in whatever we do next. I don't think they're terribly useful
>>> as-defined in CSP3: they sincerely complicate writing a parser, and they're
>>> more or less neutered so as to not leak data about redirects.
>>>
>>
> These two paragraphs reminded me... back before CSP, I worked on a system
> to do resource confinement, and our research at the time found that many
> sysadmins were totally ok with everything being based on domains, but many
> web design folk preferred paths, because they didn't always have sufficient
> control over their hosting (or their customers didn't, or it had the
> potential for a whole lot of open tickets and communication hassles even
> when it was doable).
>
> ... Of course, since the projects where we asked these questions was a
> research project, we made a note of it and then only wrote the demo code to
> support domains because paths would have been more work and weren't really
> more likely to get us a publication. ;)  (Ah, academia!)
>
> The tools have changed since that research paper, but I *suspect* there's
> still a "friction" against subdomains.  Hosted services like github pages
> or wordpress may not have that type of flexibility, and contract designers
> may have the same problems now as they did a decade ago.  These seem like
> issues that may affect folk who would be especially interested in a sleek
> new CSP.  Not sure how we'd test the hypothesis, but I'm thinking that
> Craig is onto something here so I guess I'm +1 for supporting paths too.
>
>  Terri
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>