Forum Discussion
APM URL encoding Hardening?
Some companies still use on-prem Sharepoint.. and Sharepoint is what it is.
We have had multiple servers deployed for quite some while now with ASM tuned for its quirks and so on.
However - after upgrading to version 17.5.1.6 from 17.5.1.5 we noticed some rather strange behaviors.
Like the edit modal button stopped working on certain sites, the upload button stopped working amongst some of the stuff. After some testing and stripping of functions we noticed that it started working when removing the APM policy. So the cogs started turning, what could be the issue with APM?
Finally figured out that the links which did not work where not encoded, and the links which worked were.
So after some tweaking I got to building a simple http request rewrite iRule for simply encoding the stuff before sending to server.
But I do have some qualms about it - Are there any security risks according to you dear people that I might introduce by deploying this externally? Would you have solved it in any other way?
basically it's this:
when HTTP_REQUEST {
# Re-encode characters that are illegal in URIs per RFC 3986 §2.2 / §3.4set orig_uri [HTTP::uri]
set new_uri [string map {
"\{" "%7B"
"\}" "%7D"
"|" "%7C"
"\\" "%5C"
"^" "%5E"
"`" "%60"
" " "%20"
} $orig_uri]
if { $new_uri ne $orig_uri } {
HTTP::uri $new_uri}
}
1 Reply
- Jeff_Granieri
Employee
Hi Ted-Nordvall,
I used our F5 Irules Assistant Video to help analyze your current irule, functionally it works fine. Putting on a security cap probably a good idea to have AWAF on this VS as well to help with the HTTP compliance and signature matching at a bare minimum. I did look at some possible enhancements to secure up the iRule -
when RULE_INIT { # Build map once. Note: in a braced list, "\" = literal '\', "\{" = '{', etc. # \r and MUST be encoded to prevent CRLF / smuggling. set static::uri_encode_map [list \ "\{" "%7B" "\}" "%7D" "|" "%7C" "\" "%5C" \ "^" "%5E" "\`" "%60" " " "%20" """ "%22" \ "<" "%3C" ">" "%3E" "\r" "%0D" " " "%0A" \ "\x00" "%00" "\x01" "%01" "\x02" "%02" "\x03" "%03" \ "\x04" "%04" "\x05" "%05" "\x06" "%06" "\x07" "%07" \ "\x08" "%08" "\x09" "%09" "\x0B" "%0B" "\x0C" "%0C" \ "\x0E" "%0E" "\x0F" "%0F" "\x7F" "%7F"] } when HTTP_REQUEST { set orig_uri [HTTP::uri] set new_uri [string map $static::uri_encode_map $orig_uri] if { $new_uri ne $orig_uri } { HTTP::uri $new_uri } }And here is what our AI assistant had to say about it:
AI Assistant 09:29 am
Objective
• Ensure that any unsafe or smuggling‐prone characters in the incoming HTTP request URI are percent-encoded before being sent to the pool member.
• Build a static lookup map once at rule initialization to translate braces, control characters, whitespace, and other disallowed bytes into their “%XX” forms.
• On each HTTP request, compare the original URI to its encoded version and update it if any translation occurred.
Execution Flow
• RULE_INIT event
– Runs when the iRule is loaded.
– Uses set static::uri_encode_map [list …] to construct a list of character-to-percent-encoding pairs in a static variable.
• HTTP_REQUEST event
– Triggers after full parsing of client HTTP headers (per docs for HTTP_REQUEST).
– set orig_uri [HTTP::uri] retrieves the raw path and query string.
– set new_uri [string map $static::uri_encode_map $orig_uri] applies all mappings from the static map.
– If the mapped URI differs (if { $new_uri ne $orig_uri }), call HTTP::uri $new_uri to set the rewritten URI toward the server.
Overall summary: This iRule cleanly builds a reusable encoding map at initialization and applies it on each HTTP request to neutralize potential CRLF or directory-traversal threats, using documented BIG-IP iRule commands as intended.
Please test in non-prod environment/qa. Hope it helps
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com