Exporting SSLYZE rapport with ERROR_NO_CONNECTIVITY give 500 HTTP code error from Defecdojo

[kaz-33]

🐞 Bug report

Describe the bug

I run SSLYZE scanner on machine, but the network is broken. The hook-persitence defectdojo (securecodebox) send a rapport to defectDojo. This create an Internal Server Error.

Steps To Reproduce

Steps to reproduce the behavior:

1. Run SSLYZE scanner on machine with the network is down between the Scanner and the Target
2. the Hook hook-persistence-defectdojo send a report to Defectdojo
3. The result is "HTTP/1.1 500 Internal Server Error" from defecdojo
4. The pod hook-persistence-defectdojo stay on Error status.

Expected behavior

The expected behavior is "HTTP/1.1 200" and the hook need to push a right rapport and the pod change in Completed status.

System (please complete the following information):

• secureCodeBox 4.12.024/04
• OS: Ubuntu 24.04
• Kubernetes Version

• Client Version: v1.28.3
  Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
  Server Version: v1.31.4+rke2r1
  Defectdojo:  2.42.0
  

Screenshots / Logs

Content-Disposition: form-data; name="file"; filename="sslyze-results.json"
Content-Type: application/json
Content-Length: 1696

{
"invalid_server_strings": [],
"server_scan_results": [
{
"uuid": "9670df56-2569-444b-bcad-ce04677a26c3",
"server_location": {
"hostname": "10.10.15.12",
"port": 443,
"connection_type": "DIRECT",
"ip_address": "10.10.15.12",
"http_proxy_settings": null
},
"network_configuration": {
"tls_server_name_indication": "10.10.15.12",
"tls_opportunistic_encryption": null,
"tls_client_auth_credentials": null,
"xmpp_to_hostname": null,
"network_timeout": 5,
"network_max_retries": 3
},
"connectivity_status": "ERROR",
"connectivity_error_trace": "Traceback (most recent call last):\n File "/sslyze/sslyze/scanner/_mass_connectivity_tester.py", line 120, in run\n tls_probing_result = check_connectivity_to_server(\n File "/sslyze/sslyze/server_connectivity.py", line 74, in check_connectivity_to_server\n tls_detection_result = _detect_support_for_tls_1_3(\n File "/sslyze/sslyze/server_connectivity.py", line 244, in _detect_support_for_tls_1_3\n ssl_connection.connect(should_retry_connection=False)\n File "/sslyze/sslyze/connection_helpers/tls_connection.py", line 266, in connect\n raise ConnectionToServerTimedOut(\nsslyze.errors.ConnectionToServerTimedOut: 10.10.15.12:443 -> "Connection to the server timed out".\n",
"connectivity_result": null,
"scan_status": "ERROR_NO_CONNECTIVITY",
"scan_result": null
}
],
"date_scans_started": "2025-01-17T12:45:16.091796",
"date_scans_completed": "2025-01-17T12:45:21.201739",
"sslyze_version": "6.0.0",
"sslyze_url": "https://github.com/nabla-c0d3/sslyze"
}
--eGDw0aQmm5ikCHDj_KzmX9UwEX66dE28CF--
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Fri, 17 Jan 2025 12:47:32 GMT

Additional context

If the problem connecting to the target from the scanner is due to DNS resolution, the behaviour is compliant.

Content-Disposition: form-data; name="file"; filename="sslyze-results.json"
Content-Type: application/json
Content-Length: 385

{
"invalid_server_strings": [
{
"server_string": "gatus.ddddd.fr:443",
"error_message": "Could not resolve hostname gatus.ddddd.fr"
}
],
"server_scan_results": [],
"date_scans_started": "2025-01-17T12:58:57.089422",
"date_scans_completed": "2025-01-17T12:58:57.144567",
"sslyze_version": "6.0.0",
"sslyze_url": "https://github.com/nabla-c0d3/sslyze"
}
--XxEFIEEbDds_ahBpHNcHmJT68HoS_1Z8--
HTTP/1.1 201 Created
Server: nginx

ref:
Open in securecodebox in first time, but the securecodebox Team analyse and point the problem from DefectDojo project.
secureCodeBox/secureCodeBox#2858

[kiblik]

Hi @kaz-33.
From the provided logs, it looks like sslyze cannot scan your target. DD is not responsible for scanning. As soon as you (or your tool) will have some consumable report (in case of sslyze it should be some kind of json), DD will be to do its job.
If you check carefully Traceback, you can see that it is coming from sslyze not from DD.

[valentijnscholten]

@kaz-33 Can you confirm the exact (redacted) json that is being sent to Defect Dojo? It might be that the v6.0.0 format is different or some expected fields are missing due to the scan having failed.

[kaz-33]

Hi @kaz-33. From the provided logs, it looks like sslyze cannot scan your target. DD is not responsible for scanning. As soon as you (or your tool) will have some consumable report (in case of sslyze it should be some kind of json), DD will be to do its job. If you check carefully Traceback, you can see that it is coming from sslyze not from DD.
ha ha, i know, i open this issue because it's causing an defectServer error (code 500 internal error) when i push the rapport to the defectdojo.

[kaz-33]

@kaz-33 Can you confirm the exact (redacted) json that is being sent to Defect Dojo? It might be that the v6.0.0 format is different or some expected fields are missing due to the scan having failed.

"sslyze_version": "6.0.0",

[kiblik]

Hi @kaz-33. From the provided logs, it looks like sslyze cannot scan your target. DD is not responsible for scanning. As soon as you (or your tool) will have some consumable report (in case of sslyze it should be some kind of json), DD will be to do its job. If you check carefully Traceback, you can see that it is coming from sslyze not from DD.
ha ha, i know, i open this issue because it's causing an defectServer error (code 500 internal error) when i push the rapport to the defectdojo.

Now I probably understand. The mentioned log is from the tool which is uploading the report. And json structure is report itself.

Can you provide logs from DD itself for easier troubleshooting? Not from the client side but from the server side.

[kaz-33]

json file create by sslyze
Something has gone wrong and created an internal error in DefectDojo. Is this a malformed report or behaviour not expected in DefectDojo?

{
"invalid_server_strings": [],
"server_scan_results": [
{
"uuid": "b7fb9d27-14dd-4f5d-97bc-de29eaf4dea9",
"server_location": {
"hostname": "10.10.10.159",
"port": 443,
"connection_type": "DIRECT",
"ip_address": "10.10.10.159",
"http_proxy_settings": null
},
"network_configuration": {
"tls_server_name_indication": "10.10.10.159",
"tls_opportunistic_encryption": null,
"tls_client_auth_credentials": null,
"xmpp_to_hostname": null,
"network_timeout": 5,
"network_max_retries": 3
},
"connectivity_status": "ERROR",
"connectivity_error_trace": "Traceback (most recent call last):\n File "/sslyze/sslyze/scanner/_mass_connectivity_tester.py", line 120, in run\n tls_probing_result = check_connectivity_to_server(\n File "/sslyze/sslyze/server_connectivity.py", line 74, in check_connectivity_to_server\n tls_detection_result = _detect_support_for_tls_1_3(\n File "/sslyze/sslyze/server_connectivity.py", line 244, in _detect_support_for_tls_1_3\n ssl_connection.connect(should_retry_connection=False)\n File "/sslyze/sslyze/connection_helpers/tls_connection.py", line 266, in connect\n raise ConnectionToServerTimedOut(\nsslyze.errors.ConnectionToServerTimedOut: 10.10.10.159:443 -> "Connection to the server timed out".\n",
"connectivity_result": null,
"scan_status": "ERROR_NO_CONNECTIVITY",
"scan_result": null
}
],
"date_scans_started": "2025-01-22T08:16:02.283773",
"date_scans_completed": "2025-01-22T08:16:07.407775",
"sslyze_version": "6.0.0",
"sslyze_url": "https://github.com/nabla-c0d3/sslyze"
}

[kaz-33]

Hi @kaz-33. From the provided logs, it looks like sslyze cannot scan your target. DD is not responsible for scanning. As soon as you (or your tool) will have some consumable report (in case of sslyze it should be some kind of json), DD will be to do its job. If you check carefully Traceback, you can see that it is coming from sslyze not from DD.
ha ha, i know, i open this issue because it's causing an defectServer error (code 500 internal error) when i push the rapport to the defectdojo.

Now I probably understand. The mentioned log is from the tool which is uploading the report. And json structure is report itself.

Can you provide logs from DD itself for easier troubleshooting? Not from the client side but from the server side.

The only information find on a log, is
« django.db.utils.DataError: value too long for type character varying(200) > but without any information regarding the value

[kiblik]

Now I probably understand. The mentioned log is from the tool which is uploading the report. And json structure is report itself.

Can you provide logs from DD itself for easier troubleshooting? Not from the client side but from the server side.

The only information find on a log, is
« django.db.utils.DataError: value too long for type character varying(200) > but without any information regarding the value

Perfect, we are getting closer (we have one line of error). Can I ask you for more lines around this message? To understand which part of DD code is triggering error.

Another question: You are showing report from tool which declare it failed. What kind of finding you are expecting to see in DD? Because DD should show vulnerabilities on the scanned target. And there is no information about such vulnerability in the report.

[valentijnscholten]

@kiblik I think best is to put the json in a unit test and make sure there's no 500 but 200.

[kaz-33]

Perfect, we are getting closer (we have one line of error). Can I ask you for more lines around this message? To understand which part of DD code is triggering error.

Sorry, no more information :( ...but I think you can easily reproduce the behaviour.