Hi John,
Which of the following more aptly characterizes the problem?:
IMPL. BUG: Insufficient security-constraint existed on the admin
Servlet in
the app's deployment descriptor.
ARCH. FLAW: No façade component gated privileged functionality
-alternatively-
ARCH. FLAW: Privileged functionality incapable of judging Principal's
entitlement (both fine, one user changing another's password, or
coarse,
application functionality improperly accessed)
Clausewitz said to be strong, first in general, and then at the
decisive point. Assuming you consider authentication and
authorization on admin functions a decisive point, then this scenario
is a failure in both instances. The question you raise is locating
the responsibility to deal with this problem. In a distributed
system, there are many potential areas to locate those controls.
Problems do not necessarily have to be solved (and in some cases
cannot be) at the same logical layer they were created (http://
1raindrop.typepad.com/1_raindrop/2005/11/thinking_in_lay.html). Would
an authenticating reverse proxy have prevented this problem? How
about stronger identity protocols?
-gp
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
