Oracle APEX - JQuery UI XSS Bug

JQuery UI is a brilliant library included in APEX that can help developers with both the functionality and the aesthetics of their applications. However, it is not without its bugs. There is a known bug in JQuery UI (#6016) that causes a cross site scripting vulnerability in applications that include modal dialogs with dynamic titles.

Here is a simple example of a Cross Site Scripting (XSS) attack that exploits this bug in the code from our previous blog post:

Although this bug has been fixed in JQuery UI v.1.8.4, APEX 4.2.2 ships with version 1.8.22, so in terms of developing secure applications with APEX, this is still an issue that must be addressed in order to ensure your applications are secure.

The issue is that the Jquery dialog box does not HTML escape the data before rendering it in the title, therefore this must be done manually by the developer. To fix the issue you can add the following line to your JavaScript function:

                                                         title= $('<div/>').text(title).html().replace('"','&quot;');

The text() function in JQuery HTML escapes anything within it apart from single and double quotes, so for added safety we included double quotes by adding “.html().replace('"','&quot;')”

This and other security issues are regularly found in our code reviews for our high security installs.

Oracle APEX - XSS in JavaScript column link URL

The more security conscious of you may have noticed, or may be interested to know, that there is a cross site scripting vulnerability in the column link URL when using JavaScript. This is regularly flagged in our ApexSec security scanner. In this post we will use an application with JQuery's modal dialog to illustrate this common vulnerability and its simple solution. - Check out our previous post on how to have page access protection for pages inside modal windows.

This type of problem has been mitigated in APEX 4.2.2, if the URL field of your link column starts with 'javascript:', APEX will JavaScript escape the template variables before replacing them within the JavaScript block. This is a security upgrade intended to remove the risk of this type of Cross Site Scripting (XSS) attack.

This vulnerability is with the second parameter of the modal window call (in this case the #ENAME# template variable). Modal dialogs are a common feature within any application and they allow you to give the dialog a dynamic title to enhance the User Experience (UX).

In our example, the title of the modal window opened when the edit link in the report is clicked is defined by the 'ENAME' column. So if you click to edit the employee named 'blake' then the title of the window is 'blake'. Here you can see the difference between the JavaScript in the previous blog post and the Javascript necessary to have a dynamic title in the modal window:

       Comparison of the JavaScript used in our previous blog post and the JavaScript required for a dynamic title.

We have added a second parameter called 'title' to our mymodal function. The title is no longer being defined literally as “Some title” and is now defined by the parameter variable 'title'.

Now navigate to the URL field in the link column section of the report attributes and use the template variable #ENAME# to pass the value from the ENAME column into the title parameter of the 'mymodal' function..

Whenever an edit link is clicked, the title of the modal window is set to the value of the “ENAME” column for that row in the report.

The vulnerability occurs because the template variable is only HTML escaped. This leads to an injection attack within this function call. Because the template variable occurs within a JavaScript block you can pass any text you like into the title, including JavaScript and you are therefore vulnerable to a XSS attack;

If you are using a version of APEX less than 4.2.2, your first course of action should be to ensure that the URL field for your link column is not passing a potentially malicious title to the modal window function. Our method of doing this is to create a new column in the query for your report with the following PL/SQL:

This JavaScript escapes the values in the column “ENAME” and then names this new column “ENAME_JS”. You can go ahead and make this column "HIDDEN" in order to maintain a user friendly report. Now in the URL field for the link column your second parameter should be changed from “ENAME” to “ENAME_JS”. This ensures the values being passed into your modal window function are JavaScript escaped.

In our next post we will discuss a known bug in the JQuery version that is shipped with APEX 4.2.2, as it causes another cross site scripting vulnerability in this example application that also must be fixed in order to fully erradicate the threat of XSS.

Click here to download the application used in this example.

Oracle APEX - URL Checksums and JQuery Modal Dialogs

The Problem

We, like many others have stumbled upon the issue of pages not loading inside a Jquery dialog when the page access protection is set to “Arguments must have checksum”. This is an essential security feature in APEX that prevents the manipulation of the URL in APEX pages. You will see the following error when the dialog is opened:

In our example, both the edit link in the report and the Create button outside the report must be able to successfully open the DML form inside the modal window. The problem being that the page fails to load due to the checksum not being correctly generated.

We used the following JavaScript to open the JQuery dialog:

                                         With “url” being defined in the URL field of our report's link column settings. 

We changed the target of the link column in the report from “A page in this application” to “URL” and then defined the URL as:

The issue here is that there is no checksum being generated for this link, so therefore the destination page (page 3) fails to load inside the modal window because the page access protection is set to require checksum.

The Solution

Our solution is to create a hidden column in the report, and use the “Apex_util.prepare_url” function to populate this column with the relevant URL and checksum for each entry in the report. We'll then use the template variable for that column to pass the URL into the JavaScript function call for the JQuery modal dialog.

To do this, navigate to the report region, Go to the "Region Definition" tab and in "Region Source" you should add the line:

This adds the column “LINK_URL” to the report and populates it with the URL for the edit form page. This time the checksum will be generated. We must now return to the page and make this column's display type “HIDDEN”. - When adding or removing a column from a report, you may have to log out and log back into your application for the changes to take effect.

The next step is to insert the template variable (#LINK_URL#) for the hidden column into the JavaScript function call. Navigate back into the report, drill down into report attributes > column link settings and change the “URL” field to be:

Now when the edit link is clicked in the report, the modal window will open and because the checksums are being correctly generated, the page will be displayed.

There is also a problem with the “Create” button used to add entries to the report. The template variable #LINK_URL# cannot be used as it exists in the report row and not in the page.

Our solution is to create a page item on the page and set its display type as “HIDDEN” (we named this P2_HIDDEN).

We then create a dynamic action which will contain two “true” actions, both of which are to be executed when the “Create” button is clicked.

The first of these actions will be to execute some PL/SQL code to populate this new hidden item “P2_HIDDEN” with the URL to open a blank DML form. We still need to generate a checksum because of the clear cache parameter. So the first “true” action should be:

              PL/SQL Code: :P2_HIDDEN := Apex_util.prepare_url('f?p=&APP_ID.:3:&SESSION.::&DEBUG.:3:');

As you can see, one difference here is that we no longer need to include “empno” as this page is for creating a new entry, not editing a current one. Because of this we have also included '3' in the clear cache portion of the URL. We also set “Page items to return” as the hidden page item, in this case it would be “P2_HIDDEN”. This ensures the new value is returned into the page.

Now that the new hidden item has been populated with the URL we must create a second “true” action to execute the JavaScript code necessary to pass the value of “P3_HIDDEN” into the Javascript function and successfully open the URL in the modal dialog window. This true action should be:

                   JavaScript Code: mymodal($v('P2_HIDDEN'))

The edit link in the report and the create button will now function as intended. The modal dialog window will open with the correct page and the checksum will have been generated in the URL allowing you to maintain the page access protection and avoid URL manipulation.

Click here to download the application used in this example.

Interviewing APEX developers - Are your candidates security aware?

During our regular search for Oracle APEX security things, we stumbled across a blog post called: "Oracle Application Express (APEX) Interview Questions". Selecting the right candidates to fulfil your development requirement is always tricky, and the whole process of interviewing is a difficult thing to get right. There's a interesting book on how Google handle selection of candidates, although more recently Google have admitted that such techniques may be a waste of time.

We've interviewed candidates for a range of positions throughout our careers, sometimes these are just question based, and some had a technical assessment element. Best of all were the general discussions over a beer. So we like the ethos of the APEX interview questions blog post, as a guide to what should be talked over, but we think the security section could use a little refinement. Below we've listed fourteen questions that an interviewer could ask their candidates to judge their overall security awareness with Oracle APEX applications. The skill in assessing the candidate is perhaps not their complete and accurate responses to the questions, but how they handle difficult problems and their thought processes when problem solving.

Interview questions on Oracle APEX security:

1. Discuss why allowing a user to set an item's value can, in some cases, be dangerous.
2. Describe three ways an APEX item value can be set by a user.
3. Explain how the different protection settings can be used to protect item values from being set by the user.
   -
4. What class of vulnerability can be introduced by using substitution variables in SQL with APEX applications?
5. Describe another way such security risks can be present in an APEX application.
   -
6. What's the difference between a Standard Report Column and one that is set to Display as Text (escape special characters)?
7. What type of vulnerability can result from using the former type?
8. Why would you use a Standard Report Column rather than the other type?
9. How can you ensure that the data displayed in a Standard Report Column is safe?
10. Describe another way that this vulnerability class can be introduced into your APEX applications.
    -
11. What's the difference between authentication and authorisation?
12. Describe several policies that would normally be enforced for authentication?
13. If you have a report in your APEX application that should only be accessible to certain users, how can you protect it?
14. Which are the four things in APEX that can be protected with authorisation schemes?

Depending on the role we wouldn't expect every candidate to answer all of these questions. But it could prove useful to explore some of them to ensure that security awareness is part of the selection criteria when interviewing for APEX developers.

If you'd like to learn more about Oracle APEX security, check out our Hands-On Oracle Application Express Security eBook. Our US partners over at SkillBuilders also offer APEX specific security training. For answers to the above questions, contact us and we'll send over details.