2023-10 OWASP Compliance Report
Content
Content
Overview
Date | 2023-10-09 |
---|---|
Status | wip |
Release | |
TestType | Static Code Analysis |
TestTopic | Security |
Context | |
Tester |
A01 | YES | |
---|---|---|
A02 | yes | |
A03 | yes | |
A04 | No | |
A05 | no | |
A06 | NO | |
A07 | yes | |
A08 | NO | |
A09 | NO | |
A10 | NO |
Methodology
Automated scans that incorporate OWASP standards are performed using the SonarCloud tool within the openIMIS organization. These OWASP checks, derived from the top 10 security requirements, are implemented by default before we commence the process of evaluating and ensuring the security posture of our projects. These predefined rules can be conveniently accessed through the "Rules" tab in the SonarCloud interface.
In the field of information technology, upholding industry standards stands as a crucial pillar in the endeavor to secure software applications and systems. Among these standards, the Open Web Application Security Project (OWASP) Top Ten holds an esteemed reputation as a yardstick for sound security practices. Annually, this list spotlights the ten most critical security vulnerabilities that organizations developing and managing web applications grapple with.
Addressing the OWASP Top Ten requirements is not merely a recommended practice; it's a foundational step in fortifying software against the ever-present threat of cyberattacks. These requirements encompass a range of vulnerabilities, from injection attacks to broken authentication and security misconfigurations. Compliance with these standards extends beyond best practices; in many instances, it is a regulatory mandate across various industries. Organizations are thus compelled to adopt stringent measures, including input validation, robust authentication mechanisms, and rigorous access controls, to effectively mitigate these security risks. By aligning their strategies with the OWASP Top Ten requirements, businesses signal their unwavering commitment to safeguarding sensitive data and minimizing the perils of data breaches and cyberattacks. This proactive stance not only safeguards their valuable assets but also nurtures trust among customers and partners, contributing significantly to the overall resilience and security of the broader IT landscape.
Result Summary
In summary, our automated tools have highlighted that the majority of security concerns are related to two key areas:
Defining regular expressions in a manner that might slow down the system (a potential security risk).
Issues related to Cross-Site Request Forgery (CSRF) protections not being enabled (another critical security concern).
Issue | Severity |
---|---|
Defining slow regular expressions | Potential Security Risk |
Cross-Site Request Forgery (CSRF) protections | Critical Security Concern |
Here's why defining regular expression in bad way is considered a security-sensitive issue:
Performance Impact: Regular expressions that are intentionally slow can be used as part of a denial-of-service (DoS) attack. By crafting input in a certain way, an attacker can force the system to spend excessive time processing the regex, potentially leading to a slowdown or even a system crash. This could disrupt the normal operation of a web application or service.
Resource Exhaustion: Slow regular expressions can consume excessive CPU and memory resources. If an attacker can trigger many such regex operations concurrently, they could exhaust the server's resources, making it unavailable for legitimate users.
Availability: Attacks on system availability can have security implications. For example, if a web application becomes unavailable due to a regex-based DoS attack, it may impact users' ability to access critical services, potentially leading to data breaches or other security incidents.
Sonar's detection of "Issues related to Cross-Site Request Forgery (CSRF) protections not being enabled" in Django REST framework (DRF) endpoints can occur for a few reasons, even though CSRF protection is typically enabled by default in Django. Here are some potential explanations:
Custom Configuration: If your Django project has custom configuration settings that modify the default behavior of CSRF protection, Sonar may not be aware of these changes. Sonar typically analyzes code statically and may not fully understand runtime configurations.
False Positives: Code analysis tools like Sonar sometimes produce false positives, indicating issues that don't actually exist. It's possible that Sonar is misinterpreting your code as lacking CSRF protection when it is, in fact, correctly implemented.
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 our codebase. Furthermore, there are specific Docker-related issues that require a more in-depth examination. These issues are also discussed in detail within this document.
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.
It's important to note that the number of hotspots or issues identified by Sonar should not be the sole criterion for evaluating the security of a codebase. The criticality of the issues, their impact, and the context of the application should also be considered when prioritizing and addressing security concerns. Both backend and frontend security are essential, and it's crucial to conduct a comprehensive security review across the entire application to ensure its overall security posture.
Generally no vulnerabilities were identified in any of the Sonar scans conducted across all modules. Instead, the scanning process generated hotspots for review.
Remediation
Title | Link | OWASP Category | Comment/Explanation |
---|---|---|---|
OWASP A03:2021-Injection - openimis-fe_policyholder_js FE | A03:2021-Injection | The Sonar issue is raised because the regular expression used in our code can lead to denial of service due to its vulnerability to super-linear runtime caused by backtracking. This is a security concern as it might make your application vulnerable to attacks that exploit this regex's inefficiency. To fix this issue, we modified the regular expression to make it more efficient and less prone to backtracking. One way to do this is by using a non-capturing group to make the expression more deterministic. The modified regular expression (?:[^\s@]+@[^\s@]+.[^\s@]+) should work in the same intended way as the previous one, while addressing the security issue. It maintains the same email address validation pattern and functionality while making the regular expression more efficient and less prone to super-linear runtime caused by backtracking. | |
OWASP A01:2021-Broken Access Control - openimis-be-core_py BE | A01:2021-Broken Access Control | By adding the | |
OWASP A03:2021-Injection - openimis-be_product_py BE | A03:2021-Injection | 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. | |
OWASP A03:2021-Injection - openimis-be_core_py BE | A03:2021-Injection | 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 | |
OWASP A03:2021-Injection - openimis-fe_admin_js FE | OWASP A03:2021-Injection | We replaced the regular expression with a non-backtracking variant while maintaining the functionality. In this specific case, the regex is used for formatting a number with commas for better readability. We used a non-backtracking regex to achieve the same result. The provided solution works in the same way as the original code. It formats the number by adding commas for better readability, just like the original regex. The change made is designed to address the security issue while preserving the intended functionality. | |
OWASP A02:2021-Cryptographic Failures - openimis-be-policy_notification_py, openimis-be-claim_ai_py - BE | OWASP A02:2021-Cryptographic Failures | I reviewed all of the points raised by sonar related to this topic.
We don’t need to add any changes in code. | |
A07:2021-Identification and Authentication Failures - openimis-be-core - BE | A07:2021-Identification and Authentication Failures |