Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more


In this video, you will learn how to address typical vulnerabilities from security misconfigurations.
Welcome to the third and last part of Security Misconfiguration session. In this part, we will discuss security misconfiguration mitigation. We will start discussing what makes an application vulnerable, and then we will hunt OWASP Juice Shop vulnerable source code. Before closing this session, we will discuss how to avoid such vulnerabilities. Only required services, ports, pages, accounts, and privileges should be installed and enabled. Otherwise, the attacks you face will be wider and more difficult to protect. Typically, default accounts and their passwords are public knowledge since they are documented. Deploying the application with such accounts enabled leave the door wide open to attackers. Overly informative error messages provide attackers better understanding of the target application.
Security settings of some system components, such as application frameworks or databases, are not set to secure values. Latest security features are missing, disabled, or not configured securely. All this leaves the application vulnerable. If the server does not send appropriate security headers or directives, or they are not set to secure values, then both the client and client server communication are at risk. Let’s have a look at the source code. From projects page, we will jump straight to GitHub repo.
Let’s first check the security misconfiguration in the login endpoint.
POST requests to the login endpoint are handled by the login function.
This fuction is provided by the login.js file in the root folder.
This is where everything happens. First, the sequelized query, which returns a promise.
If the query succeeds returning zero or more records, then execution continues here.
When the sequelized query fails with an error, then it is caught here, and the error passed to the express framework. We need to see how the framework is handling error. Let’s get back to the server.js file.
This is the error and link setup.
Errors are handled by the error handler middleware, and the error handler middleware is provided by the npm error handler package. Let’s check its documentation.
Reading the first line should give us a good idea of what is going on. This is a development only middleware.
Then it continues, full error stack traces and internal details of any object passed to this middleware will be sent back to the client. Of course, this is not the right error handler middleware to have in a production environment. Let’s get back to the repo and check the misconfiguration we found in the Complaint feature.
Complaints file uploads are handled here.
The root is passed several middleware functions, but XML uploads are handled by the Handle XML Upload function.
This is interesting, it looks like that, to disable the feature, someone can do the implementation and force returning the 410 status code error with a custom message, leaving the original implementation untouched. Let’s discuss mitigation. An automated and repeatable hardening process will allow you to create similar environments. Note that accounts should be different or at least use different credentials. Deploy only what is really required without any unnecessary features, components, documentation, and samples. Security configurations of every component should be reviewed and updated as part of the patch management process, in particular, cloud storage permissions. Orphan AWS S3 buckets lead to subdomain takeover. Segmented application architectures provide effective secure separation between components or tenants. Containerisation and cloud security groups make the task easier.
Enforce client side security, configuring security headers with secure values to be sent as part of responses. Security settings and configurations should be continuously verified and tested in all environments. In our next session, we will discuss XSS or Cross-Site Scripting. Until then, take your time to carefully read the Security Misconfiguration section of OWASP Top 10.

In this video, you will learn how to address typical vulnerabilities from security misconfigurations.

Now that you have learned about security misconfigurations and how to take advantage of them using the OWASP Juice Shop, this video will show you how to assess the source code to identify these vulnerabilities. You will also learn about changes you can make to mitigate these vulnerabilities.

Investigate and share: Go to OWASP Security Misconfiguration for the full information on the table shown at the start of this section. What additional information did you learn?

Prepare for the Test of the Week

You have completed the content for this week! You are now ready to move on to the Test of the Week.

The following test is going to assess your understanding of what you have learned within this past week of the course.

Remember, you do not have to take the test until you’re ready. To help you prepare, you might wish to spend some time refreshing your understanding of the contents of the past week.

You may wish to reflect on the Learning Outcomes introduced at the beginning of the week and make sure you are comfortable that you have met the requirements of each. Take some time to review your learning to help you prepare.

This article is from the free online

Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now