CSRF 対策のためのリクエストメソッドの更新とコンテンツタイプのフィルタ
クロスサイトリクエストフォージェリ (CSRF) は、悪意のない被害者を装って偽のリクエストを送信する Web ベースの攻撃です。現在ユーザーがサイトで認証されており、だまされて悪意のあるコマンドを送信する余地がある場合、攻撃者は被害者の資格情報を使用して状態変更リクエストを要求できます。
詳細については、以下のリンクを参照してください。
CSRF 攻撃に対する一般的な対策は、同期化されたトークンを使用することです。ただし、ThingWorx は異なるアプローチを使用しており、厳重なコンテンツタイプフィルタを通してすべてのリクエストをルーティングしています。このアプローチは同等のセキュリティを確保すると同時に、状態のない実装により適しています。
リクエストメソッドの更新
デフォルトでは、リクエストパラメータによってリクエストメソッドを変更することはできません。アプリケーションがこのような方法を使用して開発されている場合は、以下の処理を実行できます。
• リクエストパラメータを介して GET メソッドを POST メソッドに変更するコードを除去します。これは推奨される最良事例アプローチです。
 |
これは推奨される最良事例ではありません。これを実行する場合は、実装/アプリケーションが CSRF にさらされる可能性があることに注意してください。
「リクエストメソッド切り替えを許可」オプションは廃止されており、将来の ThingWorx リリースでは除去される予定です。
|
コンテンツタイプのフィルタ
すべての POST、PUT、および DELETE メソッドに対してリクエストヘッダーのコンテンツタイプが application/json、application/xml、text/xml のどれかであることを確認するために、ContentTypeFilter が実装されています。リクエストが multipart/form-data の場合、それは TWX-XSRF-TOKEN-VALUE という値の X-XSRF-TOKEN ヘッダーを確認します。この multipart/form-data のリクエストは、ファイルアップロードを目的としています。
• ファイルアップロードを実行する場合、ブラウザが FormData オブジェクトを実装する必要があります。
 |
FormData は古いブラウザ (Internet Explorer 9 以前) では使用できないので、ContentTypeFilter が含まれている場合、これらのブラウザではファイルアップロードが機能しません (エンティティや拡張機能のインポートを含む)。
|
|
|
「プラットフォームサブシステム」で Filter Content-Type オプションをオフにすることもできますが、その場合には、実装/アプリケーションが CSRF にさらされる可能性があることに注意してください。
Filter Content-Type オプションは廃止されており、将来の ThingWorx リリースでは除去される予定です。
|
CSRF 対策の最良事例
CSRF 対策を維持するには、次のガイドラインに従います。
• 新しいアプリケーションの開発時、Composer で構築されたマッシュアップはすべてセキュリティで保護されます。カスタム UI を使用して REST API 経由で ThingWorx にアクセスする場合は、メソッドの切り替えが必要なリクエストが含まれていないことを確認します。
• 新しい Java 拡張機能を開発するとき、すべての新しいサービスが ThingWorx サービスアノテーションフレームワークを介して公開されるようにする必要があります。このフレームワークは、すべての受信リクエストをサービスの実装に照らし合わせて識別、マッピング、およびルーティングします。ThingWorx サービスアノテーションを使用して作成および公開されたサービスはすべて CSRF から保護されています。
• 新しいサービスが ThingWorx アノテーションフレームワークを省略しなければならないケースがまれにありますが、その場合、サービスが応答するのは GET、POST、PUT、または DELETE メソッドのみである必要があります。
関連リンク