Summary
In this guide ,we will discuss about various security vulnerabilities that the CA Single Sing-On Web Agent might be affected with and steps that can be taken to remediate the said vulnerability.
The Single Sign-On Web Agent considered for this blog is 12.52 and above.
Vulnerability 1 : Directory Traversal/Browsing
Description
The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate a URL in such a way that the web site will execute or reveal the contents of arbitrary files anywhere on the web server. Any device that exposes an HTTP-based interface is potentially vulnerable to Path Traversal.
Resolution
KB : TEC1055274
Vulnerability 2 : X-Frame-Options Header Not Set
Description
X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.
Resolution
Single Sign-on Web Agent r12.51 CR4 and above does have support for XFrameOptions ACO Parameter.
The options for the XFrameOptions parameter are the same as the values for the X-Frame-Options response header:
Options: DENY, SAMEORIGIN, ALLOW-FROM uri
r12.51 CR4 and above Web Agent, also do honor this header if it is being set by the WebServer itself and let the header pass to the client/browser.
So, to mitigate this vulnerability either configure X-Frame-Options response header at the web server level or at the web agent level by setting XFrameOptions ACO Parameter.- KB : https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec2763144.html
Vulnerability 3 : Server Misconfiguration-Cache Policy
Description
Server Misconfiguration: Cache Policy
WebInspect has detected a potentially unsafe cache control policy for secure content. While content
transmitted over an SSL/TLS channel is expected to guarantee confidentiality, administrators must
nonetheless ensure that caching of sensitive content is disabled unless absolutely needed. The
misconception that secure content caching is disabled by default by user-agents could cause the application
to fail the organization’s cache policy by leaving the secure content cacheable by browsers. Unsafe
specification such as Cache-Control: public would instruct the browser to persistently cache the content on
the hard drive. Caching can be prevented by specifying one of the following three directives in the response
headers
• Cache-control: private
• Cache-Control: no-cache
• Cache-Control: no-store
Resolution
KB : TEC1482607
To prevent this vulnerability you should set ExpireForProxy ACO parameter to YES
When ExipreForProxy=YES, web agent inserts following HTTP headers in the response.
>Expires : Set to Date in the past, which prevents page from being cached by a proxy, as dictated by the HTTP 1.0 specification
>Cache-control:no-cache
Note :
Now, this is all good for normal resources but there are certain resources which you might want to still be cached. For e.g. .gif/.jss files which doesn’t change normally and also need not be protected.
If these resources are not cached on the client side, they will put an unnecessary overhead in the network traffic.
To ensure that these files are cached (exception to no-cache setting), here is what you have to do :
> Include the files you want to be cached in IgnoreExt. So IgnoreExt should contain .gif/.jss file extensions.
> Set AllowCacheHeaders=YES
When you make above changes this is what happens :
For any file included in IgnoreExt, web agent will not insert no-cache Cache-control in the response header
Vulnerability 4 : Cross-Site Request Forgery (XSRF/CSRF)
Description
Cross-Site Request Forgery (XSRF or CSRF) has been detected. Because browsers can run code sent by
multiple sites, an XSRF attack can occur if one site sends a request (never seen by the user) to another site
on which the user has authenticated that will mistakenly be received as if the user authorised the request. If
a user visits a vulnerable site, the attacker can make the user's browser send a request to a different target
site that performs an action on behalf of the user. The target site only sees a normal authenticated request
coming from the user and performs whatever sensitive action was requested. Whatever functionality exists
on the target site can be manipulated in this fashion. Recommendations include utilising CAPTCHA's or
anti-Cross-Site Request Forgery tokens to prevent Cross-Site Request Forgery attacks.
Resolution
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. - TargetAsRelativeURI-
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.
Vulnerability 5 : Privacy Violation :Autocomplete
Description
Most recent browsers have features that will save form field content entered by users and then automatically
complete form entry the next time the fields are encountered. This feature is enabled by default and could
leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly
increased if users are accessing the application from a shared environment. Recommendations include
setting autocomplete to ""off"" on all your forms.
Resolution
KB : TEC1779626
To mitigate this vulnerability, you will need to use Secure HTML Forms.
https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/policy-server-configuration/authentication-schemes/configure-html-forms-authentication
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
Vulnerability 6 : Format String Attack
Description
The attack could be executed when the application doesn’t properly validate the submitted input. In this case, if a Format String parameter, like %x, is inserted into the posted data, the string is parsed by the Format Function, and the conversion specified in the parameters is executed. However, the Format Function is expecting more arguments as input, and if these arguments are not supplied, the function could read or write the stack.
In this way, it is possible to define a well-crafted input that could change the behavior of the format function, permitting the attacker to cause denial of service or to execute arbitrary commands.
Resolution
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.
- fcchtmlencoding
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.
Default: 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:
- fcchtmlencodingchars
Fetches the specific character value, applies the HTML encoding, and substitutes the actual character value with the encoded value in an FCC file.
Important! To use the fcchtmlencodingchars parameter, the fcchtmlencoding parameter must be set to no.
To apply the HTML encoding to a specific variable in an FCC file, use the following function:
- HTMLENCODE
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:
Important! To use the HTMLENCODE function, the fcchtmlencoding parameter must be set to No.
Vulnerability 7 : SQL Injection
Description
SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.
Resolution
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.
Vulnerability 8 : Missing HttpOnly and Secure Cookie flags
Description
HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
- The example below shows the syntax used within the HTTP response header:
Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]
If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS)flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.
By setting the secure flag, the browser will prevent the transmission of a cookie over an unencrypted channel.
Resolution
KB :TEC1407794
This can be mitigated by setting following ACO parameter to YES:
UseHTTPOnlyCookies
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.
Default: No
To safeguard the information in cookies, set the value of the UseHTTPOnlyCookies parameter to yes.
UseSecureCookies
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.
Default: No
To send cookies over SSL connections, set the UseSecureCookies parameter to yes.