應用安全越來越重要 —— 互聯(lián)網(wǎng)上看到的大多數(shù)安全事件基本都和應用安全，尤其是 WEB 應用安全有關(guān)(隨便翻翻 wooyun 之類的就知道了)。最近幾年的工作基本都和應用安全有關(guān)系，借著這個機會也總結(jié)一下自己的一些觀點。

WEB 應用安全的常見思路

這篇文章不包含 DDoS 和業(yè)務相關(guān)的問題 —— DDoS 主要是網(wǎng)絡層解決的問題，我沒有把放到 WEB 應用安全這個領域討論;業(yè)務相關(guān)的安全，特別是業(yè)務特性或者業(yè)務規(guī)則帶來的安全問題也不在這個討論范圍之內(nèi)。

下面只是大概的分類，并不嚴謹。

通過工具來增強 WEB 應用的安全

工具往往對應用開發(fā)過程影響非常小，只需要在部署的時候做些配置通常即可起到防護作用。工具主要以防火墻、WAF 和各類掃描產(chǎn)品為主。這些產(chǎn)品通?；谔卣?，很難做到深入理解被防護的 WEB 應用，這類產(chǎn)品通常會遇到很多挑戰(zhàn)。

由于被保護的 WEB 應用對這些傳統(tǒng)工具而言屬于“黑盒”，要做到有效防護的代價很高。個人認為目前傳統(tǒng)的產(chǎn)品更適合做大范圍、簡單、一致的控制，作為基礎設施提供無差別的防護;也比較適合做應急措施，用來縮短 Heartbleed、Struts2 遠程代碼執(zhí)行 這類漏洞的響應時間，為徹底修復贏得足夠的時間窗口。

誤報率和漏報率：這個大家都懂的，從防病毒軟件到 IDS、IPS 到掃描器到 WAF，只要是基于特征庫，基本都走在這個“平衡木”上，很難做到既誤報低又漏報少。

0day：WEB 應用的 0day 太容易發(fā)現(xiàn)，WEB 應用數(shù)量又是海量，真正充分考慮到安全的 WEB 應用更是鳳毛麟角。因此，無法做到發(fā)現(xiàn) 0day 甚至是快速響應 0day，會非常難受，而簡單基于規(guī)則很難做到發(fā)現(xiàn)“未知”。

普適和定制：應用的數(shù)量遠多于操作系統(tǒng)、數(shù)據(jù)庫這些通用組件，應用層的安全檢查或者防護工具無法做到覆蓋所有的應用(例如：wordpress 和企業(yè) ERP 就是完全不同的應用)。

難以根除的漏洞：只要不修改代碼、不打補丁，這個應用就始終存在安全漏洞。一旦出現(xiàn)盲點，導致攻擊者能夠直接訪問到被保護的 WEB 應用，安全防護措施都失去意義(現(xiàn)在的業(yè)務系統(tǒng)都是分布式系統(tǒng)，非常容易出現(xiàn)盲點;尤其是各種 CloudWAF，被繞過的可能性更大)。

通過開發(fā)流程控制增強 WEB 應用的安全

SDLC 是 Secure Software Development Life Cycle 的簡寫，有時候也被稱作 SDL 或 SSDLC 。SDLC 的特點是在軟件開發(fā)的生命周期中都“嵌入”了安全的“基因”，對軟件產(chǎn)品的安全性有本質(zhì)上的提高。業(yè)界最成功的案例就是 Microsoft 通過 10 多年持續(xù)的實施 SDL 讓其 Windows 產(chǎn)品的安全性有了極大地提高。

SDLC 需要安全完全嵌入到軟件開發(fā)的全部活動中，非常依賴于人員和工具(漏洞掃描、代碼審計、……)，也遇到了一些挑戰(zhàn)。

從某種意義上來說，SDLC 僅僅適用于部分公司，這類公司往往有穩(wěn)定的開發(fā)組織、流程;業(yè)務變化沒有那么快，相對比較穩(wěn)定;業(yè)務非常依賴于 IT 或者軟件開發(fā)。擴展閱讀：如何在你的組織內(nèi)采用 SDL。

時間：業(yè)務特性本身的發(fā)展非?？欤瑯I(yè)務特性的開發(fā)往往是整個開發(fā)團隊產(chǎn)出的核心度量指標(特別是互聯(lián)網(wǎng)公司)。新增的安全特性會延緩產(chǎn)品開發(fā)進度，因此開發(fā)團隊會傾向于事后修復;而持續(xù)的業(yè)務壓力又會讓歷史遺留問題修復很難獲得高優(yōu)先級。本質(zhì)上是個“技術(shù)債”的問題。

專業(yè)知識：開發(fā)團隊的核心能力并不是安全。即使是 SDLC 中的培訓，也是僅以解決常見、通用攻擊方式為目標，在面臨新型攻擊或復雜攻擊時，需要對安全領域有全面和深入的了解。很難有開發(fā)人員在跟上開發(fā)領域技術(shù)發(fā)展的同時，還能補上安全領域知識，并且跟上安全領域的發(fā)展。

資源：大型組織所開發(fā)使用的應用往往非常龐大，在開發(fā)流程中構(gòu)建完整的 SDLC 無論是在組織還是技術(shù)層面會讓大多數(shù)的組織難以承受。

誤報：SDLC 中使用了非常多的工具，這些工具通常都會產(chǎn)生誤報，這些誤報非常容易形成開發(fā)人員抵制 SDLC 的原因。

流程：SDLC 本質(zhì)上是讓開發(fā)人員重視安全，越多開發(fā)人員有安全意識公司開發(fā)出來的產(chǎn)品就越安全。但壞處是，大多數(shù)情況下很難有人能評估安全是否已經(jīng)足夠了(甚至做過頭了)。特別是在時間壓力很大且缺乏專業(yè)知識的情況下，SDLC 非常容易流于形式。

通過增強對應用感知和持續(xù)監(jiān)控增強 WEB 應用安全

核心思路就是在開發(fā)過程中引入安全相關(guān)的 SDK 或 Plugin。通過這些 Plugin 或 SDK 讓應用具備缺省的安全功能，且讓安全人員持續(xù)的對應用進行監(jiān)視、響應(可以更深入到應用的運行時)。

這個思路中關(guān)鍵的一項技術(shù)目前被 Gartner 定義為 RASP。RASP 是 Runtime Application Self-Protection 的縮寫，通過嵌入 Application 的代碼讓應用程序自身具備一定的威脅感知和防護能力。通常 RASP 天生就可以與其他安全產(chǎn)品集成。Gartner 總結(jié)了這個定義，并且在 Hype Cycle for Application Security, 2014 中給把他列入到了 On the Rise 階段(屬于被關(guān)注的新技術(shù)，但并沒有大范圍地被驗證和接受)。而 Gartner 早在 2012 年就在 Runtime Application Self-Protection: A Must-Have, Emerging Security Technology 介紹過，并預計 2017 年 25% 的應用會具備這個這個能力。目前已經(jīng)有多家廠商推出了產(chǎn)品，開源社區(qū)也有相應的實現(xiàn)。

HP: HP Application Defender

Prevoty: Prevoty Runtime Application Security

waratek: Application Security for Java

OWASP: AppSensor 是一個開源方案。

Shandowd: Shadowd 是一個開源方案。

#p#

RASP 相關(guān)技術(shù)

目前 RASP 還處于一個發(fā)展的階段，尚未像防火墻等常見的安全產(chǎn)品一樣有非常明確的功能邊界(scope)，我個人認為這樣的技術(shù)甚至非常有可能會和 WAF 形成一定的融合。因此這里介紹主要是記錄自己的理解為主，考慮到 AppSensor 和 Shadowd 的思路并不一樣，分開記錄。

AppSensor

目前 AppSensor 發(fā)展到了第二版，OWASP 這個項目目標一方面是給出完整的指南，另一方面也希望能提供一個完整的實現(xiàn)。目前 AppSensor 的 2.0 版以 Application-Specific Real Time Attack Detection & Response 核心。下面是 AppSensor 的一些核心文檔可以看看。

OWASP AppSensor Getting Started

OWASP AppSensor Guide v2.0.1 EN

OWASP AppSensor Reference Implementation

AppSensor DetectionPoints 梳理了 AppSensor 集成到應用后提供實現(xiàn)的監(jiān)測點，安全人員可以利用這些監(jiān)測點達到實時監(jiān)測攻擊行為。

AppSensor ResponseActions 梳理了 AppSensor 集成到應用后提供實現(xiàn)的監(jiān)測點，安全人員可以利用這些監(jiān)測點達到實時響應攻擊行為。

構(gòu)成部分

AppSensor 一開始遵從的設計理念就包括：語言無關(guān)、插件式、為“As A Service” 設計。因此，包括 Analysis Engine 在內(nèi)的各個部分都可以被替換。

AppSensor Core：必選組件。這個是 AppSensor 的核心，對外提供了 AppSensor 的各種接口。

Analysis Engine：必選組件。這是用來判斷是否為攻擊行為，如何對此行為進行響應的核心組件，目前還僅僅是個示例的實現(xiàn)。

Storage：用來存儲數(shù)據(jù)的組件。

Configuration：用來對客戶端和服務端配置的組件。

Access Controller：僅使用 SOAP、REST 的時候為必須。主要用于對接口進行訪問控制。

Reporting：可選組件。這是用于對 AppSensor 進行管理很重要的組件，如果需要利用其他的系統(tǒng)獲取 AppSensor 的數(shù)據(jù)，就需要使用 Reporting 組件。目前支持 Simple Logging、WebSockets、REST API 的方式對外提供數(shù)據(jù)輸出。

部署方式

目前支持四種部署方式：

REST Web Service

SOAP Web Service

Thrift

Local (Embedded Java)

Shadow Daemon

Shadow Daemon 還是個非常早期的項目，目前給自己的定位還是 WAF ，通過嵌入到 WEB 應用中的代碼來收集信息，通過這些信息來判斷某次訪問是否為惡意行為并作出判斷。

構(gòu)成部分

Shadow Daemon 目前由三部分構(gòu)成。

Shadow Daemon Connector：和語言有關(guān)，主要是利用語言特性嵌入到 WEB 應用中收集數(shù)據(jù)，放到 Shadowd 中進行處理。

shadowd：收集 Shadow Daemon Connector 的數(shù)據(jù)，根據(jù)配置和規(guī)則進行響應。

shadow_ui: Shadow Daemon 的用戶界面。