一種用於防止csrf攻擊的方法和設備的製作方法
2023-08-12 22:39:41 1
專利名稱：一種用於防止csrf攻擊的方法和設備的製作方法
技術領域：
本發明涉及網絡安全，更具體地，本發明涉及一種用於防止網絡攻擊的方法和設備。
背景技術：
隨著網際網路應用的越來越廣泛，網際網路安全問題成了人們日益關注的問題。在現有的多種威脅網絡安全的攻擊方法中，跨站請求偽造(CSRF)攻擊是一種挾制終端用戶在當前已登錄的Web應用程式上執行非本意的操作的攻擊方法。攻擊者只要藉助少許的社會工程詭計，例如通過電子郵件或者是聊天軟體發送的連結，攻擊者就能迫使一個Web應用程式的用戶去執行攻擊者選擇的操作。例如，如果用戶登錄網絡銀行去查看其存款餘額， 他沒有退出網絡銀行系統就去了自己喜歡的論壇，如果攻擊者在論壇中精心構造了一個惡意的連結並誘使該用戶點擊了該連結，那麼該用戶在網絡銀行帳戶中的資金就有可能被轉移到攻擊者指定的帳戶中。當CSRF針對普通用戶發動攻擊時，將對終端用戶的數據和操作指令構成嚴重的威脅；當受攻擊的終端用戶具有管理員帳戶的時候，CSRF攻擊將危及整個 Web應用程式，因而CSRF攻擊的危害性很大。針對CSRF攻擊，一種最安全的防止方法就是對現存的所有伺服器進行改造使其能夠防範CSRF攻擊。但這種做法明顯不切實際。針對現存的伺服器，現有技術中存在的一些其他的解決方案也都不能有效地防止CSRF攻擊。因此，需要一種方法和設備能夠有效地防止CSRF攻擊。
發明內容
本公開說明性實施例中認識到現有技術中不能有效地防止CSRF攻擊的問題，提出了一種在不修改現有伺服器的前提下能夠有效防止CSRF攻擊的方法和設備。根據本公開的一個實施例，提供了一種用於防止CSRF攻擊的設備，包括請求攔截模塊，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌生成模塊，用於生成令牌；響應生成模塊，用於生成對請求的響應；令牌插入模塊，用於將令牌插入到對請求的響應中；以及響應發送模塊，用於向客戶端瀏覽器發送插入了令牌的對請求的響應。根據本公開的一個實施例，提供了一種用於防止CSRF攻擊的設備，包括請求攔截模塊，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌讀取模塊，用於讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌；令牌驗證模塊，用於驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。根據本公開的一個實施例，提供了一種用於防止CSRF攻擊的方法，包括攔截客戶端瀏覽器向伺服器發送的請求；生成令牌；生成對請求的響應；將令牌插入到對請求的響應中；以及向客戶端瀏覽器發送插入了令牌的對請求的響應。根據本公開的一個實施例，提供了一種用於防止CSRF攻擊的方法，包括攔截客戶端瀏覽器向伺服器發送的請求；讀取客戶端瀏覽器向伺服器發送的請求中的令牌；驗證客戶端瀏覽器向伺服器發送的請求中的令牌是否有效。此外，本公開的實施例還提供了與上述方法對應的電腦程式產品。利用本公開實施例提供的上述一個或多個實施例，能夠在不修改現有伺服器的前提下，有效地防止CSRF攻擊。
本公開可以通過參考下文中結合附圖所給出的描述而得到更好的理解，其中在所有附圖中使用了相同或相似的附圖標記來表示相同或者相似的部件。所述附圖連同下面的詳細說明一起包含在本說明書中並且形成本說明書的一部分，而且用來進一步舉例說明本公開的優選實施例和解釋本公開的原理和優點。在附圖中圖1顯示了 CSRF攻擊的原理圖；圖2顯示了根據本公開的一個實施例的用於防止CSRF攻擊的方法200 ；圖3a顯示了根據本公開一個實施例的用於防止CSRF攻擊的方法300 ；圖北顯示了根據本公開一個實施例的用於防止CSRF攻擊的方法300可以包括的
一些可選步驟；圖4顯示了根據本公開實施例的信號流程。
具體實施例方式在下文中將結合附圖對本公開的示範性實施例進行描述。為了清楚和簡明起見， 在說明書中並未描述實際實施方式的所有特徵。然而，應該了解，在開發任何這種實際實施例的過程中必須做出很多特定於該實際實施方式的決定，以便實現開發人員的具體目標， 例如，符合與系統及業務相關的那些限制條件，並且這些限制條件可能會隨著實施方式的不同而有所改變。此外，還應該了解，雖然開發工作有可能是非常複雜和費時的，但對得益於本公開公開內容的本領域技術人員來說，這種開發工作僅僅是例行的任務。在此，還需要說明的一點是，為了避免因不必要的細節而模糊了本公開，在附圖中僅僅示出了與根據本公開的方案密切相關的裝置結構和/或處理步驟，而省略了與本公開關係不大的其他細節。為了更好地對本公開中技術方案的原理進行介紹，下面首先結合圖1介紹CSRF攻擊的原理。圖1示例性地顯示了 CSRF攻擊的原理。在圖1顯示的系統100中，用戶102通過其客戶端瀏覽器104訪問位於伺服器108端的Web應用110。通常情況下，伺服器108首先需要驗證用戶102的身份。驗證用戶102身份的方式有多種，一般通過提示用戶102輸入用於訪問Web應用110的認證信息來進行。用戶102接收到輸入提示後輸入用於訪問Web 應用110的認證信息並將包含認證信息的登陸請求發送到伺服器108。伺服器108通過驗證接收的登錄請求中包含的用戶102的認證信息來驗證用戶102是否為Web應用110的合法用戶。假設用戶102輸入了正確的認證信息，那麼伺服器108會認為該用戶102為Web 應用110的合法用戶。由於伺服器108是通過cookie來識別用戶102的，當用戶102成功進行身份驗證之後客戶端瀏覽器104就會得到一個識別用戶102身份的cookie，該cookie 包含用戶102的認證信息，用於標識用戶102的客戶端瀏覽器104與伺服器108的Web應用Iio之間會話。這裡我們以Web應用110為網上銀行，用戶102想要通過該網上銀行進行轉帳操作為例說明CSRF攻擊的過程。假設用戶102在該銀行具有帳戶UA，他想通過網上銀行將1000元轉入到另一個帳戶UA2上。正常情況下，用戶102通過其客戶端瀏覽器104 發送的請求應該是http://bank. example/withdraw ？ account = UA&amount = 1000&for = UA2假設攻擊者106在該銀行具有帳戶ATT，同時，他知道上下文中的URL可以進行轉帳操作。這時，攻擊者106通過在其擁有權限的某一頁面嵌入如下代碼src ='Tittp://bank, example/withdraw ？ account = UA&amount = 1000&for = ATT，，並通過廣告等方式誘使用戶102訪問具有上述嵌入代碼的頁面。如果用戶102訪問了具有上述嵌入代碼的頁面，上述嵌入代碼將被執行。即，用戶102的客戶端瀏覽器104 會將上述嵌入代碼中的URLhttp://bank. example/withdraw ？ account = UA&amount = 1000&for = ATT連同用戶102的客戶端瀏覽器104中用於標識用戶102的客戶端瀏覽器104和網上銀行之間會話的cookie —起發送給網上銀行。可以看出，該URL對應於將用戶102的帳戶UA中的1000元轉入到攻擊者106的帳戶ATT中的轉帳請求。通常情況下該請求會失敗， 因為網上銀行要求用戶102的認證信息。但是，如果用戶102的客戶端瀏覽器104中用於標識用戶102的客戶端瀏覽器104和網上銀行之間會話的cookie尚未過期，由於該cookie 中含有用戶102的認證信息，那麼網上銀行就會接收到包含用戶102的認證信息的將用戶 102的帳戶UA中的1000元轉入到攻擊者106的帳戶ATT中的轉帳請求。由於該請求中包含了用戶102的認證信息，網上銀行會將上述請求視為合法的請求進行處理，即將用戶102 的帳戶UA中的1000元轉到了攻擊者106的帳戶ATT中。上面簡要描述了 CSRF攻擊的原理。下面將繼續結合上面的例子詳細介紹根據本公開的實施例用於防止CSRF攻擊的方法和設備。下面的描述均是示例性描述，在本公開中描述內容的基礎上，所屬領域技術人員可以通過增加、減少、組合、修改等方式得到在本公開構思所覆蓋範圍內的其他可能的實施方式，所有這些都將落入本公開的保護範圍內。本公開引入一個用於攔截客戶端瀏覽器向伺服器發送的請求的設備，該設備向客戶端瀏覽器發送的請求中添加令牌。隨後，該設備會對客戶端瀏覽器發送的每一個請求進行驗證以確定每一個請求是否安全。下面參見圖2，其中顯示了根據本公開一個實施例的用於防止CSRF攻擊的設備 200的設備，包括請求攔截模塊202，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌生成模塊204，用於生成令牌；響應生成模塊206，用於生成對請求的響應；令牌插入模塊208，用於將令牌插入到對請求的響應中；以及響應發送模塊210，用於向客戶端瀏覽器發送插入了令牌的對請求的響應。其中，對請求的響應可以是HTTP 307響應。此外，根據本公開一個實施例的用於防止CSRF攻擊的設備200還可以包括令牌讀取模塊212，用於讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌；令牌驗證模塊214，用於驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌驗證模塊214驗證其令牌有效，則由響應生成模塊206生成對後續請求的響應；由令牌插入模塊208將令牌插入到對後續請求的響應中；以及由響應發送模塊210向客戶端瀏覽器發送插入了令牌的對後續請求的響應。此外，根據本公開一個實施例的用於防止CSRF攻擊的設備200還可以包括請求轉發模塊216，用於將客戶端瀏覽器向伺服器發送的後續請求轉發到伺服器。如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且令牌驗證模塊214驗證其令牌有效，則由請求轉發模塊216將後續請求轉發到伺服器。此外，根據本公開一個實施例的用於防止CSRF攻擊的設備200還可以包括請求判斷模塊218，用於判斷客戶端瀏覽器向伺服器發送的後續請求是否為Ajax請求。如果請求判斷模塊218確定客戶端瀏覽器向伺服器發送的後續請求是Ajax請求，並且請求的URL 中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊214驗證其令牌有效，則由請求轉發模塊216將後續請求轉發到伺服器。如果請求判斷模塊218確定客戶端瀏覽器向伺服器發送的後續請求是非Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊214驗證其令牌有效，則由響應生成模塊206生成對後續請求的響應；由令牌插入模塊208將令牌插入到對後續請求的響應中；以及由響應發送模塊210向客戶端瀏覽器發送插入了令牌的對後續請求的響應。申請人:強調，儘管圖2中顯示的用於防止CSRF攻擊的設備200包括多個模塊，但並不是每個模塊都是必須的，可以根據設計的需要增加或減少一些模塊。例如，用於防止 CSRF攻擊的設備200可以僅包含實線顯示的那些模塊。下面參見圖3a，其中顯示了根據本公開一個實施例的用於防止CSRF攻擊的方法 300。圖3a的方法300從步驟302開始。接下來，方法300進入步驟304，其中攔截客戶端瀏覽器向伺服器發送的請求。可以通過如圖2所示的設備200中的請求攔截模塊202對請求進行攔截，請求攔截模塊202可以例如利用Java Servlet實現。可以採用現有的任意方式的對請求進行攔截的方法來達到上述目的，這裡不再贅述。接下來，方法300進入步驟306，其中生成令牌，該令牌用於插入到要向客戶端瀏覽器返回的響應中。令牌的生成可以利用現有技術中的算法和手段，例如利用UUID或隨機算法。接下來，方法300進入步驟308，其中生成針對攔截的客戶端瀏覽器向伺服器發送的請求的響應。根據本公開的一個實施例，該響應為HTTP307響應。HTTP 307響應是遵循 HTTP 1. 1協議的用於重定向的響應，能夠將客戶端瀏覽器發送的HTTP請求(包括HTTP GET 和HTTP POST)重定向到預先設置的位置。接下來，方法300進入步驟310，其中將生成的令牌插入到生成的針對攔截的客戶端瀏覽器向伺服器發送的請求的響應中。這時，向客戶端瀏覽器返回的響應中包含了在步驟306中生成的令牌。接下來，方法300進入步驟312，結束。或者可選地，方法300還可以進入圖3b。現在參見圖北，其中顯示了根據本公開一個實施例的用於防止CSRF攻擊的方法
8300可以包括的一些可選步驟。接圖3a，根據本公開一個實施例的用於防止CSRF攻擊的方法300還可以包括步驟 314，其中攔截客戶端瀏覽器向伺服器發送的後續請求。這裡，後續請求對應於執行如圖3a 顯示的方法，客戶端瀏覽器接收了設備200返回的響應之後發送的請求。由於設備200向客戶端瀏覽器返回的響應中被插入了令牌，因此，客戶端瀏覽器隨後向伺服器發出的後續請求中也會包含該令牌。接下來，方法300進入步驟316，其中讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌。接下來，方法300進入步驟318，其中驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。之後，方法300進入步驟320，其中通過比較讀取的客戶端瀏覽器向伺服器發送的後續請求中的令牌與設備200中記錄的其向客戶端瀏覽器返回的響應中插入的令牌是否相同來確定客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。如果兩者不同，方法300進入步驟322，認為該請求無效。之後方法300返回步驟314，繼續攔截客戶端瀏覽器向伺服器發送的後續請求。如果兩者相同，方法300進入步驟324，其中進一步驗證客戶端瀏覽器向伺服器發送的後續請求中請求的URL中是否存在令牌。如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且有效，方法300進入步驟326， 其中將後續請求轉發到伺服器。由於攻擊者無法知道令牌的值，因此請求的URL中存在有效的令牌將說明該請求是安全的，因而可以將其轉發到伺服器進行處理。如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中不存在令牌，則進一步驗證客戶端瀏覽器向伺服器發送的後續請求中的Referer頭域中是否存在令牌以及令牌是否有效。Referer頭域是HTTP協議中定義的HTTP頭中的欄位，允許客戶端指定請求 URL的源資源地址，這可以允許伺服器生成回退鍊表。例如，用戶通過點擊IBM的主頁(ymi ibm. com)中的連結訪問IBM技術支持頁面(誦.ibm. com/support)，那麼客戶端瀏覽器發送的訪問IBM技術支持頁面的請求中的Referer頭域中將包含IBM的主頁的地址。例如， 該請求可能為GET http//www, ibm. com/support…Referer http //www, ibm. com…如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中不存在令牌，而 Referer頭域中存在令牌並且有效，方法300進入步驟328，其中生成對後續請求的響應；之後在步驟330，將令牌插入到對後續請求的響應中，並在步驟332，向客戶端瀏覽器發送插入了令牌的對後續請求的響應。可選地，如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且有效，方法300還可以進入步驟334，其中判斷客戶端瀏覽器向伺服器發送的後續請求是否為Ajax請求，如果是Ajax請求，方法300進入步驟326， 其中將後續請求轉發到伺服器。如果不是Ajax請求，方法300進入步驟328，其中生成對後續請求的響應；之後在步驟330，將令牌插入到對後續請求的響應中，並在步驟332，向客戶端瀏覽器發送插入了令牌的對後續請求的響應。由於Ajax請求的特點，在已經驗證了令牌的有效性的前提下，可以認為該請求是安全的，因而可以將其轉發到伺服器進行處理。下面參見圖4，其中顯示了根據本公開實施例的信號流程。申請人強調，圖4隻是為了說明的目的，不能認為是對本公開保護範圍的限制。圖4中假設用戶通過他的客戶端瀏覽器請求訪問受保護的資源URL 1，如402所示。該請求發送到伺服器的認證模塊，認證模塊提示用戶輸入認證信息，如404所示。然後，用戶提供認證信息，如406所示。接下來， 伺服器驗證模塊驗證用戶提供的認證信息。如果認證信息正確，伺服器驗證模塊將請求向 URL 1轉發，如408所示。現有技術中，當伺服器驗證模塊驗證用戶的認證信息正確之後請求會被直接轉發至伺服器中的Web應用。根據本公開的一個或多個實施例，設備200攔截該請求(這裡是伺服器認證模塊轉發的訪問的請求)。之後，設備200中的令牌生成模塊生成令牌XXX (如410中所示的Token = XXX)，將令牌XXX插入到向客戶端瀏覽器返回的響應中，如410所示。根據本公開的一個實施例，設備200向客戶端瀏覽器返回HTTP 307響應，將請求重定向至。該響應典型地如下所示HTTP 307 Temporary RedirectLocation: ？ Token = XXX可見，該響應中插入了令牌XXX，該令牌被加插入到用戶將再次請求的URL 1中， 艮口 ？ Token = XXX，如 412 所示。客戶端瀏覽器接收到插入了令牌XXX的響應之後，請求訪問響應中指定的地址 ，這時的請求典型地如下所示GEIXURL 1> ？ Token = XXX可見，該請求的URL中也插入了令牌XXX，即 ？ iToken = XXX，如414所示。 這時，設備200再次攔截該請求，並驗證該請求中請求的URL中是否存在令牌並且令牌是否有效。如果請求的URL中存在令牌並且令牌有效，即請求的為 ？ Token = XXX，而 Token = XXX，設備200將該請求轉發至伺服器的Web應用，如416所示。Web應用接收到請求後對其進行響應，向客戶端瀏覽器返回請求的資源，如418所示。這時，返回的資源對應的頁面的地址中也插入了令牌XXX，即返回的頁面對應的地址是 ？ Token = XXX。假設用戶在資源對應的頁面內通過點擊連結請求訪問資源。根據HTTP協議，這時的請求中會具有Referer頭域，以表明訪問資源的來源。這時， 由於資源對應的頁面的地址中已經插入了令牌XXX，即 ？ Token = XXX， 典型的請求將如下所示GEIXURL 2>…Referer: ？ Token = XXX…S卩，該請求中也插入了令牌XXX，該令牌位於Referer頭域，如420所示。根據本公開的一個或多個實施例，設備200再次攔截該請求(這裡是客戶端瀏覽器發送的通過訪問的請求)，並驗證該請求中請求的URL中是否存在令牌以及令牌是否有效，如422所示。如果請求的URL (這裡是URL 2)中不存在令牌而Referer 頭域中存在令牌並且令牌有效，即Referer : ？ Token = XXX，並且Token = XXX，設備200再次將令牌XXX插入到向客戶端瀏覽器返回的響應中，如4 所示。根據本公開的一個實施例，設備200向客戶端瀏覽器返回HTTP 307響應，將請求重定向至，並再次插入令牌XXX。該響應典型地如下所示HTTP 307 Temporary RedirectLocation: ？ Token = XXX可見，該響應中也插入了令牌XXX，該令牌被插入到用戶將再次請求的URL 2中， 即 ？ Token = XXX，如 424 所示。客戶端瀏覽器接收到插入了令牌的上述響應之後，請求訪問響應中指定的地址 ，這時的請求典型地如下所示GEIXURL 2> ？ Token = XXX可見，該請求中請求的URL中也插入了令牌XXX，如似6所示。這時，設備200再次攔截該請求，並驗證該請求中請求的URL中是否存在令牌以及令牌是否有效。如果請求的 URL中存在令牌並且令牌有效，即請求的為 ？ Token = XXX，而Token = XXX，設備 200將該請求轉發至伺服器的Web應用，如4 所示。Web應用接收到請求後對其進行響應， 向客戶端瀏覽器返回請求的資源，如430所示。這時，返回的資源對應的頁面的地址中也插入了令牌XXX,即 ？ Token = XXX。下面簡要描述一下根據本公開的一些其他實施方式。根據本公開的一個實施例， 用於防止CSRF攻擊的設備，包括請求攔截模塊，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌讀取模塊，用於讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌；令牌驗證模塊，用於驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。可選地，用於防止CSRF攻擊的設備進一步包括請求轉發模塊，用於將客戶端瀏覽器向伺服器發送的請求轉發到伺服器。其中如果客戶端瀏覽器向伺服器發送的請求中請求的URL中存在令牌並且令牌驗證模塊驗證其令牌有效，則由請求轉發模塊將後續請求轉發到伺服器。可選地，用於防止CSRF攻擊的設備進一步包括響應生成模塊，用於生成對請求的響應；令牌插入模塊，用於將令牌插入到對請求的響應中；以及響應發送模塊，用於向客戶端瀏覽器發送插入了令牌的對請求的響應。其中如果客戶端瀏覽器向伺服器發送的請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效，則由響應生成模塊生成對請求的響應；由令牌插入模塊將令牌插入到對請求的響應中；由響應發送模塊向客戶端瀏覽器發送插入了令牌的對請求的響應。可選地，用於防止CSRF攻擊的設備進一步包括請求判斷模塊，用於判斷客戶端瀏覽器向伺服器發送的請求是否為Ajax請求。其中如果請求判斷模塊確定客戶端瀏覽器向伺服器發送的請求是Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效，則由請求轉發模塊將請求轉發到伺服器。其中如果請求判斷模塊確定客戶端瀏覽器向伺服器發送的請求是非Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效，則由響應生成模塊生成對請求的響應；由令牌插入模塊將令牌插入到對請求的響應中；由響應發送模塊向客戶端瀏覽器發送插入了令牌的對請求的響應。根據本公開的一個實施例，用於防止CSRF攻擊的方法，包括攔截客戶端瀏覽器向伺服器發送的請求；讀取客戶端瀏覽器向伺服器發送的請求中的令牌；驗證客戶端瀏覽器向伺服器發送的請求中的令牌是否有效。可選地，用於防止CSRF攻擊的方法進一步包括如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且令牌有效，則將後續請求轉發到伺服器。可選地，用於防止CSRF攻擊的方法進一步包括如果客戶端瀏覽器向伺服器發送的請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌有效，則生成對請求的響應；將令牌插入到對請求的響應中；向客戶端瀏覽器發送插入了令牌的對請求的響應。可選地，用於防止CSRF攻擊的方法進一步包括判斷客戶端瀏覽器向伺服器發送的請求是否為Ajax請求。其中如果客戶端瀏覽器向伺服器發送的請求是Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌有效，則將請求轉發到伺服器。其中如果客戶端瀏覽器向伺服器發送的請求是非Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌有效，則生成對請求的響應；將令牌插入到對請求的響應中；向客戶端瀏覽器發送插入了令牌的對請求的響應。通過以上示例性的描述可以看出，利用本公開的方法和設備，在用戶通過客戶端瀏覽器訪問資源的請求中被插入了令牌，因而設備200能夠通過驗證請求中令牌是否有效來確保請求是由用戶本人發出的，從而防止了 CSRF攻擊。以上結合具體實施例描述了本公開的基本原理，但是，需要指出的是，對本領域的普通技術人員而言，能夠理解本公開的方法和裝置的全部或者任何步驟或者部件，可以在任何計算裝置(包括處理器、存儲介質等)或者計算裝置的網絡中，以硬體、固件、軟體或者它們的組合加以實現，這是本領域普通技術人員在閱讀了本公開的說明的情況下運用他們的基本編程技能就能實現的。因此，本公開的目的還可以通過在任何計算裝置上運行一個程序或者一組程序來實現。所述計算裝置可以是公知的通用裝置。因此，本公開的目的也可以僅僅通過提供包含實現所述方法或者裝置的程序代碼的程序產品來實現。也就是說，這樣的程序產品也構成本公開，並且存儲有這樣的程序產品的存儲介質也構成本公開。顯然，所述存儲介質可以是任何公知的存儲介質或者將來所開發出來的任何存儲介質。還需要指出的是，在本公開的裝置和方法中，顯然，各部件或各步驟是可以分解和 /或重新組合的。這些分解和/或重新組合應視為本公開的等效方案。並且，執行上述系列處理的步驟可以自然地按照說明的順序按時間順序執行，但是並不需要一定按照時間順序執行。某些步驟可以並行或彼此獨立地執行。雖然已經詳細說明了本公開及其優點，但是應當理解在不脫離由所附的權利要求所限定的本公開的精神和範圍的情況下可以進行各種改變、替代和變換。而且，本申請的術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素， 或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，
由語句「包括一個......」限定的要素，並不排除在包括所述要素的過程、方法、物品或者裝
置中還存在另外的相同要素。
權利要求
1.一種用於防止CSRF攻擊的設備，包括請求攔截模塊，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌生成模塊，用於生成令牌；響應生成模塊，用於生成對請求的響應；令牌插入模塊，用於將令牌插入到對請求的響應中；以及響應發送模塊，用於向客戶端瀏覽器發送插入了令牌的對請求的響應。
2.根據權利要求1的設備，其中 所述響應是HTTP 307響應。
3.根據權利要求1或2的設備，進一步包括由請求攔截模塊攔截客戶端瀏覽器向伺服器發送的後續請求；令牌讀取模塊，用於讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌；令牌驗證模塊，用於驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。
4.根據權利要求3的設備，進一步包括請求轉發模塊，用於將客戶端瀏覽器向伺服器發送的後續請求轉發到伺服器。
5.根據權利要求4的設備，其中如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且令牌驗證模塊驗證其令牌有效，則由請求轉發模塊將後續請求轉發到伺服器。
6.根據權利要求3的設備，其中如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中不存在令牌，而Referer 頭域中存在令牌並且令牌驗證模塊驗證其令牌有效，則 由響應生成模塊生成對後續請求的響應； 由令牌插入模塊將令牌插入到對後續請求的響應中； 由響應發送模塊向客戶端瀏覽器發送插入了令牌的對後續請求的響應。
7.根據權利要求3的設備，進一步包括請求判斷模塊，用於判斷客戶端瀏覽器向伺服器發送的後續請求是否為Ajax請求。
8.根據權利要求7的設備，其中如果請求判斷模塊確定客戶端瀏覽器向伺服器發送的後續請求是Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效， 則由請求轉發模塊將後續請求轉發到伺服器。
9.根據權利要求7的設備，其中如果請求判斷模塊確定客戶端瀏覽器向伺服器發送的後續請求是非Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效， 則由響應生成模塊生成對後續請求的響應；由令牌插入模塊將令牌插入到對後續請求的響應中；由響應發送模塊向客戶端瀏覽器發送插入了令牌的對後續請求的響應。
10.一種用於防止CSRF攻擊的方法，包括攔截客戶端瀏覽器向伺服器發送的請求；生成令牌；生成對請求的響應；將令牌插入到對請求的響應中；以及向客戶端瀏覽器發送插入了令牌的對請求的響應。
11.根據權利要求10的方法，其中 所述響應是HTTP 307響應。
12.根據權利要求10或11的方法，進一步包括 攔截客戶端瀏覽器向伺服器發送的後續請求；讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌； 驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。
13.根據權利要求12的方法，進一步包括如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且令牌有效，則將後續請求轉發到伺服器。
14.根據權利要求12的方法，進一步包括如果客戶端瀏覽器向伺服器發送的請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌有效，則 生成對後續請求的響應； 將令牌插入到對後續請求的響應中； 向客戶端瀏覽器發送插入了令牌的對後續請求的響應。
15.根據權利要求12的方法，進一步包括判斷客戶端瀏覽器向伺服器發送的後續請求是否為Ajax請求。
16.根據權利要求15的方法，其中如果客戶端瀏覽器向伺服器發送的後續請求是Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌有效，則 將後續請求轉發到伺服器。
17.根據權利要求15的方法，其中如果客戶端瀏覽器向伺服器發送的後續請求是非Ajax請求，並且請求的URL中不存在令牌而Referer頭域中存在令牌並且令牌有效，則 生成對後續請求的響應； 將令牌插入到對後續請求的響應中； 向客戶端瀏覽器發送插入了令牌的對後續請求的響應。
18.一種用於防止CSRF攻擊的設備，包括請求攔截模塊，用於攔截客戶端瀏覽器向伺服器發送的請求；令牌讀取模塊，用於讀取客戶端瀏覽器向伺服器發送的後續請求中的令牌；令牌驗證模塊，用於驗證客戶端瀏覽器向伺服器發送的後續請求中的令牌是否有效。
19.根據權利要求18的設備，進一步包括請求轉發模塊，用於將客戶端瀏覽器向伺服器發送的請求轉發到伺服器。
20.根據權利要求19的設備，其中如果客戶端瀏覽器向伺服器發送的請求中請求的URL中存在令牌並且令牌驗證模塊驗證其令牌有效，則由請求轉發模塊將後續請求轉發到伺服器。
21.根據權利要求18的設備，進一步包括 響應生成模塊，用於生成對請求的響應；令牌插入模塊，用於將令牌插入到對請求的響應中；以及響應發送模塊，用於向客戶端瀏覽器發送插入了令牌的對請求的響應。
22.根據權利要求21的設備，其中如果客戶端瀏覽器向伺服器發送的請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌驗證模塊驗證其令牌有效，則 由響應生成模塊生成對請求的響應； 由令牌插入模塊將令牌插入到對請求的響應中； 由響應發送模塊向客戶端瀏覽器發送插入了令牌的對請求的響應。
23.一種用於防止CSRF攻擊的方法，包括 攔截客戶端瀏覽器向伺服器發送的請求； 讀取客戶端瀏覽器向伺服器發送的請求中的令牌；驗證客戶端瀏覽器向伺服器發送的請求中的令牌是否有效。
24.根據權利要求23的方法，進一步包括如果客戶端瀏覽器向伺服器發送的後續請求中請求的URL中存在令牌並且令牌有效，則將後續請求轉發到伺服器。
25.根據權利要求23的方法，進一步包括如果客戶端瀏覽器向伺服器發送的請求中請求的URL中不存在令牌，而Referer頭域中存在令牌並且令牌有效，則 生成對請求的響應； 將令牌插入到對請求的響應中； 向客戶端瀏覽器發送插入了令牌的對請求的響應。
全文摘要
本公開提供了一種用於防止CSRF攻擊的設備和方法，其中方法包括攔截客戶端瀏覽器向伺服器發送的請求；生成令牌；生成對請求的響應；將令牌插入到對請求的響應中；以及向客戶端瀏覽器發送插入了令牌的對請求的響應。通過本公開的設備和方法，確保用戶通過客戶端瀏覽器訪問資源的請求中都被插入了令牌，通過驗證請求中令牌是否有效來確保請求是由用戶本人發出的，從而防止了CSRF攻擊。
文檔編號H04L29/06GK102480490SQ20101058035
公開日2012年5月30日 申請日期2010年11月30日 優先權日2010年11月30日
發明者D·S·梅利克謝申, 牛剛, 童強國 申請人:國際商業機器公司