ACO BadURLChars doesn't block /%2F from URL, request gets 404 from Apache instead of 500
search cancel

ACO BadURLChars doesn't block /%2F from URL, request gets 404 from Apache instead of 500


Article ID: 6546


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On


I'm protecting a Web Site with the Web Agent, and when the request has "/%2F", I see a strange behavior. The Web Agent
doesn't block the request. As result, the browser shows error 404 "Not Found", rather than expected 500 error
that should be returned by the Web Agent.

The Web Agent ACO badurlchars is configured with "/%2f,//,./,/.,/*,*.,~,\,%00-%1f,%7f-%ff,%25". With this configuration
the Web Agent should block the request. Why it doesn't ?


Web Agent 12.52CR01 on IHS


The reason we are getting 404 when %2f is because APACHE itself is breaking the URL.

In order to avoid it we need to add in Apache Configuration : "AllowEncodedSlashes" to ON.

  Description:    Determines whether encoded path separators in URLs are allowed to be passed through
  Syntax:    AllowEncodedSlashes On|Off|NoDecode
  Default:    AllowEncodedSlashes Off
  Context:    server config, virtual host
  Status:    Core
  Module:    core
  Compatibility:    Available in Apache httpd 2.0.46 and later. NoDecode option available in 2.2.18 and later.

  The AllowEncodedSlashes directive allows URLs which contain encoded path separators (%2F for / and additionally %5C for \ on accordant systems) to be used in the path info.
  With the default value, Off, such URLs are refused with a 404 (Not found) error.
  With the value On, such URLs are accepted, and encoded slashes are decoded like all other encoded characters.
  With the value NoDecode, such URLs are accepted, but encoded slashes are not decoded but left in their encoded state.
  Turning AllowEncodedSlashes On is mostly useful when used in conjunction with PATH_INFO.


Add in Apache Configuration: "AllowEncodedSlashes" to ON to solve the issue