はじめに
こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。
弊社では本当にありがたいことに多くのお客様から様々なWebサービスの脆弱性診断をご依頼頂いています。本稿では、特にご依頼いただくことが多いBtoB SaaSという領域において実際にどのような種類の脆弱性が見つかっているのか(我々が発見できているのか)を集計し、上位10種類の脆弱性を紹介します。また、この上位10種類にどのような特徴があるのか、どのようにアクションを行うことでこれらの脆弱性がサービスに埋め込まれないようにできるのかについても解説しています。
データの概要
今回のデータは2022年1月から2023年2月までに診断を行ったBtoB SaaSに属するサービスで発見された脆弱性を元に集計と分類を行っています。集計を行った対象脆弱性の実数については、扱うデータの性質上公開できないのですが、価値のあるデータを提供できる程度の数が存在していると考えていただければと思います。
| No. | 脆弱性名 | 検出された脆弱性全体に対して占める割合(少数第一位を四捨五入) |
|---|---|---|
| 1 | ロジックの脆弱性(認証・認可以外) | 20% |
| 2 | ロジックの脆弱性(認可系) | 20% |
| 3 | ロジックの脆弱性(認証系) | 12% |
| 4 | XSS / クロスサイト・スクリプティング | 11% |
| 5 | システム情報の漏洩 | 7% |
| 6 | サーバーの設定不備 | 7% |
| 7 | DoS | 4% |
| 8 | 脆弱なミドルウェアの使用 | 3% |
| 9 | Cookieのセキュリティ設定不備 | 2% |
| 10 | CSRF / クロスサイト・リクエストフォージェリ | 2% |
こちらが報告された脆弱性を集計し、報告された数の割合が多い順に並べた表になります。上位3つの脆弱性が「ロジックの脆弱性」で、これらが全体の50%以上を占める結果となっています。
発見された脆弱性についての説明
今回の集計では実際に見つかった脆弱性を、その性質をもとに独自に分類して集計しています。分類には抽象的な部分も含まれるため、ここでは分類した脆弱性の特徴について説明します。
ロジックの脆弱性
今回の集計ではこの「ロジックの脆弱性」に分類されるものが上位3つを占める事となりました。ここで分類している「ロジックの脆弱性」とは、サービスの仕様上では想定されていない動作を引き起こすことで問題となりうるものを指しています。
このようなロジックの脆弱性は自動診断ツールでは発見が困難なものが多い性質があります。
今回はロジックの脆弱性をさらに
- 認証系
- 認可系
- それ以外(固有のビジネスロジックに依存するもの全般)
という分類を行って集計をしています。それぞれは具体的には以下のような脆弱性になります。
認証系
認証系とはログイン、ログアウト等のユーザー認証を提供する部分の機能に関する不備を分類したものです。具体的には以下のような脆弱性をこちらに分類しています。
- ログインフォームへのブルートフォース対策が取られていない
- ログインフォーム機能のレスポンスの差分からメールアドレスの存在が確認可能
- 多要素認証のため導入されているPIN入力機能の実装不備
認可系
認可系とは、サービスの仕様上で許されていない他人の情報へのアクセスを行う等といった認可制御に関するものを分類した項目です。アクセス制御に関する脆弱性もこちらに分類しています。具体的には以下のような脆弱性をこちらに属する脆弱性としています。
- 一般ユーザーが管理ユーザーのみに許可されている機能を使用
- 他者のプロフィール情報改ざん
- マルチテナントサービスにおける他テナントのデータへのアクセス
それ以外(固有のビジネスロジックに依存するもの)
ロジックの脆弱性の中でも認証系や認可系は一般的に広まっている言葉として分類可能ですが、そうでない脆弱性についてはサービス固有のビジネスロジックに依存しており、適切な抽象度で分類するのが難しいため「それ以外」としています。そのような脆弱性としてあげられるのは以下のようなものです。
- 有料限定コンテンツの制限を回避した閲覧
- 回数制限のある機能の制限回避
- 入力に対するバリデーションの不備
- リンクで共有する機能が発行するURL等の文字列が推測可能
- その他サービスの性質を損なう、無視するような行為が可能
なお、ロジックの脆弱性そのものや認証/認可/それ以外といった分類は、以下のようにデジタル庁が公開している資料でも同様の(と解釈できる)定義がされているため、一定専門家の間でも似たような認識がなされているとは思います。しかし明確な統一見解があるともいえないため、あくまで「Flatt Securityの定義におけるもの」として本記事はお読みください。
XSS
XSSはフレームワークやライブラリの機能などで対策されていることも多く、なかなか発見されないものだと思われがちですが、集計の通りまだまだ比較的多く発見される脆弱性になります。
種類によっては自動診断ツールで発見することの可能なものもありますが、そうではない、DOM Based XSSのようなものもあるためセキュリティエンジニアによる手動の脆弱性診断が必要な脆弱性であると言えます。
5位以下の脆弱性について
5位以下の脆弱性の特徴はツールで発見可能なものが多いです。弊社の提供する脆弱性診断ではセキュリティエンジニアが診断ツールの実行をしつつ、並行でツールではカバーできない部分の診断を手動で行うという手法で進行しているため、このような脆弱性も当然報告される事となっています。
10位以下の脆弱性について
上位10という結果には示されませんでしたが、報告されている脆弱性の中には
- SQLインジェクション
- ディレクトリトラバーサル
- OSコマンドインジェクション
- SSRF(サーバーサイドリクエストフォージェリ)
と言った、仕様によらない一般的な実装の不備である脆弱性も存在します。
このような脆弱性は、1件でも実際に攻撃可能なものが見つかった場合には非常に危険なため、報告数が少なくとも無視できるものではないと考えられます。実際に、弊社の脆弱性診断でも一定の頻度で発見されています。
正直なところ、ロジックの脆弱性は体系化できない以上学習が非常に難しいのですが、これらの体系化しやすい脆弱性は学習が可能ですし、それにより大きなリスクを防ぐことができます。同時に、ロジックの脆弱性を発見・対策するための基礎力のようなものも養うこともできるでしょう。弊社Flatt Securityは「KENRO」という学習プラットフォームを提供しており、Webアプリケーションのセキュアコーディングの基礎を学ぶことが可能です。
トライアルは無料・無期限で利用可能ですので、ぜひ下記のバナーよりご登録ください。
「ロジックの脆弱性」に偏りが生じた要因の分析
今回弊社でおこなった集計において、このように「ロジックの脆弱性」が多くを占める事になったのには様々な理由が考えられます。それを
- プロダクトの要因
- 開発組織の要因
- 診断ベンダーの要因
に分類し、分析してみます。
プロダクトの要因
BtoB SaaSでは利用者の属性によって利用可能な機能が異なっていたり複数事業者のデータが同一のデータベース等を共有するマルチテナント方式で運営されていたり等、比較的複雑な構成になっていることがあります。
また、固有のビジネスロジックが強く意識される機能を備えている事が多く、それが迂回または破壊されることで大きなリスクとなりうるようなサービスもあります。 このような点から、BtoB SaaSでは一般的なWebアプリケーションと比較して、潜在的に存在するロジックの脆弱性の数自体が多くなっているのではないかと考えられます。
開発組織の要因
開発者がWebセキュリティを学ぶことは重要だと考えている人は多いですが、実際にWebセキュリティを体系的に学ぶ機会が十分に提供されているとは言い難いです。特にロジックの脆弱性に関してはその性質上体系的にまとめることが難しく、情報が少ないです。
このため、どのような実装が脆弱性につながるかといった知識や、そのような脆弱性への対策方法のノウハウが開発組織に十分に浸透していないというのもロジックの脆弱性が生まれやすい原因だと考えられます。
診断ベンダーの要因(Flatt Securityの要因)
Flatt Securityでは技術力の高いエンジニアが診断対象Webサービスの特性の理解に努め、その上でビジネス上の脅威になりうる攻撃観点を考え診断を行っています。技術力の裏付けになる実績を一部紹介すると、世界最大級の脆弱性リサーチコンテスト「Pwn2Own」でメンバーがUbuntuの脆弱性を報告し3万USドルの賞金を獲得したり、またメンバーたちが報告しCVEが採番された脆弱性をWebサイトで公開していたりします。
そのため、フレームワークやライブラリの活用が進んだ昨今の開発体制の中でも、それらが提供している防御機構だけでは防げないような脆弱性を多く発見できる結果に繋がっていると考えられます。
開発者が取るべきアクション
今回の結果をうけてWebサービスの開発で脆弱性をできるだけ減らすにはどのようなアクションを取るべきかを考えてみます。
内部的なアクション
まず開発組織の中で起こせるアクションとしては開発組織内部でのプロダクトセキュリティ知識の獲得、ノウハウの共有です。
Webセキュリティの基礎知識を体系的に学ぶために良いものとしては、IPAが公開している「安全なウェブサイトの作り方」というコンテンツであったり、書籍であれば『体系的に学ぶ安全なWebアプリケーションの作り方』(通称:徳丸本)や『Webブラウザセキュリティ』が挙げられます。
また、弊社でも先ほどご紹介したように「KENRO」を展開していたり、ブログにて「Webサービスの機能とセキュリティ」というカテゴリを設け、主にロジックの脆弱性に関する内容の記事を公開しています。
外部的なアクション
開発者がセキュアコーディングの知識を備え実装することで確かに脆弱性を減らすことはできますが、ロジックの脆弱性のような、体系化できない高度なリスクまで完全に無くすことは難しいです。そのため、弊社のようなセキュリティベンダーによる脆弱性診断を活用することが重要と言えます。
その他、実装ではなく機能設計段階で早期に問題に気付けるようにするためにWebセキュリティ専門家によるコンサルティングを受けるなども効果的な手段となりえます。
技術力を強みにした弊社の脆弱性診断に興味のある方は、ぜひお客様への事例インタビュー記事をご覧ください。
終わりに
ここまでお読みいただきありがとうございました。弊社のように顧客層の多くを「インハウスのプロダクト開発チームを持つ企業」が占めるセキュリティベンダーはあまり多くないのではないでしょうか。それゆえ、興味深いデータをご紹介できたと思っています。
ぜひ今後の開発の参考にしていただければ幸いです。
また、Flatt Security はセキュリティに関する様々な発信を行っています。 最新情報を見逃さないよう、公式 Twitter のフォローをぜひお願いします！
