Squeak+Web security [Was: Re: Two small articles]

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Nov 3 09:31:14 UTC 2003


cg at tric.nl wrote:
>  <squeak-dev at lists.squeakfoundation.org> said:
> >1. Comanche is a very "unknown" server. The risk of having people target
> >it generally is very, very small.
>
> That's security-by-obscurity. If you have security in place, it is a
> nice extra, but it should NEVER be the basis for security. 

Not really "by obscurity" - I mean, the source is there. But fact
remains, using "odd" software is good for security. Sure, it shouldn't
be the *basis* for security - I didn't imply that.
 
> Buffer overflows are impossible, I grant you that. In environments like
> Seaside, which have capability-like rather than ACL-like security (every
> link is one handed out by the system specifically generated for you and
> there's no way at all that you can guess a link you don't have), you

True. And (cough) I intend to make it more like that for HV too.

> also have a whole class of security problems less to worry about, but
> the Big Three security holes are still there, gaping, waiting to be
> exploited, and - the worst - never discussed here:
> 
> 1. Cleartext passwords. I think all Squeak frameworks should refuse to
> generate forms that have a password field and a non-HTTPS submit link,
> but at the very least security sensitive code should be TRIVIALLY able
> to:
> - detect whether HTTP or HTTPS is in use;
> - steer HTML generation code to render HTTPS links.
> Documentation should have an example of Squeak-behind-Apache-SSL. 

I agree. I use https for login forms, though currently I haven't "forced
it". But perhaps I should.
And I could also stuff a Squeak-being-Apache-howto in my upcoming
article.

> 2. SQL injection. As far as I know, Squeak (including the various web
> frameworks) doesn't have any robust mechanisms to detect strings that
> were entered by the user and therefore are suspect. I think something
> like a 'TaintedString' class that includes conversion methods that clean up
> strings is necessary - TaintedStrings would then be rejected by SQL
> handling code, HTML generation code, etcetera. Probably all you'd have
> on TaintedString is #asString (stripping), #asInteger/#asFloat/... (in
> effect, also stripping).

I have done a few such rudimentary cleaner methods. But more work is
needed there, true.
In HomepageBuilder I have no SQL to worry about though :).
 
> 3. Cross-site scripting and friends - assorted attacks also based on 
> simply storing whatever the user enters and, worse, using that
> information (to display pages, possibly to others, etcetera).
> 
> As far as I can tell, Squeak is just as insecure as PHP in these areas

Probably yes.

> and the level of security consiousness is even lower here...

Well, I am not so sure about that. Security consiousness is probably
strongly coupled to how much stuff you have deployed and exposed - and
the importance of it. :-)

regard, Göran



More information about the Squeak-dev mailing list