How Does the OWASP Top 10 Apply to C/C++ Development?

developer

The Open Web Application Security Project (OWASP) is a non-profit organization focused on improving web software security. Each year they publish a top ten list of the most critical web application security risks as an awareness campaign to keep developers informed and a continuing reminder of where improvements are needed. This is a popular reference guide for security but it is squarely aimed at web application developers. So, what are the key takeaways and guidance for C/C++ developers and developers not working with web applications?

OWASP Top 10

The top ten list from OWASP are literally the who’s who of web application vulnerabilities that, despite effort to improve the state of affairs, continue to plague web developers. On this list are the usual suspects of (SQL) injections, poor authentication and access control and misconfiguration. Although aimed at a different audience, there are takeaways for C/C++ and embedded device developers in this list.

In the following table, I’ve listed the top ten vulnerability along with the description provided by OWASP plus my assessment of whether these vulnerabilities apply to C/C++. When I mean “applies” in this case, I’m saying there are similar issues with C/C++ applications that are related to this type of vulnerability. Similarly, there’s an assessment as to whether static analysis tools are suitable for detecting these vulnerabilities. When some of these vulnerabilities are partially outside the scope of source code alone, I’ve marked them as such. For example, SQL injection flaws might not directly apply but the concept of injecting malicious data through user or external inputs is valid and tainted data analysis in modern, advanced static analysis tools can detect these types of problems. Let’s take a look at the Top 10:

Top 10 Vulnerability	Description	Applies to C/C++?	Detectable by Static Analysis?
A1 Injection	Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.	Yes	Yes
A2 Broken Authentication	Authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.	Yes	Partially
A3 Sensitive Data Exposure	Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes.	Yes	Partially
A4 XML External Entities	Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.	Yes	Partially
A5 Broken Access Control	Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.	Yes	Partially
A6 Security Misconfiguration	Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.	Yes	Partially
A7 Cross-Site Scripting	XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.	No	Partially
A8 Insecure Deserialization	Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.	Yes	Partially
A9 Using Components with Known Vulnerabilities	Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.	Yes	Yes
A10 Insufficient Logging and Monitoring	Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.	Yes	No

Applications of the Top 10 to C/C++ and Detection with Static Analysis

A1 Injection

Although the OWASP Top 10 injection vulnerability is related to SQL, injection vulnerabilities are still very much a problem with C/C++ applications. Command and code injection, in addition to SQL, is a real concern for C/C++ since it’s possible to hide malicious code to be executed via a stack overflow, for example. CodeSonar uses tainted data analysis to trace the flow of input data throughout the application to determine if it gets used, unchecked, in a potentially dangerous manner. Warnings such as SQL Injection, Tainted Buffer Access and Command Injection are examples of tainted data analysis warnings that CodeSonar provides.

A2 Broken Authentication

Any application or device that requires user authentication requires careful design. It’s common for embedded devices to ignore the importance of proper authentication, even to point of leaving default user and password settings enabled in deployed products. Although it can be difficult for static analysis tools to understand the intent of a poorly designed authentication scheme, tools can warn of potential pitfalls. For example, poor password encryption is a serious concern and warnings such as Plaintext Storage of Password, Use of crypt, Use of rand, Use of rand48 are indicate poor encryption implementations.

A3 Sensitive Data Exposure

Storing sensitive data is often overlooked when developers assume that malicious access to their application or device is unlikely. However, in the era of IoT and GDPR, storing any confidential data requires special consideration. Just as with authentication, static analysis tools can’t necessarily understand the intent of a poorly designed data storage. However, they can warn of poor implementation in terms of bad cryptographic practices (e.g. use of crypt() and rand() or rand48()) or even plain text storage. Tainted data analysis also plays an important role in helping detect poor privacy and storage implementation by tracing data input to potentially bad encryption techniques.

A4 XML External Entities

Although specifically highlighting XML external data, this vulnerability can apply to any application and by extension, to any input data type. Although old XML parser implementations are the particular target here, malicious formed input is a potential attack vector for any device or application. CodeSonar provides various tainted data warning to detect these vulnerabilities as mentioned above such as Tainted Buffer Access.

A5 Broken Access Control

Like other data exposure vulnerabilities, broken access control can lead to leakage or manipulation of key data, files and resources. Bypassing access controls provided by the underlying operating system, elevating privileges and unauthorized data access over APIs are all examples of this vulnerability. Examples of warnings from CodeSonar for these types of vulnerabilities are Tainted Filename, API abuse warnings such as MAX_PATH Exceeded, use of the realpath() function, etc.

A6 Security Misconfiguration

Configuration is a broad concern and an important security problem. Although much of the misconfiguration of C/C++ applications and embedded devices lie outside the source code, there are examples where misconfiguration can be detected in the code. For example, vulnerabilities exist in unneeded or unwanted operating system features, default accounts and passwords, insecure network configuration, and poor error handling. CodeSonar can detect well known insecure functions but can be easily modified to detect a customized list of unwanted functions or to search of specific default settings.

A7 Cross-Site Scripting

Cross-site scripting (XSS) is exclusively a web application issue but luckily static analysis tools can detect these vulnerabilities. However, embedded device developers need to be keenly aware of these issue if they plan to support web-based interfaces on their devices.

A8 Insecure Deserialization

Although serialized objects might be uncommon in C and embedded applications it is possible for attackers to manipulate input data in order to trigger code execution or a denial of service condition. In general, some of these vulnerabilities can be detected via tainted data analysis and the use of input data without proper validation.

A9 Using Components with Known Vulnerabilities

The use of libraries, open source and other third party code with known vulnerabilities remains one of the key problems with software security. CodeSonar can detect vulnerabilities in external source code, open source and third party binaries as well. Managing the software supply chain is a critical security activity.

A10 Insufficient Logging and Monitoring

Mishandling error conditions, or worse, missing them altogether is a critical security issue. To detect malicious activity, application logging is critical for in-use and post-mortem analysis. Although static analysis tools usually can’t these issues nor determine the nature of logging and monitoring, dynamic test tools can. For example, penetration test tools can trigger error conditions and the application’s response can be measured.

Summary

Although the OWASP Top 10 targets web application development, there are plenty of lessons to learn for C/C++ developers. The same general vulnerability categories plague any developer regardless of their programming language or deployment platform. Good security practices such as carefully examining all input data, ensuring secure configuration, using strong cryptography and carefully managing private data, apply across industries. Static analysis tools have good coverage of the Top 10 both in the web domain and in C/C++ with products such as CodeSonar.

Interested in learning more? Read our guide “Advanced Static Analysis for C++”