APEX - Identify Report Columns Vulnerable to XSS

The following query is a very simple way of identifying all report columns within your APEX application that may be exposed by Cross Site Scripting (XSS).

XSS allows an attacker to inject web script (JavaScript) into an application and when this is rendered in the report, the script is interpreted rather than rendered as text.

To safe guard against this attack, APEX provides a "Display as Text (escape special characters)" report column attribute that can be applied to classic and Interactive Reports. This causes the script text to be displayed as text rather than interpreted by the browser. If you have any markup (HTML) within your query that the report is based on, this markup will also be displayed as text and not interpreted. I personally think this is a good by product as you should not really be coding look and feel into your raw SQL.

Anyway I digress. Here is the query that will identify all vulnerable report columns within your APEX application:

  SELECT application_id,
         application_name,
         page_id,
         region_name,
         column_alias,
         display_as
    FROM apex_application_page_rpt_cols
   WHERE display_as NOT IN
               ('Display as Text (escape special characters, does not save state)',
                'CHECKBOX',
                'Hidden',
                'Text Field')
         AND workspace != 'INTERNAL'
         AND application_id = :APP_ID
ORDER BY 1, 2, 3;

Enjoy

Comments

Unknown said…
This is a good topic and one that probably needs a bit more attention, however shouldn't the focus be more on preventing the XSS injection rather than preventing your application from displaying/executing the XSS script?

That aside thanks for the query!
24 February 2010 at 10:28
Duncan said…
Enzo

I disagree with your notion that "preventing the XSS injection" should be the focus as you enter somewhat into a minefield of validations to remove "bad scripting".

This would normally mean validating ALL users input on the client via some scipting and server side via SQL / PL/SQL possibly.

The danger is that client side validation can be bypassed with some know how so you are then putting all your faith on your server side validation. This would normally mean removing opening tags, the word script etc. Under no circumstances is this logic valid as there may be valid business data that includes these values.

Adopting the approach of accept anything and protect the output is the only way to maintain the EXACT data entered by the user and not open your app to XSS.

Just my 2 cents

Duncs
24 February 2010 at 11:43
Unknown said…
Touche, you make a very good point!

My focus has always been on data and ensuring it is clean, a number of generic functions e.g. like "strip scripts" using regex enable this which can either be used in computations, validations, or in triggers.

In regards to "all your faith on server side validation", don't you mean the "all your faith in the developer". I think if you go as far as looking to secure your reports you should possibly think about ways to secure your data as well. Since most systems these days share data.

Anyway thanks for the response it was really insightful.
24 February 2010 at 14:41
Post a Comment

Popular posts from this blog

Custom Authentication / Authorisation Schemes (Part 1)

I often see posts on the APEX forum asking how to implement custom Authentication / Authorisation schemes within their applications. The following is something I have used in several apps over the last couple of years and provides a great base for securing your application. The code base is largley based on the rather excellent article " Storing Passwords in the Database " found here with a few tweaks and changes. Firstly, just to clarify, Authentication Schemes control access to the application and Authorisation Schemes control access to page items / regions and even pages themselves. Implementing your own Authentication I tend to set up an APP_USERS table that stores Username and encrypted passwords that I Authenticate against when page 101 is submitted. All this will be explained in detail as we go. Create the APP_USERS table CREATE TABLE APP_USERS ( USERNAME VARCHAR2(10), PASSWORD VARCHAR2 (255) ); Create the Application Security Package CREATE OR REPLACE PACKAGE app_sec...
Read more

Custom Error Handling in APEX

If like me you have written several PL/SQL procedures within your APEX app, you will have had to deal with the issue of error handling. As a general rule, I try to hide all Oracle Error Messages from the user and replace these with something more meaningful for example: If a user breaks a unique key by trying to insert the same value twice, the following error message is not uncommon: ORA-00001 Unique constraint violated There is little or no merit rendering this message to a user as those outside the Oracle community, may not be able to deduce what went wrong. We can capture this error and translate it to a user friendly message explaining what went wrong for example: The record you tried to create already exists. Please try again In order to achieve this in APEX, the process is relativly simple. Set up your Custom Error Page 1. Create a new page with the following attributes: Page type: Blank Page Page Number: your choice (for this example I used page 500) Page Alias: ERRPAGE Name:...
Read more

Sum to Parent Nodes in Hierarchy Queries: CONNECT_BY_ROOT

In one of our Applicaitons, the table DEPT contains a self referncing join (Pigs Ear) as it models our organsational department hierarchy. For example: CREATE TABLE DEPT ( DEPT_ID NUMBER NOT NULL ,PARENT_ID NUMBER ,DEPT_NAME VARCHAR2 (100) NOT NULL ,EMPLOYEES NUMBER NOT NULL ,CONSTRAINT DEPT_PK PRIMARY KEY (DEPT_ID) ,CONSTRAINT DEPT_FK01 FOREIGN KEY (PARENT_ID) REFERENCES DEPT (DEPT_ID) ); INSERT INTO DEPT VALUES (1,NULL,'IT', 100); INSERT INTO DEPT VALUES (2,1,'DEVELOPMENT', 12); INSERT INTO DEPT VALUES (3,1,'SUPPORT', 15); INSERT INTO DEPT VALUES (4,1,'TEST', 25); INSERT INTO DEPT VALUES (5,2,'PL/SQL', 2); INSERT INTO DEPT VALUES (6,2,'Java', 1); INSERT INTO DEPT VALUES (7,2,'SQL', 11); INSERT INTO DEPT VALUES (8,2,'C++', 3); INSERT INTO DEPT VALUES (9,4,'Functional', 3); INSERT INTO DEPT VALUES (10,4,'Non Functional', 5); COMMIT; A quick tree walk using CONNECT BY PRIOR shows you the Parent / Child rel...
Read more