More details on data processing for Rule Of 2.
People have questions about primitive functions on opaque data, so explain a bit more about how parsing/deserializing/et c. is different. Bug: None Change-Id: I645b916a98cd616c710a53cdda22e60d80ee951b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2737520 Reviewed-by: Adrian Taylor <adetaylor@chromium.org> Reviewed-by: Adrian Taylor <adetaylor@google.com> Commit-Queue: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#881050}
This commit is contained in:

committed by
Chromium LUCI CQ

parent
e5f51c8ae0
commit
e4b62db571
@ -104,6 +104,22 @@ good) or [origin
|
||||
isolation](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=IsolateOrigins)
|
||||
(even better).
|
||||
|
||||
### Processing, Parsing, And Deserializing
|
||||
|
||||
Turning a stream of bytes into a structured object is hard to do correctly and
|
||||
safely. For example, turning a stream of bytes into a sequence of Unicode code
|
||||
points, and from there into an HTML DOM tree with all its elements, attributes,
|
||||
and metadata, is very error-prone. The same is true of QUIC packets, video
|
||||
frames, and so on.
|
||||
|
||||
Whenever the code branches on the byte values it's processing, the risk
|
||||
increases that an attacker can influence control flow and exploit bugs in the
|
||||
implementation.
|
||||
|
||||
Although we are all human and mistakes are always possible, a function that does
|
||||
not branch on input values has a better chance of being free of vulnerabilities.
|
||||
(Consider an arithmetic function, such as SHA-256, for example.)
|
||||
|
||||
## Solutions To This Puzzle
|
||||
|
||||
Chrome Security Team will generally not approve landing a CL or new feature
|
||||
|
Reference in New Issue
Block a user