This article is the second in a four-part series discussing the differences between traditional IT security / cybersecurity and blockchain security. Check out the first article in the series discussing the differences for node operators.
This article focuses on the differences between application security (AppSec) for traditional applications and smart contracts. While the first blockchains, like Bitcoin, were not designed to support smart contracts, their invention dramatically expanded the capabilities of blockchain platforms. The ability to deploy code on top of the blockchain has been one of the main drivers of blockchain’s widespread adoption and success.
Traditional Development vs. Smart Contract Development
Traditional applications and smart contracts can implement much of the same functionality. Smart contract platforms are Turing complete, and, on some of them, smart contract developers can use the same programming languages as for traditional application development.
However, traditional applications and smart contracts operate in very different environments. Some of the big differences include the following:
- Infrastructure Stack: Most applications run directly on top of the operating system. Smart contracts are more like web applications, code that runs within the context of another application. This design places constraints on the smart contract’s capabilities and the increased complexity creates more opportunities for exploitable vulnerabilities.
- Immutable Ledger: Traditional applications have mutable code and data that are stored on a private server. Smart contract code and data are stored on an immutable digital ledger that is publicly visible.
- Languages and Ecosystems: Traditional application development is often performed with well-established languages on stable platforms. Many smart contract platforms use programming languages and virtual machines designed specifically for them that are relatively new.
The same program can be written as a traditional application or a smart contract. However, the differences between the two programs’ operating environments mean that they face very different security risks and secure coding best practices can vary greatly.
Traditional vs. Blockchain AppSec
Application security (AppSec) is a priority in both IT and blockchain environments. In fact, AppSec is even more vital on the blockchain due to the multiple layers of application code that can exist, including the blockchain software itself and smart contract code that runs on top of blockchain platforms.
However, the challenges of securing applications differ significantly between IT and blockchain environments. Some common AppSec techniques in the traditional IT space include the following.
Most of the IT systems and protocols that we rely on today have been around for decades and have undergone extensive security research. While new vulnerabilities are discovered on a regular basis, many of these are simply new iterations of well-known programming errors. The fact that the OWASP Top Ten list has changed very little since its initial introduction makes this evident.
Blockchain and smart contract platforms, on the other hand, are much newer. Bitcoin, the first blockchain, was introduced in 2008, and Ethereum pioneered smart contracts in 2015. Smart contracts and decentralized finance are reliant on technologies that are less than a decade old, and many Ethereum competitors are much younger.
The relative immaturity of smart contract platforms means that many of the top platforms have received limited security research and entire classes of vulnerabilities may not have been discovered yet. Additionally, most smart contract platforms are still under development, meaning that new types of vulnerabilities may be introduced over time. As a result, ensuring that an application is secure is much more difficult in the blockchain space.
Ecosystem Fragmentation and Stability
Application developers write code for a variety of environments, including desktop OSes, mobile devices, and browsers. However, only a few platforms of each type exist (especially when considering *nix platforms as a single group), and the platforms are relatively stable. As a result, developers know how various platforms work and best practices for developing secure code for them.
The smart contract ecosystem is much more fragmented and unstable. While some platforms, such as Ethereum, have developed an early lead and a strong community, technological changes may eventually render them obsolete. At the same time, new platforms are being developed and are competing for dominance.
The lack of ecosystem stability in smart contract environments makes it more difficult for developers to create secure, stable applications. Changes to a smart contract platform’s design could undermine the security of deployed code, or a smart contract platform could lose the fight for dominance, bringing down the contracts that it hosts with it. Additionally, the youth and lack of stability in the smart contract ecosystem means that smart contracts may be written by developers with limited experience with a platform and its secure coding best practices.
Proprietary vs. Public Code
Organizations commonly take extensive measures to keep their application code and intellectual property secret. Applications are commonly closed-source and use obfuscation and legal protections to attempt to deter reverse engineering and attempted exploitation. By making vulnerabilities more difficult to find, these organizations raise the bar for attackers looking to exploit these vulnerabilities.
Smart contract code is deployed on the blockchain, making the compiled code publicly accessible, and disassemblers are available for some platforms. Additionally, the source code of many smart contracts is posted and linked on GitHub
The open-source nature of smart contract code makes it easy for other developers to reuse existing code, which may contain exploitable vulnerabilities. It also makes it easier for attackers to find vulnerabilities to exploit. Source code is easier to read and comprehend, and many of the smart contract security tools are designed for static code analysis, which requires source code access.
Operating Environment Privacy
Traditionally, applications run on a server that is under an organization’s control. Managing access to this server is a core component of a corporate security policy. By doing so, an organization limits the information available to an attacker, including the code and data used by the application.
Smart contracts run on top of the blockchain, and all of their code and data are recorded in the blockchain’s digital ledger. As a result, all information available to the smart contract is also visible to a potential attacker or malicious smart contract.
Writing code that runs in a public environment is very different from writing code for a private server, and secure coding best practices differ for each. For example, in traditional IT, seeding a cryptographically secure pseudorandom number generator (CSPRNG) with a random value to generate secure random numbers is best practice. For a smart contract, this is a classic example of a weak randomness vulnerability as the “secret” seed would be publicly visible on the blockchain and anyone could generate the same series of values, breaking the smart contract’s security.
Many of the applications that an organization uses are not designed to be exposed to the public Internet. Firewalls are commonly used to limit access to internal applications by restricting the types of traffic that can cross a network boundary. By limiting access to their applications, companies make it more difficult for attackers to gain the access and permissions required to exploit any vulnerabilities that may exist.
In contrast, most smart contract platforms are public, permissionless blockchains. Anyone can create an account on the blockchain and interact with any deployed smart contract. Additionally, smart contracts can interact with one another, allowing a malicious smart contract to exploit vulnerabilities in other smart contracts.
Without any external access control, smart contracts must implement access management internally. Smart contract functions must include access controls that restrict access to privileged functionality as an attacker can execute any publicly accessible function.
Reactive vs. Preventative Security
In traditional IT, application security management is often focused on threat detection and response rather than prevention. In many cases, applications and systems can be restored to a secure state after an attack has occurred. Additionally, vulnerabilities are often handled via updates and patches to code deployed in production.
Blockchain immutability means that smart contract exploits cannot be easily reversed, and deploying updates to code is difficult unless the code is designed to be updatable. Additionally, all security features must be built into smart contract code since no equivalent to a web application firewall (WAF) or intrusion prevention system (IPS) exists for smart contract environments. As a result, smart contract threat management must focus on prevention rather than detection and response.
Security Tool Availability
As mentioned previously, traditional IT applications operate in relatively stable ecosystems, and many of the common vulnerabilities have already been identified. As a result, numerous solutions exist to help identify vulnerabilities and protect against exploitation.
Smart contract environments’ relative immaturity means that smart contract developers and blockchain security specialists have fewer tools available. While solutions exist for established platforms such as Ethereum, they still fall short of the available solutions for web application developers. For developers on newer and less established platforms, vulnerabilities may be totally unknown and solutions non-existent.
Without tools to automate the vulnerability discovery process, securing smart contracts becomes more reliant on individual knowledge and manual effort. As a result, security audits are even more important in the blockchain space than they are for traditional IT environments.
Regulations and Best Practices
For traditional IT security, regulations, standards, best practices, and guidelines are often readily available. For example, web application developers can use the OWASP Top Ten List, CWE Top 25, and applicable regulations, such as PCI DSS for sites processing payment card data, as references for common vulnerabilities and security best practices. While regulatory compliance requirements can be a headache, they are also a valuable resource for ensuring that common vulnerabilities are covered.
Blockchain developers, on the other hand, have much less access to security guides and resources. While some platforms, such as Ethereum, provide listings of known vulnerabilities, this is not true of all platforms. Additionally, no universal regulation or standard exists for blockchain and smart contract security. As a result, it can be more difficult for developers to validate that their code is actually secure and compliant with best practices.
Developing Secure Smart Contracts
Smart contract development is very different from traditional application development. These contracts operate in a unique environment and face very different security risks. At the same time, security research and tools have not caught up, making it more difficult to identify and fix vulnerabilities in these contracts.
The high risks associated with smart contract vulnerabilities make secure coding and threat prevention more important than ever. Adoption of DevSecOps best practices can help smart contract developers to identify and remediate potential security risks in their code before it is deployed to the immutable digital ledger. Additionally, all smart contracts should undergo security audits before launch to help identify and remediate potentially exploitable vulnerabilities.
This article is the second in a four-part series exploring how security differs between traditional IT and blockchain environments. Check out the first article in the series here, and keep an eye out for upcoming articles discussing how blockchain security differs for users and Security Operations Centers (SOCs).