7月26日发布的 KesionCMS V7.0x防注补丁

　　其实就是对

　　Public Function G(Str)

　　Public Function S(Str)

　　两个函数增加了双引号,百分号,星号直接过滤掉.

　　由于这两个函数在整个系统中被大面积使用,初步搜索了一下,整个科讯cms系统光引用KS.G()就多达2435处之多,使用的场合非常复杂,如果只是过滤掉内容里像“80%的市场”这样的句子也就算了,问题在于过滤掉这些符号将直接带来很多不可预知的系统功能问题.

　　比方说:server.urlencode()之后,url网址里会有很多百分号,像%20做为空格,你过滤掉%号.这个网址就不对啦,在utf-8里面会有更多的情况出现%号,都会导致不可预知的问题.

　　所以,这里头的确是个大漏洞,而且一直存在于V7所有版本.但是增加过滤符号只能说是个当前快速的临时的解决办法。而不是真正解决问题的办法。

　　这里需要说明的是，能开发出如此优秀的软件，说明咱科讯的技术是过硬的，但是作为系统安全的常识问题，而且是一个调用频率如此频繁的核心代码，为什么咱的技术员能容忍这种低级问题长期躺在那里呢？

　　这就让我联想到刚刚发生的"温州动车事故",你可以说中国的高铁技术是世界领先的，技术是世界一流的，但是为什么还会发生动车追尾那么低级的事故呢？

　　依我看，按下面的修改更靠谱一些：

　　G = replace(G,"0x","０Ｘ")

　　G = replace(G,"0X","０Ｘ")

　　因为据我说知，双引号并不对会系统造成危害，*号虽然会造成危害，但是分析了一般的攻击代码后，他一般都要跟单引号，百分号存在，如果攻击代码使用16进制绕过单引号的话，就一定存在0x打头的符号，这就是我过滤掉ox的原因。当然如果你提交的正常内容刚好含有ox的话，那就只好显示的时候再replace回来了。但是不管怎么说，ox出现在概率要远小于百分号吧，不管怎么说，反正我的小站www.czhao123.com一直就是这样处理的。

　　"温州动车事故"之后，据说铁路从上到下都要重新严格检查系统安全，我说咱们是不是也应该从来头尾彻底检查几遍,多测试认证几次呢？其实要做到也不难，因为我这种准技术的，都还能找出几个ＡＡＡ级的重大问题哦，关键是有没有真正用心查过？当然技术员一般都不愿意承认自己的作品有问题有漏洞，因为一但被证实出来存在漏洞就必须加班加点，可是中国人（包括我自己）大家谁都不愿意加班。

　　最后，希望咱科讯走得更健康更长远，也希望我的小站慢慢做得更好。哎，总是没时间，挂了个主页在上面就什么都没管了,总想把我的好多想法在我的郴州导航网上实现，可是又什么都没做。

听楼主这样说，确实问题很大啊

这种暴力过滤确实会带来很多问题，其实可以先编码再处理