[
https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217857#comment-15217857
]
Naozumi Taromaru commented on WW-4507:
--------------------------------------
> Historically we had many issues with solely relying on "standard" encoding
> querying functions like
> response.getCharacterEncoding(). That's why the struts.i18n.encoding property
> was introduced (originally even in
> webwork). With its help we force a user configurable encoding.
org.apache.struts2.components.Include$PageResponse#getWriter
use response.getCharacterEncoding() when encoding.
Therefore
org.apache.struts2.components.Include#include should use
response.getCharacterEncoding() when decoding.
I don't usually use Struts2,
but I'm using the same encoding of request and response.
I usually use UTF-8 or Windows-31J. (Because I'm Japanese.)
I don't usually use ISO-8859-1.
So I understand that ISO-8859-1 isn't used.
I'm interested in cause of this XSS vulnerability,
because it's helpful for other lib checking.
I judged that it was org.apache.struts2.components.Include's issue
from the following information.
1. Example url is:
[http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE]
(General query parameter is used. This parameter is decoded by AP Server.)
2. <s:textfield name="myinput" id="myinput"></s:textfield> is used.
(Input value is sanitized when output.)
3. an alert message is popped open in the browser
(XSS succeed.)
4. FireFox 38.0.1 is used.
(There is no old UTF-8 decoding rule issue in Browser.)
5. jdk1.5.0.11 is used.
(There is old UTF-8 decoding rule issue in JRE.)
6. "I was only able to reproduce when the page encoding was set to ISO-8859-1.
When the page encoding is set to UTF-8 this xss issue it not reproducable."
said Reporter(brian neisen).
Therefore I thought that Reporter(brian neisen) use <s:include> or
JspTemplateEngine.
I made a comment,
because I succeeded in reproduction when I use Struts 2.3.28(Alternative
Recommendation in S2-028).
Was there another issue which meets the condition above-mentioned?
If so, please tell me that hidden condition for reproduction.
If not so, Resolution of this issue should be changed to "Workaround" or "Won't
Fix",
and S2-028 information page should be modified.
> Besides that, we recommend to use UTF-8 only. See also
> https://struts.apache.org/docs/s2-028.html
"use UTF-8" is "Workaround" in this page.
If you recommend to use UTF-8 only even when Struts 2.3.28 is used,
this page should be modified.
("Alternatively upgrade to Struts 2.3.28" should be deleted.)
> But we also said: this is a platform issue, please move to a supported JRE.
If supported JRE dosen't contain the following JRE
･1.5.0_16 or before (using old UTF-8 decoding rule)
･1.6.0_10 or before (using old UTF-8 decoding rule)
and this issue is not fixed,
Resolution of this issue should be changed to "Workaround" or "Won't Fix",
and S2-028 information page should be modified.
("Alternatively upgrade to Struts 2.3.28" should be deleted.)
> Struts 2 XSS vulnerability with <s:textfield>
> ---------------------------------------------
>
> Key: WW-4507
> URL: https://issues.apache.org/jira/browse/WW-4507
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.3.16.3
> Environment: Operating System: Windows 7. Application Server:
> JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts
> 2.3.16.3. Browser: FireFox 38.0.1
> Reporter: brian neisen
> Assignee: Rene Gielen
> Labels: struts2, vulnerability, xss
> Fix For: 2.3.28, 2.5
>
>
> WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the
> <s:textfield> tag. When loading a url in a browser with some param name, in
> this case "myinput", and the jsp being loaded has the tag <s:textfield
> name="myinput" id="myinput"></s:textfield>, an alert message is popped open
> in the browser- which is WhiteHat's method of showing the vulnerability.
> Example url is:
> [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
