Skip to content
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.

Sign up for GitHub

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

Jump to bottom

🚨 [security] [server] Update guzzlehttp/guzzle: 6.3.3 → 6.5.8 (minor) #15

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

🚨 [security] [server] Update guzzlehttp/guzzle: 6.3.3 → 6.5.8 (minor) #15

wants to merge 1 commit into from

Conversation

depfu[bot]
Copy link

@depfu depfu bot commented Jun 21, 2022 •
edited
Loading

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ guzzlehttp/guzzle (indirect, 6.3.3 → 6.5.8) · Repo · Changelog

Security Advisories 🚨

🚨 CURLOPT_HTTPAUTH option not cleared on change of origin

Impact

Authorization headers on requests are sensitive information. When using our Curl handler, it is possible to use the CURLOPT_HTTPAUTH option to specify an Authorization header. On making a request which responds with a redirect to a URI with a different origin, if we choose to follow it, we should remove the CURLOPT_HTTPAUTH and CURLOPT_USERPWD options before continuing, stopping curl from appending the Authorization header to the new request. Previously, we would only consider a change in host. Now, we consider any change in host, port or scheme to be a change in origin.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. Note that a partial fix was implemented in Guzzle 7.4.2, where a change in host would trigger removal of the curl-added Authorization header, however this earlier fix did not cover change in scheme or change in port.

Workarounds

If you do not require or expect redirects to be followed, one should simply disable redirects all together. Alternatively, one can specify to use the Guzzle stream handler backend, rather than curl.

References

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

🚨 Change in port should be considered a change in origin

Impact

Authorization and Cookie headers on requests are sensitive information. On making a request which responds with a redirect to a URI with a different port, if we choose to follow it, we should remove the Authorization and Cookie headers from the request, before containing. Previously, we would only consider a change in host or scheme downgrade. Now, we consider any change in host, port or scheme to be a change in origin.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5.

Workarounds

An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.

References

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

🚨 Failure to strip the Cookie header on change in host or HTTP downgrade

Impact

Cookie headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the Cookie header on. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any Cookie header manually added to the initial request would not be stripped. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.

Workarounds

An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.

References

RFC9110 Section 15.4

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

🚨 Fix failure to strip Authorization header on HTTP downgrade

Impact

Authorization headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, we should not forward the Authorization header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, https to http downgrades did not result in the Authorization header being removed, only changes to the host.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.

Workarounds

An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.

References

RFC9110 Section 15.4

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

🚨 Cross-domain cookie leakage in Guzzle

Impact

Previous version of Guzzle contain a vulnerability with the cookie middleware. The vulnerability is that it is not checked if the cookie domain equals the domain of the server which sets the cookie via the Set-Cookie header, allowing a malicious server to set cookies for unrelated domains. For example an attacker at www.example.com might set a session cookie for api.example.net, logging the Guzzle client into their account and retrieving private API requests from the security log of their account.

Note that our cookie middleware is disabled by default, so most library consumers will not be affected by this issue. Only those who manually add the cookie middleware to the handler stack or construct the client with ['cookies' => true] are affected. Moreover, those who do not use the same Guzzle client to call multiple domains and have disabled redirect forwarding are not affected by this vulnerability.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.5.0 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.6 or 7.4.3.

Workarounds

If you do not need support for cookies, turn off the cookie middleware. It is already off by default, but if you have turned it on and no longer need it, turn it off.

References

RFC6265 Section 5.3

For more information

If you have any questions or comments about this advisory:

Release Notes

6.5.7

See change log for changes.

6.5.6

See change log for changes.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 1 commit:

↗️ guzzlehttp/promises (indirect, 1.3.1 → 1.5.1) · Repo · Changelog

Release Notes

1.5.1

See change log for changes.

1.4.1

See change log for changes.

1.4.0

See change log for changes.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 65 commits:

↗️ guzzlehttp/psr7 (indirect, 1.5.2 → 1.9.0) · Repo · Changelog

Security Advisories 🚨

🚨 Improper Input Validation in guzzlehttp/psr7

Impact

In proper header parsing. An attacker could sneak in a new line character and pass untrusted values.

Patches

The issue is patched in 1.8.4 and 2.1.1

Workarounds

There are no known workarounds.

Release Notes

1.8.5

See change log for changes.

1.8.4

See change log for changes.

1.8.3

See change log for changes.

1.8.2

See change log for changes.

1.8.0

See change log for changes.

1.7.0

See change log for changes.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ ralouphie/getallheaders (indirect, 2.0.5 → 3.0.3) · Repo

Commits

See the full diff on Github. The new version differs by 17 commits:

↗️ symfony/polyfill-mbstring (indirect, 1.10.0 → 1.26.0) · Repo

Commits

See the full diff on Github. The new version differs by 45 commits:

↗️ symfony/polyfill-php72 (indirect, 1.10.0 → 1.26.0) · Repo

Commits

See the full diff on Github. The new version differs by 28 commits:

🆕 symfony/polyfill-intl-idn (added, 1.26.0)

🆕 symfony/polyfill-intl-normalizer (added, 1.26.0)

🗑️ laravel/envoy (removed)

🗑️ nategood/httpful (removed)

👉 No CI detected

You don't seem to have any Continuous Integration service set up!

Without a service that will test the Depfu branches and pull requests, we can't inform you if incoming updates actually work with your app. We think that this degrades the service we're trying to provide down to a point where it is more or less meaningless.

This is fine if you just want to give Depfu a quick try. If you want to really let Depfu help you keep your app up-to-date, we recommend setting up a CI system:

  • Circle CI, Semaphore and Travis-CI are all excellent options.
  • If you use something like Jenkins, make sure that you're using the Github integration correctly so that it reports status data back to Github.
  • If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with depfu/.

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu bot added the depfu label Jun 21, 2022
@depfu depfu bot mentioned this pull request Jun 21, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
depfu
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants