記得以前去面試技術也不太會但你總得講點東西，讓面試時間長一些讓面試官覺得你基礎還可以，當時選的就是名頭比較大的owasp top 10。top 10嘛你總得拿出至少三個點來講的細一些以證明你是真的知道而不是背概念。
縱觀top 10 注入和xss是比較有把握的，其他什麼「失效的認證和會話管理」、「不安全的物件直接引用」，由於當時沒有實際的生產環境攻擊和防護經驗理解不了其所說的概念和影響，感覺好幾個概念感覺意思差不多面試官如果問區別那不肯定講不清了。權衡之下就要鎖定在同是技術問題的csrf上。
而同時選擇xss和csrf你就不得不面對解釋這兩者有何區別的問題。到現在這個問題仍然是web攻防文章和書藉都要談的問題，用得最多的講得最清楚的大概是德丸浩《web應用安全權威指南》那樣，七八個箭頭箭來箭去，xss第一步是第二步是而csrf第一步是第二步是。看的時候覺得挺清楚，看完要自己去說區別做防護還是感覺完全不懂。也因此想來寫寫自己的理解。
csrf，英文全稱cross site request forgery，中文名跨站請求偽造。owasp top 10 2010排a5，owasp top 10 2013排a8，owasp top 10 2017沒排進。
我們借用owasp top 10 2013給出的例子。
首先，使用者登入了沒有csrf防護的www.bank.com。該**有乙個轉賬鏈結
然後，使用者又訪問了攻擊者傳送過來的鏈結比如叫該頁面具有以下關鍵**
最後，瀏覽器自動請求src指向的鏈結由於請求的是www.bank.com所以瀏覽器會自動帶上www.bank.com的cookie。鏈結+登入cookie都已具備，www.bank.com並沒有其他檢查，所以向123456789轉賬1500塊的請求就會被成功響應。
從漏洞存在的位置上（csrf存在於所有請求-響應模式的功能上，xss存在於將使用者輸入回顯前端web頁面的位置上），從攻擊效果上（csrf主要是執行**自身已有功能，xss主要是用於獲取cookie）都有區別。
攻擊攻擊鏈結示例
說明csrf
頁面中含src="
傳送的是hack**的頁面，目標是bank**頁面
xss'>'
傳送的是bank**的頁面，目標是hack**頁面
從前面csrf利用形式可以看到，csrf的關鍵點是瀏覽器自動帶上了bank的cookie訪問bank的鏈結，這是瀏覽器需要的機制應用是無法阻止的。所以csrf防範的立足點應該是，面對發過來的資料報如何識別是通過本**點選鏈結發過來的資料報，還是其他**發來的資料訪問資料報。
有時我們會想當然地認為某些方法可以防禦csrf，為了避免踩坑，這裡先來介紹兩種典型的錯誤防禦方式。
5.1.1 使用post方式防禦csrf
在前面使用的csrf攻擊示例中，攻擊載荷是
，其他教程為了簡單使用的也是get方式的示例，所以是不是如果我的請求限定是form表單post的，那是不是就可以防禦csrf了呢？
答案是否定的。我們完全可以把攻擊載荷換成以下post形式的攻擊**：
<5.1.2 使用https防禦csrfbody
onload
="document.forms[0].submit()"
>
<
form
action
=""method
="post"
>
<
input
type
="hidden"
name
="amount"
value
="1500"
>
<
input
type
="hidden"
name
="destinationaccount"
value
="123456789"
>
form
>
body
>
https是加密碼，攻擊者無法修改其內容，**使用https是否可以防禦csrf呢？
答案也是否定的。認為https有助於防禦csrf是沒很好地理解"https=http層+ssl層"，https的封裝過程是http層內容交給ssl層，ssl層封裝完再交給傳輸層如此下去。csrf是在http層設定內容，ssl如何防止得了csrf呢。我們攻擊載荷改成如下形式也完全可以正確請求（http改成了https）：
<5.2.1 referer頭檢測法body
onload
="document.forms[0].submit()"
>
<
form
action
=""method
="post"
>
<
input
type
="hidden"
name
="amount"
value
="1500"
>
<
input
type
="hidden"
name
="destinationaccount"
value
="123456789"
>
form
>
body
>
referer是瀏覽器自動帶上的，基於認為瀏覽器沒有相關漏洞的前提下，我們可以認為攻擊者是沒法偽造referer頭的，也就是檢測referer頭的方法是可靠的。
5.2.2 token檢測法
token就是服務端返回給客戶端類似sessionid那樣一長串的類值（長是為了防暴力猜解）。csrf依賴於瀏覽器該問鏈結時自動對應**的cookie帶上，token不放cookie（一般form表單加個hidden屬性的input標籤來存放）csrf就沒法獲取token，這樣我們就可以通過檢測傳送過來的資料報中是否有正確的token值來決定是否響應請求。
在講清token防禦的原理後，我們再來講token的設計，因為token方式給人的感覺很複雜令人望而生畏。
我們首先明確乙個問題，就是能夠防止csrf攻擊的token，並不需要每次請求都不一樣，在使用者登入後到退出前的這整個過程中的所有請求token完全可以是一樣。因為（在基於沒有其他漏洞會洩漏本次會話的token的設想下）黑客是無法獲取使用者的tokne，所以又何必每個請求都要生成乙個新的token呢。（token每次請求都要不一樣的想法是受防重放攻擊的影響）只考濾防csrf不考濾防重放的情況下，token設計就簡單多了。
使用sessionid作為token設計：在csrf中cookie是瀏覽器自己帶上的，本質而言使用者的sessionid並未丟失（也就是攻擊者並不能知道sessionid是多少），基於此我們完全可以不用另傳乙個值只需直接將sessionid作為token即可（或者也可以做些運算比如取sessionid的某些值做個md5來做為token，意思都差不多）。判斷**類似 if session["id"] == $_post["token"]
與sessionid同時返回的token設計：在生成sessionid的同時生成乙個token（服務端token可以存於session變數中）返回給客戶端，客戶端儲存該token每次請求時都在form表單中提交該值。判斷**類似if session["token"] == $_post["token"]
參考：德丸浩-《web應用安全權威指南》
CSRF攻擊與防禦
csrf是乙個偽造使用者請求的操作，所以需要構造使用者請求的所有引數才構成攻擊。表單token通過在請求引數中增加隨機數的辦法來阻止攻擊者獲得所有請求的引數 在頁面表單中增加乙個隨機數為token，每次響應頁面的token都不一樣，從正常頁面提交的請求會包含該token，而偽造者的請求無法獲得該值，...
samesite cookie防禦CSRF漏洞
samesite cookie機制本意是為了減少網路請求包，設想下，b.com 展示a.com下的，b站每向a請求一張，都會攜帶上a域下的cookie，而這些cookie對於請求來說毫無意義，無意中增加請求包大小 samesite有三個屬性lax,strict,none lax b站上通過超連結訪問...
XSS攻擊與CSRF攻擊與防禦
csrf 跨站點請求偽造 cross site request forgery 使用者在自己電腦瀏覽乙個站點a，進行登入動作後，瀏覽完後沒有退出站點。在新的tab頁面開啟乙個站點b 加入站點b是乙個釣魚 其中有乙個連線是跳到站點a，這時候站點a的登入資訊你並沒退出，站點a認為是使用者操作行為，站點b...