SaaS購入した製品の脆弱性についてはどうすればよいですか？

Question

私は大学で働いており、SaaS学習管理システム（例：Moodle、Canvas））を大学の他のシステムと統合するチームのメンバーです。

2か月前、私はCSRF攻撃を特定しました。これは、システムにコース教材を追加できるすべての人（主に講師だけでなく、他の教員や家庭教師も）が利用できます。問題は、コース資料にJavaScriptが含まれている可能性があり、コース資料を表示している管理ユーザー（たとえば、サポートリクエストへの応答として）がJavaScriptを実行することです。システムが（公開文書化された！）REST APIを使用するようになったため、上記のJavaScriptにより、特にユーザーをシステム管理者に昇格させることができます。特に、Webサイト自体REST APIを全体的に使用します。つまり、JavaScriptはAPI呼び出しを実行できる必要があります。私は機能的な悪用のデモを開発したので、それが機能すること、そしてそれがいかに簡単かを確実に知っています。行う。

私はそれをベンダーに報告しました、そして彼らの即時の応答は「講師は信頼されたユーザーであり、これは設計通りに機能しています」でした。私の怒りの答えは、「講師がシステム管理者であるとは信じていません」でした。単純なDBクエリによると、システムには、合計で最大50000人のユーザーのうち、javascript素材をアップロードできる約4000人以上のユーザーがいます。 2か月後も、当初の対応に固執しています。

私は自分の教育機関のシステムについて少し心配しています：予期しない管理者が表示されるかどうかを通知するためにいくつかの外部監視スクリプトを実装しました。オフラインバックアップがあります。ただし、このエクスプロイトが世界中のそのようなすべてのインストールに影響を与えることも気になります。これは、一般的に実行されるシステムです（おそらく> 1000インスタンス）。

これはSaaSであるため、システムを自分でブロックするための十分なアクセス権がありません。

だから私は関連する質問のグループを持っています：

この攻撃は許容可能ですか、それとも大規模なエンタープライズシステムで一般的ですか？
ユーザーが生成したコンテンツをsandbox属性でiframeにラップすると、CORSを使用してREST API。へのリクエストを防ぐことにより、この攻撃がブロックされます（管理者が最新のブラウザーを使用する場合）。これは安全ですか？ユーザーがアップロードしたJavaScriptを安全にすることはできますか？
ベンダーが修正を拒否した場合、私の次の動きは何ですか？それが知られていると悪用することはかなり簡単であることを考えると、公開は推奨されますか？

[〜＃〜] edit [〜＃〜]：コメントに回答するには：

記事を読んだにもかかわらず、csrfとxssの違いに少し漠然としていることは認めます。この定義により「何らかの方法でスクリプトを実行する」というのはXSSですが、「被害者のログに記録されたCookie /セッションを使用する」必要があるという点でCSRFです。また、悪用の鍵となるトークンは、ベンダーからcsrfトークンと呼ばれています。

（2）に従って、エクスプロイト/緩和がどのように機能するかについて、さらに詳しく説明します。あなたが正しいけれど;これは実際には別の質問です。

攻撃は、適切なAPIに対してPATCH RESTリクエストを実行する提供されたJavaScriptにfetchリクエストを含めることです。この場合、被害者のCookieがAPIの認証として使用されます。。GET以外のリクエストにはカスタムヘッダー（「xsrf」トークン）が必要ですが、提供されたJavaScriptが別のページからそのトークンをこすり落とす可能性があります。提案された軽減策については、現在、ユーザーが提供したすべてのJavaScriptを含むコースコンテンツは単一のdivにラップされています。divを、ユーザーのコンテンツを個別にフェッチする（またはiframeを使用する）srcdocに置き換えることをお勧めします。 allow-same-Originフラグのないサンドボックス属性。つまり、スクリプトは認証Cookieにアクセスできず、いずれにしてもCORSが原因でAPIへのフェッチ要求を行うことができません。

Anders · Accepted Answer

この攻撃は許容可能ですか、それとも大規模なエンタープライズシステムで一般的ですか？

いいえ、これはまったく受け入れられません。そして、それが一般的でないことを願っています。

ユーザーが生成したコンテンツをsandbox属性でiframeにラップすると、CORSを使用してREST API。へのリクエストを防ぐことにより、この攻撃がブロックされます（管理者が最新のブラウザーを使用する場合）。これは安全ですか？

理論的には、完全にサンドボックス化されたiframeが役立ちます。ただし、ご指摘のとおり、サンドボックス属性完全ではないのサポート。それはあなたが所有されるために古いブラウザを持つ1人の管理者だけを必要とします。

それ以外の場合、ユーザーがアップロードしたJavaScriptを安全にすることは可能ですか？

JS Fiddleのようなサイトがこの問題を解決する方法を見ることができます。それらは、ユーザー生成コンテンツを別のドメインからエコーバックし、それによってブラウザーを活用しますSOP保護のため。

しかし、SaaSを購入する場合、これを修正するのはあなたの役割ではありません。

ベンダーが修正を拒否した場合、私の次の動きは何ですか？それが知られていると悪用することはかなり簡単であることを考えると、公開は推奨されますか？

顧客としてのあなたの役割では、私はあなたに事件の弁護士を雇うことをお勧めします。あなたの契約が良いものである場合、システムを提供する会社はそれに違反しています。異なる許可レベルの製品の代金を払っている場合は、作成して納品する必要があります。現在、そうではありません。

セキュリティの脆弱性を発見した研究者としてのあなたの役割において、私は責任ある開示をお勧めします。特に、開示する前にベンダーに明確な期限を与える必要があります。

私はcsrfとxssの違いに少し漠然としていることを認めます。

他の人が指摘したように、あなたが説明するのはCSRFではなくXSSに保存されます。

jimouris · Answer

同様の議論が行われましたここ（私の古い仕事は製品に大規模なセキュリティの悪用がありますが、彼らは気にしません）と- ここに（セキュリティの脆弱性を倫理的に開示する方法は？）セキュリティの脆弱性の倫理的な開示について。

講師は信頼できるユーザーであり、これは設計どおりに機能しています。

彼らはあなたの攻撃を完全に理解しましたか？私の意見は、あなたが見つけたエクスプロイトの重要性について彼らを説得しようとすることです。彼らがあなたを無視し続ける場合は、上記のリンクで説明されているように、それを公開してください。