WEB安全新玩法 [1] 業務安全動態加固平台
近年來，信息安全體系建設趨於完善，以注入攻擊、跨站攻擊等為代表的傳統 Web 應用層攻擊很大程度上得到了緩解。但是，Web 應用的業務功能日益豐富、在線交易活動愈加頻繁，新的安全問題也隨之呈現：基於 Web 應用所承載的交易特性，某些利用其業務邏輯設計缺陷來構造的針對具體業務的攻擊逐漸成為主流，我們稱之為業務層攻擊。
業務層攻擊在技術上具有以下幾方面特點：
一、攻擊數據缺乏明顯特徵
與傳統的應用層攻擊不同，業務層攻擊的報文與正常業務的報文並無明顯差別。因此，基於特徵檢測的各種掃描工具和防護設備往往無法起到作用。
譬如「佔座刷單」這一攻擊——
在商品購買過程中，攻擊者利用自動化測試工具在未支付前佔用商品庫存，引發商品庫存被快速清空，導致商品無法正常銷售。諸如機票佔座、電影票佔座、電商購物中商品庫存清空等，都是此類攻擊的常見應用場景。以傳統的應用層安全來講，這種自動化的模擬完全遵循正常的業務邏輯，提交的業務數據也都是合規數據，因此並未呈現出任何安全問題。
二、與業務邏輯高度相關
業務層攻擊常常針對目標應用量身定製，攻擊者在發起攻擊前，都會對應用的業務進行深入的測試和分析，從中挖掘出有利用價值的漏洞。
比如 Web 應用中的一項常見功能，重置密碼。
每個用戶都預留了用於重置密碼的重要聯繫方式，如手機號碼或郵箱。攻擊者註冊一個用戶，並正常使用重置密碼功能，在自己的郵箱獲取重置密碼的憑據後進行密碼重置，在這一過程中，攻擊者通過截包觀察分析請求數據，篡改請求數據中的電子郵箱地址為其他賬號的郵箱地址，重放提交，就可以使用自己郵箱中已獲取的憑據成功重置其他賬號的密碼。
三、難以在開發環節避免
應用開發以滿足用戶需求為優先考量，設計者通常從功能實現而非攻擊者的視角去設計系統，同時也普遍缺乏應用安全的知識儲備和實踐能力。
舉例來說，在設計 Web 應用的用戶登錄功能時，從應用開發角度來看，在賬號或密碼輸入錯誤時，是否要求用戶在刷新驗證碼的同時重新輸入帳號信息，是不影響登錄功能的正常使用的。對攻擊者來講，這就是一個可利用的漏洞。只要不刷新 session，攻擊者就可以一直不換驗證碼去嘗試密碼，進而導致暴力破解等問題；也可以去嘗試用戶名，從而爆破用戶名列表，再利用社會工程庫的數據進行撞庫。
四、修補漏洞代價大
業務安全漏洞的修復，並非通過加入一兩段驗證代碼就能達到目的，往往需要修改業務處理流程，甚至很有可能在修補一個已知漏洞時，帶來更多新的漏洞。
例如，針對下單後篡改商品價格、優惠券重複利用、偽造成功結算請求等交易欺詐漏洞，常常需要開發者做如下修復：
- 生成數據簽名，對用戶金額和訂單簽名；
- 避免將敏感參數明文存放在 URL 中；
- 在服務端校驗/過濾客戶端提交的參數；
- 在服務端計算金額時，一定要判斷是否為正數；
- 支付過程中增加一個服務器生成的key，確認用戶校驗參數沒有被篡改；
- 用 URL 傳遞相關參數，後端進行簽名驗證；
- 對訂單金額和充值接口返回的數據進行校驗；
- 提交訂單時，後台判斷單價是否與數據庫中相符，如不符則返回錯誤；
- 支付時應從服務器拉取數據，而不是直接讀取客戶端的值。
可以看到，以上漏洞修復工作中，大部分都需要對業務處理流程進行調整，絕非在局部功能上小修小補所能解決。
五、業務層攻擊最能體現WEB攻擊特性
業務層攻擊是最能體現 Web 攻擊特性的攻擊方式，而 Web 攻擊最大的特點就是高度的對抗性，成功的 Web 攻擊永遠是見招拆招。
例如，自動註冊是攻擊者利用自動化測試工具實現批量註冊用戶的一種攻擊方法。
許多 Web 應用也意識到了這一安全風險，故而在其註冊功能上加入各種人機驗證要求，如短訊驗證、郵件驗證、各類驗證碼等，此外還可能對同 IP 註冊進行限制。而攻擊者也通過各種奇技淫巧來突破這些措施，如利用在線短訊平台來接收短訊驗證，自動切換代理服務器來突破同 IP 限制，或利用打碼平台來識別驗證碼等等。
那麼，防禦業務層攻擊有沒有某種一勞永逸的通用解決方案呢？
近年來出現了一些針對業務層攻擊的解決方案，例如通過使用前端 JS 技術來實現防調試、真實瀏覽器驗證、防（自動化訪問）模擬（真實訪問者操作）、隱藏參數、表單提交代替鏈接傳參等功能來增加業務層攻擊的實施難度。
儘管手段新奇，讓人有腦洞大開的感覺。但仔細分析這一類解決方案後，不難發現，它們遵循的依然是傳統的網絡安全防護思路：在攻擊者的攻擊路徑上層層設卡，使攻擊者實施攻擊的難度和代價增大，從而緩解或封堵威脅。採用這一類解決方案，儘管攻擊者更難挖掘出業務層漏洞，也更難發起業務層攻擊，但漏洞依然存在於 Web 應用上。
天存信息針對業務層攻擊提出一種新的解決思路，即：用戶能夠在不接觸和修改 Web 應用程序源代碼的情況下，通過快速編寫虛擬補丁代碼並實時上線生效的方式，即時建立一個安全策略實施層，修復已知業務漏洞。
實現這一思路需要解決幾個問題。
首先，由於 HTTP 協議本身是無狀態的，無論一系列請求是否來自同一個使用者，對服務器來說，都被視為一次次孤立的訪問。因此，要想從業務層面而非協議層面來分析和控制訪問，就需要還原出相互獨立的請求背後的使用者。
我們通過在iFlow2業務安全動態加固平台上引入主體的概念來解決這一問題，客戶端 IP、設備特徵、會話標識乃至它們的組合均可用來定義一個主體。通過對主體的跟蹤，我們就可以從一眾原本孤立的請求中，還原出背後的使用者。基於主體概念，業務安全動態加固平台可以統計訪問行為，做出持續的裁決。對於更複雜的跨 HTTP 事務判定邏輯，我們可以為每個主體創建稱之為「容器」的變量空間，允許規則針對主體進行記錄和計算信息，跟蹤並干預業務邏輯。從而實現基於業務邏輯而非攻防對抗層面的真正的業務漏洞的修復。
其次，儘管 Web 應用的業務交互是通過 HTTP 協議進行的，但是業務信息是隱沒在 HTTP 報文中的。例如，基礎的用戶身份鑒別和訪問控制功能在 HTTP 報文中就沒有直接的體現，更何況複雜的交易信息。如果要對這些信息進行甄別和判定，就需要從 HTTP 報文中將其提取出來，並按照業務邏輯進行梳理。
我們設計了一種專門用於實現 Web 應用安全加固的類編程語言。它介於配置和通用語言之間，具備編程的基本要素和針對 HTTP 協議的特有擴展，能為業務系統編寫涉及複雜動態判斷的邏輯。這種類編程語言具備描述業務的能力，因此，通過它能夠進行輕量級的編碼來還原業務。不僅如此，為了實現對業務的干預，除了可以斷開連接以外，結合計算能力，我們還可以通過類編程語言來實現對報文任意內容的修改, 實現對請求和響應的完全控制。
當然，考慮到安全產品的使用者通常為非程序員，更習慣面對配置文件而非一段代碼。因此，這種類編程語言雖包含語言要素，但仍以規則文件方式呈現，並採用可以體現層次結構並方便詞法校驗的 JSON 格式。
因此，在這種解決方案下，Web 安全產生了一種新玩法，即：安全測試人員在發現漏洞後，利用業務安全動態加固平台現場寫出修復代碼來供開發人員參考，並且在開發人員修復代碼之前，可以通過測試人員編寫的虛擬補丁來及時地和非侵入式地緩解或解決已發現的業務安全問題，實現對業務透明的漏洞修復。
