我有一个网站，人们可以在其中上传图片，您可能会将其视为图片托管或图片论坛。
现在，我允许将光栅图形上传到一定大小，但目前还没有矢量图形。我也想允许 SVG 上传，但是有两个问题在我脑海中盘旋：
另外，为缩略图生成一个小的（200x200px）PNG是一种好习惯，还是用缩放因子或其他东西来操纵SVG本身更好？
如果这些 SVG 漏洞是可能的，我该如何保护自己免受它们的侵害？
SVG 是否可以以这样的方式构造，即在读取元数据时它会使服务器无响应。并且可以用作对服务器的 DoS 攻击？
元数据是什么意思？如果您追求宽度和高度，则必须至少部分解析 SVG 文件才能获得它；没有像许多位图格式那样从标头中读取几个字节的捷径。这带来了 XML 解析的常见风险，例如：
作为标准预防措施，您将禁用所有 DTD 处理、XInclude、XSL、XSI 和实体解析。
是否可以以这样的方式构造 SVG，即在客户端上呈现 SVG 时，客户端变得无响应并可能使我网站上的每个用户浏览器崩溃？
可能，但是位图格式也可能发生这种情况。参见例如不久前损坏的 PNG 文件漏洞。
SVG 文件更令人担忧的是它们可以包含 JavaScript，它将在托管站点的安全上下文中运行，因此您需要担心跨站点脚本。
实际上，所有类型的上传文件都容易受到此攻击，尽管不是以这种直接、易于利用的方式。在某些情况下，浏览器（尤其是 IE）会对它们进行内容嗅探，如果它们看到看起来像标签的东西，它们可能会将它们重新解释为 HTML，包括 JavaScript。此外，将上传的文件视为 Java 小程序和 Flash 策略文件也存在一些附带问题。
所有这些问题的标准缓解措施是为您的不受信任的资源提供服务，无论是位图、SVG 还是其他任何东西，从不同的域到您的主站点：一个没有敏感会话 (cookie/auth) 信息且没有能力的域将脚本写入您的主站点的域。
另外，为缩略图生成一个小的（200x200px）PNG是一种好习惯，还是用缩放因子或其他东西来操纵SVG本身更好？
那将是一个不错的选择，但是您必须拖入一些依赖项才能渲染为位图，例如，如果您使用的是 Java，则为 Batik。自然地引入新的复杂库会增加攻击面；将缩略图作为单独的低权限帐户低优先级守护程序任务运行可能是个好主意。
您的 Web 应用程序执行的任何操作都有潜在的危险。文件上传是比较危险的功能之一，因为它可能导致远程代码执行。
将任何文件上传到服务器的问题在于它实际上可能不是您想要的文件。我不知道您使用的是什么平台或方法，但我已经多次欺骗文件上传系统来上传 .php 或 .asp 文件并执行它。听起来您并没有在服务器端渲染 SVG（无论如何这有点奇怪），因此 SVG 中的原始 XML 对您的服务器并不重要。
就＃2而言，是的，svg内存损坏漏洞很常见，我相信还会存在更多。但是，对于您上传的任何文件，这同样适用。SVG 图像更新一些，并且 SVG 图像中的大部分漏洞都在 2011 年发现。
SVG Masking 用于在点击劫持攻击中隐藏 iframe。但我不认为这种攻击向量适用于您的 svg 上传系统。