An issue for consideration

[Magnus Holm]

Good find!

1. If you run that on a real HTTP server (Apache, Nginx etc.) it will
just ignore it.
  Remember that  Mongrel/Thin should be served behind a proxy and are "lazy"
  about checking valid request.

2. A cool thing with the Rack-rewrite is that you can use Rack::Lint to validate
  the request/response according to the Rack-spec. So that will just raise:

Rack::Lint::LintError: REQUEST_METHOD unknown: FOO

3. I'm adding Rack::Lint as a middleware in bin/camping such that it's "safe" in
  development. If you're running Mongrel/Thin without proxy (madness!), you
  should also use Rack::Lint.

Do you think we should add a protection inside Camping too?

On Fri, May 23, 2008 at 6:46 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> We've just come across an issue for consideration. I am avoiding some words
> which would allow people to find this message in an internet search who have
> questionable intentions, but wish to communicate a strong sense of caution.
> Consider someone who adds extra methods to their controller which they use
> in their main get/post methods to do things or to get secret data. Consider
> now, this http request:
>
> FOO / HTTP/1.1
>
> And consider that camping allows methods to return a string and have that
> returned as a body. This could make for a lovely convenient form of RPC, but
> to those unaware, it seems there could be negative results. Aria has
> discovered with some testing that it is also possible to access helper
> methods remotely in this way, which is especially worth consideration as
> some of us use helper methods to do important things, and do not expect them
> to be directly accessible to the outside world.
> In my own app, I will be using a service to filter all requests which don't
> use a standard http method. I'd like to suggest that in the next release of
> camping, we could do something like return unless ['GET', 'POST', 'DELETE',
> 'HEAD'].include?(request_method), perhaps in the run method of camping. Or
> maybe we could raise an error. I'd also appreciate it if this update were
> deployed to rubygems servers without haste. I'll be sure to post the service
> I write to work around this issue just as soon as I'm done writing it.
>
> —
> Thoughtful Pony
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm