Fluture-Node is a FP-style HTTP and streaming utils for Node based on Fluture. Using followRedirects
or followRedirectsWith
with any of the redirection strategies built into fluture-node 4.0.0 or 4.0.1, paired with a request that includes confidential headers such as Authorization or Cookie, exposes you to a vulnerability where, if the destination server were to redirect the request to a server on a third-party domain, or the same domain over unencrypted HTTP, the headers would be included in the follow-up request and be exposed to the third party, or potential http traffic sniffing. The redirection strategies made available in version 4.0.2 automatically redact confidential headers when a redirect is followed across to another origin. A workaround has been identified by using a custom redirection strategy via the followRedirectsWith
function. The custom strategy can be based on the new strategies available in fluture-node@4.0.2.
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
Name | Vendor | Start Version | End Version |
---|---|---|---|
Fluture-node | Fluture-node_project | 4.0.0 (including) | 4.0.0 (including) |
Fluture-node | Fluture-node_project | 4.0.1 (including) | 4.0.1 (including) |
Resources that may contain sensitive data include documents, packets, messages, databases, etc. While this data may be useful to an individual user or small set of users who share the resource, it may need to be removed before the resource can be shared outside of the trusted group. The process of removal is sometimes called cleansing or scrubbing. For example, a product for editing documents might not remove sensitive data such as reviewer comments or the local pathname where the document is stored. Or, a proxy might not remove an internal IP address from headers before making an outgoing request to an Internet site.