The significance of software security cannot be emphasized enough in a modern digital world. Since businesses rely heavily on software to run their operations and offer services to their customers, these programs’ weaknesses can be quite dangerous. In the field of software security, The Open Web Application Security Project, better known as OWASP, has become a prominent player committed to addressing these problems and developing best practices.

OWASP, a nonprofit foundation established in 2001, is run by a large global volunteer network committed to enhancing software security. Their goal is to make software security visible so that people and companies can invest in protecting their applications in an educated manner. Developers, security experts, and businesses all over the world now rely on OWASP as a trusted resource.

In this article, we will highlight our most recent security audit and updates for the OpenIMIS project, a health insurance management system. It is advised that you first read our most recent piece, in which we addressed the critical function of a centralized Sonar pipeline configuration for more thorough understanding. This earlier post explores the Sonar assessment and how it may improve software security. Today, we will focus on how the centralized Sonar pipeline architecture efficiently detects and fixes OWASP vulnerabilities. Through the integration of both Sonar and OWASP ideas, this exploration demonstrates the scalability and versatility of such a structure while maintaining a comprehensive approach to software security.

Selecting the tools

Making the appropriate tool choice for OWASP compliance requirements is essential to enhancing software security. The decision should be made in light of a thorough understanding of the project’s unique requirements and any potential security issues. Take into account the development environment as well as the size and complexity of your application. 

Here are a few technologies that can help initiatives meet OWASP requirements and strengthen the security of their software:

ZAP (Zed Attack Proxy): A popular security testing tool used during the development and testing phases of online applications to identify vulnerabilities. It is renowned for being simple to use and having powerful scanning capability.

OWASP Dependency-Check: This program checks project dependencies for known flaws in external libraries. It’s essential for avoiding security problems brought on by outmoded or weak dependencies.

AppSensor: A tool and framework for in-app event detection and reaction in real time. It helps in quickly identifying and reacting to suspicious activity or attacks.

Amass: A flexible tool for obtaining information during the preliminary stages of security evaluations. It aids security experts in finding external resources, domain names, and subdomains that could serve as attack surfaces.

Defectdojo: A top application security program and vulnerability management solution. It enables management and tracking of security findings across the software development life cycle for enterprises.

Code Crawler: A static code analysis tool that aids software engineers and security experts in locating and resolving security flaws early in the software development cycle.

Security Knowledge Framework: An open-source web application that illustrates secure coding principles in a variety of programming languages. It’s an important tool for teaching development teams about security best practices.

SonarCloud/SonarQube: To cap off our discussion of security tools, we must emphasize the importance of Sonar tools.

Why Sonar tools?

Both SonarCloud and SonarQube include the same basic features and operating principles for code analysis, code quality management, and security evaluation. Their deployment model is the primary point of difference. 

SonarQube is an on-premises, self-hosted platform, whereas SonarCloud is a cloud-based service offered by SonarSource. SonarCloud provides less customization but is simple to set up and maintain. SonarQube, in comparison, demands self-hosting and management but gives more control. The needs and infrastructure of your project will determine which option you should choose.

In this article, we’ll specifically discuss SonarCloud, the tool we chose for one of our projects, OpenIMIS. It’s noteworthy to highlight that Sonar generously offers this tool for free to support open-source projects, and OpenIMIS falls into this category as an open-source initiative.

This remarkable tool not only offers an extensive array of security rules but is renowned for its strict adherence to the OWASP Top 10, a collection of the most critical web application security risks.

By concentrating on the OWASP Top 10, SonarCloud makes sure that it places a strong emphasis on minimizing widespread vulnerabilities like SQL injection, cross-site scripting (XSS), and exposed sensitive data. It assists project teams in securing their apps against the most common and harmful security attacks by actively fixing these vulnerabilities.

SonarCloud stands out for its capacity to offer useful insights that aid development teams in comprehending the nature of security concerns found and directing them toward efficient resolution. By doing this, it not only improves security but also helps firms develop a culture of secure coding practices.

Moreover, SonarCloud’s integration capabilities with CI/CD pipelines make it an invaluable asset for proactive security. By seamlessly fitting into the development workflow, it helps in identifying and addressing security issues early in the software development life cycle. This real-time feedback mechanism aligns with OWASP’s emphasis on “shifting left,” which encourages addressing security concerns as early as possible.

Rule Setup and configuration of SonarCloud

For a step-by-step tutorial on configuring and starting SonarCloud, please see our earlier blog post, where we cover the basic setup procedure. In this article, we will only address the Sonar OWASP issue.

For those looking to align SonarCloud with OWASP Top 10 compliance, the good news is that extensive customization is often unnecessary. SonarCloud already provides a comprehensive set of security rules designed to address OWASP Top 10 vulnerabilities. These predefined rules cover critical web application security risks such as SQL injection, cross-site scripting (XSS), and more. As the default configuration, SonarCloud employs these built-in rules, simplifying the process of enhancing software security right from the start.

In addition, Sonar provides helpful tools for comprehending where its security rules came from. The documentation contains information on which OWASP Top 10 category a certain rule belongs to. By navigating to any Vulnerability or Security Hotspot rule and scrolling to the “Resources” section of the SonarCloud documentation, you’ll discover a comprehensive reference specifying the OWASP Top 10 category associated with each rule. This feature empowers developers and security professionals to gain a deeper understanding of the vulnerabilities addressed by SonarCloud’s rules, facilitating more informed and targeted security assessments.

It’s crucial to stress that SonarCloud offers only a certain level of customisation, being less flexible than SonarQube. You are able to build custom profiles in SonarCloud, which are collections of guidelines tailored to a particular programming language, but customization involves only activating or deactivating built-in predefined rules for projects during code analysis. While some of these rules can be edited, the focus is primarily on coding practices, such as ‘Structures should not have too many fields,’ where you can state how many fields a structure can have. It can be challenging to find rules with security-related customization options.

Since customizing security rules in SonarCloud is limited, should your project or organization require more extensive customization, including creating entirely new rules or making deep modifications to existing ones, SonarQube is the preferred choice. SonarQube offers a more comprehensive suite of customization options, including the ability to define your own rules for a higher degree of flexibility. If you are interested in learning how to define your own rules in SonarCube, here is the link to the docs.

Yet, it’s very simple to create a custom profile in SonarCloud that meets the unique security requirements of your project. On the Sonar dashboard, select the “Quality Profiles” tab and then click “CREATE.” The programming language to which these rules apply will be shown to you as a prompt. An important choice to make is whether to inherit settings from existing profiles, benefiting from established rules, or start from scratch with an entirely new profile. While SonarQube customization enables the activation and deactivation of rules, it’s critical to remember that every decision to deactivate a rule must have a valid reason. You need to make sure that the justification for changing the profile is well-documented. This procedure supports openness and adheres to best practices for upholding the integrity and security of the code.

In summary, SonarCloud’s integrated security standards perfectly match the OWASP Top 10 to ensure security evaluations. However, SonarQube has the flexibility to meet your individual security requirements, if your project calls for additional guidelines or particular adjustments. Nevertheless, the built-in rules of SonarCloud act as a solid default basis, and this versatility makes it a robust and versatile tool for improving application security and compliance.

Testing, validation and limitations

The Sonar scans provide lots of data and a visual representation of project metrics on the Sonar project dashboard. Some of the main metrics are:

Code Smells: Flagging instances of poor code quality, such as complex methods, long classes, and duplicated code.

Bugs: Identifying actual coding errors that need to be rectified, such as null pointer exceptions and logical errors.

Duplicated Code: Spotting redundant code, which can pose maintenance challenges and elevate the risk of introducing bugs.

Complexity: Evaluating code complexity, spotlighting methods and classes that may be excessively complex and difficult to maintain.

However, the metrics of particular interest to us are:

Security Hotspots: Used by SonarQube to highlight potential security issues in the code. These are not known vulnerabilities, but areas that require more investigation. Consider them as red lights that should prompt developers and security professionals to further explore and evaluate whether a real security issue exists. Early detection of possible vulnerabilities through the use of security hotspots allows proactive remediation before the flaws become real risks.

Vulnerabilities: Vulnerabilities, on the other hand, indicate known security flaws in your code. These are actual defects or weaknesses that bad actors could take advantage of. These vulnerabilities, which include problems like SQL injection and cross-site scripting (XSS), are found and reported by SonarQube. In order to prevent security lapses and protect against data intrusions in your applications, vulnerabilities must be fixed right away.

Sonar is generally effective at detecting many OWASP-related security issues. However, there may be certain limitations and aspects that Sonar might not effectively detect or address:

False Positives: Sonar occasionally generates false positives, indicating code as vulnerable when it is not, like many automated code analysis tools. This may cause results to be noisy and necessitate manual validation.

Contextual Understanding: Sonar’s primary method of analysis is static, therefore it might not completely comprehend the context in which the code is used. It can result in issues with identifying certain complicated vulnerabilities, or produce false negatives.

Business Logic Flaws: Sonar is primarily focused on identifying common security vulnerabilities rather than business logic flaws, which may require manual testing or specialized tools.

Zero-Day Vulnerabilities: The rules and plugins for Sonar are based on known flaws and attack patterns. Until they are logged and added to its rule sets, it might not be able to detect brand-new or zero-day vulnerabilities.

Non-Code Security Issues: Sonar primarily concentrates on flaws at the code level. Other security concerns relating to server configuration, network architecture, or deployment environments might remain unnoticed.

OpenIMIS example

An illustration of SolDevelo’s efforts to achieve robust security within the OpenIMIS project is worth highlighting in this context. It is an open-source information management system that is crucial in making healthcare services more accessible in low- and middle-income countries. 

Dedicated to improving the quality of the system, SolDevelo engaged in a thorough security audit. The integration of SonarCube into each key repository on openIMIS GitHub served as the initiative’s cornerstone. It was a starting point for our effort to strengthen the openIMIS system’s security.

Initial SonarCloud scan results showed a frequent issue with security audits that many people encounter: false positives. In these cases, SonarCloud flagged code as susceptible even though it didn’t actually represent a risk. The discovery of hardcoded credentials in test scripts is an illustration of this. Despite not actually posing a security risk, SonarCloud’s strict analysis identified these instances as mistakes.

The human element enters the picture at this point. To discern between real security vulnerabilities and false alarms, auditors, developers, and security specialists must apply their knowledge and judgment. Their comprehension of the particular project context and the complexity of the openIMIS system is priceless.

The next step was to carefully sort through these findings to identify the security-important vulnerabilities and select the ones that need immediate response. This marked the beginning of our process of refinement, where we aimed to focus on real and pertinent security issues. In due course, we transitioned to creating the tickets for tracking these vulnerabilities and systematically addressing them. It’s this human touch that ensures the prioritization of security concerns based on real-world risks.

It’s worth noting that some of the problems related to unsafe HTTP and hardcoded password detection occur in test examples, primarily using mock data rather than real data. Nevertheless, these findings offer valuable insights into areas that warrant attention and improvement in the OpenIMIS codebase.

On the other hand, frontend modules look good when it comes to the security aspects. There are some errors in the assembly module related to docker files and regular expressions that need to be reviewed. The difference in the number of Sonar checks or hotspots to review between the backend and frontend of an application can be influenced by various factors, and it’s not necessarily an indication of the security of one part of the application over the other. 

Generally speaking, no vulnerabilities were identified in any of the Sonar scans conducted across all modules. Instead, the scanning process generated hotspots for review.

Here are some of the findings and remediations for OpenIMIS modules. For a more comprehensive view, please refer to the Confluence page where the entire report is available.

openimis-be_core_py BE

OWASP A01:2021-Broken Access Control – openimis-be-core_py BE

By adding the @require_GET decorator, we explicitly specify that only safe HTTP methods (i.e., GET and HEAD) are allowed for this view. This helps ensure that the view can only be accessed using read-only methods, as intended.

OWASP A03:2021-Injection – openimis-be_core_py BE

We optimized the regular expression pattern by reducing backtracking. In this optimized pattern, we’re using positive lookbehind (?<=[a-z0-9]) to ensure that the position we’re looking at is preceded by a lowercase letter or a digit, and then we’re using a positive lookahead (?=[A-Z]) to ensure that it’s followed by an uppercase letter. This should help reduce backtracking and improve performance, addressing the security concern.

openimis-be_product_py BE

OWASP A03:2021-Injection – openimis-be_product_py BE

We optimized the regular expression pattern by reducing backtracking. In this optimized pattern, we’re using positive lookbehind (?<=[a-z0-9]) to ensure that the position we’re looking at is preceded by a lowercase letter or a digit, and then we’re using a positive lookahead (?=[A-Z]) to ensure that it’s followed by an uppercase letter. This should help reduce backtracking and improve performance, addressing the security concern.

openimis-fe_claim_js FE:

OWASP A03:2021-Injection – openimis-fe_claim_js FE:

The error related to the Department of Service (DoS) might be due to the usage of a regular expression that is potentially vulnerable to super-linear runtime and backtracking, which could lead to performance issues or even denial of service in certain cases. The DoS might have strict security guidelines in place, and using regular expressions with these characteristics could be considered a security risk.

The issue with the regular expression is the use of the \B assertion, which asserts a position where there’s no word boundary. This can lead to backtracking, especially in cases where the input string is large, potentially resulting in poor performance.

To fix this issue and satisfy DoD requirements, we used a more efficient and non-backtracking regular expression pattern, like the solution provided earlier.

Learning and best practices

They say that “prevention is better than cure,” and it is especially true in the fields of cybersecurity and software development. The significance of prioritizing security from the outset is underscored by the fact that proactive methods to discover and mitigate security vulnerabilities at the early phases of development are significantly more cost-effective and efficient than fixing security breaches and faults after they have occurred. To assist you in including security into your software projects from the outset, we’ve prepared a list of essential requirements for each OWASP category.

A01:2021-Broken Access Control

• Enforce authorization and implement appropriate access constraints.
• Make sure users can only access resources and carry out approved actions.
• Apply security regulations uniformly throughout the application.

A02:2021-Cryptographic Failures

• To protect sensitive data, use cryptographic algorithms and robust encryption.
• Make sure to use safe key management procedures.
• Defend against known vulnerabilities and cryptographic flaws.

A03:2021-Injection

• To stop injection threats (such as SQL injection and OS command injection), implement input validation and output encoding.
• For database queries, use prepared statements or parameterized queries.
• Avoid dynamic commands or searches built from user input.

A04:2021-Insecure Design

• Beginning with the application’s design, consider security.
• To find potential security issues early in the development process, use threat modeling.
• Implement appropriate access controls and security architecture.

A05:2021-Security Misconfiguration

• Implement secure default settings.
• Review and update configurations frequently to reduce security flaws.
• Keep sensitive information from being displayed in error messages or by improperly configured permissions.

A06:2021-Vulnerable and Outdated Components

• Update all of the components (libraries, frameworks, and dependencies).
• To find known weaknesses in components, use a dependency checker (like OWASP Dependency-Check).
• Components having known vulnerabilities should be removed or changed.

A07:2021-Identification and Authentication Failures 

• Set up reliable user identification and authentication systems.
• When necessary, employ multi-factor authentication (MFA).
• Avoid typical flaws that allow for authentication bypass.

A08:2021-Software and Data Integrity Failures 

• Implement secure data transmission (like HTTPS) to ensure data integrity.
• Ensure that data is not altered while it is in transit or at rest and take precautions against data manipulation.
• Use cryptographic hashes to check the accuracy of your data.

A09:2021-Security Logging and Monitoring Failures

• Implement efficient security incident and event logging.
• Make proactive arrangements for monitoring and alerting for atypical or suspicious activity.
• Keep logs in a secure location and check them frequently for security flaws.

A10:2021-Server-Side Request Forgery

• To stop harmful input, validate and sanitize user input.
• Avoid enabling direct requests from user-supplied URLs to internal resources.
• Use allowlists or particular whitelists to manage accessible external resources.

To ensure that the project is thoroughly secure, it’s recommended to consider the following:

OWASP Application Security Verification Standard (ASVS): To achieve a comprehensive level of security, the project should aim to pass the official OWASP ASVS. This standard provides a detailed checklist of security controls and verification requirements. OWASP Application Security Verification Standard | OWASP Foundation 

OWASP Web Security Testing Guide: A valuable reference on performing security testing and assessments beyond what automated tools like Sonar can offer. It provides insights into various testing techniques and methodologies. OWASP Web Security Testing Guide | OWASP Foundation 

Vulnerable and Outdated Components (A06:2021-Vulnerable and Outdated Components): Note that Sonar may not effectively detect this category of vulnerabilities. To address it, consider using the OWASP Dependency-Check tool, available on the OWASP website. This tool helps identify and manage vulnerable components and libraries in your project’s dependencies. OWASP Dependency-Check | OWASP Foundation 

By combining the capabilities of Sonar with these additional measures and tools, you can enhance the security of the project and minimize the risk of OWASP-related vulnerabilities going undetected.

Conclusion

In this examination of OWASP guidelines and the implementation of SonarCloud, we’ve unearthed the foundations of strong application security. The importance of rules in Sonar, early vulnerability identification, and successful handling of the problem of false positives are some of the more important lessons learned. As we have already stressed, protecting your software requires continual dedication in order to keep ahead of developing threats.

What’s Next? Exploring SAST/DAST Compliance

But we’re not done improving the security of your software just yet. The dynamic world of SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) compliance will be covered in our upcoming blog post. These methods provide a thorough and proactive plan to defend your program against new threats. Stay tuned as we explore the nuances of application security testing in greater detail, providing you with the information and resources you need to keep your projects secure.