[Glass] security / dos attacks

[jtuchel at objektfabrik.de]

Hi list, Hi Otto, Hi Dale,

I did a bit of research and found that there are tools for filtering the 
output of a web application like Apache's mod_security.
So we shouldn't bother about the "keep it a secret" stuff on the 
Smalltalk side. This can be handled by your frontend http server.
This means it is important for Seaside or better the http adaptors 
beneath it (Zinc, KOM, Server Smalltalk in VAST, whatever) to do proper 
error handling and respond with codes in the 4xx-5xx range. Everything 
else is somebody else's problem.

Joachim



Am 23.12.13 16:04, schrieb 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