今回は、セキュリティインシデントにつながりそうな内容について知見を得たので共有していきます。一言で表すならば、「アクセストークンの使用用途をちゃんとわかっていなかった」。認証・認可について軽く勉強をしていたので、問題の重さについては十分に理解できたと思います。アクセストークンを有効活用しよう！
挨拶
どうも、二週間ほどブログの休憩をしていた龍ちゃんです。お仕事は続けていたのですが、ブログを書く元気が起きなかったので思い切ってお休みしていました。プロジェクトのお仕事が急遽入って激しめの修正を加えて、勉強をしていたのでそこで得た知見についてまとめていきたいと思います。
内容としては、「ログイン後のユーザーであれば、成り済まし可能なシステム」だったというショッキング内容になります。それでは初めて行きたいと思います。この話をするためには、認証認可の話が若干入ってきて、半年前の自分ならわからなくて泣いていたなと思います。詰まった点でも成長を感じることができる良い機会でした。
問題のあるシステム
まずは、問題のあるシステムについて話していきます。ざっくりとしたアーキ図としては以下になります。
「Static Web Apps：フロントエンド」から、「Azure AD B2C」を用いて認証をしています。もちろん認証していなければ、自動で認証画面に飛ぶように設計してあり、認証されていないユーザーはアクセスできないようになっています。ここで一つ問題があるのが、フロントエンド側の「userID」を書き換えると、ほかの人のリソースにアクセスすることができるという点です。
「userID」はUUIDという一意に発行されるIDを使用しているので、予測することは難しいです。ですが、もし「userID」が流出してしまった場合、悪意を持った「ログイン後のユーザー」が「userID」を書き換えてアクセスすると、他人のリソースを覗き見ることが可能となります。
つまりセキュリティインシデントになるということですね。もちろんフロントエンドのリソースはミニファイされており、簡単に解析できないようになっています。それでもアクセスできる可能性があるだけで問題になります。
改善後のシステム
端的に解決法について書くと「アクセストークンを発行させ、検証を行うことでアクセス元を担保する」という方法になります。
「Azure AD B2C」からアクセストークンを発行して、API通信時にHeaderとしてアクセストークンを付与して送信することで、APIサーバーにアクセストークンを引き渡します。APIサーバーでは、受け取ったアクセストークンを検証して、発行元と一致しなければリソースを渡さないことでセキュアに保つことができます。
改善後のシステムで追加した機能としては以下になります。
- Azure AD B2Cからアクセストークン取得
- API通信時、Headerにアクセストークン付与
- APIサーバー側でアクセストークンを検証
この三つの対応をするだけで、改善前よりもセキュアになります。
終わりに
具体的な対応方法としては、バックエンド側の対応も併せて勉強しているのでもう少しお待ちください。Azure AD B2Cからアクセストークンを取得するのが手間かかりました。この辺は少し先にブログ化しようと思います。
心持として、「100本ブログを達成」という結果だけ見て若干燃え尽きていましたが、上司の方からのこう言ったアドバイスを受けると、技術力はまだまだだなと思います。これからもブログと検証を重ねて早急に成長しましょう。
がんばりますぅ～( *´艸｀)
