-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[S308] mark_safe
for HTML constants
#16702
Comments
Thanks for the nice write up!
Ruff's implementation (which I think matches bandit's) isn't very sophisticated. It only searches for calls to Allowing calls to For now, the spirit of the rule is that you use So what I think should be accepted is: def myfilter(case, ...):
if case == "hello":
return mark_safe("<i>Hello world!</i>")
elif case == "bye":
return mark_safe("<b>Bye world!</b>")
else:
... |
If it does indeed sound reasonable, I could try to have a look into submitting a PR in the upcoming weeks. I'm pretty much of a newbie when it comes to Rust, but don't care to spend the time off the clock. |
It does sound reasonable to me, unless I'm overlooking something :) You can find the code here ruff/crates/ruff_linter/src/rules/flake8_bandit/rules/suspicious_function_call.rs Line 1054 in 46fe177
and you can see an example that inspects the arguments here ruff/crates/ruff_linter/src/rules/flake8_bandit/rules/suspicious_function_call.rs Lines 1058 to 1074 in 46fe177
|
You can also take a look at S704 and potentially reuse some of its logic, since it's trying to accomplish the same thing for a different API. ruff/crates/ruff_linter/src/rules/flake8_bandit/rules/unsafe_markup_use.rs Lines 135 to 160 in 851427a
|
Thanks a lot for the pointers. With your help a new version of the rule worked on the first I opened #16770 with the proposed change. Relatedly, it would be great if the @mark_safe
def my_filter(case, ...):
if case == "hello":
return "<i>Hello world!</i>"
else:
return "<b>Bye world!</b>" However, this would increase complexity. Whether the symbol is being used as function or as a decorator should be detected and branched accordingly. For the second case, the decorated function should be inspected and all return statements analyzed for "string-literal'ness. |
* main: (25 commits) [syntax-errors] Parenthesized context managers before Python 3.9 (#16523) [ci]: Disable wheel testing on `ppc64le` (#16793) [red-knot] Stabilize `negation_reverses_subtype_order` property test (#16801) [red-knot] Emit error if int/float/complex/bytes/boolean literals appear in type expressions outside `typing.Literal[]` (#16765) [ci] Use `git diff` instead of `changed-files` GH action (#16796) [syntax-errors] Improve error message and range for pre-PEP-614 decorator syntax errors (#16581) [`flake8-bandit`] Allow raw strings in `suspicious-mark-safe-usage` (`S308`) #16702 (#16770) [`refurb`] Avoid panicking `unwrap` in `verbose-decimal-constructor` (`FURB157`) (#16777) [red-knot] Add `--color` CLI option (#16758) [internal]: Upgrade salsa (#16794) Pin dependencies (#16791) [internal]: Update indirect dependencies (#16792) [ci]: Fixup codspeed upgrade (#16790) Update Rust crate compact_str to 0.9.0 (#16785) Update Rust crate clap to v4.5.32 (#16778) Update Rust crate codspeed-criterion-compat to v2.9.1 (#16784) Update Rust crate quote to v1.0.40 (#16782) Update Rust crate ordermap to v0.5.6 (#16781) Update cloudflare/wrangler-action action to v3.14.1 (#16783) Update Rust crate env_logger to v0.11.7 (#16779) ...
Question
I have a question regarding this linting rule (imported from
flake8-bandit
).I think I understand the problems with using
django.utils.safestring.mark_safe
. But know thatformat_html
is being deprecated for being used without arguments¹, I struggle to find what would be the correct way to handle something as simple as creating a filter that performs:(This is not an accurate filter API, but illustrates the purpose).
In this case I know the HTML is safe, but I don't understand how to create a safestring from it without getting the
DeprecationWarningError
from Django (format_html
) or noqa'ing the S308 rule (suspicious-mark-safe-usage
).I fail to see how a string constant could introduce a XSS unless there is programmer negligence, in which case all bets are off. Having said this, I might be the negligent here! 😅
¹: And for a good reason. When coupled with f-strings interpolation happens before Django gets to escape inputs.
Version
ruff 0.8.0
The text was updated successfully, but these errors were encountered: