Protect Yourself from Google Web Accelerator

Posted At : May 9, 2005 1:37 PM | Posted By : Steve
Related Categories:

Google has new tool called "Google Web Accelerator" out in beta that has the potential to cause quite a bit of trouble for web developers. Based on the information on the "Google Web Accelerator" help page, the tool is meant to speed up browsing for broadband users (as if our browsing isn't fast enough already).

The help page says that it does this in part by "Prefetching certain pages onto your computer in advance". This can effectively increase traffic on your site (due to the tool fetching pages that the user never reads) and mess up session tracking.

More significant, however, 37 Signals and other users report that this can cause the tool to follow "delete" links (among others) in an administration area (without respecting HTTP headers or JavaScript alerts). Note that I have not tried out Google's tool myself, for fear of messing up my own sites.

Google points to Mozilla Link Fetching as their model. This offers some hope because Mozilla's page says that they will only follow <link> tags not <a> tags. This, of course, is not what Google Web Accelerator appears to be doing currently. Given that Google's motto is "Don't Be Evil", hopefully they will correct the tool to work around these issues. In the meantime, we might be wise to protect ourselves.

Note that I don't believe this is a "panic issue". Few users have yet installed the tool and Google may make adjustments. Never-the-less, a little effort can help prevent potential problems.

How can we protect our sites?

The first thing to note is that Google Web Accelerator will not prefetch pages using SSL (https). If all of your administration sections use SSL, you have nothing to worry about.

If they don't, and if it isn't easy to make that change, you have a two other options (of which I am aware).

First, Damien McKenna has offered this bit of code which he says will block Google Web Accelerator:

<!--- block Mozilla Web Accelerator --->
<cfif structKeyExists(cgi, 'HTTP_X_MOZ')>
    <cfif cgi.HTTP_X_MOZ EQ 'prefetch'>
        <cfheader statuscode="403" statustext="Google Web Accelerator requests are forbidden." />
        <cfabort />
    </cfif>
</cfif>
Simply add that to the Application.cfm for your administration section (or any section/site for which you wish to block Google Web Accelerator).

Jochem van Dieten points out that the only reason that Google Web Accelerator can cause permanent changes on a web site (such a deleting information) is because so many of us aren't following the rules; namely RFC 2616 section 9.1.1 (he quotes the section below).
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
This is actually a very valid point. Permanent actions should be taken by clicking a button that spawns a POST action, not by clicking a link (and spawning a GET action). After all, users are used to links taking them to pages and buttons performing actions. It seems that this is the best fix because it is better for usability.

I plan to implement Damien's fix in the near future and change my applications to conform to RFC 2616 (and thereby hopefully improve usability as well) as time allows.


Read More:
http://www.houseoffusion.com/cf_lists/messages.cfm/forumid:4/threadid:40069

Comments (5) | Print | del.icio.us | Digg It! | Linking Blogs
Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
[Add Comment]
Another good practice is to have 'Are you sure?' confirmation prompts on your Delete functions. Web Accelerator does not follow JavaScript logic.

-Tim

Tim Jackson  [tim@jacksontechnical.com]

# Posted By | 5/9/05 3:34 PM
That is a good point. The 37 Signals article indicates that the action is performed despite a JavaScript confirmation.

I am not sure how they have their JavaScript confirmations set up, however. I generally have my link point to a JavaScript confirmation which then changes location.href.

That method should be safe from this problem. This approach, however, is problematic in that it prevents users with JavaScript disabled from performing the function.
# Posted By | 5/9/05 4:18 PM
- Others who have written about this problem have made the point that if your application uses a permanent cookie to identify you, and if you view a page on another site that "happens" to have links to your site, links you might not even see, WebAccelerator will execute those links.
- They have also written that operations that change data "should" use "post" rather than get.
- Unfortunately, for the many sites that use fusebox's FormURL2Attributes tag, it doesn't matter if you intended the data to be posted from a form. If a link contains the necessary information, the fusebox application will blithely accept the input as if it came from a form.
- So, if you're logged in (either through current action in another window or by the magic of a cookie that remains on your browser to keep you from having to log in), then browsing other sites with WebAccelerator can be hazardous to your application; especially if you've ticked off anyone who has a general idea of how your application works. =Marty=

R Martin Ladner  [martin.ladner@gunter.af.mil]

# Posted By | 5/12/05 1:42 PM
If you are producing applications that do not validate page information by checking source, information, and relationship then you deserve to be "Googled". No where in any action script should a "user" be able to produce an action without proper page credentials.

No wonder CF was and still is considered a "beginner's" action script.

Bad code is bad code. Reap what you sow. etc.etc.etc.

The simplicity of ColdFusion does not make experts out of beginners.

I call this the "Frontpage" effect. Anybody can build a website and 30% of my business is because someone built a site, in Frontpage.

a_real_cf_developer

# Posted By | 5/12/05 7:10 PM
Sounds like this will make websites more secure by calling attention to shortcuts that all of us have probably been guilty of at one time or another.

This will throw off web stats and analytic tools, making it more difficult to get a true picture on pagehits. Any opinions on how this will affect banner ads?
# Posted By Chris Vestal | 6/30/05 4:38 AM
[Add Comment]
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.