Why are encoded chars encoded again?

Help / Discuss
1

In a fresh installation of XWiki Standard 17.10.2, there are at least 5 API calls that include double-encoded characters in the request path (spaces added to not break the bold font):

  • /asyncrenderer/uix/xwiki %253A Help.SupportPanel.WebHome/author/xwiki %253A XWiki.admin/locale/en/secureDocument/xwiki %253A Help.SupportPanel.WebHome

  • /asyncrenderer/uix/xwiki %253A Help.TipsPanel.WebHome/author/xwiki %253A XWiki.admin/locale/en/secureDocument/xwiki %253A Help.TipsPanel.WebHome/14

  • /asyncrenderer/uix/xwiki %253A Panels.MyRecentModifications/author/xwiki %253A XWiki.admin/locale/en/request.wiki/xwiki/secureDocument/xwiki %253A Panels.MyRecentModifications/user/xwiki %253A XWiki.admin/wiki/xwiki

  • /asyncrenderer/uix/xwiki %253A Panels.Applications/author/xwiki %253A XWiki.admin/icon.theme/Font%2BAwesome/locale/en/request.wiki/xwiki/secureDocument/xwiki %253A Panels.Applications/user/xwiki %253A XWiki.admin/wiki/xwiki

  • /asyncrenderer/uix/org.xwiki.platform.wiki.ui.common.contentFooter.authors/author/xwiki %253A XWiki.admin/doc.reference/xwiki %253A Main.WebHome %2528 %2529 /locale/en/secureDocument/xwiki %253A XWiki.PageAuthorsUIX/user/xwiki %253A XWiki.admin/wiki/xwiki?clientId=12&timeout=500&wiki=xwiki

    /asyncrenderer/notifications/display/5ALERT_17xwiki**%253AXWiki.admin_10_null_434969800/locale/en/request.wiki/xwiki/user/xwiki%253A**XWiki.admin/17

The decoded chars are:

%253A => %3A => :

%2528 => %28 => (

%2529 => %29 => )

Since Traefik 2.11.32, special encoded characters like the percentage symbol are blocked by default because there usually is no reason to encode e.g. % ; # ?. Took me a bit to find that the proxy is the problem :smile:

Should I open a ticket for this?

2

“It’s not a bug, it’s a feature”.

It was done like this because of Tomcat’s ridiculous default “security” protections that were blocking encoded characters like / and \. These kinds of blockages got quite worst recently, with Jettty adding more and more forbidden characters by default with each new version and now even Servlet 6 specifications.

We have a general issue already about introducing new APIs (most of our REST APIs are impacted by this trend of not following URI specifications in the Servlet world) designed to not be impacted by this kind of problems (i.e. stop putting user input in URL path elements basically), but it will take time…

Unless you do need to pass an element which contains these characters, which can be quite common when the path is built from user input (like page names), and you accept everything.