Wizcli improvements#12446
Conversation
|
This pull request contains multiple security vulnerabilities, including potential information disclosure in error logging, a possible denial of service risk through resource exhaustion, and a hardcoded service account key in test data, which could expose sensitive credentials and system information if not properly addressed.
|
| Vulnerability | Potential Information Disclosure in Error Logging |
|---|---|
| Description | Error messages in the Wizcli directory parser include exception details. If these logs or exceptions are not carefully handled, they could expose internal system information. Implementing more generic error messages and ensuring proper exception handling is recommended to mitigate potential information disclosure. |
django-DefectDojo/dojo/tools/wizcli_dir/parser.py
Lines 1 to 66 in ae1cd2a
⚠️ Potential Denial of Service via Resource Exhaustion in dojo/tools/wizcli_img/parser.py
| Vulnerability | Potential Denial of Service via Resource Exhaustion |
|---|---|
| Description | The get_findings method reads entire file contents without size limits, which could lead to memory exhaustion if a very large file is processed. Implementing file size limits and streaming parsing techniques would help prevent potential denial of service attacks. |
django-DefectDojo/dojo/tools/wizcli_img/parser.py
Lines 1 to 73 in ae1cd2a
⚠️ Hardcoded Service Account Key in unittests/scans/wizcli_img/wizcli_img_one_vul.json
| Vulnerability | Hardcoded Service Account Key |
|---|---|
| Description | A GCP Service Account Key is present in the test JSON file. Even in test data, hardcoding service account details poses a security risk. Ensure that such sensitive credentials are never committed to version control, even in test fixtures, and use secure secret management practices. |
django-DefectDojo/unittests/scans/wizcli_img/wizcli_img_one_vul.json
Lines 1 to 387 in ae1cd2a
All finding details can be found in the DryRun Security Dashboard.
✅ Test Scan Results – Parser Behavior & Deduplication1.
|
valentijnscholten
left a comment
There was a problem hiding this comment.
Thank you @OsamaMahmood for your extensive PR. We do have some feedback:
- Could you look at updating the tests/samples scans to reflect the updates to the parsers?
- Could you look using the hash code configuration for deduplication?
I just raised #12463 to clarify the use of the unique_id_from_tool field. It's intended/accepted use is to contain value present in the report that can be used to recognize the finding inside the tool. And for strong and exact deduplication.
We will discuss internally if/how we can accomodate values computed by the parser that might be useful for deduplication.
Hi @valentijnscholten i have updated the |
|
This pull request introduces potential information disclosure risks through detailed metadata and error logging in Wizcli parsers, which could expose internal system information if logs or interfaces are not properly secured.
Sensitive Scan Metadata Exposure in
|
| Vulnerability | Sensitive Scan Metadata Exposure |
|---|---|
| Description | The changes to Wizcli parsers introduce detailed metadata fields like file paths, line numbers, and component details. While not an active exploit, these fields could expose internal system information if not properly handled. The risk is primarily in potential downstream exposure through application interfaces or logs. |
django-DefectDojo/dojo/settings/settings.dist.py
Lines 1345 to 1353 in 715d098
Potential Logging Information Disclosure in dojo/tools/wizcli_common_parsers/parsers.py
| Vulnerability | Potential Logging Information Disclosure |
|---|---|
| Description | Error logging in the Wizcli parsers includes detailed exception messages that could reveal internal system details if logs are improperly secured. The logging includes file paths, component names, and parsing errors that should be carefully managed. |
django-DefectDojo/dojo/tools/wizcli_common_parsers/parsers.py
Lines 1 to 396 in 715d098
All finding details can be found in the DryRun Security Dashboard.
valentijnscholten
left a comment
There was a problem hiding this comment.
Thanks two more things:
- see my comment on the hash code fields
- because the dedupe config has changed AND the title is not set differently, this needs some docs in the upgrade notes for 2.47.3.
Can you add instructions on how to recalculate the hash codes (see other releases to get a starting point). And line that states dedupe can mismatch between findings imported by the new parser versus the old parser (because of the change in values for the title field).
|
hi @valentijnscholten all changes done requesting for review |
|
@Maffooch @mtesauro Is there already a guideline/agreement on how to handle changes in parsers that affect deduplication? Sometimes recalculating the hash codes is enough. But in this case the title field is changing. Existing findings in Defect Dojo will have a different title and hash code as a result of that. There is note in the upgrade notes. |
|
@OsamaMahmood We have discussed this PR internally and we have some concerns around the changes in the deduplication logic/settings. It will result in new findings being created which are not deduplicated against existing findings during import/reimport. When users are using I though of some ways we could avoid this "breaking" change:
Is there any option of those you think that could work? |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Closing as stale - please feel free to reopen if closing now is a mistake |
Description
_generate_unique_idmethod to ensure consistent finding deduplication usingunique_id_from_tool:Checklist
This checklist is for your information.
dev.dev.bugfixbranch.