How effective is secure code review for discovering vulnerabilities?

Tim

10th November 2021

8 min read

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!’}), 200

 

We 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.

Resources

  • Insights
  • Labs

OWASP Top 10 2021 Released

The Open Web Application Security Project (OWASP) is a not-for-profit organisation that aims, through community-led open-source projects, to improve the security of web-based software. OWASP…

What is penetration testing and why is it important to use a CREST-approved provider?

Trusting the effectiveness of your IT security controls is crucial to mitigate risks and malicious access to your systems and the information they store. Penetration…

How secure use of the cloud can digitally transform your business

Companies that move towards digital transformation can innovate more quickly, scale efficiently and reduce risk by implementing cloud security best practices. Businesses must keep up…

How to prepare your business for secure cloud migration

The cloud holds a lot of potential for organisations. Moving your IT environment to a secure cloud provides flexibility and agility. It allows your team…

Celebrating Sentrium’s contribution to cyber security

2020 is the year that remote working exploded. Businesses and the general public had to quickly adapt to new ways of working caused by the…

What is CREST and what are the benefits of using a CREST accredited company?

We’re delighted to announce that Sentrium Security is now a CREST accredited company! This is an exciting achievement for us and it’s great to be…

Preventing exploitation of the Follina vulnerability in MSDT

The Follina Exploit A zero-click Remote Code Execution (RCE) vulnerability has started making the rounds which is leveraging functionality within applications such as Microsoft Word.…

Application Security 101 – HTTP headers

1. Strict-Transport-Security The HTTP Strict Transport Security (HSTS) header forces browsers and other agents to interact with web servers over the encrypted HTTPS protocol, which…

New Exchange RCE vulnerability actively exploited

Exchange admins now have another exploit to deal with despite still reeling from a number of high profile attacks this year including ProxyLogon and ProxyShell.…

Application Security (AppSec)

There is a movement in the IT security world that is gaining traction, and it is based around the implementation of security within applications from…

Enhancing Security in your Software Development LifeCycle – Dealing with Dependencies

The adoption of agile practices has resulted in the emergence of shift-lift testing, where testing is performed much earlier in the Software Development LifeCycle (SDLC).…

TOP