Unsafe settings

Question: Does the code turn off a security check or choose a weak setting: certificate verification, password hashing, random tokens, CORS, cookies, or secrets in environment variables the build puts into browser code?

• Runs: when selected: --rule unsafe-settings, --rule security or --rule all · Fails the check by default: no
• Right on projects JevGate was never tuned on: reviews 2 of 4, considers 0 of 4 (how it is measured)
• Right on the projects it was tuned on: reviews 74% (53 of 72), considers 76% (16 of 21)
• Looks at: application functions, each file’s top-level statements that call something, the settings objects of next.config files, and PHP page scripts
• Evidence unit: one function’s source or the file’s setup statements; then their statements as sites
• Acceptable: MD5 for cache keys, non-cryptographic random for shuffling, secure defaults
• Names: security/unsafe-settings, unsafe-settings, unsafe_settings · Version: 7

When a finding is right

A finding says code turns off a security check or chooses a weak setting. It is right when a real connection accepts any certificate, passwords are kept with a fast hash, a session cookie is sent without its flags, or a secret is built into browser code. It is wrong when the weak setting is an option a caller or operator must ask for, when the value is no secret, or when the check it names protects nothing there, such as a CSRF exemption on a view that changes no data. The commonest causes of findings labeled wrong or debatable were CSRF exemptions on views that change nothing and plain connections inside a cluster by design.

A password or token finding stays a review only when the function itself hashes with a fast hash or turns verification off; otherwise, since a callee or the platform may do it, it is a consider.

Findings it got wrong

Labeled wrong by reading the code, on open-source projects the rules were tuned on.

httpx: create_ssl_context

• Where: httpx/_config.py:43 in encode/httpx at b5addb6.
• Finding (review): create_ssl_context turns off certificate or signature verification.
• Why it was wrong: The branch that skips verification runs only when the caller passes verify=False; the default builds a verifying context. An HTTP client library offering a documented, explicit opt-out is doing its job.
• Since: a note since 0.21.0, whose TLS question counts verification skipped only when a caller or the operator asks for it as not turning it off (changelog).

Two-Factor: get_code

• Where: providers/class-two-factor-provider.php:161 in WordPress/two-factor at 72effa5.
• Finding (review): Two_Factor_Provider::get_code makes secret tokens or identifiers that can be guessed, with a non-cryptographic random generator or from known data.
• Why it was wrong: get_code picks each character with wp_rand(), which calls PHP’s cryptographic random_int() on every PHP version the plugin supports.
• Since: cleared in 0.21.0, which knows WordPress’s wp_rand is cryptographic (changelog).

PyGoat: A7_disscussion_api

• Where: introduction/apis.py:93 in adeyosemanputra/pygoat at 19d17cc.
• Finding (review): A7_disscussion_api turns off cross-site request forgery protection for requests that change data.
• Why it was wrong: The view only checks whether the posted code contains a snippet and answers success or failure. It changes no data, so a forged request can do nothing through its CSRF exemption.
• Since: not addressed; reported the same way from 0.19.0 through 0.25.0.