XSS、CSRF、SSRF

相同不同

相同點：

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標簽的屬性輸出：

比如： u s e r n a m e < / s p a n > , < p > < c : o u t v a l u e = " {username}</span>, <p><c:out value=" username</span>,<p><c:outvalue="{username}"></c:out>

此時的轉義規則如下：

< 轉成 <

轉成 >

& 轉成 &

" 轉成 "

’ 轉成 &#39

2、javascript事件

除了上面的那些轉義之外，還要附加上下面的轉義：

\ 轉成 \

/ 轉成 /

; 轉成 ；(全角;)

3、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是服務器端請求偽造，由服務器發起 重放攻擊是將截獲的資料包進行重放，達到身份認證等目的