the-web-application-hackers-handbook

252 Chapter 7 n Attacking Session Management
is to keep the sequence of pages where sensitive data is submitted as short
as possible. Then you can create a new session at the first page of this
sequence (where necessary, copying from the existing session any required
data, such as the contents of a shopping cart). Or you could use per-page
tokens (described in the following section) to prevent an attacker who
knows the token used in the first page from accessing subsequent pages.
Except where strictly necessary, personal data should not be displayed
back to the user. Even where this is required (such as a “confirm order”
page showing addresses), sensitive items such as credit card numbers and
passwords should never be displayed back to the user and should always
be masked within the source of the application’s response.
Per-Page Tokens
Finer-grained control over sessions can be achieved, and many kinds of session
attacks can be made more difficult or impossible, by using per-page tokens in
addition to session tokens. Here, a new page token is created every time a user
requests an application page (as opposed to an image, for example) and is passed
to the client in a cookie or a hidden field of an HTML form. Each time the user
makes a request, the page token is validated against the last value issued, in
addition to the normal validation of the main session token. In the case of a
non-match, the entire session is terminated. Many of the most security-critical
web applications on the Internet, such as online banks, employ per-page tokens
to provide increased protection for their session management mechanism, as
shown in Figure 7-12.
Figure 7-12: Per-page tokens used in a banking application
The use of per-page tokens does impose some restrictions on navigation (for
example, on use of the back and forward buttons and multiwindow browsing).