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
API: Exceptions swallowed by custom exception handler #5019
Comments
There were some changes #4931 that seem to now require @Maffooch @XiChen-Tibco IIRC you worked together on that PR? The weird thing is that if we leave out |
#4931 only seems to make active and verified required? |
yeah, judged too soon. the missing error / trace seems to be because of #4863. If I remove that custom exception handler, the error is displayed (KeyError on duplicate field). |
Looking at it some more it seems |
hmmm duplicate and false_p are not marked as required:
I thought the purpose of #4931 was to have the full list of required fields in the openapi spec. |
I have reopened the original bug report on fields not being marked as required. This bug report here is now renamed to cover the bug that exceptions are swallowed. |
Works perfect for me. Thank for being that reactive ! |
Error messages shouldn't reveal internal information as a security practice: https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html:
That is exactly what DefectDojo is doing now and I would consider it as a feature rather than a bug. |
The problem is the error is not in the logs anymore. Also with DEBUG off, Django usually doesn't return the full details anyway. |
I guess we could work to have this errors in logs again and a more generic error, like "duplicate attribute is missing" (which is aligned with OWASP description). |
@valentijnscholten Do you like to see a change of the exception handler or is your fix with the logging sufficient? |
We have had a couple of occasions where the error handlings was (unknowingly) changed into something that hid the error details from the response (even in DEBUG mode) or swallowed errors (not logging them). So ideally we have some test cases where we capture the current error handling behaviour so we will notice it when something changes. We can also check if everybody is happy with the current error handling. I know it's best practice to hide errors, but we also need to allow users to easily debug their problems (so we don't have to be on slack 24/7 :-)) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Slack us first!
The easiest and fastest way to help you is via Slack. There's a free and easy signup to join our #defectdojo channel in the OWASP Slack workspace: Get Access.
If you're confident you've found a bug, or are allergic to Slack, you can submit an issue anyway.
Be informative
We were working on the 2.1.0 release, so we update our defect dojo to 2.2.0. And the bug still happens.
In 2.2.0 the we can't see the full trace log.
Bug description
When trying to add a finding to a test via API this generate an Internal Server Error 500.
The test can belong to an active or closed Engagement, the bug works in the same way.
Note : the bug didn't happen with the web UI.
Steps to reproduce
Steps to reproduce the behavior:
Here is an example of what you can enter in the form (of course you need to change test and user id) :
{
"test": ,
"found_by": [
],
"title": "Fidings",
"date": "2021-09-01",
"severity": "string",
"description": "string",
"active": true,
"verified": true,
"numerical_severity": "s4"
}
Expected behavior
I expected 201 code with a json that represent the just created findings
Deployment method (select with an
X
)Environment information
Console logs (optional)
Here is the logs with the 2.1.0 version :
Note : I confirme that the sended request contain {'active' : true, 'verified': true, ...}
for the 2.2.0 release :
Additional context (optional)
Here is something that change with the 2.2.0 release, i don't know if there is any link but this is the log at the start of the app :
initializer_1 | Apply all migrations: admin, auditlog, auth, authtoken, contenttypes, django_celery_results, dojo, sessions, sites, social_django, tagging, watson
initializer_1 | Running migrations:
initializer_1 | Traceback (most recent call last):
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
initializer_1 | return self.cursor.execute(sql, params)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/mysql/base.py", line 73, in execute
initializer_1 | return self.cursor.execute(query, args)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 206, in execute
initializer_1 | res = self._query(query)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 319, in _query
initializer_1 | db.query(q)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/connections.py", line 259, in query
initializer_1 | _mysql.connection.query(self, query)
initializer_1 | MySQLdb._exceptions.OperationalError: (1060, "Duplicate column name 'sonarqube_config_id'")
initializer_1 |
initializer_1 | The above exception was the direct cause of the following exception:
initializer_1 |
initializer_1 | Traceback (most recent call last):
initializer_1 | File "manage.py", line 11, in
initializer_1 | execute_from_command_line(sys.argv)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/init.py", line 401, in execute_from_command_line
initializer_1 | utility.execute()
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/init.py", line 395, in execute
initializer_1 | self.fetch_command(subcommand).run_from_argv(self.argv)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 330, in run_from_argv
initializer_1 | self.execute(*args, **cmd_options)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 371, in execute
initializer_1 | output = self.handle(*args, **options)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 85, in wrapped
initializer_1 | res = handle_func(*args, **kwargs)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/core/management/commands/migrate.py", line 243, in handle
initializer_1 | post_migrate_state = executor.migrate(
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/migrations/executor.py", line 117, in migrate
initializer_1 | state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
initializer_1 | state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/migrations/executor.py", line 227, in apply_migration
initializer_1 | state = migration.apply(state, schema_editor)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/migrations/migration.py", line 124, in apply
initializer_1 | operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/migrations/operations/fields.py", line 104, in database_forwards
initializer_1 | schema_editor.add_field(
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/mysql/schema.py", line 89, in add_field
initializer_1 | super().add_field(model, field)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/base/schema.py", line 487, in add_field
initializer_1 | self.execute(sql, params)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/base/schema.py", line 142, in execute
initializer_1 | cursor.execute(sql, params)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 66, in execute
initializer_1 | return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
initializer_1 | return executor(sql, params, many, context)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
initializer_1 | return self.cursor.execute(sql, params)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/utils.py", line 90, in exit
initializer_1 | raise dj_exc_value.with_traceback(traceback) from exc_value
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 84, in _execute
initializer_1 | return self.cursor.execute(sql, params)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/django/db/backends/mysql/base.py", line 73, in execute
initializer_1 | return self.cursor.execute(query, args)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 206, in execute
initializer_1 | res = self._query(query)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 319, in _query
initializer_1 | db.query(q)
initializer_1 | File "/usr/local/lib/python3.8/site-packages/MySQLdb/connections.py", line 259, in query
initializer_1 | _mysql.connection.query(self, query)
initializer_1 | django.db.utils.OperationalError: (1060, "Duplicate column name 'sonarqube_config_id'")
initializer_1 | Applying dojo.0120_sonarqube_test_and_clean...Admin user: admin
initializer_1 | [01/Sep/2021 08:55:36] INFO [dojo.models:3627] disabling audit logging
initializer_1 | Admin password: Initialization detected that the admin user admin already exists in your database.
The text was updated successfully, but these errors were encountered: