Re: Content Security Policy without unsafe-inline

2014-02-06 Thread Lance Java
> What's annoying is that if Tapestry created some HTML5 elements for this
purpose; say  and ; it would "pass" the CSP even though it
would be exactly as hackable as having the inline script. Meanwhile, if
there's a man in the middle, having an inline script is no different than
having an external script in terms of injecting new client-side executable
content into the page.

Howard, I don't think CSP is trying to prevent a man in the middle attack.
It's trying to stop an XSS hack. Let's consider

   alert('hello');

Where 'hello' comes from a request parameter. A hacker could create a dodgy
link on their site and force users to pass a parameter of
hello');doSomethingEvil(); in a similar way to a SQL injection attack.

I'm starting to like your idea of  and . Please hear me out
;)

What we want:
Allow require, allow init, allow invocation of functions defined by our app

What we want to prevent:
A hacker injecting and executing arbitrary javascript

If we came up with some custom set of tags, we could restrict what's
allowed:

eg:
{foo:"value1", bar:"value2"}

{x:"y"}


I'm not sure that I love it. But it does solve the problem.


Re: Content Security Policy without unsafe-inline

2014-02-06 Thread Barry Books
I agree the data url sounds interesting but is not really practical for a
general purpose public site. I do think this might be interesting though


alert("hello ${user}");
<\t:script>

That becomes something like:



which returns:

define(["jquery"], function(jquery) {
alert("hello Barry");
}

This gives you simple dynamic javascript from a url that will work across a
cluster. It would be easy to set the cache policy and might be possible to
include in a stack if the script is static. The state would be managed just
like an event link because it's really just an event link that returns
Javascript instead of say a Zone.



On Thu, Feb 6, 2014 at 4:20 AM, Lance Java wrote:

> In theory, the data URL approach sounds perfect.
>
> But in reality we'd be swapping this:
>