Prime Community Forum

There are plans to drop dynamiccontentstreamer and use our custom ResourceHandler to do this stuff for 3.0.

Ok now I was able to reproduce this. I was using Tomcat 7.0.4. Thanks for posting your filter, I'll include this in my project!

There are plans to drop dynamiccontentstreamer and use our custom ResourceHandler to do this stuff for 3.0.
http://code.google.com/p/primefaces/iss ... il?id=2073

Glad to hear that (I would vote to reclassify as a bug or at least assign higher priority). I am still willing to send you the exploit if you are interested.

The following code could be used to prevent the injection until this issue is resolved:

Yes, simple solution.

However, if one uses JSF's error handling mechanism the way the error page is also served by JSF, then the result of the exploit still might be shown.

So, in our case, we made a redirection to a page not served by JSF.

Just a heads up...

Cheers,

However, if one uses JSF's error handling mechanism the way the error page is also served by JSF, then the result of the exploit still might be shown.

Very good point. We use JSF error pages... however the ERROR dispatch is also caught (second time) by the protecting servlet filter. We end up with showing the error page of the servlet container.

I assume this issue isn't fixed in the elite version 3.5.28, right?

franz.pfeifer wrote: ↑

18 Jul 2017, 09:16

I assume this issue isn't fixed in the elite version 3.5.28, right?

If you check issue linked by Optimus (https://code.google.com/archive/p/prime ... ssues/2073), it was fixed for 3.0 release.