我想讓Twilio與我的express/node.js安裝一起工作。 Twilio在收到短信時正在向我的服務器發送傳入連接。然後我用短信答覆回覆此問題。CSRF與Twilio
這是第一次。然後第二次,我的服務器阻止Twilio,因爲它說它是僞造的請求。
有沒有適當的方法來解決這個問題?
我想讓Twilio與我的express/node.js安裝一起工作。 Twilio在收到短信時正在向我的服務器發送傳入連接。然後我用短信答覆回覆此問題。CSRF與Twilio
這是第一次。然後第二次,我的服務器阻止Twilio,因爲它說它是僞造的請求。
有沒有適當的方法來解決這個問題?
您應該爲該URL禁用CSRF。看到這個問題如何做到這一點:Disable csrf validation for some requests on Express
CSRF是一個漏洞,只涉及需要cookie的形式的會話信息的請求(這就是爲什麼CSRF有時也被稱爲「會話騎」)。簡而言之,CSRF是指惡意網站所有者可以在他們控制的頁面上使用<form>
標籤來向您的網站發佈表單,從而在用戶不知情的情況下將已驗證的請求發送到您的服務器。例如,假設Facebook有一個/delete_user.php,它會刪除當前已通過身份驗證的用戶。對該URL的CSRF攻擊將採用惡意網站所有者網站上<form action="http://facebook.com/delete_user.php">
標記的形式(無雙關語),該標記在用戶不知情的情況下提交。 /delete_user.php的非CSRF安全實現將會看到用戶的auth cookie並刪除用戶 - 這對用戶的沮喪很大。
無論如何,長話短說,您的Twilio處理程序不需要用戶的瀏覽器cookie,因此不受CSRF攻擊。只需禁用Twilio回調URL的CSRF檢查。
感謝您的精彩解釋。我將禁用該控制器的csrf檢查。我很好奇,爲什麼瀏覽器會允許另一個網頁騎在另一個網頁上。爲什麼瀏覽器不在網站之間分配cookie? – Alexis 2013-02-10 22:24:22
瀏覽器*確實在站點之間分割Cookie。攻擊者沒有時間訪問實際的facebook.com cookie(從上面繼續我的示例)。執行此攻擊是爲了在用戶的瀏覽器內部提交GET/POST請求以引起一些副作用。 – tom 2013-02-10 22:52:29
啊。得到它了。非常感謝你! – Alexis 2013-02-10 23:17:58