文章目錄
跨源資源共享(CORS)
瀏覽器的同源策略
概念
根據字面意思就可以理解，同源策略是瀏覽器實施的一種關鍵機制，主要防止不同來源的干擾。所謂同源是指域名，協議，端口相同。
與其說同源策略的作用，不如說如果沒有同源策略會產生什麼後果，比如當你瀏覽網站A的同時也瀏覽了網站B，在該網站上運行的腳本代碼將能訪問你同時訪問的網站B的數據和功能，此時如果網站A是惡意網站，如果網站B是網上銀行，那麼此時惡意站點就可以以你的名義進行轉賬。
特點
- 位於一個域的頁面可以向另一個域提出請求
- 位於一個域的頁面可以加載來自其他域的腳本並在自己的域中執行這個腳本（在授權的情況下）
- 位於一個域的頁面無法讀取或修改屬於另一個域的cookie 或者其他DOM數據
主要功能
同源策略可以防止在一個域中運行的代碼訪問由其他域提供的內容
ps:但是很多功能是不受同源策略限制的：超鏈接、重定向、提交表單、嵌入到頁面的圖片等
跨域
主要跨域請求方法
- JSONP
- CORS
JSONP跨域
加載遠程js,可以把遠程js中數據帶進來，一筆帶過，這裏並不是主要學習這個的。
CORS跨域
爲了實現某些功能，允許瀏覽器向跨域服務器發出xmlhttprequest請求，克服SOP的限制實現跨域獲取數據。
說明
最初XMLHttpRequest僅允許向與調用頁面的來源相同的來源提出請求。隨着HTML5的出現，這一技術得以修改，從而可以與其他域進行交互。
舉例說明
首先看個實例說明一下，剛好我在逛b站，就隨手抓了一個包----如圖
- 請求頭中的Origin字段
其中紅色框框的origin字段表明該請求來源於https://message.bilibili.com
需要跨域請求時，瀏覽器會添加origin消息頭，用於指示嘗試提出跨域請求的域，對服務端來說，這個字段即是跨域標誌。
當瀏覽器收到請求並收到這個字段，首先就會判斷這個源是否在允許範圍之內，如果是，也就出現了下面介紹的這些字段。
- 響應包中的4個響應字段
-
Access-Control-Allow-Origin字段在這裏表示接受該域名的請求，有些情況會是 * 此時也就存在了安全風險。 -
Access-Control-Allow-Credentials：該字段可選。它的值是一個布爾值，表示是否允許發送Cookie。當設置爲true時，即表示服務器明確許可，Cookie可以包含在請求中，一起發給服務器。默認是false。 -
Access-Control-Expose-Headers：該字段可選。CORS請求時，XMLHttpRequest對象的getResponseHeader()方法只能拿到6個基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必須在Access-Control-Expose-Headers裏面指定。 -
Access-Control-Allow-Methods: 允許使用的請求方法
CORS的安全問題
造成安全原因同樣也是不安去的配置導致的，唉，不安全的配置會導致各種各樣的漏洞，這也是這種缺陷一直位於owaspTop10的原因。
簡單易懂的舉個例子就是foo.com向bar.com發出請求時，如果響應頭中包含了foo.com的CORS頭，這樣foo.com就可以攜帶cookie去調用bar.com了。
三種不安全的配置引起的安全問題
- CORS服務端的 Access-Control-Allow-Origin 設置爲了 * ,也就是說允許任何網站訪問本服務器的資源。毫無疑問這是存在安全風險的
這裏做一個實驗，是一個在線實驗室，就是針對這一類漏洞，如圖
出現一個登入界面，使用提供給你的用戶密碼登入進去，點擊我的賬戶，會發現會提供給你一個api key,並且這個服務器對跨域請求進行了不安全的配置，也就是上文提到的，這裏只需要在請求頭中添加Origin字段–如圖
響應消息頭中當然是不合法的，這個實驗室同時也提供了可以利用的服務器，通過這個服務器獲得本服務器的API
進入可利用服務器，向受害者服務器提出跨域請求，如圖
完成攻擊後，查看訪問日誌發現已經完成攻擊。
還有一種漏洞是由於白名單的空原始值，請求消息頭爲Origin: null，某些應用程序可能會將null來源列入白名單，以支持應用程序的本地開發，這個實驗內容和本實驗類似。
-
返回報文頭部Access-Control-Allow-Origin由請求報文Origin生成的（客戶端可控數據），並且返回報文Access-Control-Allow-Credentials=true時，表明cookie可以包含在請求頭中，一起發給服務器
-
配置了不嚴謹的正則表達式規則，也就是說對origin校驗功能不完善，比如一種情況是隻檢查以a.com結尾的網站域名
origin:http://a.com
Access-Control-Allow-Origin:http://a.com
可以構造一個類似http://b.a.com 就能繞過其驗證機制導致信息泄露，有些情況也會導致HTTP拆分注入攻擊。
通過CORS信任關係 利用XSS
甚至“正確”配置的CORS也會在兩個來源之間建立信任關係。如果網站信任易受跨站點腳本（XSS）攻擊的來源，則攻擊者可能利用XSS注入一些JavaScript，這些JavaScript使用CORS從信任易受攻擊的應用程序的站點檢索敏感信息。
- 開發人員用於對抗CORS利用的一種防禦機制，是將頻繁請求訪問信息的域列入白名單。但這並不完全安全，因爲只要白名單域中的一個子域易受到其他攻擊（如XSS），那麼也可以進行CORS利用。
https://www.cnblogs.com/linuxsec/articles/10584677.html
這篇文章有幾個實例和漏洞分析可以看看。
使用錯誤的CORS破壞TLS
假設嚴格使用HTTPS的應用程序還將使用純HTTP的受信任子域列入白名單。例如，當應用程序收到以下請求時：
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...
該應用程序響應：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true
在這種情況下，能夠攔截受害者用戶流量的攻擊者可以利用CORS配置破壞受害者與應用程序的交互。該攻擊包括以下步驟：
- 受害用戶發出任何普通的HTTP請求。
- 攻擊者將重定向注入到： http://trusted-subdomain.vulnerable-website.com
- 受害者的瀏覽器遵循重定向。
- 攻擊者攔截原始的HTTP請求，然後將包含CORS請求的欺騙響應返回給： https://vulnerable-website.com
- 受害者的瀏覽器發出CORS請求，包括來源： http://trusted-subdomain.vulnerable-website.com
- 該應用程序允許該請求，因爲這是白名單來源。請求的敏感數據將在響應中返回。
- 攻擊者的欺騙頁面可以讀取敏感數據，並將其傳輸到攻擊者控制下的任何域。
- 即使易受攻擊的網站對HTTPS的使用具有魯棒性，沒有HTTP終結點並且所有cookie被標記爲安全，此攻擊也有效。
防禦CORS
如何預防基於CORS的攻擊
CORS漏洞主要是由於配置錯誤而引起的。因此，預防是一個配置問題。以下各節介紹了一些針對CORS攻擊的有效防禦措施。
正確配置跨域請求
如果Web資源包含敏感信息，則應在Access-Control-Allow-Origin標頭中正確指定來源。
只允許信任的網站
看起來似乎很明顯，但是Access-Control-Allow-Origin標頭中指定的來源只能是受信任的站點。特別是，無需驗證就可以動態反映跨域請求的來源而無需驗證，因此應避免使用。
避免將null列入白名單
避免使用標題Access-Control-Allow-Origin: null。來自內部文檔和沙盒請求的跨域資源調用可以指定null來源。應針對私有和公共服務器的可信來源正確定義CORS標頭。
避免在內部網絡中使用通配符
避免在內部網絡中使用通配符。當內部瀏覽器可以訪問不受信任的外部域時，僅靠信任網絡配置來保護內部資源是不夠的。
CORS不能替代服務器端安全策略
CORS定義了瀏覽器的行爲，絕不能替代服務器端對敏感數據的保護-攻擊者可以直接從任何可信來源僞造請求。因此，除了正確配置的CORS之外，Web服務器還應繼續對敏感數據應用保護，例如身份驗證和會話管理。
實驗室和參考：
https://portswigger.net/web-security/cors
正在學習這個漏洞，有些錯誤的地方請指出，本人也會在以後的學習加以改正.