[x3d-public] SFImage component mismatch; security implications
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Mon Sep 16 04:55:34 PDT 2019
In general, the usual spec response is "results are undefined" because we avoid legislating how bad content should be handled, letting browsers do whatever is most efficient. Caveat author - thus the importance of quality assurance (QA).
Looking at Web3D Conference 2019 release of X3Dv4 spec, not finding any such statement:
5.3.6 SFImage and MFImage
We should probably add this, something like
"Rendering results are undefined when an incorrectly specified SFImage texture or MFImage texture array is defined."
Also thinking we should list Security Considerations for this domain. For example, conceivably a malformed SFImage might lead to buffer overruns or definition of hostile code if not protected against.
Food for thought:
An Overview of Image Security Techiques - Semantic Scholar
What could an “<img src=” XSS do?
IMG tag vulnerability
On 9/15/2019 1:11 PM, Andreas Plesch wrote:
> A question on PixelTexture came up on how to treat SFImage pixel
> values which do not match the number of components. For example,
> "1 1 1 0xAABB"
> gives a value larger than 0xFF for the one component pixel.
> Is this just invalid or should the value be masked to the lower byte, 'BB' ?
> If invalid, is there guidance on how browsers should render ? black ?
all the best, Don
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the x3d-public