Tivoli Access Manager and Rational AppScan

Application security from development to production

Managing security is a critical part of building and maintaining a modern IT infrastructure. IBM offers several complementary offerings in Security Governance, Risk Management and Compliance to help clients manage the security of their complex IT environments. IBM® Tivoli® Access Manager for e-Business is a market leading software solution in IBM's Identity and Access Management portfolio for managing enterprise Web-based authentication, authorization and single sign-on. IBM now offers a market leading Web application security scanner software offering called IBM Rational® AppScan®. This article compares and contrasts the two offerings as they relate to IBM's security operations strategy and examine what security benefits each brings to the enterprise environment. A number of scenarios are presented to highlight the roles of each of the software solutions and how they complement each other's capabilities.

Philip Nye (philip.nye@au1.ibm.com), Software Development Engineer, IBM

Philip NyePhilip 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.



Trevor Norvill (tnorvill@au1.ibm.com), IT Specialist, IBM

Trevor NorvillTrevor Norvill is a customer facing Engineer based on the Gold Coast in Australia. Trevor works with Tivoli Security products in both pre-sales and post-sales engagements.



03 February 2009

Introduction

IBM security framework

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.
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.

Rational AppScan

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.
Typical TAMeB Production Deployment architecture

Example environment

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.

Forms single sign-on

Forms single sign-on (FSSO) is a single sign-on capability in TAMeB to supply authentication credentials to a back-end application. These credentials are stored in TAM and associated with a user. When a WebSEAL authenticated user accesses a WebSEAL junction, the junction looks up the stored user credentials required by the back-end application and inserts them into the request bound for the target. This means that a user does not have to enter their credentials two times and provides a better user experience.

Figure 3. Our example TAMeb - AppScan environment.
Our example TAMeb/AppScan environment

Best practice

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.
AppScan and Tivoli Access Manager

Client side attacks: Cross-site scripting

Nature Of vulnerability

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.
Javascript injection
Figure 6. Cross-site scripting - result.
Javascript injection result

How AppScan helps

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.
Cross-site scripting - AppScan report

How TAMeb helps

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
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.

Combined IBM value

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

Nature Of vulnerability

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
UsernamePassword
Administratorpassword
guestguest
adminadmin
......

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.
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.
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.

How AppScan helps

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.

How TAMeb helps

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.

Combined IBM value

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 attack

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.

SQL injection sanitising:

In order to prevent the database server from interpreting the input parameters as SQL commands, any non-alphanumeric characters should be escaped. An example of this is:
' OR 1=1 --' should become \ \'\ OR\ 1\=1\ \-\-'
It is the responsibility of the application developer to perform this sanitisation. When rational AppScan detects such a vulnerability in your Web application, it provides coding examples and other steps on how to secure this vulnerability.

Figure 11. Altoro Mutual SQL injection vulnerability.
Altoro Mutual SQL injection vulnerability

How TAMeB helps

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 2. 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 3. 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.

How AppScan helps

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
AppScan and SQL Injection vulnerabilities

Conclusion

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.

VulnerabilityStandard Web siteWeb site scanned with AppScan Protected by TAMeB
Client side attacks: Cross-site scriptingVulnerableProtected
Authorization: Authentication BypassVulnerableProtected
Authentication: Credential/session predictionVulnerableProtected
Authentication: Secure account access controlVulnerableProtected
Command Execution: SQL injectionVulnerableProtected
Single sign-on: User password managementVulnerableProtected
Network security: Secure communicationVulnerableProtected

Vulnerable Vulnerable Protected Protected


References

Resources

  • 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 .

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli (service management), Tivoli
ArticleID=365417
ArticleTitle=Tivoli Access Manager and Rational AppScan
publish-date=02032009