1

I work in application security and SharePoint is a new area for me to be operating in. I apologize in advance if my command of the local lingo is lacking.

I recently set up an automated scan of a relatively small SharePoint site that a developer group wanted to publish outside the company firewall. The site provides a form for employees to request PTO and an approval interface for managers. The scan was running off a web crawler and must have found its way into the _layouts folder, because the end result was that the scan actually deleted the default.aspx of the site. This was simple enough to restore, and indicative of a major security in and of itself as the scan was running as an unprivileged user.

I'm now trying to build better testing procedures that will avoid some headaches down the road. What control directories and paths should I be aware of and check manually prior to unleashing a web crawler / input fuzzer on a SharePoint site? Are there any other things I should be aware of before targeting a SharePoint site with automated scanning?

Improve this question
3
  • Side note: the particular scanner being used is IBM Rational AppScan Enterprise.
    – Eric Kolb
    Commented Aug 21, 2012 at 21:05
  • 1
    I realize this is off-topic, but SharePoint security is pretty well tested and an 'unprivileged user' deleting content is not very likely. What is more likely is that the user account has higher permissions on the site through some other mechanism, like AD group membership or application policy. The Site Collection Admin can check the permissions easily in Site Settings - Check Permissions for User. It is also possible that the Site Collection itself has its permissions set improperly (i.e. Everyone in the Owners group) Both cases should be corrected before this is pushed out.
    – Dave Wise
    Commented Aug 21, 2012 at 21:24
  • @Dave I believe you're correct. I should have said, "Not Especially Privileged" user. The user was created specifically for testing and had not been added to any special security groups. Most likely, the developers had left something grossly misconfigured. We're refining our processes to identify issues like this before we get to a scan phase.
    – Eric Kolb
    Commented Aug 21, 2012 at 21:30

2 Answers 2

Reset to default
1

This is SharePoint and there is no 'safe area' to exclude from a scan as developers can add customizations pretty much anywhere. As onzur points out, /_layouts/ is generally safe as it is usually standard Microsoft Code, but you cannot assume it is safe because developers can customize the Microsoft pages (very bad practice) or they can add their own code somewhere under that folder as well (better).

It is also worth mentioning that any changes in the /_layouts/ folder affects all sites in a farm so there may be customizations that someone did for Site ABC that has nothing to Site XYZ, yet XYZ will have those changes as well, for better or worse.

Improve this answer
0

Check out the [SiteLockDownFeature](http://sharepoint-sezai-moss-2007.blogspot.com/2008/02/securing-moss-2007-publishing-sites.html ). I would check w/ the devs if its acceptable to turn Publishing features on and utilizing it. It ensures only pages within the pages directory can be accessed anonymously.

The _layouts, vti_bin, and other directory are the main one that comes to mind, but I would follow up with your team and talk to them. I would open up SharePoint Designer and look at the "All Files" tab.

Also, I would advise you get the tool to set up alerts vs automatically deleting things as next time it might not be as easy to restore :).

Best of luck. Hope that helps

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.