一、CSRF介紹

Cross-site request forgery，跨站請求偽造。發生在Web應用當中。有使用者登入了Web應用，強制其執行非本意的操作。跨站：發生在使用者終端（客戶端）。主要目的是偽造更改狀態（如，修改密碼，轉賬等）的請求，而非盜取資料。它是一種欺騙受害者提交惡意請求的攻擊，它繼承了受害者的身份與特權，代表受害者執行非本意操作。對於大多數網站，瀏覽器請求自動傳送與站點關聯的所有憑據，例如使用者的會話cookie，IP地址，Windows域憑據等。因此，如果使用者當前已對該站點進行了身份驗證，則該站點將無法區分受害者傳送的偽造請求和受害者傳送的合法請求。

有時可以把CSRF攻擊儲存在易受攻擊的站點上，被稱為“儲存的CSRF漏洞”，攻擊的嚴重更大。

角色：攻擊者（如：hacker）、伺服器（server，如網銀頁面）、釣魚網站（hacker搭建）、受害者（如admin）

情景：hacker與admin都在網銀頁面上有賬號，假設hacker當前存款0，admin存款,20000。admin在網銀頁面沒有退出登入的情況下，訪問了釣魚網站，點選了其中的連結，即發生了轉賬，金額從admin的賬戶轉移到了hacker的賬戶。因為網銀頁面與釣魚網站是兩個IP不同的網站，所以叫跨站。

分析原因：

CSRF的觸發：

1.a標籤

<a href="轉賬連結">click me.</a>

或者2.<img src="轉賬連結">（get請求）

admin在觸發了以上惡意程式碼後，請求先由釣魚網站傳送到admin客戶端，再由admin客戶端傳送到網銀頁面（偽造的請求）。網銀頁面接收到admin的請求後，將金額由admin賬戶轉移到其下的hacker賬戶，從而完成了轉賬。整個過程hacker只搭建了釣魚網站，不參與到攻擊過程中。此攻擊具有普遍性，對所有訪問者有效。

除了用get方式傳送偽造請求外，還可以用post偽造表單的方式傳送。

二、CSRF防禦

（1）無效的防禦

1.使用祕密cookie

所有的cookie，即便是加密的，也會隨著每一個請求一起提交。無論終端使用者是否被欺騙提交請求，都將提交所有身份驗證令牌，身份憑據。

2.僅接受POST請求

3.多步交易

4.URL重寫

5.https

（2）有效的防禦

1.驗證referer欄位

只接受來自例如網銀頁面的請求，而referer如果是其他網站的，則拒絕。

注意：因為referer支援客戶端自定義，所以也可能無效。

2.新增token（隨機字串）驗證

CSRF之所以能成功，是因為攻擊者可以偽造使用者的請求，該請求中所有的使用者驗證資訊都存在於cookie中，因此攻擊者可以在不知道這些驗證資訊的情況下直接利用使用者自己的cookie來通過安全驗證。由此可知，抵禦CSRF的關鍵在於：在請求中放入攻擊者所不能偽造的資訊，並且該資訊不存在於Cookie之中。鑑於此，系統開發者可以在HTTP請求中以引數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，可以認為是CSRF而拒絕請求。

3.二次驗證

在轉賬等關鍵操作之前提供當前使用者密碼或驗證碼。

4.使用者養成良好的習慣。

三、SSRF介紹

Server-Side request forgery，伺服器端請求偽造。本質：強制伺服器傳送一個攻擊者的請求。

如果Web應用開放了類似於“百度識圖”類的功能，並且對使用者提供的URL和遠端伺服器返回的資訊沒有進行合適的驗證或過濾就可能存在“請求偽造”的缺陷。

SSRF的危害：埠掃描（掃描內網機器的埠）、內網Web應用指紋識別、攻擊內網Web應用、讀取本地檔案（如用file協議）。

可通過PHP語言實現，但需要開啟curl擴充套件。

四、SSRF的防禦

1.限制協議

僅允許http和https請求。

2.限制IP

避免應用被用來獲取內網資料，攻擊內網。不能是內網IP。

3.限制埠

限制http常用埠，如80/443/8080/8090。

4.過濾返回資訊

驗證遠端伺服器對請求的響應是比較簡單的方法。

5.統一錯誤資訊

比如都用404。避免使用者可以根據錯誤資訊來判斷遠端伺服器的埠狀態。