2011 年出现了一波类似https://www.contextis.com/resources/blog/webgl-more-webgl-security-flaws/ 的博客文章，指出了 WebGL 的安全漏洞。在那个时候，WebGL 似乎可以用来从 WebGL 的帧缓冲区范围之外获取像素数据。在 Khronos 安全站点上，此问题似乎已修复 https://www.khronos.org/webgl/security/。他们谈到所有新的内存都归零，这样陈旧的数据就不会被看到。
简而言之，在过去的几年里，我没有看到很多关于这方面的讨论，WebGL 是否仍然不安全，还是现在可以使用？当前的安全问题是什么？
【问题讨论】：
标签： security memory browser webgl gpu
WebGL 的目标始终是确保安全，正如您在 Khronos 网站的链接中所描述的那样。但早在 2011 年，许多 WebGL 实现仍处于起步阶段，还有很多问题需要解决。正如您所发现的，有很多“天塌下来”的博客文章实际上只是指出了这些早期实现中的差距。
快进到今天，我认为现代 WebGL 的实现非常紧凑。考虑到现在 WebGL 安全性方面的漏洞不仅会影响启用 WebGL 的页面，还会影响任何网页，因为没有任何东西可以阻止恶意站点或注入代码在其他非 WebGL 页面上创建 WebGL 上下文。浏览器供应商非常重视这一点，如果他们认为存在未解决的安全问题，他们不会默认启用 WebGL。
许多现代实现还包含blacklists or whitelists，以确保仅在存在已知可保留安全模型的驱动程序时启用 WebGL。
所以是的，对于任何默认启用 WebGL 的浏览器，可以肯定地假设供应商对其 WebGL 实施的安全性充满信心。
【讨论】：
WebGL 做了很多事情来防止出现任何问题。
CORS
WebGL 不允许使用来自其他域的任何图像，除非该域授予跨域资源共享权限。
请注意，这与允许您使用任何图像的 Canvas 2D API 不同，但如果您使用来自不同域的图像并且您没有获得 CORS 权限，则画布将被标记为不可读；您不能再拨打getImageData 或toDataURL。
清除所有内存
WebGL 清除所有缓冲区、纹理、渲染缓冲区等，因此其他程序不会留下任何数据
检查所有边界
所有访问内存的函数都检查了它们的边界。您不能上传超出纹理或缓冲区等范围的数据。
强制执行着色器限制
着色器在发送给驱动程序之前会进行预解析，并检查它们是否没有通过某些限制。函数只能嵌套 8 层。标识符不能超过 256 个字符。检查并执行统一和属性限制。
所有着色器都被重写
用户提供的着色器不会直接传递给驱动程序。相反，它们使用生成的变量名称重写，在适当的地方插入边界检查，重写表达式以解决驱动程序错误。
WebGL 实现通常有一个黑名单
如果特定驱动程序出现问题，浏览器供应商将尝试添加解决方法或将其列入黑名单。
一些浏览器采取了更加极端的措施
Chrome（也许很快 Firefox）不会授予运行网页的进程直接访问 GPU 的权限。因此，如果 JavaScript 中的错误或 HTML5 中的错误导致页面运行某些代码，则该代码无法访问 GPU（或系统的任何其他部分）。
最重要的是，在 Chrome 中实际访问 GPU 的进程无权访问除 GPU 之外的任何内容。例如该进程无法访问磁盘。
WebGL 被设计为安全的，就像 JavaScript 或 HTML5 或图像解压缩或视频解码一样，如果存在错误浏览器会立即修复它。
【讨论】：