Wicket
  1. Wicket
  2. WICKET-1303

Slash separated URL's cannot have URL parameters with value containing forward slash '/'

    Details

    • Type: Wish Wish
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Later
    • Affects Version/s: 1.3.0-final
    • Fix Version/s: 1.5-RC1
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Tomcat 6.0.14, Firefox 2.0.0.11, Windows XP SP2

      Description

      There seems to be an issue with URL parameters encoded into path in form "/page/param1/val1" with handling parameter values with forward slash ('/'). The slash is correctly URL-encoded to entity '%2F' so that for example parameter key/value pair 'foo' => 'b/a/r' is encoded into url like: '/page/foo/b%2Fa%2Fr'. The problem is that Tomcat returns error or empty page with this url.

      I tested and researched a little bit and found out that this is Tomcat related issue. In versions >= 6.0.10 Tomcat does not allow entities '%2F' and '%5C in path by default so it responds with error (or empty page) when it encounters one of them in URL's path part. More information can be found on http://tomcat.apache.org/security-6.html, under header "Fixed in Apache Tomcat 6.0.10". I tried according to the document to turn system property org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true, to allow encoded slashes in path, and got the request with '%2F' in path through.

      I think that PageParameters in wicket should be easy to use, so that user does not have to worry about the contents of the parameter, so something should be done to this issue.

      I managed to get around this issue by double encoding the parameter values with URLEncoder. I encoded the PageParameter map parameter values with URLEncoder and replaced all occurences of '%' in resulting text with '=' before passing it forward. So only entity that is left to be encoded by the framework (AbstractRequestTargetUrlCodingStrategy) is '=' which becomes "%3D" so "foo" => "b/a/r" becomes encoded in URL like: "/page/foo/b%3D2Fa%3D2Fr". Decoding of URL is done by opposite operation sequence: framework decodes the parameter for me to form b=2Fa=2Fr and after that I replace '=' with '%' and the replaced string is further decoded with URLDecoder. Not very beautiful solution but seems to work as a quick fix and leaves non-special characters unaffected. As a little downside two extra characters are needed to encode every special character.

        Issue Links

          Activity

          Hide
          Martin Grigorov added a comment -

          Closing as "Later" because there was no activity for this issue for few years.

          Show
          Martin Grigorov added a comment - Closing as "Later" because there was no activity for this issue for few years.
          Hide
          Martin Grigorov added a comment -

          The real problem is that Tomcat uses encoded slash as path delimiter.

          From http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10:
          "Tomcat permits '\', '%2F' and '%5C' as path delimiters."

          I'm not sure why they do that... It sounds like they play friendly with the proxy servers.

          I find the suggestion to automatically double encode slashes in the path parameters as ugly. I guess we should do this only for Tomcat-like servers (JBoss included) and don't do it for Jetty, WebSphere, ... because they don't use %2F as delimiter.

          I don't have good solution for this, but the problem is not solved.

          Show
          Martin Grigorov added a comment - The real problem is that Tomcat uses encoded slash as path delimiter. From http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10: "Tomcat permits '\', '%2F' and '%5C' as path delimiters." I'm not sure why they do that... It sounds like they play friendly with the proxy servers. I find the suggestion to automatically double encode slashes in the path parameters as ugly. I guess we should do this only for Tomcat-like servers (JBoss included) and don't do it for Jetty, WebSphere, ... because they don't use %2F as delimiter. I don't have good solution for this, but the problem is not solved.
          Hide
          Noam Y. Tenne added a comment -

          This issue also occurs with JBoss 5+

          Show
          Noam Y. Tenne added a comment - This issue also occurs with JBoss 5+
          Hide
          Igor Vaynberg added a comment -

          our priority right now is to concentrate on bugs and get 1.4 out. you are more then welcome to provide a patch for this issue.

          Show
          Igor Vaynberg added a comment - our priority right now is to concentrate on bugs and get 1.4 out. you are more then welcome to provide a patch for this issue.
          Hide
          Andreas Sahlbach added a comment -

          I am currently contracted by Volkswagen. Do you know how hard it would be for me to ask the network division of VW to configure the tomcat and all three apaches along their proxy chain from their DMZ up to my application so that wicket works? Hehe, if I even mention that this change will weaken the security of the servers or if they would find out by themselves, this would be an totally impossible task. They would simply order me to change the framework.

          I totally agree that this is not a bug according to the RFC. But it is currently very inconvenient to use IMHO.

          You are right, forms are not directly affected, it's just a common case I think. In my case it was an "enter new article with description" form and a "create-new-article" with article id and article description. I think it's a pretty often used case that the form calls a page with the values of the form as parameters. And this will not work in these cases. Unfortunately it's a runtime user error. It looks like it works perfectly but will fail sometimes in productive environment. Yuk...

          Show
          Andreas Sahlbach added a comment - I am currently contracted by Volkswagen. Do you know how hard it would be for me to ask the network division of VW to configure the tomcat and all three apaches along their proxy chain from their DMZ up to my application so that wicket works? Hehe, if I even mention that this change will weaken the security of the servers or if they would find out by themselves, this would be an totally impossible task. They would simply order me to change the framework. I totally agree that this is not a bug according to the RFC. But it is currently very inconvenient to use IMHO. You are right, forms are not directly affected, it's just a common case I think. In my case it was an "enter new article with description" form and a "create-new-article" with article id and article description. I think it's a pretty often used case that the form calls a page with the values of the form as parameters. And this will not work in these cases. Unfortunately it's a runtime user error. It looks like it works perfectly but will fail sometimes in productive environment. Yuk...
          Hide
          Igor Vaynberg added a comment -

          btw, why are forms affected by this?

          Show
          Igor Vaynberg added a comment - btw, why are forms affected by this?
          Hide
          Igor Vaynberg added a comment -

          and in real life there are configuration options for both apache and tomcat that allow for this to work.

          Show
          Igor Vaynberg added a comment - and in real life there are configuration options for both apache and tomcat that allow for this to work.
          Hide
          Andreas Sahlbach added a comment -

          It's not "some serverlet container", it's Apache as well as Tomcat. And it's done on purpose for security reasons and because of this it is unlikely that they will change their behavior in the future.

          In fact IMHO it's not important if it's a bug or not. Just check out the consequences for wicket users if wicket does not change it's encoding. In this case every single wicket user has to check all of his forms. If it's possible that a user enters / or \ in one of the fields, the wicket developer cannot use the affected URL Encoders.
          The only other possibility would be that he double encodes his fields like the bug reporter did.

          Do you really think a framework should make life so hard for developers? Wouldn't it be nice if our framework-of-choice would solve this issue once and for everyone?

          There is RFC and there is real life. I strongly encourage to handle this in wicket.

          Show
          Andreas Sahlbach added a comment - It's not "some serverlet container", it's Apache as well as Tomcat. And it's done on purpose for security reasons and because of this it is unlikely that they will change their behavior in the future. In fact IMHO it's not important if it's a bug or not. Just check out the consequences for wicket users if wicket does not change it's encoding. In this case every single wicket user has to check all of his forms. If it's possible that a user enters / or \ in one of the fields, the wicket developer cannot use the affected URL Encoders. The only other possibility would be that he double encodes his fields like the bug reporter did. Do you really think a framework should make life so hard for developers? Wouldn't it be nice if our framework-of-choice would solve this issue once and for everyone? There is RFC and there is real life. I strongly encourage to handle this in wicket.
          Hide
          Igor Vaynberg added a comment -

          this is not a bug, we encode urls properly according to the RFC. some servlet containers do not respect that, it is a configuration issue there. we should consider doing something magical, but then its just adding magical code to wicket.

          Show
          Igor Vaynberg added a comment - this is not a bug, we encode urls properly according to the RFC. some servlet containers do not respect that, it is a configuration issue there. we should consider doing something magical, but then its just adding magical code to wicket.
          Hide
          Johan Compagner added a comment -

          So what would be a nice patch that goes around this tomcat issue but doesnt depend on tomcat or breaks any other container?

          Show
          Johan Compagner added a comment - So what would be a nice patch that goes around this tomcat issue but doesnt depend on tomcat or breaks any other container?
          Hide
          Mika Salminen added a comment -

          Solution I decided to use in production was to replace all '%' with '*' so that the URL is not touched by the framework encoder/decoder. This leaves the URL nice-looking and works with Tomcat 6.0.10 >=:

          Encoding:
          // encode the URL with url encoder
          String encodedText = URLEncoder.encode(text, "UTF-8");

          // replace all '*' (which is not encoded by URLEncoder) with corresponding entity code
          encodedText = encodedText.replaceAll("
          *", "%2A");

          // Replace all occurences of '%' with '*'
          encodedText = encodedText.replace('%', '*');

          Decoding:
          // replace all occurences of '*' with '%'
          String decodedText = encodedText.replace('*', '%');

          // decode with URLDecoder (decodes also occurences of "%2A' to '*'
          decodedText = URLDecoder.decode(decodedText, "UTF-8");

          Show
          Mika Salminen added a comment - Solution I decided to use in production was to replace all '%' with '*' so that the URL is not touched by the framework encoder/decoder. This leaves the URL nice-looking and works with Tomcat 6.0.10 >=: Encoding: // encode the URL with url encoder String encodedText = URLEncoder.encode(text, "UTF-8"); // replace all '*' (which is not encoded by URLEncoder) with corresponding entity code encodedText = encodedText.replaceAll(" *", "%2A"); // Replace all occurences of '%' with '*' encodedText = encodedText.replace('%', '*'); Decoding: // replace all occurences of '*' with '%' String decodedText = encodedText.replace('*', '%'); // decode with URLDecoder (decodes also occurences of "%2A' to '*' decodedText = URLDecoder.decode(decodedText, "UTF-8");

            People

            • Assignee:
              Unassigned
              Reporter:
              Mika Salminen
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development