Web security concepts and considerations for IBM WebSphere Portal administrators

Introduction

IBM WebSphere Portal can be leveraged to enforce security, an important requirement for many Web applications. It relies on underlying technologies in delivering certain security functionality and provides integration points for other security-related technologies.

This article is intended to inform WebSphere Portal administrators on how to leverage these capabilities to deliver secure Web applications. It provides examples, including configuration excerpts, but is not intended to replace product documentation as the primary reference for enablement.

This document focuses on WebSphere Portal versions 7.0 and 6.1. Most of these concepts also apply to earlier versions, although WebSphere Portal employed a different member manager in versions prior to 6.1.

WebSphere Portal and authentication

The primary security requirement for most applications is to know who is accessing the system. Authentication is the process of verifying a user's identity.

WebSphere Portal relies on IBM WebSphere Application Server to authenticate users. Anonymous users can access URLs under wps/portal/, whereas authenticated users can access wps/myportal/ (the context root, wps; default home, portal; and personalized home, myportal; can be customized).

WebSphere Application Server protects URLs based on security constraints defined in an application's web.xml. For example, the following definition allows only authenticated users to access /myportal/*:

The means of authentication are defined in security.xml ([profile]/config/cells/[cell name]/). WebSphere Portal can leverage the following WebSphere Application Server's means of authentication:

Authentication against a user registry

Users present credentials [identifier (ID) and password], which WebSphere Application Server (WAS) verifies against a user registry.

Collecting users' credentials
Users can submit credentials with the default log-in portlet included in WebSphere Portal. WebSphere Portal also provides a method of submitting credentials in a URL, via this log-in URL:

http://server:port/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=userid&password=password

The log-in URL enables automatic log in for utility programs; however, it should not be used for regular users since form submission, as the default log-in portlet employs, better protects users' credentials.

Alternatively, you can develop a custom log-in portlet and substitute it for the default log-in portlet:

http://www.ibm.com/support/docview.wss?uid=swg21358508

User registries
User registries may be any of the following:

• Standalone Lightweight Directory Access Protocol (LDAP): A single LDAP with which WebSphere Application Server communicates directly, defined in security.xml as:

• Federated Repository: One or more user repositories (including LDAPs, databases, and/or file repositories) with which WebSphere Application Server communicates via its sub-component Virtual Member Manager (VMM), defined in security.xml as:

VMM's connections to these repositories are defined in its primary configuration file, wimconfig.xml (in [profile]/config/cells/[cell name]/wim/config/).

• Standalone Custom Repository: A custom implementation of WebSphere Application Server's UserRegistry interface with which WebSphere Application Server communicates directly, defined in security.xml as:

• Federated Custom Repository: A custom implementation of WebSphere Application Server's wim.Repository interface with which WebSphere Application Server communicates via VMM. The security.xml file is similar to that of the Federated Repository above.

External security manager (ESM)

An ESM is an independent application that performs authentication and/or authorization for a Web application. WebSphere Application Server can trust an ESM's authentication of users, and this trust can be established by one of several means:

• Trust Association Interceptor (TAI) : A component installed and running on the application server that determines whether incoming requests have been authenticated by its corresponding ESM, generally based on information in the HTTP header (for example, ESM's cookies). If authenticated, the TAI tells WebSphere Application Server to trust the request and identifies the user to it.

• Lightweight third-party authentication (LTPA) junction (IBM Tivoli® Access Manager (TAM) / WebSeal only): TAM/WebSeal can be configured to authenticate users and generate LTPA tokens independently of WebSphere Application Server (refer to the SSO section below for more information on LTPA tokens). With LTPA junctions, no corresponding TAI is required to identify the user; this information is extracted from the LTPA token.

• Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Web authentication: WebSphere Application Server uses SPNEGO tokens directly rather than relying on a SPNEGO TAI to interpret them. This feature was introduced in WebSphere Application Server 7.0.
• HTTP Basic Authentication: WebSphere Portal treats HTTP Basic Authentication (specified by RFC 2617) similarly to an ESM in that the HTTP Basic Authentication TAI must be enabled to authenticate the user to WebSphere Application Server. When enabled, this method of authentication should generally be limited to specific simple clients.

Secure Sockets Layer (SSL) client certificate authentication
In this case a certificate stored in the browser or in a SmartCard is used to authenticate the user. WebSphere Application Server identifies the user by the subject field in the certificate. If you would like to use certificate authentication, consider especially a) certificate revocation and b) the web authentication trust risk.

Single sign-on (SSO)

After authenticating a user, to avoid redundant authentication, WebSphere Application Server creates an LTPA token and sets it in a cookie, telling the client to present it in subsequent requests. LTPA tokens contain the following encrypted information:

1. User's identity
2. Realm (standalone LDAP = ldapserver:port; federated repositories = RealmNameX): This identifies the repository used to verify the user's credentials.
3. Expiration date and time: LTPA tokens are valid for only a limited time.

By default, WebSphere Application Server sets the LTPA token cookie so that the browser presents it in subsequent requests to only that server. Configuring an LTPA domain changes this behavior such that the browser will present the cookie in subsequent requests to any server in that domain.

NOTE: If you set an LTPA domain, do not make its scope too broad. Doing so could result in LTPA tokens being submitted to servers that do not participate in the SSO domain (potentially feeding tokens to would-be attackers). Thus, enabling SSO requires control over or confidence in name resolution (DNS) for the domain.

For example, suppose you have two servers, portal1.ibm.com and quickr1.ibm.com, and you set the LTPA domain to “ibm.com”. When a user logs in to portal1.ibm.com, the LTPA token is set like:

LtpaToken2=...; Path=/; Domain=.ibm.com
(If the LTPA domain were not set, this would be just:
LtpaToken2=...; Path=/
)

When the browser subsequently requests http://quickr1.ibm.com/..., it will include this LTPA token in the request. When the browser requests http://otherserver.ibm.com/... (which does not participate in SSO with portal1 and quickr1), it will likewise include the cookie.

The keys used to encrypt LTPA tokens must be shared between servers participating in the SSO domain. This allows servers to decrypt the LTPA tokens generated by other servers and obtain the information (items 1-3 above) needed to identify the user to the system.

WebSphere Application Server can be configured to set either LtpaToken2-only or LtpaToken-and-LtpaToken2. LtpaToken2 uses stronger encryption and includes additional information so, unless configuring SSO with older versions of WebSphere Application Server, configure LtpaToken2-only.

IMPORTANT: Consider your security requirements when deciding whether to allow LTPA tokens to be communicated over unsecured channels. For example, if SSL is configured for log in only, then the user's credentials could be considered secured in that they would never be delivered un-encrypted (either via HTTPS or the ID in the LTPA token).

However, SSL/login-only could still enable a third party to capture an LTPA token by snooping an unsecured network and, even though the credentials (e.g., user ID and password) were not compromised, the attacker could effectively access WebSphere Portal as that user until the token expires. Enabling HTTPS for all communications would guard against this.

The optional secure attribute for cookies described in RFC 2965 will be set for LTPA tokens if "Requires SSL" is set in the WebSphere Application Server Integrated Solutions Console for Secure administration, applications, and infrastructure > single sign-on (SSO). Refer to APAR PM00610 for more information.

Likewise, the optional secure attribute will be set for JSESSIONID if "Restrict cookies to HTTPS sessions" is selected in the Integrated Solutions Console for Application Servers > WebSphere_Portal > Session management > Cookies. Refer to the "Sessions" section below for more information on JSESSIONID.

WebSphere Portal and authorization

The secondary security requirement for most applications is to restrict access to its resources. Authorization is the process of determining a user's rights to access certain data.

WebSphere Portal offers fine-grained access controls for its resources (pages, portlets, etc.). Roles define levels of access to these resources, and a user's role assignment grants him/her access rights to the associated resource.

Similarly, a group's role assignment grants its members access rights. Resource owners implicitly obtain the Manager role for public resources or the Privileged User role for private resources.

Inheritance/propagation
By default, a resource's role assignments propagate to its children. For example, if you grant a user access to a page, he/she is automatically granted access to its child pages.

Setting role blocks overrides this inheritance. An inheritance role block prevents a child resource from inheriting role assignments from its parent, while a propagation role block prevents a parent resource from propagating role assignments to its children.

Authorization and the user repository

In contrast to the various options for defining WebSphere Application Server's interfaces to user repositories discussed in the “WebSphere Portal and authentication” section above, WebSphere Portal's only interface to the user repository for the purposes of authorization is VMM (with the caveat of re-using WebSphere Application Server group information, below).

Groups can improve administrative efficiency in managing access rights. For example, consider individually granting 100 users rights to a page versus collectively granting them those same rights by making the assignment to a single group to which those 100 users belong.

Groups can be structured in various ways, each with distinct benefits. Consider the following when deciding how groups should be managed in your environment or when discussing group structures with your LDAP administrator:

Direct groups. Only users are members of groups (versus nested groups, below). If access controls are based on direct group membership only, then disabling nested group support can improve performance because WebSphere Portal would not need to iterate through the lists to determine the group hierarchy.

Nested groups. Users and groups can be members of groups (that is, groups of groups can exist in the repository). This approach can provide administrative efficiencies in managing complex organizations via a group hierarchy.

VMM's group configuration for both direct and nested groups is defined in wimconfig.xml as, for example:

In this example, VMM would consider an LDAP object to be a group if it is of the object class groupOfNames. Members of the group will be listed in that object's member attribute.

Several configuration points control WebSphere Application Server, WebSphere Portal, and VMM's resolution of nested groups:
1. WebSphere Portal's Access Control Data Management Service's accessControlDataManagement.enableNestedGroup setting. If WebSphere Portal does not reuse WebSphere Application Server's group membership resolution, then WebSphere Portal may try to resolve nested groups, depending on this setting.
2. VMM groupConfiguration memberAttribute and membershipAttribute's scope. For example, if a VMM API call were made for GroupMembershipControl, level="0" (get direct and nested groups), VMM may avoid making extra calls if membershipAttribute's scope is nested.
3. WebSphere Application Server's definition of the VMM repository's property com.ibm.ws.wim.registry.grouplevel. When WebSphere Application Server authenticates a user, it tries to resolve group membership (see reusing groups, below). This property controls whether the request for GroupMembershipControl to the VMM API is for level="0" (get direct and nested) or level="1" (get direct only).

Membership attribute. User records in the LDAP contain a membership attribute that lists the groups of which the user is a member. This list may or may not include nested groups, depending on the LDAP's implementation.

This approach generally provides a performance improvement since WebSphere Portal can get the user's group membership with a single request rather than inspecting every group's list of members and checking for the given user (and subsequent iterative requests in the case of nested groups).

The membership attribute is defined in wimconfig.xml as, for example:

The scope indicates whether the list contains the groups of which a user is a direct member (direct); both nested and direct groups (nested); or nested, direct, and dynamic groups (all).

Dynamic groups. These are defined as a search query maintained by the LDAP. Dynamic groups allow for greater LDAP administrative efficiency by providing an alternative to maintaining static group membership lists. For example, the USWorkforce group could be defined as all users with c=US.

Dynamic groups are configured in wimconfig.xml by, for example:


Note: Dynamic groups generally impose a high performance overhead because of the number of LDAP requests involved. An alternative, whereby rule based groups are managed within VMM rather than the LDAP, is available on the IBM Lotus and WebSphere Portal Business Solutions Catalog (Nav Code 1WP1002PK).

Application groups. These are maintained in a VMM database repository. Members may exist in other repositories. These are for WebSphere Portal's use only and are useful if you are using a read-only LDAP as the user repository yet still want to use groups in assigning access rights.

Reusing WebSphere Application Server groups. WebSphere Application Server collects group information during authentication and, rather than repeating this work, WebSphere Portal can be configured to re-use WebSphere Application Server's results of determining group membership. This can improve performance. Consider whether WebSphere Application Server's group resolution is the same as VMM's to maintain functionality.

Virtual users and groups
In addition to the users and groups defined in the user repository, you can assign access to the following WebSphere Portal-defined virtual user and groups:

• Anonymous Portal User
• All Authenticated Portal Users
• All Portal User Groups

Administrative interfaces
Consider your security requirements when granting access to administrative interfaces especially. These include administrative pages and portlets, the XML configuration interface, and the Portal Scripting Interface. Consider especially the process of vetting portlets prior to deployment. WebSphere Application Server provides mechanisms that applications can use to assert identity without password verification. This means that an untrustworthy portlet could obtain and assert the WebSphere Application Server's administrator's identity.

Portal access control & external identifiers

Upon initial consideration, an object's distinguished name (DN) seems a good value to uniquely identify it to LDAP clients. In practice, however, this may not be the case.

For instance, consider Jane Smith whose user ID is “jsmith” (DN: uid=jsmith,dc=ibm,dc=com). Jane marries John Doe, takes his surname, and then requests that her user ID be updated to reflect this change. She now has user ID “jsdoe” (DN: uid=jsdoe,dc=ibm,dc=com), so any LDAP client relying on DN (for example, in determining access rights) could break.

The IETF defines the Universally Unique Identifier (UUID) for objects stored in LDAPs by RFC 3928. The UUID must be unique in the directory and must stay the same for the object's lifetime.

By default, VMM uses the UUID to identify users and groups to WebSphere Portal. In turn, WebSphere Portal writes this data to the access control tables and uses it for authorization. (Though VMM can be configured to return the DN instead of the UUID, the UUID value is commonly referred to as the external identifier.)

This is important to consider if you change LDAP servers. The UUID is considered an operational attribute and, as such, is not exported in LDAP Data Interchange Formats (LDIFs).

Directory structures are generally transferred from one LDAP to another by LDIFs, and you cannot not assume that UUIDs in the source LDAP had not already been used in the target LDAP. When the LDIF is imported, the target LDAP generates its own UUIDs.

Even if the entire directory structure is the same (that is, all DNs are the same, and all object classes are the same) in the old and new LDAPs, Portal Access Control (PAC) could still break because the UUIDs are different.

You can avoid this scenario in one of two ways:

• Either clean up the invalid UUID references in PAC tables after the fact, per IBM Support Technote #1377025, “How to fix Portal Access Control settings after user/group external identifiers have changed.”

• Or, configure VMM initially to use DN as the external identifier, per Support Technote #1441092, “CWWIM4001E occurs if LDAP cannot search based on external identifier.”

(Consider the implications if distinguished names are subject to change in your environment.)

Likewise, if users or groups are deleted and recreated in the same LDAP, the UUID generally differs for the recreated object.

As an alternative to managing all access controls itself, WebSphere Portal can be configured to allow an ESM to manage authorization. Authorization can be externalized to an ESM, if, and only if, that ESM also manages authentication. Even in such a configuration, WebSphere Portal will maintain certain access controls (for instance, to virtual resources).

Virtual portals and realms

You can divide a federated repository into realms on the basis of base distinguished names, and you can use these realms to define user bases for virtual portals.

WebSphere Portal maintains realm/virtual portal associations; only users from the associated realm can log in to the virtual portal.

VMM maintains realm definitions. For example, the following wimconfig.xml excerpt defines two realms, VP1Realm and VP2Realm, with each realm containing users and groups from two different repositories:

Sessions

A session is a single user's interactions with a Web application, from when he/she logs in until he/she logs out. WebSphere Portal keeps track of users' sessions with session cookies (JSESSIONID, by default). It uses these in conjunction with LTPA tokens to determine what content to display to a user and enables certain functionality, like resuming a previous session (page last visited, portlet states, etc.).

Session management configuration also imposes certain security constraints. For example, the Security integration setting configures WebSphere Application Server to associate users' identities with their HTTP sessions. In practice this means that, with security integration enabled, if user1 were to obtain user2's session identifier (alone, i.e. LTPAToken is not obtained), user1 could not hijack user2's session.

Also, consider your security requirements when setting the session timeout, after which period of time an unused session will be invalidated. If timeout.resume.session=false, users will be forced to re-authenticate if they make a request with a cookie for a session that is timed-out.

For example, suppose you have an environment in which:

• LTPA tokens expire after 2 hours
• Session timeout is 5 minutes
• timeout.resume.session=false
• Client's OS screen-locks after 15 minutes

User1 logs in, gets an LTPA token and JSESSIONID, and then leaves the browser window open and walks away from the computer.

Anyone could access the unattended computer within the first 5 minutes and navigate through WebSphere Portal for the next 2 hours (or until User1 returns!). Anyone who accessed the unattended computer after 5 minutes would be challenged to re-authenticate before accessing protected pages in WebSphere Portal.

WebSphere Portal's session management configuration can be accessed from the WebSphere Application Server's Integrated Solutions Console (Web container session management settings).

See notes above regarding "Restrict cookies to HTTPS sessions" to maximally protect JSESSIONIDs.

Sessions and ESMs
When an ESM manages authentication, you should generally set timeout.resume.session=true and let the ESM manage session timeouts. Only one entity should time out sessions. If both the ESM and WebSphere Portal are trying to manage timing out sessions, however well the two timeout values are synchronized, unexpected behavior could occur during certain windows. Refer to Support Technote #1253578, “Implementing the timeout.resume.session parameter in WebSphere Portal” for examples.

If timeout.resume.session=true and the client makes a request with a valid LTPA token and expired JSESSIONID, WebSphere Portal will provide it a new JSESSIONID. The user experience is the same as if the session had never expired.

Other LDAP considerations

LDAP referrals
An LDAP may contain pointers to information stored in other LDAPs. When certain information is requested by an LDAP client (such as VMM), a referral in accordance with RFC 3296 may be returned.

WebSphere Portal systems must be explicitly configured to follow these referrals. In such cases, the system will use the same bind ID and password to connect to the referred-to LDAP. The bind ID should have appropriate access rights to the resources on the referred-to LDAP.

LDIFs, ldapsearch, and LDAP browsers
When integrating WebSphere Portal with an LDAP, it is often useful to directly inspect the data (such as sample user and/or group records) stored on the LDAP. This is commonly done via:

LDIFs. LDAP Data Interchange Formats, specified by RFC 2849, are generally provided by an LDAP administrator. Most LDAP administration tools provide a means of exporting user and/or group records into text files, commonly referred to as LDIFs.

ldapsearch. Command line tool for requesting data from an LDAP. Most ldapsearch implementations write their output as LDIFs. In addition to collecting LDIFs, ldapsearch is also useful in that it allows you to verify search filters, bind ids, and their access levels. If you do not have ldapsearch installed, WebSphere Application Server provides this implementation, per the Support Technote, “Using ldapsearch to debug LDAP configuration problems.”

LDAP browser. A GUI that allows you to browse the directory. LDAP browsers often provide other functionality as well, including exporting LDIFs, editing records, and constructing and executing searches.

Users' passwords

Many organizations specify password requirements as a security measure. WebSphere Portal has limited abilities to impose such requirements (such as when signing up as a user via the Registration/Edit My Profile portlet).

You can specify password length requirements and valid characters in the PUMA Validation Service. Any such configuration should agree with the user repositories' configurations to avoid errors during registration.

More complex specifications (for example, to protect against dictionary attacks) would require a custom registration portlet, a restriction by the user repository, or both. Similarly, locking out a user after a certain number of failed log-ins would need to be implemented outside of WebSphere Portal (by the user repository, by an ESM, or in a custom log-in portlet).

Remember Me and Step-up Authentication

WebSphere Portal can be configured to remember users on return visits by use of the WP RememberMeConfigService. By default, this functionality is disabled.

If enabled, remembered users may be fully authenticated if, and only if, Step-up Authentication is also enabled. Otherwise, the user is simply identified to WebSphere Portal (which can be useful for customizing public content) but not allowed access to the protected context (personalized home).

You configure Step-up Authentication by using the WP StepUpConfigService and use it to impose stricter authentication requirements for accessing specific WebSphere Portal resources. For example, a remembered user might be allowed to visit certain pages but could be prompted to resubmit credentials when he attempts to access administrative interfaces.

NOTE: Since Remember Me cookies generally do not expire as quickly as LTPA tokens, take special care if you leverage this functionality in your application. Browser, cross-site scripting (XSS), or network vulnerabilities could allow attackers to obtain the Remember Me cookie and impersonate a valid user.

Impersonation

WebSphere Portal can be configured to allow administrators to impersonate users. This can be useful in troubleshooting access control or personalization problems in your application.

Enabling impersonation requires that the WP Authentication Service be configured appropriately and a custom portlet be written and deployed. Take special care, especially in assigning access rights to the impersonation portlet, if your application leverages this functionality.

Also consider what impersonation means for your SSO environment. Refer to this article for more information on how to limit the scope of impersonation in SSO environments.

SSL

SSL secures communications over networks. It is the industry standard for this purpose and is addressed extensively in numerous public and commonly available publications. SSL's encryption occurs between the application and network layers.

Transport Layer Security (TLS) supersedes SSL, though the term “SSL” is commonly used to refer to both, and is specified by IETF's RFC 5246. For the core functionality of WebSphere Portal, there are two types of communication that can be secured by SSL:

• HTTPS. Communications between the client (for instance, a browser) and server can be secured by SSL. You can terminate the HTTPS pipe at the Web server, or you can optionally configure SSL for the communications between the Web server plug-in and WebSphere Application Server. The WebSphere Portal Information Center specifies two options for enabling HTTPS:

• LDAP/SSL (or, LDAPS, commonly). Communications between the LDAP clients (WebSphere Application Server and/or VMM, depending on the security configuration) and server are secured by SSL. This guards against network snooping to obtain users' credentials. Consider enabling LDAP/SSL if the security of any or all of the network path between WebSphere Portal and LDAP cannot be guaranteed.

WebSphere Application Server's SSL implementation is JavaTM Secure Sockets Extension (JSSE) as specified by Java 2 Standard Edition (J2SE). Refer to WebSphere Application Server documentation for more information on its SSL implementation.

Cross-site scripting

XSS attacks attempt to inject scripts into pages that will be viewed by other users (or expose vulnerabilities in sites' scripts for DOM-based attacks). These are typically attempts to collect session cookies and thereby impersonate a valid user.

Consider these common means of implementing XSS attacks:

• Reflected / non-persistent. Client input is directly reflected in the page returned to the client. For instance, suppose an attacker tricks a victim into submitting maliciously designed URLs or input to the server. Due to an XSS vulnerability, the returned page contains a malicious script that the client then executes.

Since the server that set the LTPA token also sent this page, the browser allows the script to access the LTPA token. The malicious script sends the token to the attacker, who uses it to access the compromised system as the victim.

• DOM-based. These are quite similar to reflected attacks, except in these attacks a vulnerability in the server's scripts is leveraged. For instance, an attacker tricks the victim into requesting a maliciously formed URL from the server. The server's JavaScript has an XSS vulnerability and acts on the malicious URL in such a way as to deliver the LTPA token to the attacker.

• Stored/persistent. User input is stored by the application and is used to build pages served to other users. For instance, an attacker sends the victim an email containing a malicious script. The victim authenticates and views this email in the Web application.

Due to an XSS vulnerability, the email is not properly sanitized, and the malicious script is executed and sends the attacker the victim's LTPA token as in the reflected / non-persistent attacks.

WebSphere Portal offers protection against XSS, enabled with the security.css.protection setting in the Configuration Service. This protection is enabled by default and encodes certain user input before it reaches the portlet. Take special care in theme and portlet development, if this has been disabled. Even when enabled, portlet developers still must take steps to ensure that user-submitted data is correctly encoded before entering page source. For more details, refer to the developerWorks article, “Prevent a cross-site scripting attack.”

WebSphere Application Server offers protection against XSS, enabled with the com.ibm.ws.security.addHttpOnlyAttributeToCookies custom property for Global Security. When set, the HTTP-only attribute, HttpOnly, will be set for LTPA tokens. Browsers will not allow scripts access to cookies for which HTTPOnly is set. As of this writing, HttpOnly has not been formalized in an IETF RFC but is slated for inclusion in a future RFC based on this draft.

Because of the nature of XSS, site (portlet and theme) developers and testers are primarily responsible for guarding against XSS attacks. However, several XSS vulnerabilities have been identified in common components of older versions of WebSphere Portal.

Configuration choices, intelligent application development, application testing, applying the latest maintenance, and monitoring the IBM Support site for notifications on security vulnerabilities (for example, Flash document # 1421660) are your best protections against XSS.

Securing the operating system

To deliver a secure solution running on WebSphere Portal, you must secure the underlying operating system. With appropriate OS-level access and WebSphere Application Server/Portal and/or system knowledge, an attacker could manually modify a few files (such as security.xml, wimconfig.xml, and fileRegistry.xml) and grant himself administrative access to your application.

If you want to store an administrative user(s) in fileRegistry.xml as a back-door if/when the enterprise's user repository is unavailable, do so only after considering whether your OS is secured and whether this circumvents any controls imposed by the enterprise (like password requirements).

Conclusion

Administrators, architects, and developers are faced with a variety of factors when planning for Web application security. WebSphere Portal and WebSphere Application Server can be leveraged to address many of these security requirements.

Resources and Glossary

IBM WebSphere Portal InfoCenter:
http://www.ibm.com/software/lotus/support/information-centers/#Portal

IBM WebSphere Application Server InfoCenter:
http://www.ibm.com/software/webservers/appserv/was/library/v70/

Various Internet Engineering Taskforce RFCs:
http://www.ietf.org

WebSphere Application Server Security
http://www.ibm.com/developerworks/websphere/zones/was/security/

The Web Application Hacker's Handbook,
Copyright 2008 Dafydd Stuttard, Marcus Pinto

Web Security, Privacy, & Commerce,
Copyright 2002 O'Reilly Media, Inc.

LDAP: Lightweight Directory Access Protocol – often used as an interface to user repositories – defined by Internet Engineering Task Force (IETF) in various requests for comments (RFCs), including 1777, 3494, and 4510. The LDAP server is commonly referred to as simply the LDAP.

VMM: Virtual Member Manager, a sub-component of WebSphere Application Server that serves as a level of abstraction between WebSphere Portal and WebSphere Application Server and user repositories.

About the author

Jason Wicker is a Software Engineer with IBM Software Group. He has served in technical support for WebSphere Portal, focusing on security and administration, since 2007. He joined IBM after graduating from the University of North Carolina with a B.Sc. in Applied Science - Computer Science in 1998. Jason can be reached at jwicker@us.ibm.com.

Introduction

IBM WebSphere Portal can be leveraged to enforce security, an important requirement for many Web applications. It relies on underlying technologies in delivering certain security functionality and provides integration points for other security-related technologies.

This article is intended to inform WebSphere Portal administrators on how to leverage these capabilities to deliver secure Web applications. It provides examples, including configuration excerpts, but is not intended to replace product documentation as the primary reference for enablement.

This document focuses on WebSphere Portal versions 7.0 and 6.1. Most of these concepts also apply to earlier versions, although WebSphere Portal employed a different member manager in versions prior to 6.1.

WebSphere Portal and authentication

The primary security requirement for most applications is to know who is accessing the system. Authentication is the process of verifying a user's identity.

WebSphere Portal relies on IBM WebSphere Application Server to authenticate users. Anonymous users can access URLs under wps/portal/, whereas authenticated users can access wps/myportal/ (the context root, wps; default home, portal; and personalized home, myportal; can be customized).

WebSphere Application Server protects URLs based on security constraints defined in an application's web.xml. For example, the following definition allows only authenticated users to access /myportal/*:

The means of authentication are defined in security.xml ([profile]/config/cells/[cell name]/). WebSphere Portal can leverage the following WebSphere Application Server's means of authentication:

Authentication against a user registry

Users present credentials [identifier (ID) and password], which WebSphere Application Server (WAS) verifies against a user registry.

Collecting users' credentials
Users can submit credentials with the default log-in portlet included in WebSphere Portal. WebSphere Portal also provides a method of submitting credentials in a URL, via this log-in URL:

http://server:port/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=userid&password=password

The log-in URL enables automatic log in for utility programs; however, it should not be used for regular users since form submission, as the default log-in portlet employs, better protects users' credentials.

Alternatively, you can develop a custom log-in portlet and substitute it for the default log-in portlet:

http://www.ibm.com/support/docview.wss?uid=swg21358508

User registries
User registries may be any of the following:

• Standalone Lightweight Directory Access Protocol (LDAP): A single LDAP with which WebSphere Application Server communicates directly, defined in security.xml as:

• Federated Repository: One or more user repositories (including LDAPs, databases, and/or file repositories) with which WebSphere Application Server communicates via its sub-component Virtual Member Manager (VMM), defined in security.xml as:

VMM's connections to these repositories are defined in its primary configuration file, wimconfig.xml (in [profile]/config/cells/[cell name]/wim/config/).

• Standalone Custom Repository: A custom implementation of WebSphere Application Server's UserRegistry interface with which WebSphere Application Server communicates directly, defined in security.xml as:

• Federated Custom Repository: A custom implementation of WebSphere Application Server's wim.Repository interface with which WebSphere Application Server communicates via VMM. The security.xml file is similar to that of the Federated Repository above.

External security manager (ESM)

An ESM is an independent application that performs authentication and/or authorization for a Web application. WebSphere Application Server can trust an ESM's authentication of users, and this trust can be established by one of several means:

• Trust Association Interceptor (TAI) : A component installed and running on the application server that determines whether incoming requests have been authenticated by its corresponding ESM, generally based on information in the HTTP header (for example, ESM's cookies). If authenticated, the TAI tells WebSphere Application Server to trust the request and identifies the user to it.

• Lightweight third-party authentication (LTPA) junction (IBM Tivoli® Access Manager (TAM) / WebSeal only): TAM/WebSeal can be configured to authenticate users and generate LTPA tokens independently of WebSphere Application Server (refer to the SSO section below for more information on LTPA tokens). With LTPA junctions, no corresponding TAI is required to identify the user; this information is extracted from the LTPA token.

• Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Web authentication: WebSphere Application Server uses SPNEGO tokens directly rather than relying on a SPNEGO TAI to interpret them. This feature was introduced in WebSphere Application Server 7.0.
• HTTP Basic Authentication: WebSphere Portal treats HTTP Basic Authentication (specified by RFC 2617) similarly to an ESM in that the HTTP Basic Authentication TAI must be enabled to authenticate the user to WebSphere Application Server. When enabled, this method of authentication should generally be limited to specific simple clients.

Secure Sockets Layer (SSL) client certificate authentication
In this case a certificate stored in the browser or in a SmartCard is used to authenticate the user. WebSphere Application Server identifies the user by the subject field in the certificate. If you would like to use certificate authentication, consider especially a) certificate revocation and b) the web authentication trust risk.

Single sign-on (SSO)

After authenticating a user, to avoid redundant authentication, WebSphere Application Server creates an LTPA token and sets it in a cookie, telling the client to present it in subsequent requests. LTPA tokens contain the following encrypted information:

1. User's identity
2. Realm (standalone LDAP = ldapserver:port; federated repositories = RealmNameX): This identifies the repository used to verify the user's credentials.
3. Expiration date and time: LTPA tokens are valid for only a limited time.

By default, WebSphere Application Server sets the LTPA token cookie so that the browser presents it in subsequent requests to only that server. Configuring an LTPA domain changes this behavior such that the browser will present the cookie in subsequent requests to any server in that domain.

NOTE: If you set an LTPA domain, do not make its scope too broad. Doing so could result in LTPA tokens being submitted to servers that do not participate in the SSO domain (potentially feeding tokens to would-be attackers). Thus, enabling SSO requires control over or confidence in name resolution (DNS) for the domain.

For example, suppose you have two servers, portal1.ibm.com and quickr1.ibm.com, and you set the LTPA domain to “ibm.com”. When a user logs in to portal1.ibm.com, the LTPA token is set like:

LtpaToken2=...; Path=/; Domain=.ibm.com
(If the LTPA domain were not set, this would be just:
LtpaToken2=...; Path=/
)

When the browser subsequently requests http://quickr1.ibm.com/..., it will include this LTPA token in the request. When the browser requests http://otherserver.ibm.com/... (which does not participate in SSO with portal1 and quickr1), it will likewise include the cookie.

The keys used to encrypt LTPA tokens must be shared between servers participating in the SSO domain. This allows servers to decrypt the LTPA tokens generated by other servers and obtain the information (items 1-3 above) needed to identify the user to the system.

WebSphere Application Server can be configured to set either LtpaToken2-only or LtpaToken-and-LtpaToken2. LtpaToken2 uses stronger encryption and includes additional information so, unless configuring SSO with older versions of WebSphere Application Server, configure LtpaToken2-only.

IMPORTANT: Consider your security requirements when deciding whether to allow LTPA tokens to be communicated over unsecured channels. For example, if SSL is configured for log in only, then the user's credentials could be considered secured in that they would never be delivered un-encrypted (either via HTTPS or the ID in the LTPA token).

However, SSL/login-only could still enable a third party to capture an LTPA token by snooping an unsecured network and, even though the credentials (e.g., user ID and password) were not compromised, the attacker could effectively access WebSphere Portal as that user until the token expires. Enabling HTTPS for all communications would guard against this.

The optional secure attribute for cookies described in RFC 2965 will be set for LTPA tokens if "Requires SSL" is set in the WebSphere Application Server Integrated Solutions Console for Secure administration, applications, and infrastructure > single sign-on (SSO). Refer to APAR PM00610 for more information.

Likewise, the optional secure attribute will be set for JSESSIONID if "Restrict cookies to HTTPS sessions" is selected in the Integrated Solutions Console for Application Servers > WebSphere_Portal > Session management > Cookies. Refer to the "Sessions" section below for more information on JSESSIONID.

WebSphere Portal and authorization

The secondary security requirement for most applications is to restrict access to its resources. Authorization is the process of determining a user's rights to access certain data.

WebSphere Portal offers fine-grained access controls for its resources (pages, portlets, etc.). Roles define levels of access to these resources, and a user's role assignment grants him/her access rights to the associated resource.

Similarly, a group's role assignment grants its members access rights. Resource owners implicitly obtain the Manager role for public resources or the Privileged User role for private resources.

Inheritance/propagation
By default, a resource's role assignments propagate to its children. For example, if you grant a user access to a page, he/she is automatically granted access to its child pages.

Setting role blocks overrides this inheritance. An inheritance role block prevents a child resource from inheriting role assignments from its parent, while a propagation role block prevents a parent resource from propagating role assignments to its children.

Authorization and the user repository

In contrast to the various options for defining WebSphere Application Server's interfaces to user repositories discussed in the “WebSphere Portal and authentication” section above, WebSphere Portal's only interface to the user repository for the purposes of authorization is VMM (with the caveat of re-using WebSphere Application Server group information, below).

Groups can improve administrative efficiency in managing access rights. For example, consider individually granting 100 users rights to a page versus collectively granting them those same rights by making the assignment to a single group to which those 100 users belong.

Groups can be structured in various ways, each with distinct benefits. Consider the following when deciding how groups should be managed in your environment or when discussing group structures with your LDAP administrator:

Direct groups. Only users are members of groups (versus nested groups, below). If access controls are based on direct group membership only, then disabling nested group support can improve performance because WebSphere Portal would not need to iterate through the lists to determine the group hierarchy.

Nested groups. Users and groups can be members of groups (that is, groups of groups can exist in the repository). This approach can provide administrative efficiencies in managing complex organizations via a group hierarchy.

VMM's group configuration for both direct and nested groups is defined in wimconfig.xml as, for example:

In this example, VMM would consider an LDAP object to be a group if it is of the object class groupOfNames. Members of the group will be listed in that object's member attribute.

Several configuration points control WebSphere Application Server, WebSphere Portal, and VMM's resolution of nested groups:
1. WebSphere Portal's Access Control Data Management Service's accessControlDataManagement.enableNestedGroup setting. If WebSphere Portal does not reuse WebSphere Application Server's group membership resolution, then WebSphere Portal may try to resolve nested groups, depending on this setting.
2. VMM groupConfiguration memberAttribute and membershipAttribute's scope. For example, if a VMM API call were made for GroupMembershipControl, level="0" (get direct and nested groups), VMM may avoid making extra calls if membershipAttribute's scope is nested.
3. WebSphere Application Server's definition of the VMM repository's property com.ibm.ws.wim.registry.grouplevel. When WebSphere Application Server authenticates a user, it tries to resolve group membership (see reusing groups, below). This property controls whether the request for GroupMembershipControl to the VMM API is for level="0" (get direct and nested) or level="1" (get direct only).

Membership attribute. User records in the LDAP contain a membership attribute that lists the groups of which the user is a member. This list may or may not include nested groups, depending on the LDAP's implementation.

This approach generally provides a performance improvement since WebSphere Portal can get the user's group membership with a single request rather than inspecting every group's list of members and checking for the given user (and subsequent iterative requests in the case of nested groups).

The membership attribute is defined in wimconfig.xml as, for example:

The scope indicates whether the list contains the groups of which a user is a direct member (direct); both nested and direct groups (nested); or nested, direct, and dynamic groups (all).

Dynamic groups. These are defined as a search query maintained by the LDAP. Dynamic groups allow for greater LDAP administrative efficiency by providing an alternative to maintaining static group membership lists. For example, the USWorkforce group could be defined as all users with c=US.

Dynamic groups are configured in wimconfig.xml by, for example:


Note: Dynamic groups generally impose a high performance overhead because of the number of LDAP requests involved. An alternative, whereby rule based groups are managed within VMM rather than the LDAP, is available on the IBM Lotus and WebSphere Portal Business Solutions Catalog (Nav Code 1WP1002PK).

Application groups. These are maintained in a VMM database repository. Members may exist in other repositories. These are for WebSphere Portal's use only and are useful if you are using a read-only LDAP as the user repository yet still want to use groups in assigning access rights.

Reusing WebSphere Application Server groups. WebSphere Application Server collects group information during authentication and, rather than repeating this work, WebSphere Portal can be configured to re-use WebSphere Application Server's results of determining group membership. This can improve performance. Consider whether WebSphere Application Server's group resolution is the same as VMM's to maintain functionality.

Virtual users and groups
In addition to the users and groups defined in the user repository, you can assign access to the following WebSphere Portal-defined virtual user and groups:

• Anonymous Portal User
• All Authenticated Portal Users
• All Portal User Groups

Administrative interfaces
Consider your security requirements when granting access to administrative interfaces especially. These include administrative pages and portlets, the XML configuration interface, and the Portal Scripting Interface. Consider especially the process of vetting portlets prior to deployment. WebSphere Application Server provides mechanisms that applications can use to assert identity without password verification. This means that an untrustworthy portlet could obtain and assert the WebSphere Application Server's administrator's identity.

Portal access control & external identifiers

Upon initial consideration, an object's distinguished name (DN) seems a good value to uniquely identify it to LDAP clients. In practice, however, this may not be the case.

For instance, consider Jane Smith whose user ID is “jsmith” (DN: uid=jsmith,dc=ibm,dc=com). Jane marries John Doe, takes his surname, and then requests that her user ID be updated to reflect this change. She now has user ID “jsdoe” (DN: uid=jsdoe,dc=ibm,dc=com), so any LDAP client relying on DN (for example, in determining access rights) could break.

The IETF defines the Universally Unique Identifier (UUID) for objects stored in LDAPs by RFC 3928. The UUID must be unique in the directory and must stay the same for the object's lifetime.

By default, VMM uses the UUID to identify users and groups to WebSphere Portal. In turn, WebSphere Portal writes this data to the access control tables and uses it for authorization. (Though VMM can be configured to return the DN instead of the UUID, the UUID value is commonly referred to as the external identifier.)

This is important to consider if you change LDAP servers. The UUID is considered an operational attribute and, as such, is not exported in LDAP Data Interchange Formats (LDIFs).

Directory structures are generally transferred from one LDAP to another by LDIFs, and you cannot not assume that UUIDs in the source LDAP had not already been used in the target LDAP. When the LDIF is imported, the target LDAP generates its own UUIDs.

Even if the entire directory structure is the same (that is, all DNs are the same, and all object classes are the same) in the old and new LDAPs, Portal Access Control (PAC) could still break because the UUIDs are different.

You can avoid this scenario in one of two ways:

• Either clean up the invalid UUID references in PAC tables after the fact, per IBM Support Technote #1377025, “How to fix Portal Access Control settings after user/group external identifiers have changed.”

• Or, configure VMM initially to use DN as the external identifier, per Support Technote #1441092, “CWWIM4001E occurs if LDAP cannot search based on external identifier.”

(Consider the implications if distinguished names are subject to change in your environment.)

Likewise, if users or groups are deleted and recreated in the same LDAP, the UUID generally differs for the recreated object.

As an alternative to managing all access controls itself, WebSphere Portal can be configured to allow an ESM to manage authorization. Authorization can be externalized to an ESM, if, and only if, that ESM also manages authentication. Even in such a configuration, WebSphere Portal will maintain certain access controls (for instance, to virtual resources).

Virtual portals and realms

You can divide a federated repository into realms on the basis of base distinguished names, and you can use these realms to define user bases for virtual portals.

WebSphere Portal maintains realm/virtual portal associations; only users from the associated realm can log in to the virtual portal.

VMM maintains realm definitions. For example, the following wimconfig.xml excerpt defines two realms, VP1Realm and VP2Realm, with each realm containing users and groups from two different repositories:

Sessions

A session is a single user's interactions with a Web application, from when he/she logs in until he/she logs out. WebSphere Portal keeps track of users' sessions with session cookies (JSESSIONID, by default). It uses these in conjunction with LTPA tokens to determine what content to display to a user and enables certain functionality, like resuming a previous session (page last visited, portlet states, etc.).

Session management configuration also imposes certain security constraints. For example, the Security integration setting configures WebSphere Application Server to associate users' identities with their HTTP sessions. In practice this means that, with security integration enabled, if user1 were to obtain user2's session identifier (alone, i.e. LTPAToken is not obtained), user1 could not hijack user2's session.

Also, consider your security requirements when setting the session timeout, after which period of time an unused session will be invalidated. If timeout.resume.session=false, users will be forced to re-authenticate if they make a request with a cookie for a session that is timed-out.

For example, suppose you have an environment in which:

• LTPA tokens expire after 2 hours
• Session timeout is 5 minutes
• timeout.resume.session=false
• Client's OS screen-locks after 15 minutes

User1 logs in, gets an LTPA token and JSESSIONID, and then leaves the browser window open and walks away from the computer.

Anyone could access the unattended computer within the first 5 minutes and navigate through WebSphere Portal for the next 2 hours (or until User1 returns!). Anyone who accessed the unattended computer after 5 minutes would be challenged to re-authenticate before accessing protected pages in WebSphere Portal.

WebSphere Portal's session management configuration can be accessed from the WebSphere Application Server's Integrated Solutions Console (Web container session management settings).

See notes above regarding "Restrict cookies to HTTPS sessions" to maximally protect JSESSIONIDs.

Sessions and ESMs
When an ESM manages authentication, you should generally set timeout.resume.session=true and let the ESM manage session timeouts. Only one entity should time out sessions. If both the ESM and WebSphere Portal are trying to manage timing out sessions, however well the two timeout values are synchronized, unexpected behavior could occur during certain windows. Refer to Support Technote #1253578, “Implementing the timeout.resume.session parameter in WebSphere Portal” for examples.

If timeout.resume.session=true and the client makes a request with a valid LTPA token and expired JSESSIONID, WebSphere Portal will provide it a new JSESSIONID. The user experience is the same as if the session had never expired.

Other LDAP considerations

LDAP referrals
An LDAP may contain pointers to information stored in other LDAPs. When certain information is requested by an LDAP client (such as VMM), a referral in accordance with RFC 3296 may be returned.

WebSphere Portal systems must be explicitly configured to follow these referrals. In such cases, the system will use the same bind ID and password to connect to the referred-to LDAP. The bind ID should have appropriate access rights to the resources on the referred-to LDAP.

LDIFs, ldapsearch, and LDAP browsers
When integrating WebSphere Portal with an LDAP, it is often useful to directly inspect the data (such as sample user and/or group records) stored on the LDAP. This is commonly done via:

LDIFs. LDAP Data Interchange Formats, specified by RFC 2849, are generally provided by an LDAP administrator. Most LDAP administration tools provide a means of exporting user and/or group records into text files, commonly referred to as LDIFs.

ldapsearch. Command line tool for requesting data from an LDAP. Most ldapsearch implementations write their output as LDIFs. In addition to collecting LDIFs, ldapsearch is also useful in that it allows you to verify search filters, bind ids, and their access levels. If you do not have ldapsearch installed, WebSphere Application Server provides this implementation, per the Support Technote, “Using ldapsearch to debug LDAP configuration problems.”

LDAP browser. A GUI that allows you to browse the directory. LDAP browsers often provide other functionality as well, including exporting LDIFs, editing records, and constructing and executing searches.

Users' passwords

Many organizations specify password requirements as a security measure. WebSphere Portal has limited abilities to impose such requirements (such as when signing up as a user via the Registration/Edit My Profile portlet).

You can specify password length requirements and valid characters in the PUMA Validation Service. Any such configuration should agree with the user repositories' configurations to avoid errors during registration.

More complex specifications (for example, to protect against dictionary attacks) would require a custom registration portlet, a restriction by the user repository, or both. Similarly, locking out a user after a certain number of failed log-ins would need to be implemented outside of WebSphere Portal (by the user repository, by an ESM, or in a custom log-in portlet).

Remember Me and Step-up Authentication

WebSphere Portal can be configured to remember users on return visits by use of the WP RememberMeConfigService. By default, this functionality is disabled.

If enabled, remembered users may be fully authenticated if, and only if, Step-up Authentication is also enabled. Otherwise, the user is simply identified to WebSphere Portal (which can be useful for customizing public content) but not allowed access to the protected context (personalized home).

You configure Step-up Authentication by using the WP StepUpConfigService and use it to impose stricter authentication requirements for accessing specific WebSphere Portal resources. For example, a remembered user might be allowed to visit certain pages but could be prompted to resubmit credentials when he attempts to access administrative interfaces.

NOTE: Since Remember Me cookies generally do not expire as quickly as LTPA tokens, take special care if you leverage this functionality in your application. Browser, cross-site scripting (XSS), or network vulnerabilities could allow attackers to obtain the Remember Me cookie and impersonate a valid user.

Impersonation

WebSphere Portal can be configured to allow administrators to impersonate users. This can be useful in troubleshooting access control or personalization problems in your application.

Enabling impersonation requires that the WP Authentication Service be configured appropriately and a custom portlet be written and deployed. Take special care, especially in assigning access rights to the impersonation portlet, if your application leverages this functionality.

Also consider what impersonation means for your SSO environment. Refer to this article for more information on how to limit the scope of impersonation in SSO environments.

SSL

SSL secures communications over networks. It is the industry standard for this purpose and is addressed extensively in numerous public and commonly available publications. SSL's encryption occurs between the application and network layers.

Transport Layer Security (TLS) supersedes SSL, though the term “SSL” is commonly used to refer to both, and is specified by IETF's RFC 5246. For the core functionality of WebSphere Portal, there are two types of communication that can be secured by SSL:

• HTTPS. Communications between the client (for instance, a browser) and server can be secured by SSL. You can terminate the HTTPS pipe at the Web server, or you can optionally configure SSL for the communications between the Web server plug-in and WebSphere Application Server. The WebSphere Portal Information Center specifies two options for enabling HTTPS:

• LDAP/SSL (or, LDAPS, commonly). Communications between the LDAP clients (WebSphere Application Server and/or VMM, depending on the security configuration) and server are secured by SSL. This guards against network snooping to obtain users' credentials. Consider enabling LDAP/SSL if the security of any or all of the network path between WebSphere Portal and LDAP cannot be guaranteed.

WebSphere Application Server's SSL implementation is JavaTM Secure Sockets Extension (JSSE) as specified by Java 2 Standard Edition (J2SE). Refer to WebSphere Application Server documentation for more information on its SSL implementation.

Cross-site scripting

XSS attacks attempt to inject scripts into pages that will be viewed by other users (or expose vulnerabilities in sites' scripts for DOM-based attacks). These are typically attempts to collect session cookies and thereby impersonate a valid user.

Consider these common means of implementing XSS attacks:

• Reflected / non-persistent. Client input is directly reflected in the page returned to the client. For instance, suppose an attacker tricks a victim into submitting maliciously designed URLs or input to the server. Due to an XSS vulnerability, the returned page contains a malicious script that the client then executes.

Since the server that set the LTPA token also sent this page, the browser allows the script to access the LTPA token. The malicious script sends the token to the attacker, who uses it to access the compromised system as the victim.

• DOM-based. These are quite similar to reflected attacks, except in these attacks a vulnerability in the server's scripts is leveraged. For instance, an attacker tricks the victim into requesting a maliciously formed URL from the server. The server's JavaScript has an XSS vulnerability and acts on the malicious URL in such a way as to deliver the LTPA token to the attacker.

• Stored/persistent. User input is stored by the application and is used to build pages served to other users. For instance, an attacker sends the victim an email containing a malicious script. The victim authenticates and views this email in the Web application.

Due to an XSS vulnerability, the email is not properly sanitized, and the malicious script is executed and sends the attacker the victim's LTPA token as in the reflected / non-persistent attacks.

WebSphere Portal offers protection against XSS, enabled with the security.css.protection setting in the Configuration Service. This protection is enabled by default and encodes certain user input before it reaches the portlet. Take special care in theme and portlet development, if this has been disabled. Even when enabled, portlet developers still must take steps to ensure that user-submitted data is correctly encoded before entering page source. For more details, refer to the developerWorks article, “Prevent a cross-site scripting attack.”

WebSphere Application Server offers protection against XSS with the web container custom property com.ibm.ws.webcontainer.HTTPOnlyCookies. When set, the HTTP-only attribute, HttpOnly, will be set for the cookies in this list. Browsers should not allow scripts access to cookies for which HTTPOnly is set per RFC 6265. (Note: this article previously recommended using the WAS global security custom property com.ibm.ws.security.addHttpOnlyAttributeToCookies, but this can interfere with the impersonation functionality in WebSphere Portal).

Because of the nature of XSS, site (portlet and theme) developers and testers are primarily responsible for guarding against XSS attacks. However, several XSS vulnerabilities have been identified in common components of older versions of WebSphere Portal.

Configuration choices, intelligent application development, application testing, applying the latest maintenance, and monitoring the IBM Support site for notifications on security vulnerabilities (for example, Flash document # 1421660) are your best protections against XSS.

Securing the operating system