Skip main navigation

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

Find out more
Home / Business & Management / Cyber Security / Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals / Mitigation

Mitigation

In this video, you will look at the application source code to assess and improve the application’s authentication processes.
View transcript
6.6
Welcome to the third and last part of Broken Authentication session. In this part, we will discuss authentication flaws mitigation. We will start discussing what makes an application vulnerable, and then we will hunt OWASP Juice Shop vulnerable source code. Then we will discuss how to avoid such vulnerabilities. If your application does not enforce a strong password policy, like OWASP Juice Shop, then it is vulnerable. Showing a password strength bar is not enough. If an application does nothing to detect and stop automated attacks, then sooner or later, accounts will be compromised. You have seen how easy it is to get the username/password combination lists.
48.2
OWASP Juice Shop users a security question within to exploit it, but we could have done so the same way we brute forced the password. Download the common English female first names list and keep sending requests to the application until we get the positive response. This is the worst password recovery challenge you can use– you cannot fix it. An ineffective multifactor authentication is as bad as not having one. Sometimes, multifactor is required in the front end, but not validated by the back end. Session management is another common authentication issue. We didn’t exploit it, but you’ll find extensive documentation about the topic– search and read it. Let’s have a look at the source code.
93.2
From OWASP Juice Shop project page, we can jump directly to the GitHub repo.
104.5
Juice Shop server is bootstrapped into server.js file.
116
Unlike other routes, the signup one is automatically generated by npm package called Finale.
129.8
Following this approach, signup request data is passed directly to the user model. Well, it doesn’t sound like a good idea. We need to have a look at the user model to understand how to sign up really works.
173.1
The user model has just a schema, meaning that signup request data is saved directly into the database. Not only is the password strength not enforced, but the confirmation password matching is also missing. Let’s now have a look at the security dash question endpoint used to enumerate Juice Shop accounts.
221.5
This is the function responsible to retrieve the security question from the database.
228.8
Given an email address, it looks up in the database to find the user records. If a record was found, then it searched the database for the security question records. If a security question was found, then it is returned as JSON. Otherwise, an empty JSON object is returned. This is what creates the binary feedback allowing attackers to use the application as in Oracle to enumerate user accounts. Let’s now have a look at the login root.
281.3
We have seen dysfunction before in our injection flow session. We know that this SQL query is responsible to match provided email and password against database records.
309
If no record matching the email and password is found, then we jump straight to this ELSE clause, and here, we just return an error code and the invalid email or password message. There’s no failed login attempt counter being updated or special logging. The lack of lockout feature, rate limiting, and insufficient logging, makes it possible to perpetrate brute force attacks such as the credential stuffing one we did to find the admin passwords without being noticed. If you’re building a new application, then consider multifactor authentication since it will be easy to implement. Otherwise, if you’re maintaining an existing application, changing your current implementation is worth every second. Probably, you won’t be able to get rid of password as authentication factor.
358.8
Enforce strong passwords and test them against common or leaked ones. Do not deploy or ship your application with default passwords. Otherwise, they will become shared secrets, and hey, while shared, it is no more a secret. Make sure none of the authentication mechanisms leak information about whether an account exists or not. The recover password mechanisms tend to be a good candidate for account enumeration. Make sure the response feedback remains the same regardless whether the account exists or not. Log failed login attempts. After a few, lock the account and notified the owner. Application owner should also be notified that application or a single account is under attack. Sessions should be managed server side.
403.2
Choose a well documented and actively maintained session management library. Audit the library specifically regarding tokens lifecycle. In our next session, we will discuss sensitive data exposure. Until then, take your time to carefully read the Broken Authentications section of OWASP Top 10.

In this video, you will look at the application source code to assess and improve the application’s authentication processes.

Now that you understand how authentication processes work, you will look at the source code for authentication for an application. After reviewing the initial code, the video will explain what steps can be added to the login processes to prevent a database from being hacked.

Prepare for the Test of the Week

You have completed the content for this week! Complete the poll in the next step, and then you are ready to assess your knowledge of this week’s content.

The test of the week 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.

Want to keep
learning?

This content is taken from
EC-Council online course,

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

View Course

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.

Want to keep learning?

This content is taken from EC-Council online course
Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals
View Course
See other articles from this course
This article is from the online course:

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

Created by
Join Now
This article is from the free online

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

Created by
Join Now
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

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free