[Seaside] Advice on writing secure webapps from a scarred friend

[Tim Rowledge]

Avi Bryant <avi@beta4.com> is claimed by the authorities to have written:


> Not sure there is a "right" thing - just a matter of trade offs.
Well, ok, I have to take advice on this stuff since I just don't know
about it. I guess one advantage of using the basic auth stuff is that
it plays nice with the browser remembering user/pwd stuff. 
> 
> > I've replaced things with a version from IAAuthenticatedSession alright
> > but I've lost two facilities in doing so. How can I make the popup login
> > window have a more meaningful message? What is the best way to put
> > timeouts on the session (I had been using the technique in
> > IAAuthPageSession, but perhaps I should use an IAExpiringCache? Would
> > this allow a re-login and continue as I had before?)
> 
> No, you'd lose the current position in the session.  As I said, there are
> trade offs.
So if I do a manual timeout as before for short-term timeouts (20 mins
or so) that allow returning to the scene of the crime plus an expiring
cache that cleans things up after say a few hours, that ought to be a
decent compromise between wanting to make it convenient in case a
browser dies/modem quits/etc and wanting to clear sessions out sometime
before protons start decaying.
> 
> > I tried the hacked-up session id attack after the change and it does the
> > same thing, reporting no such page state. Shouldn't the request session
> > id be checked against the actual session id somewhere? Surely if someone
> > has logged in and got a session id of '12345678' and edits it to
> > '1345678' something should be deciding there is a problem?
> 
> So the concern isn't that someone will hijack somebody else's session, but
> that they'll produce an error message?  This doesn't sound so bad.
The error isn't a problem so much (though it would be nice to make the
error message point out that your session id was wrong, perhaps you
accidentally edited the url) but being able to hijack sessions is most
definitely. It's something I could see being a popular sport in a
college setting. Especially if it lets the little buggers get in as
teacher...
> 
> But it does sound like there's a bug, namely, that you're seeing an error
> when you put in an invalid session rather than just being redirected to a
> new one.  This would be a problem in IAApplication>>sessionForRequest: -
> I'll take a look at it later, I guess.
If the session id is not 'valid' you're making a new one; perfectly
reasonable in most situations. Maybe checking the request user/pwd stuff
against other sessions would be a good check? Perhaps only if there is
a non-nil request sesion id? A combination of a plausible user and a
non-nil session id that is invalid seems suspicious to me.

Sigh. What does one do to be really secure except not allow access :-) ?

tim
-- 
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts.