[Glass] security / dos attacks

> 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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

> 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

> 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
>> [hidden email]
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
>