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

Tim Rowledge seaside@lists.squeakfoundation.org
Mon, 29 Jul 2002 18:21:10 -0700


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

> On Mon, 29 Jul 2002, Tim Rowledge wrote:
> 
> > Ideas on preventing such problems welcomed. I imagine it must be
> > possible to make a socket refuse to accept vast amounts of data, though
> > how do you decide what is vast? What can be done to 'protect' session
> > numbers?
> 
> - Use HTTP basic authentication (look for an earlier thread of yours about
> auth ;-) so that the attacker has to be on the same machine and browser
> session as the real user (problem: no way to log out except for quitting
> the browser).
OK, so far as I can tell I'm doing that - I copied code from your auth
page example. The html method for my OTAuthPAge class looks like:-
 !OTAuthPage methodsFor: 'actions' stamp: 'tpr 5/29/2002 15:38'!
html ^
'
	<h2>Log in to Accounting Ace 911</h2>
	<if condition="@message.notNil">[message]</if>
	<p>
	<form action="@authenticate">
	<table cellpadding="2">
	<tr><td>Your name:</td><td><input name="@user" type="text"></td></tr>
	<tr><td>Your Password:</td><td><input name="@password" type="password"></td></tr>
	<tr><td></td><td><input type="submit" value="Log In"></td></tr>
	</table>
	</form>
'! !

> 
> - Encode the IP address of the client into the session key (not so useful
> when a LAN is all sharing one IP).  Again, the attacker would have to be
> on the same machine.  Combine with quickly expiring sessions.
I guess the expiring session idea would help a bunch by removing all
those old session IDs quickly.
> 
> What exactly was the attack your friend demonstrated?
One involved nothing more than editing the session id part of the url.
Depending on what number you end up with you may get varying results. To
help tackle that I set the system to return errors to the browser and
changed the code that html-ises the stack to simply tell the user there
is an error, please try again. I think that at least takes away the
problem of notifiers in the image sort-of locking it up for a while.

He's just phoned to tell me of some other evils he's thought of relating
to my use of expressions in the questions :-) Like "do remember to stop
people writing exception handlers and raising exceptions as a way to get
at the stack". Such a twisty mind - but then he spent several years
working for TeRiSA designing secure sockets etc. The good news there is
that question submitting is pretty much be definition a slow process and
so spending time carefully parsing the proferred code is ok.

tim

-- 
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother," said Pooh, as his trigger finger tired.