Uploaded image for project: 'Struts 2'
  1. Struts 2
  2. WW-4507

Struts 2 XSS vulnerability with <s:textfield>

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.16.3
    • Fix Version/s: 2.3.28, 2.5
    • Component/s: None
    • 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

      Description

      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

        Issue Links

          Activity

          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Struts-JDK7-master #495 (See https://builds.apache.org/job/Struts-JDK7-master/495/)
          WW-4507 - clone Tomcat UDecoder and use it for in query string handling (lukaszlenart: rev 76f188406eb9f17a06afcb5f49f0c44d749da0d2)

          • core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java
          • core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java
          • core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          • core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
            WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in (lukaszlenart: rev 4720f46a63caaf9db97ba27dc51ac5ad21e66bdc)
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Struts-JDK7-master #495 (See https://builds.apache.org/job/Struts-JDK7-master/495/ ) WW-4507 - clone Tomcat UDecoder and use it for in query string handling (lukaszlenart: rev 76f188406eb9f17a06afcb5f49f0c44d749da0d2) core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in (lukaszlenart: rev 4720f46a63caaf9db97ba27dc51ac5ad21e66bdc) core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          Hide
          taromaru Naozumi Taromaru added a comment -

          I created new issue.
          https://issues.apache.org/jira/browse/WW-4625

          If WW-4507 and WW-4625 are different XSS vulnerability,
          please write the hidden reproduction condition of WW-4507 to this(WW-4507) page.

          Show
          taromaru Naozumi Taromaru added a comment - I created new issue. https://issues.apache.org/jira/browse/WW-4625 If WW-4507 and WW-4625 are different XSS vulnerability, please write the hidden reproduction condition of WW-4507 to this( WW-4507 ) page.
          Hide
          taromaru Naozumi Taromaru added a comment -

          > 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.)

          Show
          taromaru Naozumi Taromaru added a comment - > 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.)
          Hide
          rgielen Rene Gielen added a comment -

          Naozumi Taromaru I'm not sure if my analysis above is completely wrong. However, this is an interesting finding and I see your point.

          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.

          Users are responsible for configuring consistent encoding, that is having page encoding match their Struts 2 setup. The best solution to your point is IMO to use consistent encoding both in page encoding, connector setup and struts.i18n.encoding. Besides that, we recommend to use UTF-8 only. See also https://struts.apache.org/docs/s2-028.html

          This particular issue WW-4507 deals with a platform problem. After talking to the Tomcat guys, we agreed to add additional safety by using their encoding logic where applies to framework calls. But we also said: this is a platform issue, please move to a supported JRE. There is a reason why the old decoding rule was ditched, so we can only encourage our users to move to a modern and less buggy environment.

          If you feel like the Include component should use response.getCharacterEncoding rather than struts.i18n.encoding, you are invited to open a new issue to let us discuss this, along with possible implications.

          Show
          rgielen Rene Gielen added a comment - Naozumi Taromaru I'm not sure if my analysis above is completely wrong. However, this is an interesting finding and I see your point. 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. Users are responsible for configuring consistent encoding, that is having page encoding match their Struts 2 setup. The best solution to your point is IMO to use consistent encoding both in page encoding, connector setup and struts.i18n.encoding. Besides that, we recommend to use UTF-8 only. See also https://struts.apache.org/docs/s2-028.html This particular issue WW-4507 deals with a platform problem. After talking to the Tomcat guys, we agreed to add additional safety by using their encoding logic where applies to framework calls. But we also said: this is a platform issue, please move to a supported JRE. There is a reason why the old decoding rule was ditched, so we can only encourage our users to move to a modern and less buggy environment. If you feel like the Include component should use response.getCharacterEncoding rather than struts.i18n.encoding, you are invited to open a new issue to let us discuss this, along with possible implications.
          Hide
          taromaru Naozumi Taromaru added a comment -

          The analysis of Rene (14/Jan/16 16:04) is wrong.

          This vulnerability's one of cause is not JRE 1.5's URLDecoder, but old decoding rule of UTF-8.
          (This vulnerability's another cause is org.apache.struts2.components.Include wrong implementation.)

          byte array

          { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }
          decoding to String { U+0022 = '"' }
          is old decoding rule of UTF-8.

          Affected components are all decoding API of JDK.
          URLDecoder is one of them, but it's not all of them.
          For example...
          InputStreamReader is one of them too.
          new String(byte[], ...) is one of them too.

          Therefore even if all codes using URLDecoder are fixed,
          this vulnerability isn't fixed.

          byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }

          decoding to String

          { U+0022 = '"' }
          is old decoding rule of UTF-8.

          But,
          String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }
          changing to
          String { U+0022 = '"' }

          is caused by
          org.apache.struts2.components.Include wrong implementation
          and old decoding rule of UTF-8.

          If org.apache.struts2.components.Include wrong implementation dosen't exist,
          byte array

          { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }

          in HTTP response.
          (If XSS succeed, it's vulnerability of web browser.
          When using a modern web browser at least, XSS doesn't succeed.)

          org.apache.struts2.components.Include wrong implementation is
          pageResponse.getContent().writeTo(writer, encoding);
          and
          pageResponse.getContent().writeTo(writer, systemEncoding); .

          If
          <%@ page contentType="text/html" %>
          or
          <%@ page contentType="text/html; charset=ISO-8859-1" %>
          is written in JSP,
          "pageResponse.getContent()" include ISO-8859-1(response.getCharacterEncoding()) byte sequense.
          But org.apache.struts2.components.Include use another CharacterEncoding(default is UTF-8) when decoding.

          Therefore
          pageResponse.getContent().writeTo(writer, response.getCharacterEncoding());
          is correct.

          Show
          taromaru Naozumi Taromaru added a comment - The analysis of Rene (14/Jan/16 16:04) is wrong. This vulnerability's one of cause is not JRE 1.5's URLDecoder, but old decoding rule of UTF-8. (This vulnerability's another cause is org.apache.struts2.components.Include wrong implementation.) byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } decoding to String { U+0022 = '"' } is old decoding rule of UTF-8. Affected components are all decoding API of JDK. URLDecoder is one of them, but it's not all of them. For example... InputStreamReader is one of them too. new String(byte[], ...) is one of them too. Therefore even if all codes using URLDecoder are fixed, this vulnerability isn't fixed. byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } decoding to String { U+0022 = '"' } is old decoding rule of UTF-8. But, String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } changing to String { U+0022 = '"' } is caused by org.apache.struts2.components.Include wrong implementation and old decoding rule of UTF-8. If org.apache.struts2.components.Include wrong implementation dosen't exist, byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } in HTTP response. (If XSS succeed, it's vulnerability of web browser. When using a modern web browser at least, XSS doesn't succeed.) org.apache.struts2.components.Include wrong implementation is pageResponse.getContent().writeTo(writer, encoding); and pageResponse.getContent().writeTo(writer, systemEncoding); . If <%@ page contentType="text/html" %> or <%@ page contentType="text/html; charset=ISO-8859-1" %> is written in JSP, "pageResponse.getContent()" include ISO-8859-1(response.getCharacterEncoding()) byte sequense. But org.apache.struts2.components.Include use another CharacterEncoding(default is UTF-8) when decoding. Therefore pageResponse.getContent().writeTo(writer, response.getCharacterEncoding()); is correct.
          Hide
          victorsosa victorsosa added a comment -

          Please check Rene comment

          Show
          victorsosa victorsosa added a comment - Please check Rene comment
          Hide
          taromaru Naozumi Taromaru added a comment -

          I reproduced this issue. I use Struts 2.3.24.1 and 2.3.28.
          Even Struts 2.3.28 isn't fixed yet.

          This issue is that
          %fc%80%80%80%80%a2 become '"' after <s:textfield> tag's process.
          (If %fc%80%80%80%80%a2 become '"' before <s:textfield> tag's process, '"' become & quot; by <s:textfield> tag's process.)

          The cause of this issue is
          org.apache.struts2.components.Include#include.
          (It's used by <s:include> and JspTemplateEngine.)

          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#include use wrong character encoding when decoding.

          See
          org.apache.struts2.components.Include$PageResponse#getWriter
          org.apache.struts2.components.Include#include


          server.xml(Tomcat)
          default.

          struts.xml:
          <constant name="struts.i18n.encoding" value="..." /> is not set.

          sample.jsp:
          <%@ page contentType="text/html" %>
          ...
          <s:include value="/WEB-INF/jsp/example/included.jsp" />

          included.jsp:
          <s:textfield name="myinput" id="myinput"></s:textfield>

          Query parameter:
          myinput=%fc%80%80%80%80%a2

          1. Query parameter is decoded by Tomcat.(ISO-8859-1)
          %fc%80%80%80%80%a2 -> String

          { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }

          2. <s:textfield> tag outputs String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }

          String

          { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }
          (It dosen't contain U+0022( = '"').)

          3. String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }

          is encoded by org.apache.struts2.components.Include(ISO-8859-1)
          String

          { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 }

          -> byte array

          { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }

          4. byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }

          is decoded by org.apache.struts2.components.Include(UTF-8)
          byte array

          { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 }

          -> String

          { U+0022 = '"' }

          (use JDK 1.5.0_11)

          Show
          taromaru Naozumi Taromaru added a comment - I reproduced this issue. I use Struts 2.3.24.1 and 2.3.28. Even Struts 2.3.28 isn't fixed yet. This issue is that %fc%80%80%80%80%a2 become '"' after <s:textfield> tag's process. (If %fc%80%80%80%80%a2 become '"' before <s:textfield> tag's process, '"' become & quot; by <s:textfield> tag's process.) The cause of this issue is org.apache.struts2.components.Include#include. (It's used by <s:include> and JspTemplateEngine.) 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#include use wrong character encoding when decoding. See org.apache.struts2.components.Include$PageResponse#getWriter org.apache.struts2.components.Include#include server.xml(Tomcat) default. struts.xml: <constant name="struts.i18n.encoding" value="..." /> is not set. sample.jsp: <%@ page contentType="text/html" %> ... <s:include value="/WEB-INF/jsp/example/included.jsp" /> included.jsp: <s:textfield name="myinput" id="myinput"></s:textfield> Query parameter: myinput=%fc%80%80%80%80%a2 1. Query parameter is decoded by Tomcat.(ISO-8859-1) %fc%80%80%80%80%a2 -> String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } 2. <s:textfield> tag outputs String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } (It dosen't contain U+0022( = '"').) 3. String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } is encoded by org.apache.struts2.components.Include(ISO-8859-1) String { U+00fc, U+0080, U+0080, U+0080, U+0080, U+00a2 } -> byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } 4. byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } is decoded by org.apache.struts2.components.Include(UTF-8) byte array { 0xfc, 0x80, 0x80, 0x80, 0x80, 0xa2 } -> String { U+0022 = '"' } (use JDK 1.5.0_11)
          Hide
          lukaszlenart Lukasz Lenart added a comment -

          Great, thanks!

          Show
          lukaszlenart Lukasz Lenart added a comment - Great, thanks!
          Hide
          rgielen Rene Gielen added a comment - - edited

          Lukasz Lenart done, sorry for not resolving the issue

          Show
          rgielen Rene Gielen added a comment - - edited Lukasz Lenart done, sorry for not resolving the issue
          Hide
          lukaszlenart Lukasz Lenart added a comment -

          Rene Gielen is it done?

          Show
          lukaszlenart Lukasz Lenart added a comment - Rene Gielen is it done?
          Hide
          rgielen Rene Gielen added a comment -

          We can confirm now that this is a platform issue. Especially JRE 1.5's URLDecoder implementation seems to be broken to the point that this non-spec encoding isn't rejected / filtered. The current implementation of URLDecoder in JRE 1.8 seems to address all issues in this space, thus it is highly recommended to upgrade to JRE 1.8 for production environments

          Some containers such as Tomcat and Jetty circumvent broken JRE URLDecoder implementations by providing their own decoder for dealing with request parameters. JBoss 4.2.1 does not seem to be in this space.

          While upcoming Struts 2.3.25 will have improved handling for some edge cases where URLDecoder is called by using Tomcat's UDecoder solution, this will not address the specific issue mentioned here. To address this, one will either have to upgrade the JRE to a version with non-broken URLDecoder implementation (preferably JRE 1.8) or a container that circumvents calls to broken URLDecoder implementation calls in it's Servlet API implementation.

          Show
          rgielen Rene Gielen added a comment - We can confirm now that this is a platform issue. Especially JRE 1.5's URLDecoder implementation seems to be broken to the point that this non-spec encoding isn't rejected / filtered. The current implementation of URLDecoder in JRE 1.8 seems to address all issues in this space, thus it is highly recommended to upgrade to JRE 1.8 for production environments Some containers such as Tomcat and Jetty circumvent broken JRE URLDecoder implementations by providing their own decoder for dealing with request parameters. JBoss 4.2.1 does not seem to be in this space. While upcoming Struts 2.3.25 will have improved handling for some edge cases where URLDecoder is called by using Tomcat's UDecoder solution, this will not address the specific issue mentioned here. To address this, one will either have to upgrade the JRE to a version with non-broken URLDecoder implementation (preferably JRE 1.8) or a container that circumvents calls to broken URLDecoder implementation calls in it's Servlet API implementation.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Struts-JDK7-master #404 (See https://builds.apache.org/job/Struts-JDK7-master/404/)
          WW-4507 - clone Tomcat UDecoder and use it for in query string handling (rgielen: rev 72471d7075681bea52046645ad7aa34e9c53751e)

          • core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java
          • core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java
          • core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java
            WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in (rgielen: rev a89bbe22cd2461748d595a89a254de888a415e6c)
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Struts-JDK7-master #404 (See https://builds.apache.org/job/Struts-JDK7-master/404/ ) WW-4507 - clone Tomcat UDecoder and use it for in query string handling (rgielen: rev 72471d7075681bea52046645ad7aa34e9c53751e) core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in (rgielen: rev a89bbe22cd2461748d595a89a254de888a415e6c) core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Struts-JDK6-support-2.3 #955 (See https://builds.apache.org/job/Struts-JDK6-support-2.3/955/)
          WW-4507 - clone Tomcat UDecoder and use it for in query string handling (rgielen: rev 5421930b49822606792f36653b17d3d95ef106f9)

          • core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java
          • core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java
          • core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java
          • core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java
          • core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Struts-JDK6-support-2.3 #955 (See https://builds.apache.org/job/Struts-JDK6-support-2.3/955/ ) WW-4507 - clone Tomcat UDecoder and use it for in query string handling (rgielen: rev 5421930b49822606792f36653b17d3d95ef106f9) core/src/main/java/org/apache/struts2/views/util/DefaultUrlHelper.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Ascii.java core/src/main/java/org/apache/struts2/util/tomcat/buf/ByteChunk.java core/src/main/java/org/apache/struts2/util/tomcat/buf/HexUtils.java core/src/main/java/org/apache/struts2/util/tomcat/buf/StringCache.java core/src/main/java/org/apache/struts2/util/tomcat/buf/UDecoder.java core/src/main/java/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.java core/src/main/java/org/apache/struts2/util/URLDecoderUtil.java core/src/main/java/org/apache/struts2/util/tomcat/buf/MessageBytes.java core/src/test/java/org/apache/struts2/util/URLDecoderUtilTest.java core/src/main/java/org/apache/struts2/util/tomcat/buf/CharChunk.java core/src/main/java/org/apache/struts2/util/tomcat/buf/B2CConverter.java core/src/main/java/org/apache/struts2/util/tomcat/buf/Utf8Decoder.java core/src/main/java/org/apache/struts2/dispatcher/mapper/RestfulActionMapper.java
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit a89bbe22cd2461748d595a89a254de888a415e6c in struts's branch refs/heads/master from Rene Gielen
          [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=a89bbe2 ]

          WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in Struts

          Show
          jira-bot ASF subversion and git services added a comment - Commit a89bbe22cd2461748d595a89a254de888a415e6c in struts's branch refs/heads/master from Rene Gielen [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=a89bbe2 ] WW-4507 - adjust Tomcat url decoding code to Log4j 2 logging used in Struts
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 72471d7075681bea52046645ad7aa34e9c53751e in struts's branch refs/heads/master from Rene Gielen
          [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=72471d7 ]

          WW-4507 - clone Tomcat UDecoder and use it for in query string handling
          (cherry picked from commit 5421930)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 72471d7075681bea52046645ad7aa34e9c53751e in struts's branch refs/heads/master from Rene Gielen [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=72471d7 ] WW-4507 - clone Tomcat UDecoder and use it for in query string handling (cherry picked from commit 5421930)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5421930b49822606792f36653b17d3d95ef106f9 in struts's branch refs/heads/support-2-3 from Rene Gielen
          [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=5421930 ]

          WW-4507 - clone Tomcat UDecoder and use it for in query string handling

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5421930b49822606792f36653b17d3d95ef106f9 in struts's branch refs/heads/support-2-3 from Rene Gielen [ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=5421930 ] WW-4507 - clone Tomcat UDecoder and use it for in query string handling
          Hide
          rgielen Rene Gielen added a comment -

          I have tried to reproduce this with a page encoding of ISO-8859-1 on Tomcat 7, JDK 8, Struts 2.3.24.1, Chrome - to no success

          Just to clarify: can we confirm that this is no general issue with ISO-8859-1 page encoding usage? It looks to me like a very specific behaviour found in brian neisen's setup, including the usage of an older Struts version which is no longer supported due to security fix upgrade policy?

          Show
          rgielen Rene Gielen added a comment - I have tried to reproduce this with a page encoding of ISO-8859-1 on Tomcat 7, JDK 8, Struts 2.3.24.1, Chrome - to no success Just to clarify: can we confirm that this is no general issue with ISO-8859-1 page encoding usage? It looks to me like a very specific behaviour found in brian neisen 's setup, including the usage of an older Struts version which is no longer supported due to security fix upgrade policy?
          Hide
          lukaszlenart Lukasz Lenart added a comment -

          Thanks brian neisen - will prepare an announcement!

          Show
          lukaszlenart Lukasz Lenart added a comment - Thanks brian neisen - will prepare an announcement!
          Hide
          greaserscc@gmail.com brian neisen added a comment -

          Hi,

          The problem is related to the page encoding. 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.

          Thanks,

          Brian

          Show
          greaserscc@gmail.com brian neisen added a comment - Hi, The problem is related to the page encoding. 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. Thanks, Brian
          Hide
          angelwhu angelwhu added a comment -

          i use your environment .
          Application Server: JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts 2.3.16.3. Browser: FireFox 38.0.1 .
          but it only appear garbled and no any alert message. does it depend any other key environment ?
          and it is same to jetty , tomcat 7. no pop message.

          Show
          angelwhu angelwhu added a comment - i use your environment . Application Server: JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts 2.3.16.3. Browser: FireFox 38.0.1 . but it only appear garbled and no any alert message. does it depend any other key environment ? and it is same to jetty , tomcat 7. no pop message.
          Hide
          lukaszlenart Lukasz Lenart added a comment -

          Looks like issue is related to container and proper encoding, on Jetty I see this

          2015-09-01 08:31:32.593:WARN:oeju.UrlEncoded:org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte Be in state 0
          
          Show
          lukaszlenart Lukasz Lenart added a comment - Looks like issue is related to container and proper encoding, on Jetty I see this 2015-09-01 08:31:32.593:WARN:oeju.UrlEncoded:org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte Be in state 0
          Hide
          angelwhu angelwhu added a comment -

          struts version is 2.3.16.3. page encode is utf-8.

          Show
          angelwhu angelwhu added a comment - struts version is 2.3.16.3. page encode is utf-8.
          Hide
          lukaszlenart Lukasz Lenart added a comment -

          angelwhu Which Struts version do you use?

          Show
          lukaszlenart Lukasz Lenart added a comment - angelwhu Which Struts version do you use?
          Hide
          angelwhu angelwhu added a comment -

          Does it depend on the server ? i use tomcat 7, it doesn't work.

          Show
          angelwhu angelwhu added a comment - Does it depend on the server ? i use tomcat 7, it doesn't work.

            People

            • Assignee:
              rgielen Rene Gielen
              Reporter:
              greaserscc@gmail.com brian neisen
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development