One of our customers had a penetration test performed on their SharePoint system. I think it’s fairly standard, but it could have a custom login form. In fact, given some of the errors, I think it must have been – but I had little involvement, so I’m not sure. Heck, it could even have been a SharePoint 2007 system, or a new login form that we didn’t write.

Either way, I thought it would be interesting (and a good reminder) to look at some of the issues it threw up…

• Verbose Error Messages – Error messages returned by the application are informative and potentially useful from an attacker’s perspective.
• Missing Clickjacking Defences – The site/application did not utilise sufficient defences against Clickjacking attacks. Users interacting with a malicious site could be enticed into perform actions that would actually interact transparently with a target site.
• Username Enumeration – It is possible for an attacker to gather a list of existing user names from the login form. This happens because different error messages are sent in response to invalid username and invalid password situations.
• Viewstate Without MAC Enabled – The ViewState MAC was not present and therefore may allow an attacker to change information between the client and server in order to manipulate the web server or client.
• Password Autocomplete In Browser – Password auto-complete is not disabled in login forms. This allows user agents (browsers) to save used passwords in a cache. Obtaining valid login credentials through an attack on one such user agent may be much easier than attacking the application server itself.

Well, the Verbose Error Messages item is probably a factor of UAT, which was on the same machine, where we’d configured SharePoint to give more information than it’s usual ‘An Unexpected Error has occurred’. That’s fair enough.

User name enumeration through the login form was a surprise – I thought it was pretty much normal simply to say that there was an error. Looking at the default SharePoint 2010 Login.aspx (under _layouts) it only returns the one message, so this may be due to a custom login page.

Viewstate with MAC enabled was another surprise. SharePoint 2010 has ‘EnableViewStateMac’ set to true in Web.config by default, and a suitable key for the generating the ViewState Message Authentication Code (MAC) is also inserted into Web.config by default too (see the ‘machineKey’ in the config file). So, score another for SharePoint, though it is weird that the customer’s system didn’t have this.

Password Autocomplete in Browser is a naughty mistake – and one not found in the standard SP2010 login form. It’s disabled by default.

And finally ‘clickjacking’ defences – I must confess, I had to go and look this one up. Fortunately, I found a good article about it. Essentially, it’s a problem of content in an IFRAME being displayed within another page, but in a way that deceives the user about what they’re clicking on. It can be prevent – in modern browsers – by the HTTP Header ‘X-FRAME-OPTIONS’ – more on this from Eric Law. In short, this item is valid – I could find no evidence of such clickjacking defences in SharePoint, either as an HTTP header, or apparently there are some JavaScript defences to combat it. That’s a shame – but probably not to troubling – most of our systems and intranets anyway, so I can’t imagine what you’d clickjack for…

So, default SharePoint actually seems to score pretty on most of the issues raised, but clickjacking doesn’t seem to be defended against.

Also, while looking into this, I found this OWASP page about security attacks on SharePoint, which is pretty interesting. Though I’ve got to say, SharePoint is actually better than a lot of other products I’ve worked on with regard to security (mostly because ASP.NET is fairly well designed).