安裝mod_csrfprotector　抵禦CSRF攻擊

換個角度來思考，當使用者端發出Request時，網站伺服器就偷偷放一個小檔案（這類的檔案即稱為Cookies）到使用者端的瀏覽器中，而後當使用者端再發出Request時，網站伺服器即可透過讀取Cookies檔案中的內容來得知相關資訊，以彌補HTTP通訊協定無法記憶的問題。

就以上述的財經網站為例，當第一次使用該網站時，如果有查詢個股的資訊，就會將該資訊以Cookies檔案的形式存到使用者的瀏覽器裡，並在下次又重新拜訪該網站時，取出Cookies檔案且依據內容來顯示適當的網頁內容。

當然，Cookies的內容不能永遠都是有效的，還是要設定過期（Timeout）的時間。依過期的時間來區分，Cookies可分為下列的類型：

‧非持久（non-persist）：如果沒有設置過期時間，則表示Cookies的生命週期為瀏覽器會話（Session）期間，即表示當關閉瀏覽器時，此Cookies即過期而失效。此種Cookies又被稱為會話Cookies。

‧持久（persist）Cookie：相對於非持久Cookies，此類的Cookies會保存在硬碟上並設定過期時間，就算使用者關閉瀏覽器，只要未超過過期時間，此類的Cookies仍然是屬於有效。

不可否認地，使用Cookies可相當程度地解決HTTP無法記憶的問題，但Cookies畢竟是置放在使用者端的電腦上，雖然在實務上會以加密的方式來確保Cookies檔案內容的安全，但還是會有一定的安全隱憂。

另一方面，Cookies檔案也會有儲存容量的限制，無法儲存較為複雜的資訊。因此對於一些高敏感的操作（例如使用者身分的鑑別），還是會以Session的方式來實作。相對於Cookies，Session資訊將儲存在伺服器端，並以SessionID（此值為獨一無二的數值）當成索引，來取得伺服器端所儲存的Session資訊內容。

通常Session會與Cookies一起運用，當使用者在伺服器端建立了相關的Session空間後，就會將SessionID儲存在Request Header中的Cookie欄位。在之後的連線中，Cookie欄位將SessionID資訊傳遞至伺服器，伺服器即會取得SessionID的資訊，並利用此SessionID來檢索Session內的資訊。圖3所示，即為利用Cookie欄位將SessionID資訊傳遞至伺服器。

▲圖3 利用Cookie欄位將SessionID資訊傳遞至伺服器。

由於使用者可在瀏覽器設定中手動設定禁用Cookie功能，在禁用Cookie的情況下，必須另外使用其他的機制來傳遞SessionID的資訊，最常用的機制即是URL重寫（URL Rewriting），把SessionID直接附加在URL路徑的後面再傳遞至伺服器上，所以有時候可能看到類似下列的URL類型，其中sessionid後面所附加的參數即為SessionID的資訊：

http://www.example.com/index.php?sessionid=EDvFNggimeF1492327933EuserFA21388625424A2E

通常為了增進Session的存取效率，伺服器會以記憶體來儲存Session的資訊，因此，如果有大量的使用者連線，可能會產生大量的Session而導致記憶體耗盡的問題。因此，除了以記憶體來儲存外，另外也可利用相關的快取（Cache）機制（例如memcache或redis）來儲存Session的資訊。

當伺服器建立Session後，只要使用者繼續再使用網站，伺服器就會持續地更新Session的最後存取時間，並保持該Session。除非使用者長時間未動作並超過Session所設定的過期期限（Timeout）或使用者登出該網站，才會結束該Session。

本文所說明CSRF攻擊，即是利用Session這個特點，當受害者登入網站後，就產生一個認證用的Session，並利用使用者所送出的Request Header中的Cookie欄位來傳遞SessionID提供給伺服器來取得認證Session的內容，以提供認證身分的用途。

惡意的外部攻擊者便是利用當受害者還在使用網站（此時認證Session依然有效時），透過如社交工程等的手法，騙得受害者的認證Cookie值（即SessionID），此時外部攻擊者即可利用此Cookie值來取得受害者的認證Session，進而假冒受害者的身分。

什麼是CSRF攻擊

在此以一個實例來說明CSRF攻擊手法，圖4所示為一個常見的登入認證流程。

▲圖4 常見的登入認證流程。

當使用者輸入正確的帳號密碼後，就會在網站伺服器上新建一個認證身分用的Session（如圖4的?，以下簡稱為認證Session）空間，並將相關的認證資訊儲存至認證Session（例如使用者的身分等資訊），之後管理者的操作，均會發出內含認證Session的SessionID資訊（儲存在Request Header中的Cookie欄位）的Request要求網站伺服器服務。

當網站伺服器取得Request封包後，便會利用該Request Header中Cookie欄位內的SessionID資訊，取得儲存在伺服器上認證Session的內容來確認是否為合法的使用者，如果無法取得正確的認證Session資訊，即表示發出該Request的使用者並不是一個合法的管理者。

因此，可想像一個情境，倘若一個合法的管理者在登入的狀態，此時該認證Session仍屬有效的情況下，如果外部的攻擊者利用如社交工程的手法搭配XSS（Cross-site Scripting）攻擊手法，就可能取得管理者認證所需要的Cookie值，取得此Cookie值後，即可用來發送Request封包。

如此一來，當網站伺服器在取得此Request封包後，並利用其中的Cookie值，就能夠取得管理者的認證Session。因此，網站伺服器便會認定此Request為合法管理者所發出，而達到攻擊者假冒管理者的目的，此即為CSRF攻擊的基本原理。

降低CSRF威脅

在了解CSRF基本攻擊原理後，可從使用者端和伺服器端的角度來討論如何降低CSRF的威脅。

使用者端

由於CSRF是利用取得網站伺服器端的有效認證Session資訊，因此使用者在使用網站系統後，就應注意要即時地登出來刪除認證Session，以便降低被用來實施CSRF攻擊的機會。