我昨天在Chrome中打开了一个我们的webapps，并且发出了一个大红色的“警告这个站点包含来自URL的内容不好”。 我加倍检查了我input的url，并立即查看源文件并search了该文件。 果然，底部是一个带有编码url的脚本标记，当解码出来的时候就是Chrome发现的违规url。
我很好奇这是怎么完成的，以后怎样才能避免它。 我采取的步骤如下，但不知道如果他们是解决scheme。
我查看了IIS，看到该站点允许IUSR_ComputerName和IIS_WPG用户对整个webroot进行写入访问，原本是为了写入上载和日志文件。 我将其限制在需要写入的特定区域，并且仅限于IIS_WPG。
提前致谢。
这是一个开始。 IUSR_ComputerName是默认情况下IIS使用的匿名用户权限。 这意味着他们将能够做一个匿名的HTTP PUT，覆盖任何文件。
IIS_WPG是用于在其下运行应用程序池的权限的组。 我理解的方式，提高.NET用户对某些目录的权限应该已经足够了。 IUSR_ComputerName应该只需要读取权限。
什么是您的应用程序池设置使用？ 如果您运行多个站点，则为特定的用户帐户提供一些额外的安全性，而不是授予IIS_WPG组的权限。
这实际上发生在我身上，罪魁祸首是FTP。
在其中一个受感染文件的最后修改date当天检查您的IIS Web日志。 如果您的站点已启用FTP，请在此date检查FTP日志。 这是我们唯一能够弄清楚发生了什么的方法。
最后，我们发现networking上的一台机器感染了恶意软件，这些恶意软件在特定的FTP客户端列表中运行，并将包含未encryption密码的FTP设置文件下载到多个FTP站点。
你可以在任何一个网页中find有问题的代码吗？ 也许这是一个注入式攻击，有人正在进行中间人攻击，并在飞行中注入代码。
Neil Carpenter博客上的一篇文章概述了这一点：
回想一下networking的踪迹，我们看到了大量的免费ARP包默认网关的IP地址。 与默认网关相对应返回的MAC地址用于Compaq NIC（ ）; 但是，默认网关是具有不同MAC地址的Cisco设备。 基于此，我们确定本机正在进行ARPcaching中毒攻击（* ）以执行中间人攻击，并将iframe插入到HTTP通信中，其响应是一个html文档。
是的，代码实际上是在文件中，所以我们知道这不是SQL注入或中间人（man-in-the-middle）