使用自定義所需的HTTP頭作爲API的CSRF的保護方法是否安全？

我有它僅接受以「接受：應用/ JSON的」請求SPA內置了JSON API頭。因此，在瀏覽器中提交以下表單將導致「不可接受」。 HTTP錯誤。使用自定義所需的HTTP頭作爲API的CSRF的保護方法是否安全？

<form method="POST" action="https://api.example.domain/resource"> 
    <input type="password" name="password" value="CSRF"> 
    <input type="submit" value="Click!"> 
</form>

這是否意味着API對CSRF類型的攻擊具有免疫力，或者我錯過了什麼？

來源

2017-07-19 tooleks

應該是相當安全的，不過，有一個機會，API是脆弱的。

如果攻擊者能夠在網站中發現XSS漏洞，他可以使用JavaScript添加標頭：Accept: application/json，然後執行CSRF攻擊。

因此，值得推薦的是依靠一些無法由JavaScript設置的標頭，因爲它們位於'禁止'標題列表中，只有瀏覽器可以修改它們，因此在這裏不能使用XSS漏洞。

您將在OWASP找到更多的信息：https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

來源

2017-08-25 11:43:09

豪爾赫您好，感謝您分享了一個漂亮的文章。因此，如果REST API會在每個響應中設置「Access-Control-Allow-Origin：https：// domain.name'頭部，我還應該檢查Origin和Referer頭部還是足夠？ – tooleks

對我來說似乎夠了。但是，在向Web應用程序添加安全性時繼續進行的最好方法是遵循OWASP準則。即使你認爲它已經足夠安全，你可能會錯過一些東西。所以，我建議你仍然使用'Origin'或'Referer'頭文件，甚至同步令牌 –

我不認爲這將是安全的，因爲你無法實現在同一時間的所有的預防方法。當然，添加CORS支持，HTTP Only標誌和其他方法可能會阻止你被黑客入侵，但你並不完全安全。

而不是重新發明通過實施所有的預防方法輪，我認爲它能夠更好地使用現有的標準包裝或中間件，以防止對您的應用程序CSRF攻擊。這些代碼比您能做的更好地清理輸入。

可以使用最好的（我最喜愛的包裝）中的一個，https://github.com/ring-clojure/ring-anti-forgery防止CSRF攻擊。如果您使用節點作爲您的後端用途，這裏是另一個最好的中間件，https://github.com/expressjs/csurf。

我不會說它不可能自己編寫代碼來防止CSRF攻擊，但我認爲它使用現有標準代碼段並專注於開發功能的智能方式將會節省更多時間。

來源

2017-08-27 10:48:11

Hi Rewanth，謝謝你的回答。它的主要問題是，前端應用程序是一個完全獨立的應用程序，所以我不能使用此解決方案（CSRF的令牌隱藏字段注入由後端），因爲後端沒有使前端HTML它僅提供了REST API。 – tooleks

使用自定義所需的HTTP頭作爲API的CSRF的保護方法是否安全？

回答

相關問題