CSRF & CORS

下面轉的兩篇文章分別說明了如下兩個概念和一些解決方法：

1. CSRF - Cross-Site Request Forgery - 跨站請求僞造

2. CORS - Cross Origin Resourse-Sharing - 跨站資源共享

（1. CSRF）轉自：http://www.h3c.com.cn/About_H3C/Company_Publication/IP_Lh/2012/04/Home/Catalog/201208/751467_30008_0.htm

從下面文章中能夠知道爲何要設置csrf_token，以及爲何一些網站把csrf_token放入header或url。

1      CSRF漏洞簡介

CSRF（Cross-Site Request Forgery，跨站點僞造請求）是一種網絡攻擊方式，該攻擊能夠在受害者絕不知情的狀況下以受害者名義僞造請求發送給受攻擊站點，從而在未受權的狀況下執行在權限保護之下的操做，具備很大的危害性。具體來說，能夠這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來講這個請求是徹底合法的，可是卻完成了攻擊者所指望的一個操做，好比以你的名義發送郵件、發消息，盜取你的帳號，添加系統管理員，甚至於購買商品、虛擬貨幣轉帳等。

CSRF攻擊方式並不爲你們所熟知，實際上不少網站都存在CSRF的安全漏洞。早在2000年，CSRF這種攻擊方式已經由國外的安全人員提出，但在國內，直到2006年纔開始被關注。2008年，國內外多個大型社區和交互網站前後爆出CSRF漏洞，如：百度HI、NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站）和YouTube等。但直到如今，互聯網上的許多站點仍對此毫無防備，以致於安全業界稱CSRF爲「沉睡的巨人」，其威脅程度由此「美譽」即可見一斑。

2      CSRF攻擊原理及實例

CSRF攻擊原理

CSRF攻擊原理比較簡單，如圖1所示。其中Web A爲存在CSRF漏洞的網站，Web B爲攻擊者構建的惡意網站，User C爲Web A網站的合法用戶。

 

圖1 CSRF攻擊原理

1. 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A；

2.在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A；

3. 用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

4. 網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問第三方站點A；

5. 瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

CSRF攻擊分類

CSRF漏洞通常分爲站外和站內兩種類型。

CSRF站外類型的漏洞本質上就是傳統意義上的外部提交數據問題。一般程序員會考慮給一些留言或者評論的表單加上水印以防止SPAM問題（這裏，SPAM能夠簡單的理解爲垃圾留言、垃圾評論，或者是帶有站外連接的惡意回覆），可是有時爲了提升用戶的體驗性，可能沒有對一些操做作任何限制，因此攻擊者能夠事先預測並設置請求的參數，在站外的Web頁面裏編寫腳本僞造文件請求，或者和自動提交的表單一塊兒使用來實現GET、POST請求，當用戶在會話狀態下點擊連接訪問站外Web頁面，客戶端就被強迫發起請求。

CSRF站內類型的漏洞在必定程度上是因爲程序員濫用$_REQUEST類變量形成的。在一些敏感的操做中（如修改密碼、添加用戶等），原本要求用戶從表單提交發起POST請求傳遞參數給程序，可是因爲使用了$_REQUEST等變量，程序除支持接收POST請求傳遞的參數外也支持接收GET請求傳遞的參數，這樣就會爲攻擊者使用CSRF攻擊創造條件。通常攻擊者只要把預測的請求參數放在站內一個貼子或者留言的圖片連接裏，受害者瀏覽了這樣的頁面就會被強迫發起這些請求。

CSRF攻擊實例

下面以Axous 1.1.1 CSRF Add Admin Vulnerability（漏洞CVE編號：CVE-2012-2629）爲例，介紹CSRF攻擊具體實施過程。

Axous是一款網上商店應用軟件。Axous 1.1.1以及更低版本在實現上存在一個CSRF漏洞，遠程攻擊者能夠經過構造特製的網頁，誘使該軟件管理員訪問，成功利用此漏洞的攻擊者能夠添加系統管理員。利用此漏洞主要包含如下三個過程：

1. 攻擊者構造惡意網頁。在實施攻擊前，攻擊者須要構造一個與正常添加管理員用戶基本同樣的網頁，在該惡意網頁中對必要的參數項進行賦值，並將該網頁的action指向正常添加管理員用戶時訪問的URL，核心代碼如圖2所示；

2. 攻擊者利用社會工程學誘使Axous系統管理員訪問其構造的惡意網頁；

3. 執行惡意代碼。當系統管理員訪問惡意網頁時，惡意代碼在管理員不知情的狀況下以系統管理員的合法權限被執行，攻擊者僞造的管理員帳戶添加成功。

 

圖2 CSRF攻擊添加管理員核心代碼

3      CSRF 漏洞檢測

檢測CSRF漏洞是一項比較繁瑣的工做，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段後再從新提交，若是該提交還有效，那麼基本上能夠肯定存在CSRF漏洞。

隨着對CSRF漏洞研究的不斷深刻，不斷涌現出一些專門針對CSRF漏洞進行檢測的工具，如CSRFTester，CSRF Request Builder等。

以CSRFTester工具爲例，CSRF漏洞檢測工具的測試原理以下：使用CSRFTester進行測試時，首先須要抓取咱們在瀏覽器中訪問過的全部連接以及全部的表單等信息，而後經過在CSRFTester中修改相應的表單等信息，從新提交，這至關於一次僞造客戶端請求。若是修改後的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，固然此款工具也能夠被用來進行CSRF攻擊。

4    CSRF漏洞防護

CSRF漏洞防護主要能夠從三個層面進行，即服務端的防護、用戶端的防護和安全設備的防護。

4.1      服務端的防護

目前業界服務器端防護CSRF攻擊主要有三種策略：驗證HTTP Referer字段，在請求地址中添加token並驗證，在HTTP頭中自定義屬性並驗證。下面分別對這三種策略進行簡要介紹。

4.1.1        驗證HTTP Referer字段

根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在一般狀況下，訪問一個安全受限頁面的請求必須來自於同一個網站。好比某銀行的轉帳是經過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登陸bank. test，而後經過點擊頁面上的按鈕來觸發轉帳事件。當用戶提交請求時，該轉帳請求的Referer值就會是轉帳按鈕所在頁面的URL（本例中，一般是以bank. test域名開頭的地址）。而若是攻擊者要對銀行網站實施CSRF攻擊，他只能在本身的網站構造請求，當用戶經過攻擊者的網站發送請求到銀行時，該請求的Referer是指向攻擊者的網站。所以，要防護CSRF攻擊，銀行網站只須要對於每個轉帳請求驗證其Referer值，若是是以bank. test開頭的域名，則說明該請求是來自銀行網站本身的請求，是合法的。若是Referer是其餘網站的話，就有多是CSRF攻擊，則拒絕該請求。

4.1.2        在請求地址中添加token並驗證

CSRF攻擊之因此可以成功，是由於攻擊者能夠僞造用戶的請求，該請求中全部的用戶驗證信息都存在於Cookie中，所以攻擊者能夠在不知道這些驗證信息的狀況下直接利用用戶本身的Cookie來經過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不能僞造的信息，而且該信息不存在於Cookie之中。鑑於此，系統開發者能夠在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器端創建一個攔截器來驗證這個token，若是請求中沒有token或者token內容不正確，則認爲多是CSRF攻擊而拒絕該請求。

4.1.3        在HTTP頭中自定義屬性並驗證

自定義屬性的方法也是使用token並進行驗證，和前一種方法不一樣的是，這裏並非把token以參數的形式置於HTTP請求之中，而是把它放到HTTP頭中自定義的屬性裏。經過XMLHttpRequest這個類，能夠一次性給全部該類請求加上csrftoken這個HTTP頭屬性，並把token值放入其中。這樣解決了前一種方法在請求中加入token的不便，同時，經過這個類請求的地址不會被記錄到瀏覽器的地址欄，也不用擔憂token會經過Referer泄露到其餘網站。

4.2      用戶端的防護

    對於普通用戶來講，都學習並具有網絡安全知識以防護網絡攻擊是不現實的。但若用戶養成良好的上網習慣，則可以很大程度上減小CSRF攻擊的危害。例如，用戶上網時，不要輕易點擊網絡論壇、聊天室、即時通信工具或電子郵件中出現的連接或者圖片；及時退出長時間不使用的已登陸帳戶，尤爲是系統管理員，應儘可能在登出系統的狀況下點擊未知連接和圖片。除此以外，用戶還須要在鏈接互聯網的計算機上安裝合適的安全防禦軟件，並及時更新軟件廠商發佈的特徵庫，以保持安全軟件對最新攻擊的實時跟蹤。

 

 

跨域資源共享(CORS)安全性淺析

（轉自http://netsecurity.51cto.com/art/201311/419179.htm）

1、背景

提起瀏覽器的同源策略，你們都很熟悉。不一樣域的客戶端腳本不能讀寫對方的資源。可是實踐中有一些場景須要跨域的讀寫，因此出現了一些hack的方式來跨域。好比在同域內作一個代理，JSON-P等。但這些方式都存在缺陷，沒法完美的實現跨域讀寫。因此在XMLHttpRequest v2標準下，提出了CORS(Cross Origin Resourse-Sharing)的模型，試圖提供安全方便的跨域讀寫資源。目前主流瀏覽器均支持CORS。

2、技術原理

CORS定義了兩種跨域請求，簡單跨域請求和非簡單跨域請求。當一個跨域請求發送簡單跨域請求包括：請求方法爲HEAD，GET，POST;請求頭只有4個字段，Accept，Accept-Language，Content-Language，Last-Event-ID;若是設置了Content-Type，則其值只能是application/x-www-form-urlencoded,multipart/form-data,text/plain。提及來比較彆扭，簡單的意思就是設置了一個白名單，符合這個條件的纔是簡單請求。其餘不符合的都是非簡單請求。 

之因此有這個分類是由於瀏覽器對簡單請求和非簡單請求的處理機制是不同的。當咱們須要發送一個跨域請求的時候，瀏覽器會首先檢查這個請求，若是它符合上面所述的簡單跨域請求，瀏覽器就會馬上發送這個請求。若是瀏覽器檢查以後發現這是一個非簡單請求，好比請求頭含有X-Forwarded-For字段。這時候瀏覽器不會立刻發送這個請求，而是有一個preflight，跟服務器驗證的過程。瀏覽器先發送一個options方法的預檢請求。下圖是一個示例。若是預檢經過，則發送這個請求，不然就不拒絕發送這個跨域請求。

 

下面詳細分析一下實現安全跨域請求的控制方式。先看一下非簡單請求的預檢過程。瀏覽器先發送一個options方法的請求。帶有以下字段：

Origin: 普通的HTTP請求也會帶有，在CORS中專門做爲Origin信息供後端比對,代表來源域。

Access-Control-Request-Method: 接下來請求的方法，例如PUT, DELETE等等

Access-Control-Request-Headers: 自定義的頭部，全部用setRequestHeader方法設置的頭部都將會以逗號隔開的形式包含在這個頭中

而後若是服務器配置了cors，會返回對應對的字段，具體字段含義在返回結果是一併解釋。

Access-Control-Allow-Origin:

Access-Control-Allow-Methods:

Access-Control-Allow-Headers:

而後瀏覽器再根據服務器的返回值判斷是否發送非簡單請求。簡單請求前面講過是直接發送，只是多加一個origin字段代表跨域請求的來源。而後服務器處理完請求以後，會再返回結果中加上以下控制字段：

Access-Control-Allow-Origin: 容許跨域訪問的域，能夠是一個域的列表，也能夠是通配符"*"。這裏要注意Origin規則只對域名有效，並不會對子目錄有效。即http://foo.example/subdir/ 是無效的。可是不一樣子域名須要分開設置，這裏的規則能夠參照同源策略

Access-Control-Allow-Credentials: 是否容許請求帶有驗證信息，這部分將會在下面詳細解釋

Access-Control-Expose-Headers: 容許腳本訪問的返回頭，請求成功後，腳本能夠在XMLHttpRequest中訪問這些頭的信息(貌似webkit沒有實現這個)

Access-Control-Max-Age: 緩存這次請求的秒數。在這個時間範圍內，全部同類型的請求都將再也不發送預檢請求而是直接使用這次返回的頭做爲判斷依據，很是有用，大幅優化請求次數

Access-Control-Allow-Methods: 容許使用的請求方法，以逗號隔開

Access-Control-Allow-Headers: 容許自定義的頭部，以逗號隔開，大小寫不敏感

而後瀏覽器經過返回結果的這些控制字段來決定是將結果開放給客戶端腳本讀取仍是屏蔽掉。若是服務器沒有配置cors，返回結果沒有控制字段，瀏覽器會屏蔽腳本對返回信息的讀取。

3、安全隱患

你們注意這個流程。服務器接收到跨域請求的時候，並無先驗證，而是先處理了請求。因此從某種程度上來講。在支持cors的瀏覽器上實現跨域的寫資源，打破了傳統同源策略下不能跨域讀寫資源。

再一個就是若是程序猿偷懶將Access-Control-Allow-Origin設置爲容許來自全部域的跨域請求。那麼cors的安全機制幾乎就無效了。不過先別高興的太早。其實這裏在設計的時候有一個很好的限制。xmlhttprequest發送的請求須要使用「withCredentials」來帶上cookie，若是一個目標域設置成了容許任意域的跨域請求，這個請求又帶着cookie的話，這個請求是不合法的。(就是若是須要實現帶cookie的跨域請求，須要明確的配置容許來源的域，使用任意域的配置是不合法的)瀏覽器會屏蔽掉返回的結果。javascript就無法獲取返回的數據了。這是cors模型最後一道防線。假如沒有這個限制的話，那麼javascript就能夠獲取返回數據中的csrf token，以及各類敏感數據。這個限制極大的下降了cors的風險。

4、攻擊模型

 

從思路上講，有兩種類型的攻擊方式。一種是在攻擊者本身控制的網頁上嵌入跨域請求，用戶訪問連接，執行了跨域請求，從而攻擊目標，好比訪問了內網敏感資源。還有一種是正常的網頁被嵌入了到攻擊者控制頁面的跨域請求，從而劫持用戶的會話。

5、攻擊場景

先看第一種思路的攻擊場景：

1,複雜csrf。傳統的csrf都是利用html標籤和表單來發送請求。沒有辦法實現一些複雜步驟的csrf，好比模擬購物，先加購物車，結算，填寫信息，等等。好比上傳文件。具體能夠參考利用csrf上傳文件

2,訪問內網敏感資源。這個在必定的條件下是能夠實現的。好比內網的服務器配置了

Access-Control-Allow-Origin: * 容許任何來自任意域的跨域請求

用戶訪問惡意網頁的時候，執行了到內網服務器192.168.1.123/password.txt的請求，腳本在接收到服務器返回以後，將內容發送到攻擊者的服務器上。

第二種思路的場景:

1,交互式xss。參考揭密HTML5帶來的攻擊手法中講到的shell of the future工具。經過cors，繞過一些反會話劫持的方法，如HTTP-Only限制的cookie，綁定IP地址的會話ID等，劫持用戶會話。

2,程序猿在寫ajax請求的時候，對目標域限制不嚴。有點相似於url跳轉。facebook出現過這樣一個案例。javascript經過url裏的參數進行ajax請求。經過控制這個參數實現注入攻擊。