Buffer Overflow

> Lukas Renggli a écrit :
> >> Is there any need to worry about  buffer overflow security holes in Seaside?
> >
> > The short answer is "no". The worst thing that could possibly happen
> > is that an exception is throw.
> >
> > The long answer is "very unlikely". I have seen situations where
> > objects could access state outside their actual object boundaries,
> > e.g. if you have a corrupted class hierarchy. If you don't let users
> > evaluate Smalltalk code coming from the web this should be no problem.
> >
> >> I ask only because #textAreaInput has no way to constrain the ³size² of the
> >> data (whereas #textInput has #maxLength:).
> >
> > That provides no security at all. Web browser are free to ignore these
> > attributes.
> >
> > Lukas
> >
>
> Yes, with full access to Smalltalk language, you can manipulate
> bytecodes and generate some overflow... But then, why to use bypath and
> crooked ways when you can modify the program simply with source code!
>
> Moreover, due to the dynamic nature of objects, and memory relocation,
> exploiting overflows would be a sport harder to play than with static
> languages i guess.
>
> Still, you might want to allow limited use of Smalltalk syntax.
> For example, you want to allow your users to feed a web form with
> interpreted expressions like [2/3], [3+4] or [Time now + 1 hour]...
>
> It is not that difficult to create a Smalltalk compiler restricted to
> evaluating doIt, and restricted to a subset of "safe" classes and "safe"
> methods.
> What is difficult is to define a consistent set of such classes and
> methods, whithout security holes.
>
> You have to remove as much reflexivity as you can.
> To name few:
> - The pool of global variables must not refer to itself
> - Very generic message like #basicAt:put: or the power of #become: or
> the one that enable class creation or changing methodDictionary are not
> the safe kind.
> - And thisContext special variable should obviously be disabled.