[`flake8-bandit`]: Implement `S610` rule #10316

mkniewallner · 2024-03-09T18:14:49Z

Part of #1646.

Summary

Implement S610 rule from flake8-bandit.

Upstream references:

Implementation: https://github.com/PyCQA/bandit/blob/1.7.8/bandit/plugins/django_sql_injection.py#L20-L97
Test cases: https://github.com/PyCQA/bandit/blob/1.7.8/examples/django_sql_injection_extra.py
Test assertion: https://github.com/PyCQA/bandit/blob/1.7.8/tests/functional/test_functional.py#L517-L524

The implementation in bandit targets additional arguments (params, order_by and select_params) but doesn't seem to do anything with them in the end, so I did not include them in the implementation.

Note that this rule could be prone to false positives, as ideally we would want to check if extra() is tied to a Django queryset, but AFAIK Ruff is not able to resolve classes outside of the current module.

Test Plan

Snapshot tests

github-actions · 2024-03-09T18:39:05Z

`ruff-ecosystem` results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+22 -0 violations, +0 -0 fixes in 1 projects; 42 projects unchanged)

zulip/zulip (+22 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview --select ALL

+ zerver/actions/message_flags.py:108:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:160:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:232:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:42:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/actions/message_flags.py:56:23: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/message.py:536:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/message.py:576:36: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/push_notifications.py:1076:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/query_helpers.py:26:24: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/lib/users.py:200:89: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/models/streams.py:265:47: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:267:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:300:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:577:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:681:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_flags.py:692:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1505:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1512:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1577:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/tests/test_message_move_topic.py:1584:19: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/views/read_receipts.py:80:15: S610 Use of Django `extra` can lead to SQL injection vulnerabilities
+ zerver/worker/queue_processors.py:1079:93: S610 Use of Django `extra` can lead to SQL injection vulnerabilities

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
S610	22	22	0	0	0

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

Upstream references: - Implementation: https://github.com/PyCQA/bandit/blob/1.7.8/bandit/plugins/django_sql_injection.py#L20-L97 - Test cases: https://github.com/PyCQA/bandit/blob/1.7.8/examples/django_sql_injection_extra.py - Test assertion: https://github.com/PyCQA/bandit/blob/1.7.8/tests/functional/test_functional.py#L517-L524

mkniewallner · 2024-03-09T18:19:58Z

crates/ruff_linter/src/rules/flake8_bandit/rules/django_extra.rs

+    if !checker.semantic().seen_module(Modules::DJANGO) {
+        return;
+    }


This is also done for django_raw_sql, but I'm wondering if this should also be done for this rule.

In django_raw_sql, RawSQL import comes from django module, so this is reliable, but in our case, extra can be used even if no django imports occurs, if for instance a model defined in another file in a codebase is used, so this could skip the check for several valid cases.

On the other hand, the entire rule has the potential of having several false positives, so this could be seen as a way to know if a file belongs to a project using Django. But if I'm not mistaken, seen_module only applies to the current file, not the whole codebase, and in this specific case the latter would probably be preferable.

Case in point, the ecosystem checks detects 18 errors while bandit detects 22. That's because there are 4 things that would have been flagged in https://github.com/zulip/zulip/blob/29ca4ba6620f16598e1171be7495356f56b84328/zerver/tests/test_message_move_topic.py, but are skipped because there is no import from django in this file.

I think I'm okay with leaving this in for now.

I could go either way though. extra isn't a common method name.

Yeah, I think that the combination of extra and select/where/tables arguments should not be that common outside of Django. Worst case, for the few times it would get triggered, it's always possible for users to ignore the false positives, while skipping the check entirely if Ruff does not find a django import would leave the user with no clue that the check was not run because of that. So I think it might be best in the end to not check if Django was seen.

I went ahead and removed the check in 4e88142. Also updated the error message so that in case of false positives, the user at least knows that this is related to Django.

mkniewallner · 2024-03-09T19:40:28Z

crates/ruff_linter/src/rules/flake8_bandit/rules/django_extra.rs

+            match argument_name {
+                "select" => match argument {
+                    Expr::Dict(ExprDict { keys, values, .. }) => {
+                        if !keys.iter().flatten().all(Expr::is_string_literal_expr) {


flatten() is used to remove optional keys here. Not sure that this is really a clean way to do this, let me know if not.

Do we want to flag on select(**kwargs)? It seems like this wouldn't, but it probably should, right?

Nevermind, I misread.

We might want to consider allowing: select(**{"foo": "bar"})

charliermarsh

Thanks!

mkniewallner force-pushed the feat/add-flake8-bandit-S610 branch from eb10243 to 33f1f5c Compare March 9, 2024 18:26

mkniewallner force-pushed the feat/add-flake8-bandit-S610 branch from 33f1f5c to 709045a Compare March 9, 2024 19:15

mkniewallner commented Mar 9, 2024

View reviewed changes

mkniewallner marked this pull request as ready for review March 9, 2024 19:40

charliermarsh added rule Implementing or modifying a lint rule preview Related to preview mode features labels Mar 11, 2024

charliermarsh self-requested a review March 11, 2024 22:21

fix(rules): do not check for django import in S610

4e88142

charliermarsh merged commit fc7139d into astral-sh:main Mar 12, 2024
17 checks passed

charliermarsh reviewed Mar 12, 2024

View reviewed changes

BrewTestBot mentioned this pull request Mar 15, 2024

ruff 0.3.3 Homebrew/homebrew-core#166260

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[`flake8-bandit`]: Implement `S610` rule #10316

[`flake8-bandit`]: Implement `S610` rule #10316

mkniewallner commented Mar 9, 2024 •

edited

github-actions bot commented Mar 9, 2024 •

edited

mkniewallner Mar 9, 2024

mkniewallner Mar 9, 2024

charliermarsh Mar 11, 2024

charliermarsh Mar 11, 2024

mkniewallner Mar 11, 2024

mkniewallner Mar 11, 2024

mkniewallner Mar 9, 2024

charliermarsh Mar 11, 2024

charliermarsh Mar 12, 2024

charliermarsh Mar 12, 2024

charliermarsh left a comment

[flake8-bandit]: Implement S610 rule #10316

[flake8-bandit]: Implement S610 rule #10316

Conversation

mkniewallner commented Mar 9, 2024 • edited

Summary

Test Plan

github-actions bot commented Mar 9, 2024 • edited

ruff-ecosystem results

Linter (stable)

Linter (preview)

Formatter (stable)

Formatter (preview)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

charliermarsh left a comment

Choose a reason for hiding this comment

[`flake8-bandit`]: Implement `S610` rule #10316

[`flake8-bandit`]: Implement `S610` rule #10316

mkniewallner commented Mar 9, 2024 •

edited

github-actions bot commented Mar 9, 2024 •

edited

`ruff-ecosystem` results