ソース：
訳：
Microsoft は、これはセキュリティ プログラムの範囲外であり、セキュリティ上の脆弱性とはまったくみなしていないと回答したため、これについて記事を書くつもりです。
「これは、ユーザーが悪意のあるコードをコピーしてテキスト フィールドに貼り付けるか、ユーザー側のコード/トラフィックを変更する必要があるため、セキュリティ サービスの基準を満たしていません。 このような自己標的型攻撃は、別のユーザーを標的にするためにソーシャル エンジニアリングが必要となるため、セキュリティ上の脆弱性とはみなされません。」
2020 年 3 月 24 日更新:
実際、Microsoft は 3 月 23 日に拒否された脆弱性を再評価しており、これらの問題は実際にサービスの基準を満たしています。
私は責任ある開示を重視しているため、パッチが適用されるまで詳細は削除されます。
「この提出物は、反映された XSS ではなく自己 XSS として誤って評価されました。 後で私たちに、これらはサービスの基準を満たしていると知らされました。」
この脆弱性のおかげで、私は実際に 2020 年 3 月のマイクロソフトの初心者の殿堂入りを果たしました。
ということです この経験から学んだ教訓は、適切なエスカレーションなしに反映された XSS を Microsoft に決して送信してはいけない 。
以下の記事で説明されているように、その可能性は大いにあると信じていただいて結構です。
影響を受けるドメイン:
- activateuat.microsoft.com
- gallery.technet.microsoft.com
- ppe.gallery.technet.microsoft.com
- ppe.code.msdn.microsoft.com
反映された XSS で何ができるでしょうか?
攻撃者が被害者のブラウザで実行されるスクリプトを制御できる場合、通常はそのユーザーを完全に侵害することができます。
攻撃者は特に次のことを行うことができます。
- ユーザーが実行できるアプリケーション内でのアクションを実行します。
- ユーザーが表示できる情報を表示します。
- ユーザーが変更できる情報を変更します。
- 最初の被害者ユーザーから発生したように見える、悪意のある攻撃を含む、他のアプリケーション ユーザーとのやり取りを開始します。
脆弱性の発見:
このような脆弱性を見つけるのは難しくありません。 次のコマンドを実行しました。
assetfinder -subs-only microsoft.com | httprobe | cookieless
最後の github リポジトリは、手動テスト プロセスを自動化するために私が作成したツールです。 他の研究にも役立つことを願っています。
Cookie レスとは何ですか? それを反映型 XSS に変えるにはどうすればよいですか?
基本的に、これは、開発者がリソースを解決するためにチルダ記号を使用した場合に .NET Web サイトでのみ機能します。
<script src=”<%= ResolveUrl(“~/Script.js”) %>”></script>
次の例の URL の Cookie のない部分 (A(ABCD)) は、設計上 HTML エンコードされていないため、攻撃者が次の URL の HTML タグのコンテキストをエスケープできます。
https://gallery.technet.microsoft.com/(A(ABCD))/
これは <script src=”/(A(ABCD))/Script.js”> に変換され。
すべての文字がサポートされているわけではありませんが、十分に工夫すればアラートをポップアップ表示する方法を見つけることができて。
あなたが攻撃者であれば、前述したようにアラート以外のこともできることは明らか。
https://gallery.technet.microsoft.com/(A(%22onerror='alert%601%60'testabcd))/
これらのドメインの一部には Content-Security-Policy さえないため、Cookie なしの識別子で許可される URL の長さと文字の範囲内で定義した制限をバイパスして、サードパーティの場所からのスクリプトを実際に組み込むことができます。
ほなほな。
