SharePoint 2013 App Web versus Host Web Redux

One thing I do not like about apps as they exist today is the reduced functionality of app webs compared to a normal web, e.g. a team site. To review, an app web is created as part of a SharePoint-hosted app and as part of hybrid provider-hosted app. I wrote about my complaints in more depth here: Building Traditional SharePoint Collaboration Solutions with the App Model. In that post I advocate the use of the host web as a deployment target to create a full-featured app without the restrictions found in the ghetto-web where everything is treated as a second-class citizen.

Not long after I wrote that post fellow MVP Chris O’Brien wrote this post: SharePoint apps: working with the app web, and why you should. In it he briefly discusses reasons why you might not want to deploy to the host web.

Enough time has passed and I’ve learned enough that I feel like the question is worth revisiting.

Why App Webs Exist

The app web concept really exists for one reason only – to protect the host environment from malicious JavaScript while integrating with a site collection in the host. An app web gets its security users and groups plus things like available content types and fields from the host web. If you use a tool like SharePoint Manager you can see that an app web is contained by the host site collection. The key thing is that it is on a different domain.

If the host web’s url is something like https://hostsite.sharepoint.com/ then the app web url will be something like https://hostsite-83fb00ac6b07a2.sharepoint.com/myapp.

This accomplishes two very important things:

  1. The cookies from the host web’s domain are not visible to the app web domain. This is very important because among the cookies for the host web’s domain is the user’s authentication cookie. Scripts can’t create a client context or issue REST messages against the host domain.
  2. The JavaScript code running in the pages from the app web are prohibited by default from issuing POST requests to the host domain.

Manage Web and Full Control

In my original post and in my offline conversations with Chris I pointed out that it was possible to provision to the host web as long as the app had Manage Web permissions to the host. This was true in the beta, but when the RTM bits became available, this was changed to require Full Control for any type of file that can contain JavaScript. So, you can add word documents and text files with modest app permissions, but a Web Part page or master page requires full control.

Consider that an app with manage web permissions can read every bit of content on a site, manage users and permissions, and even delete content without having full control. So, what good is full control!? What does the requirement to have full control achieve?

It protects the tenant from the following scenarios…

An Easy Way to Hack a Farm

If you have the ability to add JavaScript to a SharePoint site, you can hack your environment with a little social engineering and help from an admin. This applies to any site that allows users to add JavaScript and is the scenario that we fear most when discussing cross-site scripting exploits.

  1. Add some JavaScript that tries to do something only an admin can do, e.g. make a user a site collection or even a farm admin.
  2. Call an admin and complain about the site not working and ask them to check it for you.
  3. Use your newly granted permissions to perform evil deeds.

You should understand that this attack doesn’t require anything more than the ability to put script into a content editor web part or to edit pages in SharePoint Designer.

Another Easy Way to Hack a Farm

Install or get an admin to install a farm solution that uses RunWithElevatedPrivileges that uses the application pool identity to perform evil deeds. In many poorly configured environments this will be a domain admin.

This might sound far-fetched, but how hard would it be to put a couple cool free tools on a site like CodePlex just to phish for farms?

How the App Web Protects You

The protection and benefit of the App Web concept should now be clear to you – prevention of cross-site scripting exploits.

How you can Protect Yourself

Use separate accounts to administer your farm. Do not browse your sites using a farm or tenant level admin account.

Should I Deploy Solutions to the Host Web?

Clearly you are taking risks if you install an app that requires Full Trust and makes significant changes to the host web. Because of this, Microsoft does not allow apps that require this permission into the marketplace. If you are a vendor and you require this permission you will have to sell directly to your clients and use a side-install approach. My plan is to offer a marketplace compatible app which deploys to the app web and offer a more advanced version that is sold directly.

However, the risk you take with a Full Trust app is the same risk that you accept by using SharePoint Designer or Content Editor Web Parts, and it is less than the risk you assume by installing a farm solution. The key decision from a security perspective comes down to a simple question of trust. Do you trust the source of the app?

If the app is for internal use and you built it in-house, I see no reason to accept the fact that the app web strips so much functionality found in a host web. I feel the same way about trusted, reputable vendors.

P.S. A Note on Full Trust

You should be aware that an app’s permissions within a given context is constrained by the permissions of the user under normal circumstances. In order to escalate to a higher level of permission the app must either impersonate a known user or create the client context using an app-only policy. Full trust does not equate to constant god-mode processing.

Furthermore, an app principal always has full control over its app web regardless of its permissions on the host web. However, it is always the case that a user’s permissions constrain the app’s permissions when it is acting on behalf of a user. Even in an app web, normal code execution is subject to the user’s rights.

P.P.S. Bugs in RTM

The permissions required to perform many kinds of actions in the on-prem version are defective as of this writing. Many operations that should not require full control require full control. Office 365 works as documented. Hopefully the issues will be resolved in a hot-fix soon.

–Doug

Author: Doug Ware