ソース：
訳：
アプリケーションの詳細について説明すると、これはユーザーが (運転免許証、パスポートなど) などの確認書類をアップロードする必要がある入札サイトでした。
サイトの入札セクションにアクセスするために。
検証ドキュメントのアップロード エンドポイントでこれを詳しく調べたところ、送信できるのは 1 回だけであることがわかり。
つまり、ドキュメントをアップロードすると、その後は変更を加えることはできず。
その後、スタッフが手動で検証します。
これは、ユーザーが確認ドキュメントをアップロードするときに行われたリクエスト。
このリクエストではありません csrf token、csrf に対して脆弱である可能性があることを意味します。
私はすぐに fetch メソッドを使用して csrf poc を作成しました。
<script>
fetch("https://www.redacted.com/api/verification/upload", { mode:"no-cors", method:"POST", headers: { "Content-Type":"multipart/form-data; boundary=----------------13370927811733493724828129654" }, body:'----------------13370927811733493724828129654\nContent-Disposition: form-data; name="file"; filename="test.png"\r\n\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00\xe1\x00\\n-----------------------------13370927811733493724828129654\nContent-Disposition: form-data; name="file" undefined\r\nundefined\n-----------------------------13370927811733493724828129654--' })
</script>
この HTML ファイルをブラウザで開くと、リクエストの応答は 403 禁止 でした。
後で、これは Origin チェックのせいだと気づきました。
リクエストのスクリーンショットでは、Origin ヘッダー値が次のように設定されていることがわかります。
https://www.redacted.com
例えば。 https://www.attacker.com/csrf.htmlその場合、Origin ヘッダー値は次のようになります。 https://www.attacker.comフェッチ要求が行われたとき。
として https://www.attacker.comと一致しません https://www.redacted.comオリジン チェックが 失敗したため、サーバーは 403 禁止エラー を返しました。
それから私は次のようないくつかのバリエーションを試しました redacted.commxyz, redacted.com.xyz , xyz.redacted.comにありました Origin ヘッダー が、どれも機能しませんでした。 開発者は、ドット文字のエスケープを忘れたなど、正規表現で何らかの間違いを犯すことがあり ます 。 そのような場合は、そのようなバリエーションを使用することで回避できます。
ヘッダーを完全に削除して Origin 次に、リクエストから リクエストを転送したところ、 200 ok レスポンス が機能し、ファイルが正常にアップロードされたことがわかりました。
ヘッダーがない場合 リクエストにOrigin 、アプリケーションはそれを検証しません。これは、 Referer チェックが設定されているため、content 属性が に設定されたメタ タグを使用した場合のシナリオと似ています。 no-referrer
なしでリクエストを行うことができる方法がないかどうかを探し始めました。 そこで、 Origin ヘッダ リクエストで送信されています。
こんなツイートを見つけました
1. Base64 encode your csrf form
— Mr_7h3xc4 (@mr_7h3xc4) 2020年4月23日
2. Use data uri:
data:text/html;base64,<encoded form here>
3 . set this as src attribute for iframe on your server.
4. Visit this link. Request will be sent without referer header.
これに従おうとしたところ、うまくいきました。
リクエストは Origin ヘッダーなしで送信されました。
の の 同様 その他 や フェッチ ただし、データ プロトコルを使用して iframe 内で Form メソッドを使用した場合にのみ機能しました。
の場合には、 Origin ヘッダーが常に送信されます。 関連 メソッド
ヘッダーという 1 つの問題は解決しました Origin が、対処すべき問題がもう 1 つありました。
メソッドにこだわっているため Form 、実際には csrf poc インタラクションレスを作成することはできません。
脆弱なリクエストをもう一度見てみると、次のようになります。
12 行目（Content-Disposition: form-data; name="file"; filename="x.png";）を見てください。
ファイル名 パラメーターがあり、その後に 画像 データがあります。
問題は、 ファイル名 パラメータと画像データを独自に csrf poc に実際に含めることができないことです。
使用される場合にのみ含まれるためです ファイルアップロード入力が 。 これについて詳しくは、この記事をご覧ください。
現在の poc は次のようになります。
この gif でわかるように、この csrf 脆弱性 を悪用するには、被害者にアップロード ボタンをクリックしてシステムからファイルを選択するように指示する必要があります。
ユーザーとの対話が必要なため、被害者が指示どおりにファイルをアップロードすることは非常に非現実的になります。
この瞬間、私は Liveoverflow による 10 万ドルのハッキング賞コンテスト中に Google Cloud Platform (GCP) で見つかったバグについて話しているビデオを見たことを思い出しました。
ため、先に進む前に必ずこのビデオを最後まで見てください。 Liveoverflow が ここで詳しく説明している
このイベント中に提出されたバグの 1 つは次のとおりです。
このブログでは、研究者 @obmihail 詳細とともに がcsrf バグの で見つかったバグに関する詳細も共有しています 、マルチパート リクエストの解析 。このバグにより、HTML フォームでは不可能な独自のコンテンツを含むファイルをアップロードできるようになりました。
上記のフォームを送信すると、次のリクエスト本文が送信されます。
>To
exploit this csrf vulnerability we have to tell the victim to click on
the upload button, and then choose a file from their system.
ユーザーの介入なしで csrf 攻撃を実行できるようになりました。
最終的な CSRF POC は次のとおりです。
name 属性にさらに焦点を当てます。 name=’\”;name=file;filename=d0B5jW1O_400x400.png;x’、このトリックを使用すると、被害者にファイルをアップロードさせることなく、偽の文書をアップロードできます。画像ファイルは、ユーザーの操作なしで自動的にアップロードされます。
ほなほな。
