Ajax密文传输数据

前端之家收集整理的这篇文章主要介绍了Ajax密文传输数据前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

AJAX还是比较强大的!(显然,这是一句废话),最近在研究一个网站的AJAX应用中发现其中的“拓展视野”部分频频被挖掘出来(也由此可见,平时本人的视野有多么的狭窄了),首先是全站的JS全部使用packed进行了压缩,呃!也不知道这种称法是否正确,就是用eval(function(p,a,c,k,e,d){})的那种世界各地都很流行的压缩方法吧,在实际的观察中,一个压缩后仅为6K,在我将其转化为“肉眼能看清楚的代码”之后,足足有20K,可见其效果还是相当明显的;此外,用HttpWatch弄到了传输数据后,居然是加密的。。。形如下面这段:
q1YqT81MzyhRsqpWys3MU7Iy0FHKTaxQsjLWUUrLL8pNBMooqeoZpSnV6igVFGUmp2KoVDIzMrIwNdAzMFBC1pOiVFsLAA==

任何一个有些许密码学经验的同志都容易很看出来,这是base64编码(我实在不喜欢称这个为“加密”),没错,和各位看官一样,我很快就用PHP自带base64_decode函数对其进行了解密,如果您觉得问题到此为止,那就错了!这时我才稍稍感到了有些震撼,解密出来的数据

呃!一堆乱码,其实应该是二进制数据,加密了(后来知道是压缩了),可是用户是看不懂这些的,客户端是肯定要进行解密的!用什么?AJAX的当然用JS解密了,挖解密函数啊,挖解密函数,看到了如下的精彩代码

var filterList=eval('('+utf8to16(zip_depress(base64decode(g_pgFilterList)))+')');

utf8to16()和base64decode()都好理解,也再一次证明加密的最后是用base64编码输出的,关键就是这个zip_depress(),zip解压?
是的,千真万确,用JS实现了zip的解压算法!!!到这里我深深的感到了震撼,原来,我知道的真的太少了啊!虽然之前知晓有md5.js,知道JS在运算方面是没有问题的。不会是这家伙自己写的压缩算法吧?经过搜索,我找到了这个算法(Zip inflate)的原版,原来该网站的制作人员修改函数名,难怪我直接google不到呢?
什么是inflate算法?—

inflate是GZip,PNG等广泛使用的解压算法,linux也使用inflate对内核进行解压.inflate的解压算法使用的第3种快速解压法的一个子集,它不考虑LONG_CODE,同时把SAME_LENGTH合并到MEDIUM_CODE。而对于规则的SAME_LENGTH编码,比如length和distance编码,inflate则使用额外的base和extra表示。这是因为在构造一般的查找表时,虽然对于SAME_LENGTH前缀可以不构造副表,但我们需要另外一个表格来保存符号的顺序,而这个表格的空间可能更大。但对于length和distance编码,他们的顺序是递增的,所以无需额外的表格来保存符号的顺序。

inflate使用root表示上述的b,查找表的数据结构为code.主表和副同时保存在inflate_state结构中的大数组codes[ENOUGH]中.表的构造函数位于inftrees.c文件的inflate_table中.

令人感到欣喜若狂的是,PHP竟然已经提供的现成函数来解压和压缩inflate,它们是gzinflate()gzdeflate(),哈哈哈!我不禁仰天狂笑的一番,用gzinflate()成功的将上文数据解密,内容是这样的:

{"weight":{"min":0,"max":3,"format":"%.2f"},"price":{"min":0,"max":"622850.00","format":"%d"}}

标准的JSON数据啦,不错!这就为以后的AJAX的传输上多了一个选择,虽然还不确定这种方法能否节省流量(因为base64算法会将原始数据“稍稍”增大),但客户端有了解压算法,服务端的PHP压缩函数又是现成的,大不了在base64这个环节上大概需要改进下,我想对于@R_125_403@的数据应该还是有确切效果的。嗯,我很满意。

原文地址:http://www.zendstudio.net/archives/js-zip-inflate/

原文链接:https://www.f2er.com/ajax/162733.html

猜你在找的Ajax相关文章