Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-9135

Undertow is doubly URLDecoder.decode(ing) auth-method query parameters

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 11.0.0.Beta1
    • 10.1.0.Final
    • Web (Undertow)
    • None
    • Hide

      Run the attached AuthMethodParserTest#testPEMEncoded unit test.

      Show
      Run the attached AuthMethodParserTest#testPEMEncoded unit test.
    • Compatibility/Configuration
    • Workaround Exists
    • Hide

      Since I know there cannot be spaces in the PEM string, I can simply replace them with a '+' within the custom AuthenticationMechanismFactory.

      Show
      Since I know there cannot be spaces in the PEM string, I can simply replace them with a '+' within the custom AuthenticationMechanismFactory.
    • Low

    Description

      I'm testing a custom authentication mechanism that is passing in a PEM encoded public key that has been URL.encoded. I have attached the web.xml I'm using, but I have also created a simple standalone unit test that illustrates the issue.

      The org.wildfly.extension.undertow.deployment.AuthMethodParser.parse method calls io.undertow.util.QueryParameterUtils.parseQueryString to handle the parsing of the query string passed in with the auth-method name. This detects if there is a need to decode a parameter and does so.

      The resulting map of query properties is then again unconditionally decodes the values again by this loop in AuthMethodParser:

                          for (Map.Entry<String, Deque<String>> entry : props.entrySet()) {
                              Deque<String> val = entry.getValue();
                              if (val.isEmpty()) {
                                  authMethodConfig.getProperties().put(URLDecoder.decode(entry.getKey(), UTF_8), "");
                              } else {
                                  authMethodConfig.getProperties().put(URLDecoder.decode(entry.getKey(), UTF_8), URLDecoder.decode(val.getFirst(), UTF_8));
                              }
                          }
      

      since the original value is a PEM encoded public key, it may contains '+' characters, and these then are incorrectly transformed into space characters. I would suggest that this second decoding step simply be dropped.

      Attachments

        Issue Links

          Activity

            People

              sdouglas1@redhat.com Stuart Douglas
              starksm64 Scott Stark (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 1 hour
                  1h
                  Remaining:
                  Remaining Estimate - 1 hour
                  1h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified