You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by David Geary <sa...@tri-lakesonline.net> on 2000/12/23 00:19:48 UTC

Proposal: Tokens and Events Guard Against Form Resubmission

ABSTRACT

It's easy for Web application users to inadvertently resubmit forms with
bookmarks or the reload and back buttons. Because of this potential for
mischief, web applications must guard against resubmission of sensitive
forms. This document proposes using the delegation event model and
tokens to restrict access to sensitive pages.

Note: This proposal depends on action events as proposed in 'Proposal:
Retrofit Struts with the Delegation Event Model'.


CREDITS

   'Command Token Implementation', posted to struts-dev by Robert Leland

   Struts Web Application Safety' on struts-dev, by Craig McClanahan
   'What about This Model?', posted to struts-user by Dan Cancro
   Web Development with JavaServer Pages, by Kolb and Fields, p 270


INTRODUCTION

Web browsers were designed for browsing the Web, not for applications.
Some browser features, such as the back button, reload button, and
bookmarks, are difficult for web applications to deal with because they
disrupt the normal flow of an application. This proposal shows how to
trap those browser features in Struts using the delegation event model
and tokens.


THE PROBLEM

Consider the following sequence of actions, as Timothy creates a new
account. First, Timothy tries to login, but since he does not have an
account, he's forwarded to the Login Failed page:

[Image]
Figure 1. The Login Failed Page

Timothy clicks on the open new account link and is forwarded to this
page:

[Image]
Figure 2. The Open New Account Page

Timothy fills in the form shown in  Figure 2, clicks the create account
button, and is forwarded to the login page:

[Image]
Figure 3. The Login Page

At this point, Timothy's account has been created and he can login, but
what if he reloads the page instead? Or what if he hits the back button,
and then clicks on the create account button without changing the form's
data? In both cases, a duplicate request will be sent to the
new-account-action. That action might detect the duplicate, but it's a
lot to ask all actions to test for duplicate submissions. Let's see how
Struts can trap such illicit access at a higher level.


TRAPPING ILLICIT ACCESS WITH STRUTS


WHAT IT DOES

Guard against sensitive form resubmission. If a sensitive form is
resubmitted, Struts throws an exception.


HOW IT'S IMPLEMENTED

Trapping illicit access is implemented in this proposal with tokens, as
described by Fields and Kolb (see credits). Here's how it works: