This content originally appeared on Level Up Coding - Medium and was authored by Nuno Brites
Increase code quality using static application security testing
To avoid creating vulnerabilities, development teams establish good practices (e.g., pair programming, code reviews, unit testing, etc.) to be followed by the developers while coding. But even with a set of good practices in place, it is possible that vulnerabilities are introduced into the codebase and are only detected when the code reaches a production environment and an end customer reports an error.
One approach that can help mitigate the appearance of new vulnerabilities is the usage of Static Application Security Testing (SAST). This technique can be applied using tools that scan the code, searching for vulnerabilities while the code is being developed or in the pipeline before it’s deployed.
Let’s have a look at some of the advantages this technique brings:
- Allows vulnerability detection to be an automated process.
- Before pushing changes to the repository or in the deployment pipeline, you can integrate SAST in your IDE, which creates multiple scan possibilities before the code reaches production.
- Provides a sense of security in the team, leading to more confidence and speed while developing the codebase.
Now let’s see how it works for a development team.
Performing Static Code Analysis
Imagine a team working on a project decides to use a tool to perform static code analysis. The team opts for a cloud-based SAST tool and chooses to integrate it into their deployment pipeline. This way, they have the guarantee that every change to the codebase is scanned before reaching production.
Now that the code has been scanned for vulnerabilities, they want to create visibility for the results of each scan. For this, they generate an HTML report for each time the scan occurred and make it available as a web page, showing the evolution of the codebase regarding vulnerabilities.
With the previous steps in place, the team can now develop iteratively and check the codebase quality as they move forward.
Let’s have a more detailed look at the static code analysis report.
Static Code Analysis Report
When a static code analysis scan happens, it generates a report that addresses the quality of the codebase. The sections of the report might vary a bit depending on the chosen SAST tool, but the most common are the following:
- Bugs — errors in the code that needs to be fixed
- Code Smells — parts of the code that are not clear enough about their purpose and might lead to misinterpretations and new errors when the code is changed
- Vulnerabilities — security vulnerabilities that allow attackers to exploit the system (e.g., SQL injection or cross-site scripting)
- Eventual Vulnerabilities — possible security vulnerabilities that must be reviewed by the human eye to be confirmed as real vulnerabilities or fake positives
Let’s run through some code examples for each section.
Bugs
A simple example of a bug is dead code. In the example below, where the variable value is incremented after the return statement is executed, the increment will never execute.
// function with bug
function increment(int i) {
return i;
i++;
}
This example is easily fixed by changing the increment line to the same line as the return.
// corrected function
function increment(int i) {
return i++;
}
Code Smells
If one function is returning different types of values in its scope, then we are in the presence of a code smell. This code smell doesn’t allow developers to understand the behavior of the function easily and can lead to errors.
// function with code smell
function f(int i) {
if (i === 1) {
return true;
}
return 2;
}
One option to fix this is to understand the purpose of the function and decide to go with a single return type, in this case, a boolean.
// corrected function
function f(int i) {
if (i === 1) {
return true;
}
return false;
}
Vulnerabilities
A very well-known vulnerability is SQL injection, where an attacker uses the parameters passed to a specific SQL query to change the meaning of the query and get access to data or attack the system directly by deleting or changing data. This might happen when the SQL queries and the respective parameters are assembled manually by concatenation, like the example below.
var dbConnection = require('./dbConnection.js');
function queryUser(req, res) {
var name = req.query.name;
var password = crypto.createHash('sha256').update(req.query.password).digest('base64');
var sql = "select * from user where name = '" + name + "' and password = '" + password + "'"; dbConnection.query(sql, function(err, result) {
// execute some code here
})
}To prevent SQL injection, use prepared statements where the query is parameterized and make sure the parameters provided by the user are properly escaped.
var dbConnection = require('./dbConnection.js');
function queryUser(req, res) {
var name = req.query.name;
var password = crypto.createHash('sha256').update(req.query.password).digest('base64');
var sql = "select * from user where name = ? and password = ?";
dbConnection.query(sql, [name, password], function(err, result) {
// execute some code here
})
}Eventual Vulnerabilities
One simple example of an eventual vulnerability is hardcoding credentials in a file in the source code. The example below shows the hardcoded credentials to access a database.
let mysql = require('mysql');
let conn = mysql.createConnection({
host:'localhost',
user: "username",
password: "notsosecretpassword",
database: "db"
});
conn.connect();To avoid hard coding credentials, they should be stored in environment variables and used in the code like the example below.
var mysql = require('mysql');
var conn = mysql.createConnection({
host: process.env.MYSQL_URL,
username: process.env.MYSQL_USERNAME,
password: process.env.MYSQL_PASSWORD,
database: process.env.MYSQL_DATABASE
});conn.connect();
Wrapping Up
Using a SAST tool is undoubtedly a good choice since it allows the development team to have an automated safeguard regarding possible vulnerabilities being introduced into the code during the development of a codebase.
It should not be seen as the path to a 100% vulnerability-free codebase since it is based on a predefined and finite set of rules that are checked while scanning the code. Still, it will save a lot of time and stress for teams as it avoids vulnerabilities being detected manually by someone (developers, quality assurance, or even the end customer) and then be fixed.
A report that reflects the quality of the codebase creates visibility, transparency, and awareness regarding the current state of the project and the necessary improvements to be made in the future.
Happy coding!
Testing Compliance with Coding Standards Through SAST was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Nuno Brites
Nuno Brites | Sciencx (2021-06-24T03:08:59+00:00) Testing Compliance with Coding Standards Through SAST. Retrieved from https://www.scien.cx/2021/06/24/testing-compliance-with-coding-standards-through-sast/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.