The IBM security framework outlines the foundations of an effective, enterprise-wide security infrastructure as shown in Figure 1. This article focuses on the identity and access management and application security lifecycle management solutions categories.
Figure 1. IBM security framework.
Tivoli Access Manager for e-Business
IBM Tivoli Access Manager for e-Business (TAMeB) provides a solution for centralized authorization, session management, and single sign-on in a Web-based enterprise environment. A common pattern for leveraging TAMeB is to use the TAMeB WebSEAL component as a reverse proxy. WebSEAL is placed in the demilitarised zone of a network to protect Web-based infrastructure in the corporate network. The TAMeB infrastructure is leveraged to provide Web-based single sign-on to Web applications that reside behind WebSEAL. WebSEAL can also be used to provide fine grained authorization of Web resources to maintain a unified security policy across the organization.
Why use TAMeB:
- TAMeB is Common Criteria certified.
- TAMeB provides developer API's for both authentication and authorization.
- TAMeB has been subjected to intense industry testing for many years.
- TAMeB has been proven with a large production installation base.
- TAMeB supports a wide range of authentication mechanisms straight out of the box.
Implementing custom security code can be costly and can introduce potential security vulnerabilities, TAMeB can secure a Web server with little or no modifications to the underlying application's code and provide an in-depth strategy to shield against existing vulnerabilities. By its nature, WebSEAL provides a single point of access to Web-based resources and is able to isolate certain types of typical Web vulnerabilities from back-end applications. However it is important to understand that there are some application-specific vulnerabilities that WebSEAL will not protect against.
IBM Rational AppScan is an offering from IBM that helps ensure the security and compliance of Web applications throughout the software development lifecycle. It offers development and security teams a comprehensive, easily repeatable method of scanning Web applications for Web-based security vulnerabilities. By integrating AppScan into an applications development process, it allows the elimination of security vulnerabilities much earlier in a product lifecycle. Regular security scans in a production environment then ensure its integrity and mitigate the risk to your online business.
The Rational AppScan Suite includes:
- IBM Rational AppScan Standard Edition
- IBM Rational AppScan Tester Edition
- IBM Rational AppScan Enterprise Edition
All three editions provide application scanning, reporting, fix recommendations, and is suited for a variety of users including application testers, developers, security auditors through to senior managers. AppScan even supports the latest Web 2.0 technologies with support for Flash and comprehensive Ajax support.
Role of TAMeB and Rational AppScan
The primary job of TAMeB WebSEAL is to perform enterprise authorization and single sign-on for Web-based resources. The nature of function that TAMeB WebSEAL performs as the initial point of contact for Web-based traffic means that TAMeB is subject to Web-based attacks. WebSEAL is therefore designed to be resistant against many types of Web-based vulnerabilities. However, some vulnerabilities are specific to the applications that are located behind the WebSEAL instances. WebSEAL does not protect against several types of application-specific vulnerabilities.
Rational AppScan is used to scan an application for vulnerabilities during development and in production. Rational AppScan can detect application-specific vulnerabilities that TAMeB WebSEAL cannot defend against. It is best practice to use both products in a defensive, in-depth approach as shown in Figure 2.
The following sections outline several scenarios where these products protect against a given vulnerability.
Figure 2. Typical TAMeB production deployment architecture with Rational AppScan.
For this article, we are using a demonstration environment based around the Rational AppScan demonstration Web site. The Web site we test with is located on the Internet at http://demo.testfire.com, which allows you to personally try some of these security exploits. Figure 3 illustrates our example infrastructure where a fictitious company ondemandinc.com is using TAMeB WebSEAL to protect the Rational AppScan demonstration server http://demo.testfire.com. On WebSEAL we have configured a virtual host junction to the AppScan demonstration site, which requires forms based authentication. WebSEAL is configured to authenticate the subject and use the form's single sign-on functionality to provide authentication credentials to the AppScan demonstration site to achieve single sign-on. Forms single sign-on is a sign-on mechanism for integrating with legacy applications and is only used in this case because other preferable single sign-on mechanisms cannot be used.
Figure 3. Our example TAMeb - AppScan environment.
Tivoli Access Manager WebSEAL provides inherent security due to the nature of the single sign-on and Web authorization function it performs. The authentication and authorization components of WebSEAL have been widely deployed at many customers. It can therefore allow applications to leverage these components and reduce the cost and risk of implementing these services. However, it is not designed to understand all the details of the applications that it protects. Some application specific vulnerabilities such as SQL injection attacks are not be picked up by WebSEAL. Rational AppScan should be used to ensure that application-specific vulnerabilities are identified and eliminated at development and implementation time. To provide a consistent defensive in-depth approach, AppScan should scan the site with and without WebSEAL deployed in the test environment.
Figure 4. AppScan tests applications while TAMeb secures access to them.
Client side attacks: Cross-site scripting
Cross-site scripting (XSS) is a significant security vulnerability that is found in Web-based applications. It is a vulnerability created when the Web application returns data that has been submitted to the application to the client's browser unfiltered, allowing malicious Javascript™ and other embedded objects to run in the client's browser session. For an example of this, see Figure 5 and Figure 6. This example simply displays a Javascript alert in the user's browser session; however by using this same method, it is possible to load an entire library of malicious Javascript files. Statistics suggest that this is the most prevalent method of security vulnerabilities found in Webs ites today.
If you follow this link: http://demo.testfire.net/search.aspx?txtSearch=%3CSCRIPT%3Ealert(%22XSS%22)%3C%2FSCRIPT%3E, you see that we have the ability to embed script into the Altoro Mutual Web pages just by typing some Javascript into the site's search box: <script>alert("AppScan XSS")</script>
Figure 5. Cross-site scripting - injection.
Figure 6. Cross-site scripting - result.
The Rational AppScan role in protecting your Web application from cross-site scripting falls into the detection category. AppScan behaves like a hacker by simulating malicious attacks on the Web application. This automated process quickly checks the entire site's data input fields for vulnerabilities and generates a report based on the results. It also adds new tests as they become known by updating automatically when you launch the AppScan product.
Figure 7. Cross-site scripting - AppScan report.
WebSEAL provides support to prevent cross-site scripting attacks. Through encoding the angle brackets in URL substrings, it can prevent client's browsers from interpreting XSS attempts as HTML source. There are also additional configuration options that allow WebSEAL to detect certain text fragments in URL substrings and invalidate the HTTP request. This configuration option is located in the illegal-url-substrings stanza of the WebSEAL configuration file. The minimum recommended substrings are listed below in Listing 1:
Listing 1. Example [illegal-url-substrings] stanza.
[illegal-url-substrings] substring = javascript: substring = <script substring = <applet substring = <embed substring = <object substring = <iframe |
This configuration allows WebSEAL to recognise illegal URL requests and act appropriately. When accessing the following URL through our secured junction, WebSEAL returns a "bad request" page:
http://demo.testfire.net/search.aspx?txtSearch=%3CSCRIPT%3Ealert(%22XSS%22)%3C%2FSCRIPT%3E.
Figure 8. WebSEAL bad request
Additional notes:
- Substring entries in the configuration file must be ASCII. WebSEAL decodes URLs before checking for the presence of these strings. Therefore, if these strings are present in the URL in another encoding, they will be filtered.
- Substrings are located using a case insensitive search.
- Substring filtering accommodates multi-byte characters.
- The mechanism protects junctioned servers.
Using AppScan and WebSEAL together provides the best choice for protection against cross-site scripting. WebSEAL is capable of identfying an attempt by hackers to use cross-site scripting on your Web application and prevent them on the fly. While AppScan ensures early in the application development process that developers are aware of any security vulnerabilities they cause through lax input, sanitation provides ongoing assurances to security auditors and senior management.
Authentication vulnerabilities
Authentication vulnerabilities are any vulnerabilities that allow a user to by-pass the standard authentication checks of your application.
Authentication by-pass
An example of this can be seen on the AppScan Altoro Web site where it is possible for a user to send a specially crafted URL to directly access a file on the server that would otherwise be protected by access restrictions. This issue is tested by sending two requests with no authentication information. The first request is expected to be redirected back to the login page, while the mutated request (with "%5C" instead of the last "/") is expected to succeed in retrieving the requested page. For full details download the trial AppScan application.
Credential and session prediction
Another simple authentication vulnerability can occur through predictable login credentials allowing unintended access. Examples of this are shown in Table 1:
Table 1. Predictable login credentials
| Username | Password |
|---|---|
| Administrator | password |
| guest | guest |
| admin | admin |
| ... | ... |
These credentials are relatively easy to guess and can often represent common, default accounts that are found in software products today. Similarly, if session management is poorly implemented, it is possible for an attacker to guess a valid session ID and hijack an authenticated session.
Figure 9. AppScan vulnerability report.
Inadequate account protection
Repeated attempts by a malicious user to access an account, by sending a large number of possible password and usernames without limiting the number of attempts, is a authentication vulnerability. When this brute force attack is combined with weak passwords, the vulnerability can become even more significant.
Figure 10. AppScan vulnerability report.
Multiple logins per user
In an organisation where users have numerous logins across different Web applications, security can be compromised unwittingly by the end users. What can often happen is that users write their passwords down on paper.
AppScan can be used to scan for predictable login credentials in back-end applications. Those accounts can then be removed to ensure that only approved access is granted. AppScan can scan thhe target application for the lack of a suitable, enforced account lock-out policy. Each application needs to be independently configured to reflect the new security policy.
TAMeB has built-in authentication and authorization functions that have undergone intense internal and industry testing through a large client installation base. This authentication and authorization infrastructure can be leveraged to implement a defensive, in-depth strategy and prevent the authentication vulnerabilities outlined in this section. TAMeB allows an IT administrator to centrally manage user accounts, control access to Web-based resources, and manage policy across the entire enterprise. TAMeB also provides a flexible mechanism to implement complex authentication requirements and stronger authentication, such as cryptographic token and client certificate authentication.
Examples of policy that TAMeB can enforce are the account lock-out policy and password policy. Administrators can enforce password complexity by setting a TAMeB password policy. WebSEAL can also be configured to lock an account when a configured number of incorrect login attempts are made on an account. IT administrators can use WebSEAL to centrally manage an account lock-out policy across the enterprise to prevent inadequate account protection vulnerabilities.
TAMeB can provide single sign-on capabilities to consolidate all Web-based applications under a single user credential. This reduces the number of account credentials that end users need to maintain and can reduce the potential for risky account management practices.
When using TAMeB, authorised access to Web-based applications can only be granted to users with valid TAMeB accounts. This extra layer of security prevents exposure of default system accounts such as "guest" or "admin", which are often available by default in back-end systems. Access to Web-based enterprise resources needs to be explicitly granted by provisioning a TAMeB account.
Application authentication vulnerabilities are a security risk that can expose a significant amount of user and corporate data to a malicious attacker. A high degree of confidence in application security can be achieved by using AppScan and Tivoli Access Manager for e-Business together.
SQL injection attacks are security vulnerabilities that exploit the database layer of your application. The main cause of this is when user input is not appropriately sanitised before commands are made to the SQL server. An example of this is easily shown on the Altoro Mutual Website: http://demo.testfire.net/bank/login.aspx. In the username field, enter the text: "' OR 1=1 --'", then enter any text as the password, and attempt to login. This small piece of text modifies the underlying SQL statement to always result in a TRUE statement allowing us access to the Internet banking without us knowing any account details. SQL injection attacks can be made easier with additional knowledge of the underlying SQL database which can be often retrieved through Server error messages.
Figure 11. Altoro Mutual SQL injection vulnerability.
Due to the complex nature of SQL injection attacks and the specific occasions for when they occur, WebSEAL does not have enough information in the standard HTTP request and response to protect against SQL injection attacks. In the context of Figure 2, if an SQL injection attack is injected into the body of an HTTP post request, WebSEAL has no context on which tto identify the attack. For example, if the following HTML is posted to the /bank/account.aspx URL of the demo.testfire.net site, an SQL injection vulnerability is exploited:
listAccount=1001160141+and+7659%3D7659
WebSEAL has no idea that this post body is intended for use by a database via an application. It does not have enough information to determine if this is an SQL injection attack.
Although WebSEAL cannot protect against SQL injection attacks out of the box, it can be configured to implement a tactical solution to eliminate an SQL injection vulnerability. Changes to production systems can often take significant time for code development and testing. It is important to fix security exposures as quick as possible. In a scenario where a new AppScan deployment has detected an SQL vulnerability in an existing environment, TAMeB WebSEAL can be used to eliminate the vulnerability using one of two methods. The "dynurl" or authorization rules features of WebSEAL can be configured to block a particular instance of an SQL injection exposure.
Consider the Altoro Mutual URL:
http://demo.testfire.net/bank/transfer.aspx?debitAccount=1001 160141%27%3B&creditAccount=1001160141&transferAmount= 1234&transfer=Transfer+Money |
This URL is vulnerable to an SQL injection attack. A dynurl definition or TAM authorization rule can be used as a tactical fix to remove an exposure while the root cause of the exposure is resolved. A configuration change in WebSEAL has a more contained scope and has a lower risk than a rushed code change to an application.
dynurl
The following must be added to the dynurl.conf configuration file to allow TAMeB WebSEAL to detect the pattern in the URL that enables the attack:
/no_access /@vhost-testfire-http/bank/transfer.aspx?debitAccount=*';* |
The following pdadmin command must be run to update the WebSEAL dynurl configuration:
pdadmin> server task <webseal-server-name> dynurl update |
An ACL must be configured on the /no_access object that denies access to everyone. An example of such an ACL is shown below:
Listing 1. ACL preventing access
pdadmin> acl show noaccess
ACL Name: noaccess
Description:
Entries:
Group iv-admin TcmdbsvaBRl
Group webseal-servers Tgmdbsl
User sec_master TcmdbsvaBRl
Any-other
Unauthenticated |
The ACL is then attached:
pdadmin> acl attach /WebSEAL/<server-root>/<jct>/no_access noaccess |
Authorization rule
The following TAM authorization rule could also be used to remove the SQL injection vulnerability:
Listing 2. Authorization rule
pdadmin>authzrule show debitRule
<xsl:choose>
<xsl:when test='contains(AMWS_qs_debitAccount, "';")'>!FALSE!</xsl:when>
<xsl:otherwise>
!TRUE!
</xsl:otherwise>
</xsl:choose> |
The authorization rule is then attached to one or more resources in the TAM-protected object space to be effective.
pdadmin> authzrule attach /WebSEAL/<server-root>/<jct>/bank/transfer.aspx debitRule |
One potential performance advantage of the authorization rule approach is that it is only evaluated where attached rather than the dynurl list, which is checked on each request.
IBM Rational AppScan detects SQL injection vulnerabilities in target applications. AppScan is used to scan the application and automatically run a series of tests to test for a range of vulnerabilities. In this case, AppScan detects that an SQL vulnerability exists and recommends actions to fix the problem.
Figure 12. AppScan tests for SQL injection vulnerabilities
This article has demonstrated the security benefits and purposes that Tivoli Access Manager for e-Business and Rational AppScan can bring to a corporate IT environment. The role of each product in the overall IBM application security strategy has been clarified. Using Tivoli Access Manager for e-Business and Rational AppScan together throughout the application lifecycle can help you identify and mitigate security vulnerabilities before they result in an expensive security breach.
| Vulnerability | Standard Web site | Web site scanned with AppScan Protected by TAMeB |
|---|---|---|
| Client side attacks: Cross-site scripting |  |  |
| Authorization: Authentication Bypass | | |
| Authentication: Credential/session prediction | | |
| Authentication: Secure account access control | | |
| Command Execution: SQL injection | | |
| Single sign-on: User password management | | |
| Network security: Secure communication | | |
Vulnerable Protected
- IBM Tivoli Access Manager for e-Business Online Help and Information Center
- Rational Support Center
- Rational AppScan trial
- developerWorks application security space
- IBM Internet security systems - a research team dedicated to identifying Internet threats.
- Share your questions and views on this article with the author and other readers in the
Tivoli Security Discussion Forum
.
- To learn more about Tivoli Security, visit the
developerWorks Tivoli zone
. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Get involved in the developerWorks community by participating in
developerWorks blogs
.
Philip Nye is a Software Development Engineer at the Gold Coast Tivoli Lab. In his time at IBM he has worked on the development of Tivoli Access Manager e-business integration components and developed for Tivoli Access Manager for Operating Systems, and is now working to develop stronger integration between Tivoli Products and Microsoft Office SharePoint. His undergraduate degrees are a Bachelor of Engineering in Software Engineering and a Bachelor of Business Management from the University of Queensland.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
