SECURITY: Requests module leaks passwords & usernames for HTTP Basic Auth #839
Comments
jonfoster
changed the title
jonfoster
changed the title
|
The MicroPython way aiui would be to mirror CPython's solution to this problem, which uses a And I see this is exactly what #823 does. That'll teach me not to look at PRs first 😆 |
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Signed-off-by: Richard Weickelt <[email protected]>
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Signed-off-by: Richard Weickelt <[email protected]>
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Signed-off-by: Richard Weickelt <[email protected]>
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Signed-off-by: Richard Weickelt <[email protected]>
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Unfortunately the copy operation does not preserve the key order and we have to touch the existing test cases. Signed-off-by: Richard Weickelt <[email protected]>
rweickelt
added a commit
to rweickelt/micropython-lib
that referenced
this issue
Dec 11, 2024
The requests() function takes a headers dict argument (call-by-reference). This object is then modified in the function. For instance the host is added and authentication information. Such behavior is not expected. It is also problematic: - Modifications of the header dictionary will be visible on the caller site. - When reusing the same (supposedly read-only) headers object for differenct calls, the second call will apparently re-use wrong headers from the previous call and may fail. This patch should also fix micropython#839. Unfortunately the copy operation does not preserve the key order and we have to touch the existing test cases. Signed-off-by: Richard Weickelt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While looking at the MicroPython
requestsmodule (on the git HEAD), I noticed this:If you make a request with HTTP basic auth (a username/password) and did not specify a headers dict, then I believe the username and password would be added to the default headers to be used for every subsequent HTTP request. Even if that request is to a completely different server, which you don't trust with your username and password. That's probably not a good idea.
I haven't verified this, it's just from reading the code, but someone should probably look into it.
This is because there is
headers={}in the function prototype, specifying a default for theheadersparameter. But (at least in cPython) that same dictionary will get reused for every call that doesn't explicitly specify aheadersparameter. So if the function changes theheadersdictionary - such as by adding anAuthorizationheader - that change will be there for every future call of the function. This is a known dangerous part of the Python language, you're not the first people to write this kind of bug.To fix this, you could keep the auth headers separate from the
headersvariable. Something like this (totally untested!) commit: jonfoster@92e9b22 - feel free to use that as a starting point.The text was updated successfully, but these errors were encountered: