RE: Web development on the iSeries using CGI and the CGIDEV2 library

> From: Mike Skvarenina
>
> This brings me to a small mention of security.  Another objective
> I had was to not allow the users to bookmark one of our apps then
> return to it at a later date bypassing the login procedure.  I
> also didn't want them being able to simply alter a variable in
> the URL to gain access to information I didn't specifically want
> them to see.  To accomplish this objective I used the POST rather
> than the GET method of passing data from the browser to the
> server.  Using this method, all the user sees and can bookmark is
> the URL to a given program.  Now if a user does bookmark a 'menu
> option' rather than going through the web menu, all they get is a
> login prompt since the User ID wasn't passed to the called
> program.  (This is part of the modular approach I will further
> describe shortly)

Be careful here.  This is not a very secure approach.  While a user with a
browser may not be able to see or change hidden POST data, it's quite easy
for them to do a "view source" and copy the HTML into their own static page.
>From that point, they can quite easily see and alter the contents of
"hidden" variables, then call the modified page up in their browser.  This
is equivalent to changing the URL on a GET request.  A little more work, but
not much.  And even if you do manage to hide the source (there are ways,
especially in DHTML), it's not that difficult to write an HTTP client that
can spoof POST data.  I'm pretty sure Brad Stone's GETURL goes a long way
towards that.


> One final note before I begin...there's this case of persistence.
>  I do not use persistence...it's difficult to implement and would
> slow down the development process as well as utilize additional
> resources on the iSeries.  All my apps run as though each
> incoming request is coming from a new visitor.

This point is more of a matter of opinion, I guess.  In my opinion,
persistent sessions are quite easy to maintain - in fact, it's as simple as
the following call in your doGet or doPost routine:

        HttpSession session = request.getSession(true);

This will return the current session object or create a new one if none
exists.  If the page is secured via ACL, the session object will include the
user ID used to log in.  As long as you serve all the pages of your
application from the same web server, this session will remain persistent
throughout the user session.  It's a little bit harder to maintain
authenticated sessions when accessing multiple IP addresses (as we do in our
more complex applications), because the normal response of the web server is
to invalidate an authenticated session when an different IP address is
processed.  Even so, it's not impossible, it just requires a little more
work.

If you're authenticating your requests individually using data from a POST
operation, you are possibly opening up a substantial security hole.  I have
to admit that web application security requires a relatively devious mind
set - you have to expect that someone can make up any possible packet and
send it to you.  Security needs to be implemented at the HTTP server level,
and sensitive data cannot be passed back and forth through the HTTP
requests, even in "hidden" fields.

I just thought I ought to point out these things before you or someone else
goes too far down a road without understanding the risks involved.

Joe Pluta
www.plutabrothers.com