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

Tim Rowledge seaside@lists.squeakfoundation.org
Mon, 29 Jul 2002 17:08:34 -0700


A friend of mine took a look at my stuff and was able to immediately
screw it by simply editing the session id number in the url :-( Sigh.

He later offered the following cogent points on the matter
>Keep the following in mind:
>
>	1.	All input is evil, until proven
>		otherwise (recall my edits to the
>		session ID).
>
>	2.	Input can be used to alter
>		application flow.
>
>	3.	Overflowed buffers are evil (maybe not in
>		Smalltalk servers, but certainly
>		long input may cause exceptions
>		to be thrown or other unwanted behavior).
>
>	4.	Input can be used to attack other
>		users (Script injection).
>
>		--	Never execute statements
>			in the Smalltalk server
>			that were sent from a browser.
>
>
>	5.	Tell the attacker nothing. If input
>		fails, don't tell them why or how.
>
Which may resonate with some of you. I really need to break 4 in
order to allow entering of new test material, though it looks like
restricting thescope of the compiler to nothing but the variable defined
in the question along with removing any mentions of
self/super/thisContext/class/etc should protect me.

Another friend pointed out (by example) how easy it is to flood the
server to death by sending infinite amounts of data in a post reply. She
managed to get it to swallow a good couple of megabytes before stopping
though.

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?

tim

-- 
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Meets quality standards: It compiles without errors.