Description:
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.
Enabling Session State Protection is a two-step process. First, you activate the feature. Second, you set page and item security attributes.
What is SSP?
SSP is used to prevent URL tampering. URL tampering is when a malicious user modifies URL parameters to access data that they may not have access to. For example, if you have a Master-Detail setup for the EMP table (i.e., a report with edit links to a form) each link will look something like this:
http://fcapex42.clarifit.com:8894/apex/f?p=211:11:14916146169058::::P11_EMPNO:7698.
If you restricted the report to employees in your current department, you can easily change the EMPNO id and change it to another employee in another department. Even though the application intended to “restrict” users to only edit people within their own department, a malicious or curious user could start editing all the employees.
SSP prevents URL tampering by applying a checksum to the end of the URL. The new URL looks something like:
http://fcapex42.clarifit.com:8894/apex/f?p=211:11:14916146169058::::P11_EMPNO:7698&cs=3358AAB32787C2A2B294CE934D50FD0C3. I\
f a user now tries to modify the EMPNO id, they will get an error in APEX as the URL won’t have the correct checksum.
Applying SSP
To add SSP at the page level (technically called Page Access Protection at the page level), edit the page and scroll down to the Security section. Select Arguments Must Have Checksum for the Page Access Protection option.
Once that is added, you can modify the page items you want SSP to be applied to. Edit a page item and scroll down to the Security section. Select an option for Session State Protection (note: click on the help link to find the differences between the various options; I usually use Checksum Required – Session Level).
To modify a page and all its page items at the same time, go to Shared Components > Session State Protection > Page Item and click on a page link.
Two Layered Approach: Page vs. Page Items
The easiest way to think of SSP in APEX is that it’s a two-layered approach. First, you must define which pages (not page items) require a checksum applied to it when passing in URL parameters. The second part is to identify which page items require a checksum when set from the URL. You can’t do the latter without the former (i.e., if you represent a set of page items to have SSP, it won’t work), but you can have pages with SSP without any page items with SSP.
The two-layered approach is where most people get confused. If you apply SSP at the page level, shouldn’t all items be protected? At first glance, the answer is “yes.” But the actual answer is no. The following example highlights why both “layers” are required.
Suppose we only apply Page Access Protection for the EMP form page (let’s say P11). If I clicked on a link to edit an employee, it would add the checksum. Initially, it looks as if everything is ok. Now suppose we have another page, P20, that doesn’t have Page Access Protection enabled. We could actually set P11_EMPNO from P20. The URL would look like this:
http://fcapex42.clarifit.com:8894/apex/f?p=211:20:14916146169058::::P11_EMPNO:7839
Most people forget that you can set page items from any page, i.e., you’re not restricted to only setting items for the current page that you’re accessing.
You could also set any of the page items via an AJAX call (since none of them have SSP applied to them). Either way, just applying page access protection isn’t enough.
When Not to Apply SSP
If you haven’t implemented SSP in your application, you should really look at doing so. Before you apply it to all items, it’s important to note that any items that can be set via an AJAX call can not have SSP enabled for them. The most usual cause of this is cascading LOVs (select a department, then a list of employees gets refreshed with all the employees that belong to the selected department).
The reason why you can’t have SSP item items that are set via AJAX is that AJAX uses JavaScript to build the URL. Since JavaScript code is downloaded and runs on the end user’s machine, it is not deemed to be secure, so if you had your checksum code in a JavaScript file, a malicious user to easily reverse engineer it and apply checksums for any item they wanted to.
Summary:
SSP is a great feature to help secure your application quickly. It’s important to remember that SSP only prevents URL tampering. Nothing more, nothing less. It’s a common mistake by developers and managers alike, that just applying SSP means that they’ve locked down and secured an application. It’s just one of many steps to help protect your application.
Ref:
http://docs.oracle.com/cd/E23903_01/doc/doc.41/e21674/sec_dev.htm#CDDFBCBI
Queries?
Do drop a note by writing us at contact@staging.doyensys.com or use the comment section below to ask your questions.
