API崛起下的Bot管理

近幾年，應用安全領域的新技術、新廠商如雨後春筍般地湧現。該領域之所以會如此快速地發展，一方面，得益於nginx及OpenResty高擴充套件性的設計，使得技術團隊可以專注於特定安全問題，並且快速開展攻防能力的研發，不必投入驅動級HOOK、核心協議棧修改以及使用者態的HTTP協議解析代理等這些複雜而又晦澀的底層技術領域；另一方面，應用是承載著資訊互動的實際橋樑。隨著資訊化浪潮的來臨與科技的進步，雲、大、物、移作為基礎設施逐漸完善，企業必然有更多的業務透過應用（web、移動、人工智慧機器人）對外提供。諸多因素推動當前應用開發模式在邁向devops及API服務化。在新模式的原始階段，安全的訴求會接踵而至，鑑於綠盟科技在Bot管理領域的技術積累，本文希望與應用開發及應用安全領域的從業者進行交流。

我們先引用一些諮詢機構在應用安全領域報告中的摘要：

“到2023年，網路中Bot流量的比例將會超過‘人的請求流量’。

到2022年，API濫用將轉變為最常見的攻擊方式，從而導致資料資訊洩露，這將成為Web企業面臨的嚴重問題。

到2021年，將有90%的Web應用程式以API而非UI的形式面對網路攻擊，其佔比遠遠高於當前2019年的40%。”

可以看到，API將是未來企業核心對外的業務介面，這導致了Bot流量佔比繼續大幅度上升。它一方面增加了業務與業務之間正常的互動，另一方面卻催生了背後附加的黑灰產的蓬勃發展，貓池、接碼、打碼平臺等一條龍工具隨著API的啟用，更加便捷、靈活。

1)     Bot模擬正常人操作實現下面的請求更加難以識別：

a.      資訊洩露：內容爬蟲、價格爬蟲

b.      漏洞探測：自動化掃描

c.      賬戶安全：信用接管（暴力破解、撞庫）、惡意註冊

2)     業務安全防護的難度更高：

a.      交易欺詐：虛假交易、薅羊毛

b.      惡意競爭：庫存囤積、黃牛黨

3)     從面向HTML格式的URL攻擊，變身為針對XML/JSON的攻擊脆弱性更明顯：

a.      API濫用：簡訊轟炸、拖庫

b.      資訊洩露：資料遍歷、批次獲取

c.      身份越權

d.      惡意訪問

 

圖1  Bot演進路線

以前對抗這類黑灰產，Bot識別是核心工作。一般應有幾個層級的圖靈測試：

1)     簡單指令碼 -- 爬蟲、Python指令碼

一般爬蟲和簡易的Python指令碼工具等都不具備JS指令碼的執行能力，透過在流量中注入JS，驗證客戶端指令碼執行能力來進行識別。

2)     一般工具 -- PhantomJS 掃描器等工具

PhantomJS和主流掃描器（Appscan、AWVS、RSAS等）都整合了JS解析引擎，因此都能夠執行JS指令碼，我們需要透過隨機選取W3C規範中的瀏覽器屬性以及各個不同瀏覽器的特殊屬性進行組合來判斷客戶端是否為真實的瀏覽器。

3)     高階工具 -- seleium + Webdriver

Webdriver是目前使用最多的前端自動化測試工具，它能夠開啟一個真實的瀏覽器並透過指令碼來進行操作。在識別這種高階工具時，我們需要透過監聽操作事件來獲取操作特徵，比如：滑鼠移動軌跡、按鍵頻率等，判斷是否為真人操作。

4)     專業工具 -- seleium + Webdriver + 模擬操作特徵

在黑產專業工具中，攻擊者一般會透過程式碼來模擬真人操作觸發相應的事件，這種情況下，我們建議結合API，將收集到的操作特徵資料，基於API進行聚類，來判斷是否為真實的人工操作。

而在API環境下，上述透過下發JS來實現層層遞進的自動化工具檢測，有些場景卻無法完成校驗工作。經過研究呼叫，目前發現了一種技術手段可以對該類問題進行解決——將API呼叫順序，抽象為場景模型，結合業務的理解，標識意圖為Bot的流量：

1)     基於Bot行為特徵進行初步分類

利好Bot：搜尋引擎、合作伙伴、第三方服務

中立Bot：爬蟲、不明意圖機器人

惡意Bot：惡意評論、垃圾郵件、價格/庫存爬蟲、掃描器、惡意搶購

2)     將Bot行為及業務特徵進行聯合分析

記錄Bot行動軌跡，結合網站業務特徵來分析機器人的行為特徵。例如機器人訪問的都是商品頁面，還是頻繁地提交同一個/一組表單；或者是無意義的訪問了很多404頁面。

同時，視覺化呈現各類已識別意圖的訪問軌跡、行為和特徵屬性，幫助使用者結合業務挖掘哪些業務是Bot最主要的目標，能夠獲取怎樣潛在的利益。完成API環境下跟黑灰產的對抗及處置。

此外， WAF、API安全與Bot管理三位應用安全成員未來的關係，也是困擾諮詢機構和國內外WAF大廠的一個問題。兩家諮詢機構Forrester和Gartner持有的意見各有側重，而Akamai、Imperva、F5三家曾作為leader象限的廠商，應對方式也不盡相同。到底會融為一體、還是組合成WAAP解決方案、或是獨立存在，還需要隨著技術和環境的演進慢慢得到統一。筆者團隊也多次討論過這個問題，我們更傾向於形成WAAP平臺——支援WAF、Bot管理及API防護幾個元件在公共資源、受限資源和內部資源間進行選擇性部署，形成不同的防護等級，具備多種安全能力聯合組合解決方案，為應用提供分層遞進的安全體系架構。討論的觀點主要有：

1)     這兩種防護能力是無法進行替換的，Bot管理雖然可以透過頁面混淆使得掃描器無法掃描成功，但它僅僅是一個針對機器人的迷宮，如果後面的資料沒有一道實在的‘牆’在前面檢測攻擊，正常人無需任何額外技巧，可以直接繞開這種防護能力。

2)     規劃防護資源的視角不同，如前文所述，Bot管理是基於同一個域下不同業務型別進行管理的，如登入、活動、服務集等，而WAF則面向站點的開發語言和中介軟體。這會導致配置無法歸一。

3)     Bot防護的核心在於管理，根據Bot型別和活動情況，分別、分時調整，這是一款中度使用的產品，並應具備以下管理手段：

限流：最通用也是最溫和的一種方式。對於機器人操作者來說，只是網站的訪問速度變慢了；但對於企業來說，是在不打草驚蛇的基礎上，緩解了機器人造成的資源浪費、釋放了伺服器資源。限流措施適用於第三方服務機器人、不明意圖的機器人等型別。哪怕是掃描器型別的機器人，有些時候限流措施都比直接封堵要更加適合。

欺騙：對於抱著特定目的而來的機器人，欺騙措施非常適用。例如對於價格爬蟲，可以透過欺騙的方式，返回給爬蟲一個錯誤的價格，誘導競爭對手設定錯誤的價格。而此時競爭對手完全意料不到自己獲取到的是錯誤資訊。

引流：當機器人流量太大以至於確實影響到了正常的業務流量時，可以透過引流的方式，把機器人流量都分流到空閒伺服器或其他業務伺服器上，從而緩解業務高峰期的壓力，為優質使用者提供更好的使用者體驗。

提醒原站：此方式非常適用於業務邏輯複雜的場景，避免閘道器型別的裝置過多地介入業務邏輯帶來的配置難題。此時只需要告訴源站，哪些請求可能是機器人流量，由源站結合此資訊來判斷響應內容。例如優惠券搶購活動，透過提醒源站，源站可以給機器人流量返回高折扣的優惠券。這樣既不會減少活動熱度（點選率），又不會造成業務損失，為企業熱門活動節約了成本。

二次校驗：類似於驗證碼機制，在有風險的情況下，增加二次驗證，避免正常客戶業務無法進行，又增加了黑灰產進一步獲利的難度。

因此，在恰當的時機調整WAF、API安全及Bot管理產品的技術規劃路線，進行WAAP的預研及devops環境的對接，應當可以在應用開發快速發展的未來，持續提供足夠的安全保護能力。