KB : TEC1055274
KB : TEC1482607
SiteMinder offers limited CSRF protection capabilities today. This a phishing-style attack where a user is manipulated into sending an HTTP request on behalf of the hacker. The hackers request is generally designed to take advantage of a user who has previously logged in legitimately to the target site prior to the attack. The request itself is semantically correct and typically indistinguishable from a valid request if executed correctly.
To prevent these types of attacks, an application generally must defend itself by building security into the application themselves, typically in the form of a secure token that validates the request. Even this is tricky since the security mechanism must avoid being captured and replayed just like a cookie or HTTP header.
CA SSO can however, prevent the variety of Cross Site Request Forgery (CSRF) attacks where a user is prompted to navigate away from a legitimate CA SSO protected website to a malicious website by utilizing following techniques:
- ValidTargetDomain - Web Agents can help protect from phishing attempts that could redirect users to a hostile web site.
This parameter specifies the domains to which a credential collector is allowed to redirect users. If the domain in the URL does not match the domains set in this parameter, the redirect is denied.
This will ensure that the webagent works with targets that are appended to its own fully qualified domain name, so that bogus targets in other cookie
domains cannot slip through as it would require the target URI be on the same Domain as the authentication service. Since everything would be
relative, an outside source could not force you out of your domain.
KB : TEC1779626
To mitigate this vulnerability, you will need to use Secure HTML Forms.
Use Secure HTML Forms Authentication Templates
The Secure HTML forms authentication templates differ from the standard versions in the following ways:
- Secure versions do not display the username in returned messages
- Secure versions include a Logout hyperlink in the top right side corner of the form template which logs out the user and redirects them to the custom logoff page
- Autocomplete is turned off for all text fields in secure versions
Default secure template files which you can customize are located in the following directories:
- Windows: webagent\secureforms
- UNIX: webagent/secureforms
To use the secure versions of the HTML forms authentication templates, copy the files from the secureforms directory to the following location, replacing the standard versions there:
- Windows: webagent\samples\forms
- UNIX: webagent/samples/forms
A set of secure forms for the US English (en-US) locale is also available in the following directories:
- Windows: webagent\secureforms_en-US
- UNIX: webagent/secureforms_en-US
To use the secure versions of the US English locale forms, copy the files from the secureforms_en-US directory to the following location, replacing the standard versions there:
- Windows: webagent\samples\forms_en-US
- UNIX: webagent/samples/forms_en-US
This is another form of Cross Site Scripting (XSS) Attack.
To mitigate this , you can encode all form fields (including hidden one) as mentioned here :
Help Prevent Attacks - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation
Prevent Cross-Site Scripting Attacks in Web Agent FCC Pages
To prevent cross-site scripting attacks against the web agent FCC pages, use HTML encoding to ensure that your FCC variable data is rendered correctly.
HTML encoding ensures that the characters are treated as their literal value and not as HTML syntax. Encoding ensures that the damaging cross-site scripting syntax is rendered as literal text as it must appear and that the browser does not execute the code while rendering the HTML form. You can encode all the syntax that could be misused during an attack.
The fcchtmlencoding parameter instructs an agent to apply an HTML encoding algorithm to all the values inserted into the FCC variables that have the following syntax:
If the characters that are traditionally blocked are necessary in the FCC data, then enable the fcchtmlencoding parameter.
Specifies whether the HTML encoding is enabled to prevent Cross-Site Scripting attacks against web agent FCC pages. This parameter does not block any characters.
Values: Yes and No.
The fcchtmlencoding parameter applies to all the variable substitutions for all the FCC forms. An agent using this parameter can serve one or more FCC forms.
To apply the HTML encoding to a specific character in an FCC file, use the following parameter:
Fetches the specific character value, applies the HTML encoding, and substitutes the actual character value with the encoded value in an FCC file.
To apply the HTML encoding to a specific variable in an FCC file, use the following function:
Fetches the specific variable values, applies the HTML encoding, and substitutes the actual variable values with the encoded values in an FCC file.
The HTMLENCODE function has the following syntax:
KB : TEC1978924
SiteMinder protects the Audit/User/Session Store data against SQL Injection.
SiteMinder does not protect the actual application data that the customer has in their application database against SQL Injection.
There is no known SQL injection vulnerability in SiteMinder code.
This can be mitigated by setting following ACO parameter to YES:
Instructs the Web Agent to set the HTTP-only attribute on the cookies it creates. When a Web Agent returns a cookie with this attribute to a user's browser, the contents of the cookie cannot be read by a script, even a script from the web site which originally set the cookie. This helps prevent any sensitive information in the cookie from being sent to an unauthorized third party through a script.
To safeguard the information in cookies, set the value of the UseHTTPOnlyCookies parameter to yes.
Sends cookies to web servers using secure (HTTPS) connections. Enable this parameter to increase security between browsers and web servers.
When this setting is enabled, users in single sign-on environments who move from an SSL web server to a non-SSL web server will have to reauthenticate. Secure cookies cannot be passed over traditional HTTP connections.
To send cookies over SSL connections, set the UseSecureCookies parameter to yes.