This post covers a critical security flaw in Office 365 SharePoint with the Content Approval feature and version history. I’m hoping it’s fixed by the time you read this, but I was told it is “by design” first by the on-premises Microsoft Premier Support Team and now again by the Microsoft Office 365 Premier Support Team.

You decide for yourself.

Office 365 Content Approval

Here’s how you can reproduce this issue. Note, I’ve done this on a brand new site collection created using the latest Team Site – SharePoint Online configuration site collection template. It also reproduces in the Team Site – Classic template, but I want to make sure it’s proven out in the latest template as well.

I then created a subsite using the newer “Team Site” template…not the “Team site (classic experience)” template…again to make sure this reproduces on the latest features. To note, I’ve already proven this bug reproduces in SharePoint 2007, SharePoint 2013, and the Office 365 SharePoint classic mode sites.

Create a List – Enable Content Approval and Version History

Navigate to the list settings. Then to General Settings > Versioning Settings. Set:

• Require content approval for submitted items – Yes
• Create a version each time you edit an item in the list – Yes

Add SharePoint List Columns and a List Item

I’m going to add a few different types of SharePoint List Columns:

• Urgency – Choice (menu to choose from)
  • Low Priority
  • Standard Priority
  • Immediate Priority
• Cost Impact – Number
• Legal Notes
  • Multiple lines of text
  • Plain text
  • Append Changes to Existing Text – Yes

Okay, so now we have a new item form as follows:

Now, add a new item and ensure you do this as a user different from the user who will be executing the content approval. After adding the item, make an update to it from this same non-approval user. You’ll have a SharePoint List Item Version History such as the following:

What’s important to note in the above is that all three updates show they were made by John Doe. This is a contributor to the site, and this is in fact who made the updates.

Complete Content Approval and then Review Version History

Here’s the bug…

Now, as a user with Content Approval permissions, who is not the user who added and updated this item. Complete the content approval:

Now, view the SharePoint List Item Version history after Content Approval:

See what’s wrong there? It looks like the content approval owner is the person who added the closing legal notes, decreased urgency, and reset cost impact. Look in the previous section…it was John Doe who added those legal notes.

Now, I understand this is a simple demo, but imagine the case where SharePoint is being used to track critical history on important legal, human resources, and financial content. After content approval, Office 365 SharePoint:

• Removes any trace that John Doe made that last update.
• Sets it so that Christopher Brotsos, the content approval owner, made the update. No changes were made by this user.

That’s a critical non-repudiation security flaw here. Imagine a department with dozens of employees collaborating on hundreds of these items. You could never go back and prove who made that last update, and that could be the update that closed the case, settled the financial terms, etc.

Conclusion

To conclude: twice now, I’ve been told by Microsoft Premier Support that this is by design. It is by design to completely remove any trace of a user having made an update to a list item. It is also by design that version history should show that a completely different person made the change.

Finally, if you try to reproduce this on a document library by setting and changing the document item’s properties…it will NOT reproduce. The version history integrity on the document library item remains…it will correctly show who made the last update and will not replace that user with the person who executed the content approval. So, Microsoft Premier support is also telling me that it’s by design that Lists should behave differently from Document Libraries with how they store and track version history for item properties.

You decide.

Categories: Office 365 and O365, SharePoint

Tags: Office, Office 365 and O365, SharePoint