Why Secure Code Reviews (SCR) and Static Application Security Testing (SAST) Are Critical for Your Business.

What is SCR (Secure Code Review)?

SCR – Generally known to Security Researchers as Secure Code Review. SCR is a very initiative-taking and preventative approach to secure an application before it’s even deployed. Where Penetration Testing focuses on finding flaws after an application is already running/deployed, Secure Code Reviews ensures that the attack surface of any application is as low as it can be before runtime.

Why SCR is Important for Your Business?

Secure Code Reviews aid heavily in terms of applications that have Security Compliance Obligations and generally reduce the overall cost it would take to secure an application as the remediation and mitigation strategies can be implemented before deployment and release. This ensures that minimal code changes are needed post deployment when it comes to security. Saving a ton of resources use post deployment.

How Do SCR and SAST Work?

Just like with Pen-tests, Code Reviews can be both Automated (SAST) as well as Manual (SCR). And again, just like Pentest, the best approach is always a right balance of both. SAST tools focus on all aspects of the code including non-readable components, third party libraries and the code itself. Whereas SCR focuses more on the data flow of the application to figure out underlying security flaws.

Both forms of reviews also focus on other issues such as encryption (Methods Used, Length of Keys, Best Practices), Logical Redundancies, Salts, Hard-Coded Secrets and Credentials, Disclosures and much more.

Understanding SCR in Action

The two important components of any finding in SCR is the Source and the Sink.

Source: The source through which the malicious activity may enter our code. This could be any parameter from a user input, or a stored malicious string that gets called again from memory, or some input that gets fetched from a third-party application to be used in our code.
Sink: The sink is where the execution of the malicious activity takes place. For example, a query getting executed, a file being created, or a response being generated using input from a source.

That’s all the theoretical knowledge required for a more practical understanding. Let’s get into it.

Vulnerability Examples and Their Impact

Let’s drill down a bit into the depths of manual review with a few examples of what vulnerable code may look like and the impact it would have if the code were to be deployed.

1. Cross-Site Scripting (XSS)

This is a snippet of some code that would lead to a Cross Site Script execution from user supplied query. This is due to the response being built from user input directly without any sanitization or validation for malicious special characters, moreover responses should not be formed in such a manner at all.

The handler class accepts “t,” which includes the request the user sends to the server.
The user query along with more parameters are extracted from the request’s URI and stored in “param.”
A “response” is generated using the value retrieved from the “q” parameter in the URI (supplied by the user).
Finally, the response is returned to the user.

Here a malicious user could form a crafted URL with a malicious payload that could be sent to any target to steal user data and much more. In a Web Pentest, this would only be detected post deployment, but SCR remediates the risk in advance.

2. Insecure Direct Object Reference (IDOR)

This is a snippet for what an IDOR may look like that would grant user admin access. The flaw here is that the user entitlement is not being managed in a standardized manner. Instead of the server checking the user entitlements server-side, it checks if a specific role is assigned to the user from the user-supplied cookie and provides access to privileged pages.

Here, the “userdata” cookie value is taken from the user request once they arrive on the landing page.
The center part here just checks the data and converts it into a processable format.
The value of the parameter “role” is then checked to see if it is set to “admin”.
If it does not, the user is shown “Not authorized to access this resource”.
And if it is, the user is granted access to the “Admin dashboard”.

This form of IDOR can be classified as Privilege Escalation. There’s not much of an explanation required to describe the extent of the damage this could lead to.

3. Broken Authorization

One of the classics and my favorite. A broken authorization vulnerability arises when the server performs important CRUD operations without entitlement checks. Other ways also include insufficient secure mechanisms in place for authorization before accessing privileged resources.

Here, when trying to access the “/admin” path, the server extracts the “role” and “X-Forwarded-For” values from the request headers.
It first checks if the value of the “role” header is set to “admin”.
Then it enters a loop to check if the value extracted from the “ClientIP” header matches either “localhost” or “127.0.0.1”.
If either case is true, the user is then granted access to the “Admin Dashboard”.

A Broken Authorization mechanism of this sort could lead to an entire application takeover. From a logical standpoint the code had nothing wrong with it. But from a security standpoint it did everything wrong.

4. Business Logic Flaw

The following snippet is a considerably basic example of what business logic vulnerability would look like. Every application has flows implemented that are essential to fulfill the main purpose of the application, finding flaws against the logic used that lead to monetary loss, defamation, or anything that would damage the business comes under a Business Logic Flaw. The example shows how a banking application has implemented the code which allows a user to withdraw funds.

The server extracts the amount to be withdrawn from the user supplied parameter value “amount”.
The value for the amount is then checked against the user’s balance to fit the criteria ‘amount should be < or = User Balance’
If the criteria fits, the “Withdraw” method is called where another check is performed to verify ‘amount should be < or = User Balance’, “money” variable value is updated to the new balance, then the user balance is updated by calling the “Update_Balance” method.
Over here, the application does not perform a validation on the user provided amount before performing the changes. This means a user supplying the application with a negative amount such as “-500” would still pass the checks for ‘amount should be < or = User Balance‘, the value would then be used in the “Withdraw” method as ‘money = self.Balance – (-500)‘ which would lead to the user gaining an additional 500 in their account balance!

These are the best vulnerabilities to find in all sorts of assessments be it SCRs or Web Pentests as they require a solid understanding of business requirement of a flow and how to secure or exploit it. Most scanners don’t pick these up, which is why a manual Pentest is the only surefire way of finding them. This is the bread and butter of any great security assessor.

5. SQL Injection (SQLi)

This is a straightforward SQL Injection prone code. The application directly appends user queries to an SQL statement and executes it. There’s no sanitization, validation, prepared statements or any of the other remediating guidelines recommended to prevent SQLi. In short, everything that could be done wrong was done wrong.

The application grabs the id, stock and color parameters from the user.
Without any sanitization or validation, these parameters are appended to a query and the results are stored.

This is a commonly known vulnerability to both Beginners and Novice security professionals. The only way to remediate this is through the provided guidelines which can be found on literally every security blog or website.

SAST Automation Tools

Now there are a lot of SAST tools out there, both paid and open source, which support a wide variety of different languages which can be used for automated static testing of application code. These points out security flaws as well as quality issues that may make your code more efficient if you’re using paid subscription models to host your applications. Of course, no tool can offer full proof guidance due to varying pros and cons and ultimately without an experienced analyst behind it all to triage, validate, remediate and re-validate, the goal falls apart very quickly.

Tools

Checkmarx
Coverity
Klocwork
Semgrep
SonarQube
HCL AppScan
Bearer
Bandit
Brakeman

The pros and cons of each of these vary. So do the supported code types, detection mechanisms, supported vulnerability types. Frequency of accuracy of findings and much more. If you’d like a post discussing different offers for each of these please do let me know.

Conclusion: Why Choose HackSavior for SCR and SAST?

We understand the critical importance of Secure Code Reviews (SCR) and SAST in protecting your business from security breaches. Our team of experts ensures that your application is secure from development through deployment, minimizing risks and costs.

By partnering with HackSavior, you can rest assured that your code is thoroughly reviewed and your security posture is rock-solid, allowing you to focus on what matters most—growing your business.

References

Pratik Bulchandani

HackSavior