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


This video explains how to identify vulnerabilities to injection attacks by assessing the source code.
Welcome to the third and last part of Injection Flaws session. In this last part, we will discuss injection flaws mitigation. We will start discussing what makes an application vulnerable. Since OWASP Juice Shop is open source, we will spot the vulnerable source code. Then we will discuss how to avoid such vulnerabilities. First big mistake– Juice Shop asks for an email address, but no validation was performed upon our payload. A validation such as this one would have aborted the backend execution before merging submitted data with the SQL query template. Sometimes, required data doesn’t have a well-defined pattern as an email address, and so validation doesn’t come easy.
In such cases, the characters range should be limited and dangerous ones removed from the input or the input rejected. Client provided data is directly concatenated to a SQL query template in and by the backend server. Remind that the backend server is written in a programming language other than SQL, so it knows nothing about how to handle SQL queries. The backend is just doing arbitrary strings concatenation. Some characters have special meaning to specific tools or contexts. In our SQL query, the single quote character is used to wrap strings like the email address.
When external data is appended to the SQL query template inside single quotes, and that data contains one or more single quote characters, then the resulting query will be different from what the template was written for. To avoid this, the single quote character in external data has to be escaped so that it is read as is with no special meaning. Escaping is not an easy task to be done externally to the target tool or context. To do it, you will need to know all special characters beforehand, and you’ll certainly miss one or a few of them. Let’s see what makes Juice Shop vulnerable.
This is the OWASP Juice Shop project page, and we’re going to jump from here to the project repo.
The project repo has all the source code, but now, we are looking for a specific folder, which should have all application roots.
Inside this folder, we should find the login.js file, which should have all the login features.
We have our first login function, and then in or after login function, but this one doesn’t look to have any SQL query template.
In the next one, we can see some select from the user’s table, and then the email and password both are matched against user input data. So this is a good candidate. Let’s copy and paste it to our text editor and make it readable.
This is how the query template looks like before interpolation. We’re going to replace the variables with the admin account details and see how the final query looks like.
So this is what gets sent to the database and executed on a legit login request. Let’s do the same with our payload.
Since what’s after the semicolon is ignored by the database server, this is the statement that gets executed.
When we are dealing with SQL, prepared statements are that safety zone. Instead of concatenating a SQL template with user input data in the backend server without the right context, you’ll first provide a SQL interpreter, the query template with some placeholders where you expect user input data to be replaced. On a second step, you will provide input data to replace the placeholders, but this operation will be done by the SQL interpreter, which knows its one context better than anything or anyone else. Always validate external data. When it does not meet your expectations or requirements, reject it. Make sure that provided data only has allowed characters. Whitelists tend to be safer than blacklists.
You know better what you want than what you don’t. As I said before, escaping is not an easy task. If there’s no safe API available, look for well documented and maintained escaping libraries specific to your target interpretor. When dealing with SQL queries, always limit the number of records to return to mitigate huge data leaks in case you get compromised. In our next session, we will discuss broken authentication flaws. Until then, take your time to carefully read the injection section of OWASP Top 10.

This video explains how to identify vulnerabilities to injection attacks by assessing the source code. Additionally, how to prevent these injection flaws from occurring is also explained.

Reading source code can be time consuming if you are not familiar with the system. In this video, you will learn how to identify the specific areas of code that may make a system vulnerable to injection attacks. Once you understand how to identify flaws in the code, you will learn how to change the code to mitigate attacks and increase your security.

Investigate and share: Go to this document on cheatsheets and read the information there. Share what you found interesting or useful in the comments section below.

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