We have a web application, which uses weblogic jsf 1.2 implementation from deployable-libraries(jsf-1.2.war). We started to use weblogic jsf impl after having some problems with compatibility of packed jsf-impl and weblogic 10.3.4.
So the problem is that, we have outputLink with several params, these params' values could contain spacial chars, so we explicitly encode them(we have taglib function for this purpose), but jsf impl on weblogic 10.3.4 also encodes these chars, so we have double encoded link URL. Does anybody know is there a possibility to disable this option on weblogic and encode params only manually.
Just do not encode it yourself with a custom taglib. The <f:param> will already implicitly do it.
<h:outputLink value="page.jsf">
<h:outputText value="Click" />
<f:param name="foo" value="#{bean.foo}" />
<f:param name="bar" value="#{bean.bar}" />
</h:outputLink>
That's all. The #{bean.foo} and #{bean.bar} in above example can just return the raw and unencoded string value.
Update as per the comments, this suggests that those two servers JBoss AS 4.2.3 and WebLogic 10.3.2 are using a specific JSF implementation/version which exposes a bug in URL-encoding of <f:param>. As far, I can only find the following related reports (it's not clear if you're using MyFaces or Mojarra, so I searched in both):
Mojarra (a.k.a. Sun RI): http://java.net/jira/browse/JAVASERVERFACES-791 fixed in 1.2_10.
MyFaces: https://issues.apache.org/jira/browse/MYFACES-1832 fixed in 1.1.6 and > 1.2.2(?).
I recommend to replace/upgrade the JSF version of the servers in question to a newer version than the ones mentioned in those reports, or to ship JSF libraries along with the webapp itself and add web.xml context parameters to instruct the server to use the webapp bundled JSF instead.
Related
I am looking for information about XSS in web applications that use JavaServer Faces.
I found paper Proofing Java EE, JSP, and JSF Applications
On page 48 (slide 36) called "Escaping in JSF" there is code snippet:
<f:verbatim value="#{foo}"/>
Also on page 50 (slide 38) there is description "Tags that don't escape enough" for <f:verbatim> and <h:outputlink>.
I can't reproduce XSS inside <f:verbatim> tag when use EL in web app with Facelets, probably because of auto escaping in JSF components:
CSRF, XSS and SQL Injection attack prevention in JSF
"JSF is designed to have builtin XSS prevention. You can safely redisplay all user-controlled input (request headers (including cookies!), request parameters (also the ones which are saved in DB!) and request bodies (uploaded text files, etc)) using any JSF component."
It seems that information in paper is for JSF before 2.0.
Also I found this:
f:verbatim tag stops working when inside a dataTable
"The <f:verbatim> tag is intented to hold plain text/HTML, not JSF components nor EL expressions."
So I don't understand how this tag could be used for XSS if it doesn't work with dynamic data from request or beans.
So I have 2 questions:
Is <f:verbatim> tag safe to XSS when use tainted input from user in web application built on JSF 2.0+ and Facelets?
In which situation <f:verbatim> tag "don't escape enough" in web applications built on JSF?
Example for JSF 2.0 and Facelets:
<h:form>
testform1#{testBean.getXSS(9)}testform1
testform2<h:outputText value="#{testBean.getXSS(10)}" escape="false" />testform2
<f:verbatim escape="false">
aaa#{testBean.getXSS(11)}bbb
ccc
<span>
#{testBean.getXSS(12)}test
<a>link#{testBean.getXSS(13)}</a>
#{testBean.getXSS(14)}
</span>
ddd
<script>alert(15)</script>
eee
<h:outputText value="#{testBean.getXSS(16)}" escape="false" />
ddd
</f:verbatim>
</h:form>
Test method in bean:
public String getXSS(Integer index) {
return ("<script>alert(" + Integer.toString(index) + ")</script>");
}
Output:
testform1<script>alert(9)</script>testform1
testform2<script>alert(10)</script>testform2
aaa<script>alert(11)</script>bbb
ccc
<span>
<script>alert(12)</script>test
<a>link<script>alert(13)</script></a>
<script>alert(14)</script>
</span>
ddd
<script>alert(15)</script>
eee
ddd
<input type="hidden" name="javax.faces.ViewState" id="j_id1:javax.faces.ViewState:1" value="-7832412971090198368:1934231343887166207" autocomplete="off" />
</form>
The referenced article/slide is from 8 june 2009. That's the era of JSF 1.2 and JSP.
JSF 2.0 was introduced december 2009. JSP was since then deprecated and replaced by Facelets. <f:verbatim> was deprecated because it's entirely useless in Facelets. JSF 2.0 on Facelets is designed to have implicit XSS prevention over all place (except of one Mojarra specific bug which is already fixed in 2.2.6, see 1st "See also" link below for detail).
In other words, ignore that article/slide. It doesn't apply on JSF 2.x at all. In future resources, doublecheck the publish date and whether the versions being treated match yours.
See also:
CSRF, XSS and SQL Injection attack prevention in JSF
Iterate <f:verbatim> within <ui:repeat>
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
This is a peculiar thing that i have observed. I have a h:commandLink inside a h:datatable. The commandLink code looks like this :
<h:commandLink value="#{grease.greaseId}" rendered="#{MyBean.btnName == 'ending'}" id="greaseNo1" action="#{MyBean.greaseIdMonitored}" immediate="true">
<f:param name="id" value="#{grease.greaseId}" />
</h:commandLink>
This is rendered as the following html :
<script src="/grease/faces/javax.faces.resource/oamSubmit.js?ln=org.apache.myfaces" type="text/javascript"><!--
//--></script><a id="myForm:dt1:0:greaseNo1" onclick="return myfaces.oam.submitForm('myForm','myForm:dt1:0:greaseNo1',null,[['id','mylot-256987']]);" href="#">mylot-256987</a>
What i don't understand is why is there a reference to org.apache.myfaces ? I am not using myfaces, rather it's ibm faces.
Any help in understanding the problem is appreciated .
From the WAS documentation:
In WebSphere® Application Server V8.0 and later, the default JavaServer Faces (JSF) implementation has changed to MyFaces.
There is no IBM Faces as such (though IBM has proprietary component libraries and extensions.) IBM has always based their JSF implementations on either the licensed reference implementation or open source software. See the WAS 8.5 documentation on how to configure the platform's JSF engine.
the oamSubmit.js file is located inside a resource folder, called org.apache.myfaces
Take a look at the implementation file.
I'm using exaples from the official Java EE tutorial In which contains the follow:
<h:panelGrid columns="2"
headerClass="list-header"
styleClass="list-background"
rowClasses="list-row-even, list-row-odd"
summary="#{bundle.CustomerInfo}"
title="#{bundle.Checkout}"
role="presentation">
But compiler says that attribute role is not defined for h:panelGrid component. How to fix this?
That attribute was introduced in JSF 2.2. As evidence, the role attribute is mentioned in JSF 2.2 <h:panelGrid> documentation, but not in JSF 2.1 <h:panelGrid> documentation.
Your question history confirms that you're using JSF 2.2 on GlassFish 4.0, so this compiler warning is actually wrong. This is not exactly a JSF problem, but an IDE problem. The IDE is somehow thinking that you're not using JSF 2.2, but JSF 2.1 or older. I.e. your toolset is working against you. You didn't mention which IDE you're using, so it's not possible to post the right answer.
If the project runs fine and the JSF page produces the right HTML output (i.e. the role attribute actually ends up in generated HTML <table> element as you can see by rightclick, View Source in webbrowser), then everything is well and it's just the IDE who's pretending to be smarter than it actually is.
I'd start peeking around in IDE project's properties to check if the JSF versions are all right. The JSF facet in project's properties must be set to version 2.2, not lower. The faces-config.xml must be declared conform JSF 2.2, not lower.
We are migrating JSF 1.1 (MyFaces) project to JSF 2. The idea is to migrate periodically by keeping both JSP and XHTML together for some time. We use many ajax4jsf-1.1.1 tags in JSP pages. We don't use RichFaces. After configuring the system to JSF 2 (with all config changes mentioned in tutorial by Balusc) When tried to access the JSP page with ajax4jsf.jar in classpath, we get an exception:
Caused by: java.lang.IllegalStateException: setViewHandler may not be executed after a lifecycle request has been completed
at org.apache.myfaces.application.ApplicationImpl.setViewHandler(ApplicationImpl.java:853)
at org.ajax4jsf.framework.ajax.InitPhaseListener.beforePhase(InitPhaseListener.java:92)
at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:131)
It looks ajax4jsf.jar is not compatible with JSF 2. Looks some issue with LifeCycle configuration.
Is there any way we can make a4j work with JSF 2 JSPs? I know when we use XHTML we don't need all this.
Get rid of Ajax4jsf 1.x altogether. It's indeed not compatible with JSF2. Instead, JSF2 offers a new main ajax tag <f:ajax> which covers all the core functionality as previously offered by Ajax4jsf 1.x.
If upgrading to RichFaces 4 is not an option (because, as you said yourself, you aren't using RichFaces components anywhere), then just remove Ajax4jsf 1.x and replace all <a4j:xxx> tags by standard JSF2 equivalents.
<a4j:ajaxListener>: use <f:ajax listener>.
<a4j:keepAlive>: just put managed bean in the view scope by #ViewScoped.
<a4j:log>: use jsf.ajax.addOnEvent() or jsf.ajax.addOnError() in JS context.
<a4j:commandLink>: just nest <f:ajax> inside <h:commandLink>.
<a4j:outputPanel>: use <h:panelGroup> and remember to include its ID in <f:ajax render> or PrimeFaces <p:outputPanel>.
<a4j:repeat>: just use standard <ui:repeat>.
<a4j:form>: just use <h:form>, it will autorecognize <f:ajax>.
<a4j:htmlCommandLink>: just nest <f:ajax> inside <h:commandLink>.
<a4j:jsFunction>: just use standard <h:commandScript>. It was however introduced late in JSF 2.3. If you can't upgrade to JSF 2.3 then consider OmniFaces <o:commandScript> or PrimeFaces <p:remoteCommand>.
<a4j:region>: just use <f:ajax execute>, you can even wrap <f:ajax> around a group of components.
<a4j:loadBundle>: just use standard <f:loadBundle>.
<a4j:status>: use jsf.ajax.addOnEvent() or jsf.ajax.addOnError() in JS context.
<a4j:actionparam>: just use standard <f:param>.
<a4j:loadScript>: just use standard <h:outputScript>.
<a4j:mediaOutput>: no replacement. Consider PrimeFaces <p:media>.
<a4j:poll>: no replacement. Consider OmniFaces <o:commandScript> or PrimeFaces <p:poll>.
<a4j:commandButton>: just nest <f:ajax> inside <h:commandButton>.
<a4j:include>: just use standard <ui:include>.
<a4j:loadStyle>: just use standard <h:outputStylesheet>.
<a4j:support>: just use standard <f:ajax>.
You also need to rename/rewrite JSP files to Facelets files. In simple cases, this is usually just a matter of changing root declarations and file extensions. Facelets makes it easier to replace all duplicated code by a single template. The following answer applies:
Migrating from JSF 1.2 to JSF 2.0
I have a <h:inputText> with an event listener like following:
<h:inputText valueChangeListener="#{myBean.handle}"/>
I would like to put it in a tag file which is to be used as follows:
<my:itext changeListener="#{myBean.handle}" />
With inside the tag file:
<h:inputText valueChangeListener="#{changeListener}" />
However it's evaluating it as a property instead of as a listener method. How can I pass the listener method into a tag file?
You can by design not pass method expressions as a tag file attribute. You basically need to convert the ValueExpression to a MethodExpression inside the tag file.
For JSF 2.x Facelets, this can be solved using OmniFaces <o:methodParam>.
<o:methodParam name="changeListenerMethod" value="#{changeListener}" />
<h:inputText valueChangeListener="#{changeListenerMethod}" />
However, for old and deprecated Facelets 1.x or JSP 2.x there is no existing solution. The OmniFaces <o:methodParam> is however open source, you should be able to copy and alter it for Facelets 1.x or JSP if necessary.
Note that when you're actually already using JSF 2.x, you could also use a composite component instead. This supports passing method expressions as <cc:attribute method-signature>. For JSF 1.x you can alternatively also create a real custom component, but that's a bit more work than just some XML.