My ASP.NET web application has a flaw that produces false security-violation
alarms.
There are several categories of users for this web site, e.g. Colonels,
Sergeants, Private_1s,
and Private_2s. Colonels may visit any page in the web site. Sergeants may
visit only non-com
pages. The non-com pages consist of non-com-0, non-com-1, and non-com-2
pages. Private_1s may visit non-com-0 and non-com-1 pages. Private_2s may
visit non-com-0 and non-com-2 pages. In addition there is a login page that
may be visited by any user.
The natural flow is as follows. The user goes from the login page to an
Officer page or to the "home" non-com-0 page. Similarly from the "home"
non-com-0 page the user can click a link to go to a different non-com-0
page, a non-com-1 page, or a non-com-2 page (depending upon his rank). From
any of the web pages the user can click a link to return to the log-in page.
From any of the non-com-1 or non-com-2 pages, the user can click a different
link to return to the "home" non-com-0 page.
The method that I am using to do forms security validation comprises the
following.
(1) Use a session variable called WebRegionS that can assume any of the
enumeration literals { officer, non_com_0, non_com_1, non_com_2 }. The
application assigns a value to WebRegionS before redirecting to a web page
in which the category changes (e.g. from non_com_0 to non_com_1).
(2) Create a new class called basePage, which is derived from
System.Web.UI.P age, and derive all web application pages from basePage.
(3) basePage has a protected variable called WebRegionP, that assumes the
same enumeration literals as WebRegionS. In the web application page's
constructor an appropriate value is assigned to WebRegionP.
(4) basePage overrides OnInit(), in which it compares WebRegionS to
WebRegionP; if they are different, it redirects to a page that displays a
diagnostic.
The flaw in the above strategy is that the user can (and probably will) use
the browser's BACK button, instead of a link. If he does this to go back
from a non-com-1 page to a non-com-0 page, the BACK button does not induce a
server-side event, and there is no opportunity to set the session variable
WebRegionS back to non_com_0. Subsequently when the user clicks something
that causes a PostBack, basePage's OnInit() is invoked, a mismatch is
detected, and the user is redirected to the page that displays the
diagnostic.
An ideal solution would be to induce a server-side event when the user
clicks the browser's BACK button. Is this doable and easy?
I looked at ASP.NET's Forms Authentication facility (class
FormsAuthentica tion, <authorizatio n> tags in Web.config,
Application_Aut henticateReques t() in Global.asax, GenericPrincipa l, etc.).
This does not seem to be appropriate for this web application, primarily
because it would let the user jump to a page, without passing through
intermediate pages. For example, the "home" non-com-0 page sets session
variables whose values are used by code in the non-com-1 pages.
What strategy do other web-application programmer's use? Am I missing
something that is easy?
I apologize for the length of the above; I tried to keep it short and
simple. If you have read this, thank you for your patience.
