2020 年雙節前夕，國內疫情穩定，長假將啟，各項安保措施比以往有所升級，而此時更是網絡安全重點保障時期，信息安全工作尤其不能懈怠。各用戶單位也陸續啟動響應，對網絡安全負責人、聯絡人通知到位，深度排查網絡安全風險，及時調整網絡安全策略，部署實施態勢感知、應急響應、持續安全評估、安全監測巡檢等安全措施，並確保安全人員現場保障。安保工作如火如荼，天存信息的技術工程人員也相繼奔赴各個信息重保工作現場。
一、安全措施與前期建設
1.1 個人心理建設
在三個重點客戶的工作現場輪流值守期間，我需要時刻緊盯日志審計平台，跟蹤滿屏的訪問日志，捕捉攻擊行為的蛛絲馬跡，深感責任重大。相信技術工程人員都會有類似感受：每每遇到這種境況，或多或少會事先祈禱一切順利，平安渡劫。
1.2 安全措施建設
重保安全的准備工作一點也含糊不得。“工欲善其事，必先利其器”，一個典型的機房安全建設設計是這個樣子的——
有這張嚴防死守的安全圖紙在手，再加上各安全廠商的 IT 精英們悉數到場鎮守，安全感油然而生。設想，在我方強大布防下，任他什么掃描、洪水攻擊、DDoS 攻擊、注入或是跨站，應該都擠不進這密不透風的防控體系。蝸居於安全中心的 WEB 應用服務器，應該能高枕無憂了。即便攻擊者挖到了應用或中間件的“0-Day”漏洞，或者事先植入了 WebShell，在主機安全加固環節，或攻擊者利用 WebShell 時，我方的 WAF 和入侵行為檢測也能排查出問題所在，並做出預警和攔截。
最擔心的事情
還是自然地發生了
二、安全事件始末
重保期間某日，我們接到了一則上級通知，還附帶有一份漏洞描述文件。
附帶的漏洞利用過程描述文件，如下。
我們立即着手排查原因，力求快速修補這個漏洞。
NO.1
首先排查日志。基於漏洞利用過程文件的描述，我們逐一檢查了 WAF 的攻擊日志，顯示無異常。
NO.2
查詢入侵行為檢測。它確實只是一條訪問日志，不是攻擊行為。
NO.3
登入服務器，跟蹤這個文件所有的訪問日志和訪問IP，寥寥數條，沒有所謂的上下文關聯，無法還原出一個完整的攻擊過程。
NO.4
最后，進入 WEB 應用的目錄，找到這個文件，粗略瀏覽代碼，發現這是一個任何人都有權限訪問的文件，沒有任何用戶和會話的檢查機制。這是一個典型的越權+任意文件上傳漏洞。
用戶單位要求緊急處置這一加急任務，對於 IT 安全運維部門，有以下幾種解決方式：
- 設置應用的訪問控制策略，只允許特定 IP 訪問這個上傳組件功能。而由於應用系統的業務面向 Internet 用戶，每天都會有業務數據通過 HTTP 協議上傳系統，限制特定 IP 並不可行。
- 臨時關閉上傳功能。基於上述實際情況，同樣無法實現。
- 限制上傳目錄的執行權限，可以禁止上傳文件的執行。然而這並非用戶可以接受的解決方案。
其實，最根本的解決辦法是協調開發部門，對這個上傳功能增加用戶限制和會話綁定。現實問題再一次橫亘在大家面前，一個5年前開發並交付的系統，找到當初的開發參與人員進行修復，當下更不具備可操作性。而 WAF 不能配置理解業務執行過程的的訪問規則，焦點便對准了我們負責 WEB 應用安全的幾家廠商。客戶要求第二天上午 8:00 前必須完美解決，時間緊迫。
在重保期間，紅頭文件和加急電話，成了壓在我們幾個相關人員頭頂上的大山。
幸好在運維期間，我把公司的 WEB 業務補丁平台，放置在了關鍵業務的前端。現在，余下要做的就是整理客戶需求，編寫用戶補丁了。
客戶的 WEB 應用環境和需求如下：
- WEB 服務器上有兩個應用目錄
/app_a/和/app_b/，分別對外負責不同業務。 - 其中
/app_a/不需要對外有上傳功能，上傳功能可以關閉，面向公網用戶開放。 /app_b/只允許內網訪問，公網用戶不能訪問，上傳功能不可關閉，內網用戶的 IP 是以 10 開頭的 IP。- 上傳功能需要驗證用戶和
session綁定，登錄后才能執行上傳操作。
三、安全事件處置
接下來是着手編寫虛擬補丁並上線補丁。虛擬補丁如下：
{
"rules": [
{
"meta": {
"phase": 1,
"function": "如果請求文件名以/szyx開頭，而且請求文件名中包含upload_json.jsp,則進行攔截，並記錄日志。"
},
"if": [
"begin(REQUEST_FILENAME, '/szyx')",
"contain(REQUEST_FILENAME, 'upload_json.jsp')"
],
"then": {
"action": "deny",
"log": "不允許在訪問/szyx相關應用的時候，訪問upload功能模塊."
}
},
{
"meta": {
"phase": 1,
"function": "如果客戶端為公網IP(不是10.開頭)，卻訪問非/szyx開頭的頁面，則進行攔截，並記錄日志."
},
"if": [
"!begin(REQUEST_FILENAME, '/szyx')",
"!begin(REMOTE_ADDR, '10.')"
],
"then": {
"action": "deny",
"log": "不允許公網IP的客戶端(此處為非10開頭的客戶端ip)訪問非/szyx相關的應用."
}
},
{
"meta": {
"phase": 4,
"comment": "如果登錄成功(登錄成功的標志是Set-Cookie中有jcxx_cookie_session_xtbz和flushcookie成員存在)，則記錄代表登錄成功的變量到SESSION中。"
},
"if": [
"REQUEST_FILENAME == '/sys/system/login/logincheck'",
"REQUEST_METHOD == 'POST'",
"notNull(RESPONSE_SET_COOKIES.jcxx_cookie_session_xtbz)",
"notNull(RESPONSE_SET_COOKIES.flushcookie)"
],
"then": "SESSION.login_success@300 = 1"
},
{
"meta": {
"phase": 1,
"function": "如果進來的請求URL中包含upload_json.jsp，則進行會話檢查."
},
"if": "contain(REQUEST_FILENAME, 'upload_json.jsp')",
"then": {
"if": "SESSION.login_success != 1",
"then": {
"action": "deny",
"log": "No Auth! You don't have access to the upload page!"
}
}
}
]
}
編寫好虛擬補丁，意味着 80% 的工作量已完成，心情可以舒緩一些了。
下一步，要驗證補丁的有效性。對此，我們分別模擬內網用戶和外網用戶對虛擬補丁做訪問和攻擊測試，日志截圖如下：
內網越權訪問（基於IP的訪問控制策略驗證）：直接訪問，直接攔截。(如圖)
內網越權訪問攔截日志：攔截日志報出，因為沒有用戶登錄和會話的綁定，這次越權請求被拒絕。
外網IP訪問限制：
處置結果：用戶單位的安全問題“越權+任意文件文件上傳漏洞”被上線的虛擬補丁完美解決，客戶表達了感謝，我們也又一次通過了安全考驗。（錢文芳 | 天存信息）