2010-04-05 58 views
5

我讀的教程在防止跨站點請求僞造 - 不要在小甜餅報頭髮送到服務器的SessionID的依靠

http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

它指出

記住 - 你必須永遠不要依靠 cookieID發送到您的服務器的sessionID;請僅查看 會話ID,以便您的GWT應用程序將 明確地在消息的有效負載 中發送到您的服務器。

是用它來防止http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

有了這個神話,是不是足以防止上述攻擊?

回答

5

是的,它足以防止跨站請求僞造。

cookie中的sessionid不可信。假設用戶登錄到mysite.com,會話ID在cookie中。現在用戶點擊鏈接到evilsite.com。 evilsite.com有這樣的代碼

<img src="http://mysite.com/transfermoney.jsp?amount=1000.." /> 

瀏覽器會主動要求到mysite.com,它也將隨會話ID發送cookie。這裏要理解的是,evilsite.com 不能讀取cookie,但它仍然可以完成它的工作。

瀏覽器同源策略可防止evilsite.com讀取會話標識符,無論是在cookie中還是嵌入在html頁面中。但是,由於瀏覽器自動將cookie發送到服務器,即使資源是從其他域中的html代碼請求的,您也有XSRF。

爲防止出現這種情況,建議將會話標識符作爲請求參數。如果將其作爲請求參數添加,evilsite.com將無法訪問標識符,因此無法將其置於img src屬性中。

但是,請記住,如果您的網站存在XSS漏洞,則任何事情都無法阻止您從XSRF中獲得。換句話說,如果你有XSS漏洞,攻擊者甚至不會在乎做XSRF。

+0

@Sripathi:對於一個非常好的問題,這是一個非常好的答案!我看到的實際問題是,人們習慣於「保持登錄狀態」,即使他們關閉了一個瀏覽器窗口,或者如果他們使用其他瀏覽器窗口訪問同一網站 - 他們希望仍然登錄。所以如果我的網站並未提供該功能(以對付CSRF攻擊),恐怕他們會將我的網站視爲「低質量」 - 即「爲什麼其他網站可以這樣做,但不是您的?」我實際上可以理解這種態度。有沒有什麼方法可以將兩個優點結合起來,或者找到一個好的折中方案? – 2010-04-05 19:40:45

+0

這是可能的。 CSRF主要是AJAX風格的APIS的一個問題,其中只需要一個請求即可完成有害的事情。對於這樣的api請求,你不應該只依賴長壽的記住我cookie。但是,僅使用cookie呈現只讀頁面是可以的 - 因爲攻擊者無法使用csrf來讀取內容。 – 2010-04-06 01:08:04

+0

我認爲,這是最好的折中方案。但是我仍然有點不確定,因爲我記得閱讀過一篇文章(http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is。HTML)關於如何從CSRF的回覆中竊取某些類型的數據的技術,雖然它不應該是可能的。我希望,這是不可能超越JavaScript的結果,因爲我們可以安全地假設它打破了第一個「<」字符左右?如果我們不能,用戶實際上必須分別登錄每個瀏覽器選項卡... – 2010-04-06 11:43:07

相關問題