ZTXBAS のオリジンバインディング
オリジンバインディングは ZTXBAS の中核となる保護です。フィッシングサイトでの操作を利用して、本来のアプリへのログインを不正承認させる攻撃に対抗します。
解決する問題
一般的なプッシュ MFA では、利用者が paypal-secure.example.com のような偽サイトにパスワードを入力し、攻撃者が正規サービスにその情報を転送できます。正規サービスが本人確認のプッシュを送ると、利用者は自分のログイン操作だと思って承認し、攻撃者にセッションが奪われるおそれがあります。
オリジンが通知に結び付いていなければ、スマートフォン側ではアクセス元の正当性を比較できません。
ZTXBAS の動作
各チャレンジは作成時にオリジンへ結び付けられ、そのオリジンが利用者のスマートフォンに表示されます。

RP は POST /v1/origins で事前登録したオリジンに対してのみチャレンジを作成できます。未登録の https://phishing.example.com は 403 UNREGISTERED_ORIGIN になります。
順番に実行される 3 つのチェック
- HMAC を検証: アプリのシークレットで署名されたリクエストかを確認します。フィッシングサイトは正当なシークレットを所有していません。
- オリジン登録を確認: 指定されたオリジンが当該アプリの
originsに存在することを確認します。 - ユーザーの存在を確認: 列挙や大量チャレンジの発生を抑止します。
3 つをすべて通過してからモバイル端末へプッシュ通知が送られます。
オリジンの正規化
比較時に、スキームとホストは小文字になり、標準ポート(HTTPS の :443、HTTP の :80)は除去されます。パス付きの URL は認められません。形式は scheme://host[:port] です。
したがって HTTPS://APP.example.com:443 と https://app.example.com は同じオリジンとして扱われ、正規化した値がチャレンジおよび JWT の origin に記録されます。
JWT の origin claim
承認後の JWT に含まれる origin を、バックエンドが期待するオリジンと照合してください。別の正当なオリジン向けに取得された JWT の転用を防ぐための確認です。
if claims.Origin != "https://app.example.com" {
return errors.New("token issued for a different origin")
}