Security Misconfiguration

Learning Objectives

Security Misconfiguration

When we use a piece of technology, we often have to configure it to our needs. When you get a new phone, for example, you have to set your name, background photo, password etc. If you decided to not set a password, this would be a security misconfiguration, since anyone could access your phone.

Likewise, when developing applications, we need to make sure the configurations of the software we use are secure. For example, if we host a database using a 3rd-party cloud provider, they might initialize the account with a default username and password (e.g. "admin" and "password"). If we forget to override this, this would be considered a misconfiguration since anyone could login.

A real-world example happened in 2021 when the personal records of half a million Ghanaian graduates were leaked. These were stored on an AWS S3 bucket which had been misconfigured such that not all the data was password-protected.

Another common example is overly informative stack-trace displays. When we're developing an app and an error occurs, we usually want the framework to print out a stack trace to the screen to help us find the bug.

image

These should be turned off, however, when the app is being run in a production environment, since such stack traces might contain sensitive information or details that could help an attacker. Failing to configure our framework/hosting-provider to hide these traces would be considered a misconfiguration.

Preventing Security Misconfiguration

Assignment

Solve the "Error Handling" challenge on Juice Shop