feat: Add allowInsecureRedirect option

[legobeat]

PR Checklist:

• I have run npm test locally and all tests are passing.
• I have added/updated tests for any new behavior.
• If this is a significant change, an issue has already been created where the problem / solution was discussed: CVE-2023-28155 #27
  

PR Description

• Ported from Ssrf fix request/request#3444
  • Existing behavior allows malicious redirects between protocols
  • Set default behavior to disable protocol downgrade in redirects (breaking)
  • Add new option allowInsecureRedirect where true reverts to old behavior
• Update cypress tests to use allowInsecureRedirect: true for applicable cases

A non-breaking (and therefore not-safe-by-default) alternative in #30.

[RedneckMartha]

I have not unit tested, but changes are simple/minimal and look good.
Note: I don't see this change as breaking. If apps using this package start to break, it's because of incorrect protocol provided OR a potentially malicious redirection. Most concerning is https to http redirect. I'm not sure why http to https is a concern in the security advisory. In any case, this fix plugs the hole and will surface the problem if there is one.

[s100]

Is there anything we can do to assist with getting this PR merged and a new version of @cypress/request published? We could really use this security fix downstream and we are trying to avoid creating a fork of your fork just for this. Thank you in advance.

[atomjump]

I second S100's suggestion. Note: we have been running the version with this patch (made manually) without any issues in some of our products.

[legobeat]

@nagash77 Have you had a chance to consider this?

[G-Rath]

note that to properly resolve GHSA-p8p7-x288-28g6 this behaviour needs to be enabled by default - given the usecase of this library and that it's a security issue I think it would be fair to argue this is a bug and so valid to change in a patch version with it enabled by default (i.e. this PR, rather than #30)

[nagash77]

Hi @legobeat , we have not had a chance to review this PR. We are currently in a push to get a new major feature out the door but I will try and get some eyes on this in the next couple of weeks. I know that is probably longer than you were hoping for but it is the best we can do at the moment. This library is at the core of Cypress so changes here do have the potential to have wide ranging impacts so this will take awhile to ensure it is safe to merge this change.

I will make sure to keep an eye on this PR so it does not get lost and we can get to a resolution one way or another.

[chrisbreiding]

Thanks for this contribution and sorry it's taken so long for us to get around to reviewing it. I discussed this with the team and we decided we want to go forward with this PR, with the more secure option as the default. Since it's breaking, we'll follow semantic versioning and release it as a new major version of this package.

[cypress-app-bot]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[lukehsiao]

Will there be a new release of cypress itself that bumps this requirement?

https://github.com/cypress-io/cypress/blob/b17043102bcb7bb653efb6526238468c74b4d564/package.json#L75

[MikeMcC399]

@chrisbreiding

Confusingly the 3.0.0 release still shows an old version 2.88.11 in https://github.com/cypress-io/request/blob/v3.0.0/package.json

request/package.json

Line 10 in c5bcf21

"version": "2.88.11",

[chrisbreiding]

Confusingly the 3.0.0 release still shows an old version 2.88.11 in v3.0.0/package.json

@MikeMcC399 That's true. Thanks for pointing that out. Since semantic-release doesn't commit a version change back to the repo after a release, we usually set the version to something that can't be mistaken or the real version, but looks like we didn't do that when this repo was converted to use semantic-release. I'm addressing this in #41.

[chrisbreiding]

Will there be a new release of cypress itself that bumps this requirement?

@lukehsiao Yes. I'm addressing that in this PR.