是什麼讓跨域ajax不安全？

Question

我不確定我瞭解這會導致哪些類型的漏洞。

當我需要從一個API我必須使用AJAX請求我自己的服務器上的PHP文件訪問數據，而PHP文件訪問的API。是什麼讓這個更安全，而不僅僅是讓我直接用ajax打API？

對於這個問題，它看起來像使用JSONP http://en.wikipedia.org/wiki/JSONP你可以做的一切，跨域Ajax會讓你做。

有人能教導我嗎？

Answer 1

我認爲你誤解了同源策略試圖解決的問題。

想象一下，我已登錄到Gmail，並且該Gmail有一個JSON資源，http：//www.mail.google.com/information-about-current-user.js，其中包含有關已登錄用戶的信息。此資源大概是爲Gmail用戶界面所使用，但如果不是用於同源策略，我訪問過的任何網站以及懷疑我可能是Gmail用戶的網站都可能運行AJAX請求以獲取該資源資源作爲我，並檢索有關我的信息，而Gmail無法對此做太多介紹。

所以同源策略並不是保護你的PHP頁面不受第三方網站的影響;而不是保護從第三方站點訪問您的PHP頁面的人員;相反，它是爲了保護訪問您的PHP頁面的人員以及他們有權訪問的任何第三方網站，來自您的PHP頁面。 （「特殊訪問」可能是因爲cookies，HTTP AUTH或IP地址白名單，或者只是在正確的網絡上，或許有人在NSA工作並訪問您的站點，這並不意味着您應該是能夠觸發來自NSA內部頁面的數據轉儲。）

JSONP通過引入不同的限制以安全的方式迴避這個問題：只有當資源是JSONP時它才能工作。因此，如果Gmail希望給定的JSON資源可供第三方使用，它可以爲該資源支持JSONP，但如果它只希望該資源能夠被其自己的用戶界面使用，則它只能支持普通的JSON。

Answer 2

隨着跨站點腳本，你會再有一個網頁，將能夠從任何地方獲取數據，然後可以在相同的上下文中頁面上的其他數據，並在理論上有機會獲得cookie來運行，您也不想訪問的其他安全信息也會被提供。跨站點腳本在這方面是非常不安全的，因爲您可以訪問任何頁面，並且如果允許該頁面上的腳本可以從任何地方加載數據，然後開始執行錯誤的代碼，那麼這是不允許的。

另一方面，JSONP允許您以JSON格式獲取數據，因爲您提供了數據傳入的必要回調，因此它提供了控制措施，數據不會被瀏覽器執行，除非回調函數執行並執行或試圖執行它。數據將採用JSON格式，然後您可以隨意執行任何操作，但不會執行，因此它更安全，因此也是允許的原因。

Answer 3

許多Web服務不是爲了抵制XSRF而構建的，所以如果一個網站可以通過一個請求攜帶跨域cookie的請求通過編程的方式加載用戶數據，只要用戶訪問過該網站，任何人都可以運行JavaScript可以竊取用戶數據。

CORS是XHR計劃安全的替代方案，通過not carrying credentials by default解決了這個問題。 CORS規範解釋了此問題：

用戶代理通常將同源限制應用於網絡請求。這些限制可防止從一個來源運行的客戶端Web應用程序獲取從另一個來源檢索到的數據，還會限制不安全的HTTP請求，這些請求可以自動啓動到與正在運行的應用程序的來源不同的目標。

在這遵循此模式的用戶代理，網絡請求通常使用環境認證和會話管理信息，包括HTTP認證和cookie信息。

編輯：

只讓XHR工作跨域的問題是，很多Web服務暴露ambient authority。通常，該權限僅適用於來自相同來源的代碼。

這意味着，信任一個網站的用戶從該網站與他們的私人數據相信所有的代碼。用戶信任他們發送數據的服務器，以及由該服務器提供的頁面加載的任何代碼。當網站背後的人員和加載的圖書館值得信賴時，用戶的信任就位置很好。

如果XHR工作的是跨源，並且攜帶了cookie，那麼該環境權限將可用於向可以向用戶提供代碼的任何人編碼。用戶以前做出的信任決定可能不再適合。

CORS不會繼承這些問題，因爲現有服務不會將環境權限暴露給CORS。

Answer 4

JS->Server(PHP)->API的模式使得它成爲可能，而不僅僅是最好的，但必不可少的實踐，以確保你通過服務器時得到的東西。除此之外，服務器上的穩定本地解析器（又名DNS蠕蟲）等等的可能性要低於某些隨機客戶端。

至於JSONP：這不是手杖，而是柺杖。恕我直言，它可能被視爲對HTML/JS組合的錯誤功能的攻擊，無法在不破壞現有代碼的情況下將其移除。其他人可能會認爲與此不同。

儘管JSONP 允許你unreflectedly在惡劣廣闊的世界從somwhere執行代碼，沒有人力量你這樣做。 JSONP的所有通用實現都使用某種哈希等來驗證，該代碼的提供者是trustwirthy。其他人可能會認爲不同。

Answer 5

original XHR從來沒有被設計爲允許跨源請求。原因是主要由CSRF attacks知道的實際安全漏洞。

在這種攻擊場景中，第三方站點可以強制受害者的用戶代理向原始站點發送僞造但合法的請求。從原始服務器的角度來看，這種僞造的請求並不能從該用戶發起的其他請求中檢測到，而這些請求是由原始服務器的網頁啓動的。原因是因爲它實際上是發送這些請求的用戶代理，並且它也會自動包含任何憑據，如cookie，HTTP身份驗證，甚至是客戶端的SSL證書。

現在這樣的請求可以很容易僞造：從簡單的GET請求開始，使用<img src="…">通過使用表單自動提交它們到POST請求。只要可預測如何僞造這些有效的請求，它就可以工作。

但是，這不是禁止XHR的跨源請求的主要原因。因爲，如上所示，即使沒有XHR甚至沒有JavaScript，也有辦法僞造請求。不，XHR不允許跨源請求的主要原因是因爲它將是第三方網頁中的JavaScript，該響應將被髮送到該頁面。因此，不僅可以發送跨源請求，還可以收到可能包含敏感信息的響應，然後由JavaScript訪問。

這就是爲什麼原始的XHR規範不允許跨源請求。但隨着技術的進步，對支持跨國請求提出了合理的要求。這就是爲什麼最初的XHR規範擴展到XHR level 2（現在合併了XHR和XHR 2級），其中主要擴展是支持在指定爲CORS的特定要求下的跨源請求。現在，服務器可以檢查請求的來源，並且還能夠限制允許的來源集合以及允許的HTTP方法和標題字段集合。

現在JSONP：要獲取JavaScript中的請求的JSON響應並且能夠處理它，它可能需要是同源請求，或者如果是跨源請求，則需要服務器和用戶代理將需要支持CORS（其中後者僅由現代瀏覽器支持）。但爲了能夠使用任何瀏覽器，JSONP被髮明出來，它只是一個有效的JavaScript函數調用，其JSON作爲一個參數，可以通過<script>作爲外部JavaScript加載，類似於<img>，並不限於同源要求。但是和其他請求一樣，JSONP請求也容易受到CSRF的影響。

所以爲了從安全角度得出結論吧：做了JSON資源的請求，以獲得在JavaScript他們的反應是必需的

• XHR
• XHR2/CORS需要做跨域請求對於JSON資源來獲得在JavaScript他們的反應
• JSONP是一種變通方法，以規避與XHR跨域請求

但也：

• 鍛造請求是可笑容易，雖然鍛造有效和合法的要求是很難的（但往往很容易爲好）
• CSRF攻擊是一個不容小覷的威脅，所以要學會如何protect against CSRF