update dependencies versions to remove 4 CVEs

[Fclem]

Added .gitignore file with usernames.csv, *.har, results.csv, and .idea.

updated :

• certifi from 2022.9.24 to 2024.7.4
• idna from 3.4 to 3.7
• requests from 2.28.1 to 2.32.0
• urllib3 from 1.26.12 to 2.2.2

Dependency pypi:certifi:2022.9.24 is vulnerable

Upgrade to 2024.7.4

PYSEC-2023-135, Score: 7.5

Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. These are in the process of being removed from Mozilla's trust store. e-Tugra's root certificates are being removed pursuant to an investigation prompted by reporting of security issues in their systems.

Read More: https://osv.dev/vulnerability/PYSEC-2023-135

GHSA-xqr8-7jwr-rhp7, Score: 7.5

Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. These are in the process of being removed from Mozilla's trust store.
e-Tugra's root certificates are being removed pursuant to an investigation prompted by reporting of security issues in their systems. Conclusions of Mozilla's investigation can be found "here" (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/C-HrP1SEq1A).

Read More: https://osv.dev/vulnerability/GHSA-xqr8-7jwr-rhp7

PYSEC-2022-42986, Score: 6.8

Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Read More: https://osv.dev/vulnerability/PYSEC-2022-42986

GHSA-43fp-rhv2-5gv8, Score: 6.8

Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store.
TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found "here" (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ).

Read More: https://osv.dev/vulnerability/GHSA-43fp-rhv2-5gv8

GHSA-248v-346w-9cwc, Score: 2

Certifi 2024.07.04 removes root certificates from "GLOBALTRUST" from the root store. These are in the process of being removed from Mozilla's trust store.
GLOBALTRUST's root certificates are being removed pursuant to an investigation which identified "long-running and unresolved compliance issues". Conclusions of Mozilla's investigation can be found "here" (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI).

Read More: https://osv.dev/vulnerability/GHSA-248v-346w-9cwc

Dependency pypi:idna:3.4 is vulnerable

Upgrade to 3.7

PYSEC-2024-60, Score: 7.5

A vulnerability was identified in the kjd/idna library, specifically within the "idna.encode()" function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the "idna.encode()" function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.

Read More: https://osv.dev/vulnerability/PYSEC-2024-60

GHSA-jjg7-2v4v-x38h, Score: 6.2

Impact
A specially crafted argument to the "idna.encode()" function could consume significant resources. This may lead to a denial-of-service.
Patches
The function has been refined to reject such strings without the associated resource consumption in version 3.7.
Workarounds
Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the "idna.encode()" function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.
References

• https://huntr.com/bounties/93d78d07-d791-4b39-a845-cbfabc44aadb

Read More: https://osv.dev/vulnerability/GHSA-jjg7-2v4v-x38h

Dependency pypi:requests:2.28.1 is vulnerable

Upgrade to 2.32.0

PYSEC-2023-74, Score: 6.1

Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use "rebuild_proxies" to reattach the "Proxy-Authorization" header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the "Proxy-Authorization" header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.

Read More: https://osv.dev/vulnerability/PYSEC-2023-74

GHSA-j8r2-6x86-q33q, Score: 6.1

Impact
Since Requests v2.3.0, Requests has been vulnerable to potentially leaking "Proxy-Authorization" headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how "rebuild_proxies" is used to recompute and "reattach the "Proxy-Authorization" header" (https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/sessions.py#L319-L328) to requests when redirected. Note this behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. "https://username:password@proxy:8080").
Current vulnerable behavior(s):

1. HTTP → HTTPS: leak
2. HTTPS → HTTP: no leak
3. HTTPS → HTTPS: leak
4. HTTP → HTTP: no leak
   For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the "Proxy-Authorization" header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.
   The reason this currently works for HTTPS connections in Requests is the "Proxy-Authorization" header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with ""proxy_manager_for"" (https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/adapters.py#L199-L235). This will compute the required proxy headers in "proxy_headers" and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.
   Patches
   Starting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.
   For users with custom adapters, this may be potentially breaking if you were already working around this behavior. The previous functionality of "rebuild_proxies" doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.
   Workarounds
   For users who are not able to update Requests immediately, there is one potential workaround.
   You may disable redirects by setting "allow_redirects" to "False" on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination.
   import requests
   r = requests.get('http://github.com/', allow_redirects=False)
   Credits
   This vulnerability was discovered and disclosed by the following individuals.
   Dennis Brinkrolf, Haxolot (https://haxolot.com/)
   Tobias Funke, (tobiasfunke93@gmail.com)

Read More: https://osv.dev/vulnerability/GHSA-j8r2-6x86-q33q

GHSA-9wx4-h78v-vm56, Score: 5.6

When making requests through a Requests "Session", if the first request is made with "verify=False" to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of "verify". This behavior will continue for the lifecycle of the connection in the connection pool.
Remediation
Any of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.

• Upgrade to "requests>=2.32.0".
• For "requests<2.32.0", avoid setting "verify=False" for the first request to a host while using a Requests Session.
• For "requests<2.32.0", call "close()" on "Session" objects to clear existing connections if "verify=False" is used.
  Related Links
• Use TLS settings in selecting connection pool psf/requests#6655

Read More: https://osv.dev/vulnerability/GHSA-9wx4-h78v-vm56

Dependency pypi:urllib3:1.26.12 is vulnerable

Upgrade to 2.2.2

PYSEC-2023-192, Score: 8.1

urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the "Cookie" HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a "Cookie" header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.

Read More: https://osv.dev/vulnerability/PYSEC-2023-192

GHSA-v845-jxx5-vc9f, Score: 5.9

urllib3 doesn't treat the "Cookie" HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a "Cookie" header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
Users must handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the "Cookie" header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.
Affected usages
We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

• Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)
• Using the "Cookie" header on requests, which is mostly typical for impersonating a browser.
• Not disabling HTTP redirects
• Either not using HTTPS or for the origin server to redirect to a malicious origin.
  Remediation
• Upgrading to at least urllib3 v1.26.17 or v2.0.6
• Disabling HTTP redirects using "redirects=False" when sending requests.
• Not using the "Cookie" header.

Read More: https://osv.dev/vulnerability/GHSA-v845-jxx5-vc9f

GHSA-34jh-p97f-mpxf, Score: 4.4

When using urllib3's proxy support with "ProxyManager", the "Proxy-Authorization" header is only sent to the configured proxy, as expected.
However, when sending HTTP requests without using urllib3's proxy support, it's possible to accidentally configure the "Proxy-Authorization" header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the "Proxy-Authorization" HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.
Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the "Proxy-Authorization" header during cross-origin redirects to avoid the small chance that users are doing this on accident.
Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the "Proxy-Authorization" header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach.
Affected usages
We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

• Setting the "Proxy-Authorization" header without using urllib3's built-in proxy support.
• Not disabling HTTP redirects.
• Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.
  Remediation
• Using the "Proxy-Authorization" header with urllib3's "ProxyManager".
• Disabling HTTP redirects using "redirects=False" when sending requests.
• Not using the "Proxy-Authorization" header.

Read More: https://osv.dev/vulnerability/GHSA-34jh-p97f-mpxf

GHSA-g4mx-q9vg-27p4, Score: 4.2

urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 "See Other" after the request had its method changed from one that could accept a request body (like "POST") to "GET" as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.
From "RFC 9110 Section 9.3.1" (https://www.rfc-editor.org/rfc/rfc9110.html#name-get):
«A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.»
Affected usages
Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.
Both of the following conditions must be true to be affected by this vulnerability:

• If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)
• The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.
  Remediation
  You can remediate this vulnerability with any of the following steps:
• Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)
• Disable redirects for services that you aren't expecting to respond with redirects with "redirects=False".
• Disable automatic redirects with "redirects=False" and handle 303 redirects manually by stripping the HTTP request body.

Read More: https://osv.dev/vulnerability/GHSA-g4mx-q9vg-27p4

PYSEC-2023-212, Score: 4.2

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like "POST") to "GET" as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with "redirects=False" and disable automatic redirects with "redirects=False" and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

Read More: https://osv.dev/vulnerability/PYSEC-2023-212

[maxtheaxe]

looks good! sorry for the delay