WEB 應用安全的總結

jopen 9年前發布 | 28K 次閱讀 安全 安全相關

WEB 應用安全的總結

應用安全越來越重要 —— 互聯網上看到的大多數安全事件1基本都和應用安全，尤其是 WEB 應用安全有關（隨便翻翻 wooyun 之類的就知道了）。最近幾年的工作基本都和應用安全有關系，借著這個機會也總結一下自己的一些觀點。

WEB 應用安全的常見思路

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

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

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

    工具往往對應用開發過程影響非常小，只需要在部署的時候做些配置通常即可起到防護作用。工具主要以防火墻、WAF 和各類掃描產品為主。這些產品通常基于特征，很難做到深入理解被防護的 WEB 應用，這類產品通常會遇到很多挑戰。

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

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

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

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

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

      </li>

    • 通過開發流程控制增強 WEB 應用的安全

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

      WEB 應用安全的總結

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

      • 時間：業務特性本身的發展非常快，業務特性的開發往往是整個開發團隊產出的核心度量指標（特別是互聯網公司）。新增的安全特性會延緩產品開發進度，因此開發團隊會傾向于事后修復；而持續的業務壓力又會讓歷史遺留問題修復很難獲得高優先級。本質上是個“技術債”的問題。

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

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

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

      • 流程：SDLC 本質上是讓開發人員重視安全，越多開發人員有安全意識公司開發出來的產品就越安全。但壞處是，大多數情況下很難有人能評估安全是否已經足夠了（甚至做過頭了）。特別是在時間壓力很大且缺乏專業知識的情況下，SDLC 非常容易流于形式。
        • </ul>

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

        </li>

      • 通過增強對應用感知和持續監控增強 WEB 應用安全

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

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

        • HP: HP Application Defender

        • Prevoty: Prevoty Runtime Application Security

        • waratek: Application Security for Java

        • OWASP: AppSensor 是一個開源方案。

        • Shandowd: Shadowd 是一個開源方案。
          • </ul> </li> </ol>

          RASP 相關技術

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

          AppSensor

          目前 AppSensor 發展到了第二版，OWASP 這個項目目標一方面是給出完整的指南，另一方面也希望能提供一個完整的實現。目前 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 集成到應用后提供實現的監測點，安全人員可以利用這些監測點達到實時監測攻擊行為。

          • AppSensor ResponseActions 梳理了 AppSensor 集成到應用后提供實現的監測點，安全人員可以利用這些監測點達到實時響應攻擊行為。
            • </ul>

            構成部分

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

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

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

            • Storage：用來存儲數據的組件。

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

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

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

              部署方式

              目前支持四種部署方式：

              • REST Web Service

              • SOAP Web Service

              • Thrift

              • Local (Embedded Java)
                • </ul>

                Shadow Daemon

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

                構成部分

                WEB 應用安全的總結

                Shadow Daemon 目前由三部分構成。

                • Shadow Daemon Connector：和語言有關，主要是利用語言特性嵌入到 WEB 應用中收集數據，放到 Shadowd 中進行處理。

                • shadowd：收集 Shadow Daemon Connector 的數據，根據配置和規則進行響應。

                • shadow_ui: Shadow Daemon 的用戶界面。
                  • </ul>

                  TAG: WAF, 應用安全, RSAP, 開源,

                  1. 國內外各類被公布的安全事件，包括數據泄漏、被入侵等。 ?

                  2. 各個公司開發水平比不上 Microsoft 這些大公司（直到現在 Microsoft 的“補丁日”只見到提前，沒見到過推遲的）；不像操作系統種類相對較少，WEB 應用數量非常龐大；WEB 應用漏洞挖掘也跟容易（看看 wooyun 就知道了）。 ?

                  3. 現在越來越多的傳統工具嘗試開始理解被保護 WEB 應用，并且開始不僅僅依賴于簡單特征做檢測和防護。目前為止，上面的挑戰還沒有被傳統工具很好的解決。 ?

                  4. Microsoft: Evolution of the Microsoft SDL ?

                  5. 2009 年國內關于 SDL 的討論: 《安全漏洞和SDL的討論，及EMET》；2014 年“知乎”上云舒的更新: 《如何評價安全開發生命周期sdl實施效果？》 ?

                  6. 2001 年 Code Red、Nimda 蠕蟲爆發后，Bill Gates 發出了面向全員的郵件，提出了微軟的產品從設計上就應該是安全的（by design），并在 2002 年成立了 TwC 部門，2014 年 TwC 不再單獨存在。http://en.wikipedia.org/wiki/Trustworthy_computing ?

                  7. Gartner: Gartner 給出的 RASP 定義 ?
                    8. </ol> </div> 來自：http://sbilly.com/2015/04/15/web-application-security-2016/

                   本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
                   轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
                   本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

相關經驗

相關資訊

相關文檔