Tomek wrote:Why cannot you apply checksum on application items? have you not enabled session state protection in your application?
I follow official Oracle White Paper about how to do it and everything works nicely, however...
Custom EBS function definition follows this syntax to pass the context information to APEX (as per white paper):
The actual URL that gets generated looks like this (I use different names, but it is very similar):
As you see the RESP_ID, APPL_ID, and SECURITY_GROUP values are passed in the URL. All is great except those numbers can be easily manipulated since I cannot apply checksum protection to the defined Application Items. The URL string is constructed by the Oracle seeded jsp page and I do not have any control over it.
But it looks like the Oracle solution implements possible security problem.For a fully secure Oracle solution you would need to re-validate the responsibility, resp_app_id and security group within the Apex application using an Apex Authorisation scheme. This would have to be attached to each page (or process) where the responsibility is used. The advantage of this approach is that it is then easy to switch responsibilities in Apex independently of the EBS responsibility.
Tomek wrote:So even though user tampers the URL he won't be able to see any unauthorized data. they will see an unauthorized error message. I guess this is similar to checksum because even checksum doesn't stop them changing the url values and press enter, which gives checksum error. As Rod mentioned you will need to create authorization in APEX to validate the responsibility, resp_app_id and security group against the user.
I do have the authorization scheme that evaluates and sets the context for Apex so it works correctly against context specific data. The authorization scheme executes for every page. But in my first page opened from EBS the URL exposes the values which can be manipulated (see below):