Background

In recent blog posts, we’ve mentioned that PeopleSoft provides a number of security protections out of the box. In this entry, we wanted to go into more detail on this, specifically focusing on what you should know about PeopleSoft and common web application vulnerabilities.

• Data sniffing
• SQL Injection
• Cross-Site Scripting
• Content Spoofing and Injection
• Directory Indexing
• Information Leakage

If you hire an organization to perform penetration testing (as any organization deploying PeopleSoft on the public internet should), these are the items that they will primarily focus on.

PeopleTools as a Security Platform

One of the most important aspects of security within PeopleSoft, is that the platform ensures that security protections are built in globally.  As such, PeopleTools differs from other development platforms in the following ways:

• Secure by Default:  Developers do not have to write specific security code in the application, because protections are applied automatically — PeopleTools takes care of it for them — thus ensuring that security is enforced consistently.
• Rapid evolution:  Keeping up with potential vulnerabilities is an arms race where new attack vectors are constantly being created by the bad guys.  Because the security logic is applied externally to the application logic, vulnerabilities can be addressed at the platform level, delivered by Oracle, and applied platform-wide immediately.
• Centralized Security Expertise:  PeopleTools has a team of security developers who’s job it is to stay current on best practices and potential vulnerabilities, allowing the rest of the organization to focus on business functionality.  This ensures that customers staying current on their PeopleSoft updates will be have the latest protections available.

So, let’s look at each of the common web vulnerabilities and what PeopleSoft does to remediate them.

Data Sniffing

Although this should be second nature to anybody deploying a web application, SSL termination is a critical component of ensuring secure data transportation between the end-user and the PeopleSoft system. PeopleSoft has configuration settings specifically for SSL termination and virtual addressing so that all traffic can be sent securely.  It also gives organizations the ability to utilize other tiers for SSL termination, such as the load balancer.

SQL Injection

Because many web applications access and store data through a relational database, a common attack vector is to inject SQL into edit boxes, URLs, or other user enterable fields to bypass application logic and talk directly to the database.  This could allow an unauthorized user to:

• Gather sensitive data
• Make unauthorized updates to application data
• Escalate privileges and/or bypass system controls
• Cause service interruptions

The following comic — “Bobby Tables” — pokes fun at this technique:

PeopleTools mitigates this vector through its definitional development infrastructure. When a page is developed in PeopleTools, the developer is rarely writing SQL, but placing the fields on the page.  PeopleTools will generate the SQL with the appropriate size, type, and encoding.

However, PeopleTools does not restrict developers from writing their own SQL, frequently using the infamous SQL-Exec PeopleCode function.  Therefore, it’s important that organizations incorporate strong change management techniques to review in detail any places where customizations are made with SQLExec functions.

Cross-Site Scripting

Cross-site scripting occurs when an unauthorized site or form controls a page or form in your application, making unauthorized updates.  This is commonly done with JavaScript, but can also be accomplished with other techniques.

PeopleTools protects against cross-site scripting by embedding a random token in each PeopleSoft page that is validated by servlets on the PeopleSoft web server.  If the form doesn’t have the token or the token is rejected, the traffic is also rejected.

This vulnerability existed in very early PeopleTools versions (circa 2000), but was remediated quickly platform-wide with a PeopleTools update once the threat vector was discovered and hasn’t been a risk for at least 10 years.

Content Spoofing and Injection

Content spoofing and injection is a whole category of techniques for making unexpected modifications to HTTP traffic between the browser and the application.  Examples include:

• Modifying the URL in unexpected ways
• Altering or removing HTTP Headers
• Altering or removing cookies
• Altering the HTML or XML content

A common technique followed by the bad guys is to install a proxy between the browser and the application, capture traffic, modify the different aspects of the traffic, and play back the results.

PeopleTools protects against spoofing and injection by acting as a single controller that issues and processes the HTTP traffic.  Whenever an unexpected event occurs (such as an unexpected URL), it will either issue a security error (such as You are not authorized to access this component) or will terminate your session.

That said, there are techniques that some implementation decisions that customers can make that would allow an organization to circumvent these protections.  These would include the following:

• Adding an HTTP header to the HTML to maintain the identity of the user for single signon.  If the header is accessible to the end-user and Signon PeopleCode does not have anti-spoofing functionality, modifying the header could allow access without logging in.
• Utilizing the %GetRequest parameter with a SQL-Exec function.  Because this function allows parameters to be embedded in the URL as a query string, improper use of it could open up a vulnerability
• Improper implementation of location-based security rules.  Many organizations will implement location-based security by hiding URLs based on location (versus blocking them).  Because any PeopleSoft page can be accessed directly from a URL, merely hiding navigation does not block access to the content.

Directory Indexing

Directory indexing is a threat vector where a person gets a web server to disclose the list of files and folders on it.  In some cases, this can be used to determine how the application works behind the scenes, even to point of looking at the code that is running on the server.

PeopleSoft provides a few protections against this:

• The first is that all of the security, business and database logic runs on a server separate from the PeopleSoft web server.  This means that gaining access to the web server does not provide access to the directories controlling how the application processes
• The second is that PeopleSoft has a number of ways in which it can be deployed in conjunction with a DMZ.  One common option is to have a proxy server running in the DMZ where the web server itself is behind the corporate firewall.

Information Leakage

The last threat vector we will discuss.  From the context of this discussion, we will be covering information leakage as it relates to an external attacker trying to learn about how the system operates.  Information Leakage can also be discussed from the perspective of an authorized user’s use of sensitive application data, which will be discussed in a future post.

Anybody familiar with PeopleSoft’s Control-J function is familiar with type of data that can be leaked.  This page provides information about the version of PeopleTools, the PeopleSoft application, and the ports that are being used on the app servers.  At the weblogic level, the weblogic console provides information about the java version being run, etc.  Although it is great for troubleshooting issues in a development or test environment, an external person can utilize this to research known vulnerabilities for the versions being utilized to plan an attack.

Fortunately, PeopleSoft provides a configuration option in the web profile to turn off disclosure of this information, and the default PROD web profile has this setting made appropriately.