DEV Community: Charlotte Fereday

Authentication and Authorisation 101

Charlotte Fereday — Sat, 16 Jan 2021 18:18:39 +0000

This blog post was originally published in Tes Engineering blog here.

Last year I gave a talk at a Node Girls and Women of Security
meetup to share a few things I have learned about authentication and authorisation since joining our Security Engineering team at Tes.
You can see the video of this talk here.

This post summarises some of the key points made during the talk, alongside some sketch notes and code snippets from an example app.

Authentication and authorisation both relate to the concept of identity. Though the words are similar their meanings are different. Let’s explore how...

Authentication

At the most basic level, we can say that authentication is the process of checking the identity of a user: are you who you say you are?

The most common place that authentication is used is the Login Page of an application. During login user entered credentials are checked against what we have stored in the database. This allows us to verify that we know and trust a user is who they say they are, via, for example, a username and a password.

Although the concept of authentication is straightforward, the technical process of its implementation is typically complex, because it’s absolutely vital to keep users’ data secure. For this reason, many companies opt to use a third party company, for example Google or Auth0, to handle the authentication process for them.

Some companies choose to implement authentication themselves. Here are a couple of golden rules if you go down this route.

Rule 1: Only a customer should know their password

Keeping secret data secure is vitally important for any company to protect their users and their reputation. We want to mitigate against the risk that even if a bad actor got access to a database, they would never get a plain text password. The safest strategy to prevent this is to not store the plain text password at all.

One solution is to hash passwords to carry out a ‘one way’ transformation which turns turns a plain text password into an unrecognisable string. We can use one way encryption to verify the password whilst making it very difficult for a bad actor to transform it to its original plain text value.

We can safely hash passwords by using well maintained and recognised open source libraries, such as bcrypt library. Here’s an example code snippet using the bcrypt library to hash a password before storing it, to keep user credentials safe.

Rule 2: Always validate user input before using it

One of the most common places for an attack on an application is the Login page. Injection or hijacking attacks can aim to make our code do something we did not tell it to do, by sending an instruction where we would expect some user-entered data or credentials.

Never trust the user input to safeguard applications, but rather always validate and transform data before using it.

Again a widely used open source validation library like Joi can help you easily create schemas and transform the data into safe objects.

Authorisation

After a user has been authenticated, we can move onto checking what resource they are authorised to access. It's important to control who-can-access-what to protect data, reputation and revenue.

We can use roles to indicate whether or not a user should have access to a resource. For instance, only an administrator should be able to access the admin page, or only a particular client has access to a specific endpoint.

JSON Web Tokens(JWT)

Json Web Tokens (JWT) help to implement authorisation.
JWT is an open standard that defines a way to securely transmit information between parties as a JSON object.

We can trust this information because it is digitally signed and verified by server-side code.
It helps authorisation systems scale, to ensure only those authorised have access to particular resources, and protect private personal data.

Sign

A JWT is digitally signed with a secret or a public/private key pair that is only known to an application. This means an application can ensure that the JWT was signed from a trusted source (via said secret or corresponding public key) and prevents it from being secretly tampered with.

Here’s an example of using the jsonwebtoken library to sign a JWT where it is then added to a cookie.

Role data is included as part of the JWT, for instance in this example if the username is ‘admin’ then this user gets an ‘admin’ role. Clearly this management of roles is a hack for a toy project, in a real secure system there will be more sophisticated ways of managing admins.

Verify

Once we have a JWT, we can verify that the token is valid on our servers, and only trust it if the JWT hasn’t been tampered with or expired.

The jsonwebtoken library allows us to digitally verify a user or client and effectively manage whether they should have access to a particular resource.

Summary

Aside from learning more about authentication and authorisation, the aim of this blog is to show that as engineers we can learn a few good security practices and have access to many open source libraries to help us build more secure applications.

Writing secure code is absolutely critical for our users - you don’t need to be a security expert to get started.

If you’d like to learn more about some of the topics touched on here, I've listed below some articles that I found useful.

JavaScript Security 101

Charlotte Fereday — Mon, 07 Dec 2020 08:22:00 +0000

This blog post was originally published in Tes Engineering blog here.

I recently completed the JavaScript Security: Best Practices course by Marcin Hoppe and wanted to share some key practical take aways I learnt on how to write more secure JavaScript.
As well as reading this blog, I'd also highly recommend completing the course. It's short and sweet and hands on!

JavaScript Threat Environments

It's worth noting that there are two different threat environments: client-side JavaScript vs server-side JavaScript. For client-side JavaScript the browser operates on a low trust & highly restricted basis, necessarily so because it works with JavaScript from uncontrolled sources by virtue of users navigating the web.
In comparison for server-side JavaScript Node.js works on a high trust & privileged basis, because it's a controlled source (i.e. Engineering teams have written the code) and it doesn't change during runtime.
There's a more detailed summary of these differing threat environments in the Roadmap for Node.js Security, and it's important to keep this difference in mind when writing JavaScript.

The dynamic nature of JavaScript on the one hand makes it incredibly versatile, and on the other creates a number of security pitfalls. Here are three key pitfalls in JavaScript and how to avoid them.

1. Comparisons & conversions abuse

TLDR;
JavaScript has a dynamic type system which can have some dangerous but avoidable consequences. Use the JavaScript Strict mode to help avoid pitfalls such as loose comparison.

Some examples...

NaN, Null & undefined

Automated conversions can lead unexpected code to be executed:

console.log(typeof NaN) // number
console.log(typeof null) // object
console.log(typeof undefined) // undefined

For example, this calculatingStuff function relies on the input being a number. Without any validation to guard against the input being NaN, the function still runs because NaN is classed as a number.

const calculatingStuff = (num) => {
  return num * 3;
};

console.log(calculatingStuff(NaN)) // NaN

It's important to have guard clauses and error handling in place to avoid unexpected behaviour in automated conversions. For instance in this version of calculatingStuffv2 we throw an error if the input is NaN.

const calculatingStuffv2 = (num) => {
if (isNaN(num)) {
  return new Error('Not a number!')
}
  return num * 3;
};

console.log(calculatingStuffv2(NaN)) // Error: Not a number!
console.log(calculatingStuffv2(undefined)) // Error: Not a number!
console.log(calculatingStuffv2(null)) // 0
console.log(calculatingStuffv2(2)) // 6

The isNaN() also guards against undefined, but will not guard against null. As with everything in JavaScript, there are many ways you could write checks to guard against these NaN, null and undefined.
A more reliable approach to "catch 'em all" is to check for truthiness, as all of these values are falsy they will always return the error:

const calculatingStuffv2 = (num) => {
if (!num) {
  return new Error('Not a number!')
}
  return num * 3;
};

console.log(calculatingStuffv2(NaN)) // Error: Not a number!
console.log(calculatingStuffv2(undefined)) // Error: Not a number!
console.log(calculatingStuffv2(null)) // // Error: Not a number!
console.log(calculatingStuffv2(2)) // 6

Loose comparison

Loose comparison is another way code could be unexpectedly executed:

const num = 0;
const obj = new String('0');
const str = '0';

console.log(num == obj); // true
console.log(num == str); // true
console.log(obj == str); // true

Using the strict comparison === would rule out the possibility of unexpected side effects, because it always considers operands of different types to be different.

const num = 0;
const obj = new String('0');
const str = '0';

console.log(num === obj); // false
console.log(num === str); // false
console.log(obj === str); // false

2. Injection attacks from dynamically executed code

TLDR;
Be sure to always validate data before using it in your application, and avoid passing strings as arguments to JavaScript functions which can dynamically execute code.

Some examples...

eval()

As described in the mdn docs eval 'executes the code it's passed with the privileges of the caller'.

This can become very dangerous if, for example, eval is passed an unvalidated user input with malicious code in it.

eval('(' + '<script type='text/javascript'>some malicious code</script>' + '(');

Unsafe variants of browser APIs

Both setTimeout & setInterval have an optional syntax where a string can be passed instead of a function.

window.setTimeout('<script type='text/javascript'>some malicious code</script>', 2*1000);

Just like the eval() example this would lead to executing the malicious code at runtime. This can be avoided by always using the passing a function as the argument syntax.

3. Attacks from Prototype pollution

TLDR;
Every JavaScript object has a prototype chain which is mutable and can be changed at runtime. Guard against this by:

Freezing the prototype to prevent new properties being added or amended
Create objects without a prototype
Prefer Map over plain {} objects

Some examples...

Here's an example where the value of the toString function in the prototype is changed to execute the malicious script.

let cutePuppy = {name: "Barny", breed: "Beagle"}
cutePuppy.__proto__.toString = ()=>{<script type='text/javascript'>some malicious code</script>}

A couple of approaches to mitigate this risk is to be careful when initiating new objects, to either create them removing the prototype, freeze the prototype or use Map object.

// remove
let cutePuppyNoPrototype = Object.create(null, {name: "Barny", breed: "Beagle"})

// freeze
const proto = cutePuppyNoPrototype.prototype;
Object.freeze(proto);

// Map
let puppyMap = new Map()
cutePuppyNoPrototype.set({name: "Barny", breed: "Beagle"})

Prototypal inheritance is an underrated threat so it's definitely worth considering this to guard against JavaScript being exploited in a variety of ways.

Tooling

Finally, beyond being aware of these pitfalls of JavaScript, there are a number of tools you could use to get early feedback during development. It's important to consider security concerns for both JavaScript that you have written, and third party JavaScript introduced through dependencies.

Here are a few highlights from some great Static code analysis (SAST) tools listed in Awesome Node.js security & Guidesmiths Cybersecurity handbook.

In your code

Always use strict development mode when writing JavaScript
Use a linter, for example eslint can configured to guard against some of the pitfalls we explored above by editing the rules:

"rules": {
  "no-eval": "error",
  "no-implied-eval": "error",
  "no-new-func": "error",
}

Use a security plugin in your text editor, for example eslint-plugin-security

In your JavaScript dependencies code

Use npm audit to check for known vulnerabilities
Use lockfile lint to check changes in the package-lock.json which is typically not reviewed
Use trust but verify to compare an npm package with its source repository to ensure the resulting artifact is the same

Asynchronous JavaScript 101

Charlotte Fereday — Mon, 23 Nov 2020 16:57:50 +0000

This blog post was originally published in Tes Engineering blog.

Here is a short recap of some fundamentals of using asynchronous JavaScript with some practical examples.

Why do I need to use asynchronous code again?

JavaScript by its nature is synchronous. Each line is executed in the order it appears in the code. It’s also single threaded, it can only execute one command at a time.

If we have an operation that takes some time to complete, we are effectively blocked waiting for it. A couple of common scenarios where this could happen are calling an API and waiting for a response, or querying a database and waiting for the results. Ultimately the impact of this is a slow and frustrating user experience, which can lead to users dropping off your website.

Asynchronous programming offers a way to bypass the synchronous single threaded nature of JavaScript, enabling us to execute code in the background.

Promises

Promises enable asynchronous programming in JavaScript. A promise creates a substitute for the awaited value of the asynchronous task and lets asynchronous methods return values like synchronous methods. Instead of immediately returning the final value, the asynchronous method returns a promise to supply the value at some future point.

Let's look at a couple of common ways of implementing Promises. The sample code is extracted from a toy project Security Dashboard I’m working on, more here for the curious.

Chained Promises

const fetchLatestDevToNewsPromiseChaining = () => {
  return fetch('https://dev.to/api/articles?per_page=5&tag=security')
    .then(response => response.json())
    .then(latestArticles => keyDevToInfo(latestArticles))
    .catch(err)
};

JavaScript’s built in Fetch API returns a promise object which we can then ‘chain’ promise methods on to, in order to handle the response.

.then() passes the return value of its callback to the function in the subsequent .then(), whilst .catch() handles a rejected promise. We can keep ‘chaining’ on more handling of the results by adding more promise methods.

Async / await

const fetchLatestDevToNewsAsyncAwait = async () => {
  try {
    const response = await fetch("https://dev.to/api/articles?per_page=5&tag=security")
    const latestArticles = await response.json()
    return keyDevToInfo(latestArticles)
  } catch (err) {
    return err
  }
}

The other common approach is to use async / await. We use the keyword async on the function declaration and then await immediately before the request to the API. Rather than using the promise methods to handle the response, we can simply write any further handling in the same way as any other synchronous JavaScript.

As we’re not using promise methods here we should handle any rejected promises using a try / catch block.

What you’ll notice in both cases is that we don’t need to literally create the Promise object: most libraries that assist with making a request to an API will by default return a promise object. It’s fairly rare to need to use the Promise constructor.

Handling promises

Whether you’re using chained promises or async / await to write asynchronous JavaScript, a promise will be returned, and so when calling the function wrapping the asynchronous code we also need to settle the promise to get the value back.

There are some ways these can be handled via built in iterable methods from JavaScript, here are a few very handy ones for settling results of multiple promises:

Promise.all

Promise.all([fetchLatestDevToNewsPromiseChaining(), fetchLatestDevToNewsAsyncAwait()])
  .then(([chained, async]) => {
    createFile([...chained, ...async])
  })

Promise.all is a good option for asynchronous tasks that are dependent on another. If one of the promises is rejected, it will immediately return its value. If all the promises are resolved you’ll get back the value of the settled promise in the same order the promises were executed.

This may not be a great choice if you don’t know the size of the array of promises being passed in, as it can cause concurrency problems.

Promise.allSettled

Promise.allSettled([fetchLatestDevToNewsPromiseChaining(), fetchLatestDevToNewsAsyncAwait()])
  .then(([chained, async]) => {
    createFile([...chained, ...async])
  })

Promise.allSettled is handy for asynchronous tasks that aren’t dependent on one another and so don’t need to be rejected immediately. It’s very similar to Promise.all except that at the end you’ll get the results of the promises regardless of whether they are rejected or resolved.

Promise.race

Promise.race([fetchLatestDevToNewsPromiseChaining(), fetchLatestDevToNewsAsyncAwait()])
  .then(([chained, async]) => {
    createFile([...chained, ...async])
  })

Promise.race is useful when you want to get the result of the first promise to either resolve or reject. As soon as it has one it will return that result - so it wouldn’t be a good candidate to use in this code.

So ... should I use chained promises or async / await?

We’ve looked at two common approaches for handling asynchronous code in JavaScript: chained promises and async / await.

What’s the difference between these two approaches? Not much: choosing one or the other is more of a stylistic preference.

Using async / await makes the code more readable and easier to reason about because it reads more like synchronous code. Likewise, if there are many subsequent actions to perform, using multiple chained promises in the code may be harder to understand.

On the other hand, it could also be argued that if it’s a simple operation with few subsequent actions chained then the built in .catch() method reads very clearly.

Whichever approach you take, thank your lucky stars that you have the option to avoid callback hell!

Visualising documentation: JavaSript array.of

Charlotte Fereday — Sun, 20 Sep 2020 20:51:24 +0000

Today’s function is array.of(), mdn description here.

This function creates an array from whatever it has been given. Sounds a lot like array.from() right?

The difference is array.of can take multiple parameters, so works especially well if there are many things to add to the array, i.e. numbers. Whilst array.from can only takes one parameter, so works well especially with a string to split each char into an element in the array.

Another difference between array.from is that if array.of is passed an array and a function it won't apply the function to each element in the array like array.from but instead stores the function in the array.

Would welcome any comments on good situations to use this function.

I've done my own version of the docs with sketches together. Here’s the folder for array.of. Check out the readme to see how you can run the examples.

Visualising documentation: JavaScript array.map

Charlotte Fereday — Sun, 06 Sep 2020 17:39:34 +0000

Today’s function is array.map(), mdn description here.

Map applies the function it's given to every element in the array, and returns a new array with each transformed element inside it.

It's interesting to consider when to use map vs other core functions that could have the same effect, for example array.from(). Would welcome comments on trade offs.

I've done my own version of the docs with sketches together. Here’s the folder for array.map. Check out the readme to see how you can run the examples.

Visualising documentation: JavaScript array.from

Charlotte Fereday — Fri, 28 Aug 2020 13:56:19 +0000

Today’s function is array.from(), mdn description here.

This function creates an array from whatever it has been given.

For example, if you give it a string it will split the string into chars and build an array from that. You could also give it an existing array and a function, and it will create a new array from the results of applying the function to each item in the original array.

For this second use case, it's interesting to consider when to use array.from() vs array.map(). Would welcome any comments :)

I've done my own version of the docs with sketches together. Here’s the folder for array.from. Check out the readme to see how you can run the examples.

Visualising documentation: JavaScript array.flatMap

Charlotte Fereday — Sun, 23 Aug 2020 16:08:55 +0000

Today’s function is array.flatMap(), mdn description here.

FlatMap does two things:

map() -> applies the test function to each element of the aray
flat() -> flattens the results, i.e. smooshes together any nested arrays into a new single level 'flat' array.

That's right, it's the same as doing array.map.flat(). So why use it? It's a bit more efficient.

I've done my own version of the docs with sketches together. Here’s the folder for array.flatMap. Check out the readme to see how you can run the examples.

Visualising documentation: JavaScript array.flat

Charlotte Fereday — Tue, 18 Aug 2020 20:31:37 +0000

Today’s function is array.flat(), mdn description here.

Flat takes a nested array and smooshes it into a new single level 'flat' array. If there are empty slots anywhere in the array, it will remove those too.

I've done my own version of the docs with sketches together. Check out the readme to see how you can run the examples. Here’s the folder for array.flat.

Visualising documentation: JavaScript array.filter

Charlotte Fereday — Mon, 17 Aug 2020 20:39:59 +0000

Most days, for a few weeks, I’m aiming to sketch core JavaScript array functions.

This series began on medium and moves over here :)

Today’s function is array.filter(), mdn description here. Filter creates a new array with all the elements which meet the requirements for the test function.

Here’s my own version of the rewritten core docs & the sketches together. Here’s the folder for array.filter. Check out the readme to see how you can run the examples.

DEV Community: Charlotte Fereday

Authentication and Authorisation 101

Authentication

Rule 1: Only a customer should know their password

Rule 2: Always validate user input before using it

Authorisation

JSON Web Tokens(JWT)

Sign

Verify

Summary

Further Reading

Passwords

Validation

JSON web token

Cookies

JavaScript Security 101

JavaScript Threat Environments

1. Comparisons & conversions abuse

NaN, Null & undefined

Loose comparison

2. Injection attacks from dynamically executed code

eval()

Unsafe variants of browser APIs

3. Attacks from Prototype pollution

Tooling

In your code

In your JavaScript dependencies code

Asynchronous JavaScript 101

Why do I need to use asynchronous code again?

Promises

Chained Promises

Async / await

Handling promises

Promise.all

Promise.allSettled

Promise.race

So ... should I use chained promises or async / await?

Visualising documentation: JavaSript array.of

Visualising documentation: JavaScript array.map

Visualising documentation: JavaScript array.from

Visualising documentation: JavaScript array.flatMap

Visualising documentation: JavaScript array.flat

Visualising documentation: JavaScript array.filter