Kommentare für Jakob Korherr's Blog http://www.jakobk.com A blog about Java, MyFaces and web development Tue, 29 Nov 2011 04:36:00 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Kommentar zu JSF value expression injection vulnerability von djorm http://www.jakobk.com/2011/11/jsf-value-expression-injection-vulnerability/comment-page-1/#comment-852 djorm Tue, 29 Nov 2011 04:36:00 +0000 http://www.jakobk.com/?p=218#comment-852 Thanks for such a good write up and useful reproducer! Thanks for such a good write up and useful reproducer!

]]> Kommentar zu JSF value expression injection vulnerability von JSF value expression injection vulnerability | Syngu http://www.jakobk.com/2011/11/jsf-value-expression-injection-vulnerability/comment-page-1/#comment-840 JSF value expression injection vulnerability | Syngu Thu, 24 Nov 2011 06:39:39 +0000 http://www.jakobk.com/?p=218#comment-840 [...] A few days ago an issue was reported to Mojarra. It basically states that it is possible in JSF 2 to perform ValueExpression injection when includeViewParams is set to true on a navigation case. This means an attacker can cause any method of any managed bean in the application to be executed.    News Read the original post on DZone... [...] [...] A few days ago an issue was reported to Mojarra. It basically states that it is possible in JSF 2 to perform ValueExpression injection when includeViewParams is set to true on a navigation case. This means an attacker can cause any method of any managed bean in the application to be executed.    News Read the original post on DZone… [...]

]]> Kommentar zu JSF value expression injection vulnerability von J2EE Video Tutorial http://www.jakobk.com/2011/11/jsf-value-expression-injection-vulnerability/comment-page-1/#comment-838 J2EE Video Tutorial Thu, 24 Nov 2011 01:06:58 +0000 http://www.jakobk.com/?p=218#comment-838 Thank you for this info Thank you for this info

]]> Kommentar zu JSF value expression injection vulnerability von Jakob Korherr's Blog » JSF value expression injection vulnerability | Java EE 6 Development | Scoop.it http://www.jakobk.com/2011/11/jsf-value-expression-injection-vulnerability/comment-page-1/#comment-835 Jakob Korherr's Blog » JSF value expression injection vulnerability | Java EE 6 Development | Scoop.it Tue, 22 Nov 2011 17:09:22 +0000 http://www.jakobk.com/?p=218#comment-835 [...] Jakob Korherr's Blog » JSF value expression injection vulnerability [...] [...] Jakob Korherr's Blog » JSF value expression injection vulnerability [...]

]]> Kommentar zu Validation errors and bean updates von Michael Heinen http://www.jakobk.com/2010/06/validation-errors-and-bean-updates/comment-page-1/#comment-787 Michael Heinen Tue, 18 Oct 2011 15:48:15 +0000 http://www.jakobk.com/?p=107#comment-787 Hi Jakob, I just stumbled over this entry today and faced this problem also. I solved it in combination with a phase listener and a customized view handler: - A request scope flag is set in a phase listener if response is rendered immediately caused by a validation or conversion error. - The ViewHandler checks after(!) rendering this response but before state saving whether this flag is set. If it is set, the submitted input component, the input components of the submitted region or all input components of the submitted view are reset. So the resets are done in error case only. The tree visits are not so expensive in case of an ajax request with richfaces. The id of the submitted component (ajaxSingle=true) or the id of submitted region is in the request parameters. Out of the box support for this would be nice. I do not see any reason to keep the old values after the response with the invalid values is rendered again. Cheers, Michael Hi Jakob,
I just stumbled over this entry today and faced this problem also.
I solved it in combination with a phase listener and a customized view handler:
- A request scope flag is set in a phase listener if response is rendered immediately caused by a validation or conversion error.
- The ViewHandler checks after(!) rendering this response but before state saving whether this flag is set. If it is set, the submitted input component, the input components of the submitted region or all input components of the submitted view are reset.

So the resets are done in error case only. The tree visits are not so expensive in case of an ajax request with richfaces. The id of the submitted component (ajaxSingle=true) or the id of submitted region is in the request parameters.

Out of the box support for this would be nice. I do not see any reason to keep the old values after the response with the invalid values is rendered again.

Cheers,
Michael

]]> Kommentar zu How to wrap a ValueExpression in EL 1.0 and 2.2 von somebody http://www.jakobk.com/2010/12/how-to-wrap-a-valueexpression-in-el-1-0-and-2-2/comment-page-1/#comment-690 somebody Mon, 25 Jul 2011 15:10:59 +0000 http://www.jakobk.com/?p=170#comment-690 If I remember the the jvm spec correctly than this is not covered by the spec and therefore might not work on certain other jvm/classloader impls (ibm, jrockit, openjdk). Take a look here #7, 12.4.2 http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44459 I would be rather defensive using such tricks... If I remember the the jvm spec correctly than this is not covered by the spec and therefore might not work on certain other jvm/classloader impls (ibm, jrockit, openjdk). Take a look here #7, 12.4.2 http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44459
I would be rather defensive using such tricks…

]]> Kommentar zu JSF 2.0: View parameters von Stateless vs Stateful JSF view parameters | J-Development http://www.jakobk.com/2010/04/jsf-2-0-view-parameters/comment-page-1/#comment-614 Stateless vs Stateful JSF view parameters | J-Development Sun, 03 Jul 2011 17:25:35 +0000 http://www.jakobk.com/?p=82#comment-614 [...] otherwise the initial URL parameter would be ‘lost’ after the first postback. See e.g. JSF 2.0: View parameters, where the author seems really happy with this behavior: The UIViewParameter component also stores [...] [...] otherwise the initial URL parameter would be ‘lost’ after the first postback. See e.g. JSF 2.0: View parameters, where the author seems really happy with this behavior: The UIViewParameter component also stores [...]

]]> Kommentar zu Validation errors and bean updates von Jakob Korherr http://www.jakobk.com/2010/06/validation-errors-and-bean-updates/comment-page-1/#comment-551 Jakob Korherr Mon, 06 Jun 2011 22:35:05 +0000 http://www.jakobk.com/?p=107#comment-551 Hi Pat, It depends. Calling resetValue() itself is very cheap, but, for example, performing a full tree visit to reach every input component (in order to call resetValue()) is pretty expensive. Using a PreRenderComponentEvent is a very good idea! This is just as good as binding the components to a request-scoped binding bean and accessing them in the setter(s), I guess! Regards, Jakob Hi Pat,

It depends. Calling resetValue() itself is very cheap, but, for example, performing a full tree visit to reach every input component (in order to call resetValue()) is pretty expensive.

Using a PreRenderComponentEvent is a very good idea! This is just as good as binding the components to a request-scoped binding bean and accessing them in the setter(s), I guess!

Regards,
Jakob

]]> Kommentar zu Validation errors and bean updates von PatMey http://www.jakobk.com/2010/06/validation-errors-and-bean-updates/comment-page-1/#comment-550 PatMey Mon, 06 Jun 2011 19:50:09 +0000 http://www.jakobk.com/?p=107#comment-550 Hey Jakob, Is it a "performance killer" to perform reset values in PhaseListener as you wrote? You can use for that a PreRenerComponent Event at setting the value. Greets, Pat Hey Jakob,

Is it a “performance killer” to perform reset values in PhaseListener as you wrote? You can use for that a PreRenerComponent Event at setting the value.
Greets,
Pat

]]> Kommentar zu create annotation instances at runtime von Bob McWhirter http://www.jakobk.com/2010/09/create-annotation-instances-at-runtime/comment-page-1/#comment-456 Bob McWhirter Tue, 29 Mar 2011 01:19:08 +0000 http://www.jakobk.com/?p=146#comment-456 We're going to be using the AnnotationInstanceProvider within TorqueBox, since it's rather difficult to create annotations from Ruby. Thanks, Dan! We’re going to be using the AnnotationInstanceProvider within TorqueBox, since it’s rather difficult to create annotations from Ruby.

Thanks, Dan!

]]>