阅读本文后，我没有一个明确的答案：
http://palizine.plynt.com/issues/2010Oct/bypass-xss-filters/
浏览器会将<img> src中的text / html数据URI有效负载解释为执行<script>标记的文档吗？
如果没有，那么在第三方HTML中允许数据URI是否安全？
此用例在浏览器级别存在哪些安全机制？
答案 0 :(得分：9)
MSDN documentation说IE没有：
出于安全原因，数据URI仅限于下载的资源。数据URI不能用于导航，脚本编写或填充框架或iframe元素。
另一方面，Mozilla允许执行iframe和script：
数据：继承其引用来源的网址允许它们被使用 生成或窗口内容，父级可以与之交互。壁虎 一直这样做（我们已经分散了很多安全检查 在那周围不得不担心它。）
Safari和Chromium沙盒数据URI执行，有效地将它们视为跨域请求。
我们目前标记数据：URI无法访问任何其他来源，包括其他数据：URI。
HTML5规范声明：
如果文档或图像是根据数据生成的：作为HTTP重定向的位置（或其他协议中的等效项）返回的URL
原点是重定向到数据的URL的来源：URL。
如果文档或图像是根据数据生成的：在另一个文档或脚本中找到的URL
当调用导航算法时，原点是现任设置对象指定的原点的别名，或者，如果没有涉及脚本，则是启动导航到该URL的元素的节点文档。
如果以某种其他方式获取文档或图像（例如，数据：用户输入的URL，使用createDocument（）API创建的文档，则返回数据：作为HTTP重定向的位置返回的URL等）
原点是创建文档或图像时分配的全局唯一标识符。
RFC6454补充说：
URI本身不一定是同源的。例如，数据URI [RFC2397]与自身不同，因为数据URI不使用基于服务器的命名权限，因此具有全局唯一标识符作为原点。
CSSHTTPRequest library使用数据URI来执行跨站点GET请求，但这是它可以在所有浏览器中执行的最多。
<强>参考
答案 1 :(得分：1)
以这种方式注入数据是可能的，但重要的是要注意，也可以在图像本身的二进制数据中注入数据。无论哪种方式都没有100％安全。 EVER。如果您正在使用codeigniter框架，那么您可以通过
非常牢固地保护自己 $this->security->xss_clean()
除此之外，可以构建自己的这样一个脚本版本，只需用正则表达式删除危险的东西。在构建这样的脚本时，请记住要关注不同的字符编码。