Secure by default with SSL in Windows Azure Web Sites

Hero Image

Windows Azure Web Sites (WAWS) allow your web applications to be exposed over HTTP and HTTPS. After you configure your Azure web site with an SSL certificate, by default your endpoints will be reachable over both HTTP and HTTPS. For some apps you may want to prevent the use of HTTP and require callers to always use HTTPS. How do you do this within an web app deployed to Windows Azure Web Sites?

A simple practice to promote your site’s security is to detect if a call is made over HTTP and redirect the caller to the corresponding HTTPS endpoint instead. Implementation of this mechanism in Windows Azure Web Sites requires understanding of how HTTPS is implemented in WAWS.

When a caller is making an HTTPS request to your site, the request first arrives at WAWS router based on the ARR technology. This is where the SSL connection from the client is terminated. After performing SSL handshake on your site’s behalf, ARR forwards the client request to the actual server running your application code over unsecured HTTP connection. (This is OK, since this traffic is internal to an Azure data center). However, it raises the question of how your web application can detect if the original client call was made over HTTP or HTTPS? It turns out the ARR is attaching a special HTTP request header to every request that arrives over HTTPS. The name of the header is x-arr-ssl and its value contains information about the SSL server certificate that was used to secure the TCP connection between the client and the ARR.

image

An application deployed to Windows Azure Web Sites can detect presence of the x-arr-ssl header in deciding whether to redirect client’s call to an HTTPS endpoint, or continue processing it. This approach can be implemented with any web application technology. The example below shows a simple Connect middleware for Node.js applications deployed to WAWS that allow redirecting all traffic to HTTPS endpoints:

   function ensureHttps(redirect) {  
    return function (req, res, next) {  
        if (req.headers['x-arr-ssl']) {  
            next();  
        }  
        else if (redirect) {  
            res.redirect('https://' + req.host + req.url);  
        }  
        else {  
            res.send(404);  
        }  
    }  
}
  

The middleware will detect HTTPS request and continue processing them. If an HTTP request arrives, it can be either redirected to a corresponding HTTPS endpoint, or flat out rejected with an HTTP 404 response, depending how the middleware is configured. As a rule of thumb, if the request contains sensitive information and it was received over plain HTTP, it should be rejected. Otherwise, it is OK to redirect it to a corresponding HTTPS endpoint. Here is how you can use this middleware in configuring endpoints of an Express application:

app.post('/',  
    ensureHttps(true), // This is a home page, redirect HTTP to HTTPS  
    routes.home);  
  
app.get('/account',  
    ensureHttps(false), // Authenticated endpoint, reject HTTP with a 404  
    authenticate(),  
    routes.account);

You can see the redirection from HTTP to HTTPS in action when you navigate to http://mobilechapters.com.

image

Enjoy!


ArrowPrevious
NextArrow

Most Recent

23 June 2022
Is EdgeDB the Future?

EdgeDB solves some design flaws of relational and No-SQL databases. Read the differences between EdgeDB, MongoDB, and GraphQL and the best use cases for EdgeDB.

22 June 2022
Trello API Limits, 5 Best Practices to Avoid Rate Limiting

Third-party APIs like the Trello API can make life easier for developer. We'll discuss best practices to avoid rate limits in the Trello API.

22 June 2022
Using the Google Calendar API in React.js, An In-Depth Guide

We'll build a simple React app that uses Google Calendar API and that lists and adds events to your calendar. Let’s dive in.