騰訊李旬保：WASL-Web應用安全的思考

來自騰訊的李旬保，在現場發表演講。以下為文字實錄：

主持人：大家都知道Web安全逐漸也被廣泛應用了，針對應用層面的黑客攻擊也是越來越多了，有沒有辦法防範外面更加專業、更加體系的攻擊呢。下面有請騰訊李旬保給大家帶來的WASL-WEB應用安全的思考。

李旬保：大家好，很高興能代表騰訊參加這次峰會。首先自我介紹一下，我叫李旬保，06年6月從武漢點選檢視武漢及更多城市天氣預報大學資訊安全系畢業。畢業後一直在騰訊公司安全中心從事Web應用安全的工作。這次我演講的主題是WASL-WEB應用安全的思考。在純技術更高層面做一點思考，怎麼樣更好地開展Web安全工作。

這是這次演講的主要内容（圖），首先從現狀出發，講一下現在開發模式的缺陷、WASL體系介紹、應用WASL困難與挑戰、最後對Web安全做一下總結與展望。

首先從業務體系開始說起，自從98年騰訊公司成立以來，我們從隻有單一的IM業務開始經過9年多的發展，現在已經發展到包括網際網路增值業務、無線、互動娛樂、電子商務、廣告、網絡媒體幾大平台組成的比較大的網際網路企業。我們的注冊使用者現在已經有5億多，活躍使用者有2億多。其中包月付費使用者有2000多萬。網際網路的繁榮也促進了Web應用發展，其中我們有很多業務，除了IM這種是在用戶端的，大部分業務都是通過Web來進行的。圍繞我們IM平台展開，構成一個比較有機的業務體系。這些應用的迅猛發展給網民帶來了很多很好的體驗，給公司帶來很多利潤的同時，我們也發現了很多問題，比如說刷Q币、刷會員、刷天數。去年我們公司就聯合公安網監聯合打掉了數個盜号、盜Q币的團夥，這個給我們一個信号，除了業務不斷創造價值的同時，也有一些反面力量企圖從我們這裡非法擷取利益。我們這個業務體系就像一個網絡帝國，它越擴張，它的邊界就越大。就意味着我們面臨更多的威脅。每一個web門戶就相當于進入這個帝國一個城門，一旦一個地方出現了薄弱環節，他就可以通過Web界面長驅直入，到達我們帝國裡面。

在現在這種情況下，Web應用安全形勢比較嚴峻的情況下，我們怎麼樣保衛我們領土呢？首先從 Web安全現狀講起。現在很多人都知道“google hacking”，在我寫這個PPT的時候，我想到一個最簡單的例子，就是查找有哪些站點配置了目錄浏覽。伺服器目錄浏覽是一個不安全的配置，我搜尋到這個，可以看到還是有不少網站是可以看到目錄下的檔案，當然這裡面隻是一個純粹的網頁，好像沒有什麼發現。但是看另外一個公司，這裡面就有一些有趣的東西，打開其中一個文本檔案，看起來好像是一些聊天的曆史記錄。但是這個東西對某些人還是沒有很大興趣。我們看第三個網站，這次我們很有收獲，可以看到腳本裡寫有備份資料的腳本，包括mysql使用者名、密碼、DB。這裡面沒有用到特殊技巧，隻是用到浏覽器就可以看到有這麼多東西。而且我們也知道，過去也有報道過這樣的問題，把敏感log放在Web目錄上，又開放了浏覽目錄權限，使得黑客直接通路這個目錄就把這些敏感的log打開就擷取到了明文的使用者名、密碼。這還是最簡單的不安全配置。可以看到這種配置到現在還是很普遍的。如果這種這麼簡單的安全配置還是這麼普遍，可以想象其他更複雜的問題應該是更普遍的存在，也就知道我們現在Web應用的安全是處于怎樣的境地。

為什麼會出現這種情況呢？這跟我們現在Web業務開發和我們怎麼做應用安全的方法有關系。現在是怎麼樣開發的呢？在國内很多網際網路企業都有這樣一個特點，就是說業務第一，等有了一大部分使用者再完善，而安全呢隻是一個錦上添花、可有可無的屬性。如果沒有時間的話，就忽略掉。如果有興趣的話，就搞一搞。這在觀念、政策上就把安全放在很低的位置。其次很多網際網路企業覺得安全就是防火牆，做一下滲透測試。局限于安全技術，但是安全也不僅僅是技術。我們組織上可能有一個安全部門，會響應這些安全事件。外面報告一個漏洞，然後急急忙忙趕回來把它處理掉，這并不是一種有效的安全體制。沒有辦法從根本上杜絕安全問題以後不再出現，代碼品質很難保證。如果不能解決這個問題，安全缺陷數量無法收攏。業務長期高風險運作。有很多業務員會有這樣的一個錯覺，認為我這個程式已經跑了2、3年，從來沒都有出現問題，是以我不用關心它。從來沒有出現問題，并不代表問題不存在。總有一天有一個人發現了這個問題，就會造成入侵事故。最主要就是說我們目前這種模式還不能保證Web應用的安全。我們有安全部門，但是在實際中更像一個救火隊。哪裡出現火情，就急急忙忙趕過去。很多安全界的朋友都經曆過半夜被電話叫醒，趕到公司處理安全事件的情況。另外，還有一種情況，網際網路應用的開發周期都很短，主要是為了更快把業務推出去。通常采用的開發模式就是一種靈活開發模式，開發周期通常限制在一個月，長一點也就是2個月到6個月。這麼短的時間對安全投入也是大大的限制。不可能像其他做大型軟體的廠商可以把幾年時間投入到裡面去。這樣子，開發出來的代碼安全隐患是很多的。從裡面發生安全事故的幾率也很大。一旦釋出出去，發生事故後補救的成本也就非常高。并且我們很難從這些事故中吸取教訓。

怎麼解決這個問題呢？怎麼樣從根本上解決Web應用安全問題。我們就提出了WASL，Web應用安全生命周期體系。簡單來說，Web安全是安全教育、安全技術、安全制度的綜合，是一個持續演進的過程，不僅僅局限于技術。這是一個通常情況下我們采用的Web應用開發生命周期圖，從業務開始模組化然後到它的計劃最後到需求，然後到分析設計、然後到編碼實作、測試，最後釋出版本、部署、上線。這裡面就得到一個初始的版本，這個過程又重新整理新的需求，根據使用者回報，新的需求又被更新、設計，加到新的開發計劃裡去。這是一個疊代的過程。通常一般疊代過程會在2個星期到6個月時間是比較短的周期，每個周期都很緊湊。這是一個分布。從這一個分布得到一種政策，如果我們能夠有一種方法，把最多的這種問題解決，我們就收攏了絕大部分的漏洞。然後再對其他的類型，比如說比較難的一些類型，我們通過一些措施能夠預防或者降低風險的話，也就解決了剩下部分80%的問題。最後面的，如果很難解決的那些我們就通過其他措施，比如應急響應這些就把所有風險降到最低。我們應該在Web 應用開發周期裡用什麼樣的政策呢？這還是剛才Web應用的開發周期，通過漏洞的簡單分析。對于跨站、跳轉、注入漏洞這些，大多數都是非常簡單的不安全編碼疏忽所導緻的，可以在編碼這個階段通過使用一些安全編碼實踐來避免掉。我們對這兩種檢測也有比較成熟的檢測方法可以檢測出來，在這個階段就把它解決掉。而對于不安全配置這種更多的屬于伺服器配置的問題。這是營運環境了，我們可以在營運這個階段，通過靜态檢查以及通過監測方式，把這些問題在這個階段發現出來。對于第三方合作，可以通過清理的方式，不使用不安全的連結或者使用監視，過一段時間就檢查這個連結是否還是安全的，有沒有被更改。通過一種報警的方式來解決。然後剩下的是一種邏輯的漏洞，這種是比較難解決。我們可以通過為這些業務在需求階段提供一些安全的屬性、安全的需求，然後在設計和實踐的時候把安全需求實作，把常見的這些邏輯問題，比如登陸的身份驗證問題解決掉，對于更進階别的邏輯問題，把它的風險降到最低。WASL技術也就是基于這樣的分析。

怎麼樣應用WASL或者說WASL包括哪些内容？大家可以看到右邊這個圖（圖），這裡包括幾個部分，最高一級就是制度和規範。然後下來是Web應用開發的生命周期，在每一個步驟都會實施這個安全教育，并且使用了相關的安全技術，來保證常見的 Web缺陷能夠在成本最低的階段把它解決掉。剩下的就是漏網之魚，通過安全相應流程把它處理。這裡面第一步是需要定義角色、職責。角色和職責的作用就是說明确你這個組織裡面誰應該做什麼事情，他對這個事情應該負到什麼責任。如果他違反了這個職責，應該受到什麼樣的處理。一個典型的結構包括管理決策層負責安全制度的決策，然後簽署相關的政策檔案。專業的安全部門是負責安全技術的開發、研發，然後還有架構的安全稽核、安全流程開發、漏洞的響應，這是一個專業的團隊。而對于業務部門也同樣需要有相應的安全人員。通過設立一個安全專員，他就是負責整個項目、整個流程裡面所有的這些安全需求、安全規範，這些措施都能很好實施，并且作為一種溝通和協調的角色。安全接口人是作為業務部門和安全部門起到一個溝通作用。通過這樣一個結構，每個人擔當什麼角色都明确定義出來，這樣每個人就能知道具體做哪些事情。角色和職責确定之後，下面也就是安全意識的培養。如果沒有安全意識的話，這裡面的安全也就是很難保證的。

一個很小的例子，上班路上看到有橫幅提醒說請不要使用煙道式直排是的熱水器，可能會有安全隐患，這也是安全意識教育的一種形式。這種就是提示你自己會不會也有這個問題呢？我看到整個橫幅的時候，就會想家裡的熱水器是不是直排式或者煙道式，腦子裡就有了這樣的一種生命安全的意識。還有通過曆史案例教育，我們曆史上出現的嚴重問題，它是怎麼樣發展的、造成怎樣的嚴重後果、為什麼會發生，我們會不會在同樣地方犯了類似的錯誤呢，通過曆史案例學習可以得到教訓。然後針對這個開發生命周期裡每個階段都會會一些針對性課程，比如安全需求怎麼提出、安全編碼是怎樣的、怎樣設計安全架構、安全測試是怎麼樣進行的，一些針對性的課程加深業務人員對安全的了解。安全程式設計實踐主要是通過開發人員，因為所有的實作最終還是通過編碼實作，如果程式設計人員安全編成意識和技術都不夠熟練的話，就很難保證安全措施的實作。然後還可以提供滲透實踐與演習，我們可以搭建有各種各樣問題的一個實踐演習系統，通過組織，業務人員來參加這個實踐的演習，讓他們能夠從黑客這種角度怎麼樣通過這些漏洞入侵到系統裡，加深他們對Web安全的了解。而這個教育過程要持續進行。并且這個教育還必須有一個體系來確定達到相應效果。我們可以通過考核或者一些激勵措施，相當于安全知識的認證。比如你每年都要通過一個考試，能夠達到這樣一個水準，然後才能繼續開發。

一旦進入開發周期了，最開始在需求這個階段就必須得把安全需求提出來。這裡面安全需求的提出可能由業務這邊來提出，這就需要業務人員、需求人員也有一些安全的意識。就是說我這個業務哪一些東西需要保護、哪一些是最有價值的。如果我這個業務有人非正常使用的話，比如誤用、濫用或者一些異常使用的話，他應該是怎樣的應對。在開發過程中，還可能有需求變更的情況。如果需求變更了，對現有系統有哪些影響。這些都需要在需求這個階段确定，并且要保證安全需求能夠持續得到跟蹤，主要通過安全專員來確定。

到了設計這個階段，通常就是包括了架構設計和子產品的設計，這裡面對于設計的話，也有很多的很好的實踐。但是在架構這一層顯得有一點點虛，比如說保持簡單，大家都知道越複雜的東西就越難實作、也越難測試、也越難保證它是正常工作。但是通常很多業務都複雜，在複雜性和安全性、簡單性得到一個平衡。defense in depth，每個步驟都要進行适當防護，隻有加強了最弱的連結，整個流程才是安全的。在操作某個資源的時候，你需要給他最小的權限，隻需要讀的話，就不要給他寫的權限。還有信任原則，既使是内部系統，也要堅持最小的信任原則。可能你信任它，但是它這個可能是一個不安全的來源，輸入到你這個系統之後，就變成一個危害。Graceful Failure，就是一旦失敗的時候，要恰當處理失敗的情況。比如有一些業務支付失敗，支付到一半的時候應該怎麼處理呢？是重新執行一次還是完全拒絕這次服務，讓使用者重新開始，這裡面都是要考慮的，否則的話有可能在這個過程中出現問題。

怎麼樣設計一個安全架構呢？它的政策有哪些可以參考？這裡面提到最開始你要确定這個系統裡面有哪些資源。有哪一些角色，然後這些流程通過的邊界有哪一些。明确資源、角色、邊界，之後你就可以對不同的資源提出不同的安全需求，也就是從需求這個裡面來，然後為他提供不同程度的保護措施。當這些都确定後，可以設計一個最簡的方案，包括安全的措施。并且在這個過程中設計一個驗證的方案。也就是我怎樣驗證，這些安全措施都得到了恰當的實施。在這個階段可能還需要做一個風險分析，就是這個應用一旦部署之後他會面臨哪些安全威脅。這個主要通過幾個步驟來，首先是需要分析營運環境中有哪些安全因素，是網絡這一層還是應用這一層，還是合作方這一層。确定最有可能的威脅，哪一些威脅是最嚴重的，最有可能發生的。一旦發生之後它的影響會有多大，它發生的頻率有多高。一旦這些清楚之後，我們就可以制定降低威脅和風險的措施。當這個架構設計好之後，通常應該還是經過一個驗證、評審階段，對于每一天開發的，不需要這麼頻繁的安全評審。但是最初建立的時候，這個時候需要安全評審。還有在架構進行重大調整的時候，也需要評審，這個重構會不會對現有架構産生新的威脅。

這是一個簡單的模型。上面一層是Web浏覽器，下面是Web應用，左邊一個站點A、右邊一個站點B，左邊這個站點A是一個典型的二層架構，右邊這是一個典型的三層架構，對于這樣一個架構怎麼樣分析它的威脅，哪個架構更安全呢？為什麼說三層架構要比兩層架構安全一些呢？我們可以通過分析它的威脅來得出它的一些結論。在哪一些地方可能出現問題，對于兩層這種應用來說，首先資料傳輸要經過信道，這裡無論兩層還是三層，他都會要經過這個信道，然後進行一個從浏覽器到伺服器端的交流，而這個通信信道有可能受到的威脅是是被監聽，可能會導緻敏感資訊洩露。而這個威脅對你應用威脅有多大呢？一般應用是無關緊要，可能就是一個通告。但是對某些應用要登陸密碼或者線上支付應用，必須保證整個通信過程都是安全的。這裡面是一個威脅點，面臨的威脅就是被。在CGI這一層，從外部處理資料，沒有驗證參數，對用戶端軟體可能會溢出。這種威脅情況主要是在于可能會造成拒絕服務的攻擊，再到資料這一層，可能會受到系統注入的攻擊。在登陸這個步驟裡，很有可能CGI沒有進行身份驗證然後就允許你通路一些敏感資源或者是你的身份級别不夠，某些資源是需要、某些級别需要會員級别才能通路，但是我沒有判斷完全就允許你通路這些資源，那也是一個邏輯的問題。這可能會在邏輯子產品出現。

三層架構多了一個APP，APP把DB請求轉換。這裡面主要威脅是在于因為多了一層從CGI 到APP就多了一個邊界，這個就存在一個信任的關系。認為内部可以任意通路，這種情況很常見，就是說A部門系統有一個資源類似于IM，B部門有一個業務需要通路IM資源來提供相應服務，IM部門提供一個接口給提供Web服務的部門，但是要充分信任Web應用這個部門，這樣就使得Web部門也沒有考慮到這種情況，一旦發生不驗證你這個身份然後就操控了其他使用者的資料，這種情況也是會有發生的。但是如果我在這個階段就限制了，把信任關系降到最低，不信任CGI 這邊，要驗證你的資料，這種情況就不會發生。多了一個邏輯層之後更有可能發生邏輯漏洞問題。因為Web應用是無狀态的，他如果要維持一個狀态的話需要一些比較複雜的邏輯。這個過程很容易出現的。Web應用最關鍵的還是業務，業務邏輯一旦出現問題，有可能會造成很大的一個損失。這是在伺服器端。

在用戶端又有哪些威脅呢？表現層常見的就是釣魚，也就是一些虛假資訊。這個也屬于Web安全範疇。這個跟漏洞有比較小的關系，但是也是嚴重的問題。因為很多使用者經常會受騙，這個資訊從我們站點裡面出來。然後在用戶端這個邏輯有可能會受到身份被。也就是說用你的身份來進行一些操作，比如說我用你的身份幫你買一個東西或者給誰發一個消息，幫你投一個票，但是你完全不知道，這種漏洞主要是利用跨站腳本、CSRF攻擊。還有惡意代碼，惡意代碼怎麼會從我們這裡出現呢？主要是有一些應用我需要允許使用者輸入HTML，比如電子郵件、 BBS，有可能你的應用某一個地方出現跨站問題，他就把惡意代碼就放在這個地方來，一旦使用者通路的時候，就會使使用者遭到一個攻擊。在架構上要考慮怎麼樣消除這些威脅。三層架構為什麼比兩層架構安全些呢？因為三層架構可以在APP這一層做一個集中控制，而且有一個稽核機制，就比一個這麼多的入口安全很多。主要是看應用的需要。兩層架構最主要是要守住門戶，也就是編碼層次，要安全的編碼。這樣就不會觸及到DB這一層。

之後就是實作，也就是編碼。始終要貫徹安全的思想，比如占絕大部分不安全的編碼主要是 code注入這些，還有跨站腳本出現，跳轉、讀取檔案這些，這主要都是參數驗證，這個都可以通過安全編碼指引。使用安全元件的話，可以把一些常見的工作用元件實作，減輕編碼人員重複編碼的工作。對于這些安全的需求、實作，要提供一個測試标準。就是怎麼樣測試代碼。在這個階段可以提供一些工具的支援，比如靜态代碼分析，可以分析一些code注入、跨站腳本，同時可以提供一些脆弱性測試工具。在這個階段還要進行code review，重審代碼，把殘留的不安全代碼清理掉。

測試，測試這個階段需要為安全需求建立測試政策和用例。主要要測試安全特性，通常我們會有一些比較有規律的一些測試案例，通過總結曆史案例用自動化測試工具，還有通過人工測試某些關鍵地方，然後把這些問題找出來。在這個階段進行單元測試的話，是比較好進行的。因為可以有自動化工具進行，但是系統測試的話就稍微困難一些。因為系統測試需要整個業務結合在一起，而且還有可能很多地方是不到的。系統測試可以發現結合在一起出現的問題。自動化測試主要是不安全代碼的測試。測試之後就是釋出和營運階段，這個部署之前通常要確定營運主機環境安全，主要是一些配置。還有通過這些相應的掃描工具來進行複查，在管理中主要的情況就是比如說某些需要建立DB連接配接，需要用低權限使用者，還有管理背景權限。曾經發現有些問題是把管理背景開到外網去，而且這個使用者的控制存在弱密碼的情況，這種情況也需要考慮。通過線上監控和掃描可以發現這些普遍性的問題，存在的漏洞都可以發現。對于一些入侵的話，也可以進行某些告警。檔案被篡改的話是可以被發現的。對業務異常資訊監測與分析。

疊代，在某些開發中，疊代是非常頻繁的。這裡面主要要注意需求變更的時候，安全需求也能夠得到相應的關注，保證這些需求滿足新的需要，通過持續的重構，可以把舊有的不安全的代碼清理出去。在這個階段還會有持續內建、灰階部署政策。持續內建是在每一個小的階段測試每一個小的單元，把安全問題解決掉，避免它內建到大的系統中後很難修改。灰階部署的時候要確定不同版本的邊界，沒有出現版本交叉帶來的安全問題。

通過前面幾個安全開發周期的相關政策，基本可以消滅大部分的安全隐患。但是還是可能會存在漏網之魚，那就是要通過安全響應來進行善後處理。主要是經常監視這些漏洞的來源，是來自外部報告還是内部滲透測試。還是被一些地下組織利用。不同來源有不同的響應政策。漏洞發現之後要分析與定位，到底涉及哪些系統，發現的問題是在哪個地方，然後制定修複計劃。并且進行回歸的測試。確定沒有問題之後再重新釋出上線。如果一旦這一個漏洞已經被外部公布的話，還要采取措施應對公關危機。最後我們要從這些事件中吸取教訓，避免以後重犯同樣的問題。

安全技術，包括代碼審計工具，對一些常用的過濾庫可以通過提供安全元件與API庫形式。對測試也可以有CGI測試工具、漏洞掃描平台，其它的安全技術包括敏感操作行為分析、第三方内容監控、配置核查等。

這是一個圖（圖），從最底層網絡層端口掃描到主機層的漏洞掃描系統，確定這個主機沒有開放不允許的服務。CGI掃描系統保證應用程式沒有問題。對于第三方的可以通過一些監控，檢測檔案是否被篡改。在内部的可以實作一些防篡改的措施，比如監控主機檔案有沒有被改變。通過這樣一整套系統基本上可以使我們安全水準達到比較高的層次。對于安全API這些還可以進行Log，給我們提供攻擊資料分析來源。比如現在的攻擊趨勢是怎麼樣的。所有這些系統都接入ITIL系統裡，一旦發現問題可以及時通知到負責人進行快速響應。下面這個是在開發流程裡應用到的技術，主要是編碼階段的安全API，開發階段有靜态代碼分析以及開發和測試時都應用到的安全測試工具。

安全的制度，這需要高層的了解與支援，對安全做一個承諾，沒有制度的支援，多好的體系都是空談。規範與标準的作用，相當于一種指引，而流程則提供了規範實作的途徑。最後有了制度之後，還要切實地執行。這是WASL體系總結（圖），最高層是安全制度，然後通過規範、流程、标準指導，最下面就是教育、技術、實踐、執行。這個體系裡面包括人的因素、技術因素、過程因素，組成一個有機的體系結構。

困難與挑戰，主要還是制度的建立。需要在不同的業務模式中進行成本與收益的平衡。體系的建立，需要所有人員的理念與習慣做出一定的改變。在隊伍建設方面，需要普及安全知識與意識，并培養一定的安全專家。技術上的難關，可以通過衆多的企業進行開放與聯合，共享相關的安全成果。因為安全技術畢竟是一種知識性、基礎性的東西，大家可以共同合作的方式，把安全推進，進而使各自的業務能夠集中精力，提高整體的效率。

WASL展望：安全技術不斷進步，黑客也不斷進步，可以預料是一個長期的攻與防的過程。我們需要探索出更規範更有效的體系來指導實踐。在軟體安全體系方面，業界已經有一些比較好的體系，可以适當的進行融合。最後，希望業界中能夠有更多的交流互通，集合衆人的力量來共同做好安全工作。

以下為現場問答：

問：我有一個問題，你這個體系做下來已經基本上杜絕了sql注入。但是有一個問題，業務邏輯上面怎麼檢查？

李旬保：目前這方面還是比較少經驗，可能需要更多從一開始需求的時候提出一些安全需求。比如一個Web IM我在登陸的時候，因為它登陸模式不一樣，我登陸的時候能登陸到我自己這個，我給别人發消息的時候，不能匿名給其他人。

問：我是這個意思，能不能有效檢查這些？我們現在發現一個可以修補。怎麼去檢查這些問題？

李旬保：目前還沒有太多有效的經驗。

主持人：對于CGI這種邏輯問題可以從幾個層面解決，第一，從初始的設計方面。比如充點卡，你在CGI開啟的時候就是寫死，把消息分得很清楚。可以有利于避免邏輯。這隻是一個層面。第二，DB。剛才他提到的也是目前比較有效的方法。根本解決方法無論什麼安全目前都無法解決。微軟目前有一個思想，一旦發生安全事件，我們能從中學到什麼，怎麼規避類似問題。要借鑒這種思路，一旦發生邏輯問題，我們把邏輯最根源問題分析出來，然後會在這上面做很多模型、設計上提一些要求，通過這種方法來做。我認為第三點很重要，本身在企業内部要有一個資料庫，然後去研究它的根源是什麼，這樣才是最高效率的。

李旬保：比如我充值的時候，會充一個負的數或者很大的數，或者要充值送出這個請求的時候把帳号改掉。

問：我的意思是這樣，兩個業務，可能A部門設計這個點卡充值30元，B部門推出一個15元的，導緻這個業務就變成可能雙方都不知道的情況，産生業務邏輯的錯誤，而不是程式上的。程式上的我們都能規避，但是在業務上，特别是檢查發現存在很大問題。我覺得代碼注入都可以有一種方式去檢查，這種邏輯上有沒有一個好的手段？

主持人：這個問題跟我們提供的一個方案比較類似，方法三，模型。再一個我提到的設計這塊，統一調一個bos接口就可以解決。今天我們的會議十個精彩議題都已經演講完畢了，首先感謝李旬保。相信大家從中獲得了不少有用的資訊。感謝專家們的演講，同時也感謝各位積極的交流與提問，下面有請安全中心經理為我們會議總結發言。

安全中心經理：首先非常感謝各位專家的精彩演講。專家用非常豐富的經驗對安全趨勢研判給我們非常大的啟示，在座也大受菲益。各位會問我們為什麼辦這樣一個峰會，前一段時間發生了一個攻擊事件，包括google、新浪、百度，他用大量殭屍電腦攻擊網站授權伺服器，然後在一個假的網站上放了很多漏洞，比如迅雷、暴風影音，上面挂了很多木馬，這個木馬就是偷中國26種遊戲密碼。從這個案例我們就可以看出黑客行為無時無刻不在進行中，我們網際網路企業經常也都是孤軍奮戰，我們辦這次會議不僅是提供一個交流平台，更希望建立一個聯系管道，在比較

原文位址：http://tech.qq.com/a/20080320/000266.htm