We’ve recently discussed application security and the trend we’re seeing in which companies are increasingly implementing security early on in the Software Development Life Cycle (SDLC).
In our blog post exploring the impact of adopting application security, we described a common scenario involving assessing an application that was ready for release. Through the assessment, critical vulnerabilities were identified, such as an SQL injection, close to the go-live deadline.
This time, we’re covering how a secure code review early on in the SDLC can identify this vulnerability. This would give developers time to make changes without delaying the project, and understand the importance of security best practices when coding secure applications.
In this similar scenario, the company contacted us during the early stages of development – the adoption of “Shift-Left”.
The scenario
An application software development company contacts us for a secure code review. The application consists of a Bootstrap frontend, a search form for querying critical business information, and is supported by an API that queries the business-critical database.
Up to here, everything is the same as the previous scenario which stated that “During the application assessment, a consultant identifies a potential SQL injection vulnerability in the search functionality with an apostrophe (‘). A database syntax error is returned. ”
What if?
However, what if the application doesn’t provide a syntax error message? Instead, it handles the error and returns a generic message. Would the vulnerability still be found?
To explain this, we’ve developed a basic application to simulate the identification of the vulnerability. Within the application, we have admin functionality to search for users:
We attempt to cause a database error by inserting an apostrophe (‘) into the search field. But this time, no error is returned, and we’re told that a user couldn’t be found.
It doesn’t take much to expand the test further and use an SQL command to confirm the existence of the vulnerability. However, this is simply a simulation to show the differences between a code review and an application review.
An alternative approach
We review the basic code that handles the request from the user and the database query that’s performed.
try:
# SQL Query
result = db.session.execute('SELECT * FROM users WHERE id = ' + str(Id))
# Return the user object
return jsonify({'user': [dict(row) for row in result]})
except Exception as e:
# Error handled here
return jsonify({'error': 'Could not find a user!'}), 200We can see that a database query is performed on the ‘users’ table, where the ‘id’ equals the string value of the variable ‘Id’. If this ‘Id’ variable contains a value that is user-controlled, we can easily inject this statement and execute our own SQL.
try:
# Get the id of the issue from the request argument
Id = request.args.get('id', None)We’ve confirmed that the ‘Id’ variable is the value passed in the GET parameter, and can inject potentially malicious SQL statements.
Heading back to the application frontend, we continue to insert a typical 1 or 1 = 1; statement. This is used to bypass authentication or return all records from a table.
What happens next?
As per an application assessment, the consultant continues the code review in the hunt for more vulnerabilities. In this scenario, the client requested a secure code review. A vulnerability was identified which is the same vulnerability as identified in the application assessment.
However, this time, the client had a secure code review performed at an earlier stage in the SDLC. This gives them a chance to remediate issues long before the application is released into production.
Further to this, the interaction between our security consultants and the development team means the client gains a deeper understanding of what it takes to develop applications securely. The client can now continue to develop the application securely from the ground up with security taking precedence.
Final thoughts
With the rapid development of applications, multiple updates, feature upgrades, fixes and improvements, there’s always the potential that vulnerabilities are introduced at multiple stages of the SDLC.
From this example, we can see that a code review can lead to a greater level of assurance during the development phases and should be routinely performed.
There shouldn’t be a compromise between rapid development cycles and best practice security. When an organisation adopts security early on, both can be achieved. This will improve security posture and reduce costs of security integration while maintaining fast delivery which ultimately leads to business success.
In our next blog post, we’ll take this example and shift it even further left. Before any code is written, we can start to map out how an application functions; documenting its inputs and outputs, user roles, external dependencies and service, in what is known as threat-modelling. If you need require any assistance, please get in touch with us today and find out how we can help you.
