W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: HTML Imports and CSP

From: Jim Manico <jim.manico@owasp.org>
Date: Thu, 2 Apr 2015 14:16:17 -0700
Message-ID: <-540522170612154325@unknownmsgid>
To: Crispin Cowan <crispin@microsoft.com>
Cc: Mike West <mkwst@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Please study LINQ more. It auto-parameterizes. Same with GO Templates. It
auto-encodes in the UI. These framework constructs allow devs to mix code
and data safely. This is the future....

Jim Manico
(808) 652-3805

On Apr 2, 2015, at 12:57 PM, Crispin Cowan <crispin@microsoft.com> wrote:

  And I’m saying that I disagree, what you have listed is a system that
mixes code with data, and copes with the security burden that creates. I
don’t know LINQ, had to look it up, and I find this: “LINQ extends the
language by the addition of query expressions
<http://en.wikipedia.org/wiki/Expression_(computer_science)>, which are
akin to SQL <http://en.wikipedia.org/wiki/SQL> statements, and can be used
to conveniently extract and process data from arrays
<http://en.wikipedia.org/wiki/Array_data_structure>, enumerable classes
<http://en.wikipedia.org/wiki/Class_(computer_science)>, XML
<http://en.wikipedia.org/wiki/XML> documents,” So, it is subject to similar
threats to SQL injection, which is yet another form of mixing code with
data and getting threats as a result. As I said, I don’t know LINQ at all,
so don’t know what was done to mitigate those threats, and don’t speak for
Microsoft with respect to LINQ.

*From:* Jim Manico [mailto:jim.manico@owasp.org <jim.manico@owasp.org>]
*Sent:* Thursday, April 2, 2015 11:02 AM
*To:* Crispin Cowan
*Cc:* Mike West; Devdatta Akhawe; Justin Fagnani; public-webappsec@w3.org
*Subject:* Re: HTML Imports and CSP

There are several cases that I listed below where this is not the case.

What I am saying is that if we want a secure future, we need frameworks
that allow the mixing of code and data in a safe way, like LINQ, Go
templates and many other modern framework examples in the wild today.


Jim Manico


(808) 652-3805

On Apr 2, 2015, at 10:20 AM, Crispin Cowan <crispin@microsoft.com> wrote:

 Sorry, it is so, regardless of whether anyone likes it J The vast majority
of security vulnerability classes result from confusing code with data:

·         Buffer overflows, integer overflows, UAFs, etc., all memory
corruption, happens because of confusing code with data: the CPU gets its
instructions from the same memory as it gets its data. A Harvard
architecture would eliminate this problem.

·         XSS results from mixing code with data: hand a user a URL that
they think is a web address, and it loads and runs code in their context.

·         CSP failed to wipe out XSS at a stroke, precisely because of
inline scripting that makes creating effective CSP difficult.

When you mix code with data inline, you create signaling and escaping
problems that make it easy to confuse code with data. So there are exactly
two choices here:

1.       Don’t mix code with data.

2.       Do mix code with data, and accept a never-ending burden of
perpetual security issues.

Here’s a talk I gave at the NSF last year on mixing code with data

That web site will ask you to “register” before you can view the video,
which only means that they ask you for your e-mail address, they don’t even
use passwords. So you can register yourself, or you can just enter
crispin@microsoft.com and it will let you in.

*From:* Jim Manico [mailto:jim.manico@owasp.org <jim.manico@owasp.org>]
*Sent:* Thursday, April 2, 2015 10:11 AM
*To:* Crispin Cowan
*Cc:* Mike West; Devdatta Akhawe; Justin Fagnani; public-webappsec@w3.org
*Subject:* Re: HTML Imports and CSP

This should not be so. Make it easier for coders with better franeworks.
Systems like .NET LINQ allow the mixing and does the parameterization
behind the hood. Also consider autoescaping templates.


Jim Manico


(808) 652-3805

On Apr 2, 2015, at 10:07 AM, Crispin Cowan <crispin@microsoft.com> wrote:

 My point was that mixing code with data is always bad for security, but
that doesn’t always make it the wrong choice, sometimes other
considerations are more important. But I do not think we should mix code
with data on the basis of “we do it elsewhere, so what the heck” J

*From:* Jim Manico [mailto:jim.manico@owasp.org <jim.manico@owasp.org>]
*Sent:* Thursday, April 2, 2015 10:05 AM
*To:* Crispin Cowan
*Cc:* Mike West; Devdatta Akhawe; Justin Fagnani; public-webappsec@w3.org
*Subject:* Re: HTML Imports and CSP

There are edge cases where inline script is necessary, like when
dynamically loading JS based on certain conditions. Those edge cases are
rare and only needed for extreme   performance tuning.


Jim Manico


(808) 652-3805

On Apr 2, 2015, at 9:37 AM, Crispin Cowan <crispin@microsoft.com> wrote:

 Mixing code inline with data is **always** a bad idea. The web never
should have allowed inline script, but it is too late to fix that now. The
best we can do is avoid creating **new** opportunities to mix code with

So, I would block inline event handlers just on principle, unless there is
some compelling compat need.

*From:* Mike West [mailto:mkwst@google.com <mkwst@google.com>]
*Sent:* Wednesday, April 1, 2015 11:50 PM
*To:* Devdatta Akhawe
*Cc:* Justin Fagnani; public-webappsec@w3.org
*Subject:* Re: HTML Imports and CSP

On Thu, Apr 2, 2015 at 6:32 AM, Devdatta Akhawe <dev.akhawe@gmail.com>

> Sure, why not? I'm not a huge fan of inline event handlers, but I don't
> think that allowing them (and inline script) in Imports actually increases
> the risk a developer exposes herself to. Do you think that's an incorrect
> analysis?

There is a huge difference in risk of XSS in inline event handlers and
inline scripts. Different types of contexts, nested contexts etc all
are issues. *cough* I think Joel wrote a paper about this :D

You're not wrong there; inline event handlers are bad and they should feel

That said, is the risk really different in kind from just allowing plain
old inline script that executes directly? It doesn't seem to be. Allowing
one without allowing the other seems capricious.

> There's a difference between supporting a new feature which isn't
> covered by any directive, and changing the meaning of a directive that
> already covers a featue.

Again, because of the DOMXSS risk (even just injecting a new inline script
without nonce), I think not using a new directive messes up the
security invariants for any CSP adopters.

If we move imports from `script-src` to `import-src`, then sites that
currently disallow imports will no longer have that protection. That seems

What's your ideal solution?

Received on Thursday, 2 April 2015 21:16:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:48 UTC