运维第三方代码的教训

1、因程序漏洞导致主机被黑客控制，发包攻击第三方虚拟主机（某传奇私服和山东某政府部门的官网），造成宽出口拥堵。我们不得已终止服务。起初客户方拒不承认自己的代码的有问题，还威胁停单。
2、我方运维周末加班重搭环境，收回服务器管理权限，并增强安全防护。对方修改程序之后，服务再次启动。中途对方要求重开FTP权限以更新应用，我方回绝，要求所有更新必须先发更新包，由开发和安全组同事审核之后，运维负责更新。

3、程序运行期间，对方开发以客户要查数据为由申请phpMyAdmin权限，我方建议他们自己写PHP脚本查询数据。但对方表现很困难，能看出他们的开发能力相当薄弱。后来我方DBA帮忙导数据，对发现数据库设计简陋而且不合规范。
4、某次更新之后，程序运行不正常，对方开发又咬定我们的环境出问题，并长时间拨打我们开发同事的电话，纠缠不清，影响了我们的正常工作，最后查出是他们在脚本中写错了数据库密码。
5、12月1日，服务再次出现故障，部分地区和网络无法访问，经查：主要是对方程序cookies里面带了引号，匹配到了WAF标准规则库里面其中一条，被认为是入侵行为，所以被中断连接。后来我方运维去掉该敏感规则，目前运营正常。

附录一 WAF 防护：

Justice
连接中断的那个问题，通过和WAF设备的厂家了解：
主要是cookies里面带了引号，匹配到了他们标准规则库里面其中一条，被认为是入侵行为，所以被中断连接。
这个是之前有故障的那天之后就开始是这样配置的，不过那时候大家关注度不高，所以没发现
当前我们已经去掉那条比较敏感的规则，剩余的继续观察。
由于这个应用的安全性存疑，所以不得不防WAF设备进行防范。

附录二 第三方代码风险：

Chrisen
只要是第三方代码，风险都是有的。
具体到我们公司的研发结构和方向，ASP PHP基本没多少人精通。 Java 可以协助进行代码审查，但 Java 厚重，如果对方没有提供源码，我们只能从日志里分析，解决问题复杂而且缓慢。
从代码功能看，JS 一般也就是用来和客户进行数据交互，或者监测页面访问，不是主体功能。
当然XSS也是高危，但是我司前后端同事都有一定的处理经验，排查问题也就比较快了。
注：为了造成不必要的纠纷，我隐去了客户的名字。