Database Reference
In-Depth Information
23. Change the value of
Table Name
to
TICKETS_SECURE_V
, as
shown in
Figure 9-38
. Click
Apply Changes
.
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 check-
sum 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 naviga-
tion component. However, you did nothing to protect pages 210 and 220, where the ac-
tual 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 re-
port 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.
