Rails - May 2005 - FYI: watch out for google's web accelerator - can empty your app of data

Hi All,

A co-worker passed this info on to me:
http://37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php

The Skinny: Google has a "Web Accelerator" that pre-caches pages by
following url''s.  If you have any plain/simple URL''s that
don''t take
paramaters (like what often happens in rails apps), it will try to
follow those links. So, take for example many of the tutorials out
there, if your app works like that where you click a link to delete
entries which uses a GET rather than a POST, the accelerator will
follow all those links and proceed to empty your DB.

The link above has a small fix for RoR stuff (checks a browser
variable & denies access if you have it).  Sorry if this has been
posted before - I did not see it in the archives.  Follow the link for
better details.

Thanks,

Clay

Godless Infidel wrote:
>he Skinny: Google has a "Web Accelerator" that pre-caches pages by
>following url''s... you click a link to delete
>entries which uses a GET rather than a POST
>
Don''t allow any GET to change your data. Use it for read-only 
operations, and use only POST for insert/delete/update.
I am quite surprised that they had this problem with Backpack, as this 
was a big pain in the ass for any public Instiki installation 
pre-version 0.9.2 (to those who remember it: that''s what
"mysterious
page rollbacks" was all about).

-- 
Best regards,

Alexey Verkhovsky

Ruby Forum: http://ruby-forum.org        (moderator)
RForum:     http://rforum.andreas-s.net  (co-author)
Instiki:    http://instiki.org           (maintainer)

Alexey Verkhovsky wrote:
> I am quite surprised that they had this problem with Backpack, as this 
> was a big pain in the ass for any public Instiki installation 
> pre-version 0.9.2 (to those who remember it: that''s what
"mysterious
> page rollbacks" was all about).
The comments to the original blog entry apparently contain the answer to 
my question.

-- 
Best regards,

Alexey Verkhovsky

Ruby Forum: http://ruby-forum.org        (moderator)
RForum:     http://rforum.andreas-s.net  (co-author)
Instiki:    http://instiki.org           (maintainer)

On 6 May 2005, at 22:27, Alexey Verkhovsky wrote:
> Don''t allow any GET to change your data. Use it for read-only  
> operations, and use only POST for insert/delete/update.
> I am quite surprised that they had this problem with Backpack, as  
> this was a big pain in the ass for any public Instiki installation  
> pre-version 0.9.2 (to those who remember it: that''s what  
> "mysterious page rollbacks" was all about).
To expand: common opinion on this has been that it''s a bad thing to  
do on public sites (because web crawlers will crawl your dangerous  
links) but it''s OK if you do it on applications that require  
authentication. This assumption is even built in to Rails in the form  
of the :confirm attribute, which is designed to be used on such links.

Google Web Accelerator highlights one of the reasons that making this  
assumption is unsafe. Another, and one that is rarely discussed, is  
that it introduces a major security hole in to your application. If I  
want to delete a whole bunch of stuff from your BackPack account (for  
example) I just need to trick you in to visiting a page with the  
following HTML:

<img src="http://your-user-name.backpackit.com/page/6000/destroy"  
width="1" height="1">
<img src="http://your-user-name.backpackit.com/page/6001/destroy"  
width="1" height="1">
<img src="http://your-user-name.backpackit.com/page/6002/destroy"  
width="1" height="1">
<img src="http://your-user-name.backpackit.com/page/6003/destroy"  
width="1" height="1">
<img src="http://your-user-name.backpackit.com/page/6004/destroy"  
width="1" height="1">
...
<img src="http://simon.backpackit.com/page/8000/destroy"
width="1"
height="1">

Provided I''ve covered all of the likely page IDs for your account  
(which really isn''t hard - there''s nothing to stop me adding
tens of
thousands of images to the malicious page) I can basically nuke your  
whole account.

Developers need to be more aware of this issue; I know I wasn''t.  
There''s a good thread about it on my blog:

http://simon.incutio.com/archive/2005/05/06/bad

Cheers,

Simon Willison
http://simon.incutio.com/

On 5/7/05, Alexey Verkhovsky
<alex-vV7tgcE2N9Nhl2p70BpVqQ@public.gmane.org>
wrote:
> Alexey Verkhovsky wrote:
> 
> > I am quite surprised that they had this problem with Backpack, as this
> > was a big pain in the ass for any public Instiki installation
> > pre-version 0.9.2 (to those who remember it: that''s what
"mysterious
> > page rollbacks" was all about).
> 
> The comments to the original blog entry apparently contain the answer to
> my question.
Yeah,  David''s comment was pretty accurate.   But Simon''s is
just as important.

I think something that would really help is perhaps a link_to_post
helper that creates something like

<form action="url" method="post"
id="something">
  <a href="#" onclick="submit the
form">link_text</a>
</form>

> --
> Best regards,
> 
> Alexey Verkhovsky
> 
> Ruby Forum: http://ruby-forum.org        (moderator)
> RForum:     http://rforum.andreas-s.net  (co-author)
> Instiki:    http://instiki.org           (maintainer)
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Cheers

Koz

How''s this safer.  Sure, you have to be a bit craftier, but
I''d think
you could easily simulate POSTs from some javascript.  Does Rails (or
web servers in general) protect against this at all?  You can probably
simulate referral links also.

Maybe the other lesson to be learned is don''t have guessable URLs like
username.site.com/page/n/destroy?

On 5/6/05, Simon Willison <cs1spw-+E0FUbDlCk21Qrn1Bg8BZw@public.gmane.org>
wrote:
> On 6 May 2005, at 22:27, Alexey Verkhovsky wrote:
> > Don''t allow any GET to change your data. Use it for read-only
> > operations, and use only POST for insert/delete/update.
> > I am quite surprised that they had this problem with Backpack, as
> > this was a big pain in the ass for any public Instiki installation
> > pre-version 0.9.2 (to those who remember it: that''s what
> > "mysterious page rollbacks" was all about).
> 
> To expand: common opinion on this has been that it''s a bad thing
to
> do on public sites (because web crawlers will crawl your dangerous
> links) but it''s OK if you do it on applications that require
> authentication. This assumption is even built in to Rails in the form
> of the :confirm attribute, which is designed to be used on such links.
> 
> Google Web Accelerator highlights one of the reasons that making this
> assumption is unsafe. Another, and one that is rarely discussed, is
> that it introduces a major security hole in to your application. If I
> want to delete a whole bunch of stuff from your BackPack account (for
> example) I just need to trick you in to visiting a page with the
> following HTML:
> 
> <img
src="http://your-user-name.backpackit.com/page/6000/destroy"
> width="1" height="1">
> <img
src="http://your-user-name.backpackit.com/page/6001/destroy"
> width="1" height="1">
> <img
src="http://your-user-name.backpackit.com/page/6002/destroy"
> width="1" height="1">
> <img
src="http://your-user-name.backpackit.com/page/6003/destroy"
> width="1" height="1">
> <img
src="http://your-user-name.backpackit.com/page/6004/destroy"
> width="1" height="1">
> ...
> <img src="http://simon.backpackit.com/page/8000/destroy"
width="1"
> height="1">
> 
> Provided I''ve covered all of the likely page IDs for your account
> (which really isn''t hard - there''s nothing to stop me
adding tens of
> thousands of images to the malicious page) I can basically nuke your
> whole account.
> 
> Developers need to be more aware of this issue; I know I wasn''t.
> There''s a good thread about it on my blog:
> 
> http://simon.incutio.com/archive/2005/05/06/bad
> 
> Cheers,
> 
> Simon Willison
> http://simon.incutio.com/
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
rick
http://techno-weenie.net

There''s a link_to_remote and link_to_function helper function already.

On 5/6/05, Michael Koziarski
<koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 5/7/05, Alexey Verkhovsky
<alex-vV7tgcE2N9Nhl2p70BpVqQ@public.gmane.org> wrote:
> > Alexey Verkhovsky wrote:
> >
> > > I am quite surprised that they had this problem with Backpack, as
this
> > > was a big pain in the ass for any public Instiki installation
> > > pre-version 0.9.2 (to those who remember it: that''s what
"mysterious
> > > page rollbacks" was all about).
> >
> > The comments to the original blog entry apparently contain the answer
to
> > my question.
> 
> Yeah,  David''s comment was pretty accurate.   But Simon''s
is just as important.
> 
> I think something that would really help is perhaps a link_to_post
> helper that creates something like
> 
> <form action="url" method="post"
id="something">
>   <a href="#" onclick="submit the
form">link_text</a>
> </form>
> 
> > --
> > Best regards,
> >
> > Alexey Verkhovsky
> >
> > Ruby Forum: http://ruby-forum.org        (moderator)
> > RForum:     http://rforum.andreas-s.net  (co-author)
> > Instiki:    http://instiki.org           (maintainer)
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> --
> Cheers
> 
> Koz
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
rick
http://techno-weenie.net

On 5/7/05, Rick Olson
<technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> There''s a link_to_remote and link_to_function helper function
already.
Neither of which do what the snippet I posted does, link_to_remote is
for ajax, not plain old http.  And link_to_function is just a link to
a javascript function

link_to_post would simply be a form tag wrapping link_to_function, but
it has very different behaviour.
> On 5/6/05, Michael Koziarski
<koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 5/7/05, Alexey Verkhovsky
<alex-vV7tgcE2N9Nhl2p70BpVqQ@public.gmane.org> wrote:
> > > Alexey Verkhovsky wrote:
> > >
> > > > I am quite surprised that they had this problem with
Backpack, as this
> > > > was a big pain in the ass for any public Instiki
installation
> > > > pre-version 0.9.2 (to those who remember it: that''s
what "mysterious
> > > > page rollbacks" was all about).
> > >
> > > The comments to the original blog entry apparently contain the
answer to
> > > my question.
> >
> > Yeah,  David''s comment was pretty accurate.   But
Simon''s is just as important.
> >
> > I think something that would really help is perhaps a link_to_post
> > helper that creates something like
> >
> > <form action="url" method="post"
id="something">
> >   <a href="#" onclick="submit the
form">link_text</a>
> > </form>
> >
> > > --
> > > Best regards,
> > >
> > > Alexey Verkhovsky
> > >
> > > Ruby Forum: http://ruby-forum.org        (moderator)
> > > RForum:     http://rforum.andreas-s.net  (co-author)
> > > Instiki:    http://instiki.org           (maintainer)
> > >
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> >
> > --
> > Cheers
> >
> > Koz
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> --
> rick
> http://techno-weenie.net
> 

-- 
Cheers

Koz

On 6 May 2005, at 22:42, Rick Olson wrote:
> How''s this safer.  Sure, you have to be a bit craftier, but
I''d think
> you could easily simulate POSTs from some javascript.  Does Rails (or
> web servers in general) protect against this at all?  You can probably
> simulate referral links also.
Rats, you can. I just built a quick proof of concept which adds an  
iframe, then writes the HTML for a form to it and submits it. You  
could include hundreds of those on the page in the exact same way as  
the image trick.

This is the exact problem that the XMLHttpRequest same-domain  
security policy is meant to fix, but it seems all-too-easy to work  
around.

It looks like the only way to build this kind of functionality  
securely is to add a randomly generated hidden form field variable to  
the form, which confirms that the POSTed data came from a form that  
was first retrieved from that site. Some kind of mechanism for doing  
this easily would be an excellent addition to Rails, or indeed any  
other framework.

It''s interesting to note that the same trick can be used to secure  
against the GET attack I described previously, which actually weakens  
my earlier argument.

Cheers,

Simon Willison
http://simon.incutio.com/

(This follows on from the thread about Google''s web accelerator)

It seems the vulnerability I''ve been talking about has a name: CSRF,  
or Cross-site request forgery:

http://www.squarefree.com/securitytips/web-developers.html#CSRF

That page describes a fix for the problem, based on a hidden form  
field that hashes the user''s login cookie with a secret on the  
server. Automated support for this could be added to Rails extremely  
easily, and would defend against an important and rarely discussed  
class of security vulnerabilities.

Cheers,

Simon Willison
http://simon.incutio.com/

I''ve collected a bunch of post/comments/link about this stuff on my
blog:
http://www.oluyede.org/blog/2005/05/07/the-get-mess/

Hope this helps

-- 
Lawrence
http://www.oluyede.org/blog

Michael Koziarski wrote:
>
>>question.
>>    
>>
>
>Yeah,  David''s comment was pretty accurate.   But Simon''s
is just as important.
>
>I think something that would really help is perhaps a link_to_post
>helper that creates something like
>
><form action="url" method="post"
id="something">
>  <a href="#" onclick="submit the
form">link_text</a>
></form>
>
>  
>
to go along with this does rails have a mechanism in place for limiting 
actions
to specific actions like delete is only allowed for POST. GET is disallowed?

I know you can add filters for requests but is there an easier machanism...
something along the lines of a:

post_only :delete, :create

which would create the requestite filtering?



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 5/7/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org>
wrote:
> Michael Koziarski wrote:
> 
> >
> >>question.
> >>
> >>
> >
> >Yeah,  David''s comment was pretty accurate.   But
Simon''s is just as important.
> >
> >I think something that would really help is perhaps a link_to_post
> >helper that creates something like
> >
> ><form action="url" method="post"
id="something">
> >  <a href="#" onclick="submit the
form">link_text</a>
> ></form>
> >
> >
> >
> to go along with this does rails have a mechanism in place for limiting
> actions
> to specific actions like delete is only allowed for POST. GET is
disallowed?
> 
> I know you can add filters for requests but is there an easier machanism...
> something along the lines of a:
> 
> post_only :delete, :create
> 
> which would create the requestite filtering?
Sure does, it''s called verify

http://rails.rubyonrails.com/classes/ActionController/Verification/ClassMethods.html#M000108

verify :method=> :post, :only=>[:dangeroud, :actions],
:redirect_to=>...


-- 
Cheers

Koz

On 07/05/2005, at 8:10 AM, Simon Willison wrote:
> That page describes a fix for the problem, based on a hidden form 
> field that hashes the user''s login cookie with a secret on the
server.
> Automated support for this could be added to Rails extremely easily, 
> and would defend against an important and rarely discussed class of 
> security vulnerabilities.
To support multiple windows/tabs submitting different forms, we''d need 
a list of valid tokens stored in the session, and not just one. Once a 
valid token is submitted it can then be expired.

I guess the tokens should be a hash salted with the user''s password (or
password hash) and should be expired at the earliest opportunity (end 
of session / logout).

If you used this token scheme you could still provide <a> links that 
included the token, which would prevent cross-site scripting attacks,  
but it still wouldn''t solve the original problem of GET vs POST though 
(in the case of Google Web Accelerator).

- tim lucas

On 07/05/2005, at 3:00 PM, Michael Koziarski wrote:
>> to go along with this does rails have a mechanism in place for  
>> limiting
>> actions
>> to specific actions like delete is only allowed for POST. GET is  
>> disallowed?
>>
>> I know you can add filters for requests but is there an easier  
>> machanism...
>> something along the lines of a:
>>
>> post_only :delete, :create
>>
>> which would create the requestite filtering?
>
> Sure does, it''s called verify
>
> http://rails.rubyonrails.com/classes/ActionController/Verification/ 
> ClassMethods.html#M000108
>
> verify :method=> :post, :only=>[:dangeroud, :actions],  
> :redirect_to=>...
Though what advantage does this give in terms of CSRF(1), as it  
certainly doesn''t provide much added security?

- tim lucas

http://www.squarefree.com/securitytips/web-developers.html#CSRF

Tim Lucas wrote:
> On 07/05/2005, at 3:00 PM, Michael Koziarski wrote:
>
>>> to go along with this does rails have a mechanism in place for  
>>> limiting
>>> actions
>>> to specific actions like delete is only allowed for POST. GET is  
>>> disallowed?
>>>
>>> I know you can add filters for requests but is there an easier  
>>> machanism...
>>> something along the lines of a:
>>>
>>> post_only :delete, :create
>>>
>>> which would create the requestite filtering?
>>
>>
>> Sure does, it''s called verify
>>
>> http://rails.rubyonrails.com/classes/ActionController/Verification/ 
>> ClassMethods.html#M000108
>>
>> verify :method=> :post, :only=>[:dangeroud, :actions],  
>> :redirect_to=>...
>
>
> Though what advantage does this give in terms of CSRF(1), as it  
> certainly doesn''t provide much added security?
>
> - tim lucas
>
> http://www.squarefree.com/securitytips/web-developers.html#CSRF

      Preventing CSRF

   1. Make sure that the cgi that handles form submissions for forms
      that change server state only accepts POST parameters, not GET
      parameters. Some server-side languages default to accepting both.





_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 13/05/2005, at 12:41 AM, Sean T Allen wrote:
>>> verify :method=> :post, :only=>[:dangeroud, :actions],  
>>> :redirect_to=>...
>>
>> Though what advantage does this give in terms of CSRF(1), as it  
>> certainly doesn''t provide much added security?
>
>   Preventing CSRF
>
>   1. Make sure that the cgi that handles form submissions for forms
>      that change server state only accepts POST parameters, not GET
>      parameters. Some server-side languages default to accepting both.
I should have placed emphasis on the *much* in "doesn''t provide
much
added security".

The point I was trying to make, though I agree I could have been more 
explicit, was that only accepting post won''t make it secure, so
let''s
get form token functionality in the form helpers.

- tim lucas

Tim Lucas wrote:
> On 13/05/2005, at 12:41 AM, Sean T Allen wrote:
>
>>>> verify :method=> :post, :only=>[:dangeroud, :actions],  
>>>> :redirect_to=>...
>>>
>>>
>>> Though what advantage does this give in terms of CSRF(1), as it  
>>> certainly doesn''t provide much added security?
>>
>>
>>   Preventing CSRF
>>
>>   1. Make sure that the cgi that handles form submissions for forms
>>      that change server state only accepts POST parameters, not GET
>>      parameters. Some server-side languages default to accepting both.
>
>
> I should have placed emphasis on the *much* in "doesn''t
provide much
> added security".
>
> The point I was trying to make, though I agree I could have been more 
> explicit, was that only accepting post won''t make it secure, so
let''s
> get form token functionality in the form helpers.
>
> - tim lucas
>
I never said that wasnt needed rather that the above is one part of the 
picture and being new to rails... i wasnt sure if/where it was 
implemented...



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails