在傳統應用程序中改寫csrf並重寫url

Question

我正在使用遺留的java應用程序（13yrs +），它沒有防止CSRF攻擊的機制。

在前端它使用多種技術，dwr，jquery和請求來自各種來源，AJAX，形成sumbitting帖子，獲取請求。使用Get請求進行的非安全操作應受CSRF保護。

在後端，所有事情都通過Struts操作。

沒有合適的自動功能測試，應用程序非常龐大，沒有人知道它是如何工作的，因此無法輕鬆引入更改。

要將應用程序添加到每個獲取鏈接和每個表單提交中都很困難。對於DWR和jQuery，事情更簡單，因爲所有請求都有一個入口點。

該應用程序不需要使用瀏覽器書籤，它在內部提供了一個收藏夾菜單，在該菜單中保存特定的書籤。 此外，表單動作或鏈接的url總是通過struts或標準taglib呈現。因此，如果我將JSESSIONID更改爲通過url重寫而不是cookie，則應用程序可能會稍作更改...

這給了我下面的想法，不需要大量的開發工作就可以將CSRF保護引入到應用程序中：

*使用URL重寫而不是cookie來傳遞JSESSIONID。 *爲了克服在頭中顯示JSESSIONID的問題，爲http會話引入第二個祕密cookie。因此，當會話第一次建立時，將包含隨機值的HttpOnly cookie發送回客戶端，並將其放入HTTP會話中。 *在所有struts Actions的父項中，使用HTTP會話中的值檢查此祕密cookie的值，如果不相等，則拋出異常。

與重寫應用程序以在每個請求中引入令牌的巨大努力相比，這似乎是一種簡單的方法。也許太容易了......我的想法有沒有一個錯誤？

Answer 1

在上一篇文章中，我想使用jsessionid作爲csrf標記進行Url重寫，並使用第二個自定義HttpOnly cookie進行身份驗證。 但最後我決定：

• 不使用使用JSESSIONID作爲CSRF令牌，但保持它的認證，因爲它在默認情況下設計的。

• 使用Origin標題保護表單提交和ajax調用。這不包括執行非安全操作的獲取請求。另外，它只適用於較新的瀏覽器。

• 保護用csrf標記獲取請求。應用程序中的URL由標籤c：url，html：rewrite組成，所以它只是用包含csrf標記的自定義標記覆蓋這些標記的問題。