Re: JSP Security - Limiting URL's

[Andrew Jaquith <ajaquith () atstake com>]

The author is correct is suggesting that order & flow should be managed 
external to the presentation pages. But I agree with Jeff that the code 
is a bit difficult to follow.

For those of you keeping score at home, the approach outlined by the 
author ought to look suspiciously like Model-View-Controller aka Model 
2. But this begs a little question: why roll your own when there are 
some good ones out there already? Jakarta Struts is the dominant one; 
Jakarta Turbine is another. Webwork has a number of fans because it is 
fairly simple.

I can sense the author's guilty feelings oozing out of the last 
paragraph: "The JSP application framework that I presented in this 
column is designed to be simple [not], secure [unproven], and verifiable 
[huh?]... However, there are other more general, powerful, and 
comprehensive application frameworks that you can use. The Struts 
framework of the Apache-Jakarta project 
<http://jakarta.apache.org/struts/index.html> is an example of the 
latter. Struts goes beyond a simple state machine to provide extensive 
support for the Model-View-Controller paradigm."

So on balance I am not sure that the article adds too much value. The 
community (and particularly newbie MVC developers) would be better 
served if the examples were tailored to one of the existing MVC 
frameworks. That said, it's great to see more security-conscious 
articles coming out of the mainstream Java outlets.

Andrew

Jeff Williams @ Aspect wrote:

> If you have a site (or part of a site) where users are supposed to
> access pages in a particular order, this is THE way to solve the
> problem. I call this "flow control" as opposed to access control.
> Essentially, you set up a state machine on the server side that controls
> the transition to the next page. One nice side-effect is that there only
> a single URL for the entire site.
>
> The biggest downside to this model is that you can't just link into any
> page within the site. The only way to certain pages is to go through all
> the steps.  This will also make it difficult for spiders to index your
> site, as some of them give up when many pages share the same URL. In
> addition, you are quite likely to have problems with the 'web
> application firewall' products, as many use the URL as a key for what
> policy to enforce.
>
> So, the article is right on.  I do have a few minor comments below on
> the implementation.
>
> I found the author's implementation a little difficult to follow. Trying
> to centralize the state machine can make things within a web app real
> complicated. I think a more OO way is to implement put each page in
> charge of deciding which pages can send requests to it.  Of course this
> depends on the size and complexity of the state machine and how often
> you think it'll change.
>
> If you look closely at the article, you'll see that the author had to
> work hard to deal with the "multiple window" problem.  State machines
> don't like getting requests out of order, so if you have two windows
> open at the same time, everything gets botched up. The author invented a
> "smID" parameter that has to go on every page to deal with this -- then
> calls it a "feature."
>
> --Jeff
>
> Jeff Williams
> jeff.williams () aspectsecurity com
> Aspect Security, Inc.
> www.aspectsecurity.com
>
>
> ----- Original Message -----
> From: securityarchitect () hush com
> To: webappsec () securityfocus com
> Sent: Monday, December 09, 2002 5:42 PM
> Subject: JSP Security - Limiting URL's
>
>
>
> http://www.onjava.com/pub/a/onjava/2001/06/27/java_security.html
>
> Can anyone see a downside to this ?
>
>
>
> Concerned about your privacy? Follow this link to get
> FREE encrypted email: https://www.hushmail.com/?l=2
>
> Big $$$ to be made with the HushMail Affiliate Program:
> https://www.hushmail.com/about.php?subloc=affiliate&l=427
>
>  


--
Andrew Jaquith
Program Director
@stake, Inc.
196 Broadway
Cambridge, MA 02139 USA

Direct:  617.768.2711
Mobile:  617.501.3278
Fax:     617.621.1478
Email:   ajaquith () atstake com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546