Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint: Ways to Lock-down SharePoint Designer Server-Side

Leave a comment

Beyond the discussion over the pro’s and con’s of SharePoint Designer, you may sometimes have to prevent its usage in order to comply with the policies or governance in place in your organization. Although you can block it from the client-side (using software restriction policies or Office ADM files), the most efficient measures (talking about enforcement) remain on the server-side.

Disable “Remote Interfaces” at Web Application Level

From the SharePoint Central Administration Web Site, you can modify the “Permissions for Web Application” and uncheck “Remote Interfaces”.

  • Pro’s: Simple, no code, config only
  • Con’s: will not only block SharePoint Designer but ALL “rich” protocols: WebDAV, Soap, FPRPC… No more Explorer View, RSS Feed, working from Office or “Edit in Office menu options”…

Lock Site Definition in ONET.XML

Modifying The configuration or each site definition in ONET.XML (adding the attribute DisableWebDesignFeatures=”wdfopensite” to each Project tag) will prevent customization using SP Designer.

  • Pro’s: Offers granularity per site definition
  • Con’s: Manual edition of ONET.XML by default… Up to you to package it properly otherwise.

Manage Permission at Site-Level

Add and Customize Pages: Removing this permission will prevent edition of pages that are not stored as list items (default.aspx and so on)

Browse Directories: disabling this option will simply prevent SPD to open a site… But it will also break other WebDAV clients!

Manage Lists: Disabling this permission will prevent some kind of modification from SPD but will not prevent its global usage. Moreover, it will also break simple browser-based advanced list edition…

  • Pro’s: Offers granularity per site.
  • Con’s: does not scale for large farms with lots of sites. Light break other functionalities or might not totally lock down SPD Usage… Better be prepared with a bullet-proof functional test matrix 😉

Using ISAPI Filter and User Agent String: UrlScan3.1

Since version 3.0, UrlScan tools comes with rich pattern-based request blocking options. To reject request originating from FrontPage Designer, add the following elements to the configuration file (UrlScan.ini):

RuleList=DenyUserAgent

[DenyUserAgent]
DenyDataSection=Agent Strings
ScanHeaders=User-Agent

[Agent Strings]
MS FrontPage 12.0

  • Pro’s: Easy to deploy and to configure. Excellent performances. Participates to the overall effort to secure the platform. Includes logging (own and IIS W3C files). Relatively granular deployment possible (per web application)
  • Con’s: Remains at ISAPI-level. No rich authorization options (based on user identity, membership…). Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using ISAPI Filter and User Agent String: Make your own

“Simplistic” example below. Ready to be compiled. Do not forget to chose the appropriate platform (32 or 64-bit) depending on your destination server.

#include <windows.h>
#include <httpfilt.h>

BOOL GetFilterVersion(HTTP_FILTER_VERSION *pVer)
{
  pVer->dwFlags = (SF_NOTIFY_PREPROC_HEADERS | SF_NOTIFY_AUTHENTICATION |
             SF_NOTIFY_URL_MAP  | SF_NOTIFY_SEND_RAW_DATA | SF_NOTIFY_LOG  | SF_NOTIFY_END_OF_NET_SESSION );
  pVer->dwFilterVersion = HTTP_FILTER_REVISION;
  strcpy(pVer->lpszFilterDesc, "SharePoint Designer Blocking ISAPI, Version 1.0");
  return TRUE;
}

DWORD WINAPI __stdcall HttpFilterProc(HTTP_FILTER_CONTEXT *pfc, DWORD NotificationType, VOID *pvData)
{
    char buffer[256];
    DWORD buffSize = sizeof(buffer);
    HTTP_FILTER_PREPROC_HEADERS *p;
    switch (NotificationType)  {

      case SF_NOTIFY_PREPROC_HEADERS :
      p = (HTTP_FILTER_PREPROC_HEADERS *)pvData;
      BOOL bHeader = p->GetHeader(pfc,"User-Agent:",buffer,&buffSize);
      CString UserAgent(buffer);
      if(UserAgent.Find("MS FrontPage 12.0") != -1) {
          p->ServerSupportFunction( pfc, SF_REQ_SEND_RESPONSE_HEADER, (PVOID) "403 Forbidden" , (ULONG_PTR)"Content-Length: 0rnContent-Type: text/htmlrnrn", NULL );
      }
      return SF_STATUS_REQ_HANDLED_NOTIFICATION;
    }
    return SF_STATUS_REQ_NEXT_NOTIFICATION;
}

  • Pro’s: Easy to deploy. Excellent performances
  • Con’s: Requires code and appropriate compilation. Limited functionalities, hard to code compared to HTTP modules/handlers. No logging, totally blind operations. Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using HTTP Module and User Agent String: Make your own too

HTTP modules are "roughly the .Net translation of ISAPI with tons of extra capabilities. “Simple” example below.

using System;
using System.Web;

namespace BlockSPD
{
    public class BlockSPDHttpModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(BeginRequest);
        }
        private void BeginRequest(object sender, EventArgs e)
        {
            HttpContext currentContext = HttpContext.Current;

            if (currentContext.Request.UserAgent != null && currentContext.Request.UserAgent.Contains("MS FrontPage 12.0"))
            {
                currentContext.Response.StatusCode = 403;
                currentContext.Response.StatusDescription = "Forbidden";
              &
#160; currentContext.Response.End();
            }
        }
        public void Dispose()
        {    
        }
    }
}

  • Pro’s: Easily to develop and relatively easy to deploy. High flexibility for extra conditions: user’s identity, group membership, URL accessed… with minimal effort compared to ISAPI
  • Con’s: Requires code. Implies more processing overhead than ISAPI. No logging, totally blind operations. Not 100% reliable: techies can find easy ways to tweak their User-Agent string

Using HTTP Module and User Agent String: Cool CodePlex projects

Don’t want to waste your time playing around with own modules/handlers, take a look at these ones from CodePlex:

More options using ISAPI, Modules, handlers or URLScan…

The technologies described above can also be used to reject requests that can be considered as “typical” fro SPD:

– Rejecting request whose URL ends with “/_vti_bin/_vti_aut/author.dll"

– Rejecting verbs or request that are typical from the FrontPageRPC procotol

In both cases, you might also block valid request coming from OFfice applications such as Word or Excel though…

Additional Resources

Marc

Advertisements

Author: Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s