2013-10-21 51 views
0

我需要處理使用Jekyll構建的靜態網站的查詢表單。防止使用查詢表格的靜態網站(即Jekyll網站)針對JSONP請求僞造JSONP請求

查詢表單向另一個處理請求的域上的PHP應用程序提交JSONP請求(GET)。

是否可以防止CSRF,因爲表單將是靜態的?

我注意到了PHP Slim Framework的CSRF中間件只能保護POST,PUT & DELETE方法,而不是GET。

如果我在靜態站點中創建腳本,那麼每個頁面上的表單加載的服務器請求的數據(cookie值,csrf標記以及字段值等)可以工作嗎?

感謝您的時間對CSRF

+1

你想要保護什麼?如果用戶沒有以任何方式進行身份驗證,則提供CSRF保護沒有任何好處。是這樣嗎? – SilverlightFox

+0

這是正確的,用戶沒有被認證。 – Globalz

+1

沒有必要保護CSRF,因爲表單在當前用戶的上下文中沒有獲得任何東西 - 如果攻擊者想要在您的網站上提交表單,則不需要「跨站點」。他們只會提交它。聽起來好像你在使用CAPTCHA來防止機器人提交表單(如果這就是你真正的追求?)。 – SilverlightFox

回答

1

因爲表單在當前用戶的上下文中沒有獲得任何東西 - 因此,如果攻擊者想在您的網站上提交表單,則不需要「跨站點「......他們只會提交它。

聽起來好像你是在CAPTCHA之後,以阻止機器人提交表單(如果這是你真的以後?)。

1

防禦取決於從哪個發送請求的頁面,並在服務器上,它被送到同意的用戶的唯一標識符。

由於表單是靜態的,所以不能在表單中放置該唯一標識符。

如果我在靜態網站中有一個腳本構建每個頁面上的表單加載與服務器請求的數據(cookie值,csrf標記以及字段值等)可以工作嗎?

只有當它是服務器端腳本(所以表單不會是靜態的),否則任何站點都可以包含它以獲取令牌。


我注意到了PHP框架修身的CSRF中間件只能從POST保護,PUT & DELETE方法,而不是GET。

這是因爲GET requests shouldn't be doing anything in the first place,所以(除非你濫用它們),不需要對它們應用CSRF保護。

特別是,該慣例已經確定,GET和HEAD方法不應該具有采取除檢索以外的行爲的意義。這些方法應該被認爲是「安全的」。這允許用戶代理以一種特殊的方式表示其他方法,例如POST,PUT和DELETE,以便使用戶意識到正在請求可能不安全的操作的事實。

+0

謝謝你。我現在認爲CORS可能更好,因爲它支持的不僅僅是GET請求,而不像JSONP – Globalz

+0

即使使用CORS,CSRF仍然是個問題。攻擊只需要提出請求,它不需要將響應暴露給JS。 – Quentin

+0

很酷。我想通過一個簡單的get jsonp請求提供服務器提供的csrf令牌的JavaScript編譯表單,因爲它只是檢索。表單提交將向PHP應用發出CORS POST請求,以驗證請求並採取必要措施,例如發送帶有表單值的電子郵件 – Globalz