Security Issues with the HEAD approach to authorizing SharePoint content
January 10th, 2010
Recently, while working on a Google Search Appliance implementation involving a custom SAML interface users were being returned documents in some cases which they did not have access to. In reviewing the logs, we found that SharePoint was responding with an HTTP status of 200.
The GSA resolves late binding by performing a head request. Our case involved a user being granted access to a document by the GSA that they shouldn’t have. For reasons unknown, when one user accessed a page, they got a 401 (unauthorized) and when another use accessed the page, they got an error. Both users were not able to access the document.
The head request was something similar to:
This appears to be a standard 200 response, but it contains something interesting. There is an additional header called SharePointError. In digging around MSDN, I found this article . The SAML bridge had to be modified to check for this head in addition to the response. The existence of this header does not indicate a failure, only that it needs to be future examined to see if the user has access.
