Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.3.24, 2.3.28
-
None
-
Operating System: Windows 7(N/A).
Application Server: Tomcat 6(any server running on JRE1.6 or before JRE).
Java: jdk1.5.0.11.
Developloment Framework: Struts 2.3.28, 2.3.24.1.
Browser: FireFox 38.0.1.
Description
<s:include> tag and JspTemplateEngine use
org.apache.struts2.components.Include#include.
(I use <s:include> tag.)
The included page is encoded by response character encoding(default is ISO-8859-1(ServletResponse)).
But encoded result is decoded by 'request' character encoding(default is UTF-8(@Inject(StrutsConstants.STRUTS_I18N_ENCODING))).
org.apache.struts2.components.Include use wrong character encoding.
If request and response character encoding are specifically configured to same character encoding,
there are no problems.
However, if request and response character encoding are not specifically configured,
(or <%@ page contentType="text/html; charset=ISO-8859-1" %> is written in JSP only,)
the included page is encoded by ISO-8859-1 and decoded by UTF-8.
By using old decoding rule of UTF-8(enable on JRE1.5.0_16 or before and JRE1.6.0_10 or before),
XSS vulnerability occurs, even if input value is sanitized when output as <s:textfield>.
Please refer to description of WW-4507 for sample attack parameter information.
Please refer to my comment written in WW-4507 for more analysis information.
P.S.
I'm thinking WW-4507(S2-028) has been caused by this.
(WW-4507(S2-028) is not fixed in 2.3.28.)
But if it's different, please show the hidden reproduction condition to WW-4507.