search cancel

Siteminder encoding issue

book

Article ID: 201492

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

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 ?

 

 

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.

 

Environment

 

  Web Agent 12.52SP1CR07 64bit on Apache 2.2.34 64bit on RedHat 6;
  Policy Server 12.52SP1CR00 on RedHat 6;

 

Resolution

 

Correct the Custom Authentication Scheme in order to not double encode
characters :

  mycustomlogin.fcc

to solve the issue.