Critical Security Issue in Groove Forms

[Ashok Hingorani]

Hi

what with roles and permissions and the ability to restrict forms / views
visibility etc etc - it seems so strange that a user can just goto
Files/Export and dump all data to an excel sheet ???

there must be a way to stop members getting data out of Groove that the
designer does not want them to see - all export / copy / print must be
restricted to the content of views allowed to participants / guests

seem to remember in the old days it was possible to access the main tool
menu from JS code - to add or disable menu items - is this still possible - i
see no API's to access the toolcontainer / globalcontainer

or is this ability to restrict what members can do in a tool covered by the
Profiles, which i have little info on - are Profiles set only by the Hosted
Management servers or can they be set for indiv users as well

this is a show stopper for certain Apps where crtitical info must be made
available for internal lookups / verification but no way we want the member
to access the real data let alone dump it all to Excel so easily

any houghts would be welcome - specially - how do we get this to the
attention of Groove / Support and get them to fix it asap.

rgds

ashok

 

[Hugh Pyle [MSFT]]

Hi Ashok. Jack's elsewhere but you can certainly fire this sort of stuff
toward me.

As Mark, says, the security boundary is the workspace, and we've always been
careful to not present any visibility controls within the workspace as
security functions (eg. the visibility controls per form or per view)...
even when some of those controls are moderately secure. In Forms, the
somewhat-more-secure option is to use "reader" fields to control access: if
your name is not on the reader list, you are blocked from reading the
record. But even here, it really is not a truly secure option, since the
data always gets on to your machine and into the database if you're a member
of the workspace, and you could certainly find it with enough determination.

In the lookup-confidential-information case, I guess you could obfuscate the
critical data with some sort of ROT13 or XOr or the like, and decode it
using script - but of course anyone with access to a script debugger (i.e.
just about anyone) could easily get to the cleartext. In general, if the
workspace contains the data, then the amount of determined effort needed for
a workspace member to access that data is a sliding scale from "trivial" to
"probably not very difficult". On the other hand, the amount of effort
required for a non-member to access that data is significant.

Bottom line: if you don't want people to have access to the data in a
workspace, don't invite them to it.

 

[Hugh Pyle [MSFT]]

Good to see you active here too. Hope you'll look us up if you're back on
the east coast sometime.

 

[Ashok Hingorani]

sure will Hugh
maybe in the next few months
need to get my Virtual Application Processor running clean.

meanwhile could you pls see if there is any way to get some things
'rectified' like the security / export to excel etc and the abscence of field
lengths in the Web Services schema. actually have a really long list but this
is not the place i suppose.

cheers

ashok