Agreed, that would be the safest route. However we've got to do some dynamic jiggery-pokery with the URL, such that it does have to come from the server. Hopefully using a secure connection will be protection enough...
Elaine On Sep 24, 1:18 pm, "Benjamin [API Guru]" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
