Create a Secure Intranet Web Application

In my last post, my aim was to provide value to IT administrators supporting their intranets and discuss how to optimize performance, covering topics around browsers, server hardware and configuration options available to you within the Intranet Connections platform. Continuing along that path, I would like to cover security, the common vulnerabilities found in web applications and the features available to you within Intranet Connections, including how to address these.

Last week, I had an interesting conversation with a prospective intranet customer who broached the subject of securing our intranet web application and asked how we address known web application security threats as published in the top 10 list from the Open Web Application Security Project (OWASP). So, lets’ do a broad overview of the tools available to you to protect your intranet and the important data it houses.

Intranet or Extranet

An important point to cover is whether your intranet is exposed to the internet. Some of our customers do allow access to the internet for mobile employees without the requirement of a VPN or equivalent connection to their LAN. In this scenario, it is much more important that you consider how you configure access to your server and what security features to implement. If you’re completely behind a firewall, clearly you will be much more protected than if you’ve opened up to the web.

Stay Updated for a Secure Intranet

The first thing to look at which is completely in your control is making sure you’re not open to known vulnerabilities in the software pieces used to run your intranet. Are you on a modern OS (2012 R2) or at least the very latest service pack with Windows Updates occurring routinely? Similarly, with your database server, is SQL up to date? Intranet Connections can comfortably run on SQL 2014 Express with roughly half of our customers running Express editions of SQL.

Is your application server up to date? Do you use SSL encryption to protect your client/server traffic? If yes, are you using a 256-bit Secure Sockets Layer (SSL) certificate? Most browsers will begin reporting to end users sites with less secure connections (128-bit). Finally, on the client side, make sure you are applying security updates and upgrading browsers regularly.

Keep Intranet Intruders Out

Intranet Connections supports two authentication mechanisms, built-in Windows Authentication and Form authentication. You can enable both (mixed mode) or one, and you can also select whether you want to allow anonymous access (Site Secure option). If you only want people with valid Windows credentials, then make sure you configure it that way in the product and in the Internet Information Server (IIS).

If you do want to make use of Form logins, make use of the features available to prevent session hijacking, password guessing, brute force attacks, dictionary attacks, and so on. You can implement strong passwords, password expiry, CAPTCHA on login, lock out for repeated failed logins, session IP checking, and short session timeouts, all of which can be done on the administration screen under the Security section on your intranet.

By design, Intranet Connections securely encrypts all stored passwords, rotates sessions on login, and checks the validity of sessions on every request. With session cookies, Intranet Connections also make sure they are only accessible over HTTP (not JavaScript), are secured if operating over SSL, and only exist throughout the session of the browser (deleted upon closing the browser).

External to your intranet web application, make sure you also use strong passwords for your SQL logins and application server logins. These typically come with stock passwords and it would be prudent to alter them for your environment. If you do, make sure you update your datasource so the application can connect with the database, and keep track of your passwords somewhere safe internally. The last thing you want to do is bring down your intranet accidentally!

Manage Access for a Secure Intranet

In general, permissions are granted based on roles (elevated rights) for users, or standard view/add/update/delete permissions for content. In terms of roles, users can be assigned rights such as administrator, site designer, profile manager, site owner, or app owner. These are typically easy to understand and grant you rights to fully manage content at a particular level or within a given area. Content is generally organized in folders (or categories) inside applications under a given site. This hierarchy allows you to granularly control the standard CRUD (create, read, update, delete) actions at any given level. When assigning these permissions, you can always target individual users or groups, which often makes administration easier.

The configuration for the logged in user is checked on every application server request to ensure no indirect access can be obtained to sensitive data you have secured. Items such as Mega Menus, navigation links, widget content, or folders that a user does not have access to will not be presented to a user at all.

One extra feature you many want to implement is the File Migration Utility under security. By default, the intranet will upload files within the web root. If you want to prevent direct access you can use this to begin storing your uploaded files somewhere else (e.g. separate drive, SAN) and force file access to occur through a secure application server request within Intranet Connections, which has the aforementioned security checking layered on top.

Working Together to Keep You Secure

New threats crop up every year requiring action on public websites, in some instances these trickling into the intranet space. In addition to our own internal testing, our valuable clients have run penetration tests on their intranets and have kindly shared these results with us. This has been valuable feedback for us, helping us strengthen the security features in Intranet Connections.

Intranet Connections is focused and concerned with the creating a secure intranet for our customers. We proactively test and work with our customers to stay on top of potential vulnerabilities. By doing your part, keeping your servers up to date and following best practices for application security you can create a secure intranet. As always, we do our part to build protection into Intranet Connections for a secure intranet any way we can. If you have any questions surrounding the security and features discussed, please comment below.

Discover the guide to a simple intranet and simple intranet management.