我已經(jīng)看過有關(guān)該主題的文章和帖子（包括SO），并且普遍的評論是，同源策略阻止跨域的POST形式。我見過有人建議將同源政策不適用于表單帖子的唯一位置是此處。我想從一個更“官方”或正式的來源獲得答案。例如，是否有人知道解決同源性如何影響表單POST的RFC？澄清：我不是在問是否可以構(gòu)造GET或POST并將其發(fā)送到任何域。我在問：如果Chrome，IE或Firefox允許域“ Y”中的內(nèi)容將POST發(fā)送到域“ X”如果收到POST的服務(wù)器實(shí)際上將看不到任何表單值。我之所以這樣說，是因?yàn)榇蠖鄶?shù)在線討論都記錄了測試人員說服務(wù)器收到了該帖子，但是表單值都是空的/已被剝離。官方文件（即RFC）解釋了預(yù)期的行為（無論瀏覽器當(dāng)前已實(shí)現(xiàn)了什么）。順便說一句，如果同源源不影響表單POST，那么這使得為什么需要使用防偽令牌更加明顯。我之所以說“有點(diǎn)”，是因?yàn)楹茈y相信攻擊者可以簡單地發(fā)出HTTP GET來檢索包含防偽令牌的表單，然后進(jìn)行包含相同令牌的非法POST。評論？
3 回答
倚天杖
TA貢獻(xiàn)1828條經(jīng)驗(yàn) 獲得超3個贊
相同的原始策略與將請求發(fā)送到另一個url（不同的協(xié)議，域或端口）無關(guān)。
這一切都是為了限制對另一個URL的訪問（讀?。╉憫?yīng)數(shù)據(jù)。因此，頁面內(nèi)的JavaScript代碼可以發(fā)布到任意域，也可以將該頁面內(nèi)的表單提交到任何地方（除非表單位于具有不同url的iframe中）。
但是導(dǎo)致這些POST請求效率低下的原因是這些請求缺少防偽令牌，因此其他url會將其忽略。此外，如果JavaScript試圖通過向受害者url發(fā)送AJAX請求來獲取該安全性令牌，那么將通過Same Origin Policy阻止訪問該數(shù)據(jù)。
添加回答
舉報(bào)
0/150
提交
取消