為什麼瀏覽器要限制跨域訪問?

01-04

能舉例說明嗎？

如果在A網站中，我們希望使用Ajax來獲得B網站中的特定內容

如果A網站與B網站不在同一個域中，那麼就出現了跨域訪問問題

Ajax的跨域訪問問題是現有的Ajax開發人員比較常遇到的問題

一般都會用jsoncallback方法來解決

你可以理解為兩個域名之間不能跨過域名來發送請求或者請求數據，否則就是不安全的

關於CSRF攻擊，下面這篇博客有詳細介紹

http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

淺談CSRF攻擊方式

一.CSRF是什麼？

　　CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。

二.CSRF可以做什麼？

　　你這可以這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私泄露以及財產安全。

三.CSRF漏洞現狀

　　CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年才開始被關注，08年，國內外的多個大型社區和交互網站分別爆出CSRF漏洞，如：http://NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站），YouTube和百度HI......而現在，互聯網上的許多站點仍對此毫無防備，以至於安全業界稱CSRF為「沉睡的巨人」。

四.CSRF的原理

　　下圖簡單闡述了CSRF攻擊的思想：

防止CSRF攻擊，比如說有兩個網站 A和B。

你是A網站的管理員，你在A網站有一個許可權是刪除用戶，比如說這個過程只需用你的身份登陸並且POST數據到http://a.com/delUser，就可以實現刪除操作。

好現在說B網站，B網站被攻擊了，別人種下了惡意代碼，你點開的時候就會模擬跨域請求，如果是針對你，那麼就可以模擬對A站的跨域請求，恰好這個時候你已經在A站登陸了。那麼攻擊者在B站內通過腳本，模擬一個用戶刪除操作是很簡單的。

面對這種問題，有從瀏覽器解決，但個人認為最好是從網站端解決，檢測每次POST過來數據時熱refer，添加accesstoken等都是好方法。希望對你有幫助

回答這個問題有幾個層面：

1.一個Web系統的安全都和誰有關

一個Web系統的安全主要和網站的運行商（包括伺服器端開發商、運維管理等）、各級網路服務提供商、瀏覽器廠商或瀏覽器第三方插件開發商、用戶。

當用戶遇到了跨域相關的安全問題時，網站運營商說我只提供內容（網站健壯的前提下），網路服務提供商說我只提供傳輸服務，用戶表示很無辜。

大家目光都對準了瀏覽器廠商，雖然心裡有千萬匹草泥馬在奔騰，但不說點什麼好像不合適。先推出協議擋一下：

2.http的協議出場

HTTP是是一個基於請求與響應模式的、無狀態的、應用層的協議，常基於TCP的連接方式。 http請求由三部分組成，分別是：請求行、消息報頭、請求正文。

最理想的環境是各個資源都是安全無害的，這樣只要通過http請求中的參數Referer，記錄訪問的來源就可以了。但理想環境不存在，你的網站和內容真的健壯嗎？如果訪問的是惡意來源怎麼辦？（瀏覽器廠商心中偷笑一下）。對於惡意的來源，最大的風險往往首先不是技術風險，而是業務風險。

到這裡，瀏覽器廠商開始出場秀自己的社會責任、技術實力等漂亮的羽毛了。

3.瀏覽器廠商

嗯嗯，出於對用戶的負責（可能真實的想法是商業競爭和規避法律、法規的風險，要訪問一個web系統的入口就是瀏覽器，你不管誰管），我們必須提出相應的解決辦法。

瀏覽器能夠在用戶瀏覽網站的同時運行一些程序，如js，java applet，fs，activex等。出於訪問控制這個最基本的安全剛需，應該禁止那些不允許跨域調用其他頁面的對象。這時，同源策略這個要求才正式登場

一般會提示：已阻止交叉源請求：同源策略不允許讀取XXX上的遠程資源。可以將資源移動到相同的域名上或者啟用 CORS 來解決這個問題。

本質上是由於瀏覽器實現的同源策略的限制。

XmlHttpRequest只允許請求當前源（域名、協議、埠）的資源，所以AJAX是不允許跨域的。不過像&,&,&,&這些標籤是允許跨域的，但你並不能修改這些資源，比如iframe里的內容。