Siteminder encoding issue
Article ID: 201492
Updated On:
Products
Issue/Introduction
We're running a Web Agent and when url has already %5E character, then the
backend server application receives it double encoded as %255E. To
illustrate :
The Web Agent receives the URL :
https://myserver.mydomain.com/myapp/myapplicationpage^ItemNumber/
and the Web Agent sends it as
https://myserver.mydomain.com/myapp/myapplicationpage%255EItemNumber/
How can we fix that ?
Environment
Web Agent 12.52SP1CR07 64bit on Apache 2.2.34 64bit on RedHat 6;
Policy Server 12.52SP1CR00 on RedHat 6;
Cause
You shouldn't use caret ^ character in URL as this is unsafe character :
Uniform Resource Locators (URL)
In most URL schemes, the sequences of characters in different parts
of a URL are used to represent sequences of octets used in Internet
protocols. For example, in the ftp scheme, the host name, directory
name and file names are such sequences of octets, represented by
parts of the URL. Within those parts, an octet may be represented by
the chararacter which has that octet as its code within the US-ASCII
[20] coded character set.
In addition, octets may be encoded by a character triplet consisting
of the character "%" followed by the two hexadecimal digits (from
"0123456789ABCDEF") which forming the hexadecimal value of the octet.
(The characters "abcdef" may also be used in hexadecimal encodings.)
The character "%" is unsafe because it is used for
encodings of other characters.
Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "\", "^", "~",
"[", "]", and "`".
All unsafe characters must always be encoded within a URL.
https://tools.ietf.org/html/rfc1738#:~:text=2.2.&text=RFC%201738%20Uniform%20Resource%20Locators%20(URL)%20December%201994%20Reserved%3A,the%20octet%20must%20be%20encoded.
So the application should encode it first to %5E.
fiddler.saz
The first request is sent correctly with myapplicationpage%5EItemNumber
encoded as the RFC requests :
Line 3 :
GET https://myserver.mydomain.com/myapp/myapplicationpage%5EItemNumber/ HTTP/1.1
https%3A%2F%2Fmyserver.mydomain.com%2Fmyapp%2Fmyapplicationpage-%5EItemNumber%2F
HTTP/1.1 302 Found
Date: Fri, 18 Sep 2020 10:59:55 GMT
Location: https://myserver.mydomain.com/siteminderagent/forms/mycustomlogin.fcc?TYPE=33554433&REALMOID=06-000741d6-4617-2xsa-44ws-391c9970f051&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=-SM-SAw44sa%2sddedds0kT9KwtNgg%2bCtx9h%2bdLgDeli%2fqU%2fWracdxAiAhEZph&TARGET=-SM-https%3A%2F%2Fmyserver.mydomain.com%2Fmyapp%2Fmyapplicationpage-%5EItemNumber%2F
and the Web Agent keeps that encoding in the TARGET value :
TARGET=-SM- [...] myapplicationpage-%5EItemNumber
Line 4 :
GET https://myserver.mydomain.com/siteminderagent/forms/mycustomlogin.fcc?TYPE=33554433&REALMOID=06-000741d6-4617-2xsa-44ws-391c9970f051&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=-SM-SAw44sa%2sddedds0kT9KwtNgg%2bCtx9h%2bdLgDeli%2fqU%2fWracdxAiAhEZph&TARGET=-SM-https%3A%2F%2Fmyserver.mydomain.com%2Fmyapp%2Fmyapplicationpage-%5EItemNumber%2F
HTTP/1.1 200 OK
Date: Fri, 18 Sep 2020 10:59:56 GMT
Server: Apache
Welcome to Our Page
https://myserver.mydomain.com/myapp/myapplicationpage%5EItemNumber/
But when POSTing, the mycustomlogin.fcc sends the value double encoded :
target=https [...] myapplicationpage%255EItemNumber [...]
So the code of the mycustomlogin.fcc should be reviewed in order to
not double encode that character.
Resolution
Correct the Custom Authentication Scheme in order to not double encode
characters :
mycustomlogin.fcc
to solve the issue.
Feedback
