PHPcms加密通信到底怎么搞？聊聊我踩过的那些坑
说实话，第一次听到“PHPcms加密通信”这个词的时候，我脑袋里是懵的，那会儿刚接手一个老项目，用的是PHPCMS V9，客户突然提了个需求，说前后端传输的数据得加密，不然怕被人抓包篡改，我当时心想，不就是加个密嘛，有啥难的？结果……哎，别提了,坑是一个接一个。
为什么PHPcms加密通信这么让人头疼？
你得知道，PHPCMS本身是个挺老的CMS框架了，它默认的通信方式基本就是明文传输，你打开它的模板，里面全是$_GET、$_POST直接拿数据，哪儿有什么加密解密的影子？所以一旦要做PHPcms加密通信，就意味着你得自己动手,从底层开始改。
我一开始想得挺美：用AES加密不就完了？前端JS加密，后端PHP解密，对称加密，速度快，实现也简单，可实际问题来了——PHPCMS的前端用的是它自己那套模板引擎，你想塞个CryptoJS进去，还得考虑跟jQuery版本兼容不兼容，我当时用的jQuery是1.8，CryptoJS的某些版本直接报错,你说气不气人？
我试过的几种PHPcms加密通信方案
AES + Base64，最直接但也最容易被吐槽
这个方案说白了就是前端用AES加密一串JSON，然后Base64编码一下，通过AJAX发给后端，后端收到之后先Base64解码，再AES解密,拿到原始数据。
听起来挺顺的对吧？但我跟你说，这里有个大坑：密钥管理，你把密钥写在前端JS里，那不等于告诉全世界“我家钥匙藏在门口地毯下面”吗？稍微懂点技术的人打开F12就能看到，所以这个方案只适合内部系统,或者对安全要求没那么变态的场景。
不过话说回来，如果你的PHPcms加密通信只是为了防一下普通的抓包工具，那AES+Base64确实够用了，我当时就是这么干的,客户也没再说什么。
RSA非对称加密，安全但慢得让人想砸键盘
后来我觉得AES密钥暴露的问题太严重了，就想着换成RSA，前端用公钥加密，后端用私钥解密,这样密钥就不用暴露在前端了。
理想很丰满，现实很骨感，RSA加密有个长度限制，你一次只能加密一百多个字节，PHPCMS里随便一个表单提交，数据量都不止这么点吧？那就得分段加密，分段解密，我跟你讲，光是写这个分段逻辑，我就熬了两个晚上，而且RSA的计算速度……唉，用户点个提交按钮，转圈转了三四秒,你猜人家会不会以为网站挂了？
所以后来我学乖了，PHPcms加密通信最实用的方案其实是混合加密：用RSA传递一个临时的AES密钥，然后用AES加密实际数据，这样既安全又快，但说实话，对于大多数中小型项目,真没必要搞这么复杂。
几个让我差点崩溃的细节
第一个，PHPCMS的过滤机制，你在前端加密后的数据，传回后端的时候，PHPCMS会自动帮你做一些“安全过滤”，比如转义引号、过滤特殊字符，结果就是，你加密后的密文被它一过滤，解密出来全是乱码，我当时查了半天，最后发现得在接收数据之前先stripslashes一下，或者干脆用file_get_contents('php://input')拿原始数据。
第二个，编码问题，AES加密出来的结果是二进制的，你直接传给后端，PHPCMS可能给你当成UTF-8处理，然后就……呵呵了，所以一定要记得Base64或者Hex编码，我推荐Base64，虽然体积大一点,但兼容性好。
第三个，时间戳和随机数，做PHPcms加密通信的时候，一定要加时间戳和随机数，不然别人把你的密文截下来重新发一遍，你的系统就重复执行了，这个叫重放攻击，听起来很高大上，其实防起来很简单，就是在加密的数据里加个timestamp和nonce,后端校验一下时间差和随机数是否用过就行了。
到底值不值得折腾？
说实话，如果你是个人站长，用PHPCMS搭个小站，那PHPcms加密通信这事儿……我觉得真没必要，你又不是银行，又不是支付平台，折腾这玩意儿干啥？有那时间不如多写两篇原创文章,把SEO搞搞好。
但如果你是给企业做项目，客户明确要求数据加密传输，那你就得硬着头皮上，我的建议是：别自己造轮子，去GitHub上找个成熟的PHP加密库，比如phpseclib，或者直接用OpenSSL扩展，然后前端用crypto-js，这东西虽然老,但稳啊。
最后说一句，做PHPcms加密通信的时候，一定要前后端一起调试，你别前端加密完了，后端解密不出来，然后两边互相甩锅，我当初就是吃了这个亏，前端说“我加密没问题”，后端说“你传过来的就是乱码”，吵了半天发现是编码格式没统一，哎,说多了都是泪。
好了，今天就聊到这儿，如果你也在搞PHPcms加密通信，欢迎留言交流,咱们一起避坑！