-
-
Notifications
You must be signed in to change notification settings - Fork 606
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
Bandit 1.7.5 false positive for request_without_timeout (B113) #996
Comments
* Temporary suppress bandit request_without_timeout (B113) error because of false positives. * See also: PyCQA/bandit#996 Change-Id: I7a1c276c2a51ac5278d8a20bd7e267c6a9340e96
Yes, if you look back at PR #743 that created this new check, there was concern over introducing such a low confidence plugin. The best course of action for now would be to skip the test if you're getting too many false positives. |
I've found a few more examples of false positives.
|
This repros... import requests
requests.post(
"https://httpbin.org/post", timeout=60 * 3
) edit: It's because of the |
Should be fixed with #1011 |
@ericwb, this still hits on 3260f13:
Should I open a new issue? |
@tucked Good catch. Seems timeout arg gets missed as the node is an ast.BinOp. The context._get_literal_value() doesn't handle BinOp and defaults to None. |
There are some limitations in what Bandit can identify. So in the case of BinOp node, Bandit would be required to evaluate the value (possibly via eval()). But BinOp nodes can also include variables and Bandit doesn't keep track of things like a stack and heap. It moves Bandit into the territory of a compiler or runtime analysis. This example is simple as it is only "60 * 3", but what about "60 * x" or "x ** 2" or "(5 - 1) ** 2". It can get complicated fast as you possibly have to handle many types of operations and precedence. One possible way to fix in scenarios with all constants is to:
However, even Bandit itself warns about using eval(). And ast.literal_eval() doesn't work on BinOp nodes. |
this is a false positive, see PyCQA#996
I've been meaning to comment on this as well. If the above isn't possible to evaluate, I dont know if that means this is even harder (or easier) to catch. But this is how we use it when it triggers false positives (deployer configured values).
|
Describe the bug
Bandit is incorrectly marking calls to requests library without a timeout while the code it's actually not calling directly the requests library and the timeout is already set elsewhere.
Reproduction steps
Run bandit:
bandit -l -i -r --skip B404,B603 somepath/
Get an error:
Expected behavior
Bandit should not report any error because the session has a default timeout set via an
HTTPAdapter
in another library.The code calls
self.requests
that could be any kind of object, does bandit do code inspection of the object to detect that is actually a requests session?I don't think so as it triggered the issue also with my pseudo code that doesn't import the real library.
If it was indeed doing introspection, it should probably also check if there is a default timeout set in the session.
Bandit version
1.7.5 (Default)
Python version
3.9,3.10
Additional context
[note] The dropdown menu of the issues template here on Github has a Python 3.1 version and is missing 3.10, possibly a typo in the template.
The text was updated successfully, but these errors were encountered: