目錄
區別和聯系
防御
聯系和區別
相同點：
XSS，CSRF,SSRF三種常見的Web服務端漏洞均是由於，服務器端對用戶提供的可控數據過於信任或者過濾不嚴導致的。
相同點：
XSS，CSRF,SSRF三種常見的Web服務端漏洞均是由於，服務器端對用戶提供的可控數據過於信任或者過濾不嚴導致的。
不同點：
XSS是服務器對用戶輸入的數據沒有進行足夠的過濾，導致客戶端瀏覽器在渲染服務器返回的html頁面時，出現了預期值之外的腳本語句被執行。
CSRF(跨站請求偽造)是服務器端沒有對用戶提交的數據進行隨機值校驗，且對http請求包內的refer字段校驗不嚴，導致攻擊者可以利用用戶的Cookie信息偽造用戶請求發送至服務器。
SSRF(服務端請求偽造）是服務器對用戶提供的可控URL過於信任，沒有對攻擊者提供的RUL進行地址限制和足夠的檢測，導致攻擊者可以以此為跳板攻擊內網或其他服務器。
防御
xss：修復方式：對字符實體進行轉義、使用HTTP Only來禁止JavaScript讀取Cookie值、輸入時校驗、瀏覽器與Web應用端采用相同的字符編碼
a)HttpOnly屬性
為Cookie中的關鍵值設置httponly屬性，眾所周知，大部分XSS（跨站腳本攻擊）的目的都是通過瀏覽器的同源策略，來獲取用戶Cookie，從而冒充用戶登陸系統的。
如果為Cookie中用於用戶認證的關鍵值設置httponly屬性，瀏覽器將會禁止js通過同源策略訪問cookie中設有httponly屬性的信息，因此以劫持用戶認證cookie為目的XSS攻擊將會失敗。
但很明顯，只為cookie中的值設置Httponly是不夠的，因為XSS攻擊並不是只能獲取用戶COOKIE，它還可以竊取用戶瀏覽器信息，模擬用戶身份執行操作等等
b) 對輸入和URL參數進行過濾(白名單和黑名單
c)對輸出進行編碼
在輸出數據之前對潛在的威脅的字符進行編碼、轉義是防御XSS攻擊十分有效的措施。如果使用好的話，理論上是可以防御住所有的XSS攻擊的。對所有要動態輸出到頁面的內容，通通進行相關的編碼和轉義。當然轉義是按照其輸出的上下文環境來決定如何轉義的。
1、作為body文本輸出，作為html標簽的屬性輸出：
比如：<span>${username}</span>, <p><c:out value="${username}"></c:out></p>
<input type="text" value="${username}" />
此時的轉義規則如下：
< 轉成 <
> 轉成 >
& 轉成 &
" 轉成 "
' 轉成 '
2、javascript事件
<input type="button" onclick='go_to_url("${myUrl}");' />
除了上面的那些轉義之外，還要附加上下面的轉義：
\ 轉成 \\
/ 轉成 \/
; 轉成 ；(全角;)
3、URL屬性
如果 <script>, <style>, <imt> 等標簽的 src 和 href 屬性值為動態內容，那么要確保這些url沒有執行惡意連接。
確保：href 和 src 的值必須以 http://開頭，白名單方式；不能有10進制和16進制編碼字符
cfrs：修復方式：篩選出需要防范CSRF的頁面然后嵌入Token、再次輸入密碼、檢驗Referer.
Referer頭檢測法
Referer標識當前請求的來源頁面，瀏覽器訪問時除了自動帶上Cookie還會自動帶上Referer，所以服務端可以檢測Referer頭是否本網站頁面來決定是否響應請求。
Referer是瀏覽器自動帶上的，基於認為瀏覽器沒有相關漏洞的前提下，我們可以認為攻擊者是沒法偽造Referer頭的，也就是檢測Referer頭的方法是可靠的。
但該方式有時會不受認可，一是因為瀏覽器是可以設置禁止發送Referer頭的，如果使用該方式那么禁止Referer頭的瀏覽將無法正常使用，這可能會降低用戶使用體驗。二是因為由於移動端的崛起當下流行前后端分離app和web共用一套后端代碼，但app是不會自動帶Referer頭的，如果使用該方式app端不好處理。
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"]
ssrf：
修復方案：
限制協議為HTTP、HTTPS
不用限制302重定向
設置URL白名單或者限制內網IP
面試題：
CSRF 和 XSS 和 XXE 有什么區別，以及修復方式？
XSS是跨站腳本攻擊，用戶提交的數據中可以構造代碼來執行，從而實現竊取用戶信息等攻擊。修復方式：對字符實體進行轉義、使用HTTP Only來禁止JavaScript讀取Cookie值、輸入時校驗、瀏覽器與Web應用端采用相同的字符編碼。 CSRF是跨站請求偽造攻擊，是由於沒有在關鍵操作執行時進行是否由用戶自願發起的確認，模仿合法用戶對服務器發起請求 。修復方式：篩選出需要防范CSRF的頁面然后嵌入Token、再次輸入密碼、檢驗Referer XXE是XML外部實體注入攻擊，XML中可以通過調用實體來請求本地或者遠程內容，和遠程文件保護類似，會引發相關安全問題，例如敏感文件讀取。修復方式：XML解析庫在調用時嚴格禁止對外部實體的解析。
CSRF、SSRF和重放攻擊有什么區別？
CSRF是服務器端沒有對用戶提交的數據進行嚴格的把控，導致攻擊者可以利用用戶的Cookie信息偽造用戶請求發送至服務器。而SSRF是服務器對用戶提供的可控URL地址過於信任，沒有經過嚴格檢測，導致攻擊者可以以此為跳板攻擊內網或其他服務器。
CSRF是跨站請求偽造攻擊，由客戶端發起 SSRF是服務器端請求偽造，由服務器發起 重放攻擊是將截獲的數據包進行重放，達到身份認證等目的