Symantec Access Management

There are customers that prefer to let the application handle cross-site scripting attacks. The FCC is a siteminder applications – this tip describes how to protect the FCC using existing siteminder mechanisms that are part of the language that make the FCCC files programmable.

SiteMinder FCC files supports three types of encoding and decoding functions.

smencode()/smdecode()
urlencode()/urldecode()
b64encode()/b64decode()

Basically, anywhere you have $$variable$$, you modify the string to be $$encode function(variable)$$. So $$target$$ becomes $$urlencode(target)$$, for example. Then, to make sure that the variable is properly decoded after a post (important for hidden variables!!), place @variable=%decode function(variable)% at the top of the file in the list of FCC directives. Following my example, you’d add @target=%urldecode(target)%. See the attached login.fcc file for a full working example of how this works. I encourage your team to make the changes in their test environment and retry their XSS attacks.

This approach provides a fully programmable, variable-by-variable, approach to handling custom data insertion in SiteMinder FCC forms. You will be able to insure that all data is encoded, if you wish, and you can choose the type of encoding: Base64, URL, or SM (a proprietary hybrid of URL encoding). These directives work outside the functionality of CSSChecking and BadFormChars and will work OOB with your environments today.
Example: Login.fcc

Need to decode in the directive declaration

<!-- SiteMinder Encoding=ISO-8859-1; -->
@username=%USER%
@smretries=0
@target=%urldecode(target)%
@smquerydata=%urldecode(smquerydata)%
@smagentname=%urldecode(smagentname)%
@smauthreason=%urldecode(smauthreason)%
@postpreservationdata=%urldecode(postpreservationdata)%



<tr>

<td colspan=4 NOWRAP WIDTH="50%" HEIGHT="25" align="CENTER">

<input type=hidden name=target value="$$urlencode(target)$$">

<input type=hidden name=smquerydata value="$$urlencode(smquerydata)$$">

<input type=hidden name=smauthreason value="$$urlencode(smauthreason)$$">

<input type=hidden name=smagentname value="$$urlencode(smagentname)$$">

<input type=hidden name=postpreservationdata value="$$urlencode(postpreservationdata)$$">

<input type="button" value="Login" onClick="submitForm();">

</td>

stephen_mcquiggan wrote:

There are customers that prefer to let the application handle cross-site scripting attacks. The FCC is a siteminder applications – this tip describes how to protect the FCC using existing siteminder mechanisms that are part of the language that make the FCCC files programmable.

SiteMinder FCC files supports three types of encoding and decoding functions.

smencode()/smdecode()
urlencode()/urldecode()
b64encode()/b64decode()

Basically, anywhere you have $$variable$$, you modify the string to be $$encode function(variable)$$. So $$target$$ becomes $$urlencode(target)$$, for example. Then, to make sure that the variable is properly decoded after a post (important for hidden variables!!), place @variable=%decode function(variable)% at the top of the file in the list of FCC directives. Following my example, you’d add @target=%urldecode(target)%. See the attached login.fcc file for a full working example of how this works. I encourage your team to make the changes in their test environment and retry their XSS attacks.

This approach provides a fully programmable, variable-by-variable, approach to handling custom data insertion in SiteMinder FCC forms. You will be able to insure that all data is encoded, if you wish, and you can choose the type of encoding: Base64, URL, or SM (a proprietary hybrid of URL encoding). These directives work outside the functionality of CSSChecking and BadFormChars and will work OOB with your environments today.
Example: Login.fcc

Need to decode in the directive declaration

<!-- SiteMinder Encoding=ISO-8859-1; -->
@username=%USER%
@smretries=0
@target=%urldecode(target)%
@smquerydata=%urldecode(smquerydata)%
@smagentname=%urldecode(smagentname)%
@smauthreason=%urldecode(smauthreason)%
@postpreservationdata=%urldecode(postpreservationdata)%



<tr>

<td colspan=4 NOWRAP WIDTH="50%" HEIGHT="25" align="CENTER">

<input type=hidden name=target value="$$urlencode(target)$$">

<input type=hidden name=smquerydata value="$$urlencode(smquerydata)$$">

<input type=hidden name=smauthreason value="$$urlencode(smauthreason)$$">

<input type=hidden name=smagentname value="$$urlencode(smagentname)$$">

<input type=hidden name=postpreservationdata value="$$urlencode(postpreservationdata)$$">

<input type="button" value="Login" onClick="submitForm();">

</td>

You can not apply the encoding function to ANY form fields...Read below for the reasoning :

It is possible to smencode (or urlencode/b64encode) all the fields in the ssologin.fcc by just doing $$smecnode(variable_name)$$

Where ,

variable_name could be target,smquerydata,postpreservationdata or any custom fields.

However, to ensure that the variable is properly decoded after the POST , you will need to do the corresponding decoding for that variable using

@variable=%decode function(variable)% synatx at the top of your fcc file.

Now, limitation here is that you can NOT define any variable here. Only certain special variable are allowed here.

These are called directives.

In other words, there are only limited set of directives which are allowed for special processing and they are :

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/policy-server-configuration/authentication-schemes/configure-html-forms-authentication

-username

-password

-target

-smheaders

-smerrorpage

-smretries

-smpasswordfcc

-smusrmsg

-smauthreason

-smsavecreds

-smsave

-save

-smtransient

-smagentname

-smlogout

So , as you can see , you cannot encode "postpreservationdata" field or any other custom fields, because they are NOT a valid directive and as such they won't be decoded even if you specify following at the top of your fcc :

@postpreservationdata=%smdecode(postpreservationdata)%

This will eventually cause the postpreservationdata to be unable to decode after the POST is complete.

Added info: postpreservationdata if encoded will likely break since the data POSTed by the form won’t be in the exact format expected by the agent.  When there is preserved post data, the data should already be base64 encoded and safe for posting