1、案例一：我网站的日期转换函数被植入的广告代码重写导致客户端所有使用该函数的日期都是错误的 1、先说问题 时隔几个月，没有详细截图，只能口述。 开发a组的同事收到部分用户反馈网站日期不正确，本地测试无论如何都不能重现问题，请注意：是部分客户、测试无论如何都不能重现问题； 开发a组找到平台开发人员，接触新问题一开始都不知道原因，有时候经验也不管用，先分析问题吧：这个问题具有特定性，也就是个体差异，应该从客户端去找原因，并排除假想者认为是服务器数据故障。 2、处理经过 用户在异地，只有通过远程查找问题，已经是很普及的方法了，就连亲戚朋友电脑出问题他们也懂远程协助。 a、确认问题是否存在. b、既然是javascript函数解析日期出了问题，毫不犹豫按F12快捷键，凭肉眼死盯着界面是看不出问题，必须定位到问题根源。 1、熟悉平台的人凭经验判断找出日期转换函数的位置：输入Date.format，查找定位脚本，设置断点； 2、不熟悉平台的同事，可以根据控件名称来定位脚本，比如界面上很明显的是Grid的DateTimeColumn列日期显示异常，因此在按F12弹出开发人员工具查询框里面输入：DateTimeColumn，定位到对应控件脚本，javascript对程序员来说都不会陌生，凭经验找出日期转换的代码，并设置断点；如图1 c、断点设置好之后，重新打开网页，进入断点，按F11跟进去Date.dateTimeToStr，很明显是自定义的公共函数，继续跟，如下图2 我们知道Date对象是没有format方法的，因此可以判断上面的dateTime.format是平台定义的日期转换函数，Date.prototype.format = function Date$format(format) { .... }, 继续F11。 d、惊奇的事情出现了，当前断点跳入了一个未知的js脚本里面，跟进去的format函数不是平台定义的，意思是：根本没有执行平台format函数而是执行了其他脚本的format。 e、我也是第一次遇到这样的问题，所以说解决问题也是学习的有效途径。 如此一来就会想到，其他脚本从何而来？ 才会想到使用网络抓包工具可以看个究竟，就会情不自禁的打开Fiddler，当然还有很多其他工具，第一次接触它就觉得很好用； 为什么要会用Fiddler？ 很多开发上遇到问题都可以用这个工具排查，比如调用xx网站的API，首先你要分析它的数据包格式吧。 客户机器肯定是没有该工具的，需要开发人员先安装。 其实F12开发人员工具也可以看到网络请求，看到请求加载的脚本，各大主流浏览器都集成了类似插件。 f、打开Fiddler，刷新网页，可以看到Fiddler里面每一个请求结果，其中就会找到不属于我们网站的脚本，而且很多第三方的脚本请求。 最重要的是用fiddler可以看到服务器返回的json数据，其中日期数据明明就是2014-11-11，页面上显示的日期却是1990，由此可以断定不是服务器数据问题... 3、问题分析 由2，就解释了我们的网站被嵌入了三方脚本，且三方脚本与平台的日期接口函数重名，从而日期转换格式异常。 访问我们的网站为何会嵌入三方脚本？首先想到的是不是哪个开发人员想用第三方js库引入的呢？经过询问排除此原因，如果是程序本身嵌入了第三方脚本，所有客户都会受影响，现在是特定用户。 也不去管js从何而来了，反正程序本身没有，只知道是在网络传输过程中被加入的，从而想到曾经有位老大跟我们说过类似电信广告问题，不过针对此问题改程序本身就有点捉急，改了也不会立刻发版，你懂的，线上几十万用户等着使用呢。 我们分析，嵌入的4个三方js的地址格式，如：http://xxx.com/js/a.js?xxx=xx 在网页中，查看源码表现形式如下图3 有人想到修改用户的hosts文件，将xxx.com 映射到 127.0.0.1，这样特定js的请求会失败，脚本就不会得到执行，因而保全了平台的完整性；查了下，也确实有人这么做的。 问题暂告一段落...
2、案例二：我网站的特定用户在录单过程中出现白屏 时隔几月，与案例一的经验没有联想在一起，也走了不少弯路才找到问题原因，现象不一样，本质却一样； 开发反馈：某个用户操作过程中白屏了，且出现Type未定义的脚本错误 还得从一开始的问题反馈到远程客户找原因，这个流程是必然的，你需要学会与客户有效且愉快的沟通，不要问题没解决好自己被气的半死，为何要说“气”，曾见过被用户折腾的想哭的客服，对于客户来说你需要转变角色，这点很重要。 问题分析：Type是我们平台的一个公对象，居然出现未定义？焦点一下转移到平台脚本上面去了，是不是平台相关依赖的脚本没有加载？什么情况下没加载？肯定是客户网络慢，开始胡思乱想。 特定客户问题分析要领：从浏览器兼容性、木马病毒（没遇到过）、客户网络几个原因着手。 1、重现问题 告诉用户，让他操作先重现问题；作为平台维护的人，面对不是自己开发的产品和业务流程陌生感油然而生，不过这不是影响解决问题的因素，客户端问题本质是脚本与兼容性，与懂不懂业务没多大关系。 我盯着屏幕，看着用户操作半天，问题依然没出现，好，请他先暂停一下，看来该问题具有偶然性，不是必然重现。 再次分析可能原因：1、与数据有关，特定账号、特定数据才会触发，90%以上是业务性问题。2、特定浏览器下。 是同一账号，数据相同，排除1；客户机器就只有一款ie8浏览器，排除2； 遇到不明原因的问题就越想弄清楚才罢休，开发经验有限，主要还是没有重现问题，不知道具体现象，远程操作紧到找不到原因也耽搁双方时间，就告知客户如果再次出现白屏，保留现场并立刻通知我们。 虽然没重现到问题，还是记录了客户使用情况：windows xp系统、2G内存、IE8浏览器，改为了非兼容模式，问题没有重现；并记录到Tower项目管理计划中：2014-11-04 远程检查，有个客户使用“xxx快速登录工具”或兼容模式,IE8,特定操作出现白屏的问题（没重现到，特此备案） 2、紧急召回 客户弹窗说他又出现白屏了，远程一看，果然整个浏览器都白茫茫一片，客户还在抱怨花了半天时间录单的事，不厌其烦的开始我的工作，先抓图。原来客户使用的是自定义的浏览器工具下出现的白屏，排除是否工具问题导致，切换成360安全浏览器试试。如下图，问题一样，说明跟浏览器无关。 好，通过查看源文件，白屏和出现Type未定义错误的现象就很好理解了，整个网页就只剩下两个script标签，所以白屏；其中一个是我们非常熟悉的/R.axd?xxxList.js，这个脚本里面对Type对象有引用，而当前上下文紧有两个脚本标签，没有Type对象；之前完整显示的单据中肯定会有table，div，body标签啊，那其他标签去哪儿了？既然问题重现了，那好办多了，管它三七二十一，安装Fiddler，打开Fiddler，操作网页单据，等待问题重现，如下图，铁证如山：解决方案 面对如此大招，1、加映射无济于事，这样的情况只有把官网映射到127.0.0.1。 2、检测到有脚本植入，立刻刷新页面，那悲剧了，用户的输入的单据怎么办？当前操作还没保存。 还是得从程序自身出发，eval脚本之前，对脚本进行检查过滤，具体实现细节： a.检查执行的代码是否对程序本身有干扰，目前就document.write造成白屏影响而谈。 b.如果没有干扰，执行脚本。 c.检测到干扰，也不用去做过滤了，重新请求原脚本文件，既然是异步的那就可以重新请求一遍，轮询a，每个脚本文件出现错误最多尝试8次请求，如果还是被植入广告，那就终止当前用户操作，提示用户，先保存当前任务，过会再试。 d.如果c检测到干扰，记录错误日志到服务器（log.txt)，可以作为后续分析统计情况。
3、Fiddler相关推荐 1、Fiddler介绍篇http://www.2cto.com/kf/201308/234826.html 2、使用Fiddler提高前端工作效率http://www.2cto.com/kf/201308/234828.html总结 1、ISP拦截请求插入广告 方式一：纂改网页数据包，针对Content-Type为text/html类型的请求，嵌入script标签。 方式二：纂改脚本请求数据包，针对Content-Type为application/x-javascript，完全重写脚本内容，加入document.write语句。 方式三：串改数据包，针对Content-Type为application/x-javascript，完全重写脚本，在原有数据的基础上增加自己的广告代码。 目前就知道以上三种方式，共同的特点广告代码都是外链；其中1、2我们已经遇到过，它没有影响产品的原有结构，并且我们有相应的对策；3影响了产品的独立性和完整性，已经改变了网站自身的结构了（没遇到过）深究 研究isp广告脚本有何意义？ 个人理解不同的广告商植入的广告千奇百怪，层出不穷， 输出到客户端的脚本无非就是一些dom操作，实现广告播放吧；更狠点的盗取客户端cookie信息等；ISP真正有意义的算法分布在不同地方的服务器上。案例二中为何在地址栏输入http://xxx/re/re.php?...返回内容为空？那通过我们的电脑访问官网的网站一切正常呢；或许跟我们申请的宽带账号有关系，分区域、特定网络、甚至特定宽带id、按ip归宿地来固定投放广告，总之这是一套复杂的算法。另外re.php是一个动态文件，中间不知道它要经过多少跳转，整个过程做了些什么事情，这个问题现在还没搞清楚，待牛人出现。。。