[Flight] Taint APIs #27445
Merged
[Flight] Taint APIs #27445
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
React Core Team
Clean up values when the life time object gets finalized.
Instead of copying all typed arrays that we serialize into a string, we only do that if the length of the data is the length of any tainted binary value first. You're not really supposed to use this with arbitrary binary data but mostly things like hashes or tokens that end up with the same length.
A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object.
sophiebits
approved these changes
Oct 2, 2023
|
|
||
| const process = { | ||
| env: { | ||
| SECRET: '3e971ecc1485fe78625598bf9b6f85db', |
There was a problem hiding this comment.
cute
$ echo -n Seb | md5
3e971ecc1485fe78625598bf9b6f85db
There was a problem hiding this comment.
I was wondering who would be the first nerd to figure this out. Did you notice the hidden pattern for the other ones tho?
packages/react/src/ReactTaint.js
Outdated
| (typeof lifetime !== 'object' && typeof lifetime !== 'function') | ||
| ) { | ||
| throw new Error( | ||
| 'To taint a value, a life time must be defined by passing an object that holds ' + |
packages/react/src/ReactTaint.js
Outdated
| 'Cannot taint a ' + | ||
| kind + | ||
| ' because the value is too general and cannot be ' + | ||
| 'a secret by', |
When you add it a value to a shared in memory cache, then it can become associated with multiple other pending requests before it becomes freed. Typically a shared cache might hold onto it but even that cache might eventually free it, such as an LRU. That freeing could happen while a request that has extracted it from the cache has already gotten a handle to the data. |
|
Makes sense, good thinking. |
acdlite
added a commit
to acdlite/next.js
that referenced
this pull request
Oct 4, 2023
React upstream changes: - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
alunyov
pushed a commit
to alunyov/react
that referenced
this pull request
Oct 11, 2023
This lets a registered object or value be "tainted", which we block from crossing the serialization boundary. It's only allowed to stay in-memory. This is an extra layer of protection against mistakes of transferring data from a data access layer to a client. It doesn't provide perfect protection, because it doesn't trace through derived values and substrings. So it shouldn't be used as the only security layer but more layers are better. `taintObjectReference` is for specific object instances, not any nested objects or values inside that object. It's useful to avoid specific objects from getting passed as is. It ensures that you don't accidentally leak values in a specific context. It can be for security reasons like tokens, privacy reasons like personal data or performance reasons like avoiding passing large objects over the wire. It might be privacy violation to leak the age of a specific user, but the number itself isn't blocked in any other context. As soon as the value is extracted and passed specifically without the object, it can therefore leak. `taintUniqueValue` is useful for high entropy values such as hashes, tokens or crypto keys that are very unique values. In that case it can be useful to taint the actual primitive values themselves. These can be encoded as a string, bigint or typed array. We don't currently check for this value in a substring or inside other typed arrays. Since values can be created from different sources they don't just follow garbage collection. In this case an additional object must be provided that defines the life time of this value for how long it should be blocked. It can be `globalThis` for essentially forever, but that risks leaking memory for ever when you're dealing with dynamic values like reading a token from a database. So in that case the idea is that you pass the object that might end up in cache. A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object.
gnoff
added a commit
to gnoff/next.js
that referenced
this pull request
Oct 13, 2023
- facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
gnoff
added a commit
to gnoff/next.js
that referenced
this pull request
Oct 13, 2023
- facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
gnoff
added a commit
to gnoff/next.js
that referenced
this pull request
Oct 13, 2023
- facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
gnoff
added a commit
to gnoff/next.js
that referenced
this pull request
Oct 13, 2023
- facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
gnoff
added a commit
to gnoff/next.js
that referenced
this pull request
Oct 16, 2023
- facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436
ztanner
added a commit
to vercel/next.js
that referenced
this pull request
Oct 16, 2023
…experimental prefix for server action APIs (#56809) The latest React canary builds have a few changes that need to be adopted for compatability. 1. the `useFormState` and `useFormStatus` hooks in `react-dom` and the `formData` opiont in `react-dom/server` are no longer prefixed with `experimental_` 2. server content (an undocumented React feature) has been removed. Next only had trivial intenral use of this API and did not expose a coherent feature to Next users (no ability to seed context on refetches). It is still possible that some users used the React server context APIs which is why this should go into Next 14. ### React upstream changes - facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436 --------- Co-authored-by: Zack Tanner <zacktanner@gmail.com> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Jiachi Liu <inbox@huozhi.im>
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
This lets a registered object or value be "tainted", which we block from crossing the serialization boundary. It's only allowed to stay in-memory. This is an extra layer of protection against mistakes of transferring data from a data access layer to a client. It doesn't provide perfect protection, because it doesn't trace through derived values and substrings. So it shouldn't be used as the only security layer but more layers are better. `taintObjectReference` is for specific object instances, not any nested objects or values inside that object. It's useful to avoid specific objects from getting passed as is. It ensures that you don't accidentally leak values in a specific context. It can be for security reasons like tokens, privacy reasons like personal data or performance reasons like avoiding passing large objects over the wire. It might be privacy violation to leak the age of a specific user, but the number itself isn't blocked in any other context. As soon as the value is extracted and passed specifically without the object, it can therefore leak. `taintUniqueValue` is useful for high entropy values such as hashes, tokens or crypto keys that are very unique values. In that case it can be useful to taint the actual primitive values themselves. These can be encoded as a string, bigint or typed array. We don't currently check for this value in a substring or inside other typed arrays. Since values can be created from different sources they don't just follow garbage collection. In this case an additional object must be provided that defines the life time of this value for how long it should be blocked. It can be `globalThis` for essentially forever, but that risks leaking memory for ever when you're dealing with dynamic values like reading a token from a database. So in that case the idea is that you pass the object that might end up in cache. A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object.
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
This lets a registered object or value be "tainted", which we block from crossing the serialization boundary. It's only allowed to stay in-memory. This is an extra layer of protection against mistakes of transferring data from a data access layer to a client. It doesn't provide perfect protection, because it doesn't trace through derived values and substrings. So it shouldn't be used as the only security layer but more layers are better. `taintObjectReference` is for specific object instances, not any nested objects or values inside that object. It's useful to avoid specific objects from getting passed as is. It ensures that you don't accidentally leak values in a specific context. It can be for security reasons like tokens, privacy reasons like personal data or performance reasons like avoiding passing large objects over the wire. It might be privacy violation to leak the age of a specific user, but the number itself isn't blocked in any other context. As soon as the value is extracted and passed specifically without the object, it can therefore leak. `taintUniqueValue` is useful for high entropy values such as hashes, tokens or crypto keys that are very unique values. In that case it can be useful to taint the actual primitive values themselves. These can be encoded as a string, bigint or typed array. We don't currently check for this value in a substring or inside other typed arrays. Since values can be created from different sources they don't just follow garbage collection. In this case an additional object must be provided that defines the life time of this value for how long it should be blocked. It can be `globalThis` for essentially forever, but that risks leaking memory for ever when you're dealing with dynamic values like reading a token from a database. So in that case the idea is that you pass the object that might end up in cache. A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object. DiffTrain build for commit 843ec07.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This lets a registered object or value be "tainted", which we block from crossing the serialization boundary. It's only allowed to stay in-memory.
This is an extra layer of protection against mistakes of transferring data from a data access layer to a client. It doesn't provide perfect protection, because it doesn't trace through derived values and substrings. So it shouldn't be used as the only security layer but more layers are better.
taintObjectReferenceis for specific object instances, not any nested objects or values inside that object. It's useful to avoid specific objects from getting passed as is. It ensures that you don't accidentally leak values in a specific context. It can be for security reasons like tokens, privacy reasons like personal data or performance reasons like avoiding passing large objects over the wire.It might be privacy violation to leak the age of a specific user, but the number itself isn't blocked in any other context. As soon as the value is extracted and passed specifically without the object, it can therefore leak.
taintUniqueValueis useful for high entropy values such as hashes, tokens or crypto keys that are very unique values. In that case it can be useful to taint the actual primitive values themselves. These can be encoded as a string, bigint or typed array. We don't currently check for this value in a substring or inside other typed arrays.Since values can be created from different sources they don't just follow garbage collection. In this case an additional object must be provided that defines the life time of this value for how long it should be blocked. It can be
globalThisfor essentially forever, but that risks leaking memory for ever when you're dealing with dynamic values like reading a token from a database. So in that case the idea is that you pass the object that might end up in cache.A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted
entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object.