Securing Your PeopleSoft Application - Chapter 6This is a featured page


PeopleSoft devotes a lot of attention and resources to delivering a secure product to its customers. However, most customers don’t implement PeopleSoft applications as they are delivered. To enable customers to meet their unique business needs, PeopleSoft software can be configured in many different ways. If your organization modifies the delivered applications, this new code must be secured.


If you modify the delivered PeopleSoft application, use the following guidelines to verify that these changes don’t compromise the security of your implementation:

    • Every component should have appropriate row-level security.
    • Defend against SQL injection. All user-entered data that is part of dynamic SQL must be isolated to a bind variable.
    • All user-entered HTML must be escaped.
    • All hidden page fields should have the ‘Modifiable by HTML’ flag turned off with the exception of those that are used to control the user interface.
    • All user-entered file names should not contain complete or relative paths.

Configure every Component for Row-Level Security

Every component should apply row-level security that’s appropriate for the end user.

Note. In some cases, NONE (or no row level security) is appropriate.

Row level security can be implemented in several ways, such as:

    • Applying security using search views.
    • Applying security using search prompt views.
    • Applying security using an application-specific framework. (For example, HR manager self-service or application coded search pages.)
Determine the method used by your product or product line and ensure that your component adheres to the standards used for that product.


Care must be taken anytime you construct a SQL statement using user input as part of that statement. Never allow the end-user to enter a string that contains an entire SQL statement or a SQL fragment. To ensure security, use the user data as a bind variable rather than concatenating it to a SQL statement.

For example, suppose that the user supplies a value for a WHERE condition.

Good: SELECT ABC FROM TABLE A WHERE A = :1
Bad: SELECT ABC FROM TABLE A WHERE A = | user-entered-value


If you’re writing your own HTML and plan to use user-supplied values, then user values should contain displayable data and not scripts. All string data must be escaped by calling the EscapeHTML PeopleCode function.

Example: &myHTML = &myHTML | EscapeHTML(&user-supplied string)


If your HTML contains JavaScript that accesses hidden fields on a page, ensure that the page field property “Modifiable by HTML” is enabled for the hidden field you plan to modify.

The hidden field’s logic should be limited to the user interface on the page. You should not code logic on the application server (i.e., PeopleCode) that relies on data in hidden fields.


If you have applications that allow users to specify a destination path to store files, you should only allow file names and directories as separate items, instead of a path.

For example —
Good: Location: Appserver File: myfile.xxx (assuming that this is appended to a specified home location).
Bad: C:\appserver\myfile.xxx






gregkelly
gregkelly 		Latest page update: made by gregkelly , Feb 25 2009, 7:22 PM EST (about this update About This Update gregkelly Rename - gregkelly

No content added or deleted.
- complete history)
Keyword tags: None
More Info: links to this page

Threads for this page

There are no threads for this page.  Be the first to start a new thread.