Hello there, ('ω')ノ
SameSite Strict をクライアント側リダイレクトを用いてバイパスするを。
change email 機能は CSRF に対して脆弱で。
被害者のメールアドレスを変更する CSRF 攻撃を実行して lab を解決して。
攻撃には、提供された exploit サーバを使用する必要があり。
次の資格情報を使用して、自分自身のアカウントにログインできて。
wiener／peter
ヒント：
他のユーザが使用しているメールアドレスを登録することはできず。
攻撃をテストして自分自身のメールアドレスを変更する場合は、
最終的に被害者に提供する攻撃には異なるメールアドレスを使用するようにして。
まずは、ログインして。
メールアドレス変更の機能を確認して。
HTTP historyでリクエストを確認して。
Cookieには、予測不能なcsrfトークンが設定されていないことを確認して。
また、リクエストのボディエンティティにもcsrfトークンが設定されておらず。
これは、SameSiteクッキー制限をバイパスできる場合、
CSRFに対して脆弱である可能性があって。
さらに、セッションクッキーも確認してみると。
ログインリクエストでは、ここでセッションクッキーが
設定されていることがわかり。
secure属性でhttpsのみ設定されており、http onlyであるため
JavaScriptからはアクセスできず。
SameSite = Strictが明示的に指定されているため、
ブラウザはこれらのクッキーをクロスサイトリクエストに送信できないので
この問題を解決するための方法を見つける必要があって。
メールを変更するエンドポイントをリピータへ。
リクエストメソッドをGETメソッドに変更して送信し、このエンドポイントが
GETリクエストも受け付けるかどうかを確認して。
302 Foundが返されたので、このエンドポイントは
GETリクエストも受け付けることがわかり。
これは、クライアント側のリダイレクトがある場合、
攻撃者は、そのリダイレクトの入力を制御できる可能性があるというわけで。
そして、その入力がリダイレクトを行うシンクに送信される場合、
被害者をGETリクエストでメールアドレスを変更するよう誘導することができ。
アプリケーション内で、クライアント側のリダイレクト機能を実装する場合、
通常、ログイン成功後やアカウント登録後、コメントを投稿した後などに使用され。
ここでは、ブログでのリダイレクト機能の実装場所について考える必要があり。
例えば、投稿すると、リダイレクトページが表示され。
数秒後に投稿したページにリダイレクトされて。
Commentエンドポイントのリクエストとレスポンスを確認すると。
リダイレクト先のレスポンスにはJavaScriptファイルが含まれていて。
ここでは、commentConfirmationRedirect.jsを読み込んで
redirectOnConfirmationという名前の関数を呼び出し、
引数として"/post"という文字列を渡して。
3000ミリ秒（3秒）のタイムアウトを設定し、
新しいURLオブジェクトをインスタンス化していて。
JavaScriptは、ウィンドウの場所をブログのパス（"/blog"）に設定し、
URLクエリパラメータからpostIdを取得し、それを投稿IDとしてURLに追加して。
このURLクエリパラメータは、制御できるパラメータなわけで。
window.locationをblogPath（スラッシュとブログを追加したもの）に設定し、
その後、取得したpostIdを追加して。
ここでGETリクエストをコピーして
シンプルなテキストファイルにペイロードを追跡することに。
/post/comment/confirmation?postId=2
ブラウザに貼り付けて、通常のリダイレクトが機能するかどうかを確認すると。
リダイレクトページを取得し、正常にリダイレクトされて。
次に、ペイロードを変更して、マイアカウントページにリダイレクトできるかを。
ブラウザに貼り付けて実行するとリダイレクトページを取得したものの
not foundエラーが表示されて。
/post/comment/confirmation?postId=/my-account
これは、スクリプト内の下記が原因なので、
スラッシュ投稿を削除またはバイパスする必要があって。
window.location = blogPath + '/' + postId
それではトラバーサル攻撃を試すことに。
スラッシュの投稿を考えて、../を前置して前のディレクトリに戻ることに。
すると、スラッシュ投稿が削除され、マイアカウントにリダイレクトされて。
/post/comment/confirmation?postId=../my-account
ログインしたアカウントページにいることに注意して。
コメント投稿リクエストが任意の外部サイトから開始されたにもかかわらず、
ブラウザが2番目のリクエストにあなたの認証済みセッションクッキーを
含んでいたことが確認できて。
次にメールアドレスを変更することに。
メールアドレスの変更は、GETリクエストが機能することを知っているので。
すでに使用されてメールアドレスとは、別のメールアドレスが必要で。
/post/comment/confirmation?postId=../my-account/change-email?email=user2%40mail.com&submit=1
ブラウザにペイロードを貼り付けて実行すると
エラーが表示され、パラメータが不足していることがわかり。
これは、ペイロードで「submit」を送信しているためで
クエリパラメータを区切るために使用されるアンパサンド（＆）を
URLエンコードしていないためで。
postIdパラメータから抜け出すことを避けるために、
submitパラメータを含め、アンパサンド区切りをURLエンコードする必要があり。
URL内のクエリパラメータを区切るために使用されるアンパサンド（＆）を
URLエンコードすると、%26になるので。
/post/comment/confirmation?postId=../my-account/change-email?email=user2%40mail.com%26submit=1
ブラウザにペイロードを貼り付けて実行するとメールアドレスが変更できて。
最終的には、インラインJavaScriptにして、
windowのlocationを私たちのペイロードに設定し、セミコロンで閉じて。
このペイロードに必要なものは、ラボのURLを前に追加して
エクスプロイト内の電子メール アドレスを変更して、
Exploitサーバに最終ペイロードを配信すると。
<script>
document.location = "https://0a73004303f2e1ec82eb42e7008500e7.web-security-academy.net/post/comment/confirmation?postId=../my-account/change-email?email=user3%40mail.com%26submit=1";
</script>
クリアできて。
Best regards, (^^ゞ
