WebサービスやSaaS開発で気をつけるべき認証認可におけるロジックの脆弱性。どのようなもので、どう対策すべきか？［PR］

今回は「WebサービスやSaaS開発で気をつけるべき認証認可におけるロジックの脆弱性。どのようなもので、どう対策すべきか？［PR］」についてご紹介します。

関連ワード （予算、代表、趣味等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

WebサービスやSaaS（Software as a Service）の開発において、認証や認可における脆弱性が発覚した場合、その深刻度は大きいことが多く対策は必須です。

言うまでもなく、どんなに素晴らしい機能が提供されていたとしても、脆弱性を突かれて情報漏洩やデータ破壊などを起こしてしまえば、ソフトウェアで提供される価値が地に落ちてしまうからです。

認証と認可の脆弱性は全体の3割以上にも

セキュリティスタートアップとして多くのSaaS開発企業などにセキュリティ診断（脆弱性診断）を提供しているFlatt Security社は、同社が2022年の1月から1年強の間にBtoB SaaSを対象として検出した脆弱性を集計すると、ソフトウェアのロジックや仕様に起因するものが非常に多かったと説明しています。

しかも2位と3位には認証と認可に関する脆弱性がそれぞれランクインしているのです。

2023年3月現在、Flatt Security社が検出した脆弱性の集計結果

このデータや分類に関する詳細な解説は下記の同社技術ブログで公開されています。

参考：「BtoB SaaSに多く発見された脆弱性Top10」を集計しました – Flatt Security Blog

同社はソフトウェアの脆弱性を、それぞれのソフトウェアの仕様やロジックに起因する「ロジックの脆弱性」と、XSS（クロスサイトスクリプティング）やSQLインジェクション、CSRF（クロスサイトリクエストフォージェリ）などに代表される、どのソフトウェアにも共通して発生し得る「一般的な脆弱性」に大別されると説明しています。

そして上記のように、同社の集計ではロジックの脆弱性の方が、一般的な脆弱性に比べて多くなっていることが示されています。

ロジックの脆弱性とはどのような脆弱性で、どう対策すべきなのでしょうか。1位のロジックの脆弱性には認証認可以外の多様な脆弱性が含まれるため、2位と3位にあたる認可系と認証系のロジックの脆弱性について、同社の説明を参考に例を見ていきましょう。

認証系ロジックの脆弱性の例を見てみる

まず認証系、具体的には新規登録やログイン時の動作を考えてみます。

よくある実装として、新規登録時に「このメールアドレスはすでに使われています」あるいはログイン時に「パスワードが間違っています」というエラーメッセージが返ってくるケースがあります。

しかしこれによって、あるメールアドレスの持ち主がサービスに登録しているかどうか、という情報が容易に漏洩することになります。

そこから例えばユーザーが特定の趣味や嗜好、あるいは思想や信仰を持つかどうか、あるいは特定の疾病や施術率などのセンシティブな情報が得られる可能性があることは容易に想像できるでしょう。

自社のサービスではセンシティブな情報は扱っていないから大丈夫だろうと、サービス提供側が勝手に判断することは危険です。単純に多くの情報を集めるだけでも、リスト攻撃の手がかりにできるのです。

悪意のあるユーザーは複数の情報を組み合わせることで、漏洩した情報の価値を高める手段を持つ可能性を考慮すべきでしょう。

そのために、こうした実装はロジックの脆弱性と見なされるわけです。

さて、ではこれを修正したとしましょう。

それでも、メールアドレスが存在せずにログインに失敗する場合と、パスワードが間違っていてログインに失敗する場合とを比較したら、内部処理が異なることでエラーが返る処理時間が異なるかもしれません。

こうしたわずかな違いも、悪意のあるユーザーにとっては攻撃の手がかりになる可能性があるのです。

ログイン機能におけるロジックの脆弱性への根本的な対策には、多要素認証やreCAPTCHAの導入、試行回数の上限を設定するなどが考えられますが、詳しくは同社のブログ「Webサービスにおけるログイン機能の仕様とセキュリティ観点」を参照してみてください。

認可に関するロジックの脆弱性の例とは

次に認可の例として、特定の権限を持つユーザーにのみ表示や操作ができる管理画面のロジックの脆弱性の例について見てみましょう。

安易なロジックとしては、全機能を持つ画面を生成しておいて権限に合わない機能はCSSで非表示にすることで、権限ごとの画面を文字通り見かけ上だけ用意する方法です。

ほかにも、操作元ユーザーIDをリクエストに含む方法や、操作権限に関する情報をリクエストに含んでサーバに送り、それを元に画面を生成する方法などもあるでしょう。

これらも、画面の操作や偽造されたリクエストによって脆弱性を引き起こす可能性があります。

対策としては、必ずサーバ側でユーザーごとに利用できる機能を出し分けるようにし、クライアントが生成したリクエストの値はサーバでつねに検証する、といったことです。

参考：Webサービスの認可制御の不備によって起こる仕様の脆弱性と対策 – Flatt Security Blog

同社はこうしたロジックの脆弱性を開発者が検出するためのチェックシートも公開しています。

参考：仕様起因の脆弱性を防ぐ！開発者向けセキュリティチェックシート(Markdown)を公開しました

スキャンツールによるチェックだけでは不十分

このようにロジックにおける脆弱性を検出するには、いわゆる脆弱性検出用のスキャンツールによるチェックだけでは十分でなく、専門知識を持つ技術者が、そのソフトウェアで起こり得るさまざまな動作とその結果に対する十分な想像力を働かせることが求められます。

こうした検証にフォーカスしたセキュリティの専門家によるセキュリティ診断サービスを提供しているのが、Flatt Securityです。

Flatt Securityが提供する診断サービスの概要

強みはAWS、Google Cloud、Firebaseなどのさまざまなクラウドサービス、ReactやVue、GraphQLなどのさまざまな技術スタック、Webアプリケーション、モバイルアプリ、ゲーム、IoTなどのさまざまなアプリケーションに対応し、ソースコードやシステムの設計、仕様書などを元に分析し診断するホワイトボックス診断も行えることです。

最近ではパスワードレスを実現するFIDOを活用したアプリケーションの診断実績を持つなど、最新技術にも強みを発揮しています。

参考：セキュリティ診断事例インタビュー | 株式会社Flatt Security

その上、同社の執行役員兼プロフェッショナルサービス事業CTO 志賀遼太氏は世界最大級のハッキングコンテスト「Pwn2Own」で2021年に3万ドルを獲得する実績を持ちます。そして志賀氏がこのセキュリティ診断サービスの技術統括を担当しているのです。

志賀氏以外にも、同社にはTwitterやGitHub, GitLabなどの名だたるグローバルサービスに対して脆弱性を発見し報告してきたエンジニアも在籍しており、技術力は折り紙付きです。

顧客の技術スタックや予算に合わせて診断内容を提案

同社が提供する診断サービスは、技術スタックや予算に合わせてオーダーメイドな形で提案してもらえ、コミュニケーションはSlackで行うことも可能です。

報告書は、脆弱性の再現方法のPoCがJavaScriptコードやシェルスクリプトとして記述されコピー＆ペーストするだけで動作確認でき、修正に必要な情報が具体的に示される内容や、フォーマットはMarkdown形式でも提供されるなど、開発者とそのプロダクトに寄り添った対応が可能です。

開発者のために最適化されたFlatt Securityのセキュリティ診断についての詳細は、ぜひ同社のWebサイトをご覧ください。

≫セキュリティ診断(脆弱性診断) | Flatt Security

同社では下記のWebサイトでセキュリティに関する情報発信も積極的に行っていますので、合わせてご覧ください。

• 技術ブログ「Flatt Security Blog」
• セキュリティとプロダクト開発の今を伝えるメディア「#FlattSecurityMagazine」

（本記事はFlatt Security社の提供によるタイアップ記事です）