Issues with URL encoded ControllerIDs

[Bastian-Krause]

Hi!

I'm using the hawkbit/hawkbit-update-server:latest docker container.
There seem to be some issues/inconsistencies with URL encoded ControllerIDs:

1. Creating a target with ControllerID * works (management API).
   Polling this target via the DDI API:

• Not URL encoded:

$ curl -H "Authorization: TargetToken 50aea537bce197fa3371215fbdc5f3c6" "http://localhost:8080/DEFAULT/controller/v1/*"
{"config":{"polling":{"sleep":"00:00:30"}},"_links":{"configData":{"href":"http://localhost:8080/DEFAULT/controller/v1/*/configData"}}}

• URL encoded:

$ curl -v -H "Authorization: TargetToken 50aea537bce197fa3371215fbdc5f3c6" "http://localhost:8080/DEFAULT/controller/v1/%2A"
[...]
< HTTP/1.1 401 Unauthorized
[...]

2. Creating a target with ControllerID ö works (management API).
   Polling this target via the DDI API:

• Not URL encoded:

$ curl -v -H "Authorization: TargetToken da8935abe0960f7062c833fab173c6ee" "http://localhost:8080/DEFAULT/controller/v1/ö"
[...]
< HTTP/1.1 500 Server Error
[...]
{"timestamp":"2021-07-01T14:09:32.684+00:00","status":500,"error":"Internal Server Error","message":""}

hawkBit's logs tell us:

org.springframework.security.web.firewall.RequestRejectedException: The requestURI was rejected because it can only contain printable ASCII characters.
	at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:345)
	at org.eclipse.hawkbit.autoconfigure.security.SecurityManagedConfiguration$UISecurityConfigurationAdapter$IgnorePathsStrictHttpFirewall.getFirewalledRequest(SecurityManagedConfiguration.java:769)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:194)
        [...]

• URL encoded:

$ curl -v -H "Authorization: TargetToken da8935abe0960f7062c833fab173c6ee" "http://localhost:8080/DEFAULT/controller/v1/%C3%B6"
[...]
< HTTP/1.1 401 Unauthorized
[...]

So we can obviously create targets that cannot poll the DDI API, right?

But maybe if we create the target with a URL encoded ControllerID?

3. Creating a target with ControllerID %C3%B6 works (management API).
   Polling this target via the DDI API:

• URL encoded:

$ curl -H "Authorization: TargetToken 920e8c8b58619c836efc47960422c5e2" "http://localhost:8080/DEFAULT/controller/v1/%C3%B6"
{"config":{"polling":{"sleep":"00:00:30"}},"_links":{"configData":{"href":"http://localhost:8080/DEFAULT/controller/v1/%C3%B6/configData"}}}

So this works. But now there is a new target "ö" listed in the Web UI:

Status registered
Description: Plug and Play target: ö
Last poll: Thu Jul 1 16:16:56 CEST 2021
Security token: 1e9f7827e9d6bab45ac8d8d0cbc26aed
Created by: CONTROLLER_PLUG_AND_PLAY
[...]

The URL encoded target %C3%B6 is not marked as registered, "Last poll" is empty, although it's security token (TargetToken) was accepted. Is this intended behavior?

Expected behavior: It would be nice to know which characters are allowed in the ControllerID. Ideally they should be accepted URL encoded. And the DDI API as well as the Management API should accept/deny them consistently.

[bogdan-bondar]

Hi @Bastian-Krause ! Thanks a lot for bringing this issue up. We should indeed restrict/define and document the allowed controller id format/characters. What would be your expectations:

1. Would you prefer allowing the special characters, like *, %, etc. for controller ids? Generally I would prefer to simply disallow them as it could lead to unpredictable behaviour during DB queries execution as well as target filtering.
2. If I got it correct, you would expect the URL encoded controller ids to be decoded by hawkbit and not interpreted as exact controller ids?

[Bastian-Krause]

What would be your expectations:

1. Would you prefer allowing the special characters, like *, %, etc. for controller ids? Generally I would prefer to simply disallow them as it could lead to unpredictable behaviour during DB queries execution as well as target filtering.

Personally, I'd prefer it if special characters were simply not allowed in ControllerIDs, globally.

Edit: if non-ASCII should be allowed in URL-encoded form (see below), the check for these unallowed characters must be performed after URL-decoding.

2. If I got it correct, you would expect the URL encoded controller ids to be decoded by hawkbit and not interpreted as exact controller ids?

If non-ASCII (plain) characters like äöüß should still be allowed, it would be nice if hawkBit would URL-decode the ControllerID. I think it should not hurt to always do that, right? %C3%B6 and ö for example would then be handled as the same ControllerID.