1.2 Web應用程序中存在的風險及預防

由于網絡技術日趨成熟，黑客們也將注意力從以往對網絡服務器的攻擊逐步轉移到了對Web應用的攻擊上。根據Gartner的最新調查，信息安全攻擊有75%都是發生在Web應用而非網絡層面上。同時，數據也顯示，2/3的Web站點都相當脆弱，易受攻擊。然而現實是，絕大多數企業將大量的投資花費在網絡和服務器的安全上，沒有從真正意義上保證Web應用本身的安全，給黑客以可乘之機。

Web應用程序安全無疑是當務之急，也是值得關注的話題。對相關各方而言，這一問題都至關重要。這里的相關各方包括互聯網業務收入日益增長的公司、向Web應用程序托付敏感信息的用戶，以及通過竊取支付信息或入侵銀行賬戶偷竊巨額資金的犯罪分子。可靠的信譽也非常重要，沒人愿意與不安全的Web站點進行交易，也沒有組織愿意披露有關其安全方面的漏洞或違規行為的詳細情況。因此，獲取當前Web應用程序安全狀況的可靠信息不可小視。

1.2.1 Web應用程序的安全套接層（SSL）應用

與任何新興技術一樣，Web應用程序也會帶來一系列新的安全方面的漏洞。這些常見的缺陷也在“與時俱進”，一些開發人員在開發現有應用程序時未曾考慮到的攻擊方式都相繼出現了。由于安全意識的加強，一些問題已經得到解決。新技術的開發也會引入新的漏洞。Web瀏覽器軟件的改進基本上消除了某些缺陷。

對Web應用程序而言，安全確實是個“問題”。查詢一個典型的應用程序的幫助頁面，其中的內容會向你保證該應用程序確實是安全的。大多數Web應用程序都聲稱其安全可靠，因為它們使用SSL（Secure Socket Layer, SSL安全套接層）。

它使用128位安全套接層技術設計，是為網絡通信提供安全及數據完整性的一種安全協議。SSL在傳輸層對網絡連接進行加密，可防止未授權用戶查看您的任何信息。它提供以下服務。

（1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器。

（2）加密數據以防止數據中途被竊取。

（3）維護數據的完整性，確保數據在傳輸過程中不被改變。

您可以放心使用本站點，我們絕對保障您的數據安全。Web應用程序常常要求用戶核實站點證書，并想方設法讓用戶相信其所采用的先進加密協議無懈可擊，從而說服用戶放心地向其提供個人信息。

TCP/IP協議棧中的安全機制如圖1-2所示。

此外，各種組織還聲稱他們遵循支付卡行業（PCI）標準，以消除用戶對安全問題的擔憂。

我們極其注重安全，每天掃描Web站點，以確保始終遵循PCI標準，并免受黑客攻擊。下面的標志上顯示了最近掃描日期，請放心訪問該Web站點。

實際上，大多數Web應用程序并不安全，雖然SSL已得到廣泛使用，且會定期進行PCI掃描。常見的Web應用程序漏洞類型有以下幾種。

（1）跨站點腳本（94%）。攻擊者可利用該漏洞攻擊應用程序的其他用戶、訪問其信息、代表他們執行未授權操作，或者向其發動其他攻擊。

（2）跨站點請求偽造（92%）。利用這種漏洞，攻擊者可以誘使用戶在無意中使用自己的用戶權限對應用程序執行操作。惡意Web站點可以利用該漏洞，通過受害用戶與應用程序進行交互，執行用戶并不打算執行的操作。

（3）信息泄露（78%）。這一問題包括應用程序泄露敏感信息，攻擊者利用這些敏感信息通過有缺陷的錯誤處理或其他行為攻擊應用程序。

（4）不完善的訪問控制措施（71%）。這一問題涉及的情況包括應用程序無法為數據和功能提供全面保護，攻擊者可以查看其他用戶保存在服務器中的敏感信息，或者執行特權操作。（5）不完善的身份驗證措施（62%）。這類漏洞包括應用程序登錄機制中的各種缺陷，可能會使攻擊者破解保密性不強的密碼、發動蠻力攻擊或完全避開登錄。

（6）SQL注入（32%）。攻擊者可通過這一漏洞提交專門設計的輸入，干擾應用程序與后端數據庫的交互活動。攻擊者能夠從應用程序中提取任何數據、破壞其邏輯結構，或者在數據庫服務器上執行命令。

OWASP（開放式Web應用程序安全項目組織）列出的Web應用程序漏洞排名如圖1-3所示。

SSL是一種出色的技術，可為用戶瀏覽器和Web服務器間傳輸的數據提供機密性與完整性保護功能。它有助于防止信息泄露，并可保證用戶處理的Web服務器的安全性。但SSL并不能抵御直接針對某個應用程序的服務器或客戶端組件的攻擊，而許多成功的攻擊都恰恰屬于這種類型。

從SSL協議所提供的服務及其工作流程可以看出，SSL協議運行的基礎是商家對消費者信息保密的承諾，這就有利于商家而不利于消費者。在電子商務初級階段，由于運作電子商務的企業大都是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL 3.0中通過數字簽名和數字證書可實現瀏覽器和Web服務器雙方的身份驗證，但是SSL協議仍存在一些問題，如只能提供交易中客戶與服務器間的雙方認證，在涉及多方的電子交易中，SSL協議并不能協調各方間的安全傳輸和信任關系。在這種情況下，Visa和MasterCard兩大信用卡組織制定了SET協議，為網上信用卡支付提供了全球性的標準。特別需要指出的是，SSL并不能阻止上述任何漏洞或許多其他使應用程序受到威脅的漏洞。無論是否使用SSL，大多數Web應用程序仍然存在安全漏洞。

1.2.2 Web應用程序安全的核心問題

Web應用程序為結構設計人員和開發人員提出了一系列復雜的安全問題。最安全、最有能力抵御攻擊的Web應用程序是那些應用安全思想構建的應用程序。與多數分布式應用程序一樣，為確保安全，Web應用程序必須解決一個根本的問題。由于應用程序無法控制客戶端，用戶幾乎可向服務器端應用程序提交任意輸入。應用程序必須假設所有輸入的信息都是惡意的輸入，并必須采取措施確保攻擊者無法使用專門設計的輸入破壞應用程序，干擾其邏輯結構與行為，并最終達到非法訪問其數據和功能的目的。這個核心問題表現在以下幾個方面。

（1）用戶并不限于僅使用一種Web瀏覽器訪問應用程序。大量各種各樣的工具可以協助攻擊Web應用程序，這些工具既可整合在瀏覽器中，也可獨立于瀏覽器運作。這些工具能夠提出普通瀏覽器無法提交的請求，并能夠迅速生成大量的請求，查找和利用安全問題達到自己的目的。

（2）用戶可干預客戶端與服務器間傳送的所有數據，包括請求參數、Cookies和HTTP信息頭。可輕易避開客戶端執行的任何安全控件，如輸入確認驗證。

（3）絕大多數針對Web應用程序的攻擊都涉及向服務器提交輸入，旨在引起一些應用程序設計者無法預料或不希望出現的事件。以下舉例說明為實現這種目的而提交的專門設計的輸入。

① 用戶可按任何順序發送請求，并可在應用程序要求之外的不同階段不止一次提交或根本不提交參數。用戶的操作可能與開發人員對用戶和應用程序交互方式做出的任何假設完全不同。

② 改變由后端數據庫處理的某個輸入，從而注入一個惡意數據庫查詢以訪問敏感數據。

③ 利用應用程序處理過程中的邏輯錯誤刪除某些正常提交的參數。

④ 更改以隱藏的HTML表單字段提交的產品價格，以更低廉的價格欺詐性地購買該產品。

⑤ 修改在HTTP Cookies中傳送的會話令牌，劫持另一個驗證用戶的會話。

輸入驗證是一個很復雜的問題，并且是應用程序開發人員需要解決的首要問題。然而，正確的輸入驗證是防御目前應用程序攻擊的最有效方法之一。正確的輸入驗證是防止XSS、SQL注入、緩沖區溢出和其他輸入攻擊的有效對策。

輸入驗證非常復雜，因為對于應用程序之間甚至應用程序內部的輸入，其有效構成沒有一個統一的答案。同樣，對于惡意的輸入也沒有一個統一的定義。更困難的是，應用程序對如何處理此輸入將會影響應用的風險。例如，您是否存儲用于其他應用程序的數據，或者應用程序是否接受來自其他應用程序所創建的數據源的輸入？

以下做法可以增強Web應用程序的輸入驗證。

（1）假定所有輸入都是惡意的。

開始輸入驗證時，首先假定所有輸入都是惡意的，除非有證據表明它們并無惡意。無論輸入是來自服務、共享文件、用戶還是數據庫，只要其來源不在可信任的范圍之內，就應對輸入進行驗證。例如，如果調用返回字符串的外部Web服務，如何知道該服務不會執行惡意命令呢？另外，如果幾個應用程序寫入同一個共享數據庫，您在讀取數據時，如何知道該數據是否安全呢？

（2）集中式驗證方法。

將輸入驗證策略作為應用程序設計的核心元素。考慮集中式驗證方法，如通過使用共享庫中的公共驗證和篩選代碼。這可確保驗證規則應用的一致性。此外，還能減少開發的工作量，且有助于以后的維護工作。

許多情況下，不同的字段要求不同的驗證方法，如要求使用專門開發的常規表達式。但是，通常可以得到驗證常用字段（如電子郵件地址、標題、名稱、包括郵政編碼在內的通信地址，等等）的常規方法。

輸入驗證的集中式方法如圖1-4所示。

（3）不要依賴于客戶端驗證。

應使用服務器端代碼執行其自身的驗證。如果攻擊者繞過客戶端或關閉客戶端腳本例程（如通過禁用Java Script腳本），后果如何？使用客戶端驗證可以減少客戶端到服務器端的往返次數，但不要依賴這種方法進行安全驗證。這是一個深入徹底的防御示例。

（4）注意標準化問題。

數據的標準形式是最標準、最簡單的形式。標準化是指將數據轉化為標準形式的過程。文件路徑和URL尤其傾向于標準化問題，許多廣為人知的漏洞利用都直接源自標準化缺陷。例如，請考慮以下字符串，它以標準形式表示了文件及其路徑。

c:\temp\somefi le.dat

以下字符串也可以代表同一個文件。

somefi le.dat
    c:\temp\subdir\..\somefi le.dat
    c:\temp\somefi le.dat
    ..\somefi le.dat
    c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Csomefi le.dat

最后一個示例使用十六進制指定字符：

%3A代表冒號；

%5C代表反斜杠符號；

%2E代表點號。

通常，應設法避免讓應用程序接受用戶輸入的文件名，以防止標準化問題，可以考慮其他設計方法。例如，讓應用程序為用戶確定文件名。如果確實需要用戶輸入文件名，在做出安全決策（如授予或拒絕對特定文件的訪問權限）之前，應確保這些文件名具有嚴格定義的形式。

（5）限制、拒絕和凈化輸入。

輸入驗證的首選方法是從開始就限制允許輸入的內容。按照已知的有效類型、模式和范圍驗證數據要比通過查找已知有害字符的數據驗證方法容易。設計應用程序時，應了解應用程序需要輸入什么內容。與潛在的惡意輸入相比，有效數據的范圍通常是更為有限的集合。然而，為了使防御更為徹底，您可能還希望拒絕已知的有害輸入，然后凈化輸入，如圖1-5所示。

要創建有效的輸入驗證策略，需了解以下方法及其折中方案。

① 限制輸入。限制輸入與允許輸入有益數據類似。這是首選的輸入驗證方法。其思想是定義一個篩選器，根據類型、長度、格式和范圍來篩選輸入的數據。定義應用程序字段可以接受的數據輸入，并強制應用該定義。拒絕一切有害數據。限制輸入可能包括在服務器上設置字符集，以便在本地建立輸入的規范格式。

② 驗證數據的類型、長度、格式和范圍。在適當的地方對輸入數據使用強類型檢查，例如，在用于操作和處理輸入數據的類中，以及在數據訪問例程中。例如，可以使用參數化的存儲過程來訪問數據，以便利用輸入字段的強類型檢查所帶來的好處。

應該檢查字符串字段的長度，在許多情況下，還應檢查字符串的格式是否正確。例如，郵政編碼和身份證號碼等都具有明確定義的格式，可以使用常規表達式進行驗證。嚴格的檢查不僅是很好的編程習慣，還能讓攻擊者更難利用用戶的代碼。攻擊者可能會通過類型檢查，但長度檢查會加大攻擊者實施其所喜歡的攻擊方式的難度。

③ 拒絕已知的有害輸入。雖然不能完全依賴于這種方法，但還是應該拒絕“有害”數據。此方法通常不會像使用上述的“允許”方法那樣有效，但二者結合使用可以收到最佳效果。要拒絕有害數據，需假定應用程序知道惡意輸入的所有變體。請記住，字符有多種表達方式。這是“允許”方法成為首選方法的另一個原因。

雖然在應用程序已經部署、不能再做重大更改時，“拒絕”方法非常有用，但它不如“允許”方法那樣可靠，因為有害數據（如可用于識別常見攻擊的樣式）不是保持不變的。有效數據的形式是保持不變的，但有害數據的范圍是時常變化的。

④ 凈化輸入。凈化是為了使有潛在危害的數據變得安全。如果所允許的輸入范圍不能保證輸入數據的安全性，那么凈化輸入是非常有用的。凈化包括從刪除用戶輸入字符串后面的空格到去除值（以便按照文字格式處理該數據）等一切行為。

在Web應用程序中，另一個常見的凈化輸入示例是使用URL編碼或HTML編碼來包裝數據，并將其作為文本而不是可執行腳本來處理。HtmlEncode方法去除HTML字符，而UrlEncode方法對URL進行編碼，使其成為有效的URI請求。

在實踐中，以下是使用上述方法處理常見輸入字段的幾個示例。

（1）姓氏字段。這是一個很好的應用限制輸入的示例。在這種情況下，可以接受的字符串范圍為ASCII A-Z和a-z，以及連字符和波浪線（在SQL中，波浪線沒有意義），以便處理類似O'Dell之類的姓氏。還應限制輸入內容的最大長度。

（2）數量字段。這是應用輸入限制的另一個例子。在此示例中，可以使用簡單的類型和范圍限制。例如，輸入數據應該是介于0～1000之間的正整數。

（3）自定義文本字段。示例包括留言板上的備注字段。在這種情況下，您可能被允許輸入字母和空格，以及省略符號、逗號和連字符等常用字符。允許輸入的字符集只包括符號、括號和大括號。

有些應用程序可能允許用戶使用一組有限的腳本字符修飾文本，如粗體“<b>”、斜體“<b>”，甚至包含指向他們所喜愛的URL的連接。處理URL時，驗證時應先對所輸入的值進行編碼，以便將其作為URL處理。

（4）不驗證用戶輸入的現有Web應用程序。在理想方案中，應用程序將檢查每個字段和入口點的輸入內容是否可以接受。然而，如果現有Web應用程序不驗證用戶輸入，則需要一種權宜方法來降低風險，直到改進應用程序的輸入驗證策略。以下兩種方法都不能確保輸入數據的安全處理，因為這要依賴于輸入的來源，以及應用程序使用輸入數據的方式，目前，它們作為快速的補救措施，能在短期內提高應用程序的安全性。

① 向客戶端寫回數據時，對用戶輸入的數據進行HTML編碼和URL編碼。在這種情況下，假設所有輸入均未作為HTML處理，并且向客戶端寫回的所有輸出都包含在受保護的表單中。這是凈化操作在起作用。

② 拒絕惡意腳本字符。這是一個拒絕已知有害輸入的示例。在這種情況下，將使用可配置的惡意字符集來拒絕輸入。如上所述，這種方法存在的問題是，有害數據是與上下文相關的。

毋庸置疑，SSL無法阻止攻擊者向服務器提交專門設計的輸入。應用程序使用SSL僅僅表示網絡上的其他用戶無法查看或修改攻擊者傳送的數據。因為攻擊者控制著SSL通道的終端，能夠通過這條通道向服務器傳送任何內容。如果前面提到的任何攻擊成功實現，那么不論其在FAQ中聲稱其如何安全，該應用程序都很容易受到攻擊。

1.2.3 Web應用程序中存在的安全風險

任何情況下，如果一個應用程序必須接受并處理可能是惡意的未經驗證的數據，就會產生Web應用程序面臨的核心安全問題。但是，對Web應用程序而言，幾種因素的結合使問題更加嚴重，這也解釋了當今互聯網上許多Web應用程序無法很好地解決這一問題的原因。

1．不成熟的安全意識

近年來，人們對Web應用程序安全問題的意識有所增強，但與網絡和操作系統這些發展更加完善的領域相比，人們對Web應用程序安全問題的意識還遠不夠成熟。雖然大多數IT安全人員掌握了相當多的網絡安全與主機強化基礎知識，但他們對與Web應用程序安全有關的許多核心概念仍然不甚了解，甚至存有誤解。當前，在其工作中，Web應用程序開發人員往往需要整合數十甚至數百個第三方數據包，導致他們無法集中精力研究基礎技術。即使是經驗豐富的Web應用程序開發人員，也經常會對所用的編程框架的安全性做出錯誤假設，或遇到一些對他們而言完全陌生的基本缺陷類型。

2．獨立開發

大多數Web應用程序都由企業自己的員工或合作公司獨立開發，即使應用程序采用第三方組件，通常也是使用新代碼將第三方組件進行自定義或拼湊在一起。在這種情況下，每個應用程序都各不相同，并且可能包含其獨有的缺陷。這種情形與組織購買業內一流產品并按照行業標準指南安裝的典型基礎架構部署形成鮮明對照。

3．欺騙性的簡化

使用今天的Web應用程序和開發工具，一個程序員新手也能在短期內從頭開始創建一個強大的應用程序。但是，在編寫功能性代碼與編寫安全代碼之間存在巨大的差異。許多Web應用程序由善意的個人創建，他們只是缺乏發現安全問題的知識與經驗。

近年來出現了一種顯著趨勢，即使用提供現成代碼組件的應用程序框架來處理各種常見的功能，這些功能包括身份驗證、頁面模板、公告牌及與常用后端基礎架構組件的集成，等等。Liferay和Appfuse就屬于這種類型的框架。使用這些產品可以快速、方便地創建可運行的應用程序，而無須了解這些應用程序的運行機制或它們包含的潛在風險。這也意味著許多公司會使用相同的框架。因此，即使僅僅出現一個漏洞，該漏洞也將會影響許多無關的應用程序。

4．迅速發展的威脅形勢

Web應用程序攻擊與防御研究發展相對不成熟，是一個正蓬勃發展的領域，其中新概念與威脅出現的速度比傳統的技術要快得多。在客戶端方面尤其如此，針對特定攻擊的公認防御機制往往會在一些研究中失去作用，這些研究最終成就了新的攻擊技巧。在項目開始之初就完全了解了當前威脅的開發團隊，很可能到應用程序開發完成并部署后會面臨許多未知的威脅。

5．資源與時間限制

由于獨立、一次性開發的影響，許多Web應用程序開發項目會受到嚴格的時間與資源限制。通常，設計或開發團隊不可能雇用專職的安全專家，而且由于項目進程的拖延，往往要等到項目周期的最后階段才由專家進行安全測試。為了兼顧各種要素，按期開發出穩定而實用的應用程序的要求往往使開發團隊忽視不明顯的安全問題。小型組織一般不愿多花時間評估一個新的應用程序。快速滲透測試通常只能發現明顯的安全漏洞，而往往會遺漏比較細微、需要時間和耐心來發現的漏洞。

6．技術上強其所難

Web應用程序使用的許多核心技術出現于萬維網早期階段，那時的狀況與目前十分不同。從那以后，其功能已遠遠超越最初的設想，如在許多基于AJAX的應用程序中使用Java Script進行數據傳輸。隨著對Web應用程序功能要求的變化，用于實現這種功能的技術已遠遠落后于其發展要求，而開發人員還是沿用原有的技術來滿足新的需求。因此，這種做法造成的安全漏洞與無法預料的負面影響也就不足為奇了。

7．對功能的需求不斷增強

在設計應用程序時，開發人員主要考慮的是功能和可用性。曾經靜態的用戶資源現在包含社交網絡功能，允許用戶上傳照片，對頁面進行“維基”風格的編輯。以前，應用程序設計人員可以僅僅通過用戶名和密碼來創建登錄功能，而現今的站點則包含密碼恢復、用戶名恢復、密碼提示，以及在將來訪問時記住用戶名和密碼的選項。無疑，這類站點聲稱能夠提供各種安全功能，但實際上，這些功能不過是增大了該站點的受攻擊面而已。

8．Web應用程序體系結構設計不當

Web應用程序向設計人員和開發人員提出了許多挑戰。HTTP是無國界的，這意味著跟蹤每位用戶的會話狀態將成為應用程序的責任。作為先導者，應用程序必須能夠通過某種形式的身份驗證來識別用戶。由于所有后續授權決策都要基于用戶的標識，因此，身份驗證過程必須是安全的，同樣必須很好地保護用于跟蹤已驗證用戶的會話處理機制。設計安全的身份驗證和會話管理機制僅僅是Web應用程序設計人員和開發人員所面臨的眾多問題中的兩個方面。由于輸入和輸出數據要在公共網絡上進行傳輸，因此還會存在其他挑戰。防止參數操作和敏感數據泄漏是另一些重要問題。

表1-1顯示了由于設計不當導致的Web應用程序漏洞及潛在問題。

1.2.4 Web應用程序安全的預防及發展趨勢

在Web應用程序出現之前，主要在網絡邊界上抵御外部攻擊。保護這個邊界需要對其提供的服務進行強化、打補丁，并在用戶訪問之間設置防火墻。Web應用程序改變了這一切。用戶要訪問應用程序，邊界防火墻必須允許其通過HTTP/HTTPS連接內部服務器；應用程序要實現其功能，必須允許其連接服務器以支持后端系統，如數據庫、大型主機及金融與后勤系統，這些系統通常處于組織運營的核心部分，并由幾層網絡級防御保護。

如果Web應用程序存在漏洞，那么公共互聯網上的攻擊者只需從Web瀏覽器提交專門設計的數據就可攻破組織的核心后端系統。這些數據會像傳送至Web應用程序的正常、良性數據流一樣，穿透組織的所有網絡防御。

Web應用程序的廣泛應用使得典型組織的安全邊界發生了變化。部分安全邊界仍舊關注防火墻與防御主機，但大部分安全邊界更加關注組織所使用的Web應用程序。Web應用程序接收用戶輸入的方式多種多樣，將這些數據傳送至敏感后端系統的方式也多種多樣，這些都是一系列攻擊的潛在關口，因此必須在應用程序內部執行防御措施，以阻擋這些攻擊。即使某個Web應用程序中的某一行代碼存在缺陷，也會使組織的內部系統易于遭受攻擊。此外，隨著“聚合”應用程序、第三方小部件及其他跨域集成技術的出現，服務器端安全邊界常常會跨越組織本身的邊界。而且，各種組織還盲目地信任外部應用程序和服務。前述有關該新的安全邊界內漏洞發生概率的統計數據值得每一個組織思考。

對一個針對組織的攻擊者而言，獲得網絡訪問權或在服務器上執行任意命令可能并不是他們真正想要實現的目標。大多數或者基本上所有攻擊者的真實意圖是執行一些應用程序級行為，如偷竊個人信息、轉賬或購買價格低廉的產品。而應用程序層面上存在的安全問題對實現這些目標有很大幫助。

Web應用程序安全邊界發生變化的另一原因，在于用戶本身在訪問一個易受攻擊的應用程序時面臨的威脅。惡意攻擊者可能會利用一個良性但易受攻擊的Web應用程序攻擊任何訪問它的用戶。如果用戶位于企業內部網絡，攻擊者可能會控制用戶的瀏覽器，并從用戶的可信位置向本地網絡發動攻擊。如果攻擊者心存惡意，他不需要用戶的任何合作，就可以代表用戶執行任何行為。隨著瀏覽器擴展技術的興起，各種插件不斷增多，客戶端受攻擊面的范圍也明顯變大。

網絡管理員清楚如何防止其用戶訪問惡意的Web站點，終端用戶也逐漸意識到這種威脅。但是，鑒于Web應用程序漏洞的本質，與一個全然惡意的Web站點相比，易受攻擊的應用程序至少給用戶及其組織帶來了一種威脅。因此，新的安全邊界要求所有應用程序的所有者承擔保護其用戶的責任，使他們免受通過應用程序傳送的攻擊。

此外，人們普遍采用電子郵件作為一種補充驗證機制，安全邊界在一定程度上向客戶端轉移。當前，大量應用程序都包含“忘記密碼”功能，攻擊者可以利用該功能向任何注冊地址發送賬戶恢復電子郵件，而無須任何其他用戶特定的信息。因此，如果攻擊者攻破了用戶的Web郵件賬戶，就可以輕松擴大攻擊范圍，并攻破受害用戶注冊的大多數Web應用程序賬戶。

Web應用程序安全的預防措施有以下幾種。

（1）確定安全Web應用程序的重要體系結構和設計問題。

（2）設計時考慮重要部署問題。

（3）制定能增強Web應用程序輸入驗證的策略。

（4）設計安全的身份驗證和會話管理機制。

（5）選擇適當的授權模型。

（6）實現有效的賬戶管理方法，并保護用戶會話。

（7）對隱私、認可、防止篡改和身份驗證信息進行加密。

（8）防止參數操作。

（9）設計審核和記錄策略。

Web應用程序安全的發展趨勢：雖然經過約10年的廣泛應用，但目前互聯網上的Web應用程序仍然充滿漏洞。在了解Web應用程序面臨的安全威脅及如何有效應對這些威脅方面，整個行業仍未形成成熟的意識。目前幾乎沒有跡象表明上述問題能夠在不遠的將來得到解決。

也就是說，Web應用程序的安全形勢并非靜止不變。盡管SQL注入等熟悉的傳統漏洞還在不斷出現，但已不是主要問題。而且，現有的漏洞也變得更難以發現和利用。幾年前只需使用瀏覽器就能夠輕易探測與利用的小漏洞，現在需要花費大量精力開發先進技術來發現。

Web應用程序安全的另一個突出趨勢：攻擊目標已由傳統的服務器端應用程序轉向用戶應用程序。后一類攻擊仍然需要利用應用程序本身的缺陷，但這類攻擊一般要求與其他用戶進行某種形式的交互，以達到破壞用戶與易受攻擊的應用程序之間交易的目的。其他軟件安全領域也同樣存在這種趨勢。隨著安全威脅意識的增強，服務器端存在的缺陷首先應為人們所理解并得到解決，從而可以在進一步的研究過程中將注意力集中在客戶端。

Web應用程序安全預防方法中必須解決的其他重要問題如圖1-6所示。

技術領域的各種最新趨勢在一定程度上改變了Web應用程序的安全狀態。一些極具誤導性的熱門詞匯使這些趨勢深入人心，下面是一些最熱門的詞匯。

（1）大數據。這一術語指無法在可承受的時間范圍內用常規軟件工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。大數據技術的戰略意義不在于掌握龐大的數據信息，而在于對這些含有意義的數據進行專業化處理。換言之，如果把大數據比作一種產業，那么這種產業實現盈利的關鍵，在于提高對數據的“加工能力”，通過“加工”實現數據的“增值”。

（2）云計算。這一術語指更多地通過外部服務提供商來實施技術棧的各個部分，包括應用程序軟件、應用程序平臺、Web服務器軟件、數據庫和硬件。它也指在托管環境中大量采用虛擬化技術。云計算是基于互聯網的相關服務的增加、使用和交付模式，通常涉及通過互聯網來提供動態易擴展且經常是虛擬化的資源。云是網絡、互聯網的一種比喻說法。過去在圖中往往用云來表示電信網，后來也用云來表示互聯網和底層基礎設施的抽象。因此，云計算甚至可以讓你體驗每秒10萬億次的運算能力，擁有這么強大的計算能力可以模擬核爆炸、預測氣候變化和市場發展趨勢。用戶通過計算機、筆記本電腦、手機等方式接入數據中心，按自己的需求進行運算。

（3）Web 6.0。這一術語指本質上不是單純的互聯網技術或衍生思想，而是物聯網與互聯網的初步結合，一種全新模式，惠及廣大網民。這里不要將物聯網看成是互聯網的附庸，它是與互聯網等價的物理媒介，是即將改變世界的新的物理模式。在Web 6.0里每個人都有調動自己感官的無限權力，用自己的五官去重新發現世界，從而改變世界。

和技術領域的大多數變革一樣，這些趨勢也催生了一些新型攻擊，并導致現有攻擊產生變體。雖然這些趨勢受到人們的大肆追捧，但鑒于其導致的各種問題，它們并不像人們最初認為的那樣會帶來顛覆性的改變。我們將在本書的相應部分討論與這些及其他最新趨勢有關的安全問題。

盡管Web應用程序發生了這些改變，一些典型漏洞并未表現出任何減少的跡象。它們繼續出現，方式與Web技術發展初期大致相同。這些漏洞包括業務邏輯缺陷、未能正確應用訪問控制及其他設計問題。即使在應用程序組件緊密集成及“一切皆服務”的時代，這些問題仍然會廣泛存在。