|
Oracle® HTML DB
Release 2.0 |
|
 Previous |
 Next |
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, or even session credentials and return the information to the attacker. If malicious code were introduced into an Oracle HTML DB 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 HTML DB engine escapes characters in certain cases.
Topics:
In HTML regions and other static display areas, you can reference session state using the &ITEM. notation. Examples of static displays 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.
You can control whether items are escaped when they are rendered using the Cross-Site Scripting Protection attribute on the Edit Page Item page.
To enable cross-site scripting protection:
Navigate to the appropriate Page Definition:
Navigate to the Workspace home page.
Click the Application Builder icon.
Select an application.
Select a page.
The Page Definition appears.
Under Items, select the item name.
The attributes page for the item appears.
Scroll down to Security.
From Cross-Site Scripting Protection select one of the following:
Yes - Indicates the item is deemed safe to render exactly as is when fetched from session state. If you select Yes, the item is escaped when it is passed into session state using an f?p URL or when saved in session state when it is submitted on the page.
No - Specifies the item should be escaped when it is rendered. If you select No, the item is not escaped when it is passed into session state using an f?p URL or saved in session state when it is submitted on the page.
Click Apply Changes.
|
Note: Application-level items have an implicit setting of Yes for this attribute which cannot be changed. |
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 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 script, 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.
The Oracle HTML DB escapes data rendered in the body of a report. References to session state in report headings and messages, are fetched from session state using a method that assumes that referenced values have the Cross-Site Scripting Protection attribute enabled. In other words, these values are not escaped when they are fetched because it is assumed that they have been escaped on input. As you create reports, it is important you understand this assumption and not reference items in reports for which the Cross-Site Scripting Protection attribute is set to No.
When form items, including hidden items, obtain their values during page rendering, the resulting string is escaped before rendering. The only exception are items of display type Display as Text (does not save state), which are not escaped.
Items having the display type Display as Text (does not save state) feature a unique escape on input behavior. These items obtain values containing HTML or script by way a page computation, page processes, or source and default values from within an application, but they cannot obtain values using f?p URLs or by POSTing them. This behavior makes them a good choice for framing text values in HTML markup or for including JavaScript.
As an added precaution, always follow best practices to guard against cross-site scripting attacks. For example, during the development process think about whether or not an item could have malicious content stored in it by URL tampering or another means. Avoid referencing form items using &MY_ITEM. for rendering in most types of static areas since it can lead to security vulnerabilities. Instead, use application-level items or page items of type Display as text (does not save state). Another easy safeguard is to escape less than (<), greater than (>), and ampersands (&).