I think the safest thing to do is probably to check the update url for updates and have it just return some basic information like update available yes/no. If the gadget gets a yes response it can popup a predefined message to the user "There is a new version available, visit our webpage to download it now" and then redirect him to the gadgets webpage which is hard-coded in the gadget itself. You could add the current version as a get parameter here and greet the user with the update message if he in fact needs a new version.
Benjamin On Sep 24, 12:17 pm, eharman <[EMAIL PROTECTED]> wrote: > Thanks for your response, this is most interesting. I didn't think > there was anything special about framework.operUrl, and since we're > trying to be backwards compatible to 5.1 I think we'll continue using > the activexobject. > > OK, so that's a lot to think about. Firstly you advise using a secure > connection whenever posting data; happily we're already doing this. > The gets are using non-secure connections, but (with the exception of > the download URL) all responses are verified before parsing. > > Secondly all asynch responses are XML, not JSON, so no danger of eval- > ing something nasty. The download URL is the only instance where un- > audited response data is given directly to the user. > > Thirdly, there's the question of the update mechanism. At the mo it > looks like this: > 1. Asynch request for version info + update URL to new .gg file (not > secure) > 2. Gadget displays upgrade message and "download" link > 3. User clicks link, which uses WScript.Shell to run the URL in the > default browser (not secure) > 4. User is prompted to save/run by the browser, following the normal > browser download flow. > > If I'm understanding correctly, an attacker might intercept the asynch > version/URL request (#1), and modify the response to include a bogus > update URL. I totally agree that we should not be providing a direct > URL to the .gg file; thanks to this thread I now have external support > to convince people to provide a download *page* instead. Much better > usability if nothing else, as we can give instructions on what to do > if the install doesn't work. > > Even given that change, I suppose technically our asynch XML response > would still be vulnerable to attack: someone could still modify it to > a URL of their choosing. I'm guessing we should also make this request > secure, just to be on the safe side? > > Thanks for the clarification on how MITM attacks work, and that simple > links to web pages are low in risk. I think other than the two fixes > for the upgrade mechanism, it sounds like we're pretty clear. Am I > missing anything that you can tell? BTW sorry I can't send the gadget > itself; it hasn't been released yet and blah legal blah. > > Elaine --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Desktop Developer Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Desktop-Developer?hl=en -~----------~----~----~----~------~----~------~--~---
