Hi, I'm not totally sure I understand the issue. The ActiveXObject and framework.openUrl will both just shell execute the URL in the default browser. While applications could potentially modify this request and redirect the user to an alternative webpage e.g. for fishing etc. the attacker would already need access to the machine. In this case it doesn't make any difference if you use http or https.
The man-in-the-middle attack that was mentiond to you was probably about the use of XmlHttpRequest. If you are connecting to an unsecure page it can be possible that someone modifies the response and provides the gadget with malformed, invalid or corrupt data. If you are doing any posts to your webpage with XmlHttpRequest you should definitely use https connections because otherwise it is possible to read the information you transmitted if the attacker is on the same network. If you are requesting data that is executed on the client e.g. through eval calls you should first make sure the data has the correct format and run some sanitation method on it. I'm not sure what information you are retrieving in your update method but if you send the gadget a new download url which is downloaded and executed on the client (using ActiveXObject and run() ) then it is potentially possible that an attacker can simulate an update response and send the gadget a link to a virus or other malware which is then downloaded and executed to infect the pc. The idea for updates is to not download and execute any executables or gadgets but to forward the user to a webpage where he can download the updated version himself. Since browsers now often check downloaded files for viruses and the user can verify that this is iin fact your webpage this is much safer and less critical. Hope this answers your question. If you have more question maybe you can send a link to the gadget so I can have a closer look at the code and see what the issue might be. Benjamin On Sep 23, 1:59 pm, eharman <[EMAIL PROTECTED]> wrote: > Hi there, we've written a gadget that links out to multiple URLs in a > variety of different ways. Recently we received feedback from someone > at Google that our "download the latest version" mechanism is > susceptible to man-in-the-middle attacks. They recommended using > framework.openUrl instead of the activexobject, and also using https > instead of http. They said it was a critical flaw in the gadget, and > must be fixed before publishing. > > Fair enough, I'm all for fixing security holes. However it's confusing > that they only seemed to care about our "download" mechanism, even > though we clearly have multiple other URLs that open via the same > mechanism (i.e. a browser), and are also not secure. So I have some > questions which I'm hoping someone will be able to shed some light on! > > 1. Is there anything about framework.openUrl that is inherently more > secure than using the activexobject? Are there any other differences > that might make one more advisable than the other? > > 2. Should all URLs opened in a web browser from the gadget use a > secure protocol? > > 3. We're also using XmlHttpRequest for asynchronous transmission, > hitting non-secure URLs. Is there something safer about XmlHttpRequest > that would explain why the Google peeps didn't flag it as a security > risk? > > In case anyone's wondering why we don't just ask the people who made > the recommendation originally: we are, but I have low confidence in > quality of communication with them :) Unfortunately the message we > received has been filtered through many different (non-technical, I'm > guessing) people, not to mention 3rd party companies. I was hoping > someone here would have a faster and clearer answer. > > Thanks! > 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 -~----------~----~----~----~------~----~------~--~---
