[Seaside] bad request

Otto Behrens otto at finworks.biz
Mon Dec 23 15:25:25 UTC 2013


Vulnerability tests that ran against our site showed that URL's with
percentage encoded UTF8 characters creates a 500 (internal server
error) response, where I think they should actually respond with 404
or 405.

Some examples:

GET /% breaks when WAUrl class #decodePercent: tries to read off the
end of the stream.
GET /%C0 breaks for the same reason, but in GRPharoUtf8CodecStream |
next: (more cases in there!)
GET /%C0%10 raises GRInvalidUtf8Error.
GET /%C0%AE returns 404 (not found).

I'd like to improve on this, if you agree.

I need some guidance on how to improve regarding the construction of
the request. This is the code in WAServerAdaptor | contextFor:

It creates a request (self requestFor: aNativeRequest) without
handling exceptions. This means that the outer exception handler
catches it and returns a 500.

I am not sure where to handle errors such as these and to elegantly
ensure that the response is "bad request" if the request could not be
parsed. I also see that there's a nice badRequest method on
WAResponse, without any senders in my image. Perhaps this is some
perform: magic that I can't trace.

Any help will be appreciated.


More information about the seaside mailing list