Understanding Cross-Site Scripting Protection

Cross site-scripting (also referred to as XSS) is a security breach that takes advantage of dynamically generated Web pages. In a XSS attack, a Web application is sent a script that activates when it is read by a user's browser. Once activated, these scripts can steal data, even session credentials, and return the information to the attacker.

If malicious code were introduced into an Oracle Application Express application, it could be rendered into HTML regions and other places within the application during normal page rendering. To prevent the introduction of malicious code into session state, the Application Express engine escapes characters in certain cases.

Topics:

Protecting HTML Regions and Other Static Areas
Protecting Dynamic Output
Protecting Report Regions
Protecting Form Items

Protecting HTML Regions and Other Static Areas

In HTML regions and other static display areas, you can reference session state using the &ITEM. notation. Examples of static display areas include HTML regions, page headers and footers, region headers and footers, region titles, button labels, help text, form item labels and post-element text, templates, radiogroup (before and after field text), event success messages, event error messages, navigation bar attributes, application static substitution string values, chart labels and legends, breadcrumbs and list framing text, and calendar text, labels, or legends.

About Safe Item Display Types

When session state is referenced in this way, the value emitted to the page will not have special characters (<, >, &, ") escaped if the referenced item is one of the following safe item display types:

Display as Text (does not save state)
Display as Text (escape special characters, does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PL/SQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)

If the referenced item has a display type other than one of the above types, the value emitted to the page will have special characters escaped. Although application-level items are also considered to have a safe display type, they do not actually have display properties like form items do.

About the Rules Used to Determine Whether to Escape Values

The Application Express engine uses predefined smart escaping rules to determine if and when to escape values fetched from session state.

The reason for these rules is that items that use the display types listed previously are often for text containing HTML that is intended to be emitted to the browser without being filtered (that is, escaped). The only way this can be made safe is by the enforcement of the rule that these types of items are always escaped on input to the application. For example, if a user passes some text into a safe item using an Oracle Application Express f?p URL syntax, the Application Express engine escapes special characters when saving the value into session state. This has two intended results:

If the value contained no special characters, the value passed in is saved into session state exactly as it was provided.
If the value contained special characters, those characters are escaped when the value is saved into session state.

In either situation, the item can now safely be referenced using an &ITEM. notation in any HTML region or other static area mentioned previously.

Using Safe Item Types to Hold and Emit HTML Markup

You can use the safe item types listed previously to hold and emit HTML markup to the browser. For example, suppose you have a requirement to render some text in bold face by referencing a safe page item named P1_XXX (using &P1_XXX.) The item P1_XXX is presumed to contain the following HTML:

<b>ABABABAB</b>

You can achieve this by using application controls (computations, processes, item source expressions, item default values, and so on) to store values into these safe items. When values are introduced in this way, you ensure the safety of the content. When you use these methods, the Application Express engine does not escape any special characters when saving the values into session state.

Finally, the safety of safe items is ensured by a rule that prevents those items from being posted on a page and submitted to the Application Express engine as part of a page submission.

Protecting Dynamic Output

Items fetched from session state and rendered using htp.p or other methods should be explicitly escaped by the code where it is appropriate to do so. For example, suppose a PL/SQL dynamic content region on a page uses the following:

 htp.p(v('SOME_ITEM'));

If the value of the item fetched from session state could contain unintended tags or scripts, you might want to use the following in the region:

htp.p(htf.escape_sc(v('SOME_ITEM')));

However, if you are confident that the fetched value is safe for rendering, you do not need to escape the value. As a developer, you need to determine when it is appropriate to not escape output.

As a best practice, follow this rule:

Never emit an item fetched from session state without escaping it unless the item is one of the safe types described in "About Safe Item Display Types".

The reason for this is that as a developer, there is no way you can prevent a hacker from posting a malicious value into a non-safe item. Even if your application does not present these items visibly to ordinary users, be aware that a hacker can mount a XSS attack using your application if you do not follow this rule.

Protecting Report Regions

The Application Express engine escapes data rendered in the body of a report. References to session state in report headings and messages are fetched from session state using the smart escaping rules so that the values of safe item types are not escaped and the values of other item types are escaped.

Protecting Form Items

When form items, including hidden items, obtain their values during the generation of the form page to be sent to the browser, the resulting text is escaped before rendering. Some of the safe item types are exceptions to this rule in order to support the intended behavior of each display type.