Databases Reference
In-Depth Information
Figure 9-38.
Update the source for fetching the next record.
Now all of your data is secured based on who is signed on to the system. Or is it?
Session-State Protection
One of the most common ways to compromise a web application is through a form of attack known as
URL
tampering
. You don't need to be a programmer or hacker to launch this type of attack—all you need to do is alter
the URL in your browser. APEX introduced the session-state protection feature in release 2.2. When enabled, it adds
a checksum value to the URL. If any portion of the URL is altered, the resulting checksum doesn't match what is
expected, and the page simply won't render. Implementing session-state protection is simple and recommended for
any report based on sensitive data.
In the previous exercise, you secured the data from the report pages and a navigation component. However, you
did nothing to protect pages 210 and 220, where the actual changes are made. Thus, if a user were to tamper with
the APEX URL, it would be trivial for them to view and edit other users' tickets. This is easily visible from the report
on page 200. The end of the URL on the report clearly shows
P210_TICKET_ID:10
, where 10 in this case is the ticket
number. Changing that number in the URL directly will cause APEX to fetch the new record ID, regardless of whether
it's assigned to the current user.
You can prevent this from happening in a few easy steps using APEX's session-state protection functionality:
1.
Go t
o the
Shared Components
of the application.
2.
In the
Security
region, click
Session State Protection
.
3.
Click
Page
.
4.
Click the link for
Page 210 - Manage Tickets
.
5.
Set
Page Access Protection
to
Arguments Must Have Checksum
, set
Display Item
Type
to
Data Entry Items
, set
Item Session State Protection
for
P210_TICKET_ID
to
Checksum Required - Session Level
, and click
Apply Changes
. Figure
9-39
shows the
session-state protection settings for page 210.
