360浏览器提醒12306：请正视“穿越”漏洞 这不是…

　　最近，一些用户通过12306官网购买的车票，出现购票日期错误的情况，明明选定了若干天以后的车票，但实际订票付款后，却发现票面时间发生错误，与用户预期的订票时间最多相差20天，严重影响旅客正常乘车。

　　网站出现漏洞不可怕，可怕的是回避漏洞。特别是在春运抢票的高峰时期，一旦车票日期出错，财产损失是小，直接耽误旅客回家行程。实际上，任何网站都有可能出现漏洞，出现漏洞也不是什么丢脸的事情，就连谷歌、微软这样的世界顶级公司的大企业的产品也经常出现各种漏洞。

　　12306“穿越”漏洞解决起来也并不困难。360技术工程师分析发现，此问题是12306网站响应用户“查询余票”请求时，响应内容缺少四个关键参数。一旦网络繁忙或12306服务器负载较大，出票时间就会出现匹配错误的情况。只要补充上述参数，漏洞即可解除。

　　过年回家，是中国人亲人相聚、血脉相连的象征。古装片的穿越剧好看，但穿越漏洞一点都不好玩。请12306正视漏洞，解决漏洞，让更多人顺利回家，是我们共同的愿望!

　　附1：遭遇穿越漏洞用户反馈

　　网友小红帽要茁壮成长：看了一下图片，我那天就是一模一样的情况。明明选的20天后，结果出来就是第二天的票。而且用的是手机版，更看不到日期!

　　网友忘年雨：我也被坑了，买28号的票，结果出来的是9号的我这一下子被坑了三个人!

　　广东陈先生：“本来输入的购票日期是1月29日，在查询、预订页面都没有问题，可是在最后的确认订单、支付环节，车票的出发时间却奇怪地变成了1月10日。”

　　网友“Summer_在路上”：“我同学今天来车站取1月12日回家的票，结果取出来的车票上面，日期竟然写着是2013年12月24日，都要被12306傻哭了!”

　　附2：360工程师提供的“穿越”漏洞解决方案

　　12306服务器没有舍得带上请求中的四个关键参数：

　　leftTicketDTO.train_date=2014-01-28

　　leftTicketDTO.from_station=BJP

　　leftTicketDTO.to_station=QFK

　　purpose_codes=ADULT

　　这样带来的后果是：

　　当客户端先后发出查询请求一和二时，客户端中无法明确分辨两个回应分别对应哪个请求，只能假设先回来的是回应一，后回来的是回应二。

　　这在大部分情况下，的确是正确的。但是当网络繁忙或者12306服务器负载较大时，这个假设就会不成立：

　　请求一发出后，会长时间(超过5秒)收不到回应，客户端因为定时5秒查询而发出请求二;

　　当请求以发出超过10秒时，客户端认为不会再收到回应一了;

　　于是，在请求二发出后，姗姗来迟的回应一被客户端当作回应二处理了!

　　如果请求一是查询1月8号的票，请求二是查询1月26号的票，那么用户这种情况下：在1月26号的结果中看到的其实是1月8号的结果，下单时也就会被误下单成1月8号的票—而他自己以为是1月26号的