APEX uses the best of the modern web to create native web applications; unfortunately, this also brings modern vulnerabilities that we always need to be aware of. To protect applications, APEX has a number of in-built security features available to prevent SQL Injection and Cross Site Scripting.
Often, important processes in our applications fire when a button is clicked. For UI reasons, if a process can’t be fired, or the users don’t have permission to do it, the button may become inactive or disabled. However, this is only HTML, if the application process is not safe, someone with a minor knowledge of HTML can revert this button back to life and boom! Fire you process!
Let’s first see what is behind a disabled button; if we inspect this button using the chrome console (right click on the button and select “inspect”), something similar to the code below will show.
<div class="t-ButtonRegion-buttons"> <button onclick="apex.confirm('Are you sure you want to place this order?','PLACE_ORDER');" class="t-Button t-Button--hot lto6341306998453375987_0 apex_disabled" type="button" id="SAVE" disabled=""> <span class="t-Button-label">Complete Order</span></button> </div>
If we remove the property disabled=”” and the class apex_disabled, the button becomes active and clickable again.
So, should I hide the button?
Therefore, what if I hide the button and add a Server-side Condition in the application process to only fire when the SAVE button is clicked?
We need also insure that each page has access protection, otherwise the hacker can set inject values in the URL.
Available options include:
The page may be requested using a URL, with or without session state arguments, and without having to have a checksum. The URL below includes the RIR request and set the value 1 for the P4_ITEM.
- Arguments Must Have Checksum
If Request, Clear Cache, or Name/Value Pair arguments appear in the URL, a checksum must also be provided. The URL below includes the RIR request, set the value 1 for the P4_ITEM and include a checksum.
If we manually try to change the value, 1 to another one, the user will get the following error.
Session state protection violation: This may be caused by manual alteration of a URL containing a checksum or by using a link with an incorrect or missing checksum. If you are unsure what caused this error, please contact the application administrator for assistance.
- No Arguments Supported
A URL may be used to request the page, but the URL cannot contain Request, Clear Cache, or Name/Value Pair arguments.
- No URL Access
The page may not be accessed using a URL.
However, the page may be the target of a Branch to Page branch type, as this does not perform a URL redirect.
- Avoid by applying conditions to the application process that check page items.
- Create page validations to double check using the same rule that made the button disabled.
- Use APEX authorization schemes to validate page access. Even if a page is not available on the menu to a specific user, the user can set the page number in the page URL (https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:::) and go to the page if there is no authorization is selected. To create authorization schemes, go to Shared Components \ Authorization Schemes and then any that you create will be available in the page properties.
APEX is very safe and used by numerous military and classified agencies around the world, but like most web technologies, the developers needs to know and use the security resources in order to avoid breaches that could make the app vulnerable.
Rodrigo is a Development Consultant at Explorer. Rodrigo has an Oracle APEX Developer Expert Certification issued by Oracle and is an experienced software engineer with emphasis in analysis, design and development of bespoke Oracle applications utilising development tools such as PL/SQL, APEX and Forms for a variety of international businesses.