Symantec Access Management

Hi All,

I am using SiteMinder 12.51 version environment, I am facing problem with webagent which blocks the Target URL which has SHIFT_JIS character set.

It blocks only during login.

And it throws an error  "badCSSChars found substituting 'target'"  and it is changing the target value as DATA BLOCKED on login page.

Case

1.  Users hits the URL contains SHIFT_JIS.

2.  Redirected to the login page and the webagent block the URL and changing target value to "DATA BLOCKED"  < target =$$target$$>

If user already logged in and try accesing the same URL contains SHIFT_JIS, it is allowing It is working fine

Issue: I suspect when redirecting user to the loginpage webagent is encoding the SHIFT_JIS Actual URL to  some URL < conatins badCSSChars>

Please help me to solve this.

Thank You

Regards

Saravanan

BadCSSChars contain by default only 3 characters <'>

Unless you have these 3 Characters in the TARGET which appears as a Query Parameter to the Login Page. When WebAgent populates the Form POST on login.fcc - you'd see "DATA BLOCKED".

However my suspicious is that it isn't the BadCSSChars, though your log states "BadCSSChars found substituting target". Remember TARGET gets subsituted from a Query into a FORM Data (we also have an ACO Parameter BadFormChars). Further more the documentation does not suggest, however I also recollect a new ACO parameter called BadTargetChars (which applied to TARGET only in FORM DATA; however BadFormChars applies to rest of the FORM DATA - before this change BadFormChars applied to all FORM DATA including TARGET).

So lets take a stepped approach.

Step-1:

I certainely have reservations against disabling CSSChecks in Production. However if you have a Test ENV; then for testing purposes set CSSChecking=no in your Agent Configuration Object. Recycle the WebServer Services and Test. Lets see what result we get out from Step-1 and then decide way forward.

Regards

Hubert.

Hi Hubert,

I have the below value in the query parameter, which get subtituted to  -%C4  this new substituted value contains BadCSSChars.

ト  ===>  %C4

I even tried csschecking= no and restart agent, the result is same "BadCSSChars found substituting target".

Note: If i hit the same URL after login in, I am not facing any issue.

Hi Hubert,

The below japanese character is causing the issue.

UrlEncode.net URLエンコード

ﾀ ===>  %C0

when we pass the above shift_JIS value in query string to the login page, fcc is blocking the  target content.

I have also tried to pass this value  "%C0" to other CA siteminder protected sites, same issue.

Thank You

Regards

Saravanan

Thank You Saravanan Nalla

When I encode ﾀ I get %EF%BE%80

URL Decoder/Encoder

HTML URL Encoding Reference

I am unsure why the link you provided returns a %C0

Nevertheless, Have a look at this thread Re: SiteMinder Protected URLs with Chinese Characters. I still think the error message you are encountering is misleading.

Would it be possible to paste the complete URL from the address bar after removing the FQDNs.

Regards

Hubert

Saravanan Nalla

Understand SiteMinder URL Encoding and Decoding.

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec476572.aspx

Product Information Matrix - CA Technologies

Understand SiteMinders SM Encoding of URLs - CA Technologies

Regards

Hubert