APEX uses the best of modern web technologies to create native web applications. Unfortunately, this also introduces modern vulnerabilities that we need to be aware of. To protect applications, APEX has several built-in security features to prevent SQL Injection and Cross-Site Scripting.
Often, important processes in our applications are triggered when a button is clicked. For UI reasons, if a process can’t be triggered, or users don’t have permission, the button may become inactive or disabled. However, this is only HTML. If the application process is not secure, someone with basic HTML knowledge can re-enable this button and trigger your 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 up:
<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?
In some cases, it could work, but if you have just an application process on the page that fires when you submit the page, someone can easily call it by using just the JavaScript below:
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?
Let’s look again to the button HTML above.id\=”SAVE”, the condition: “only fire when the SAVE button is clicked” means the same as “request = ‘SAVE’”. The would-be hacker just needs to add the request to the JavaScript.
In the next scenario, there is a status item that I set to a value (OK) when the process can be called; can I check this item value before calling the application process? The malicious user may also know the JavaScript below.
We need also insure that each page has access protection, otherwise the hacker can set inject values in the URL.
Available options include:
- Unrestricted
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.
https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:RIR:P4_ITEM:1
- 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.
Tips:
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.
Summary:
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.