更新請求方法和內容類型篩選來獲得 CSRF 防護
跨網站偽造請求 (CSRF) 是一種以 Web 為基礎的攻擊，會代表不知情的受害者提交經過偽造的請求。如果使用者目前已向某個網站進行驗證且可經過拐騙來提交某個惡意的指令，攻擊者便可使用受害者的認證來發出狀態變更請求。
如需詳細資訊，請參閱下列連結：
針對 CSRF 攻擊的一個常用防禦方法是使用已同步處理的權杖。不過，ThingWorx 採用了一個替代方法，改為透過一個嚴格的內容類型篩選器來路由所有請求。此方法具有同樣的安全性，而且更適合無狀態實行。
更新請求方法
依預設，無法經由請求參數來變更請求方法。如果您的應用程式是使用這些作法開發而成，您可以：
• 移除會透過請求參數將 GET 方法變更為 POST 方法的任何程式碼。這是建議的最佳作法。
 |
這並不是建議的最佳作法，而且這麼做即表示接受讓您的實行/應用程式承受 CSRF 的風險。
「允許請求方法轉換」選項已淘汰，將會在未來的 ThingWorx 發行版本中移除。
|
內容類型篩選
已實行 ContentTypeFilter 來核對請求標題中的內容類型是否為適用於所有 POST、PUT 和 DELETE 方法的 application/json、application/xml 或 text/xml。若請求為 multipart/form-data，它將會檢查是否存在值為 TWX-XSRF-TOKEN-VALUE 的 X-XSRF-TOKEN 標題。此 multipart/form data 的請求是用於檔案上載。
• 若執行檔案上載，您的瀏覽器必須實行 FormData 物件。
 |
舊版瀏覽器 (Internet Explorer 9 和較舊版本) 並未提供 FormData，因此若包括 ContentTypeFilter，將無法在這些瀏覽器中進行檔案上載 (包括實體和延伸功能匯入項目)。
|
|
|
Filter Content-Type 選項已淘汰，將會在未來的 ThingWorx 發行版本中移除。
|
CSRF 防護的最佳作法
請遵循下列指導方針來維持 CSRF 防護：
• 開發新的應用程式時，在 Composer 中建構的所有混搭都是安全的。如果您正在使用透過 REST API 存取 ThingWorx 的自訂 UI，請確保您沒有在其中包括需要方法轉換的任何請求。
• 開發新的 Java 延伸功能時，請確保透過 ThingWorx 服務註釋架構來顯示所有新服務。此架構負責識別所有的傳入請求，以及將它們對應和路由至服務的實行。使用 ThingWorx 服務註釋建立和顯示的所有服務都將免遭 CSRF 危害。
• 在新服務必須旁路 ThingWorx 註釋架構的少數情況下，請確保服務只對 GET、POST、PUT 或 DELETE 方法有反應。
相關連結