`aws sso login` をブラウザ側JavaScriptだけで実現しようと10時間格闘した結果、セキュリティを落とさず達成するのは無理だとわかった話

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

それでもやる方法を考える。たぶん、/etc/hosts やprivate hosted zoneを使ってdomain nameそのままproxyサーバーに接続さえさせてしまえばsigv4で矛盾が発生しないので、突破できる可能性はある。 が、手間が多すぎる・・。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

WASMは結構やんちゃできるっぽいからVM動かしてその中でって思ったけど、さすがに外道がすぎる気がする。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

あとはchrome extension使えば割と無法なこともできる気がする、が、それでもcors制約破壊できるかは疑問。 corsというか、sigv4が強すぎる。これとcorsの組み合わせが強くてどうにもならん。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

github.com/aws/aws-sdk-js… で書かれている、cros OK/NGの基準はまじで意味不明だが、仕組みが良くできていることは確か。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

考え方が、世界で一番売れている拳銃はガバだから、それだけ多くの素人が使う可能性がある → ガバだけ3つ安全装置つけよう、みたいな感じなのでほんとうに納得いっていないが。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

SSO-OIDC関連の処理だけproxyというか、それ関連まるごと代行するような専用APIを作れば行けるか？その専用APIとの間はsigv4じゃないし、それらから生成したaws api用credentialsはSSO専用とかじゃないので普通に使えるはず。athena apiはcors対応しているしそこの問題はない。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

C#とかネイティブアプリでのAWS SSOログインのロジックはそういった仕組みに近い。 ただ、それをAPIとブラウザでやってしまうとAPIとブラウザ間の通信でcredentialsが流れてしまうんだよな。HTTPSだとはいえ、MITMなどのリスクがある。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

corsを回避しようとした結果、corsがないよりセキュリティ強度が下がるってジョークかよ。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

だめだ、aws apiのcors設定が馬鹿げているように感じられたとしても、それを回避するためにcorsがないよりセキュリティ強度が下がるのは許容できない。 加えて、たぶんcorsをバイパスすることはできない。現実的に可能な方法があるなら、それはセキュリティホールとして認識されているはず。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

やりたかなかったが、SSG諦めてサーバサイドへロジック込めた上でcredentialsもそこに置くか。 まあiam instace profileなどroleのあタッチもできるしAWS推奨の方法なので簡単ではある。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

使う人がそれぞれデプロイしないといけないという点、それが本質的には必要ないという点(CORSの制限さえ外されていればブラウザ側で完結する)、そもそもAWSではcloudrunに当たるようなdockerイメージだけ用意すればとりあえずデプロイしてくれる便利サービスがない点などが気に入らないだけで。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

最後のやつはapp runnerか。存在感うすすぎて完全に忘れていた。 良い機会なので、今回ちょっと触ってみても良いかもなあ。 だめならいつも通りAPI gateway + lambdaになるけど。