SharePoint Config

Public facing SharePoint websites often contain a combination of content that is publicly available, and sensitive content that should only be shown to authenticated users (e.g. personal details like email, address and other account information). While SSL provides a mechanism for delivering the sensitive content over a secure connection it also has a performance overhead. This often results in a requirement to partially secure the site using SSL/HTTPS, but deliver the remainder of the site via HTTP. This is the first in a series of posts that show how you can accomplish this scenario using SharePoint. The steps that will be covered are:

1. Configuring a SharePoint web application to allow SSL connections.
2. Enforcing the correct protocol (HTTPS for displaying and sending sensitive data, HTTP for non-sensitive information).
3. Logon over HTTPS from HTTP pages.
4. Securing the authentication cookie.

Before getting into the details it is worth reviewing how data is transferred at the transport layer when we use forms authentication so we can understand what we need to secure. The following steps show what data would be transferred if we were using an out-of-the-box publishing portal using forms based authentication without SSL.

1. Requesting a page

When you browse to a page such as the homepage the browser sends a GET request as shown below:

GET /Pages/default.aspx HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application […]
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; […]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.company.com
If-Modified-Since: Mon, 08 Mar 2010 15:50:30 GMT

If the request was successful you would see a response similar to the one below:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Mon, 22 Feb 2010 18:35:35 GMT
Last-Modified: Tue, 09 Mar 2010 18:35:35 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Tue, 09 Mar 2010 18:36:08 GMT
Content-Length: 23617

<encoded HTML response>

So far so good, nothing particularly confidential that is essential to secure here. If you want to know more about what these all mean I’d suggest reading the article “What really happens when you navigate to a URL”. A more interesting scenario is when we are sending information such as when we enter our login credentials and click Login (the example below is using the ASP Login control on a publishing page).

2. Submitting a login request

In this case the browser sends out a POST request that contains the contents of the input controls within the form that is being submitted. In the case of a SharePoint page there are a large number of controls so I’ve removed the ones we aren’t interested in the example request below:

POST /Pages/login.aspx HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application […]
Referer: http://www.company.com/Pages/login.aspx
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; […]
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: www.company.com
Content-Length: 2819
Connection: Keep-Alive
Pragma: no-cache

__SPSCEditMenu=true
&MSOWebPartPage_PostbackSource=
&__REQUESTDIGEST=0xCB[…]
&__VIEWSTATE=%2F[…]
&ctl00%24ctl12%24g_72f08516_e11c_43f6_935a_7e9308c7b55d%24ctl00%24UserName=spuser
&ctl00%24ctl12%24g_72f08516_e11c_43f6_935a_7e9308c7b55d%24ctl00%24Password=pass@word1

We can see here that we are sending the username and password in clear text. This obviously needs to be secured, otherwise anyone who can see this information as is travels from your browser to the server will be able to see this in the clear.

If the login request is successful we would see a response similar to the one below from the server:

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 25200
Content-Type: text/html; charset=utf-8
Location: /Pages/default.aspx
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
Set-Cookie: .ASPXAUTH=34ED30EB80078109D439825F1F76D7[…]; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 09 Mar 2010 18:54:54 GMT

The important information here is the Set-Cookie statement with the .ASPXAUTH value. The .ASPXAUTH cookie is used by ASP.NET to authenticate a user, and will be passed to the server for every subsequent page request until the user logs out or the cookie expires. So if we were to take the .ASPXAUTH cookie value and set it on another machine we would then be logged in as that user! This is obviously another important piece of information we need to secure.

For example if we make a request to the homepage after we have logged in a request similar to the following would be sent.

GET /PressReleases/Pages/default.aspx HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, […]
Referer: http://www.company.com/Pages/default.aspx
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; […]
Accept-Encoding: gzip, deflate
Host: www.company.com
Connection: Keep-Alive
Cookie: .ASPXAUTH=34ED30EB80078109D439825F1F76D7[…]

We can see the .ASPXAUTH cookie being sent to authenticate us with the server for this request. Assuming the cookie hasn’t expired if an attacker could steal this information they could replay this request from a different machine and steal the identity of the user that is logged in.

SSL Configuration Options

There are a number of ways to configure SSL and we won’t cover them all in detail. The simplest (from a configuration point of view) and most secure would be to put the entire site under SSL. This would work well for many extranet scenarios where most if not all the content is sensitive and needs to be secured. This might also work well for public facing internet sites where almost all the content requires the user to be logged in, but for many sites where there is a mix of sensitive and non-sensitive information this isn’t ideal. This partially SSL secured scenario is the one that will be covered here.

Additionally when setting up SSL you have the option of terminating the SSL connection at the firewall level or on the SharePoint/web server itself. For performance reasons it is advantageous to terminate the SSL connection at the firewall so if your firewall supports it this is the recommended approach. If it isn’t possible, or you want to replicate the SSL settings in development and/or test environments you will need to place an SSL certificate on the SharePoint/web server and configure redirection at the IIS level. These steps will be covered in the following posts.

Stay tuned.