Blog posts by Petra Liljecrantz

Common security issues with a CMS application

Thu, 14 Apr 2016 20:39:16 GMT

This is the fourth and final post about issues I encounterd working for Episerver Managed Services. We (and the entire support organization) often saw some security issues in applications and I wanted to share the four most common ones.

Exposed web services with debug tracing on

The attribute includeExceptionDetailInFaults is set default to true and a default value is often transferred to a production environment as well, it should be set to false so exceptions are not included in the packages when, for example, a cache invalidation broadcast occurs in Episerver CMS.

Set it like this:

<configuration>
    …
    <system.serviceModel>
        ... 
        <behaviors>
            <serviceBehaviors>
                ...
                <serviceDebug includeExceptionDetailInFaults="false" />

Username and passwords are sent in plain text

This is one of those things that most developers actually know is bad but somehow it gets down prioritized or just forgotten, so I can´t stress this enough.

Username and password are sent as plain text over the internet when logging in to edit mode, this makes it easier to listen to and get access to the servers. Use an SSL certificate to protect at least the login if not the entire site, the most common way is to terminate the SSL certificate in the server or load balancer with a wildcard certificate that can handle sub domains.

Unused role- and membership providers are exposed

An application should only use the SqlServerRoleProvider as the means of logging in (or ADFS) but usually both MultiplexingRoleProvider and WindowsRoleProvider are still loaded as role providers, the same goes for the membership providers. To minimize the attack surface it’s recommended to only expose active providers.

The WindowsMembershipProvider will expose the administrator account directly out on the internet available for brute force attacks. Therefore it´s recommended to simply remove the role- and membership providers not used from web.config.

Here is an example of web.config transformations you can use to force this behavior:

<!-- Set "SqlServerMembershipProvider" as default and remove the other providers -->
<membership defaultProvider="SqlServerMembershipProvider" xdt:Transform="SetAttributes(defaultProvider)" >
    <providers>
        <clear />
        <add name="MultiplexingMembershipProvider" xdt:Transform="Remove" xdt:Locator="Match(name)" type="EPiServer.Security.MultiplexingMembershipProvider, EPiServer.Framework" />
        <add name="WindowsMembershipProvider" xdt:Transform="Remove" xdt:Locator="Match(name)" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" />
    </providers>
</membership>

<!-- Set "SqlServerRoleProvider" as default and remove the other providers -->
<roleManager defaultProvider="SqlServerRoleProvider" xdt:Transform="SetAttributes(defaultProvider)" >
    <providers>
        <clear />
        <add name="MultiplexingRoleProvider" xdt:Transform="Remove" xdt:Locator="Match(name)" type="EPiServer.Security.MultiplexingRoleProvider, EPiServer.Framework"  />
        <add name="WindowsRoleProvider" xdt:Transform="Remove" xdt:Locator="Match(name)" type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
    </providers>
</roleManager>

Open edit mode on webfronts

All public servers expose EPiServer’s largest attack surface: the editorial and administrator interface, this is a security risk and in an environment that has one separate server for administrators to do their work and another (or several) servers acting as web fronts it´s a good recommendation to deny access to edit mode for all users (including editors and administrators as they should use the other server and that server should be protected by IP restriction or domain restriction).

This is done by replacing the location path configuration in web.config to deny all users access to the paths “episerver/”, “episerver/CMS/admin/” and “/util”. Since the methods HasEditAccess and HasAdminAccess in PrincipalInfo is based on this path you need to explicitly deny acces and not just remove the location path.

Example of deny access to all:

<configuration> 
  ...
  <location path="episerver">
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
  </location>

If there´s no separate admin server then you´ll want to restrict the edit and admin location path to only allow certain IP numbers. Episerver Managed Services provide IP restrictions in the firewall, but a better way (in my opintion) to do it is in the application, through a setting in web.config. Then the customer or you as the developer can control that yourselves.

This is all you need:

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false" denyAction="NotFound">
            <add allowed="true" ipAddress="123.456.0.0" subnetMast="255.255.0.0"/>
        </ipSecurity>
    </security>
</system.webServer>

The example configuration snippet shows an ipSecurity configuration that only allows access to addresses originating from the range specified by the combination of the ipAddress and subnetMask attributes. Setting allowUnlisted to false means that only those individual addresses, or address ranges, explicitly specified will be allowed to make HTTP requests to the website. Setting the allowed attribute to true in the child add element indicates that the address and subnet together define an address range that is allowed to access the website. If a request is made to a website from an address outside of the allowed IP address range, then a HTTP 404 Not Found error is returned as defined in the denyAction attribute.

Stay safe out there!

Differences between scheduled publish and normal publish

Tue, 22 Mar 2016 11:54:42 GMT

This is the third post on issues I encountered working for Episerver Managed Services and this time it´s about scheduled publish. One question that we got fairly frequent was about the scheduled publish job. Partners had issues of different kind (pages not publishing, cache not working etc.) and it was escalated to us. I find that there isn´t a whole lot documented about scheduled publishing so these are some stuff I learnt directly from the developer team. It covers some differences between a scheduled publish and a normal publish done manually by an editor which publishes the page directly.

The normal publish uses the users context while the scheduled publish runs without the users context and thus it skips the access check. This could in theory mean that a page can be scheduled for publish by a user that isn´t supposed to be able to publish.
The normal publish has access to the HttpContext and the scheduled publish hasn´t, so if a page that´s target for a scheduled publish relies on the HttpContext it will probably have some issues and the publish will most likely fail.
The normal publish fires off the publish event which will invalidate the built-in cache so that all load balanced servers will go to the database to fetch the new content, the scheduled publish however does not fire off that event so other load balanced servers will not get the new content until the pageCacheSlidingExpiration has passed (which is by default 12 hours). This setting can be changed in web.config by adding pageCacheSlidingExpiration anywhere in the applicationSettings tag within the episerver tag, like this:

<episerver>
    <applicationSettings httpCacheability="Public" pageCacheSlidingExpiration="7.00:00:00"...

How to keep the integrity of a backup chain

Mon, 21 Mar 2016 12:02:54 GMT

This is the second post about issues I often encountered working for Episerver Managed Services. It´s not an Episerver specific blog post per se, but we often saw this problem and it has to do with developers messing up the integrity of a backup chain. For some people this might be obvious and a no brainer, but like I wrote, it was quite a big problem so people need to learn and be aware of this.

The backup chain

In any hosting environment, regardless if you have in-house hosting or with a hosting provider such as Episerver Managed Services there are of course backup jobs running to backup an SQL database. A common setup is to take a full backup once a week and differential backups running each day or perhaps a full backup once and then only differential backups each day. Regardless which approach is used it´s important to keep the integrity of the backup chain.

The issue

All too often partners or customers have access to the production database and performing backups before a deploy. That´s all good and is what should be done, but the developer might not have knowledge about how the backups are run and how a backup chain works, so when they do a backup they do a full backup and are not aware that by not checking the box Copy-only database they are destroying the backup chain causing the database not being able to be restored to the latest differential backup. In the case of trouble and the database have to be restored the previous differential backup can´t be used, it will mess up the database.

Of course the full backup done before the deploy was made could be used but then the backup chain has to be setup again with an initial full backup. And if the database backup in question has been deleted after the deploy or can´t be used for any other reason then a lot of data would be lost when having to revert back to the latest full backup in the backup chain.

The solution

Always check the Copy-only backup box when doing a backup before a deploy, as shown here:

How to avoid RaiseEvent error on cache invalidation

Sun, 20 Mar 2016 16:03:06 GMT

It´s been a little over six months since I left Episerver and my job as Web Applications Engineer in the group Web Operations in Managed Services. During my time there I just couldn´t find the time to blog about some stuff that I learnt about recurring issues of many different applications written by many different partners.

I´d thought that I would write some blog posts now instead about the most frequent issues that we handled in Managed Services. This first one will cover errors occuring upon cache invalidation in load balanced environments.

Episerver CMS event system

It´s well known that Episerver has an event system that sends out messages when a page have been published so the built-in cache gets invalidated and the new content is fetched from the database. This event system is mainly used in load balanced environments or when a separate admin server has been setup.

I´m not going to dig deep into how it works since there´s a lot of blog posts and help about that, but I´ll cover the basics before addressing the issue we often saw.

The event system can use UDP or TCP but UDP is the default one and is usually the one that works best without modification. An event system is setup in the web.config.

Add this code inside the system.serviceModel tag:

<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
<extensions>
    <bindingElementExtensions>
        <add name="udpTransportCustom" type="Microsoft.ServiceModel.Samples.UdpTransportElement, EPiServer.Events"/>
    </bindingElementExtensions>
</extensions>
<services>
   <service name="EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="customBinding" bindingConfiguration="RemoteEventsBinding" address="soap.udp://239.255.255.19:5000/RemoteEventService" />
    </service>
</services>
<client>
    <endpoint name="RemoteEventServiceClientEndPoint" address="soap.udp://239.255.255.19:5000/RemoteEventService" binding="customBinding" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" />
</client>
<behaviors>
    <serviceBehaviors>
        <behavior name="DebugServiceBehaviour">
            <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
    </serviceBehaviors>
</behaviors>

Then add this inside the bindings tag:

<customBinding>
    <binding name="RemoteEventsBinding">
        <binaryMessageEncoding/>
        <udpTransportCustom multicast="True"/>
    </binding>
</customBinding>

RaiseEvent error thrown upon cache invalidation

Now to the issue and the purpose of this blog post:

The IP number with a port assigned, 239.255.255.19:5000, is a default UDP broadcast IP and can be left as is for both service and client. The only exception is if the server is hosting multiple EPiServer CMS versions, like CMS 6 R2 and CMS 7.5, then you´ll have to change the port number to 5001 (for example, it can be whatever you want) for either the CMS 6 R2 version or the 7.5 version. This is because from version 7.5 and above the broadcast messages are handled different and if both CMS versions listens to the same port number you´ll get a lot of errors thrown and the cache invalidation isn´t working properly.

These errors looks like this in New Relic and we saw up to several thousands of these errors in just a couple of hours in some applications.

Same validation key in databases

One thing that is also really important to know is that if the production database is created from a backup of the stage database they will invalidate each other’s cache since they will share the same key used for validation when a broadcast message arrives. It might not be a major issue that the stage environment for example gets its cache invalidated alongside production, but it´s good to know that it will happen and why. The only way around this is to setup a completly new database for production (or staging if you´d rather work the other way around) and do some migrating of content.