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
|