Content Security Policy without unsafe-inline
I'm trying to add CSP (https://en.wikipedia.org/wiki/Content_Security_Policy) to a Tapestry application. The problem is that I have to add unsafe-inline because Tapestry adds all the initializing stuff in an inline script Block at the bottom. That's making XSS attacks easier (or even possible). Is there a way to prevent that in 5.3 and are there any plans on getting rid of this old-school stuff in 5.4? -- Chris - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load?
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java lance.j...@googlemail.com wrote: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load? Not to mention that JavaScriptSupport.addScript() is deprecated. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...)
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com:
How would you propose JavaScriptSupport.addScript(...) would work without
inline scripts?
Not to mention that JavaScriptSupport.addScript() is deprecated.
The same question applies to JavaScriptSupport.require(...)
I guess event handlers should be registered in completely different
way - using ids, CSS classes or data- attributes. More like the
standard jQuery way with selectors and on:
$( #myTable tr ).on( click, function() {
alert( $( this ).attr(data-id) );
});
So, all the JS for a component should be in the JS. So maybe the whole
JavaScriptSupport class should be deprecated?
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 14:01:16 -0200, Christian Köberl
tapestry.christian.koeb...@gmail.com wrote:
I guess event handlers should be registered in completely different
way - using ids, CSS classes or data- attributes. More like the
standard jQuery way with selectors and on:
$( #myTable tr ).on( click, function() {
alert( $( this ).attr(data-id) );
});
That's what Tapestry 5.4 does in its components.
So, all the JS for a component should be in the JS.
But the JS file still needs to be included in the HTML.
So maybe the whole
JavaScriptSupport class should be deprecated?
How would JavaScript files be included by pages and components? Do you
have any suggestion on how a JavaScriptSupport-less Tapestry would work in
relation to JavaScript? I'm sorry, I just cannot see how (nor why).
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 13:35:01 -0200, Lance Java lance.j...@googlemail.com wrote: Not to mention that JavaScriptSupport.addScript() is deprecated. The same question applies to JavaScriptSupport.require(...) I don't think so. addScript() adds arbitrary JavaScript, so that may be a problem if a remote attacker creates some way of calling it. JavaScriptSupport.require() doesn't add arbitrary JavaScript: it just adds calls to the JS function require(). -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
I have a sneaking suspicion that trying to implement this you would end up
writing a custom implementation of script and eval(...) to achieve
tapestry's current behaviour
:)
On 4 Feb 2014 16:01, Christian Köberl
tapestry.christian.koeb...@gmail.com wrote:
2014-02-04 Lance Java lance.j...@googlemail.com:
How would you propose JavaScriptSupport.addScript(...) would work
without inline scripts?
Not to mention that JavaScriptSupport.addScript() is deprecated.
The same question applies to JavaScriptSupport.require(...)
I guess event handlers should be registered in completely different
way - using ids, CSS classes or data- attributes. More like the
standard jQuery way with selectors and on:
$( #myTable tr ).on( click, function() {
alert( $( this ).attr(data-id) );
});
So, all the JS for a component should be in the JS. So maybe the whole
JavaScriptSupport class should be deprecated?
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 12:58:22 -0200, Lance Java lance.j...@googlemail.com wrote: How would you propose JavaScriptSupport.addScript(...) would work without inline scripts? Do you expect a custom javascript file per page load? Reading the linked Wikipedia article, that's the only solution I can think of. I think it could be done with just a couple changes and a new Dispatcher. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Reading the linked Wikipedia article, that's the only solution I can think of. I think it could be done with just a couple changes and a new Dispatcher. It's tricky because there would be 2 requests (1 for markup and 1 for javascript).
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 14:32:52 -0200, Lance Java lance.j...@googlemail.com wrote: I have a sneaking suspicion that trying to implement this you would end up writing a custom implementation of script and eval(...) to achieve tapestry's current behaviour Nope, I was thinking of encoding the JavaScript code in the URL, probably in Base64, and write a Dispatcher that would catch these requests, extract the code from the URL and return it. Or store the code in memory, put a token in the URL and use the token to retrieve the stored code. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
I hate both ideas! Encoding in the URL means a useless request and will have issues with maximum url length. A token requires serverside state and relies on some form of time to live.
Re: Content Security Policy without unsafe-inline
I also think encoding in the URL opens up a security hole.
Re: Mixup with page resolution
On Sun, 02 Feb 2014 17:05:28 -0200, Bob Harner bobhar...@gmail.com wrote: I'm with Lance in thinking that an exception should be thrown. The exception message should list the conflicting page names, of course. I prefer to have Tapestry check the longer URL before using the shorter one, as in 99.9% of the time there are no conflicting page names. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 15:20:25 -0200, Lance Java lance.j...@googlemail.com wrote: I hate both ideas! Encoding in the URL means a useless request and will have issues with maximum url length. And security, as you cited in another e-mail, but only if the attacker manages to change the generated HTML to include the JavaScript URL, but, if they can already change the generated HTML, security is already lost. A token requires serverside state and relies on some form of time to live. Actually, the token and its corresponding state would be thrown off after used, so it wouldn't have much of a memory load. The use of some caching library would solve the time to live problem, and the time to live itself would be quite short. There are the two solutions I can see for anyone who wants to use Content Security Policy. There's no free lunch. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
If there was no time to live I could kill your server by requesting lots of pages and never requesting the javascript :) If url encoding I could get your cookie if you visit my (external) site which includes a script from your site.
Re: Content Security Policy without unsafe-inline
2014-02-04 Thiago H de Paula Figueiredo thiag...@gmail.com:
How would JavaScript files be included by pages and components? Do you have
any suggestion on how a JavaScriptSupport-less Tapestry would work in
relation to JavaScript? I'm sorry, I just cannot see how (nor why).
Easy, just the way require.js works :)
// MyComp.java
@Import(library = MyComp.js)
public class MyComp {
}
// MyComp.js
require( ['t5/core/console], function( console ) {
console.log('lala');
});
If you need any data in your script, then just add the stuff to your
DOM, e.g. with data- attributes or hidden fields.
See http://www.requirejs.org/docs/start.html - there's no example with
inline JS.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 15:58:46 -0200, Lance Java lance.j...@googlemail.com wrote: If there was no time to live I never suggested that. Of course there would be a time to live. Caches can be easily configured to do that. If url encoding I could get your cookie if you visit my (external) site which includes a script from your site. Yep, bad idea. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
Agreed that the only reasonable solution is a token + ttl. I'm not convinced it's a good idea though.
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
tapestry-hibernate upgrade version?
Hi guys, in Tap 5.4 I'm wondering if there is any chance we could upgrade the tapestry-hibernate version away from 4.1.2? 4.1.2 seems to have a bug which causes the mysql driver not be found in Tomcat. Please see post https://forum.hibernate.org/viewtopic.php?p=2454336 If I upgraded it in my pom, would this cause issues else where? -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Content Security Policy without unsafe-inline
I happen to be a fan of tapestry's multi-page approach and serverside markup generation. On 4 Feb 2014 18:35, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). Most methods in JavaScriptSupport are deprecated anyway. JavaScriptSupport#require could be removed again (requiring could be done by @Import). Voila - no inline JS anymore. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 16:34:45 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: It's tricky because there would be 2 requests (1 for markup and 1 for javascript). No, there's no need for a 2nd request - JS should be static - it's code! The data should be in the DOM (or probably fetched by a REST request per JSON). Think outside of the Tapestry box - if you look at recent examples in other frameworks you won't find any inline JS anymore. It's not about inline JavaScript. And I agree that it should be avoided. I think you're overlooking something: the fact that, sometimes, JavaScript needs to be dynamically generated server-side because it needs dynamic information. And one solution for doing this is to generate inline JavaScript. The other solution would be to have an AJAX request to do it, but then it's another request and it would slow down stuff a lot. And, again, let me remember you that Tapestry is already doing what you're asking in most places. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Content Security Policy without unsafe-inline
On Tue, 04 Feb 2014 17:45:37 -0200, Christian Köberl tapestry.christian.koeb...@gmail.com wrote: 2014-02-04 Lance Java lance.j...@googlemail.com: I happen to be a fan of tapestry's multi-page approach and serverside markup generation. Me too - but I think there would be a big chance in 5.4 to clean up the JS stuff and I think inline JS is no good idea. The core components could all be refactored to work without inline JS - like the new DateField (a good example how to do it). I don't know a politer way of saying this, but I already said that Tapestry 5.4 is already doing that at least twice. I'm having a really unlucky day. :( -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-hibernate upgrade version?
If I upgraded it in my pom, would this cause issues else where? Not making any guarantees but it shouldn't be a problem (unless the hibernate api has changed, which I doubt)
Re: tapestry-hibernate upgrade version?
Thanks Lance. On Tue, Feb 4, 2014 at 3:22 PM, Lance Java lance.j...@googlemail.comwrote: If I upgraded it in my pom, would this cause issues else where? Not making any guarantees but it shouldn't be a problem (unless the hibernate api has changed, which I doubt) -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: tapestry-hibernate upgrade version?
JIRA ticket please! On Tue, 04 Feb 2014 19:17:49 -0200, George Christman gchrist...@cardaddy.com wrote: Thanks Lance. On Tue, Feb 4, 2014 at 3:22 PM, Lance Java lance.j...@googlemail.comwrote: If I upgraded it in my pom, would this cause issues else where? Not making any guarantees but it shouldn't be a problem (unless the hibernate api has changed, which I doubt) -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
