Developer security best practices include configuring password item types, identifying risky password items, viewing the Security Profiles report, understanding cross site-scripting protection, managing session state, preventing URL tampering, and securing file uploads.
See Also:
Parent topic: Managing Application Security
Password items do not emit the text entered to the web browser screen. When creating password items, Oracle recommends using password attributes that do not save session state to prevent the password from being saved in the database in the session state tables.
Configurable password item type attributes include:
Value Required - If set to Yes and the page item is visible, Oracle Application Express automatically performs a NOT NULL validation when the page is submitted. If set to No, no validation a NULL value is accepted.
Submit when Enter pressed - If set to Yes, when the user presses the ENTER key in the field the page is submitted.
Does not save state - If set to Yes, the password is not saved into session state. For security reasons you should always set this attribute to Yes. If you set it to No, consider to set the attribute Store value encrypted in session state to Yes.
Authorization Scheme - Optionally select an authorization scheme which must evaluate to TRUE in order for this component to be rendered or otherwise processed.
Session State Protection - You can select the level of session state protection by setting this attribute to Unrestricted or Restricted.
Unrestricted means the item may be set by passing the item in a URL or in a form. No checksum is required in the URL.
Restricted means the item may not be set from a browser. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed, even if Session State Protection is disabled.
Store value encrypted in session state - Session state that is sensitive can be encrypted when stored in Application Express session state management tables. To maintain session state encrypted for this item set the value to Yes. To learn more, see "About Session State and Security".
See Also:
Parent topic: Understanding Developer Security Best Practices
Use the Security Profiles report and Password Items report to help identify at risk password items.
At risk password items are those that either:
Do not use a password item type that does not save session state.
Store an unencrypted value in session state .
Parent topic: Understanding Developer Security Best Practices
To view the Security Profiles Report:
Parent topic: Identifying At Risk Password Items
To identify at risk password items:
Tip:
For pages that contain password items, set the page attribute Form Auto Complete to Off. Setting that attribute to Off prevents the web browser from attempting to auto complete items on the page.
Parent topic: Identifying At Risk Password Items
Learn about best practices for protecting your application from a cross site-scripting security breach.
Parent topic: Understanding Developer Security Best Practices
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.
Parent topic: Understanding Cross-Site Scripting Protection
Learn how to protect HTML regions and other static display areas.
Parent topic: Understanding Cross-Site Scripting Protection
In HTML regions and other static display areas, you can reference session state using the substitution strings. Special substitution strings available within a template are denoted by the number symbol (#), for example, #ABC#
. To reference page or application items use 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.
Developers can also append an exclamation mark (!
) followed by a predefined filter name to a page or application item name or to a report column reference to escape special characters in the substitution value.
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 Display Only with the attribute Save Session State set to No and Escape Special set to No.
If the referenced item has a display type other than Display Only with the attribute Save Session State set to No, 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.
See Also:
Parent topic: Protecting HTML Regions and Other Static Areas
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.
Parent topic: Protecting HTML Regions and Other Static Areas
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.
Parent topic: Protecting HTML Regions and Other Static Areas
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(apex_escape.html(: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 must 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 a safe type.
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.
See Also:
Parent topic: Understanding Cross-Site Scripting Protection
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.
Oracle Application Express automatically escapes HTML special characters of a report column when the column's Escape special characters attribute is set to Yes. If you need to render HTML fragments instead of plain column values (for example, for highlighting), instead of concatenating the HTML fragment in the query itself (which prevents you from using Escape special characters), you should use the report column's HTML Expression attribute. In the HTML Expression attribute, you can enter static HTML and embed escaped column values with the #COLUMN#
notation. The extended column notation gives you control regarding how Oracle Application Express should escape a column value:
#COLUMN!HTML#
- Escapes reserved HTML characters.
#COLUMN!ATTR#
- Escapes reserved characters in a HTML attribute context.
#COLUMN!JS#
- Escapes reserved characters in a JavaScript context.
#COLUMN!RAW#
- Preserves the original item value and does not escape characters.
#COLUMN!STRIPHTML#
- Removes HTML tags from the output and escapes reserved HTML characters.
For example, suppose you have a report based on this query:
SELECT empno, ename, NULL DELETE_LINK FROM emp
In this example, all columns are escaped. You could define a HTML Expression on DELETE_LINK
as follows:
<a href="javascript:if (confirm('Do you really want to delete #ENAME!JS#?')) doSubmit('DELETE-#EMPNO#');">Delete</a>
This example renders a link that asks if you would like to delete an employee and submits a request to delete the row if the user is confirmed. If you had not used #ENAME!JS#
but #ENAME#
, a name like O'Neill would cause a syntax error and an attacker could exploit the improper escaping for cross-site scripting.
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 to support the intended behavior of each display type.
Some item types have the Security attribute Escape special characters. Use the Escape special characters attribute to specify if the value should be escaped or not. The default is set to Yes. To display HTML code, set this attribute to No.
Developers can also append an exclamation mark (!
) followed by a predefined filter name to a page or application item name or to a report column reference, to escape special characters in the substitution value.
Parent topic: Understanding Cross-Site Scripting Protection
You can limit cross site-scripting and other injection attacks by restricting the characters users can enter on an item. To accomplish this, use the Restricted Characters attribute in the Security region of the Edit Page Item page. Restricted Characters can be saved in session state. Available options include:
All Characters Allowed
No restriction applies.
Whitelist for a-Z, 0-9 and space
Only allow characters a-z, A-Z, 0-9, and space.
Blacklist HTML command characters (<>").
Do not allow reserved HTML characters
Blacklist &<>"/;,*|=% and --:
Do not allow &, <, >, ", /, ;, ",", *, |, =, % and "--" (PL/SQL comment).
Blacklist &<>"/;,*|=% or -- and new line
Do not allow &, <, >, ", /, ;, ",", *, |, =, %, "--", and new line characters
If you select a restriction, Oracle Application Express displays an error message if a user tries to save data which does not conform to the selected character restriction.
See Also:
Parent topic: Understanding Cross-Site Scripting Protection
Learn about managing session state and security.
Oracle Application Express persists session state in database tables. Session state is preserved in database tables because it is more secure to store the session state on the server side than on the client. Because Oracle Application Express applications use the stateless HTTP protocol, an application's session state across multiple page views is preserved in database tables. Not maintaining a synchronous database connection for each Oracle Application Express application user significantly lessens memory and database resource requirements.
Developers can query the session state stored by Oracle Application Express applications using the App Builder and built-in monitoring pages. Developers and administrators can access session state for any application in the workspace to which they are authenticated.
Developer best practices for managing session state include:
As a standard part of implementing program control flow, clear the session state of unneeded values using clear-cache page processes or clear-cache directives in URLs used to navigate to pages.
Use password page item types that do not save state. This prevents the entered passwords from being saved in session state tables in the database.
When sensitive data must persist in a session, it should be saved in Oracle Application Express session state tables in encrypted form. To use this feature, set the page item's Store value encrypted in session state attribute to Yes. Encrypted stored values are automatically decrypted when read.
Note:
The objective of encrypted session state is to persist session state such that the unencrypted values cannot be read by other Oracle Application Express developers or database administrators who might have access to the Oracle Application Express session state tables, debug output, or database data files. Oracle recommends that database backups be performed using facilities that encrypt data in the backup files.
Tip:
You can encrypt item values up to 4000 bytes in length. Attempts to encrypt values longer than 4000 bytes produces an error message.
Parent topic: Understanding Developer Security Best Practices
Session State Protection is a built-in functionality that prevents hackers from tampering with the URLs within your application. URL tampering can adversely affect program logic, session state contents, and information privacy.
Parent topic: Understanding Developer Security Best Practices
When enabled, Session State Protection uses the Page Access Protection attributes and the Session State Protection item attributes with checksums positioned in f?p=
URLs to prevent URL tampering and unauthorized access to and alteration of session state. When Session State Protection is disabled, the page and item attributes related to session state protection are ignored and checksums are not included checksums in generated f?p=
URLs.
Parent topic: Preventing URL Tampering
You can enable session state protection from either the Edit Security Attributes page or the Session State Protection page.
Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes. You can perform these steps using a wizard, or you can set security attributes for pages and items manually on the Session State Protection page.
Parent topic: Preventing URL Tampering
To enable Session State Protection from the Edit Security Attributes page:
Tip:
To disable Session State Protection, perform the same steps again, but select Disabled instead of Enabled. Disabling Session State Protection does not change existing security attribute settings, but those attributes are ignored at runtime.
Enabling Session State Protection affects whether bookmarked links to the current application work. Consider the following rules:
Bookmarked links created after Session State Protection is enabled work if the bookmarked link contains a checksum.
Bookmarked links created before Session State Protection is enabled do not work if the bookmarked link contains a checksum.
Bookmarks that do not contain checksums or contain unnecessary checksums are not affected by Session State Protection.
During page rendering, the Application Express engine uses a hidden application attribute (a checksum salt) during computation and to verify checksums included in f?p
URLs. When you enable Session State Protection, the Application Express engine includes checksums. You can reset the checksum salt attribute by clicking Expire Bookmarks on the Edit Security Attributes page.
Tip:
Be aware that if you click Expire Bookmarks, bookmarked URLs used to access your application that contain previously generated checksums will fail.
On the Confirm Invalidate Bookmarks page, you can also configure the Bookmark Checksum Function which is the hash algorithm used for computing bookmark checksums.
To enable Session State Protection:
Tip:
To disable Session State Protection, perform the same steps, but select Disable instead of Enable. Disabling Session State Protection does not change existing security attribute settings, but those attributes are ignored at runtime.
Parent topic: Enabling Session State Protection
Tip:
Before you can configure security attributes, you must first enable Session State Protection. See "Enabling Session State Protection".
Parent topic: Preventing URL Tampering
Once you have enabled Session State Protection, the next step is to configure security attributes. You can configure security attributes in two ways:
Use a wizard and select a value for specific attribute categories. Those selections are then applied to all pages and items within the application.
Configure values for individual pages, items, or application items.
Parent topic: Configuring Session State Protection
You can review a summary of Session State Protection settings for pages, items, and application items on the first page of the Session State Protection wizard.
To view summaries of existing Session State Protection settings:
Parent topic: Configuring Session State Protection
When you configure Session State Protection using a wizard, you set a value for specific attribute categories. Those selections are then applied to all pages and items within the application.
To configure Session State Protection using a wizard:
Parent topic: Configuring Session State Protection
To configure Session State Protection for Pages:
See Also:
Parent topic: Configuring Session State Protection
To configure Session State Protection for items:
See Also:
Parent topic: Configuring Session State Protection
To configure Session State Protection for application items:
See Also:
Parent topic: Configuring Session State Protection
Learn about developer best practices for securing file uploads.
Oracle Application Express enables you to easily build an application that can be used to upload files and to access uploaded files. These files are uploaded into a common file storage table. Although the database view APEX_APPLICATION_FILES
shows those files associated with your database account (or workspace), programmatic access to the common file storage table does not always require authentication, enabling other users to see your uploaded files.:
See Also:
"About the Differences Between Page Items and Application Items"
"About Item Types" to learn more about creating a File Browse page-level item
Parent topic: Understanding Developer Security Best Practices