[Glass] security / dos attacks

[jtuchel at objektfabrik.de]

Otto,

we've been seeing similar problems on VA Smalltalk. There were requests 
that seemed lik esomebody tries to check the server if it reacts to 
certain Strings. Unfortunately, the server came up with a debugger 
instead of either ignoring it or returning an HTML error message.

I think we all agree that a server shouldn't crash if a request cannot 
be decoded or process.

The whole thing, however is much more complicated than just returning an 
HTTP status code if a request cannot be decoded, and I have learned a 
little about this over the last few weeks. There are good reasons for 
your server to not react at all to the outside, so that possible 
attackers do not learn anything about your server, other than it didn't 
react in the way they'd hoped. So there are several possible things a 
server should do, and you need to have a way to configure that behaviour:

* In development and test, you'd probably want to receive an HTTP error 
code if you send illegal requests to your Web Server (In your case 
Gemstone/S)
* In pre-production and production, you'd better not get anything back 
from the server if you send requests that cannot be processed
* You may need, however, to keep a log of such access attempts to 
understand a intrusion after the fact (I really hope I'll never be in 
that situation), so you may want to log those requests with as much 
information about where it came from and what happened before and after.

You may have a vague idea by now that this is a very wide field and 
maybe this is not something that can or should be solved in Smalltalk. I 
guess there are people who have solved the issue better than any 
Smalltalk verndor ever could. I only have to find out what people 
usually do about this.

So: first step sure is catching errors and responding with an 
appropriate HTTP status code, just to keep your server from crashing. 
But as you can see, that is neither a perfect nor complete solution.

HTH,

Joachim


Am 23.12.13 14:36, schrieb Otto Behrens:
> Hi,
>
> We've been getting some hacking / dos attempts on our sites.
>
> In some cases, we do get a successful crash of the FCGI server. I'm
> still trying to find those.
>
> In my hunt for this, I found that some requests create an Internal
> Server Error response. For example, a GET on /%C0%AE generates the
> following message: 'InterpreterError 2258: Primitive failed , selector
> <#'_unicodePrim:'> receiver <'À®'>'
>
> I'm worried that this somehow opens a gap to hack into the system, so
> I think it is better to respond with a 404 or something like that.
> Does this make sense? I was thinking that I should be chasing down 500
> responses so that we can catch where they manage to break the server.
>
> Have you encountered this? Any ideas on solving it?
>
> Here's what I found so far:
> 1. The method WAFastCGIAdaptor | requestUrlFor: creates a WAUrl and
> then calls #decodeWith: on it, which breaks.
> 2. In the code that creates the WAUrl, it calls #decode: on the path
> segments, which decodes %C0 as a UTF8 character. (WAUrl | decode:).
> 3. doing this breaks:
>
> (String with: (Character codePoint: 192) with: (Character codePoint:
> 174)) decodeFromUTF8
>
> Thanks
> Otto
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1