Saturday, February 26, 2011

Search Features vs. Security

One of the most popular search features on the web is the query suggestion feature, or a derivative, related queries.
image

This feature has now entered the SharePoint sphere with SharePoint 2010. In theory I agree the feature is a good one, but what about security? While the web is all about the masses, and any single person will be anonymously lost in the crowd, this is not necessarily the case in the enterprise.

I created a small test where user A uploaded a document with the term “pertaining pepsi” and user B one with the term “pertaining dr. pepper”. Each document is only available to the user uploading it.

In SharePoint 2010 search terms will be added as suggestion when the term has been used 6 times and someone clicked a result. User A searched for “pertaining pepsi” several times and opened the result document. Then I logged in as user B, and started to type “pert”


image

And lo and behold, it suggested the term with “pepsi”, even though the user don’t have access to any documents with the word.

The proper way of doing this is to execute a search for each suggested term and check if you have any results before displaying it to the user. It will require more search power, but at least you won’t breach security when your secret project is suddenly exposed to the rest of the company just because the team working on it searched on it so much.

2 comments:

  1. Ole Kristian Mørch-StorsteinFebruary 26, 2011 at 4:49 PM

    Excellent post!

    For organizations where protecting information is part of their bread and butter, this is a real showstopper. Basically query suggestions must be turned off in its current implementation.

    If querying the search engine once per suggestion is not an option (e.g. due to query volume) adding security trimming to the query suggestions means completely re-writing the feature as it's current implementation is based on extracting terms from the fixml, assigning rank according to statistical occurrence and submitting them to a classical Fast matcher which has no concept of security.

    ReplyDelete
  2. It's actually based on the executed queries, which are stored in a db, and not a FS4SP specific feature. All queries entered are logged, and then used for suggestion if enough of them are made and results are clicked.

    And for many enterprises the oob feature has to be turned off. Anyone up for creating one which works? :)

    ReplyDelete