IBM WebSphere Developer Technical Journal: WebSphere Application Server V6 advanced security hardening -- Part 1

Overview and approach to security hardening

Security consists of more than just some firewalls at the edge of your network protecting you from the outside. It is a difficult and complex set of actions and procedures that strive to strengthen your systems as much as is appropriate. This article covers many aspects of security in general, details the IBM® WebSphere® Application Server security architecture, and discusses hardening a WebSphere Application Server environment. Part 1 of 2.


Keys Botzum, Senior Technical Staff Member , EMC

Keys Botzum is a Senior Technical Staff Member with IBM Software Services for WebSphere. Mr. Botzum has over 10 years of experience in large scale distributed system design and additionally specializes in security. Mr. Botzum has worked with a variety of distributed technologies, including Sun RPC, DCE, CORBA, AFS, and DFS. Recently, he has been focusing on J2EE and related technologies. He holds a Masters degree in Computer Science from Stanford University and a B.S. in Applied Mathematics/Computer Science from Carnegie Mellon University. Mr. Botzum has published numerous papers on WebSphere and WebSphere security. Additional articles and presentations by Keys Botzum can be found at, as well as on IBM developerWorks WebSphere. He is also co-author of IBM WebSphere: Deployment and Advanced Configuration.

developerWorks Professional author

07 December 2005

Also available in Chinese

From the IBM WebSphere Developer Technical Journal

The article is based on the security chapter from the book IBM WebSphere: Deployment and Advanced Configuration. It has been significantly updated for WebSphere Application Server V6 and edited to focus solely on hardening. The text has been edited and formatted for publication as a standalone article While this article is based on WebSphere Application Server V6, most of the issues here apply equally well to V5 and V5.1. Where an issue is unique to V6, we will identify it specifically. Nearly everything else applies to all three major releases, although the screen shots and examples are from V6.


For Versions 6.1 and 7.0
An updated version of this article is available for WebSphere Application Server V6.1 and V7.0.

In this article, we will cover several aspects of security. We will briefly discuss why security is important and then detail the WebSphere Application Server security architecture. We will cover some subtle points of WebSphere Application Server security and then move on to detailed discussions of how to harden a WebSphere Application Server environment to be secure. Finally, we will provide some tips for troubleshooting security problems. Given the limited space available, much of this material will be high level and will not delve into the details. Wherever possible, we will point the reader to appropriate references for detailed information.

Why security?

Hopefully, most readers realize that security is a key aspect of enterprise systems. Nonetheless, we will briefly justify security in order to introduce some common ways of thinking about it.

The fundamental purpose of security is to keep the bad people out of your systems. More precisely, security is the process of applying various techniques to prevent unauthorized parties, known as intruders, from gaining unauthorized access to things.

There are many types of intruders out there: foreign spy agencies, corporations in competition with you, hackers, and even your own employees. Each of these intruders has different motivations, different skills and knowledge, different access, and different levels of need. For example:

  • An employee may have a grudge against the company, and while employees have tremendous levels of internal access and system knowledge, they probably have limited resources and hacking skill.
  • An external hacker is probably an expert in security attacks, but may not have any particular grudge against you.
  • A foreign spy agency, depending on your business, may have a great deal of interest in you and possess tremendous resources.

Intruders may be after your systems for one of two reasons: to gain access to information that they should not have, or to alter the behavior of a system in some way. In the latter case, by changing the system behavior, they may seek to perform transactions that benefit them, or they may wish to simply cause your system to fail in some interesting way in an effort to harm your organization.

As you can see, there are many different types of intruders and motivations and, as we will discuss later, many different types of attacks. As you plan your security, you need to be aware of this.

We also want to emphasize that security should not be seen as simply a gate that keeps the "outsiders" out. That is far too simplistic a view. Many organizations today focus their security efforts entirely on people outside of the organization in the mistaken belief that only outsiders are a danger. This is simply not the case. People within your organization are also very likely to attack your systems. Several recent studies have indicated that perhaps as many as half of all break-ins are caused by or involve employees or contractors within the organization.

Even assuming that every person on your network is in fact trustworthy, can you also assume they never make a mistake? Given the rise of e-mail-based viruses, it is reckless to assume your entire internal network can be trusted. It cannot.

It is crucial that your security efforts protect your systems from all potential intruders. This is why this article is so long, and in two parts. Security consists of more than just some firewalls at the edge of your network protecting you from the "outside." It is a difficult and complex set of actions and procedures that strive to strengthen your systems as much as appropriate.

Limits and reality

It is important to realize that there is no such thing as a perfectly secure system. Your goal is to protect the system as well as you can within the constraints of the business. When thinking about security, you ideally should:

  • Analyze the various points of attack.
  • Consider the risk of an attack at each point.
  • Determine the potential for damage from a successful attack that results in a security breach.
  • Estimate the cost of preventing each attack.

When estimating the damage of a security breach, never forget that security breaches can cause loss of faith in users of the system. Thus, the "cost of security breach" may include very high indirect costs (such as, loss of investor confidence).

Once you have performed the steps listed above, you can then determine appropriate tradeoffs of risk versus cost. Essentially, the goal is to make the cost to the intruder of breaking into your system exceed the value of what is gained, while at the same time ensuring that the business can bear the costs of running the secure system. (This can be a problem when some hackers break into systems simply for the fun of it. What you can hope is that by creating a reasonably secure environment, intruders will move on to easier targets.) Ultimately, the level of security required is a business -- not a technical -- decision. However, as technicians, we must help all parties understand the value and importance of security. That said, with the exception of protection against internal application attacks, most of the security hardening steps suggested in this paper are fairly low cost, and so most organizations should implement them all. What is not covered here are more sophisticated and expensive security approaches -- stronger authentication, auditing, intrusion detection, and so on -- that go far beyond the native WebSphere Application Server product capabilities.

Security is a large topic, and it is impossible to completely cover all aspects of security in this article. This article is not intended to be an introduction to security or a tutorial on how to secure WebSphere Application Server-based systems. Rather, it is a high-level overview or checklist of the core technical issues as they relate to WebSphere Application Server that need to be considered. The information in this article should be used in conjunction with a much larger effort of creating a secure enterprise.

Readers interested in learning more should refer to the Resources section. In particular, my Web site provides a high-level, if somewhat dated, overview of the basics of application security.

Social engineering

Since this is a technical article, we are focused on technical solutions to securing systems. In fact, we are focused primarily on the WebSphere Application Server piece of the security puzzle. Nonetheless, you should be aware that it is often easier to compromise systems using social engineering techniques. That is, by tricking the human beings that work for your organization, attackers are able to gain access to systems and information to which they should not have access. (See What is social engineering? for more.)

Perhaps the one conclusion of relevance to this article's discussion that we can learn from social engineering attack techniques is the fact that by using social engineering, your attackers may be coming from within your network. This again serves to emphasize the earlier point that security that is focused solely on keeping the intruders out of the network is insufficient. This is why the discussion here will focus on security at multiple levels. Each level tries to thwart different types of attacks and also provides more barriers to attackers.

Total system view: the details matter

Before delving into specific point-by-point recommendations, we want to take a moment to outline the fundamental techniques for creating secure systems. The fundamental view is to look at every system boundary or point of sharing and examine what actors have access to those boundaries or shared components. That is, given that this boundary exists (we presume reasonable trust within a subsystem), what can an intruder do to break this boundary? Or, given that something is shared, can intruders share something inappropriately? Most boundaries are obvious: network connections, process-to-process communication, file systems, operating system interfaces, and so on, but some boundaries are more subtle. For example, if one application uses J2C resources within WebSphere Application Server, consider the possibility that some other application might try to access those same resources. This occurs because there is a system boundary between the first application and WebSphere Application Server and a second application and WebSphere Application Server. Perhaps both applications can access this common resource (in fact, they can). This is a case of inappropriate sharing.

To prevent these various forms of attack, you can apply a number of well-known techniques. For lower-level network-based attacks, apply encryption and network filtering. This denies the intruder the ability to see or access things they should not see. We also rely on operating systems to provide mechanisms to protect operating system resources from abuse. For example, we wouldn't want ordinary user-level code to gain access to the system bus and directly read internal communication. We also leverage the fact that most modern operating systems possess fairly robust protections for system APIs. Unfortunately, in a WebSphere Application Server environment, these operating system protections are of limited value because they are based on process identity, which is a very coarse-grained concept when you consider application servers servicing requests from thousands of users at once.

At a high level, we apply authentication and authorization rigorously. Every API, every method, and every resource potentially needs to require some form of authorization. That is, access to these things must be restricted based upon need. And, of course, authorization is of little value without robust authentication. Authentication is concerned with knowing the identity of the caller. We add the word "robust" because an easily forged authentication is of little value.

Where appropriate authentication and authorization are not available, we resort to clever design and procedures to prevent potential problems. This is how we protect J2C resources. Since WebSphere Application Server does not provide for authorization of access to J2C resources, we instead, apply other techniques to limit (based on configuration) the ability of applications to reference J2C resources inappropriately.

As you might imagine, examining all of the system boundaries and shared components is a difficult task. And, in fact, securing a system leads to thinking deeply about complexity. Perhaps the hardest truth about security is that creating a secure system works against abstraction. That is, one of the core principles of good abstraction is the hiding of concerns from higher-level components. That is a highly desirable and good thing. Unfortunately, intruders aren't kind to us. They don't care about our abstractions or our good designs. Their goal is to break our systems any way they can. And, in doing so, they will look for holes in our wonderful designs. Thus, to validate a system's security, you have to think about it at every level of abstraction: at the highest architectural level, but also at the lowest level of detail. Rigorous reviews of everything are required.

The smallest mistake can undermine the integrity of an entire system. This is best exemplified by the technique of taking control of C/C++ based systems by using buffer overrun techniques. Essentially, an intruder passes in a string that is too large for some existing buffer. The extra information then overlays a part of the running program and causes the runtime to execute instructions that it should not execute. With care, one can cause a program to do almost anything. (For more details, see Buffer Overflows -- What Are They and What Can I Do About Them?) As a security architect, to even identify this attack, you have to understand deeply how the C/C++ runtime manages memory and executes running programs. You also have to review every line of code to find this particular hole, assuming you understood that it existed.

Today, we know about the attack, yet it continues to be successful because individual programmers make very small bad decisions that compromise entire systems. Thankfully, this particular attack seems to be infeasible in Java™. But, do not believe for an instant that there aren't other small errors out there that lead to compromise. Think hard about security; it is hard.

Hardening security overview

The J2EE™ specification and WebSphere Application Server provide a powerful infrastructure for implementing secure systems. Unfortunately, many people are not aware of all of the issues surrounding creating a secure WebSphere Application Server based system. There are many degrees of freedom and many different sources of this information. This tends to lead to people overlooking security issues and to deploying systems that are not secure. This section attempts to summarize the key issues.

Security hardening is the act of configuring WebSphere Application Server, developing applications, and configuring various other related components to maximize security -- in essence, to prevent, block, or mitigate various forms of attack. To do this effectively, it is important to consider the forms of attack. There are four basic approaches to attacking an application server:

There are four basic approaches to attacking a J2EE-based system:

  • Network-based attacks
    These attacks rely on low-level access to network packets and attempt to harm the system by altering this traffic or discovering information from these packets.

  • Machine-based attacks
    In this case, the intruder has access to a machine on which WebSphere Application Server is running. The goal is to limit the ability to damage the configuration or to see things that shouldn't be seen.

  • Application-based external attacks
    In this scenario, an intruder uses application-level protocols (HTTP, IIOP, JMX. Web services, and so on) to access the application, perhaps via a Web browser or some other client type.The intruder uses this access to try to circumvent the normal application usage and to do inappropriate things. The key is that the attack is executed using well-defined APIs and protocols. The intruder is not necessarily outside the company, but he is executing code from outside of the application itself. These types of attacks are the most dangerous because they usually require the least skill and can be done from a great distance as long as IP connectivity is available.

  • Application-based internal attacks
    In this case, we are concerned with the danger of a rogue application. In this scenario, multiple applications share the same WebSphere Application Server infrastructure, and we do not completely trust each application. While perfect security is unachievable here, there are techniques that can limit how much damage each application can do. Internal attacks are normally an indicator of untrusted code that is "evil." Generally, that is the concern here. But always remember that a hacker might compromise an application remotely (via the previous techniques), and then leverage internal attack methods to do even more harm.

Note that we will not be considering one other form of technical attack, Denial of Service (DoS) attacks. While very important, this is beyond the scope of this article. Preventing DoS attacks require different techniques that go well beyond what an application server can provide. You will need to consider network traffic monitors, rate limiters, intrusion detection tools, and more.

Hardening approach

We are now going to identify the various known steps you should take to protect the WebSphere Application Server infrastructure and applications from these four forms of attack. Ideally, you would organize the information into four buckets, one for each form of attack. Unfortunately, attacks don't neatly divide along those lines. Several different techniques of protection help with multiple forms of attack, and sometimes a single attack may leverage multiple forms of intrusion to achieve the end goal. For example, in the simplest case, network sniffing is used to obtain passwords, and those passwords are then used to mount an application-level attack. Instead, we organize the hardening techniques into a logical structure based on when the activity occurs, or based on the role of the person concerned with these issues:

  • Infrastructure
    Actions that can be taken to configure the WebSphere Application Server infrastructure for maximum security. These are typically done once, when the infrastructure is built out and involve only the system administrators.

  • Application configuration
    Actions that can be taken by application developers and administrators and are visible during the deployment process. Essentially, these are application design and implementation decisions that are visible to the WebSphere Application Server administrator and are verifiable (possibly with some difficulty) as part of the deployment process. This section will have a large number of techniques, further reinforcing the point that security is not a bolt-on; security is the responsibility of every person involved in the application design, development, and deployment.

  • Application design and implementation
    Actions that are taken by developers and designers during development that are crucial to security but may be difficult to detect as part of the deployment process.

  • Application isolation
    This is explicitly discussed separately because of the complexity of the issues involved.

Within each section, we order the various techniques by priority. Prioritization is, of course, subjective. We've attempted to prioritize threats within each area using roughly this method:

  • Machine-based threats are less likely than network threats because access to the machine in production is usually restricted. If this isn't the case in your environment, then these threats become very likely. You need to restrict access to those machines.

  • The most serious attacks are performed remotely using only IP connectivity. This implies that all communication must be authenticated.

  • Traffic should be encrypted to protect it, but encryption of WebSphere Application Server internal traffic is less important than encryption of traffic that travels "beyond WebSphere Application Server." This is because the network traversed may have more points, where an attacker can snoop traffic.

To help you tie these techniques back to the classes of attack just presented, for each technique we will include the following graphic:

The four squares will be shaded as appropriate to represent the type of attack this technique helps to prevent:

  • N = Network-based
  • M = Machine-based
  • E = External application-based
  • I = Internal application-based

Keep in mind that internal applications can always take advantage of "external" methods of attack. Thus, we don't explicitly list I when E is already present. We do, however, list "I" when the vulnerability is uniquely exploitable by internal applications.

SSL overview

Secure sockets layer (SSL) is a key component of the WebSphere Application Server security architecture. SSL is used extensively for securing communication. It is used to protect HTTP traffic, IIOP traffic, LDAP traffic, and SOAP traffic. SSL requires the use of public/private key pairs, and in the case of WebSphere Application Server, these keys are stored in key stores. Because of the key importance of SSL in securing the infrastructure, we are going to briefly digress and cover some key aspects of SSL as they related to WebSphere Application Server. This discussion is intentionally superficial and discusses only the key points you need to properly configure SSL.

Public Key Cryptography is fundamentally based upon a public/private key pair. These two keys are related cryptographically. The important point is that the keys are asymmetric -- information encrypted with one key can be decrypted using the other key. The private key is, well, private. That is, you must always protect that private key. Should anyone else ever gain access to the private key, they can then use it as "proof" of identity and act as you. It's like a password, only more difficult to change. Possessing the private key is proof of identity. The public key is the part of the key pair that can be shared with others.

If there was a secure way to distribute public keys to trusted parties, that would be enough. However, Public Key Cryptography takes things a step further and introduces the idea of signed public keys. A signed public key has a digital signature (quite analogous to a human signature) that states that the signer vouches for the public key. The signer is assuring that the party that possesses the private key corresponding to the signed public key is the party identified by the key. These signed public keys are called certificates. Well-known signers are called Certificate Authorities (CA). It is also possible to sign a public key using itself. These are known as self-signed certificates. These self-signed certificates are no less secure than certificates signed by a certificate authority. They are just harder to manage, as we'll see in a moment.

Figure 1 shows the basic process of creating a certificate using a CA and distributing it, in this case, to perform server authentication with SSL. That is, the server possesses a certificate that it uses to identify itself to the client. The client does not have a certificate and is, therefore, anonymous to SSL.

Figure 1. Server SSL authentication - certificate creation and distribution
Figure 1. Server SSL authentication - certificate creation and distribution

When looking at this picture, take note that the client must possess the certificate that signed the generated public key of the server. This is the crucial part of trust. Since the client trusts any certificate it has (which in this case includes the CA certificate), it trusts certificates that the CA has signed. It's worth noting that if you were to use self-signed certificates, you would need to distribute manually the self-signed certificate to each client, rather than relying on a well-known CA certificate that is likely already built into the client. This is no less secure, but if you have many clients, it is much harder to manage distributing all of those signing certificates (one for each server) to all clients. It's much easier to distribute just one CA certificate that signs many certificates. That's pretty much it for server authentication using SSL. After the authentication, SSL will actually use secret key encryption to secure the channel, but the details of that aren't relevant to this discussion.

When a client authenticates itself to a server, the process is similar although the roles are reversed. In order for a server to authenticate a client (this is often called client certificate authentication), the client must possess a private key and corresponding certificate, while the server must possess the corresponding signing certificate. That's really all there is to it. Notice what wasn't required. SSL certificate authentication merely determines that the certificate is valid, not who the certificate represents. That is the responsibility of later, post-SSL processing. This has significant implications as we'll see in a moment.

In summary, because SSL uses certificate authentication, each side of the SSL connection must possess the appropriate keys in a key store file. Whenever you configure SSL key stores, think about the fundamental rules about which party needs which keys. Usually, that will tell you what you need.

A powerful SSL trick

As we just mentioned, once SSL validates the certificate, the authentication process is over from SSL's perspective. What ideally should happen next is that another component will look at the identity in the certificate, and then use that identity to make an authorization decision. That authorization decision could be the client deciding the server is trusted (Web browsers do this when verifying that the name in the certificate is the same as the Web server's hostname) or the server extracting the user's name and then using that to create credentials for future authorization decisions (this is what WebSphere Application Server does when end user's authenticate). Unfortunately, not all systems have that capability. This is where you can take advantage of a popular SSL trick: limiting the valid certificates.

Notice that in the previous scenario involving client authentication, the client presents a certificate that is validated by the server against the set of trusted certificates. Once it is validated, the SSL handshake completes. If we limit the signers we trust on the server, we can limit who can even complete that SSL handshake. In the extreme with self-signed certificates, we can create a situation where there is only one signer: the self-signed certificate. This means that there is only one valid client side private key that can be used to connect to this SSL endpoint -- the private key we generated when we created the self-signed certificate in the first place. This is how we can easily limit who can even connect to a system over SSL, even if the server side components don't provide authorization. You can think of this as creating a secure trusted tunnel at the network layer. Assuming we've configured everything correctly, only special trusted clients can even be connecting over this transport. That's very useful in several situations in WebSphere Application Server, which we will discuss later.

Managing SSL

As we have already seen, WebSphere Application Server manages keys in key store files. There are two types of key files: key stores and trust stores. A trust store is nothing more than a key store that, by convention, contains only trusted signers. Thus, you should place CA certificates and other signing certificates in a trust store and private information (personal certificates with private keys) in the key store.

Unfortunately, there is a catch to this simple system. Most of WebSphere Application Server uses the new Java-defined key store format known as Java Key Stores (JKS). (In fact, WebSphere Application Server SSL Configurations support three modern key database formats: JKS, JCEKS, and PKCS12. ) The IBM HTTP Server and the WebSphere Application Server Web server plug-in use an older key format known as the KDB format (or more correctly, the CMS format). The two formats are similar in function, but are incompatible in format. Be careful not to mix them up.

IBM provides a tool known as ikeyman for managing key stores. It is a very simple tool that creates key stores, generates self-signed certificates, imports and exports keys, and generates certificate requests for a CA. Use this tool when managing key stores. As of WebSphere Application Server V5.1, a single version of ikeyman supports all of the needed key store formats. If you are using an older version of WebSphere Application Server, the ikeyman included with WebSphere Application Server in the bin directory does not support the KDB format. To create KDB files, you'll have to run the older ikeyman that should be available under the GSK5 install directory that is implicitly installed when you install WebSphere Application Server. On Windows™, the GSK is usually under c:\program files\ibm\gsk5. On Solaris™, it is usually under /opt/ibm/gsk5. Other platforms are similar.

WebSphere Application Server SSL configurations

It is helpful to briefly describe how SSL configuration works in WebSphere Application Server. The WebSphere Application Server server code uses SSL configurations whenever an SSL based transport is used. This means that HTTPS, IIOP/SSL, SSL channels, and LDAP/SSL all share common code for managing SSL configuration. Thus, as you configure SSL later, you'll want to understand this common information. SSL configurations are managed from the global security panel in the SSL area. When you click there, you'll see a list of SSL configurations defined for the cell. You can add you own SSL configurations for new uses or modify the existing configurations. Obviously, you should be cautious when modifying the existing configurations as they are shared by multiple components.

Figure 2 shows an example SSL configuration.

Figure 2. SSL configuration
Figure 2. SSL configuration

The key items of interest here are:

  • Client authentication
    Setting this informs WebSphere Application Server that inbound requests should be authenticated using client certificate authentication. This means that the client will be required to present a certificate and that it will be validated against the signers specified in the configured trust store. Whether anything is done with the identity depends on the protocol. In many situations, WebSphere Application Server does nothing with the identity in the certificate, which is why the SSL trick we mentioned earlier is so helpful.

  • Security level
    You should set this to HIGH (this is the default) to limit the acceptable ciphers unless you have a good reason not to. If you wish, you can use the pick list to specify precisely the ciphers to use, but this isn't usually necessary.

The lower half of the SSL panel lets you specify the key store file and trust store file. See Figure 3. In this case, you'll need to specify the file system location (which must be the same on every server), the key file password (which is used by the server to decrypt the file), and the key file format. WebSphere Application Server supports several standard formats, but JKS is the default. As we said earlier, the key file contains the private keys, while the trust file contains the signing keys.

Figure 3. SSL configuration continued
Figure 3. SSL configuration continued

Now that we have discussed the basics of SSL in WebSphere Application Server, it is time to turn our attention to the real purpose of security -- creating a secure environment.

Infrastructure-based preventative measures

When securing the infrastructure, you must first understand the components to be secured. As with any vulnerability analysis, we start by identifying the components and their external communication paths. This analysis doesn't uncover internal application vulnerabilities, but does expose most others. It's useful to review a standard WebSphere Application Server topology and see all of the network links and protocols. As someone concerned about security, you need to know about all of these links and focus on securing those links. These links represent the coarsest grained system boundaries we mentioned earlier. See Figure 4.

Figure 4. Network link picture
Figure 4. Network link picture

The letters on the links in Figure 4 indicate the protocols used across those communication links. For each protocol, we list the usage and also provide some information on firewall friendliness:

  • H = HTTP traffic

    • Usage: Browser to Web server, Web server to app server, and admin Web client.
    • Firewall friendly.
  • W = WebSphere Application Server internal communication

    • Usage: Admin clients and WebSphere Application Server internal server admin traffic. Note that WebSphere Application Server internal communication uses one of several protocols:
      • RMI/IIOP or SOAP/HTTP: Admin client protocol is configurable.
      • File transfer service (dmgr to node agent): Uses HTTP(S).
      • DCS (Distributed Consistency Service) RMM (Reliable Multicast Messaging): Uses private protocol. Used by memory to memory replication, stateful session EJBs, dynacache, and the high availability manager.
    • SOAP/HTTP firewall friendly. DCS can be firewall friendly.
  • I = RMI/IIOP communication

    • Usage: EJB clients (standalone and Web container).
    • Generally firewall hostile because of dynamic ports and embedded IP addresses (which can interfere with firewalls that perform Network Address Translation).
  • M = SIB messaging protocol

    • Usage: JMS client to messaging engine.
    • Protocol: Proprietary
    • Firewall friendly as can fix ports used. Likely NAT firewall hostile.
  • MQ = MQ protocol

    • Usage: WebSphere MQ clients (true clients and application servers).
    • Protocol: Proprietary
    • Firewall feasible (there are a number of ports to consider). See WebSphere MQ support pac MA86.
  • L = LDAP communication

    • Usage: WebSphere Application Server verification of user information in registry.
    • Protocol: TCP stream formatted as defined in LDAP RFC
    • Firewall friendly
  • J = JDBC database communication via vendor JDBC drivers

    • Usage: Application JDBC access and WebSphere Application Server session database access.
    • Protocol: Network protocol is proprietary to each database.
    • Firewall aspects depend on database (generally firewall friendly).
  • S = SOAP

    • Usage: SOAP clients
    • Protocol: Generally SOAP/HTTP
    • Firewall friendly when SOAP/HTTP.

As Figure 4 shows, a typical WebSphere Application Server configuration has a number of network links. It is important to protect traffic on each of those links as much as possible to stop intruders. In the remainder of this section, we will discuss the steps required to secure the infrastructure just described.

1. Put the Web server in the DMZ without WebSphere Application Serverattack code

There are three fundamental principles of a DMZ that you need to consider:

  • Inbound network traffic from outside must be terminated in the DMZ. A network transparent load balancer, such as Network Dispatcher, doesn't meet that requirement alone.

  • The type of traffic and number of open ports from the DMZ to the intranet must be limited.

  • Components running in the DMZ must be hardened and follow the principle of least function and low complexity.

In a typical DMZ configuration, there is an outer firewall, the DMZ network containing as little as possible, and an inner firewall protecting the production network.

Thus, it is normal to place the Web server in the DMZ and the WebSphere Application Server application servers inside the inner firewall. This is ideal, as the Web server machine then can have a simple configuration and can require little software. It also serves as a point in the DMZ that terminates inbound requests. And finally, the only port that must be opened on the inner firewall is the HTTP(S) port for the target application servers. These steps make the DMZ a very hostile place for an attacker. If you place WebSphere Application Server on a machine in the DMZ, far more software must be installed on those machines, and more ports must be opened on the inner firewall so WebSphere Application Server can access the production network. This largely undermines the value of the DMZ.

2. Separate your production network from your intranet attack code

Today, most organizations understand the value of a DMZ that separates the outsiders on the Internet from the intranet. However, far too many organizations fail to realize that many intruders are on the inside. As we stated earlier, you need to protect against internal as well as external threats. Just as you protect yourself against the large untrusted Internet, you should also protect your production systems from the large and untrustworthy Intranet. Separate your production networks from your internal network using firewalls. These firewalls, while likely more permissive than the Internet-facing firewalls, can still block numerous forms of attack. Applying this step and the previous step you should end up with a firewall topology like the one shown in Figure 5. For more information on firewall port assignments, see Firewall Port Assignments in WebSphere Application Server.

Notice that we've placed wsadmin on the edge of the firewall. This is attempting to show that while we prefer that wsadmin be run from only within the production network (within the protected area), you can run wsadmin through a firewall fairly easily. We've also shown EJB clients on the edge as they might be on either side of the firewall.

Figure 5. Recommended firewall configuration
Figure 5. Recommended firewall configuration

We've chosen to show only a single firewall and not a full DMZ facing the Intranet. This is the most common topology. However, we are increasingly seeing full DMZs (with a Web server in the internal DMZ) protecting the production network from the non-production Intranet. That is certainly a reasonable approach.

3. Enable global securityattack code

By default, WebSphere Application Server provides no security. This means that all network links are unencrypted and unauthenticated. As a result, any user with access to the deployment manager (HTTP to the Web admin console or SOAP/IIOP to the JMX management ports) can use the WebSphere Application Server administrative tools to perform any administrative operation, up to and including removing existing servers. Needless to say, this presents a great security risk.

Therefore, at a minimum, you should enable WebSphere Application Server global security in a production environment to prevent these trivial forms of attack. Once WebSphere Application Server security is enabled globally, the WebSphere Application Server internal links between the deployment manager and the application servers and traffic from the administrative clients (Web and command line) to the deployment manager are encrypted and authenticated (see Figure 5). Among other things, this means that administrators will be required to authenticate when running the administrative tools.

Enable Single Sign-On

When enabling WebSphere Application Server global security with LTPA, always enable Single Sign-On (SSO). This tells WebSphere Application Server to create LTPA cookies and send them back to the browser. It makes it possible for the application server to remember the user's identity across requests. If you do not enable SSO, WebSphere Application Server will not create a cookie and must reauthenticate the user on every request. In many cases, this will not work. With Form-based login without SSO, every login results in the user being returned to the login page because the redirect to the page after login never succeeds, as WebSphere Application Server has forgotten the user's identity immediately after login. More importantly, it is inefficient. Since every request results in a reauthentication of the user, the performance of the system can be quite poor.

We haven't mentioned SWAM because we prefer not to use it for several reasons:

  1. It will be deprecated in the future.
  2. It is not supported on WebSphere Application Server Network Deployment (ND).
  3. It relies on the HTTP session for security. Since the HTTP session is not designed to be secure, that isn't a great idea.

Be aware that enabling global security does not protect all network links, but rather a number of key internal links. We'll discuss securing additional network links later in this article. We will also discuss securing applications by leveraging WebSphere Application Server security now that it has been enabled.

4. Use HTTPS from the browserattack code

If your site performs any authentication or has any activities that should be protected, use HTTPS from the browser to the Web server. If HTTPS is not used, information such as passwords, user activities, WebSphere Application Server session IDs, and LTPA security tokens can potentially be seen by intruders as the traffic travels over the external network.

While you can transmit LTPA tokens over an unencrypted channel, for maximum protection, it is best that they are sent over an encrypted link. If an LTPA token is successfully captured, the thief can impersonate the user identified until it expires.

5. Configure secure file transfer attack code

Even when security is enabled, the deployment manager continues to communicate configuration updates to the node agents using an unauthenticated protocol. More precisely, node agents pull admin configuration updates from the deployment manager using an unauthenticated file transfer service. Thus, any foreign client can potentially connect to a deployment manager and upload arbitrary files. If numerous large files are uploaded, the operating system could run out of disk space, resulting in a total failure. It is also theoretically possible to download files that are being replicated from the deployment manager to nodes. However, given the brief and transient nature of these files, this is less likely.

To ensure that the deployment manager only responds to file transfer requests from trusted servers in the cell, you must install the filetransferSecured application and replace the existing insecure application. Because this application is a system application, it is not normally visible, but it is there. You must remove it and install a new one using wsadmin. IBM provides a script for this, but be aware that at the time of writing this article, the instructions in the V6 Information Center are not quite correct (and this is not documented in the V5 or V5.1 Information Centers). To install the filetransferSecured application, follow the steps below (we show a Windows example, but UNIX® is essentially the same).

cd <profilehome>\bin
wsadmin.bat -user <wasadminuser> -password
<waspassword> wsadmin>source ../../../bin/redeployFileTransfer.jacl wsadmin>fileTransferAuthenticationOn <your cell
name> <dmgr node name> dmgr wsadmin>$AdminConfig save

We are assuming a WebSphere Application Server ND environment. If you are using WebSphere Application Server base, the server name is obviously not dmgr. It is probably server1.

If you can't remember the cell name and node name, you can find them by looking under the config directory for the profile. Remember that the node is the node of the deployment manager, and thus the name likely ends in "CellManager."

6. Configure certificates to ensure reasonable Web-based administrative certificate validationattack code

When security is enabled and you use the Web administrative console, your Web browser will likely warn you that the certificate is not trusted and that the hostname does not match the hostname in the certificate. You should see messages like those in Figures 6 and 7 (we are using the Mozilla Web browser).

Figure 6. Mozilla informing the user that the certificate is not trusted
Figure 6. Mozilla informing the user that the certificate is not trusted
Figure7. Mozilla informing the user that the certificate is specifying a hostname different from the hostname that the browser is expecting
Figure 7. Mozilla informing the user that the certificate is specifying a different hostname than the browser is expecting

These messages are warnings indicating possible security problems related to the certificates that WebSphere Application Server is using. When you update the default keyring, you can take steps to prevent these warnings. First, generate a certificate where the Subject name is the same as the hostname of the machine running the administrative Web application (the one server in base or the deployment manager in other editions). That will take care of the second browser error message. The first message can be prevented by either buying a certificate from a well-known CA for the WebSphere Application Server's administrative console (this is probably overkill), or by accepting the certificate permanently. Keep in mind that if you ever see this message again, that is quite possibly a sign of a security breach. Thus, your system administration staff should be trained to recognize that this warning should only occur when the certificate is updated. If it occurs at other times, it's a red flag warning that the system has been compromised.

7. Protect JNDI attack code

J2EE applications use JNDI to find other applications and resources. WebSphere Application Server therefore makes extensive use of JNDI. Unfortunately, the JNDI namespace is by default insecure. Everyone has read access, while all authenticated users have read/write access. As a result, any client with IIOP access to the cell (the JNDI namespace is accessible via IIOP remotely) can modify the namespace in arbitrary ways if they have a valid user ID and password in the WebSphere Application Server registry. Needless to say, this is quite a risk.

To address this, you should restrict access to the JNDI namespace by specifying something more restrictive administratively using the Environment => Naming => CORBA Naming Service Groups area in the admin console. We recommend you restrict the namespace such that only "Everyone" has read access and no one has read/write access. This is reasonably safe as there is nothing sensitive stored in JNDI (passwords are not stored there). An intruder could potential determine server endpoints and such, but little else. The key is to prevent malicious updates. See Figure 8 for an example. Notice that we've removed the default ALL AUTHENTICATED grants.

Figure 8. Naming authorization with only EVERYONE having read
Figure 8. Naming authorization with only EVERYONE having read

This setting ensures that attackers cannot modify the JNDI namespace. This does not impact WebSphere Application Server's own operations (including registering resources in JNDI) because it always grants itself the needed permissions. However, applications that write to JNDI will fail. Since this is rare, this should not be an issue in most situations. If some applications need write access to JNDI, you'll have to grant them the needed permissions. Note that JNDI permissions apply to the entire namespace, not just one part.

8. Ensure meaningful authorization on default messaging
attack code V6 only

By default, the service integration bus (SIB) has no meaningful authorization, even when WebSphere Application Server security is enabled. This means that any party with a valid user ID and password in the WebSphere Application Server registry (which could be anyone in your company) can perform any action against any queue. None of this is visible or configurable via the administration console, so you are going to have to use wsadmin. The messaging bus admin tasks are controlled by the wsadmin $AdminTask command. If you use listGroupsInBusConnectorRole, you will quickly discover that, by default, all authenticated users have access to the bus. That's not very secure!

We recommend that you immediately use the removeGroupFromBusConnectorRole and addUserToBusConnectorRole/addGroupToBusConnectorRole tasks to correct this. For example:

wsadmin>$AdminTask removeGroupFromBusConnectorRole {-bus mySIB -group AllAuthenticated}

wsadmin>$AdminTask addUserToBusConnectorRole {-bus mySIB -user bususeryoudetermine}

Of course, once you configure authorization to limit the parties that can connect, you'll need to ensure that your client components (MDBs, JMS, etc) authenticate using appropriate identities.

9. Restrict access to WebSphere MQ messagingattack code

If you are using WebSphere MQ as your messaging provider, you'll need to address queue authorization via other techniques. WebSphere MQ, by default, does not perform any user authentication when using client/server mode (bindings mode relies on process to process authentication within a machine). In fact, when you specify a user ID and password on the connection factory for WebSphere MQ, those values are ignored by WebSphere MQ.

One option to address this is to implement your own custom WebSphere MQ authentication plugin on the WebSphere MQ server side to validate the user ID and password sent by WebSphere Application Server. A second, and likely simpler technique is to configure WebSphere MQ to use SSL with client authentication, and then ensure that only the WebSphere Application Server server possesses acceptable certificates for connecting to WebSphere MQ (leveraging the SSL client authentication trick mentioned earlier).

10. Encrypt WebSphere Application Server to LDAP link attack code

When using an LDAP registry, WebSphere Application Server verifies a user's password using the standard ldap_bind. This requires that WebSphere Application Server send the user's password to the LDAP server. If that request is not encrypted, a hacker could use a network sniffer to steal the passwords of users authenticating (including administrative passwords!). Most LDAP directories support LDAP over SSL, and WebSphere Application Server can be configured to use this. On the LDAP user registry panel (see Figure 9), check the use SSL option and then configure an SSL Configuration appropriate to your LDAP directory. You'll most likely need to place the signing key for the LDAP server's certificate) into the trust store. It's best to create a new SSL Configuration just for LDAP to avoid causing problems with the existing SSL usage.

Figure 9. Enable LDAP SSL
Figure 9. Enable LDAP SSL

If you use a custom registry, you'll want to secure this traffic using whatever mechanism is available.

11. Change the default key fileattack code

Considerations for changing the default keyring

When changing the default certificates, there is one important thing to keep in mind. As with any SSL-based system, the client must be able to verify the certificate presented by the server. This requires that the client hold the signing certificate for the signer that signed the certificate presented by the server.

When WebSphere Application Server ships, all of this is taken care of for Java clients, including the IBM provided tools such as the wsadmin and Tivoli™ Performance Viewer (for versions prior to V6), as well as custom-written clients. However, when you update the server key file to use a new private key and certificate signed by some signer, you must ensure that the Java clients can verify those certificates. You will need to update the client trust file to contain the signer certificate for the party that issued your new server certificates. This means that any Java clients, such as the WebSphere Application Server admin clients, may need new client key files. If you use certificates issued from a well-known CA, such as Verisign, this will not be necessary since the default client key rings include signing certificates from the most common public CAs already. This is not a recommendation to buy certificates from a CA for WebSphere Application Server internal communication. If you have few Java clients, it is usually easier and cheaper to simply generate a self-signed certificate and update the small number of client keyrings manually.

This issue also affects the Web server to application server communication. Because the Web server plug-in supports HTTPS by default, the Web server plug-in keyring contains a copy of the WebSphere Application Server sample signing certificate. If you change the default keyring, do not forget to update the Web server plug-in keyring to include the new certificate.

As stated earlier, enabling WebSphere Application Server security causes most internal traffic to use SSL to protect it from various forms of network attack. However, in order to establish an SSL connection, the server must posses a certificate and corresponding private key. To simplify the initial installation process, WebSphere Application Server is delivered with a sample key file containing a sample private key. This "private" key is included in every copy of WebSphere Application Server sold. As such, it is not very private. The name of the key file, DummyServerKeyFile, makes this clear.

To protect your environment, you should create your own private key and certificate for communication. All of this is done using the ikeyman tool. Using ikeyman, create a new keystore and truststore, and then update the existing SSL configurations to use these new files. See the WebSphere Application Information Center and the WebSphere Application Security 6.0 Security Redbook for more details.

When you create a new keystore and truststore, keep in mind that every signer that you place in the truststore is a statement about trust. You are trusting that signer to identify principals in the system. If you trust multiple signers, there is the very real risk that multiple signers will create certificates for what appear to be the same user depending on how certificates are mapped to user identities. If you are using certificates for client authentication, to reduce this risk, you should reduce the number of signers in the trust store to the minimum number possible.

While we are talking about certificates, we want to digress briefly on a crucial point -- certificates expire. Should the WebSphere Application Server certificates expire, WebSphere Application Server will stop working. No communication will be possible. Thus, when you create new certificates as we recommend, ensure that you mark the expiration date on a calendar. If, against our advice, you use the default keys, remember that they expire as well. You must actively plan for certificate expiration and obtain or generate new certificates prior to their expiration.

12. Harden the Web server hostattack code

If you are following the standard topology recommended earlier, your Web server is running in the DMZ. Since a DMZ is the front line defense against potential intruders, special care must be taken to harden this server.

This article does not discuss the specifics of Web server hardening, but you should look hard at things like operating system hardening, limiting the Web server modules being loaded, and other Web server configuration steps. See Building Secure Servers with LINUX for more information on these topics.

Web server management (V6 only)

When hardening your Web server, there is one WebSphere Application Server specific item that you need to consider. It is possible for the WebSphere Application Server administrative infrastructure to manage Web servers. While this seems like a good thing from an ease of use perspective, this raises serious security issues. There are two ways you can manage a Web server: using a managed node and using the native IBM HTTP Server (IHS) Admin Server.

Using a managed node requires that you place a node agent on the Web server machine (which is typically in the DMZ) and that this agent be part of the WebSphere Application Server cell. This is completely unacceptable from a security perspective, and thus should not be used except in those rare cases where there is no need for a DMZ. This is unacceptable for two reasons:

  • A node agent is a fully functional member of the cell and has full administrative authority. If it is compromised in the DMZ, the entire cell is compromised.

  • WebSphere Application Server is a large and powerful product, and therefore it is difficult to harden as this article shows. Such products don't belong in the DMZ.

The second approach requires using IBM HTTP Server and configuring the HTTP Admin Server. In this scenario, the deployment manager sends administrative requests to the HTTP Admin Server running on the Web server host. This seems like a reasonable approach, but some may be concerned about even this type of traffic.

13. Don't run samples in productionattack code

WebSphere Application Server ships with several excellent examples to demonstrate various parts of the product. These samples are not intended for use in a production environment. Do not run them there, as they create significant security risks. In particular, the showCfg and snoop servlets can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you do not want to give a potential intruder. This is easily addressed by not running server1 (that contains the samples) in production. If you are using WebSphere Application Server base, you'll actually want to remove the examples from server1.

14. Review Web server trust boundariesattack code

When configuring your environment, always be careful to consider trust boundaries. It is unfortunately far too easy to accidentally create a weak secure environment by inappropriately extending the trust boundary. Normally, WebSphere Application Server performs its own authentication using strong mechanisms. But, it is possible for WebSphere Application Server to trust other components in your infrastructure to perform the authentication. If done properly, there is no problem. However, if done improperly or without careful consideration, you can create an insecure system, or at least one with poorly understood trust relationships. Remember the old adage -- security is only as strong as its weakest link! Carefully limit the WebSphere Application Server trust domain.

Extension of the WebSphere Application Server trust domain typically occurs explicitly when writing TAIs, login modules, or other custom code, but it can also occur implicitly, for example, when using certificates.

When using client certificate authentication for Web clients, realize that the Web server is now part of your trust domain. The WebSphere Application Server plugin forwards information about the user's certificate to the application server. The application server must trust that the Web server has done proper certificate authentication. WebSphere Application Server can't repeat the SSL authentication handshake (only the SSL terminator can do that). Therefore, compromise of the Web server will compromise WebSphere Application Server security completely.

Further, when you are using client certificate authentication to the Web server, since WebSphere Application Server now completely trusts the Web server, you should configure authenticated HTTPS between the Web server and the application server to avoid attacks that spoof the certificate information. This brings us to the next topic.

15. Consider authenticating Web server to WebSphere Application Server HTTP link attack code

The WebSphere Application Server Web server plug-in forwards requests from the Web server to the target application server. By default, if the traffic to the Web server is over HTTPS, then the plug-in will automatically use HTTPS when forwarding the request to an application server, thus protecting its confidentiality.

Further, with some care, you can configure the application servers (which contain a small embedded HTTP listener) to only accept requests from known Web servers. This prevents various sneak attacks that bypass any security e in front of or in the Web server, and creates a trusted network path. This type of situation might seem unlikely, but it is possible. Some examples:

  • You have an authenticating proxy server that just sends the user ID as an HTTP header without any authentication information. An intruder that can access the Web container directly can become anyone simply by providing this same header. Tivoli Access Manager WebSEAL does not have this weakness.

  • You are using client certificate authentication to the Web server. When this occurs, the WebSphere Application Server plugin forwards the certificate information from the Web server to application server and trusts it. Thus, direct access to the Web container by an intruder will compromise WebSphere Application Server security completely when client certificates are being used because the intruder can assert any valid certificate and become anyone.

To create a trusted network path from the Web server to the application server, you configure the application server Web container SSL configuration to use client authentication. Once you have ensured that client authentication is in use, you need to ensure that only trusted Web servers can contact the Web container. To do this, you must limit the parties that have access by applying the SSL trick. Specifically in this case, you'll need to:

  1. Create a key store and trust store for the Web container and a key store for the Web Server plug-in using ikeyman.

  2. Delete from all key store, including the trust store, all of the existing signing certificates. At this point, you cannot use any key store to validate any certificates. That's intentional.

  3. Create a self-signed certificate in the two key stores and export just the certificate (not the private key).

  4. Import into the plug-in key store the certificate exported from the Web container key store. Import into the Web container trust store the plug-in certificate. Now each side contains only a single signing certificate. This means you can verify exactly one certificate -- the self-signed certificate created for the peer.

  5. Install the newly created key stores into the Web container and Web server plug-in.

16. Protect private keysattack code

WebSphere Application Server maintains several sets of private keys. The two most important examples include the primary keystore for internal communication, and the keystore used for communication between the Web server and the application server. These private keys should be kept private and not shared. Since they are stored on computer file systems, those file systems must be carefully protected. Given the sensitive nature of the information in the keystore, even placing it on a shared network accessible file system is inadvisable.

Also be careful to avoid incidental sharing of these keys. For example, do not use the same keys in production as in other environments. Many people will have access to development and test machines and their private keys. Guard the production keys carefully.

17. Configure and use trust association interceptors carefullyattack code

TAIs are often used to allow WebSphere Application Server to recognize existing authentication information from a Web SSO proxy server, such as Tivoli Access Manager WebSEAL. Generally, this is fine. However, be careful when developing, selecting, and configuring TAIs. A TAI extends the trust domain. WebSphere Application Server is now trusting the TAI and whatever the TAI trusts. If the TAI is improperly developed or configured, it is possible to completely compromise the security of WebSphere Application Server. If you custom-develop a TAI, ensure that the TAI carefully validates the parameters passed in the request and that the validation is done in a secure way. We've seen TAIs that perform foolish things such as simply accepting a username in an HTTP header. That's useless unless care is taken to ensure that all traffic received at WebSphere Application Server must be sent via the authentication proxy. For example, using the techniques described earlier, and that the authentication proxy will always override an HTTP header set by the client since HTTP headers can be forged.

WebSEAL TAI configuration

TAI version note

Mutual SSL authentication is no longer supported by the newer WebSEAL TAI included with WebSphere Application Server V5.1.1 and later, and known by the class name TAMTrustAssociationInterceptorPlus. You can still configure mutual SSL in WebSphere Application Server (and doing so is often useful), but the TAI won't honor it. You must use password-based authentication from WebSEAL with the newer TAI. The older TAI (WebSealTrustAssociationInterceptor) continues to be included if you wish to use it.

To clarify the importance of careful configuration, we are going to specifically discuss the IBM provided WebSEAL TAI, but any TAI requires careful design and configuration to be secure. Proper configuration of the trust relationships between WebSphere Application Server and Tivoli Access Manager WebSEAL is crucial to the creation of a secure configuration. To create this secure configuration, steps must be taken on both WebSphere Application Server and WebSEAL. Within WebSphere Application Server, both the Web container configuration and the WebSEAL TAI configuration must be set properly.

The trust relationship between the two products is crucial because the WebSEAL TAI within WebSphere Application Server is accepting identity assertions from WebSEAL. If that link is compromised, an intruder could then assert any identity and completely undermine the security of the infrastructure. The trust relationship between WebSphere Application Server and WebSEAL is established through one of two mechanisms: mutual SSL authentication and password based authentication. Either mechanism is appropriate within a secure environment. However, each must be configured properly or serious security breaches are possible. In either case, WebSEAL sends the end user's user ID as an iv-user header on the HTTP request. The difference between the two configurations is how WebSEAL proves itself to the application server.

WebSEAL password configuration

When password authentication is used, WebSEAL sends its user ID and password as the basic auth header in the HTTP request (the user's user ID is in the iv-user header). Password based authentication is configured in two places. First, TAM WebSEAL must be configured to send its user ID and password to the application servers for the junction being configured. This password is, of course, a secret that must be carefully protected. The WebSEAL TAI validates this password against the registry when it is received.

However, there is one subtle and easily overlooked point. If the LoginId property is not set on the WebSEAL properties, then the TAI will verify the user ID and password combination sent from WebSEAL and trust it if it is any valid user ID and password combination. This is not a secure configuration because this implies that any person knowing any valid user ID and password combination can connect to WebSphere Application Server and assert any user's identity. When you specify the LoginId property, the WebSEAL TAI ignores the inbound user ID in the basic auth header and verifies the LoginId and WebSEAL password combination. In that case, there is then only one (presumably closely guarded secret) valid password sent from WebSEAL. You should, of course, configure SSL from WebSEAL to the application server to ensure that the secret password is not sent in cleartext.

WebSEAL mutualSSL configuration

Mutual SSL is configured through three separate and critically important steps:

  1. You must configure WebSEAL to use SSL to communicate with WebSphere Application Server and that SSL configuration must include a client certificate known only to the application server Web container.

  2. You must configure the application server Web container to perform client certificate authentication.You also must alter its trust store to include only the client certificate that WebSEAL is using. This step is crucial because this is how we guarantee that requests to the application server Web container are coming only from WebSEAL and not some intruder (using mutually authenticated SSL is not sufficient). You must also remove from the Web container the non-HTTPS transports to ensure that only mutually authenticated SSL is used when contacting the server.

  3. You must configure the WebSEAL TAI with mutualSSL=true in its properties. However, you must understand that this last step merely states to the TAI that it should assume the connection is secure and that it is using mutually authenticated SSL. If either of the two previous steps is not configured exactly correctly, your environment is now completely insecure. Thus, the choice to use mutualSSL must be taken with great care. Any configuration mistakes will result in an environment where any user can be impersonated.

If you add a Web server to the mix, things get even more complicated. In this case, you must carefully configure a mutual SSL configuration between WebSEAL and the Web server, and a second between the Web server plugin and the WebSphere Application Server Web container.

18. Use only the new LTPA cookie formatattack code

WebSphere Application Server V5.1.1 introduced a new LTPA cookie format (LTPAToken2) to support subject propagation (see Advanced Authentication in WebSphere Application Server). While doing this, some theoretical weaknesses in the old format were also addressed. Bear in mind that these weaknesses are theoretical. No known compromises have occurred. It is desirable to use the new stronger format, unless you have to use the older format.

The new LTPA token uses the following strong cryptographic techniques:

  • Random salt
  • Strong AES based ciphers
  • Data is signed
  • Data is encrypted.

For the curious, a 1024 bit RSA key pair is used for signing and a 128 bit secret key (AES) is used for encryption. The cipher used for encryption is AES/CBC/PKCS5Padding.

Both the old and new cookie format are supported simultaneously by default to ensure compatibility with other systems, such as older versions of WebSphere Application Server, Lotus® Domino®, and TAM WebSEAL, when it creates LTPA cookies. If you don't need this compatibility, you should disable it. To do so, go to the Security => Authentication Mechanisms => LTPA => SSO configuration panel and unselect interoperability mode. See Figure 10.

Figure 10. SSO interoperability mode setting
Figure 10. SSO interoperability mode setting

19. Don't specify passwords on the command lineattack code

Once security is enabled, the WebSphere Application Server administrative tools require that you authenticate in order to function. The default or obvious way to do this is to specify the user ID and password on the command line as parameters to the tools. Do not do this. This exposes your administrative password to anyone looking over your shoulder. And, on many operating systems, anyone that can see a list of processes can see the arguments on the command line. Instead, ensure that the administrative tools prompt for a user ID and password. As of WebSphere Application Server V6.0.2, all of the administrative tools prompt automatically for a user ID and password if one isn't provided on the command line. No further action is required.

If you are using an older version of WebSphere Application Server, you can force the tools to prompt by telling them to use RMI (the default is SOAP) communication. The RMI engine prompts when needed. To do this, simply specify -conntype RMI -port <bootstrap port>. Here's an example of starting wsadmin this way to connect to a deployment manager listening on the default port: -connectype RMI -port 9809

You may find it annoying that the command line tools prompt graphically for a user ID and password. Fortunately, you can override this behavior. You can force the tools to use a simple text based prompt. To do this, change the loginSource from prompt to stdin by editing the appropriate configuration file. By default, the administrative tools use SOAP, and thus you need to edit the soap.client.props file. If you are using RMI, edit sas.client.props. Look for the loginSource property in the appropriate file and change it to specify stdin.

20. Carefully limit trusted signersattack code

When using certificate authentication (client or server), you need to understand that each signer in the trust store represents a trusted provider of identity information (a certificate). You should trust as few signers as possible. Otherwise, it is possible that two signers might issue certificates that map to the same user identity. That would create a serious security hole in your architecture.

You should review the trust stores on the clients and servers using ikeyman and remove any signers which are not needed.

21. Encrypt default messaging links
attack code V6 only

By default, messaging occurs over unencrypted links. This is obviously undesirable. To correct this, you'll need to make some configuration changes. For each application server (not cluster), go to the messaging engine inbound transport panel and disable the InboundBasicMessaging transport. Once you've done this, clients will only be able to use the InboundSecureMessaging transport. See Figure 11.

Version note

The ability to specify the transport chain for MDBs was added with WebSphere Application Server V6.0.2.

To complete the task you must then configure every client to use the InboundSecureMessaging transport. This requires specifying this transport in one of several places depending on the client type. Ordinary JMS clients (even server side) will need to specify the InboundSecureMessaging transport on the connection factory panel. See Figure 12. MDBs need InboundSecureMessaging specified on the activation specification panel. Finally, if cross bus communication is being used, you need to specify InboundSecureMessaging as the inter-engine transport chain on the bus configuration panel.

Figure 11. disable InboundBasicMessaging
Figure 11. disable InboundBasicMessaging
Figure 12. Configuring connection factory to use secure transport
Figure 12. Configuring connection factory to use secure transport

See Administering messaging security for more information.

22. Encrypt WebSphere MQ nessaging linksattack code

If you are using MQ rather than the default messaging provider, you should of course use SSL to MQ. This is done by specifying the SSLCIPHERSUITE property. Refer to the WebSphere Application Server Information Center and the WebSphere MQ documentation for more details on that.

23. Encrypt Distribution and Consistency Services transport link
attack code V6 only

Core groups rely on Distribution and Consistency Services (DCS), which uses a reliable multicast message (RMM) system for transport. RMM can use one of several wire transport technologies. To maximize security, use encrypted links. To ensure this for each core group, select a transport type of channel framework and DCS-Secure as channel chain. See Figure 13.

Figure 13. Configuring DCS to use a protected link
Figure 13. Configuring DCS to use a protected link

Note that DCS always authenticates messages when global security is enabled. Once the transport is encrypted, you have a highly secure channel.

Once you have done this, all services that rely on DCS are now using an encrypted and authenticated transport. Those services are DynaCache, memory to memory session replication, core groups, Web services caching, and stateful session bean persistence.

24. Encrypt Distributed Replication Service network links attack code

If you are using WebSphere Application Server V6 and have configured DCS to use an encrypted link, this step is unnecessary since Distributed Replication Service (DRS) runs over the DCS link.

DRS traffic is not encrypted by default even when global security is enabled. DRS encryption is configured by specifying DES or 3DES as the encryption type on the replication domain configuration panel (environment => replication domains => yourdomain).

25. Protect application server to database link attack code

Just as with any other network link, confidential information may be written to or read from the database. Although most databases support some form of authentication, not all support encrypting JDBC traffic (see your database vendor's documentation) between the client (WebSphere Application Server applications, in this case) and the database. Thus, you must recognize this weakness and take appropriate steps. Some form of network-level encryption, such as a Virtual Private Network (VPN), perhaps using IP Security Protocol (IPSEC), is the most obvious solution, although there are other reasonable choices. If you can place your database near WebSphere Application Server (in the network sense), various forms of firewalls and simple routing tricks can greatly limit the access to the network traffic going to the database. The key here is to identify this risk and then address it as appropriate.

26. Create separate administrative user IDsattack code

When WebSphere Application Server security is configured, a single security ID is initially configured as the Security Server ID. This ID is effectively the equivalent of root in WebSphere Application Server and can perform any administrative operation. Because of the importance of this ID, it is best not to widely share the password.

Console login note

As of WebSphere Application Server V6, you'll find that you cannot login to the admin console as an administrator (other than the security server ID) once you've configured JNDI hardening, as suggested earlier. You'll need to specifically grant all of the CosNaming permissions to your administrators so they can login.

As with most systems, WebSphere Application Server does allow multiple principals to act as administrators. Simply use the administrative application and go to the System Administration/Console Users (or Groups) section to specify additional users or groups that should be granted administrative authority. When you do this, each individual person can authenticate as himself or herself when administering WebSphere Application Server. Note that all administrators have the same authority throughout the cell. WebSphere Application Server does not support instance-based administrative authorization.

As of WebSphere Application Server 5.0.2, all administrative actions that result in changes to the configuration of WebSphere Application Server are audited by the deployment manager, including the identity of the principal that made the change. Obviously, these audit records are more useful if each administrator has a separate identity. Audit records are treated as serious messages and sent, by default, to SystemOut.log from the deployment manager.

The approach of giving individual administrators their own separate administrative access is handy in an environment where central administrators administer multiple WebSphere Application Server cells. You can configure all of these cells to share a common registry, and thus the administrators can use the same ID and password to administer each cell, while each cell has its own local "root" ID and password.

27. Take advantage of administrative rolesattack code

WebSphere Application Server allows for four administrative roles: administrator, operator, monitor, and configurator. These roles make it possible to give individuals (and automated systems) access appropriate to their level of need. We strongly recommend taking advantage of roles whenever possible. By using the less powerful roles of monitor and operator, you can restrict the actions an administrator can take. For example, you can give the less senior administrators the ability to start and stop servers; and the night operators the ability the watch the system (monitor). These actions greatly limit the risk of damage by trusting people with only the permissions they need.

One interesting role is the monitor role. By giving a user or system this access level, you are giving only the ability to monitor the system state. You cannot change the state, nor can you alter the configuration. For example, if you develop monitoring scripts that check for system health and have to store the user ID and password locally with the script, use an ID with the monitor role. Even if the ID is compromised, little serious harm can result.

28. Remove JDKs left by Web server and plugin installersattack code

When you install IBM's HTTP Server, the installer leaves behind a JDK in the _jvm directory of the installation root. As this is a full JDK (which includes development tools) this should not be on a machine in the DMZ. You should remove this JDK. Keep in mind that this will make it impossible to run some tools, such as ikeyman, on this Web server. We don't consider that a significant issue because running such tools in the DMZ is problematic.

When you install the WebSphere Application Server HTTP Server plugin using the IBM installer, it also leaves behind JDKs -- two in this case. The first JDK is used by the uninstaller and is in the _uninstPlugin directory under the plugin installation root. The second JDK is in the java directory and is used by ikeyman and other Java tools. As before, you should remove this during post-installation.

If you do choose to remove the JDKs, make a backup copy just in case for future use. One technique might be to zip or tar the JDK and replace it later, such as when it would be needed for the WebSphere Application Server update installer when applying fixes, and then zip/tar and remove it again when the process is complete.

29. Choose appropriate process identityattack code

The WebSphere Application Server processes run on an operating system and must therefore, run under some operating system identity. There are three ways to run WebSphere Application Server with respect to operating system identities:

  • Run everything as root.
  • Run everything as a single user identity, such as "was".
  • Run the node agents as root and individual application servers under their own identities.

IBM tests for and fully supports the first two approaches. The third approach may seem tempting because you can then leverage operating system permissions, but it isn't very effective in practice for the following reasons:

  • It is difficult to configure and there are no documented procedures. Many WebSphere Application Server processes need read access to numerous files and write access to the log and transaction directories.

  • By running the node agent as root, you effectively give the WebSphere Application Server administrator and any applications running in WebSphere Application Server root authority.

  • The primary value of this approach is to control file system access by applications. You can achieve this using Java 2 permissions.

  • This approach creates the false impression that applications are isolated from each other. They are not. The WebSphere Application Server internal security model is based on J2EE and Java 2 security and is unaffected by operating system permissions. Thus, if you choose this approach to protect yourself from "rogue" applications, your approach is misguided.

The first approach is obviously undesirable because, as a general best practice, it is best to avoid running any process as root if it can be avoided. This leaves the second approach, which is fully supported and provides application isolation (should that be desirable) when used in conjunction with Java 2 security. Therefore, we recommend that approach.

Obviously, once you have chosen a WebSphere Application Server process identity, you should limit file system access to WebSphere Application Server's files by leveraging operating system file permissions. WebSphere Application Server, like any complex system, uses and maintains a great deal of sensitive information. In general, no one should have read or write access to most of the WebSphere Application Server information. In particular, the WebSphere Application Server configuration files (<root>/config) contain configuration information as well as passwords.

Do not take this too far. We've seen far too many cases where during development, developers aren't allowed to even see the application server log files. Such paranoia is unwarranted. During development, maximal security is not productive. During production, you should lock down WebSphere Application Server as much as possible. During development, be more lenient.

30. Enforce CSIv2 transport SSL useattack code

When WebSphere Application Server servers and clients communicate using CSIv2 IIOP, they negotiate the transport security. Whatever is acceptable to both parties is chosen. Generally, that is fine, but you should be aware of one potential weakness. WebSphere Application Server supports CSIv2 over SSL or cleartext. By default, both parties will typically negotiate to use SSL, thus ensuring an encrypted communication channel. However, if either party in the negotiation requests cleartext, then cleartext will be used. You may not even realize your traffic is being sent in the clear! This might happen, for example, if a client was misconfigured. If you want to guarantee that traffic is encrypted (and you should), it is safer to ensure that SSL is always used.

You can ensure that SSL is used for IIOP by indicating that it is required, and not optional on the CSIv2 transport panel (Security => Authentication Protocol => CSIv2 Inbound Transport). You should do the same for the CSIv2 Outbound Transport. See Figure 14.

Figure 14. CSIv2 transport panel
Figure 14. CSIv2 transport panel

31. Keep up to date with patches and fixesattack code

As with any complex product, IBM occasionally finds and fixes security bugs in WebSphere Application Server, IBM HTTP Server, and other products. It is crucial that you keep up to date on these fixes. It is advisable that you subscribe to support bulletins for the products you use, and in the case of WebSphere Application Server, monitor the recommended updates support page. These bulletins often contain notices for recently discovered security bugs and fixes. You can be certain that potential intruders learn of those security holes quickly. The sooner you act, the better.

Be aware that WebSphere Application Server security fixes are usually rolled into the next cumulative fix for every supported release and then will no longer be listed on the recommend updates page. Therefore you will need to keep up with cumulative fixes if you want all known security holes to be closed.

32. Disable unused portsattack code

A basic principle of security hardening is to minimize the attack surface for potential attacks. This is event true when there are no known security issues with a given service. If the service is not required for the site to correctly function, it should be removed to minimize the likelihood of an attacker taking advantage of this additional function at some point in the future. Examine Figure 15 and you'll see that a typical WebSphere Application Server application server is listening on a lot of ports.

Figure 15. Default ports for a WebSphere Application Server ND application server
Figure 15. Default ports for a WebSphere Application Server ND application server

If a given service is not required, then you can disable its listening ports. Looking at this list, potential candidates for disabling are:

  • SAS_SSL_SERVERAUTH_LISTENER_ADDRESS -- used for compatibility with WebSphere Application Server V4 and earlier releases. This is the old IIOP security protocol. CSIv2 replaces it as of V5.

  • SIB_ENDPOINT_* -- used by the built in messaging engine. If you aren't using messaging, you don't need it either.

  • SIB_MQ_* -- used by the messaging engine when connecting with WebSphere MQ.

  • WC_adminhost* -- used for administrative Web browser access. These are already disabled in an application server that is part of a cell.

  • WC_defaulthost* -- the default Web container listening ports. If you've added custom listener ports, these might not be needed.

Different ports require different techniques for disabling them, depending on how they are implemented:

  • The SAS_SSL_SERVERAUTH_LISTENER_ADDRESS can be taken out of service by selecting CSI as the active protocol on the global security panel.

  • The WC_* ports are all for the Web container. They can best be removed, modified, or disabled from the Web container transport chain configuration panel (application servers => servername => web container => transport chain). The only listening Web ports you need are those used by your applications.

  • The SIB_* ports are not started unless the messaging engine is enabled, so no action is necessary for them.

Application-based preventative measures: configuration

At this point, we have focused on the basic steps that a WebSphere Application Server architecture and the administration team can take to ensure that they create a secure infrastructure. That's obviously an important step, but it is not sufficient. Now that the infrastructure has been hardened, we must examine things that applications need to do to be secure. Obviously, applications will need to take advantage of the infrastructure provided by WebSphere Application Server, but there are also numerous other actions that application developers need to take. We'll detail many of those issues here.

33. Never set Web server doc root to WARattack code

WAR files contain application code and lots of sensitive information. Only some of that information is Web-servable content. Thus, it is inappropriate to set the Web server document root to the WAR root. If you do this, the Web server will serve up all the content of the WAR without interpretation. This will result in code, raw JSPs, and more being served up to end users.

Note that this recommendation only applies when a Web server is co-located with an Application Server -- a configuration that we do not recommend.

34. Carefully verify that every servlet alias is secureattack code

WebSphere Application Server secures servlets by URL. Each URL that is to be secured must be specified in the web.xml file describing the application. If a servlet has more than one alias (that is, multiple URLs access the same servlet class), or there are many servlets, it is easy to accidentally forget to secure an alias. Be cautious. Since WebSphere Application Server secures URLs, not the underlying classes, if just one servlet URL is insecure, an intruder might be able to bypass your security. To prevent this, whenever possible, use wildcards to secure servlets. If that is not appropriate, carefully double-check your web.xml file before deployment.

The alias problem is further aggravated by the feature known as serve servlets by classname, which brings us to our next recommendation.

35. Don't serve servlets by classnameattack code

You can serve servlets by classname or via a normal URL alias. Normally, applications choose the latter. That is, developers define a precise mapping from each URL to each servlet class in the web.xml file by hand, or by using one of the various WebSphere Application Server development tools.

However, WebSphere Application Server also lets you serve servlets by classname. Instead of defining a mapping for each servlet, a single generic URL (such as /servlet) serves all servlets. The component of the path after the base is assumed to be the classname for the servlet. For example, "/servlet/" refers to the servlet class ""

Serving servlets by classname is accomplished by setting the serveServletsByClassnameEnabled property to true in the ibm-web-ext.xmi file, or by checking serve servlets by classname in the WAR editor of IBM Rational® Application Developer. Do not enable this feature. This feature makes it possible for anyone that knows the classname of any servlet to invoke it directly. Even if your servlet URLs are secured, an attacker may be able to bypass the normal URL-based security. Further, depending on the classloader structure, an attacker may be able to invoke servlets outside of your Web application.

35. Do not place sensitive information in WAR rootattack code

WAR files contain servable content. The Web container serves HTML and JSP files found in the root of the WAR file. This is fine as long as you place only servable content in the root. Thus, never place content that shouldn't be shown to end users in the root of the WAR. For example, don't put property files, class files, or other important information there. If you must place information in the WAR, place it within the WEB-INF directory, as allowed in the servlet specification. Information there is never served by the Web container.

36. Define a default error handlerattack code

When errors occur in a Web application or even before the application dispatch (if for example WebSphere Application Server can't find the target servlet), an error message is displayed to the user. By default, WebSphere Application Server will display a raw exception stack dump of the error. Not only is this incredibly unfriendly to the end user, it also reveals information about the application. Names of classes and methods are in the stack information. The exception message is also displayed; this message might contain sensitive information.

It is best to ensure the end users never see a raw error message. While you can in every single servlet ensure that exceptions are always caught, this doesn't cover every case (as we said earlier). Instead, you should define a default error page. The default error page will be displayed whenever an unhandled exception occurs. This page can be a friendly error message rather than a stack trace. The default error page is defined in ibm-web-ext.xmi using the defaultErrorPage attribute. It can also be set in Rational Application Developer using the Web Deployment Descriptor editor (extensions tab).

37. Consider disabling file serving and directory browsingattack code

You can further limit the risk of inappropriate serving of content by disabling file serving and directory browsing in your Web applications. Obviously, if the WAR contains servable static content, you need to enable file serving.

38. Enable session securityattack code

WebSphere Application Server does not normally enforce any authorization of HTTP Session access. Any party with a valid session identifier can access any session. While session identifiers aren't likely to be guessable, it may be possible to obtain session identifiers through other means.

To reduce the risk of this form of attack, you should consider enabling session security. This setting is configured on the application server => <server name> => web container => session management panel. Check the box labeled security integration. Once this is done, WebSphere Application Server will track what user (as determined by the LTPA credential that they present) owns what session, and will ensure that only that user can access that session.

In rare cases, this setting can break Web applications. If the application contains a mixture of secure (those with authorization constraints) and insecure servlets, the insecure servlets cannot access the session object. Once a secure servlet accesses the session, it is marked as "owned" by that user. Insecure servlets, which run as anonymous, will receive an authorization failure if they try to access those pages.

39. Beware of custom JMX network access attack code

JMX and custom MBeans make it possible to support powerful remote customized administration of your applications. Be aware that JMX MBeans are network accessible. If you choose to deploy them, do so carefully and ensure that they have proper authorization on their operations. WebSphere Application Server will automatically provide default authorization restrictions for MBeans based on information in the descriptor in the MBean JAR file. Whether this is appropriate depends on your application. See IBM WebSphere: Advanced Deployment and Administration for more information.

Application-based preventative measures: design and implementation

Now we turn our attention to the actions that application developers and designers must take to build a secure application. These steps are crucial and, sadly, often overlooked.

40. Use WebSphere Application Server security to secure applicationsattack code

Usually, application teams recognize that they need some amount of security in their application. This is often a business requirement. Unfortunately, many teams develop their own security infrastructure. While this is possible to do well, it is very difficult, and most teams do not succeed. Instead, there is the illusion of strong security, but in fact the system security is quite weak. Security is simply a hard problem. There are subtle issues of cryptography, replay attacks, and various other forms of attack that are easily overlooked. The message here is that you should use WebSphere Application Server security unless it truly does not meet your needs. This is rarely the case.

Perhaps the most common complaint about the J2EE-defined declarative security model is that it is not sufficiently granular. For example, you can only perform authorization at the method level of an EJB or servlet, not at the instance level. In this context, a method on a servlet is one of the HTTP methods: GET, POST, PUT, and so on. Thus, for example, all bank accounts have the same security restrictions, but you would prefer that certain users have special permissions on their own accounts.

This problem is addressed by the J2EE security APIs (isCallerInRole and getCallerPrincipal). By using these APIs, applications can develop their own powerful and flexible authorization rules, but still drive those rules from information that is known to be accurate -- the security attributes from the WebSphere Application Server runtime.

An example of weak security

Here is one quick example of a weak security system. Applications that don't use WebSphere Application Server security tend to create their own security tokens and pass them within the application. These tokens typically contain the user's name and some security attributes, such as their group memberships. It is not at all uncommon for these security tokens to have no cryptographically verifiable information. The presumption is that you can make security decisions based on the information in these tokens. This is false. The tokens simply assert user privileges.

The problem here is that any Java program can forge one of these security objects, and then possibly sneak into the system through a back door. The best example of this is when the application creates these tokens in the servlet layer and then passes them to an EJB layer. If the EJB layer is not secured (see the next section), intruders can call an EJB directly with forged credentials, rendering the application's security meaningless. Thus, without substantial engineering efforts, the only reliable secure source of user information is the WebSphere Application Server infrastructure. (Note that you can integrate the WebSphere Application Server security infrastructure with other authentication or authorization products. For example, Tivoli Access Manager can provide authentication and authorization support.)

41. Secure every layer of the application (particularly EJBs)attack code

All too often, Web applications are deployed with some degree of security (home-grown or WebSphere Application Server-based) at the servlet layer, but the other layers that are part of the application are left unsecured. This is done under the false assumption that only servlets need to be secured in the application because they are the front door to the application. But, as any police officer will tell you, you have to lock the back door and windows to your home as well.

There are many ways for this to occur, but this is most commonly seen when EJBs are used as part of a multi-tier architecture when Java clients aren't part of the application. In this case, developers often assume that the EJBs do not need to be secured since they are not "user-accessible" in their application design, but this assumption is dangerously wrong. An intruder can bypass the servlet interfaces, go directly to the EJB layer, and wreak havoc if you have no security enforcement at that layer. This is easy to do with available Java IDEs that can inspect running EJBs, obtain their metadata, and dynamically create test clients. Rational Application Developer is capable of this, and developers see this every day when they use the integrated test client.

Often, the first reaction to this problem is to secure the EJBs via some trivial means, perhaps by marking them accessible to all authenticated users. But, depending on the registry, "all authenticated users" might be every employee in a company. Some take this a step further and restrict access to members of a certain group that means roughly "anyone that can access this application." That's better, but it's usually not sufficient, as everyone that can access the application shouldn't necessarily be able to perform all the operations in the application. The right way to address this is to implement authorization checks in the EJBs. You might also consider implementing EJBs as local EJBs, making it impossible to connect to them remotely.

42. Do not rely on HTTP Session for user identityattack code

Unfortunately, some applications that use their own security track the user's authentication session through the use of the HTTP Session. This is dangerous. The session is tracked via a session ID (on the URL or in a cookie). While the ID is randomly generated, it is still subject to replay attacks because it does not timeout (except when idle). On the other hand, the LTPA token, which is created when WebSphere Application Server security is used by the application, is designed to provide a stronger authentication token. In particular, LTPA tokens have limited lifetimes and use strong encryption. The security subsystem audits the receipt of potentially forged LTPA tokens.

43. Validate all user inputattack code

Cross-site scripting is a fairly insidious attack that takes advantage of the flexibility and power of Web browsers. Most Web browsers can interpret various scripting languages, such as JavaScript. The browser knows it is looking at something executable based upon a special sequence of escape characters. There lies the power, and dangerous flaw, of the Web browser security model.

Intruders take advantage of this hole by tricking a Web site into displaying in the browser a script that the intruder wants the site to execute. This is accomplished fairly easily on sites that allow for arbitrary user input. For example, if a site includes a form for inputting an address, a user can instead input JavaScript. When the site displays the address later, the Web browser will execute the script. That script, since it is running inside the Web browser from the site, has access to secure information, such as the user's cookies.

So far, this doesn't seem dangerous, but intruders take this one step further. They trick a user into going to a Web site and inputting the "evil script", perhaps by sending the user an innocent URL in an email. Now the intruder can use the user's identity to do harm. See Understanding Malicious Content Mitigation for Web Developers for more information.

This problem is actually a special case of a much larger class of problems related to user input validation. Whenever you allow a user to type in free text, you must ensure that the text doesn't contain special characters that could cause harm. For example, if a user were to type in a string that is used to search some index, it may be important to filter the string for improper wildcard characters that might cause unbounded searches. In the case of cross-site scripting prevention, you need to filter out the escape characters for the scripting languages supported by the browser. The message here is that all external input should be considered suspect and should be carefully validated.

44. Store information securelyattack code

To create a secure system, you must consider where information is stored or displayed. Sometimes, fairly serious security leaks can be introduced by accident. For example, be cautious about storing highly confidential information in the HTTP Session object, as this object may be serialized to the database. Thus, that information could be read from there. If an intruder has access to your database, or even raw machine-level access to the database volumes, he or she might be able to see information in the session. Needless to say, such an attack would take a high degree of skill.

45. Auditing and tracing can be sensitiveattack code

Any non-trivial application will generate substantial logging and tracing information for business purposes and debugging purposes. That's all well and good. Just remember that information in files has a tendency to end up in a lot of places (maybe outside your company). Extremely sensitive information should not be traced, and you should try to avoid auditing it if you can. For example, we've seen clients that print user passwords to a trace file. If that file is read by the wrong person (perhaps a consultant there to help you), you have just revealed sensitive information inappropriately.

We strongly recommend limiting what is logged and reviewing what is logged just to be safe.

46. Invalidate idle usersattack code

Invalidate user HTTP Sessions and authentication sessions as soon as you are done with them. Doing so reduces the possibility of idle sessions being hijacked by another user. It also frees up resources for other work.

HTTP Sessions are destroyed by using the HTTPSession.invalidate() method. WebSphere Application Server authentication session information is destroyed by directing the user to the ibm_security_logout URL. See the WebSphere Application Server Information Center for details. It's worth noting that the most reliable way to eliminate cookies in the browser is to simply exit the Web browser. Many Web sites now recommend this explicitly; perhaps yours should as well. Note that the closing of the browser does not remove any server side state -- that will wait for a server side timeout. You might consider capturing the browser close event with JavaScript if this is a concern.

Continue to Part 2

This article continues in WebSphere Application Server V6 advanced security hardening, Part 2: Advanced security considerations.



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 WebSphere on developerWorks

ArticleTitle=IBM WebSphere Developer Technical Journal: WebSphere Application Server V6 advanced security hardening -- Part 1