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

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

    Details

    • Steps to Reproduce:
      Hide

      Run the attached AuthMethodParserTest#testPEMEncoded unit test.

      Show
      Run the attached AuthMethodParserTest#testPEMEncoded unit test.
    • Affects:
      Compatibility/Configuration
    • Workaround:
      Workaround Exists
    • Workaround Description:
      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.
    • Estimated Difficulty:
      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  swd847 Stuart Douglas
                  Reporter:
                  starksm64 Scott Stark
                • 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