WO Adaptor URL Sanitization Fixes

[NotsoanoNimus]

Added fix-ups to the Utilities/Adaptors subfolders specifically to address a vulnerability in parsing, whereby an adversary can directly inject their own headers and content into the web requests going to the application (WO) servers behind the adaptor.

The new code returns a 404 on any encounter of a 0x0D (carriage-return) or a 0x0A (line-feed) character in the adaptor translate functions, and the defined forbidden character set is written in such a way as to be expandable later as necessary. This behavior of returning a 404 error mimics Apache's mitigation of the use of %2f in request URLs.

IMPORTANTLY: This URL cleanliness will not affect content within query strings usually, since those characters are not typically expanded by webserver software before reaching the adaptor interface.

Tested and operating in an active production scenario, filtering arbitrary HTTP header injection or URL-based reflection but maintaining normal operation as expected. The most recent commit addresses enabling the protection by default but provides the option to regress to the previous behavior in situations and deployments where it may be considered safe or necessary.

For more information about the problem being fixed, I will post a separate link to my blog for interested users.

[NotsoanoNimus]

As stated, here is the link to my article about the WebObjects adaptor vulnerability present in Project WONDER. If the link is inappropriate, please feel free to remove it or request such.

Thank you.

[maiksd]

Hi Zachary, somehow we failed to give this the proper attention when you first posted it. Reviewing your detailed article now.

[maiksd]

Reviewed the patch, and I approve merging it. I want to wait for people in other timezones to have a chance to chime in, though. Until then, we confirmed this to be mitigated by the following global apache config:

RewriteEngine On
RewriteOptions InheritDown
RewriteRule ^.*\x0d\x0a - [F,L,NC]