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.1And 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/15535691/attachment.html>
This should help. include Camping::ControllerSecurity in your controllers module or your Camping (or whatever Camping.goes has turned it in to) module, after requiring this:> module Camping > module ControllerSecurity > def service(*a) > @method = ''get'' unless [''get'', ''post'', ''delete'', > ''head''].include?(@method.to_s.downcase) > super(*a) > end > end > endAnd the world should feel safe again, I think. I haven''t really tested it properly, but what could go wrong? It certainly isn''t making my app break. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/81f1cb5e/attachment-0001.html>
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
Yeah I think it''d be good, or if not just make it not work on helper methods, just class methods in the controller, then it wouldn''t be so nasty and unexpected. It''s good to hear i''m safe behind apache. On 23/05/2008, at 8:16 PM, Magnus Holm wrote:> 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 > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
On May 22, 2008, at 10:46 PM, Bluebie, Jenna 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. > >return unless [''GET'', ''POST'', ''DELETE'', ''HEAD''].include? (ControllerClass.instance_methods(false)) -- only use methods defined directly in the controller?> ? > Thoughtful Pony > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-listAria Stewart aredridel at nbtsc.org
On Fri, May 23, 2008 at 12:16:15PM +0200, Magnus Holm wrote:> Do you think we should add a protection inside Camping too?No, if Rack comes with Rack::Lint and Camping now depends on Rack, then it''d be redundant to have it in Camping as well, you know? _why
On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote:> This should help. include Camping::ControllerSecurity in your controllers > module or your Camping (or whatever Camping.goes has turned it in to) > module, after requiring this: > >> module Camping >> module ControllerSecurity >> def service(*a) >> @method = ''get'' unless [''get'', ''post'', ''delete'', >> ''head''].include?(@method.to_s.downcase) >> super(*a) >> end >> end >> end > > > And the world should feel safe again, I think. I haven''t really tested it > properly, but what could go wrong? It certainly isn''t making my app break.You missed PUT :) I can imagine situations where you''d want to be able to use more esoteric HTTP methods (like OPTIONS, or any of WebDAV''s many extension methods). I don''t have a better solution though, and this may be Good Enough?. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/56d7b37e/attachment.bin>
You at least want to allow what''s in the HTTP spec -- that''s HEAD, TRACE, OPTIONS, and CONNECT, on top of the GET/POST/PUT/DELETE. -- Eric On Fri, May 23, 2008 at 7:21 PM, Brendan Taylor <whateley at gmail.com> wrote:> On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote: >> This should help. include Camping::ControllerSecurity in your controllers >> module or your Camping (or whatever Camping.goes has turned it in to) >> module, after requiring this: >> >>> module Camping >>> module ControllerSecurity >>> def service(*a) >>> @method = ''get'' unless [''get'', ''post'', ''delete'', >>> ''head''].include?(@method.to_s.downcase) >>> super(*a) >>> end >>> end >>> end >> >> >> And the world should feel safe again, I think. I haven''t really tested it >> properly, but what could go wrong? It certainly isn''t making my app break. > > You missed PUT :) > > I can imagine situations where you''d want to be able to use more > esoteric HTTP methods (like OPTIONS, or any of WebDAV''s many extension > methods). I don''t have a better solution though, and this may be Good > Enough?. > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
On May 23, 2008, at 5:21 PM, Brendan Taylor wrote:> > You missed PUT :) > > I can imagine situations where you''d want to be able to use more > esoteric HTTP methods (like OPTIONS, or any of WebDAV''s many extension > methods). I don''t have a better solution though, and this may be Good > Enough?.Indeed. I have a CalDAV server started using Camping as a basis.