Avoid raising S310 if user explicitly checks for URL scheme

[q0w]

• A minimal code snippet that reproduces the bug.

import urllib.request


def foo(url: str) -> None:
    if not url.startswith(("https://", "http://")):
        raise ValueError
    req = urllib.request.Request(
        url,
        headers=headers,
        data=data,
        method=method,
    )
    resp = urllib.request.urlopen(req)

Also it would be great if ruff could recognize asserts (like assert url.startswith(("https://", "http://")))

• The command you invoked (e.g., ruff /path/to/file.py --fix), ideally including the --isolated flag.

ruff --isolated --select S t.py

• The current Ruff settings (any relevant sections from your pyproject.toml).

No pyproject.toml

• The current Ruff version (ruff --version).

ruff 0.0.292

[qdegraaf]

Could you clarify why urllib.request.Request should be flagged under S310? Bandit's blacklist for the relevant rule does not include it as an issue.

[q0w]

I think s310 should not be triggered because I check the URL in the first lines.

[qdegraaf]

Ah I misunderstood. I thought from your description that the rule was not triggering and it should. But if I understand you correctly now, it is being flagged, and you want to change rule S310 to not flag if the URL passed to it has been checked to start with https:// or http:// and not say file://. This would not be specific to just urllib.request.Request I take it but all urlopen calls flagged by S310.

@charliermarsh is that something that is desirable to implement or is this something that should be manually marked as a check skip by the dev in question. Docs just suggest:

/// To mitigate this risk, audit all uses of URL open functions and ensure that
/// only permitted schemes are used (e.g., allowing `http:` and `https:` and
/// disallowing `file:` and `ftp:`).

[charliermarsh]

I think this will be hard to get right with absolute certainty and so I'm somewhat hesitant to invest in it given that it's a security-related rule. If someone wants to try, though, I am happy to review it.

[charliermarsh]

We now no longer flag this if you use a string literal, which is at least an improvement.

[henryiii]

What about string literal but not in place? This is currently triggering the warning:

url = "https://pypi.org/pypi?:action=list_classifiers"
context = ssl.create_default_context()
with urlopen(url, context=context) as response:

[Hawk777]

A string literal passed through Request is also flagged when it ideally shouldn’t be:

import urllib

urllib.request.urlopen(urllib.request.Request("https://example.com/"))

(obviously in this case I could just pass the string literal directly; in reality, I’m constructing the Request because I have extra headers to add)

[charliermarsh]

I can fix a few of these.

[retu2libc]

It would be cool if stuff like

url = f"https://{self.target_url}{self.path}"

didn't trigger this.