空談Security***方法之CSRF和XSS

其實，關於這兩個***（CSRF和XSS）的介紹，網上有不少文章，你們能夠自行搜索。這裏只談一下我的對它們的理解。

CSRF和XSS

CSRF的全稱是Cross Site Request Forgery，中文名稱叫跨站請求僞造。

XSS的全稱是Cross Site Scripting，中文名稱叫跨站腳本***。

雖然它們的名字都包含「跨站」，可是它們倒是不一樣的***方式，不管是***的手段仍是***的原理，都有很大的不一樣。

簡單描述這兩個***方式：

CSRF

用戶已經登錄了授信網站A，這時***發送一個釣魚網站B給這個用戶，當用戶點擊這個釣魚網站B時，釣魚網站B利用用戶在授信網站A的session，發送請求給授信網站A後端的API，從而達到一些***的目的。

XSS

一個博客網站，***發表了一篇文章，內容包含一些scripts，這些scripts的邏輯是調用後端的API關注博主。當其餘用戶打開瀏覽器瀏覽這篇文章時，這些scripts就自動執行，用戶就自動關注了***的博主。

下面是我對這兩個***的總結：

1. 它們跟瀏覽器的same-origin policy（同源策略，是瀏覽器的一個基本安全功能）有什麼關係嗎？

若是服務器設置成只容許同源訪問，對XSS***沒有任何幫助，但能夠必定程度限制CSRF***。

由於CSRF***原理上是須要跨域的，因此若是把同源策略放開，即CORS，必定程度上會增長CSRF***的風險。可是，即便是同源策略，也不能避免CSRF***，由於同源策略只能限制Ajax請求不能跨域，可是<img>、<script>等標籤仍是能夠跨域，因此CSRF***任然能夠利用這些標籤，這也是jsonp的原理。

2. 大方向上，CSRF和XSS是兩類不一樣的***方式。CSRF屬於僞造***（冒充別人的名義幹壞事）；而XSS屬於注入***（sql注入也屬於注入***）。

3. 從解決方案來說，CSRF通常來講是加一個token；而XSS則是配置csp（content security policy）白名單策略，目的是隻容許信任的scripts才能執行，以前作過的一個項目就是用的一個nodejs的library-helmetjs來配置的csp。

4. 關於實際案例，幾年以前新浪微博就遭受過一次大規模的XSS***。（See https://tech.qq.com/a/20110628/000413.htm）

CSRF和clickjacking

另外，CSRF和clickjacking（點擊劫持）有啥區別呢？（關於clickjacking，能夠參考這篇文章：一文帶你讀懂點擊劫持詳解+實驗）

1. CSRF利用受害者已經登錄的其餘網站的session；而clickjacking則是利用iframe把惡意的頁面嵌入進來，而且隱藏在正常的頁面後面。

2. CSRF能夠不須要受害者和UI的交互；而clickjacking則須要受害者和UI的交互，好比受害者點擊一個關閉廣告的按鈕，有可能實際是關注了一個微博的好友。

3. clickjacking***的難度更大，由於須要受害者和UI的交互，而且***的成本更大。

CORS

最後，再聊一下CORS，由於據我瞭解，好像不少人對它理解都不是很準確。

1. CORS（Cross-Origin Resource Sharing），中文叫跨域資源共享。

2. CORS不是一個安全功能，相反，CORS下降了安全保障。（參考微軟的一篇文檔：https://docs.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-3.1#same-origin）

「Cross Origin Resource Sharing (CORS):

• Is a W3C standard that allows a server to relax the same-origin policy.

• Is not a security feature, CORS relaxes security. An API is not safer by allowing CORS. For more information, see How CORS works.

• Allows a server to explicitly allow some cross-origin requests while rejecting others.

• Is safer and more flexible than earlier techniques, such as JSONP.」

3. 同源策略是瀏覽器的一個安全功能，對於一個跨域請求，服務器會正常處理這個請求，只是會在response加上Access-Control-Allow-Origin的header，當瀏覽器處理response時，發現有這個header，就會block這個response的渲染，報一個錯出來。這也是爲何咱們用postman等工具不會有這個問題的緣由。有時候咱們本地快速開發測試，確實須要跨域，這時咱們能夠把瀏覽器的安全功能關掉，就能夠正常工做。

chrome.exe --disable-web-security --user-data-dir
這裏提醒一下，網上不少文章都說服務器端就把請求reject掉了，其實這種說法是錯誤的，記住！

4. 這篇文章（不要再問我跨域的問題了）講跨域講的挺好，你們能夠參考。