We are creating an Oracle Apex application for one of our clients.
ApEx 4.2.0.00.27, database 11gR2
Certain (hidden) items are protected with the Session State protection option 'Checksum required - Session Level'. This prevents the tampering with the values in it self.
However security officers are concerned that it might be possible for someone to change the item value and recalculate a checksum to match with that value. And if this item value is the key to another row this could mean changing the data of another user.
In an answer on the checksum mechanism in a tabular form (https://forums.oracle.com/message/5397831#5397831) the steps are described as follows:
If I apply this to the SSP-checksum I can think of the following steps:
Now the security officers scenario:
If (and I think it's highly unlikely) someone would be able to calculate correct checksums, would this scenario work? Or do we miss something in our thinking?
if an attacker has a way to calculate correct checksums, this scenario would work. That being said, I think it is very theoretical. Checksum protection is a fundamental security concept and used in all kinds of web frameworks, not only APEX. I am confident that our implementation is at least as good as that of the others.
However, security can (and very often should) be applied on all layers, not only the front end. For example, one layer below the URL / item checksum protection are the form and tabular form processes of APEX. You can add runtime where clauses that APEX automatically adds when it fetches rows or performs insert/update/delete. They can be used to ensure that DML only applies to records that the user is allowed to see and edit. Further below, you have Fine Grained Access control (also known as VPD), that does something similar directly in the database. It is an enterprise feature, but you can also emulate it to some level with views and triggers if you are on standard edition. The final layer is a sound relational data model, where the correct data types and constraints guard the data integrity. Depending on the complexity of an application, it sometimes makes sense to add a logical view/trigger layer on top of the physical model, where additional security checks are implemented.
We haven't found a way yet of calculating the checksum in this manner, it would be equivalent to pre-computing session identifiers in any other web frameworks.
If there was a vulnerability found in the checksum calculation, it would be reported to Oracle and the framework would be fixed (very quickly i should imagine), and all APEX users would benefit from the fix, this is a very good reason to use the APEX framework for such things.
There is one very limited scenario where an attacker can compute a URL checksum and that is when the developer miss-uses the prepare_url function, and includes an unprotected item too soon in the function (page number for example) and thus can receive the checksum for the values of his or her choice. We have only seen this exploitable once in the many applications we have seen and this should be picked up in a secure code review.