Blog

OVERVIEW

Your organisation has cascading sets of people it interacts with. In the core, there are full-time employees. They have badges, access cards, accounts, organisationally-issued hardware. They use the IT-managed hardware and software to achieve their job, including a VPN to access services remotely. You create IT-managed identities, often in systems like Google G Suite or Microsoft Active Directory.

The next tranche of team members are contractors. Indeed, these users you might treat most no differently than the full-time staff. But some contractors are in specific job roles which do not require them to have IT-managed hardware or accounts. They may be specialists who work outside the building. These users might have no corporately-managed identity. Examples might include Transit drivers, Janitorial services.

After these people we have team members that are even more digitally-disconnected. Seasonal temporary workers. Temporary consultants. Workers from affiliated but arms-length organisations. In a Municipal environment these could include lifeguards for the pool, workers with the Library system, or local Social Services providers.

Traditionally these other tiers of users were ignored from an IT standpoint. Paystubs were delivered on paper, policies were posted on a bulletin board. Some organisations would use shared-accounts on Kiosk (shared) computers for online learning management systems.

Covid-19 has accelerated the thinking around these users. How can we furlough users, tell them to “check the Intranet” for details on what has changed/when they can come back to work if they have no access to the Intranet? How can we ask them to use a mail-drop for their pay stubs or timesheets if we are asking them not to come in the building?

Identity management (Authentication) and role-management (Authorisation) are the two key disciplines we need to improve if we are to solve the issue of connecting the digitally disenfranchised.

Zero Trust Architecture

A Zero Trust architecture allows us to have seamless access to any resource, from any device, for any user, from any network. And, does it more securely. Zero Trust splits the User Identity from the User Authorisation. It moves from a perimeter-based security practice to a fine-grained user & resource control.

Zero Trust (as defined by NIST SP 800-207) is a term for evolving cybersecurity from static network perimeter-based security (e.g. VPN) to an architecture that focuses on the user(identity) and the resource(authorisation).

The core requirements:

1. Simple, secure, Identity. Make it trivial for you users to login with a single username/password, single-sign-on, multi-factor authentication.
2. Decouple authorisation from Identity and from each Application.

Once these are achieved you can simply, securely, move access to individual systems to the users who need them. Those digitally disenfranchised users can access that corporate Intranet, including if their employment has been suspended, including if they have no corporate email address, device, VPN.

Evolving beyond the VPN

For many years the VPN was the gold standard of remote security. You kept your inside network isolated except for a few users with curated software on managed devices.

The VPN has a large cost. Managing the client software. It’s a stateful device, it does not scale well as we add users. It doesn’t behave well with foreign network firewalls. But, and most importantly in 2020, it nearly completely breaks remote collaboration tools. A VPN forces all traffic through the corporate network. So your video conferencing flows from your home to your company, and then back out to the Internet to the other people. In this model the corporate network becomes a choke-point: rather than scaling as you add staff, your performance drops off, the productivity goes down. Work from home has accelerated this problem.

The VPN also was masquerading as a secure solution. Years ago every server had a well-known port and IP. VPN rules, in conjunction with a firewall, were written to try and segment, isolate all pairwise communication. Now that users are remote, mobile, we cannot know their IP. Some services have moved to SaaS and cloud, the IP is unknowable. Many organisations now have little or no network segmentation. The VPN has become a giant on-off switch rather than a precision allow/deny method. Once you VPN in, you are infinitely trusted, the opposite of zero-trust.

Zero Trust provides a means for each connection to assert who its from, and to what it is going, with what requirements. This can be policed in a very fine grained fashion without the bandwidth or security challenges of the VPN. Treat each application as if it were on the public Internet, then secure it, no VPN is needed.

Identity Evolved, Multi-Factor Authentication Simplified

Identity is core to a person. They are the same person whether they use USER@gmail or USER@corp to identify themself. A core method of simply demonstrating identity is OpenID Connect. This secure, web-based protocol works with all devices. It is simple enough for the average consumer to use. You often see it as “Login with Google” or “Login with Facebook”.

In conjunction with OpenID Connect, we propose federating multiple sources of Identity. These can include affiliated organisations (the Library, the Police), or social providers (Google, Facebook, Twitter).

To confirm identity we propose ubiquitous, simple, multi-factor authentication. In a corporate world these are often done with RSA SecureID fobs, or USB Universal 2nd Factor devices like YubiKey or Google Titan.

In this newly expanded Identity world these become expensive and complex. We propose instead using a device that all users have easy access to: their mobile phone.

A mobile phone can support Web Push: the user will receive a push notification on their registered device “Is this you trying to login”. It can support Authenticator Apps (Twilio’s Authy, Google Authenticator, Microsoft Authenticator, etc) with QR-codes and PIN numbers. But, more interestingly, with the WebAuthN standard, it supports biometrics. This allows users to login securely, simply, with a fingerprint or face blink, in conjunction with the device they registered.

To reduce or eliminate the provisioning cost we propose Trust-On-First-Use: the user is challenged to set up their multi-factor authentication the first time they login. This reduces risk, increases security, without increasing cost.

Multi-factor, something you know with something you have, achieved, for no cost. Simple enough for a consumer. Strong enough for the corporation.

Identity-Aware Web Application Firewall

Each application has an intrinsic set of roles (admin, teacher, student, …). Adding a web-application firewall in front means we can police this access, using the identity of the user in conjunction with the identity of the application. Without configuring a complex Layer-3&4 firewall. Without introducing a VPN.

The Web Application Firewall will then increase the security of the application by reducing common risks such as Cross-Site-Scripting, SQL Injection. The end result is more secure than the previous corporate-firewall-vpn-enclave. And simpler.

Recommendation

Every organisation has more users than they would believe who they need to securely interact with. It is uneconomical to treat them all as full time employees.

Using a Zero Trust architecture, securely solving Identity including 3rd party Identity providers federated in, with simple, secure multi-factor authentication, and adding an external Identity-Aware Web Application Firewall can break the log jam.

Make any application available to any user on any device, on any network today. Without a VPN. And increase your security while doing so.

Cookies are a method by which a web server can convince a web client to remember, and return, some information. It’s technically a violation of the web since the HTTP protocol is intended to be idempotent. Some also consider it a violation of privacy.

However, in this video we are not going to take a position on the good/bad/ugly of cookies. Instead we are going to focus on how to use them securely.

First, let’s understand how long it will live. Cookies have a `expires` and `max-age` attribute. If you set either of these (to some time in the future), the cookie will survive a browser restart (a persistent cookie). If you don’t set it, it becomes a session cookie.

So, we’ve just learned our first lesson: the more sensitive the data, the shorter the expiry should be to limit the damage.

Second, let’s learn about the `secure` flag. How great is it to make security be a Boolean! Well, it’s not that great here. The Secure flag means ‘do not send unencrypted’ (in practise, only send over HTTPS). So we’ve learned our second lesson: always use Secure. No excuses!

Third, let’s talk about the httpOnly flag. Well this is a weird one, its all HTTP right? Well, it turns out they mean more HTML-only. If httpOnly is set, we cannot read the cookie from JavaScript. You want this, it prevents Cross-Site-Scripting (XSS) type attacks where rogue JavaScript snoops around. If you have JavaScript that needs to read cookies, maybe try and solve that. Now, the httpOnly flag is not an absolute, there is a type of attack called Cross-Site-Tracing (XST). Purists will tell you to disable the TRACE method on your web server.

Not content w/ httpOnly and Secure, the cookie committee created the SameSite flag.  Sometimes called First-Party cookies it allows a server to reduce the impact of a Cross-Site Request Forgery (CSRF) attack by forcing a cookie to only be sent with requests from the same domain. Not universally implemented, somewhat newer, support is still strong. Do your best to set this to ‘strict’. If you find that your POST fail, and you cannot fix your application, have a long discussion with yourself about `lax`.

OK, that must be it, right. Wait, there’s more? The HostOnly flag specifies if a cookie can be used on subdomains. If you are doing single-sign-on across multiple sites, you want this set to the domain. For individual web applications, you likely want the domain field blank. A cookie with a domain attribute controls where it will be sent.

Seem complex? Just do this:

• Don’t use cookies unless you must
• Don’t set expiry, or use a very short one
• Use httpOnly always
• Use Secure always
• Use SameSite strict unless you can’t
• Leave domain empty unless used for single sign on

If you want to see an example of how you could use Lua OpenResty, a Web Application Firewall, to add some after-the-fact-security, have a look below!

local headers = ngx.req.get_headers()
if headers["x-forwarded-proto"] == "https" then
  local ck = require "resty.cookie"
  local cookie, err = ck:new()
  local fields, err = cookie:get_all()
  if fields then
    for k, v in pairs(fields) do 
      local ok, err = cookie:set({ 
        key = k, 
        value = v, 
        path = "/", 
        httponly = true, 
        secure = true, 
        samesite = "Strict" }) 
    end
  end
end

Last year I met this web application. Let’s call it Hank. Hank was pretty, but not that smart. In particular, Hank was very prone to trusting what user’s told it. Earlier we learned about how Hank would just trust what a user entered, and then later use that against others. But that is not what we are talking about today. Today we are talking about how Hank would let a user modify some data and become an administrator.

You see, the browser is a funny world. It tries very hard to protect its user from the threats that lurk on the web. But, it’s also not very trustworthy itself. Any user can modify data in it. You can’t have secrets, you can’t trust fields. You can’t have some variable ‘admin=true’ and expect the user to just behave.

In Hank’s case it used a login method called OpenID Connect. Yes the very same one I’m a big fan of. But, Hank skipped some classes and used the Implicit Flow instead of the PKCE flow. Bad Hank. This would be fine if Hank just used the authentication and passed the token as-is to the back-end, but, Hank used some fields in the ID Token to indicate role (e.g. admin vs end-user). Worse, Hank’s back-end used the same fields but did not validate the ID Token. So a user could login, modify the resulting info, and pass it back to the back-end and become an admin. Naughty Hank!

Now the correct solution here is sometimes called the 3-legged flow. In this model, the front end (the browser), sets up and finishes the login flow, but, the last step is it shares a code w/ the back-end which then goes and fetches from the authentication and retrieves the token. In this model we have a protected code base and can have secrets, we would often cipher the result and make a session cookie, making it impossible to modify in the front-end.
So, how would you solve this? Send Hank in for some code surgery? That would be the best. But what if you don’t have the time or money? Can you let Hank loose on the Internet?

Sure you can! The fix was complex, but, in the Web Application Firewall we intercepted the response to the back-end that had the fields in it that were prone to modification. Using the Access Token that Hank supplied, we then went and fetched the real values (in this example the user role), overwriting what the user supplied. We then ciphered with something the user doesn’t have access to (since its in the back-end), and returned it as a cookie. Later, on other requests, we would translate it back for the back-end.

Fully transparent, fully secure. Now that you’ve read the story of Hank, I hope that you will read your OpenID Code Flows and look closely at PKCE or 3-legged. Don’t allow critical information to be modified in the browser and just trusted in the backend. Trust, but verify. Defense in Depth. Assume the browser is broken. Its just easier that way.

As for the workaround in the Web Application Firewall? First we make the observation that we have already confirmed the validity of the Bearer token. Then, we put in a rule like this:

local auth_header = ngx.req.get_headers()["authorization"]
local str = require "resty.string"
local aes = require "resty.aes"
local ck = require "resty.cookie"
local cookie, err = ck:new()
local aes_256_cbc_sha512x5 = aes:new(session_secret, nil, aes.cipher(256,"cbc"), aes.hash.sha512, 5)
local encrypted = aes_256_cbc_sha512x5:encrypt(auth_header)
-- str.to_hex(encrypted),
local ok, err = cookie:set({
  key = "agilicus_token",
  value = ngx.encode_base64(encrypted, true),
  path = "/",
  httponly = true,
  secure = true,
  samesite = "Strict"
})

Later we use that encrypted cookie overriding what the user can provide. We also do an east-west call (replicating what the browser did and trusted), but in the back-end where they cannot modify:

local http = require "resty.http"
local httpc = http.new()
local auth_header = ngx.req.get_headers()["authorization"]
-- Initialise response to 500, override if we logout
ngx.status = 500
if auth_header then
  ngx.say("Error: cannot log out, Host or Authentication header is not set")
else
  local domain = x.."."..y.."."..z
  local uri = "https://auth."..domain.."/token/revoke"
  local token = string.match(auth_header, "[^ ]+ (.*)")
  local res, err = httpc:request_uri(uri, {
  method = "POST",
  body = "token="..token.."&token_type_hint=access_token",
  headers = {
    ["Content-Type"] = "application/x-www-form-urlencoded",
  },
  keepalive_timeout = 1,
  keepalive_pool = 1
})
if not res then
  ngx.say("Failed to revoke access token on "..uri.." : ", err)
else
  ngx.status = res.status
  ngx.say(res.body)
end
end

HTML and Web Applications are the dominant applications of our time. HTML was originally designed as a read-only documentation format and over time became rich, interactive. Many popular web applications today accept user-generated content (comments, images, etc.) and then display to other users.

In addition, as the web has become more complex, sites have adopted libraries from many 3rd parties, including ones which dynamically choose content such as advertisements and news feeds.

When you mix these things together you create risk. A user, entering their credit card into a travel-site to buy something alongside an advertisement, presented via JavaScript coming from a CDN, and community comments, is a recipe for security disaster. And yet, it’s the norm.

Many different tools address this challenge, but today we will talk about the most powerful (and most complex), Content-Security-Policy.

Content-Security-Policy is a header that a web site emits, instructing the browser what to allow and deny, broken down by type (fonts, CSS, images, etc), and by domain (self, inline, other websites).

A strong, secure Content-Security-Policy will only allow `self`. This means that we allow nothing hosted anywhere other than the source web server. However, this is not very realistic, it prohibits e.g. Google Analytics, fonts served from a CDN, etc. Previously I showed how to use Google Tag Manager with Content-Security-Manager.

The risks you protect against with a strong Content-Security-Policy include unsafe 3rd party code evaluating (running) in the page model of the browser for your web page. Some pages are more sensitive than others (login pages, form submittals). However, with modern applications,  a session cookie or a JSON Web Token (JWT) representing the login and permission, are available on all pages: we need the Content-Security-Policy to be strong on all pages.

A hybrid between `self` and named sites is called subresource-integrity. The browser checks a signature of the content, executing it only if matched. This is far more flexible than trying to estimate all possible sources of 3rd party content. However, it can be challenging to set up since all libraries must support it.

If possible, use either `self` or subresource-integrity for all types. Block `object`. Do not allow `unsafe-inline` or `unsafe-eval` or `data:`.

If you have an Angular application, I recommend compiling it as

ng build --aot --subresourceIntegrity --outputHashing=all --prod=true

An excellent resource to assess your Content-Security-Policy is the Mozilla Observatory.

If you own and operate a web application, whether it be a static site like WordPress, or an e-commerce site, you must setup your Content-Security-Policy. No exceptions. Your customers fate rests in your hands, be responsible.

The Web Application Firewall (or WAF) is a firewall that operates at the Web (HTTP) layer of your application. It blocks common classes of errors that exist in web-based applications. It is useful to prevent zero-day attacks, to give you more time to apply patches, and as a general Defense-In-Depth strategy.

The main protection it gives is generic for:

• Cross-Site Scripting (XSS)
• SQL Injection
• Web Session Hijacking

All while not changing the application source code.

If you operate a web application (you operate the webserver), you should use a web application firewall if:

• The application is not read-only (it accepts user input)
• It accepts or displays 3rd-party content
• It accepts or displays user-generated content
• It has an API
• The user can authenticate
• The webserver is anything other than a simple Nginx or Apache server with static content (for example, you run Java or ASP or PHP)
• The webserver has access to any internal content such as a database or shared filesystem

Your Web Application Firewall should always be in use. It should have rules calibrated to each path and method call (for example, only authenticated users can POST to /api/updates). Setting up these rules can be complex and requires knowledge of how the application functions. Do not just accept the defaults and hope! If you have input to the design of the Web Application, follow these rules to simplify securing it:

1. Put static content (images, css, html, javascript) in a single path (e.g. /assets)
2. Avoid using self-modifying CSS and HTML (don’t require unsafe eval or inline)
3. Have a common location in the API schema for the user-id
4. Compile templates ahead of time
5. Avoid using 3rd-party libraries and content hosted by external sites
6. If you do use 3rd-party hosted, use subresource integrity

An unexpected and positive side-effect of the web application firewall is simplified and enriched reporting into your security event logging.

If you operate a web application, the web application firewall gives you peace of mind, simply, with low cost. It doesn’t replace writing secure applications, it augments.