Enhancements to PageParserPath element in the SharePoint web.config – PhysicalPath

September 2020 public update for SharePoint included a security fix which broke lots of existing customized ghosted pages in SharePoint installations.

The security fix requires administrators to manually enable certain customized pages by adding a PageParserPath entry in the SharePoint/SafeMode section of the web.config containing a VirtualPath attribute which includes the virtual path to the affected page. The virtual path here represents the path part of the Url as it is requested from the server. E.g.:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath VirtualPath="/relativepath/page.aspx" CompilationMode="Always" AllowUnsafeControls="true" AllowServerSideScript="true" />
    </PageParserPaths>
</SafeMode>

Although wildcards are allowed for these PageParserPath entries for security reasons it is recommended to add VirtualPath as specific as possible. The VirtualPath should include site collection path which may require to add many entries even for one blocked ghosted page if it is used in multiple site collections.
In some scenarios hundreds of PageParserPath entries have to be added to unblock a single blocked ghosted page which is used in multiple site collections.

As a relief for this the implementation of the PageParserPath element has been enhanced by adding a PhysicalPath attribute to it.
In this scenario customers only have to enter a single PageParserPath element unblocking the specific ghosted page on the file system rather than multiple entries for each virtual path.

PhysicalPath is more secure than VirtualPath: while PageParserPath with VirtualPath attribute unblocks as well ghosted and unghosted pages (means pages which have been modified from the version on the file system and which are stored as modified version in the content database) the PhysicalPath attribute only unblocks ghosted pages. Means pages which have not been modified from the version on the file system. This guarantees that SharePoint administrators have full control over the code and controls referenced in the unblocked pages which is not always the case for pages that were modified by users with sufficient rights in a site collection.

Syntax:

Example 1

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath 
             PhysicalPath="C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\GLOBAL\seattle.master" 
             CompilationMode="Always" 
             AllowUnsafeControls="false" 
             AllowServerSideScript="true" />
    </PageParserPaths>
</SafeMode>

Note:

  • PhysicalPath is real full physical path of the seattle.master file in the file system.
  • The same additional attributes (e.g. CompliationMode, AllowServerSideScript) can be used as with VirtualPath

 

Example 2

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false"> 
    <PageParserPaths>
        <PageParserPath 
             PhysicalPath="C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\solutiondir\*" 
             CompilationMode="Always" 
             AllowServerSideScript="true" 
             AllowUnsafeControls="false" 
             IncludeSubFolders="true"/>
        <PageParserPath VirtualPath="/<anySubPath>" ... />
    </PageParserPaths>
</SafeMode>

Note:

  • PhysicalPath also support suffix wildcard, same as VirtualPath.
  • IncludeSubFolder attribute is also supported with PhysicalPath.

Example 3

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false"> 
    <PageParserPaths> 
        <PageParserPath 
            PhysicalPath="C:\anyPhysicalPath\*" 
            VirtualPath="/anyVirtualPath/*" 
            CompilationMode="Always" 
            AllowServerSideScript="true" 
            AllowUnsafeControls="false"/>
    </PageParserPaths> 
</SafeMode>

Note:

  • If PhysicalPath is specified together with VirtualPath, the PhysicalPath will be ignored and only the VirtualPath attribute is used.

 

Conflict management

It is possible to have multipled PageParserPath elements (some with VirtualPath while some with PhysicalPath). A single page could matched by more than one entry.
In this case the following logic will be applied to determine which element is being used:

  • If the page is matched by multiple PhysicalPath rules the most specific one will be used
  • If the page is matched by multiple VirtualPath rules the most specific one will be used
  • If the page is exactly matched by a PhysicalPath and exactly matched by a VirtualPath rule the VirtualPath rule will be used
  • If the page is exactly matched by a PhysicalPath rule and by a directoy matched VirtualPath rule the PhysicalPath rule will be used
  • If the page is directoy matched by a PhysicalPath rule and directoy matched by a VirtualPath rule the VirtualPath rule will be used

 

How can the physical path be identified if a page does not render?

An ULS log entry has been added to record the physicalPath for each accessed page. You can search ‘84lu6’ in ULS log and will find the PhysicalPath.

Here is example of from the ULS log:

w3wp.exe (0x0144) 0x1870 SharePoint Foundation Runtime 84lu6 Medium Get Page Parser Setting by virtualPath=/anysubpath/seattle.master and physicalPath=C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\global\seattle.master

Which SharePoint version benefit from the improvement?

Currently (February 2021 CU) SharePoint Server 2016 and 2019 can make use of the new PhysicalPath attribute for PageParserPath. In one of the upcoming CUs the functionality will also come to SharePoint 2013.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.