How the $170 million Ethereum bug could have been prevented
Disclosure: Codacy, the automated code reviews platform, has previously sponsored Hacker Noon. For Hacker Noon readers, theyâre offering 15% off using this code: HACKERNOON.
There have been a spate of high profile security breaches in recent years. These include Ashley Madison, Telegram, and BitFinex, but most significantly Equifax and Yahoo!.
Together, these breaches exposed the records of well over 4 billion private individuals. As you can imagine, in their wake security has been getting a significant level of increased attention.
And so it should. The internet, and the services which run atop it have become so essential to the functioning of modern life. When things go wrong there, they can have disastrous consequences for so many people.
So as software developers we appreciateâââmore than ever beforeâââthat if we create an application which is accessible via the internet, then it is a potential target.
That said, application security isnât always easy to implementâââespecially when working for pointy-eared-bosses who place tight time and budget constraints upon us.
But just like testing, securityâs something that we have to accept responsibility for, because weâre the ones who write the code.
Luckily for us though, as with using testing tools to help us thoroughly test our code, there are tools available to help us find potential security vulnerabilities. Theyâre called static code analysis tools.
What is Static Code Analysis?
If youâve not heard the term before, according to OWASP, static code analysis:
Commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within âstaticâ (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.
These tools, as the description indicates, donât just find security vulnerabilities. They can also scan for a wide range of other problems, including coding standard violations, unused code, performance problems, and error-prone code.
Regardless of the software language(s) that you use, there are a number of static analysis packages available for it. And in addition to these packages there are a range of online services, often able to scan multiple languages and frameworks.
Hereâs a short list for PHP (as itâs the language with which Iâm most intimately familiar):
- OWASP WAP: Web Application Protection
- Side Channel Analyzer: Static Analysis for Detecting Side-Channel Vulnerabilities in PHP applications
- psecio/parse: A static scanning tool to review your PHP code for potential security-related issues
- PHP-malware-finder: Attempts to detect obfuscated/dodgy code as well as files using PHP functions often used in malwares/webshells
- progpilot: A static analyzer for security purposes
- Codacy
With all these libraries and services, youâd be forgiven for thinking that static code analysis would be a panacea for your security problems? For example;
- Write your code
- Run an analyzer
- Correct what it finds
- Youâre done!
And in some ways this process is just such a panacea. But it is not without limitations as well; limitations you need to be aware of.
These include:
- Identifying false positives and negatives during software scans. It can be hard to analyze code in the context of a larger codebase. For example, how do you validate all calls to a function and what parameters are passed to those calls? How do you programmatically validate a function which is part of a larger call-chain?
- Difficulty detecting hard to find vulnerabilities, such as access control errors and misconfigurations. Itâs common for aspects of an application to be configuration-based. A prime example is configuring access control lists. If the application being scanned is built this way, and a static code analyzer is only checking code, it may report the application as containing no known vulnerabilities, but miss an ACL misconfiguration. Whatâs more, how can a static analyzer fully understand ACL lists?
These are just two drawbacks to bear in mind when working with static code analysis; there are others. That said, static code analysis is an excellent way to automate the process of identifying an extensive range of security issues, well before your clients and users encounter them.
While not perfect (but what is) it goes a long way to finding issues with your code, that would not normally be detected consistently and predictably.
Static Code Analysis Has Other Benefits
Getting back to the positives, in addition to finding security problems, static analysis tools can also be used to educate developers about security issues and about how to write more secure code.
Well designed ones will not only find valid problems, they will also explain why the problem was identified.
Secondly, they can help the team grow a sense of trust in the security-readiness of the software that theyâre producing. Theyâre not a panacea, but they can still help to know that quality is improving.
Thirdly, theyâre automatable, as they can be integrated with your teamâs development tools. These include IDEs such as PhpStorm, and development pipelines such as Phing, Ant, Make, Codeship, and Capistrano.
For example, you could integrate WAP as a run configuration in PhpStorm, and run it intermittently. You could also integrate it as part of a Git commit hook.
Integrating them with existing tools and workflows will help ensure that theyâre used consistently. As we all know, if somethingâs too hard to setup or to use, itâs likely going to be avoidedâââeven if itâs the best tool in the world!
One Thing To Remember!
By now, you may be thinking that the essential thing to scan is your applicationâs code. And youâd not be wrong. But do we write code in isolation? Do we ever write code that doesnât have external dependencies?
Iâd suggest that unless itâs a very small script, then it will always have at least one dependency, if not several. Looking specifically to the language which I spend most of my time with, PHP, Iâd say that, more often than not, theyâre going to have at least one very obvious dependencyâââapplication frameworks.
If you take a look at some of PHPâs top frameworks (Laravel, Zend Framework, and Symfony), you can see that each of them has at least a handful of vulnerabilities, which can lead to exploits. If youâre using Ruby, what about Ruby on Rails? If youâre using Python, what about Django?
This isnât meant as a hack job on any one of these frameworks. I mention them just to point out that you have to be holistic in your security thinking. Make sure that you check your external dependencies and frameworks to see if they have vulnerabilities which need patching.
A Step-through Example
Now that weâve had a good introduction to static code analysis and started considering what to scan, letâs work through how to use static code analysis to find and resolve security issues in our code.
In this example weâll use Codacy to scan the Laravel framework codebase, PHPâs most popular application development framework.
Weâre not going to go too deep into Codacy. Weâll just stick to the essentials of what we need to know so that you get a broad overview of how the service works and how scans work. If youâd like to explore further however, feel free to do so.
First: Import the project into Codacy
To get your project into Codacy, the first thing that you need to do is to import it. This is quite trivial if your Codacy account is linked to either a GitHub or Bitbucket account.
If so, as you can see in the image above, scroll through the list of projects, and check one or more of them that you want to import.
After that, the projectâs code will be reviewed, cloned, and analyzed. Depending on the size of the project, this may take a bit of time.
For what itâs worth, I imported a large project yesterday, which took about 15 minutes to prepare. However, Iâve never found the import process to take more than about 3â5 minutes normally.
Second: View The Security Vulnerabilities
Once the projectâs completed, youâll be redirected to the projectâs dashboard, which you can see above. As Codacy performs a wide-range of static code analysis, not just for security problems, youâll see project analysis for a number of those areas.
However, you can see a birds-eye-view security score on the lower left-hand side of the dashboard, just above âOpen Pull Requestsâ.
To view, the security vulnerabilities click âSecurityâ in the left-hand navigation menu. There, youâll see the 15 categories which Codacy uses to classify security problems; including Auth, CSRF, DoS, SQL Injection, and XSS.
Only categories marked with a red cross contain security problems.
One thing to bear in mind; not all of the security patterns are enabled by default. This can be a good thing, depending on your projectâs age. In the example Iâm using, which is Laravel, this is not an issue.
You can see that it performs quite well, as youâd expect. However, it does show problems in File Access, Input validation, Other, and Regex. Looking in âOtherâ, you can see that one issue has been flagged in one file. The other categories only refer to the same file.
On a side note; as a PHP enthusiast, Iâm proud that no PHP-issues were found.
Three: View An Issue
Looking at the issue, you can see that itâs highlighted âGeneric Object Injection Sinkâ as the problem in public/js/app.js. Expanding it out further, you can see quite a detailed description of why the issue has been flagged and what it may mean.
Itâs worth noting here, again, that highlighted issues may be false positives or false negatives. So you have to be discerning when reviewing issues and determine if they are actually an issue or not.
Four: Fix an Issue
When youâve found a genuine issue, something which needs fixing, you can begin doing so from the dashboard. Codacy helps you in two ways. Firstly, the dashboard gives you an estimate of the time it would take to fix. In this bugâs case, itâs anticipated that it should take no longer than 15 minutes to fix.
Secondly, you can create an issue in either GitHub or Bitbucket directly from the issue. By clicking âSettingsâ (the cog icon next to âView Fileâ) ->âGitHubâ -> âCreate Issueâ a popup window appears, which you can see below.
The window contains a default issue title, pre-filled with the identified issue, and a message with some default information, including the message, commit hash, file name, and line number.
From there, you can then resolve the issue with a future pull request, and then rescan the codebase to ensure that the issue is no longer reported.
Wind Up
And thatâs been a rapid introduction to static code analysis, how it can be integrated into one or more places in your development tools and workflow, as well as a working example of how to use it to identify (and stay abreast) of security vulnerabilities within your application.
If this is your first time hearing about the concept and the tools, I strongly encourage you to have a look through the supplied list of tools, along with the links in the further reading section.
That way, youâll progressively expand your knowledge and awareness of how to develop more secure, more robust software. If youâd like to know more about Codacy, feel free to sign up for a 14-day trial, and begin analyzing your applications.
Read more articles on The Codacy Blog.