On Thu, 25 May 2000, Baveco, Hans wrote:
> This is mostly a question directed to Jochen, but others may provide
> valuable information as well..
I'll try :)
[snip]
> I hope to get permission from the ICT department of our institute to
> experiment with swiki's that are accessible from outside our firewall.
Great!
> However, they require an evaluation of the potential risks of
> running a comswiki server across the firewall, and therefore probably they
> need to take a look at the implementation etc themselves - as I can't
> provide all the information that may need.
Off the top of my head, I can think of several areas that would need
examination:
1) Uploads. Obviously, if you allow uploads, you open the
possibility of a variety of attacks. Note that it's probably *not*
sufficient to restrict execution permissions on the upload directory
(in a unix like system), but to ensure that the *swiki* never files
in or "evaluates embedded" any uploaded file.
Of course, with the current security model, it would be possible
to restrict uploads to a set of "trusted users".
2) <script> tags and embedded code. As shipped, the swikis permit
the entry of arbitrary HTML, both mixed in with "SwikiSyntax" and
inside <html></html>. This permits the sort of third party
malicious client side script attacks.
I would want to ensure, as well, that no edit gets run through the
embedded code evaluator. As things stands, I'm pretty sure it
never does, but if one has user edited templates, this must be
watched for handled carefully.
Fortuneately, it's fairly easy to shut this one down, both by
killing the <html> tag, and by converting all $<s to the
corresponding entities. More sophisticatedly, one could filter for
the compromising tags (<script> etc.). The TextProcessors make all
this rather straightforward.
3) If the swiki is open, then there is the standard worry about
swiki trashing. There indeed, *has* been such an incident (on
swiki.net) the first serious one I've heard of. Lockability seems
to take care of that.
4) In a Squeak server app, "functions" tend to be triggered by
urls and parameters tend to be encoded in them as well. Thus, some
analysis of what a Swiki does with various kinds of "trash" urls
is warrented (examining the "addresses" folder is a good thing
here).
5) Other than that, I don't think there are any *special* risks
involved. I certainly wouldn't run the server root :) As the
modular VM and segmented image become available, shutting down
certain kinds of risky behavior will become easier. (And moreso,
if Lex's capabilities stuff gets in.)
If one were concerned with minimizing the damage a hijacked server
could do, I suspect that placing guards in a relatively few places
would do the trick. Thus, one could check before executing certain
file or socket primitives that the writes were legit. Indeed, one
could compile those checks into the prims themselves, which would
be the safest of all.
> Beta 10 is promised to be a lot
> different, and I wonder whether that would affect such a risk-assessment
> (and I thus should wait until I have beta 10 up and running)?
Some of these things are independant of the Swiki, so I'd look at them. I
think if you can assess the current beta, you'll be in a better position
to assess the next version, so I don't think it will *really* hurt.
But waiting on certain issues is certainly worth doing.
> And the other question is: surely all you people involved in the
> development of swiki's can provide a kind of risk-assessment? Are there any
> risks in addition to the risks associated with any standard http server?
See above. Please note that I am *not* a security expert. Indeed, I'm
rather cavilier about security :)
Oh, denial of service. As they stand (and until someone shows me otherwise
:)) Squeak's networking prims are rather vulnerable to being swamped in
various ways. This is somewhat platform and vm dependent, however.
Note that I've spent some time thinking about how to set up Comanche (and
thus Comswiki) as a cgi type system. Theoretically, it shouldn't be that
hard, espeically on a Mac (using the Applescript plugin) or Unix (using
the OSProcesses goodie). This would reduce the problem to that of securing
a cgi.
Cheers,
Bijan Parsia.
