一次 XML 上传导致域名被封的经历复盘（腾讯网址安全中心是不是只剩下机器人了）

深有同感，之前一个小程序也因为一张莫名其妙的图片，被腾讯封了，前前后后耗时一个多月，最终也只是降级到“打开网址会有风险提示”这种程度

你希望我们同情一下还是帮你喷一下腾讯呢
你说你「无意」投放了带恶意链接的 xml
姑且先不纠结为啥你们一开始会有这么个 xml,
也信了你们只是菜而不是坏
那既然你们行为确实恶劣影响，恶意脚本也实实在在让很多用户受害
那仅仅封一个域名不是很轻的惩罚了吗，
较真一点可以直接找网安调查一下你们才对。
经济损失也是你们活该

@NessajCN 不知道哪里恶劣了，黑灰产利用漏洞拿 xml 做了跳板，我们同为受害者。
我分享经历只是让大家能注意到这个问题，避免更多人犯同样的低级错误。

尊敬的用户您好，我们非常重视您反馈的问题，并对由此给您带来的不便深表歉意。腾讯云始终致力于为客户提供稳定可靠的服务，对于您遇到的域名封禁及申诉处理问题，我们已第一时间同步内部相关团队进行核查，并将积极协助您推进解决。为确保您的问题得到更高效的处理，请您将腾讯云账号 ID 或域名信息通过([email protected]) 邮箱发送给我们，感谢您的理解与支持。

这个更多是你们开发者的问题吧。就不应该开放 svg 的上传..

类似于 XXS 的 XXE 漏洞，如果使用 svg 图片作为矢量图要多注意：
https://github.com/rtnthakur/CVE/blob/main/MODX/README.md

最好每个项目都独立域名, 手里最少存一个备案过得应急域名

要不某个项目被风控, 就会牵连一大片项目.

@tencentcloud 你是真的还是假的。v2 里面怎么还有官方？？？

尊敬的用户您好！经复核您反馈的域名因存在恶意文件触发的安全拦截现已解除。我们对申诉流程中的不好体验深表歉意，后续我们将优化审核机制，提供更清晰的处置指引。若您有任何疑问或建议，请随时通过工单系统联系我们，我们将尽快协助您解决。感谢您的反馈与信任！

@jamel 这个应该是真官方 具体能不能解问题就不知道了 这个主题应该发在全球工单系统

@NessajCN 好像 xml 是其他人利用漏洞上传上去的，不是 OP 自己上传上去的，总之这么一想真的还是挺吓人的

上面的 @tencentcloud 已经反馈你们的安全拦截已被解除。 请楼主出来确认一下。

@NessajCN 我看文中 是 OP 他们上传了一个页面，可以上传头像， 其他人上传了带恶意 js 的 svg 图片，所以导致的问题，不是 OP 投放的链接 XML

腾讯的客服是真的弱 收钱是真的会收 最近注册公司做业务 一个公司四五个认证
微信开放平台 微信服务号 微信公众号 企业微信 小程序 每个都要单独出钱年审， 垄断了没办法。

封是真没什么问题，关键是要及时解

svg 这个学习了！

小程序嵌入的网页也因域名封禁无法打开 这个最好另外弄个域名跳转，避免牵连

@tencentcloud 真够讽刺的，官方渠道全是机器人，外部私人论坛倒是有活人盯着！

连 LOL 买皮肤不到账找一圈官网都找不到客服，腾讯系不会再充钱

@bugly @vace @tomatocici2333 @Liuman

有一个技术细节问题，svg 我之前研究过

svg 如果放到 <img> ，那么浏览器会禁止加载任何外部资源，脚本也禁止执行

除非你放到 <object>, <embed>, <iframe> 里，或者直接把 svg 内容嵌入到 .html 的 <svg> 里

LZ 你这个怎么触发的？

我猜，这个头像，没有在你们 小程序 里出的问题，而是头像资源被嵌入到别的什么页面里引起和你们无关的人访问，然后腾讯把你们域名给牵连了？

鸡蛋别放在同一个篮子里……老祖宗的智慧这一块 以后还是多研究一下支付宝小程序的好，至少有个备用方案
不过“遭遇危机”这一栏里，你们是已经把 xml 删掉了再申诉的吗，还是当时还没发现一直在申诉，后续才发觉的

垄断惯的毛病

@est 我们是做 VR 、全景之类的在线创意服务，客户 A 定制的小程序允许用户上传头像，有恶意用户通过调用上传接口（接口允许 svg/xml ），然后 xml 被存储到了 bucket 中，接口返回了 url ，这个 url 就是上面提到的。

然后他们把这个 domain.com/xxx.xml 当成链接，引导别人访问，如上截图，会带上一些参数，再由内部的脚本解析参数，跳转到其他的页面。

客户 B 也和我们有合作，然后就是这些文件被识别到了，所在的主域名被封禁了，我们排查问题才发现这些 xml 的问题。。。。

@anivie 第一次申诉会有提示是什么原因，哪些文件造成的，然后就立马删除这些文件了，并遍历了桶内的全部文件。

第二天申诉还是一样的邮件回复，一天只能提交 1 次，我们想了各种方法，比如上面提到的，都是完全一样的邮件回复，坚持申诉了一周多，感觉不会有改变，就放弃了。

@tencentcloud 非常感谢 确实帮我们解决大问题！

我们后续会加强网站安全建设，避免被黑灰产再次利用。

@est 因为它用户传的是 xml 根本不是 svg ，只是 svg 本身就是 xml 的一种，它没做好检测被绕过了

@drymonfidelia 它传的就是 svg 。svg 可以用 js 来做动画。

然后黑产引导用户直接访问这个 svg 链接。这个情况下的确 js 是可以执行的。

然后腾讯检测到，就把 up 主的域名封了。

归根结底还是这个 bucket 没管理好，被人利用来传别的东西，然后当成链接分享出去霍霍了。

svg 内嵌 script ？这个还真没想过

嗯，调用 oss 资源没有签名吗，有签名也不会被黑产引导直接访问链接吧（时效限制）。

还有一些其他的措施，可以缓解，比如加上 Referer 限制，强制将 Content-Type 设置为 application/octet-stream 和 x-content-type-options 为 nosniff ，可以部分缓解该情况。

还有一些法子，应该有用但是不太常规。比如，存图片到 oss 时，先加密，然后展示时前端解密。不用太复杂，也没必要藏密钥。总之就是让机器人识别不出这是什么东西。用 xor 就可以（虽然可能绕过，但是足够应对非针对性的攻击）。

不过最好还是别允许 svg 了吧。

不仅仅是 svg ，上次我发现有人构造带 script 的 pdf 上传过来

这个腾讯关不了的站就会有人工客服了

@jamel 你可能是新人，不知道 V2EX 有全球工单系统的功能。很多新闻都是从 V2EX 出来了。

牛逼

曾经也经历过基于公众号的 H5 域名被封的经历，也是根本找不到人工客服！最后无奈换域名

@bugly 迟到的正义赔偿你损失了吗？

域名封了就封了啊. 我家附近的电驴充电桩, 经常被封, 昨天扫码跟今天扫码, 弹出来的小程序都可能不是同一个.
你事先就要备好多个域名多个小程序, 封了一个另一个马上补上就行了

svg 是可以执行 js 的，大家需要注意，下方是示例代码：
```
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 360 640" preserveAspectRatio="xMidYMid meet" xmlns:xlink="http://www.w3.org/1999/xlink">
<style>
text {
font-size: 24px;
text-anchor: middle;
dominant-baseline: middle;
fill: #333;
}
a {
text-decoration: none;
}
</style>
<a xlink:href="https://www.baidu.com">
<text x="50%" y="10%" id="hello">loading...</text>
</a>
<script type="application/ecmascript">
<![CDATA[
setTimeout(function() {
var textElement = document.getElementById('hello');
textElement.textCOntent= "点击跳转";
}, 1500);
]]>
</script>
</svg>
```
保存为 test.svg 双击即可运行 js 代码，改成 test.xml 也是一样的道理。

我们的图标库项目是使用 [svglint]( https://github.com/simple-icons/svglint) 严格要求 SVG 图片的格式

感谢楼主，最近新上线的图床之前没注意到这点，现在把 SVG 格式直接禁掉了~
欢迎大家体验免费图床： https://img.lusyoe.com

@tes286
我们的业务大部分不涉及后端，前端开发完流水线同步发布到 oss ，通过用 CDN 访问，由于全景之类的项目会生成很多 xml 文件，文件内又有各种资源的引用，还要考虑性能等各种限制，所以对资源进行签名难度比较高。而且我们一直把 xml 当作一种可信任的配置格式。


@busier
被封禁能理解，主要是解决问题的过程曲折，损失的部分是学费吧。


@bthulu
一直兢兢业业，平时也很注意安全，连诱导分享都不敢做，所以没有提前准备对抗手段。

封可以

但应该提示正确的问题原因

解决后解封

关键不是封,而是处理方式太恶心

@bugly 感觉你 #3 这句 “黑灰产利用漏洞拿 xml 做了跳板，我们同为受害者”这种心态存在很大误区，包括其他很多从业者，都存在很大误区。。。

主体是受害人没错，但更大的是责任人，是责任人，是责任人。。是你们自己开发存在漏洞，才导致后续一系列后果。第一责任人是你们自己。如果因为漏洞造成用户的损失，第一责任人还是你们。

@pytth 感谢你的示例，v2ex 马上被封

@vace 这个就是 xss 漏洞，不是 xxe

@lscho 第一责任人不应该是干坏事和因此获利的人吗，谁能保证自己业务的几十万行代码，每一行都安全呢。如果这样推论：坏人去 A 家拿了菜刀砍人，A 是第一责任人，就因为 A 没锁上厨房的门、没把菜刀放保险箱？

再向上推论微信平台、手机的存在才导致这一系列的后果，如果没有微信、没有手机、没有互联网，就不会有人在网上上当受骗。

讲个笑话,网易云都被搞过,更何况小企业了.

我两年前刚注册的域名都被微信直接屏蔽 说有危险链接，可是我甚至还未个这个域名做任何解析。也是申诉了将近一个月 才找到真人客服帮我处理了。

现在黑产因为需要依赖微信内的正常访问的域名，自己注册域名的风险很高，因此是每天都要去挖漏洞，来避免一些问题，1 是避免被查； 2 是降低域名的开销； 3 是减慢被封的速度；尤其是大厂大公司知名企业的域名，很多黑产都是比较喜欢的，因此腾讯、百度、网易、小米、美团、新浪、阿里等企业的域名很多都存在 XSS 以及文件上传漏洞。
-
常见于以下地方：
1 、微信小程序头像上传、反馈、发布；
2 、APP 的头像上传、文件上传、实名认证、营业执照上传等地；
3 、网页的文件上传例如富文本编辑器、头像上传、附件上传；
-
漏洞常见问题：
1 、对象存储可通过重放，html 文件改后缀为 png 即可上传，一般没有做文件类型校验的对象存储；
2 、重放时 Content-Type:image/png ，改为 text/html 也可以轻松绕过，仍然是文件类型校验不严谨所致；
3 、验证 Content-Type 和后缀名，但是并未验证真实的二进制数据，在 html 代码中混入图片的头信息当然可以传上去；
4 、后缀名只限制 html ，但是未限制 htm\xhtml\xhtm\shtml\mhtm 等类型，这些仍然存在上传的风险；
5 、未限制 svg 和 xml 的上传，这些是存在执行 js 代码的风险的；
6 、对象存储容易通过 URL 传递?response-content-type=临时改变文件执行类型，上传的是 png ，链接虽然得到，但是无法执行 html ，对象存储可以拼接 ?response-content-type=text/html 即可将 png 作为 html 执行，即可出发 js 代码
-
以上是本人分析过很多很多黑产的一些常见案例。

@illl 写代码存在漏洞和被人强行攻击是两码事，所以你的举例不对。。。。代码有漏洞是你盖的房子有质量问题，并不是 A 没上锁。

如果是被 ddos 攻击，这才和你的举例一样。感觉你从头到尾都没有理解网络安全。因为网站是因为主体的需求而产生的，并不是因为“再向上推论微信平台、手机的存在”，因为主体的需求才产生了这个业务，如果因为主体没有做好安全防护，导致客户收到损失，主体就是第一责任人。

中华人民共和国网络安全法已经写的很清楚了

@lscho 我觉得你说的对，

一：我因为此次事件对我客户造成的损失，确实是第一责任人，这个道理我明白，也承担了客户的全部损失。
二，微信因为恶意文件的存在，封禁我的域名，我也能理解，我按照流程复查处理、申诉；
三：假如有人通过访问这个 xml 文件，再跳转到诈骗页面，这个人上当受骗，我也还是第一责任人吗？

@bugly 网络安全法中对网络安全实行的是等级保护制度。

如果你们企业履行了符合自身等级的网络安全等级保护制度，那么你们有可能不是第一责任人。但是从你的描述中，几乎可以确定没有履行。所以你们就是第一责任人。因为用户和平台是契约关系，至于平台被攻击，那是平台和攻击人之间的事，这是两个概念。

其实也就是事情发生到你们身上，你才觉得难以理解。换个说法，你一看就明白了。

假设支付宝有漏洞，你使用支付宝的时候，有人利用支付宝漏洞强制把用户的钱扣了。你觉得用户该找谁？用户肯定报案找支付宝追责，支付宝得去报案找攻击者追责，这是两码事。

@lscho 我觉得这个很难追责，目前从采样的 xml 样本分析中可以发现，每一个植入的脚本都指向不同的域名，他们明显不止控制了一个站点，有些可以拼接 html/xml 提供入口，有些可以注入 js 代码，有些可以提权执行后端代码，为了防止被追踪，访问链接也是重定向了很多次，再由这些零件组装了一个完善的诈骗站点。虽然我已经清理了这些恶意文件，但是不影响他们整个网络的运行。

@xiangbohua @Liuman @est @tes286 @lscho @pytth

我从样本中溯源了一个 xml ，看起来是一个售卖视频的页面，加载流程基本如下，下面的域名不固定，感觉会根据可用性判断跳转地点：

1 => 从某个上级渠道带参数进入我方 xml 执行 JS ，继续生成参数跳转到下一个域名

2 => 进入新的 htm 地址： https://img.yeepay.com/spaceTravel/img/2508122039270000006.htm

3 => 在页面调用了个后端接口： https://web.游小戏.cn/index/index/get?buck=XXXXXX&str=XXXXXX&sign=1111

4 => 生成一个访问 URL ，调用新的接口： https://mam.云途腾.cn/api/url.php?k=1&jump=1&buck=XXXXXX&ur=&t=1111

5 => 根据 4 中返回的 url 又进入一个域名： http://uploadn.luoxiangqiche.com/jiahui-cms-lab/prod/ee9d1d0fe5f1d1f722236c69ee67dd0a.html

做了这么多，只是为了保护 5 的目标地址？ 5 从源码看有支付功能，后端接口是 3 ，域名是一个做挂车的公司持有 ，在微信中依然能访问，我已经给他们留言了。

@lscho 老师，这条作业流水线上我也是第一责任人吗....

@tes286 大佬问下，我使用客户端直传 oos, 在生成临时凭证设置
uploadContentType := []string{"image/jpeg", "image/jpg", "image/png", "image/webp", "image/bmp", "image/gif"}

这样能避免这类重放改文件类型的 xml 上传吗

@Configuration 您好，感谢您的关注与反馈！腾讯云提供 7×24 小时人工客服服务，您可通过腾讯云控制台工单系统 或在线售后等服务通道快速接入，或拨打 7×24 小时热线 95716 ，均有专人提供服务支持。后续我们会持续优化服务流程，确保沟通更顺畅。您的监督是我们进步的动力，感谢支持！

全球工单系统，果然名不虚传

@mengdodo 防不住，除非你上传的时候做二进制核验，读取文件的真实数据，进一步拦截伪造的图片文件。攻击者会将 test.html 修改后缀名为 test.png ，然后 test.png 内是 html 代码，其中 html 代码前面包含了图片头信息，二进制信息，可以绕过上传检测。，上传后得到 https://xxxxxx.oss-cn-hangzhou.aliyuncs.com/file/test.png ，执行后虽然是一个加载不出来的图片，但是，拼接 response-content-type 就可以指定这个文件的执行类型，例如：

https://xxxxxx.oss-cn-hangzhou.aliyuncs.com/file/test.png?response-content-type=text/html ，意味着 test.png 会以 text/html 类型执行，那么 test.png 等同于 test.html 了，里面的 js 就会被执行，除非你有严格的对象存储配置，禁止这样的参数去定义执行类型。