| |||||||||||||
Office suite security is hardOffice suite security is hardPosted Jun 14, 2007 16:09 UTC (Thu) by MathFox (guest, #6104)In reply to: Office suite security is hard by eru Parent article: BadBunny? Only if you invite it in
Sorry, but I don't see what this example has to do with macros, unless you assume everything the technical writer does has to be mediated by the document macros, which would be just silly.One thing that can be done in a macro is currency conversion: a simple SOAP call to an currency website will do the trick. When one has the code to perform SOAP calls, one can generalize and use them for uploads of the document contents... These applets typically do not need external access. When they do, it would not harm usability if they asked. Something like a box saying "Macro send_travel_invoice requests to upload emp1234.odf to travels.mycompany.com. Allow? [Yes] [No] [Abort]". The box should come from the core of the application and be visually formatted in a way that no macro can replicate.Having the user confirm some actions is fine with me; but there are risks with confirmation boxes: Users may click "yes" without thinking when they see them too often; malicious macros may try to overwrite (part of) the box, presenting a different question to the user. I repeat that macro control is hard; document control is hard.
(Log in to post comments)
Office suite security is hard Posted Jun 14, 2007 20:03 UTC (Thu) by eru (subscriber, #2753) [Link] One thing that can be done in a macro is currency conversion: a simple SOAP call to an currency website will do the trick. When one has the code to perform SOAP calls, one can generalize and use them for uploads of the document contents...So, no SOAP calls without asking the user. Having the user confirm some actions is fine with me; but there are risks with confirmation boxes: Users may click "yes" without thinking when they see them too often; True, but the alternative of quiet access is worse. I would also assume that writers of non-malicious macros for the system would try to minimize these questions by avoiding redundant accesses and doing as much as possible per requested access, since it is now somewhat "expensive". The system might also try to be intelligent, eg. not ask again about trying to load the same URL or file. malicious macros may try to overwrite (part of) the box, presenting a different question to the user. It should not be too hard for the suite to prevent this by forcing this security box to be always be on top of all other windows. The dialog box would also be invisible from the point of the macro language. Eg. an open("filename", "w") kind of operation would pop up the box without giving the macro language any change to prevent or modify it.
|
|||||||||||||