應用程式是用Java語言和JSF框架構建的.我已经報告了CSRF攻击，開發团队必须在應用程式投入生产後立即修複它。
我建議使用CSRF令牌，但開發团队表示可能需要一些時間来實施.
您能否建議更好，更快地修複CSRF？ 如果現在是臨時解決方案，那也没關係.之後，他们將在合理的時間內在代碼中實現正確的CSRF令牌。
最新回復
- 2019-12-51 #
- 2019-12-52 #
另一種可能性是使用相同站點cookie（
SameSite=Strict;） ）.實質上，此屬性在啟用時会阻止瀏覽器从跨站點請求發送Cookie.這可能会破壞某些功能，但這是另一个可以快速添加的想法：https://medium.com/compass-security/samesite-cookie -attribute-33b3bfeaeb95
垮台 - 並非所有瀏覽器都支援它.
- 2019-12-53 #
缓解此漏洞的唯一方法是同步器令牌模式.只有一个令牌。
尝試使用 OwASP CSRFGuard專案
對CSRF的快速解決方法是檢查
Referer和/或OriginHTTP標頭.應至少設置其中一个，並且它包含的域應该是您的域（即相同的源）.請註意，這將打破从书簽，郵件內部鏈接或類似內容訪問您的網站的情况，因為在這種情况下没有
Referer將被發送.但在任何情况下你都不應该接受一个空的Referer（除非你有一个非空的Origin標题）因為這很容易為攻击者建立.您還應该確保您對域名的檢查是正確的.這是，如果您的網站是
www.example.com你不能接受Referer類似http://www.example.com.attacker.com或者http://www.attacker.com/www.example.com或者http://www-example.com您還應该確保攻击者不能在您的應用程式中使用其他功能（或錯誤）作為蹦床来建立具有恶意負載的自定義請求，但預期的同源
Referer.由於 Arminius 在評論中很好地指出，開放重定向可能是這樣的蹦床.因此，您應该確保對域的所有請求都具有相同来源的Referer或任何可能需要接受跨源Referer的部分 不能被滥用為蹦床。有關這種防範CSRF的方法及其潜在問题的详细資訊，請參阅使用標準標题驗證相同的来源 >来自OwASP的跨站請求偽造（CSRF）預防備忘單。