A. 有狀態的Web應用程序都有漏洞嗎求答案
在沒有足夠協作的情況下，許多 Web 應用程序對可變數據（比如 JavaBeans 類）使用了 HttpSession 這個機制，從而使自身面臨大量潛在的並發性危險。雖然Java? 生態系統中存在許多 Web 框架，但它們都直接或間接地基於 Servlets 基礎設施。Servlets API 提供大量有用特性，包括通過 HttpSession 和ServletContext 機制提供的狀態管理，它允許應用程序在跨多個用戶請求時保持狀態。然而，在 Web 應用程序中使用共享狀態受一些微妙的（並且大部分沒有進行說明）的規則控制著，因此導致許多應用程序無意中觸犯了規則。結果是許多有狀態 Web 應用程序存在難以發覺的嚴重缺陷。 范圍容器在Servlet 規范中，ServletContext、HttpSession 和HttpRequest 對象被稱為 范圍容器（Scoped container）。它們都有 getAttribute() 和setAttribute() 方法，為應用程序存儲數據。這些范圍容器的區別在於它們的生命周期不同。對於 HttpRequest，數據只在請求期間有效；對於 HttpSession，數據在用戶和應用程序的會話期間有效；而對於 ServletContext，數據在應用程序的整個生命周期中都有效。 由於HTTP 協議是沒有狀態的，所以范圍容器在構造有狀態 Web 應用程序時十分有用；servlet 容器負責管理應用程序的狀態和數據的生命周期。盡管這個規范沒有強調，但需要保證嵌套在會話或應用程序中的容器在某種程度上是線程安全的，因為 getAttribute() 和setAttribute() 方法隨時都可能被不同的線程調用（這個規范沒有直接要求這些實現必須是線程安全的，但它們提供的服務實際上提出了這一點）。范圍容器還為 Web 應用程序提供一個潛在的好處：容器可以透明地管理應用程序狀態的復制和故障轉移。 會話session 是特定用戶和 Web 應用程序之間的一系列請求-響應交換。用戶希望 Web 站點記住他的身份驗證憑證、購物車的物品，以及在前面的請求中輸入到 Web 表單的信息。但核心 HTTP 協議是沒有狀態的，這意味著必須將所有請求信息存儲到請求本身。因此，如果要創建比一個請求-響應周期更長的有用交互，就必須存儲會話狀態。servlet 框架允許將每個請求與一個會話關聯起來，並提供充當值存儲庫的 HttpSession 介面，用於存儲與該會話相關的（鍵，值）數據項。清單 1 是一段典型的 servlet 代碼，它用於在 HttpSession 中存儲購物車數據：清單1. 使用 HttpSession 存儲購物車數據 HttpSession session = request.getSession(true); ShoppingCart cart = (ShoppingCart)session.getAttribute("shoppingCart"); if (cart == null) { cart = new ShoppingCart(...); session.setAttribute("shoppingCart"); } doSomethingWith(cart); 清單1 提供的是 servlet 的典型用途；這個應用程序查看是否已將一個對象放到會話中，如果還沒有，它將創建一個該會話的後續請求可以使用的對象。構建在 servlet 之上的 Web 框架（比如 JSP、JSF 和 SpringMVC 等）隱藏了細節情況，但對於標記為嵌入到會話中的數據，它們替您執行了實際操作。不幸的是，清單 1 中的用法很可能是不正確的。 與線程相關的問題當HTTP 請求到達 servlet 容器之後，會在 servlet 容器管理的線程上下文中創建 HttpRequest 和HttpResponse 對象，並傳遞給 servlet 的 service() 方法。servlet 負責生成響應；在響應完成之前 servlet 一直控制這個線程，響應完成時該線程返回到可用的線程池。Servlet 容器沒有保持線程與會話之間的聯系；某個會話的下一個請求很可能由另一個不同的線程來處理。事實上，可能有多個請求同時進入同一個會話（當用戶與頁面交互時，使用框架或 AJAX 技術從伺服器獲取數據的 Web 應用程序可能發生這種現象）。在這種情況，同一用戶可能發出多個請求，這些請求在不同的線程上並行執行。 大多數情況下，這類線程問題與 Web 應用程序開發人員無關。由於自身沒有狀態，HTTP 鼓勵只有存儲在請求中的數據（不與其他並發請求共享）和存儲在存儲庫（比如資料庫）中的、已進行並發性控制的數據，才具有響應功能。然而，一旦 Web 應用程序將數據存儲在 HttpSession 或ServletContext 等共享容器之後，該 Web 應用程序就具有了並發性，因此必須考慮應用程序內部的線程安全問題。 盡管我們常用線程安全描述代碼，但實際上它是描述數據的。具體來說，線程安全是指適當地協調對被多個線程訪問的可變數據的訪問。Servlet 應用程序通常是線程安全的，因為它們沒有共享任何可變數據，因此就不需要額外的同步。但可以通過很多種辦法將共享狀態引入到 Web 應用程序 — 除了 HttpSession 和ServletContext 等范圍容器外，還可以使用 HttpServlet 對象的靜態欄位和實例欄位。如果要讓 Web 應用程序跨請求共享數據，開發人員就必須注意共享數據的位置，並保證訪問共享數據時線程之間有足夠的協作（同步），以避免與線程相關的危險。 Web 應用程序的線程風險如果Web 應用程序將購物車等可變會話數據存儲在 HttpSession 中，就有可能出現兩個請求試圖同時訪問該購物車。這可能導致以下幾種故障： 原子性故障。在數據不一致的狀態下，一個線程正在更新多個數據項，而另一個線程正在讀取這些數據 讀線程和寫線程之間的可見性故障。一個線程修改購物車，但另一個線程看到的購物車內容的狀態是過時的或不一致的 原子性故障清單2 展示了一個用於在游戲應用程序中設置和獲取最高分的不恰當的方法實現。它使用一個 PlayerScore 對象來表示最高分，這實際上是一個具有 name 和score 屬性的普通 JavaBean 類，存儲在內嵌於應用程序的 ServletContext 中（假設在應用程序啟動時，初始最高分在 ServletContext 中被設置為 highScore 屬性，因此 getAttribute() 調用不會失敗）。 清單2. 在范圍容器中存儲相關項的不恰當模式 public PlayerScore getHighScore() { ServletContext ctx = getServletConfig().getServletContext(); PlayerScore hs = (PlayerScore) ctx.getAttribute("highScore"); PlayerScore result = new PlayerScore(); result.setName(hs.getName()); result.setScore(hs.getScore()); return result; } public void updateHighScore(PlayerScore newScore) { ServletContext ctx = getServletConfig().getServletContext(); PlayerScore hs = (PlayerScore) ctx.getAttribute("highScore"); if (newScore.getScore() > hs.getScore()) { hs.setName(newScore.getName()); hs.setScore(newScore.getScore()); } } 清單2 中的代碼不夠好。這里採用的方法是在 ServletContext 中存儲一個包含最高分玩家的名字和分數的可變容器。當打破記錄時，必須更新名字和分數。 假如當前的最高分玩家是 Bob，他的分數為 1000，但是 Joe 以 1100 分打破了這個記錄。在正要設置 Joe 的分數時，另一個玩家又發出獲得最高分的請求。getHighScore() 將從servlet 上下文獲取 PlayerScore 對象，然後從該對象獲取名字和分數。如果不慎出現計時失誤，就有可能獲取 Bob 的名字和 Joe 的分數，顯示 Bob 取得了 1100 分，而實際上 Bob 並沒有獲得這個分數（這種故障在免費游戲站點上是可以接受的，因為 「分數」 並不是 「銀行存款」）。這是一種原子性故障，因為彼此之間本應該是原子關系的兩個操作 — 獲取名字/分數對和更新名字/分數對 — 實際上並沒有按照原子關系執行，而且其中一個線程可以在不一致狀態下查看共享數據。另外，由於分數更新邏輯遵循 check-then-act 模式，因此可能出現兩個線程 「爭奪」 更新最高分，從而導致難以預料的結果。假設當前的最高分是 1000，有兩個玩家同時注冊更高的分數 1100 和 1200。如果出現計時失誤，這兩個分數都能夠通過 「高於現有分數的最高分」 檢查，並且都進入到更新最高分的代碼塊中。和前面一樣，根據計時的實際情況，最後的結果可能不一致（採用一個玩家的名字和另一個玩家的分數），或者出現錯誤（分數為 1100 的玩家可能覆蓋分數為 1200 的玩家）。 可見性故障 比原子性故障更復雜的是可見性 故障。沒有同步時，如果一個線程讀取另外一個線程正在寫的變數，讀的線程將看到過時的 數據。更糟糕的是，讀線程還可能會看到 x 變數的最新數據和 y 變數的過時數據，即使先寫 y 變數也是這樣。可見性故障非常復雜，因為它的發生是隨機的，甚至是頻繁的，這會導致罕見的難以調試的間發性故障。可見性故障是由數據爭奪引起的 — 訪問共享變數時不能正確同步。爭奪數據的程序，不管它是什麼樣的，都屬於有漏洞的程序，因為它們的行為不能可靠預測。 Java Memory Model（JMM）定義一些條件，它們保證讀變數的線程能夠看到另一個線程的寫入結果（詳細講解 JMM 超出了本文的范圍；參見 參考資料）。JMM 在一個稱為 happens-before 的程序的操作上定義一個排序。只有在通用鎖上執行同步或訪問一個通用的可變變數時，才能創建跨線程的 Happens-before 排序。在沒有 happens-before 排序的情況下， Java 平台可以延遲或更改順序，按照這個順序，一個線程的寫操作對於另一個讀取同一變數的線程是可見的。 清單2 中的代碼不僅有原子性故障，還有可見性故障。updateHighScore() 方法從 ServletContext 獲取HighScore 對象，然後修改它的狀態。這樣做的目的是讓其他調用 getHighScore() 的線程看見這些修改，但是如果 updateHighScore() 的name 和 score 屬性的寫操作和其他調用 getHighScore() 的線程的 name 和 score 屬性的讀操作之間沒有 happens-before 排序，我們只能期盼運氣好些，讓讀線程能夠看到正確的值。 可能的解決方案盡管servlet 規范沒有充分地描述 servlet 容器必須提供的 happens-before 保證，但可以得出結論：將一個屬性放置在共享范圍容器（HttpSession 或ServletContext）應該在另一個線程獲取該屬性之前發生。（參見 JCiP 4.5.1 了解這個結論的推理過程。該規范中這樣描述：「執行請求線程的多個 servlets 可能同時積極地訪問單個會話對象。開發人員負責恰當地同步對會話資源的訪問）。 set-after-write 技巧更新存儲在其他會話容器中的可變數據時，必須在修改該數據後再次調用 setAttribute()。這是一種常用的最佳實踐。清單 3 展示了重寫 updateHighScore() 以使用這個技巧的示例（這個技巧的目的之一是提示容器值已經更改，因此可以在分布式 Web 應用程序的各個實例之間重新同步會話和應用程序狀態）。 清單3. 使用 set-after-write 技巧提示 servlet 容器值已經更新 public void updateHighScore(PlayerScore newScore) { ServletContext ctx = getServletConfig().getServletContext(); PlayerScore hs = (PlayerScore) ctx.getAttribute("highScore"); if (newScore.getScore() > hs.getScore()) { hs.setName(newScore.getName()); hs.setScore(newScore.getScore()); ctx.setAttribute("highScore", hs); } } 不幸的是，盡管這個技巧能夠在集群應用程序中高效地復制會話和應用程序狀態，但它不能解決本例中的基本線程安全問題。它可以減輕可見性問題（即另一個玩家可能永遠看不到在 updateHighScore() 中更新的值），但還不能解決許多潛在的原子性問題。 利用同步set-after-write 技巧可以消除可見性問題，因為 happens-before 排序是可傳遞的，因而調用 updateHighScore() 中的setAttribute() 和調用 getHighScore() 中的getAttribute() 之間有一個邊緣地帶。因為 HighScore 狀態的更新在 setAttribute() 之前發生，setAttribute() 狀態的更新在從 getAttribute() 返回之前發生，getAttribute() 狀態的更新在 getHighScore() 的調用方使用狀態之前發生，所以通過這種傳遞可以得出結論：調用方 getHighScore() 看到的值至少和 setAttribute() 的最近一次調用一樣新。這個技巧稱為利用同步（piggybacking on synchronization），因為 getHighScore() 和updateHighScore() 方法能夠在 getAttribute() 和setAttribute() 中使用同步信息來提供一些可見性保證。然而，在上面這個例子中，這還不能完全解決問題。set-after-write 技巧可能對狀態復制非常有用，但還不能提供線程安全。 了解不可修改性要創建線程安全的應用程序，一個有用的技巧便是盡可能多地使用不可修改的數據。清單 4 展示了重寫後的最高分示例，它使用了 HighScore 的不可修改的 實現，從而避免了原子性故障（允許調用方看見不存在的玩家/分數對）和可見性故障（阻止 getHighScore() 的調用方看見在調用 updateHighScore() 時寫的最新值）： 清單4. 使用不可修改的 HighScore 對象修復原子性和可見性漏洞 Public class HighScore { public final String name; public final int score; public HighScore(String name, int score) { this.name = name; this.score = score; } } public PlayerScore getHighScore() { ServletContext ctx = getServletConfig().getServletContext(); return (PlayerScore) ctx.getAttribute("highScore"); } public void updateHighScore(PlayerScore newScore) { ServletContext ctx = getServletConfig().getServletContext(); PlayerScore hs = (PlayerScore) ctx.getAttribute("highScore"); if (newScore.score > hs.score) ctx.setAttribute("highScore", newScore); } 清單4 中的代碼的潛在故障很少。在 setAttribute() 和getAttribute() 中使用同步保證了可見性。實際上，僅存儲單個不可修改數據項消除了潛在的原子性故障，即 getHighScore() 的調用方可以看見名字/分數對的不一致更新。 將不可修改對象放置在范圍容器避免了許多原子性和可見性故障；將有效不可修改性 對象放置在范圍容器中也是安全的。有效不可修改性對象是指那些雖然理論上是可修改的，但實際上在發布之後再沒有被更改過的對象，比如 JavaBean，將一個對象放置到 HttpSession 中之後，它的 setter 方法就不再被調用。 放置在 HttpSession 中的數據不僅被該會話的請求訪問；它還可能被容器本身訪問（如果容器進行狀態復制的話）。所有放置在 HttpSession 或ServletContext 中的數據應該是線程安全的或有效不可修改的。 影響原子狀態轉換但是清單4 中的代碼仍然有一個問題 — updateHighScore() 中的check-then-act 仍然使兩個試圖更新最高分數的線程之間存在潛在 「爭奪」。如果計時失誤，有一個更新可能會丟失。兩個線程可能同時通過了 「高於現有分數的新最高分」 檢查，造成它們同時調用 setAttribute()。不能確保兩個分數中最高者獲得調用，這取決於計時。要修復這個最後的漏洞，我們需要一種原子性地更新分數引用的方法，同時又要保證不受干擾。有幾種方法可以實現這個目的。 清單5 為 updateHighScore() 添加了同步，確保更新進程中固有的 check-then-act 不和另一個更新並發執行。如果所有條件修改邏輯獲得 updateHighScore() 使用的同一個鎖，用這種方法就可以了。 清單5. 使用同步修復最後一個原子性漏洞 public void updateHighScore(PlayerScore newScore) { ServletContext ctx = getServletConfig().getServletContext(); PlayerScore hs = (PlayerScore) ctx.getAttribute("highScore"); synchronized (lock) { if (newScore.score > hs.score) ctx.setAttribute("highScore", newScore); } } 雖然清單 5 中的技術是可行的，但還有一個更好的技術：使用 java.util.concurrent 包中的 AtomicReference 類。這個類的用途就是通過 compareAndSet() 調用提供原子條件更新。清單 6 展示了如何使用 AtomicReference 來修復本示例的最後一個原子性問題。這個方法比清單 5 中的代碼好，因為很難違背更新最高分數的規則。 清單6. 使用 AtomicReference 來修復最後一個原子性漏洞 public PlayerScore getHighScore() { ServletContext ctx = getServletConfig().getServletContext(); AtomicReference<PlayerScore> holder = (AtomicReference<PlayerScore>) ctx.getAttribute("highScore"); return holder.get(); } public void updateHighScore(PlayerScore newScore) { ServletContext ctx = getServletConfig().getServletContext(); AtomicReference<PlayerScore> holder = (AtomicReference<PlayerScore>) ctx.getAttribute("highScore"); while (true) { HighScore old = holder.get(); if (old.score >= newScore.score) break; else if (holder.compareAndSet(old, newScore)) break; } } 對於放置在范圍容器中的可修改數據，應該將它們的狀態轉換變成原子性的，這可以通過同步或 java.util.concurrent 中的原子變數類來實現。 序列化對 HttpSession 的訪問在我已給出的示例中，我試圖避免與訪問整個應用程序中的 ServletContext 相關的各種危險。很明顯，訪問 ServletContext 時需要細心的協作，因為任何請求都可以訪問 ServletContext。然而，大多數有狀態 Web 應用程序嚴重依賴於內嵌於會話的容器 HttpSession。同一個會話中發生多個同步請求的原因不是很直觀；畢竟，每個會話都是綁定到一個特定用戶或瀏覽器會話的，並且用戶不一定一次請求多個頁面。但是在編程式地生成請求的應用程序中（比如 AJAX 應用程序），一個會話中的請求是可以重疊的。 單個會話中的請求當然可以是重疊的，但這不是一件好事。如果可以輕松地序列化會話中的請求，當訪問 HttpSession 中的共享對象時，這里提到的所有問題幾乎都可以解決；序列化可以阻止原子性故障，並且利用 HttpSession 中的同步可以阻止可見性故障。序列化特定會話的請求不會對吞吐量造成很大的影響，因為一個會話中的請求很少重疊，在一個會話中出現很多請求重疊就更罕見了。 不幸的是，servlet 規范並沒有提到 「序列化同一會話中的請求」。不過 SpringMVC 框架提供了一種方法，並且這種方法可以在其他框架中輕松實現。SpringMVC 控制器的基類 AbstractController 提供了一個布爾變數 synchronizeOnSession；設置這里之後，它將使用一個鎖，確保一個會話中只同時執行一個請求。 序列化 HttpSession 上的請求消除了很多並發性危險。同樣，將對象限制在 Event Dispatch Thread（EDT）中減少了 Swing 應用程序中的同步需求。結束語許多有狀態 Web 應用程序有很嚴重的並發性漏洞。在沒有足夠協調的情況下，訪問存儲在 HttpSession 和ServletContext 等范圍容器中的可變數據就會產生這些漏洞。開發人員通常會誤認為 getAttribute() 和setAttribute() 方法中的同步已經足夠 但這只能應付特定情況，比如當屬性是不可修改、有效不可修改或線程安全的對象時，或當可能訪問容器的請求被序列化時。通常，放置在范圍容器中的所有內容都應該是高度不可修改的或線程安全的。servlet 規范提供的范圍容器機制並不管理沒有提供它們自己的同步的可變對象。將普通的 JavaBean 類存儲在 HttpSession 中是很大的隱患。
B. Web應用常見的安全漏洞有哪些
OWASP總結了現有Web應用程序在安全方面常見的十大漏洞分別是：非法輸入、失效的訪問控制、失效的賬戶和線程管理、跨站腳本攻擊、緩存溢出問題、注入式攻擊、異常錯誤處理、不安全的存儲、程序拒絕服務攻擊、不安全的配置管理等。
非法輸入
Unvalidated Input
在數據被輸入程序前忽略對數據合法性的檢驗是一個常見的編程漏洞。隨著OWASP對Web應用程序脆弱性的調查，非法輸入的問題已成為大多數Web應用程序安全漏洞方面的一個普遍現象。
失效的訪問控制
Broken Access Control
大部分企業都非常關注對已經建立的連接進行控制，但是，允許一個特定的字元串輸入可以讓攻擊行為繞過企業的控制。
失效的賬戶和線程管理
Broken Authentication and Session Management
有良好的訪問控制並不意味著萬事大吉，企業還應該保護用戶的密碼、會話令牌、賬戶列表及其它任何可為攻擊者提供有利信息、能幫助他們攻擊企業網路的內容。
跨站點腳本攻擊
Cross Site Scripting Flaws
這是一種常見的攻擊，當攻擊腳本被嵌入企業的Web頁面或其它可以訪問的Web資源中，沒有保護能力的台式機訪問這個頁面或資源時，腳本就會被啟動，這種攻擊可以影響企業內成百上千員工的終端電腦。
緩存溢出問題
Buffer Overflows
這個問題一般出現在用較早的編程語言、如C語言編寫的程序中，這種編程錯誤其實也是由於沒有很好地確定輸入內容在內存中的位置所致。
注入式攻擊
Injection Flaws
如果沒有成功地阻止帶有語法含義的輸入內容，有可能導致對資料庫信息的非法訪問，在Web表單中輸入的內容應該保持簡單，並且不應包含可被執行的代碼。
異常錯誤處理
Improper Error Handling
當錯誤發生時，向用戶提交錯誤提示是很正常的事情，但是如果提交的錯誤提示中包含了太多的內容，就有可能會被攻擊者分析出網路環境的結構或配置。
不安全的存儲
Insecure Storage
對於Web應用程序來說，妥善保存密碼、用戶名及其他與身份驗證有關的信息是非常重要的工作，對這些信息進行加密則是非常有效的方式，但是一些企業會採用那些未經實踐驗證的加密解決方案，其中就可能存在安全漏洞。
程序拒絕服務攻擊
Application Denial of Service
與拒絕服務攻擊 (DoS)類似，應用程序的DoS攻擊會利用大量非法用戶搶占應用程序資源，導致合法用戶無法使用該Web應用程序。
不安全的配置管理
Insecure Configuration Management
有效的配置管理過程可以為Web應用程序和企業的網路架構提供良好的保護。
以上十個漏洞並不能涵蓋如今企業Web應用程序中的全部脆弱點，它只是OWASP成員最常遇到的問題，也是所有企業在開發和改進Web應用程序時應著重檢查的內容。
C. web漏洞掃描工具有哪些
1、Nexpose：跟其他掃描工具不同的是，它的功能十分強大，可以更新漏洞資料庫，也可以看出哪些漏洞可以被Metasploit Exploit，可以生成非常詳細、強大的Report，涵蓋了很多統計功能和漏洞的詳細信息。
2、OpenVAS：類似Nessus的綜合型漏洞掃描器，可以用來識別遠程主機、Web應用存在的各種漏洞，它使用NVT腳本對剁成遠程系統的安全問題進行檢測。
3、WebScarab：可以分析使用HTTP和HTTPS協議進行通信的應用程序，它可以簡單記錄觀察的會話且允許操作人員以各種方式進行查看。
4、WebInspect：是一款強大的Web應用程序掃描程序，有助於確認Web應用中已知和未知的漏洞，還可以檢查一個Web伺服器是否正確配置。
5、Whisker/libwhisker：是一個Perla工具，適合於HTTP測試，可以針對許多已知的安全漏洞，測試HTTP伺服器，特別是檢測危險CGI的存在。
6、Burpsuite：可以用於攻擊Web應用程序的集成平台，允許一個攻擊者將人工和自動的技術進行結合，並允許將一種工具發現的漏洞形成另外一種工具的基礎。
7、Wikto：是一個Web伺服器評估工具，可以檢查Web伺服器中的漏洞，並提供與Nikto一樣的很多功能，但增加了許多有趣的功能部分。
8、Watchfire AppScan：是一款商業類的Web漏洞掃描程序，簡化了部件測試和開發早期的安全保證，可以掃描許多常見的漏洞，如跨站腳本攻擊、HTTP響應拆分漏洞、參數篡改、隱式欄位處理、後門/調試選項、緩沖區溢出等等。
9、N-Stealth：是一款商業級的Web伺服器安全掃描程序，主要為Windows平台提供掃描，但並不提供源代碼。
D. web安全測試主要有哪些漏洞
以下類型的安全漏洞
權控缺失
系統未能正確分配用戶的許可權，用戶能執行超出自己職能范圍的操作，這類漏洞稱為權控缺失。權控缺失分為兩類：平行越權、垂直越權。
邏輯漏洞
邏輯漏洞通常是由於程序邏輯不嚴密或邏輯太復雜,導致一些邏輯分支被繞過或處理錯誤。常見漏洞包括:任意密碼修改(沒有舊密碼驗證)、密碼找回漏洞、業務數據篡改等。邏輯漏洞的出現易造成賬號被盜、免費購物,游戲應用易造成刷錢、刷游戲幣等嚴重問題。
條件競爭
服務端在做並發編程時，需要考慮到條件競爭的情況。在多個並發線程同時訪問同一資源時，由於對請求的處理不是原子性的，無法預測調度的順序，就可能由於時間序列上的沖突而造成對共享資源的操作混亂。
XSS跨站腳本攻擊
是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，提交的數據被WEB應用程序直接使用，使別的用戶訪問都會執行相應的嵌入代碼。從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。
E. web應用中的注入漏洞主要有哪幾種
網路發展至今，他的高端我們都見識過，但是網路安全也是一直以來不變的話題，怎樣能使網路更加安全呢?如何構建一個安全的Web環境，是應該考慮的事情。該選擇哪些安全工具呢?我們可以再危險發生之前，先測試一下自己系統中的漏洞。為大家推薦10大Web漏洞掃描程序。 1. Nikto 這是一個開源的Web伺服器掃描程序，它可以對Web伺服器的多種項目進行全面的測試。其掃描項目和插件經常更新並且可以自動更新。Nikto可以在盡可能短的周期內測試你的Web伺服器，這在其日誌文件中相當明顯。不過，如果你想試驗一下，它也可以支持 LibWhisker的反IDS方法。不過，並非每一次檢查都可以找出一個安全問題，雖然多數情況下是這樣的。有一些項目是僅提供信息類型的檢查，這種檢查可以查找一些並不存在安全漏洞的項目，不過Web管理員或安全工程師們並不知道。 2. Paros proxy 這是一個對Web應用程序的漏洞進行評估的代理程序，即一個基於Java的web代理程序，可以評估Web應用程序的漏洞。它支持動態地編輯/查看 HTTP/HTTPS,從而改變cookies和表單欄位等項目。它包括一個Web通信記錄程序，Web圈套程序，hash 計算器，還有一個可以測試常見的Web應用程序攻擊的掃描器。 3. WebScarab: 它可以分析使用HTTP和HTTPS協議進行通信的應用程序，WebScarab可以用最簡單地形式記錄它觀察的會話，並允許操作人員以各種方式觀查會話。如果你需要觀察一個基於HTTP(S)應用程序的運行狀態，那麼WebScarabi就可以滿足你這種需要。不管是幫助開發人員調試其它方面的難題，還是允許安全專業人員識別漏洞，它都是一款不錯的工具。 4. WebInspect： 這是一款強大的Web應用程序掃描程序。SPI Dynamics的這款應用程序安全評估工具有助於確認Web應用中已知的和未知的漏洞。它還可以檢查一個Web伺服器是否正確配置，並會嘗試一些常見的 Web攻擊，如參數注入、跨站腳本、目錄遍歷攻擊等等。 5. Whisker/libwhisker : Libwhisker是一個Perla模塊，適合於HTTP測試。它可以針對許多已知的安全漏洞，測試HTTP伺服器，特別是檢測危險CGI的存在。 Whisker是一個使用libwhisker的掃描程序。 6. Burpsuite： 這是一個可以用於攻擊Web應用程序的集成平台。Burp套件允許一個攻擊者將人工的和自動的技術結合起來，以列舉、分析、攻擊Web應用程序，或利用這些程序的漏洞。各種各樣的burp工具協同工作，共享信息，並允許將一種工具發現的漏洞形成另外一種工具的基礎。 7. Wikto: 可以說這是一個Web伺服器評估工具，它可以檢查Web伺服器中的漏洞，並提供與Nikto一樣的很多功能，但增加了許多有趣的功能部分，如後端 miner和緊密的Google集成。它為MS.NET環境編寫，但用戶需要注冊才能下載其二進制文件和源代碼。 8. Acunetix Web Vulnerability Scanner : 這是一款商業級的Web漏洞掃描程序，它可以檢查Web應用程序中的漏洞，如SQL注入、跨站腳本攻擊、身份驗證頁上的弱口令長度等。它擁有一個操作方便的圖形用戶界面，並且能夠創建專業級的Web站點安全審核報告。 9. Watchfire AppScan： 這也是一款商業類的Web漏洞掃描程序。AppScan在應用程序的整個開發周期都提供安全測試，從而測試簡化了部件測試和開發早期的安全保證。它可以掃描許多常見的漏洞，如跨站腳本攻擊、HTTP響應拆分漏洞、參數篡改、隱式欄位處理、後門/調試選項、緩沖區溢出等等。 10. N-Stealth： N-Stealth是一款商業級的Web伺服器安全掃描程序。它比一些免費的Web掃描程序，如Whisker/libwhisker、 Nikto等的升級頻率更高。還要注意，實際上所有通用的VA工具，如Nessus, ISS Internet Scanner, Retina, SAINT, Sara等都包含Web 掃描部件。N-Stealth主要為Windows平台提供掃描，但並不提供源代碼。
F. web 應用的常見 漏洞有哪些
web常見的幾個漏洞
1. SQL注入
SQL注入攻擊是黑客對資料庫進行攻擊的常用手段之一。
2. XSS跨站點腳本
XSS是一種經常出現在web應用中的計算機安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。
3. 緩沖區溢出
緩沖區溢出漏洞是指在程序試圖將數據放到及其內存中的某一個位置的時候，因為沒有足夠的空間就會發生緩沖區溢出的現象。
4. cookies修改
即使 Cookie 被竊取，卻因 Cookie 被隨機更新，且內容無規律性，攻擊者無法加以利用。另外利用了時間戳另一大好處就是防止 Cookie 篡改或重放。
5. 上傳漏洞
這個漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。
6. 命令行注入
所謂的命令行輸入就是webshell 了，拿到了許可權的黑客可以肆意妄為。
G. web安全漏洞有哪些
web常見的幾個漏洞
1. SQL注入。SQL注入攻擊是黑客對資料庫進行攻擊的常用手段之一。
2. XSS跨站點腳本。XSS是一種經常出現在web應用中的計算機安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。
3. 緩沖區溢出。緩沖區溢出漏洞是指在程序試圖將數據放到及其內存中的某一個位置的時候，因為沒有足夠的空間就會發生緩沖區溢出的現象。
4. cookies修改。即使 Cookie 被竊取，卻因 Cookie 被隨機更新，且內容無規律性，攻擊者無法加以利用。另外利用了時間戳另一大好處就是防止 Cookie 篡改或重放。
5. 上傳漏洞。這個漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。
6. 命令行輸入。就是webshell ，拿到了許可權的黑客可以肆意妄為。
H. 最好的WEB漏洞掃描工具
十大Web漏洞掃描程序,見：http://www.15897.com/blog/post/top-10-vul-scanner.html介紹
I. web漏洞攻擊有哪些
一、SQL注入漏洞
SQL注入攻擊（SQL Injection），簡稱注入攻擊、SQL注入，被廣泛用於非法獲取網站控制權，是發生在應用程序的資料庫層上的安全漏洞。在設計程序，忽略了對輸入字元串中夾帶的SQL指令的檢查，被資料庫誤認為是正常的SQL指令而運行，從而使資料庫受到攻擊，可能導致數據被竊取、更改、刪除，以及進一步導致網站被嵌入惡意代碼、被植入後門程序等危害。
通常情況下，SQL注入的位置包括：
（1）表單提交，主要是POST請求，也包括GET請求；
（2）URL參數提交，主要為GET請求參數；
（3）Cookie參數提交；
（4）HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等；
（5）一些邊緣的輸入點，比如.mp3文件的一些文件信息等。
常見的防範方法
（1）所有的查詢語句都使用資料庫提供的參數化查詢介面，參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。當前幾乎所有的資料庫系統都提供了參數化SQL語句執行介面，使用此介面可以非常有效的防止SQL注入攻擊。
（2）對進入資料庫的特殊字元（』」<>&*;等）進行轉義處理，或編碼轉換。
（3）確認每種數據的類型，比如數字型的數據就必須是數字，資料庫中的存儲欄位必須對應為int型。
（4）數據長度應該嚴格規定，能在一定程度上防止比較長的SQL注入語句無法正確執行。
（5）網站每個數據層的編碼統一，建議全部使用UTF-8編碼，上下層編碼不一致有可能導致一些過濾模型被繞過。
（6）嚴格限制網站用戶的資料庫的操作許可權，給此用戶提供僅僅能夠滿足其工作的許可權，從而最大限度的減少注入攻擊對資料庫的危害。
（7）避免網站顯示SQL錯誤信息，比如類型錯誤、欄位不匹配等，防止攻擊者利用這些錯誤信息進行一些判斷。
（8）在網站發布之前建議使用一些專業的SQL注入檢測工具進行檢測，及時修補這些SQL注入漏洞。
二、跨站腳本漏洞
跨站腳本攻擊（Cross-site scripting，通常簡稱為XSS）發生在客戶端，可被用於進行竊取隱私、釣魚欺騙、竊取密碼、傳播惡意代碼等攻擊。
XSS攻擊使用到的技術主要為HTML和Javascript，也包括VBScript和ActionScript等。XSS攻擊對WEB伺服器雖無直接危害，但是它藉助網站進行傳播，使網站的使用用戶受到攻擊，導致網站用戶帳號被竊取，從而對網站也產生了較嚴重的危害。
XSS類型包括：
（1）非持久型跨站：即反射型跨站腳本漏洞，是目前最普遍的跨站類型。跨站代碼一般存在於鏈接中，請求這樣的鏈接時，跨站代碼經過服務端反射回來，這類跨站的代碼不存儲到服務端（比如資料庫中）。上面章節所舉的例子就是這類情況。
（2）持久型跨站：這是危害最直接的跨站類型，跨站代碼存儲於服務端（比如資料庫中）。常見情況是某用戶在論壇發貼，如果論壇沒有過濾用戶輸入的Javascript代碼數據，就會導致其他瀏覽此貼的用戶的瀏覽器會執行發貼人所嵌入的Javascript代碼。
（3）DOM跨站（DOM XSS）：是一種發生在客戶端DOM（Document Object Model文檔對象模型）中的跨站漏洞，很大原因是因為客戶端腳本處理邏輯導致的安全問題。
常用的防止XSS技術包括：
（1）與SQL注入防護的建議一樣，假定所有輸入都是可疑的，必須對所有輸入中的script、iframe等字樣進行嚴格的檢查。這里的輸入不僅僅是用戶可以直接交互的輸入介面，也包括HTTP請求中的Cookie中的變數，HTTP請求頭部中的變數等。
（2）不僅要驗證數據的類型，還要驗證其格式、長度、范圍和內容。
（3）不要僅僅在客戶端做數據的驗證與過濾，關鍵的過濾步驟在服務端進行。
（4）對輸出的數據也要檢查，資料庫里的值有可能會在一個大網站的多處都有輸出，即使在輸入做了編碼等操作，在各處的輸出點時也要進行安全檢查。
（5）在發布應用程序之前測試所有已知的威脅。
三、弱口令漏洞
弱口令(weak password) 沒有嚴格和准確的定義，通常認為容易被別人（他們有可能對你很了解）猜測到或被破解工具破解的口令均為弱口令。設置密碼通常遵循以下原則：
（1）不使用空口令或系統預設的口令，這些口令眾所周之，為典型的弱口令。
（2）口令長度不小於8個字元。
（3）口令不應該為連續的某個字元（例如：AAAAAAAA）或重復某些字元的組合（例如：tzf.tzf.）。
（4）口令應該為以下四類字元的組合，大寫字母(A-Z)、小寫字母(a-z)、數字(0-9)和特殊字元。每類字元至少包含一個。如果某類字元只包含一個，那麼該字元不應為首字元或尾字元。
（5）口令中不應包含本人、父母、子女和配偶的姓名和出生日期、紀念日期、登錄名、E-mail地址等等與本人有關的信息，以及字典中的單詞。
（6）口令不應該為用數字或符號代替某些字母的單詞。
（7）口令應該易記且可以快速輸入，防止他人從你身後很容易看到你的輸入。
（8）至少90天內更換一次口令，防止未被發現的入侵者繼續使用該口令。
四、HTTP報頭追蹤漏洞
HTTP/1.1（RFC2616）規范定義了HTTP TRACE方法，主要是用於客戶端通過向Web伺服器提交TRACE請求來進行測試或獲得診斷信息。當Web伺服器啟用TRACE時，提交的請求頭會在伺服器響應的內容（Body）中完整的返回，其中HTTP頭很可能包括Session Token、Cookies或其它認證信息。攻擊者可以利用此漏洞來欺騙合法用戶並得到他們的私人信息。該漏洞往往與其它方式配合來進行有效攻擊，由於HTTP TRACE請求可以通過客戶瀏覽器腳本發起（如XMLHttpRequest），並可以通過DOM介面來訪問，因此很容易被攻擊者利用。
防禦HTTP報頭追蹤漏洞的方法通常禁用HTTP TRACE方法。
五、Struts2遠程命令執行漏洞
ApacheStruts是一款建立Java web應用程序的開放源代碼架構。Apache Struts存在一個輸入過濾錯誤，如果遇到轉換錯誤可被利用注入和執行任意Java代碼。
網站存在遠程代碼執行漏洞的大部分原因是由於網站採用了Apache Struts Xwork作為網站應用框架，由於該軟體存在遠程代碼執高危漏洞，導致網站面臨安全風險。CNVD處置過諸多此類漏洞，例如：「GPS車載衛星定位系統」網站存在遠程命令執行漏洞(CNVD-2012-13934)；Aspcms留言本遠程代碼執行漏洞（CNVD-2012-11590）等。
修復此類漏洞，只需到Apache官網升級Apache Struts到最新版本：http://struts.apache.org
六、文件上傳漏洞
文件上傳漏洞通常由於網頁代碼中的文件上傳路徑變數過濾不嚴造成的，如果文件上傳功能實現代碼沒有嚴格限制用戶上傳的文件後綴以及文件類型，攻擊者可通過 Web 訪問的目錄上傳任意文件，包括網站後門文件（webshell），進而遠程式控制制網站伺服器。
因此，在開發網站及應用程序過程中，需嚴格限制和校驗上傳的文件，禁止上傳惡意代碼的文件。同時限制相關目錄的執行許可權，防範webshell攻擊。
七、私有IP地址泄露漏洞
IP地址是網路用戶的重要標示，是攻擊者進行攻擊前需要了解的。獲取的方法較多，攻擊者也會因不同的網路情況採取不同的方法，如：在區域網內使用Ping指令，Ping對方在網路中的名稱而獲得IP；在Internet上使用IP版的QQ直接顯示。最有效的辦法是截獲並分析對方的網路數據包。攻擊者可以找到並直接通過軟體解析截獲後的數據包的IP包頭信息，再根據這些信息了解具體的IP。
針對最有效的「數據包分析方法」而言，就可以安裝能夠自動去掉發送數據包包頭IP信息的一些軟體。不過使用這些軟體有些缺點，譬如：耗費資源嚴重，降低計算機性能；訪問一些論壇或者網站時會受影響；不適合網吧用戶使用等等。現在的個人用戶採用最普及隱藏IP的方法應該是使用代理，由於使用代理伺服器後，「轉址服務」會對發送出去的數據包有所修改，致使「數據包分析」的方法失效。一些容易泄漏用戶IP的網路軟體(QQ、MSN、IE等)都支持使用代理方式連接Internet，特別是QQ使用「ezProxy」等代理軟體連接後，IP版的QQ都無法顯示該IP地址。雖然代理可以有效地隱藏用戶IP，但攻擊者亦可以繞過代理，查找到對方的真實IP地址，用戶在何種情況下使用何種方法隱藏IP，也要因情況而論。
八、未加密登錄請求
由於Web配置不安全，登陸請求把諸如用戶名和密碼等敏感欄位未加密進行傳輸，攻擊者可以竊聽網路以劫獲這些敏感信息。建議進行例如SSH等的加密後再傳輸。
九、敏感信息泄露漏洞
SQL注入、XSS、目錄遍歷、弱口令等均可導致敏感信息泄露，攻擊者可以通過漏洞獲得敏感信息。針對不同成因，防禦方式不同
十、CSRF
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
Web應用是指採用B/S架構、通過HTTP/HTTPS協議提供服務的統稱。隨著互聯網的廣泛使用，Web應用已經融入到日常生活中的各個方面：網上購物、網路銀行應用、證券股票交易、政府行政審批等等。在這些Web訪問中，大多數應用不是靜態的網頁瀏覽，而是涉及到伺服器側的動態處理。此時，如果Java、PHP、ASP等程序語言的編程人員的安全意識不足，對程序參數輸入等檢查不嚴格等，會導致Web應用安全問題層出不窮。
本文根據當前Web應用的安全情況，列舉了Web應用程序常見的攻擊原理及危害，並給出如何避免遭受Web攻擊的建議。
Web應用漏洞原理
Web應用攻擊是攻擊者通過瀏覽器或攻擊工具，在URL或者其它輸入區域（如表單等），向Web伺服器發送特殊請求，從中發現Web應用程序存在的漏洞，從而進一步操縱和控制網站，查看、修改未授權的信息。
1.1 Web應用的漏洞分類
1、信息泄露漏洞
信息泄露漏洞是由於Web伺服器或應用程序沒有正確處理一些特殊請求，泄露Web伺服器的一些敏感信息，如用戶名、密碼、源代碼、伺服器信息、配置信息等。
造成信息泄露主要有以下三種原因：
–Web伺服器配置存在問題，導致一些系統文件或者配置文件暴露在互聯網中；
–Web伺服器本身存在漏洞，在瀏覽器中輸入一些特殊的字元，可以訪問未授權的文件或者動態腳本文件源碼；
–Web網站的程序編寫存在問題，對用戶提交請求沒有進行適當的過濾，直接使用用戶提交上來的數據。
2、目錄遍歷漏洞
目錄遍歷漏洞是攻擊者向Web伺服器發送請求，通過在URL中或在有特殊意義的目錄中附加「../」、或者附加「../」的一些變形（如「..\」或「..//」甚至其編碼），導致攻擊者能夠訪問未授權的目錄，以及在Web伺服器的根目錄以外執行命令。
3、命令執行漏洞
命令執行漏洞是通過URL發起請求，在Web伺服器端執行未授權的命令，獲取系統信息，篡改系統配置，控制整個系統，使系統癱瘓等。
命令執行漏洞主要有兩種情況：
–通過目錄遍歷漏洞，訪問系統文件夾，執行指定的系統命令；
–攻擊者提交特殊的字元或者命令，Web程序沒有進行檢測或者繞過Web應用程序過濾，把用戶提交的請求作為指令進行解析，導致執行任意命令。
4、文件包含漏洞
文件包含漏洞是由攻擊者向Web伺服器發送請求時，在URL添加非法參數，Web伺服器端程序變數過濾不嚴，把非法的文件名作為參數處理。這些非法的文件名可以是伺服器本地的某個文件，也可以是遠端的某個惡意文件。由於這種漏洞是由PHP變數過濾不嚴導致的，所以只有基於PHP開發的Web應用程序才有可能存在文件包含漏洞。
5、SQL注入漏洞
SQL注入漏洞是由於Web應用程序沒有對用戶輸入數據的合法性進行判斷，攻擊者通過Web頁面的輸入區域(如URL、表單等) ，用精心構造的SQL語句插入特殊字元和指令，通過和資料庫交互獲得私密信息或者篡改資料庫信息。SQL注入攻擊在Web攻擊中非常流行，攻擊者可以利用SQL注入漏洞獲得管理員許可權，在網頁上加掛木馬和各種惡意程序，盜取企業和用戶敏感信息。
6、跨站腳本漏洞
跨站腳本漏洞是因為Web應用程序時沒有對用戶提交的語句和變數進行過濾或限制，攻擊者通過Web頁面的輸入區域向資料庫或HTML頁面中提交惡意代碼，當用戶打開有惡意代碼的鏈接或頁面時，惡意代碼通過瀏覽器自動執行，從而達到攻擊的目的。跨站腳本漏洞危害很大，尤其是目前被廣泛使用的網路銀行，通過跨站腳本漏洞攻擊者可以冒充受害者訪問用戶重要賬戶，盜竊企業重要信息。
根據前期各個漏洞研究機構的調查顯示，SQL注入漏洞和跨站腳本漏洞的普遍程度排名前兩位，造成的危害也更加巨大。
1.2 SQL注入攻擊原理
SQL注入攻擊是通過構造巧妙的SQL語句，同網頁提交的內容結合起來進行注入攻擊。比較常用的手段有使用注釋符號、恆等式（如1＝1）、使用union語句進行聯合查詢、使用insert或update語句插入或修改數據等，此外還可以利用一些內置函數輔助攻擊。
通過SQL注入漏洞攻擊網站的步驟一般如下：
第一步：探測網站是否存在SQL注入漏洞。
第二步：探測後台資料庫的類型。
第三步：根據後台資料庫的類型，探測系統表的信息。
第四步：探測存在的表信息。
第五步：探測表中存在的列信息。
第六步：探測表中的數據信息。
1.3 跨站腳本攻擊原理
跨站腳本攻擊的目的是盜走客戶端敏感信息,冒充受害者訪問用戶的重要賬戶。跨站腳本攻擊主要有以下三種形式：
1、本地跨站腳本攻擊
B給A發送一個惡意構造的Web URL，A點擊查看了這個URL，並將該頁面保存到本地硬碟（或B構造的網頁中存在這樣的功能）。A在本地運行該網頁，網頁中嵌入的惡意腳本可以A電腦上執行A持有的許可權下的所有命令。
2、反射跨站腳本攻擊
A經常瀏覽某個網站，此網站為B所擁有。A使用用戶名/密碼登錄B網站，B網站存儲下A的敏感信息（如銀行帳戶信息等）。C發現B的站點包含反射跨站腳本漏洞，編寫一個利用漏洞的URL，域名為B網站，在URL後面嵌入了惡意腳本（如獲取A的cookie文件），並通過郵件或社會工程學等方式欺騙A訪問存在惡意的URL。當A使用C提供的URL訪問B網站時，由於B網站存在反射跨站腳本漏洞，嵌入到URL中的惡意腳本通過Web伺服器返回給A，並在A瀏覽器中執行，A的敏感信息在完全不知情的情況下將發送給了C。
3、持久跨站腳本攻擊
B擁有一個Web站點，該站點允許用戶發布和瀏覽已發布的信息。C注意到B的站點具有持久跨站腳本漏洞，C發布一個熱點信息，吸引用戶閱讀。A一旦瀏覽該信息，其會話cookies或者其它信息將被C盜走。持久性跨站腳本攻擊一般出現在論壇、留言簿等網頁，攻擊者通過留言，將攻擊數據寫入伺服器資料庫中，瀏覽該留言的用戶的信息都會被泄漏。
Web應用漏洞的防禦實現
對於以上常見的Web應用漏洞漏洞，可以從如下幾個方面入手進行防禦：
1)對 Web應用開發者而言
大部分Web應用常見漏洞，都是在Web應用開發中，開發者沒有對用戶輸入的參數進行檢測或者檢測不嚴格造成的。所以，Web應用開發者應該樹立很強的安全意識，開發中編寫安全代碼；對用戶提交的URL、查詢關鍵字、HTTP頭、POST數據等進行嚴格的檢測和限制，只接受一定長度范圍內、採用適當格式及編碼的字元，阻塞、過濾或者忽略其它的任何字元。通過編寫安全的Web應用代碼，可以消除絕大部分的Web應用安全問題。
2) 對Web網站管理員而言
作為負責網站日常維護管理工作Web管理員，應該及時跟蹤並安裝最新的、支撐Web網站運行的各種軟體的安全補丁，確保攻擊者無法通過軟體漏洞對網站進行攻擊。
除了軟體本身的漏洞外，Web伺服器、資料庫等不正確的配置也可能導致Web應用安全問題。Web網站管理員應該對網站各種軟體配置進行仔細檢測，降低安全問題的出現可能。
此外，Web管理員還應該定期審計Web伺服器日誌，檢測是否存在異常訪問，及早發現潛在的安全問題。
3）使用網路防攻擊設備
前兩種為事前預防方式，是比較理想化的情況。然而在現實中，Web應用系統的漏洞還是不可避免的存在：部分Web網站已經存在大量的安全漏洞，而Web開發者和網站管理員並沒有意識到或發現這些安全漏洞。由於Web應用是採用HTTP協議，普通的防火牆設備無法對Web類攻擊進行防禦，因此可以使用IPS入侵防禦設備來實現安全防護。
H3C IPS Web攻擊防禦
H3C IPS入侵防禦設備有一套完整的Web攻擊防禦框架，能夠及時發現各種已經暴露的和潛在的Web攻擊。下圖為對於Web攻擊的總體防禦框架。
圖1：Web攻擊防禦框架，參見：http://blog.csdn.net/moshenglv/article/details/53439579
H3C IPS採用基於特徵識別的方式識別並阻斷各種攻擊。IPS設備有一個完整的特徵庫，並可定期以手工與自動的方式對特徵庫進行升級。當網路流量進入IPS後，IPS首先對報文進行預處理，檢測報文是否正確，即滿足協議定義要求，沒有錯誤欄位；如果報文正確，則進入深度檢測引擎。該引擎是IPS檢測的核心模塊，對通過IPS設備的Web流量進行深層次的分析，並與IPS攻擊庫中的特徵進行匹配，檢測Web流量是否存在異常；如果發現流量匹配了攻擊特徵，IPS則阻斷網路流量並上報日誌；否則，網路流量順利通過。
此Web攻擊防禦框架有如下幾個特點：
1) 構造完整的Web攻擊檢測模型，准確識別各種Web攻擊
針對Web攻擊的特點，考慮到各種Web攻擊的原理和形態，在不同漏洞模型之上開發出通用的、層次化的Web攻擊檢測模型，並融合到特徵庫中。這些模型抽象出Web攻擊的一般形態，對主流的攻擊能夠准確識別，使得模型通用化。
2) 檢測方式靈活，可以准確識別變形的Web攻擊
在實際攻擊中，攻擊者為了逃避防攻擊設備的檢測，經常對Web攻擊進行變形，如採用URL編碼技術、修改參數等。H3C根據Web應用漏洞發生的原理、攻擊方式和攻擊目標，對攻擊特徵進行了擴展。即使攻擊者修改攻擊參數、格式、語句等內容，相同漏洞原理下各種變形的攻擊同樣能夠被有效阻斷。這使得IPS的防禦范圍擴大，防禦的靈活性也顯著增強，極大的減少了漏報情況的出現。
3) 確保對最新漏洞及技術的跟蹤，有效阻止最新的攻擊
隨著Web攻擊出現的頻率日益增高，其危害有逐步擴展的趨勢。這對IPS設備在防禦的深度和廣度上提出了更高的要求，不僅要能夠防禦已有的Web攻擊，更要有效的阻止最新出現的、未公布的攻擊。目前，H3C已經建立起一套完整的攻防試驗環境，可以及時發現潛在Web安全漏洞。同時還在繼續跟蹤最新的Web攻擊技術和工具，及時更新Web攻擊的特徵庫，第一時間發布最新的Web漏洞應對措施，確保用戶的網路不受到攻擊。
4) 保證正常業務的高效運行
檢測引擎是IPS整個設備運行的關鍵，該引擎使用了高效、准確的檢測演算法，對通過設備的流量進行深層次的分析，並通過和攻擊特徵進行匹配，檢測流量是否存在異常。如果流量沒有匹配到攻擊特徵，則允許流量通過，不會妨礙正常的網路業務，在准確防禦的同時保證了正常業務的高效運行。
結束語
互聯網和Web技術廣泛使用，使Web應用安全所面臨的挑戰日益嚴峻，Web系統時時刻刻都在遭受各種攻擊的威脅，在這種情況下，需要制定一個完整的Web攻擊防禦解決方案，通過安全的Web應用程序、Web伺服器軟體、Web防攻擊設備共同配合，確保整個網站的安全。任何一個簡單的漏洞、疏忽都會造成整個網站受到攻擊，造成巨大損失。此外 ，Web攻擊防禦是一個長期持續的工作，隨著Web技術的發展和更新，Web攻擊手段也不斷發展，針對這些最新的安全威脅，需要及時調整Web安全防護策略，確保Web攻擊防禦的主動性，使Web網站在一個安全的環境中為企業和客戶服務。
原文鏈接：