Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruff: Add and fix S110 (+ merge all S1 rules) #11256

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

kiblik
Copy link
Contributor

@kiblik kiblik commented Nov 13, 2024

Copy link

dryrunsecurity bot commented Nov 13, 2024

DryRun Security Summary

This pull request covers a variety of code changes in the DefectDojo application, focusing on improving error handling, input validation, logging, and security-related features across different components of the application, with the goal of enhancing the overall security posture of the application.

Expand for full summary

Summary:

The code changes in this pull request cover a variety of files and functionality within the DefectDojo application, a popular open-source web application for managing the software vulnerability lifecycle. The changes focus on improving error handling, input validation, logging, and security-related features across different components of the application.

Key security-related improvements include:

  1. Improved Error Handling: Several code changes simplify exception handling and remove the use of broad exception suppression, making the code more robust and transparent.
  2. Input Validation: The changes highlight the importance of properly validating user input to prevent potential security issues like SQL injection or cross-site scripting (XSS) vulnerabilities.
  3. Logging and Auditing: The changes enhance the logging and auditing capabilities of the application, which can be valuable for security monitoring and incident investigation.
  4. Security Headers: The addition of a middleware to set security-related HTTP headers, such as X-Frame-Options and Content-Security-Policy, can help improve the overall security posture of the application.
  5. Authentication and Authorization: The changes focus on strengthening user authentication and authorization mechanisms, ensuring that only authorized users can perform sensitive actions.

While the changes do not introduce any obvious security vulnerabilities, it's crucial to continue reviewing the entire codebase and considering the broader context of the application to identify and address any potential security risks.

Files Changed:

  1. dojo/cred/views.py: The changes simplify the code for deleting credentials and ensure that the necessary checks and authorizations are in place.
  2. dojo/finding/helper.py: The changes improve the handling of finding groups, including the management of group names and the association of findings.
  3. dojo/benchmark/views.py: The changes are a minor optimization that removes the use of contextlib.suppress() to handle exceptions.
  4. dojo/middleware.py: The changes enhance the application's security features, including user authentication, password management, logging, and the addition of security-related HTTP headers.
  5. dojo/product/views.py: The changes improve the error handling and reliability of the GITHUB integration functionality.
  6. dojo/tools/gitlab_api_fuzzing/parser.py: The changes enhance the parsing and handling of GitLab API Fuzzing report data, providing more detailed information about the found vulnerabilities.
  7. dojo/templatetags/display_tags.py: The changes improve the exception handling and data processing in the inline_image function.
  8. dojo/tools/h1/parser.py: The changes improve the error handling and readability of the build_description method in the HackerOneVulnerabilityDisclosureProgram class.
  9. ruff.toml: The changes to the Ruff linter configuration file indicate a focus on addressing security-related issues in the codebase.
  10. tests/Import_scanner_test.py: The changes simplify the logic in the test_engagement_import_scan_result function, improving its readability.
  11. dojo/tools/veracode/json_parser.py: The changes improve the robustness and reliability of the date parsing logic in the Veracode findings parser.
  12. dojo/tools/kiuwan/parser.py: The changes enhance the handling of CWE values and highlight the importance of input validation and sensitive information exposure.
  13. tests/base_test_class.py: The changes simplify the wait_for_datatable_if_content() function without introducing any significant security concerns.

Code Analysis

We ran 9 analyzers against 13 files and 1 analyzer had findings. 8 analyzers had no findings.

Analyzer Findings
Authn/Authz Analyzer 2 findings

View PR in the DryRun Dashboard.

@kiblik kiblik force-pushed the ruff_S1 branch 6 times, most recently from 586b87c to f8660e5 Compare November 13, 2024 18:53
@kiblik kiblik marked this pull request as ready for review November 13, 2024 18:54
Copy link
Contributor

@Maffooch Maffooch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of passing, could we get by on logging the exception? That seems safer than removing the exception handling altogether

@kiblik
Copy link
Contributor Author

kiblik commented Nov 19, 2024

Instead of passing, could we get by on logging the exception? That seems safer than removing the exception handling altogether

In general, I do not consider "suppressing exceptions and replacing them with writing to error log" as the best approach. Admins usually check logs only if there is wrong behavior or if they have some smart rules in their central monitoring. Simple ignoring of errors is not the best.

I made rewrites and I suppose I solved most of the cases which might be problematic.

  • dojo/benchmark/views.py: If benchmarks are not created, we should not silently ignore them. If they were only logged, it might bring frustration to users who do not receive any feedback, and just ignore the user’s input.
  • dojo/cred/views.py: I rewrite to a method that has the same outcome but without exception
  • dojo/finding/helper.py: Also ”no-exception” rewrite
  • dojo/middleware.py: Here catching makes sense but I decreased it to reasonable scope
  • dojo/product/views.py: Might be a good idea to test this but if there is an issue in the form, the user should be informed, not ignored
  • dojo/templatetags/display_tags.py: I believe I made a rewrite that avoids all reasonable situations
  • dojo/tools/gitlab_api_fuzzing/parser.py: Also ”no-exception” rewrite
  • dojo/tools/h1/parser.py: Also ”no-exception” rewrite
  • dojo/tools/kiuwan/parser.py: Also ”no-exception” rewrite
  • dojo/tools/veracode/json_parser.py: Also ”no-exception” rewrite
  • tests/Import_scanner_test.py: This is a test and it is not failing - so there is probably no problematic situation
  • tests/base_test_class.py: Also ”no-exception” rewrite (using of existing function)

But I’m happy for any feedback.

Copy link
Contributor

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Copy link
Contributor

Conflicts have been resolved. A maintainer will review the pull request shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants