Tracking vulnerabilities and keeping Node.js packages up to date

Software evolves quickly and new versions of libraries are released but how do you keep track of updated dependencies and vulnerable libraries? Managing dependencies has always been somewhat a pain point but an important part of software development as it's better to be tracking vulnerabilities and running fresh packages than being pwned.

There are couple of tools for JavaScript projects which use npm to manage dependencies to check new versions and some tools to track vulnerabilities. Here's a short introduction to npm audit, depcheck, npm-check-updates and npm-check to help you on your way.

If your project is using yarn adjust your workflow accordingly. There's for example yarn audit and yarn-check to match tools for npm. And it goes without saying that don't use npm if your project uses yarn.

Running security audit with npm audit

From version 6 onwards npm comes build with audit command which checks for vulnerabilities in your dependencies and runs automatically when you install a package with npm install. You can also run npm audit manually on your locally installed packages to conduct a security audit of the package and produce a report of dependency vulnerabilities and suggested patches.

The npm audit command submits a description of the dependencies configured in your package to your default registry and asks for a report of known vulnerabilities. It checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies.

If your npm registry doesn't support npm audit, like Artifactory, you can pass in the --registry flag to point to public npm. The downside is that now you can't audit private packages that are on the Artifactory registry.

$ npm audit --registry=https://registry.npmjs.org

"Running npm audit will produce a report of security vulnerabilities with the affected package name, vulnerability severity and description, path, and other information, and, if available, commands to apply patches to resolve vulnerabilities."

Example: partial output of npm audit run

Using npm audit is useful also in Continuous Integration as it will return a non-zero response code if security vulnerabilities are found.

For more information read npm's Auditing dependencies for security vulnerabilities.

Updating packages with npm outdated

It's recommended to regularly update the local packages your project depends on to improve your code as improvements to its dependencies are made. In your project root directory, run the update command and then outdated. There should not be any output.

$ npm update
$ npm outdated 
Example of results from npm outdated

You can also update globally-installed packages. To see which global packages need to be updated run outdated first with --depth=0.

$ npm outdated -g --depth=0
$ npm outdated -g

For more information read updating packages downloaded from the registry.

Check updates with npm-check-updates

Package.json contains dependencies with semantic versioning policy and to find newer versions of package dependencies than what your package.json allows you need tools like npm-check-updates. It can upgrade your package.json dependencies to the latest versions, ignoring specified versions while maintaining your existing semantic versioning policies.

Install npm-check-updates globally with:

$ npm install -g npm-check-updates 

And run it with:

$ ncu

The result shows any new dependencies for the project in the current directory. See documentation for i.a. configuration files for filtering and excluding dependencies.

Example of results from ncu

And finally you can run ncu -u to upgrade the package.json.

Check updates with npm-check

Similar tool to npm-check-updates is npm-check which additionally gives more information about the version changes available and also lets you interactively pick which packages to update instead of an all or nothing approach. It checks for outdated, incorrect, and unused dependencies.

Install npm-check globally with:

$ npm i -g npm-check

Now you can run the command inside your project directory:

$ npm-check
Or
$ npm-check --registry=https://registry.npmjs.org

It will display all possible updates with information about the type of update, project URL, commands, and will attempt to check if the package is still in use. You can easily parse through the results and see what packages might be safe to update. When updates are required it will return a non-zero response code that you can use in your CI tools.

The check for unused dependencies uses depcheck and isn't able to foresee all ways dependencies can be used so be vary with careless removing of packages.

To see an interactive UI for choosing which modules to update run:

$ npm-check –u

Analyze dependencies with depcheck

Your package.json is filled with dependencies and some of them might be useless or even missing from package.json. Depcheck is a tool for analyzing the dependencies in a project to see how each dependency is used, which dependencies are useless, and which dependencies are missing. It does not only recognizes the dependencies in JavaScript files, but also supports i.a. React JSX and Typescript.

Install depcheck with:

$ npm install -g depcheck
And with additional syntax support for Typescript
$ npm install -g depcheck typescript

Run depcheck with:

$ depcheck [directory]
Example of results from depcheck

Summary

tl;dr;

  1. Use npm audit in your CI pipeline
  2. Update dependencies with npm outdated
  3. Check new versions of dependencies with either npm-check-updates or npm-check
  4. Analyze dependencies with depcheck

Notes from security in the age of Docker & Kubernetes

Security is always the more obscure part of software development and while container runtimes provide good isolation from the host operating system when using Docker and running containers in Kubernetes, you should not assume to be free from exploits. Remember to use the best practices when you were not using containers.

Here is my notes from How Soon We Forget: Security in the Age of Docker & Kubernetes article which looked at some common regressions in security practices associated with the migration to Docker and Kubernetes and suggested ways to avoid them. And to continue the topic with notes from Taking the Scissors away: make your Kubernetes Cluster safe for DevOps talk which gives good advice and looks at some of the concepts of forcing security of the application workloads both from conceptual and practical points of view. Also Best Practices for Kubernetes deployment and Securing a cluster are worth reading.

These notes don't explain things so it's worth reading either the documents or the articles mentioned above.

Running as non-root

"One of the most common and easiest security lapses to address is running binaries as root."

Use non-root Docker images. It requires effort and is easier for greenfield projects.

In Kubernetes, you can enforce running containers as non-root using the pod and container security context.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app
      name: app
    spec:
      containers:
      - image: my/app:1.0.0
        name: app
        securityContext:
          allowPrivilegeEscalation: false
          privileged: false
      securityContext:
        fsGroup: 2866
        runAsNonRoot: true
        runAsUser: 2866

Use read-only file system

"Do you really need to write files within a container?"

In Kubernetes, set the root file system to read-only using the pod security context and create an emptyDir volume to mount at /tmp.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app
      name: app
    spec:
      containers:
      - env:
        - name: TMPDIR
          value: /tmp
        image: my/app:1.0.0
        name: app
        securityContext:
          readOnlyRootFilesystem: true
        volumeMounts:
        - mountPath: /tmp
          name: tmp
      volumes:
      - emptyDir: {}
        name: tmp

Protect against Denial of service

"Setting resources limits for your containers protects against a host of denial of service attacks."

With resource quotas you can limit a container to e.g. half a CPU and half a GiB of memory. Kubernetes deployment specification would look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app
      name: app
    spec:
      containers:
      - image: my/app:1.0.0
        name: app
        resources:
          limits:
            cpu: 500m
            memory: 512Mi

Health and readiness checks

"It's a good idea to make sure if your application is not healthy that it shuts down properly so it can be replaced. Kubernetes can help you with this if your application can respond to health and readiness checks and you configure them in your pod specification."

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app
      name: app
    spec:
      containers:
      - image: my/app:1.0.0
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /health
            port: http
            scheme: HTTP
          initialDelaySeconds: 20
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 3
        name: app
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: http
            scheme: HTTP
          initialDelaySeconds: 20
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 3

The liveness probe should indicate if the application is running and readiness probe should indicate if the application can service requests. Read more from Kubernetes documentation.

Use Kubernetes policies

"Kubernetes provides network and pod security policies that give you control over what pods can communicate with each other and what types of pods can be started, respectively."

Pod Security Policies allow you to control what capabilities pods can have. When pod security policies are enabled, Kubernetes will only start pods that satisfy the constraints of the pod security policies.

They say that Pod Security Policy is actually one of the most difficult things to configure properly in Kubernetes cluster. For example it's easy to completely cap your cluster: you can't create any pods.

An example of a pod security policy that enforces some of the best practices mentioned: non-privileged containers, allow only read-only filesystem, minimum set of allowed volumes and don't use host’s network, pid or ipc namespaces.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: best-practices
spec:
  # non-privileged containers
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  runAsUser:
    rule: MustRunAsNonRoot
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  # restrict file systems
  readOnlyRootFilesystem: true
  volumes:
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim
  # limit interaction with host
  hostNetwork: false
  hostIPC: false
  hostPID: false

Network Policies

"Network policies allow you to define ingress and egress rules, i.e., firewall rules, for your pods using IP CIDR ranges and Kubernetes label selectors for pods and namespaces, similar to how Kubernetes service resources select pods."

For example you can create a network policy which will deny ingress from pods in other namespaces but allow pods within the namespace to communicate with each other.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-from-other-namespaces
  namespace: mine
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

There is a GitHub repository of common network policies to help you get started using network policies.

Namespaces

Use namespaces and ensure that you've set the following defaults:

Summary

"defense in depth" is still important even in the world of containers. The container is not safe. The operating system is not safe. The host is not safe. The network is not safe.

How Soon We Forget: Security in the Age of Docker & Kubernetes

OWASP Helsinki chapter meeting 34: Secure API

OWASP Helsinki Chapter held a meeting number 34 last week at Eficode with topics of
"Perfectly secure API" and "Best friends: API security & API management". The event gave good overview to the topics covered and was quite packed with people. Eficode's premises were modern and there was snacks and beverages. And also a sauna. Here is a short recap of the talks.

OWASP Helsinki Chapter Meeting 34

Perfectly secure API

Matti Suominen from Nixu talked about perfectly secure API and things related to get there. Can API be secure? On gut feeling APIs seems to be rubbish and have problems. He covered the topic from three view points: security, risks and defense. Good starting point is to read OWASP resources like ASVS, Top 10 and Security cheat sheet. Also implement security centrally, involve business in design and DIY never works out.

Best friends: API security & API management

Antti Virtanen from Solita talked about API security and API management and how we've traveled from dark ages to modern times. You can do API security with tools like Amazon AWS API Gateway but the main point was to step further with API management. Use some already made products like Apigee and open source alternative Tyk.io. Slides are available in Slideshare.

Snacks and beverages

Refreshments were basic and different

Keeping data secured with iStorage datAshur Personal2 USB flash drive

Knowledge is power and keeping it secured from unauthorised eyes is important, be it inside of a computer, on external hard drive or on USB flash drive. Especially small external devices are easy to lose and can leave your data vulnerable if not encrypted. Fortunately there are solutions like iStorage datAshur Personal2 which is an USB flash drive with combination of hardware encryption, physical keypad and tamper-proofing. I got 8 GB version of Personal2 for testing (for free) and here's a quick review how the device works.

datAshur Personal2 secures data with hardware encryption and on-board keypad

iStorage datAshur Personal2 is an USB 3.0 flash drive designed to keep your data protected from unauthorised access even if it's lost or stolen. It's operating system and platform-independent and available up to 64 GB. The beef about the flash drive is that user needs to enter 7-15 digit PIN code onto the rechargeable battery powered on-board keypad before connecting the drive to the USB port and accessing the data. All data transferred to the datAshur Personal2 is encrypted in real-time with built-in XTS-AES 256-bit hardware encryption. The device automatically locks when unplugged from the computer or power to the USB port is turned off and it can be set to lock after a certain amount of time. And what's good about hardware encryption is that it (in theory) shouldn't slow the drive down when writing or reading files to or from the drive. The device has protection against brute forcing and it's aluminium housing is dust- and water- resistant.

Personal2 differs from most flash drives in length, being a little longer to accommodate the keypad. Buttons are quite small so large fingers may have some difficulty finding the right key. Overall build quality looks good although the removable USB plug cover is cumbersome and easily lost. The keypad is powered with rechargeable battery and even if the battery goes dead you can just recharge it from the USB port. The keypad on the iStorage datAshur is critical for security as it means the device works independently from a computer and prevents a keylogger from recording a code entered via keyboard. It also makes it operating system and platform-independent and doesn't require any specific software or drivers.

The datAshur Personal2 can be configured with two different PINs: user and admin PINs, making it perfect for corporate and government deployment. If the user forgets their PIN, the drive can be unlocked using the Admin PIN which will then clear the old User PIN and allow the User to set a new PIN. It also ensures that the corporate data can be retrieved from the device when an employee leaves the company.

The device also has a reset feature which clears both User and Admin PINs, deletes all data, creates a new randomly generated encryption key and allows the drive to be reused. To prevent brute-force attacks, if both admin and user PINs have been created and incorrect user PIN is entered ten consecutive times, the brute force mechanism will trigger and the user PIN will be deleted. If the admin PIN is entered incorrectly ten consecutive times, then both the user and admin PINs, the encryption key and all data will be deleted and lost forever. The device will revert back to factory default settings and needs to be formatted before it can be reused.

The device comes with quick start guide which tells you how to unlock the drive and how to change the user PIN. I tested the Personal2 with macOS Sierra and getting started with it was easy. The drive worked just like any other normal USB flash drive and after unlocking it was recognised as usual. I didn't measure the read or write speeds but they seemed fine for that size of a drive. They say that it's up to 116MB/s read and 43MB/s write which is typical for small USB 3 flash drives. Of course decent performance is required but transfer speeds are not the reason why you buy encrypted USB flash drives.

The datAshur Personal2 isn't the first or last encrypted USB flash drive with hardware keypad but it seems to work nicely. It costs somewhat more than a normal USB flash drive (8GB is £39, 64GB is £79) but that's what you pay for keeping sensitive data secured. And what comes to performance, it's always a compromise between security and speed.

Build secure Web applications by reading Iron-Clad Java

Building secure Web applications isn't easy and contains many aspects that the development team has to consider and take into account. "Iron-Clad Java: Building Secure Web Applications" book is good starting point to learn concepts, tactics, patterns and anti-patterns to develop, deploy and maintain secure Java applications. With 304 pages the book is more about getting an overview and pointers for further reading and research but works quite nicely in that regard.

"Iron-Clad Java: Building secure Web applications"

As the name suggests, "Iron-Clad Java: Building Secure Web Applications" by Jim Manico and August Detlefsen, is targeted for Java developers and is suitable reading also for less technical people in the team like project managers and managers as it doesn't go too deeply to technical aspects or code. After reading the book even the managers should get an appreciation and the vocabulary to discuss security with their staff. The reader should get a solid understanding of what is wrong with many web apps in general and what corrective measures to take to mitigate the issues. The book was published September 2014 and has 304 pages (ISBN-13: 978-0071835886).

The book covers topics like secure authentication and session management processes, access control design, defending against cross-site scripting (XSS) and cross-site request forgery (CSRF), protecting sensitive data while stored or in transit, preventing SQL injection, ensuring safe file I/O and upload, using effective logging, error handling, and intrusion detection methods and also guide for secure software development lifecycle (secure-SDLC). The topics are written with theory and practice and so that they are approachable for developers new to security, for those that might be a little inexperienced but still providing useful nuggets for experienced developers.

In good and bad the book gives somewhat opinionated answers what technics and tools you can use to address security issues but overall the advice is solid and un-biased and more or less framework agnostic. So, the lessons learned should apply to any project. For me, writing examples with e.g. JSP and Struts makes me question if also the other tools the book suggest (which I wasn't familiar with) are suitable for modern Java EE application development. Something to look into after reading the book. Also OWASP seemed to have answer to almost every security aspect.

Anyways, the book's advice isn't about using certain technologies but giving you something to think about and educating about security aspects in your Java Web application. What matters is that the book gives explanations of why you need to implement a specific control for a given issue, how you could do it and what the impacts are. This is what many security professionals miss when speaking to developers. The book tells you what the security problem is and then why and how you should fix that so it makes sense for developers.

Taking care for Web application security isn't just for architects and developers but it's also a topic which importance whole team should know and understand. The "Iron-Clad Java: Building secure Web applications" gives good overview to security and is suitable for the whole development team to read.