はじめに
こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。
これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。
ダウンロードは下記のGitHubリンクよりどうぞ。
また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。
- はじめに
- アプリケーションの仕様起因の脆弱性とは
- アプリケーションの仕様起因の脆弱性を防ぐために
- 「アプリケーション仕様とセキュリティ観点解説記事」の紹介
- 「アプリケーション仕様とセキュリティ観点」チェックシートの配布
- 終わりに
アプリケーションの仕様起因の脆弱性とは
Webアプリケーションの脆弱性として広く知られているものには、XSSやSQLインジェクションといった、アプリケーションを利用するコンテキストによらず実装の問題で起こりえるものがあります。
逆に特定の機能の挙動が想定された挙動とは異なり、サービスの運営やビジネスに悪影響を及ぼすようなものをここでは「仕様起因の脆弱性」と呼んでいます。
例えば「ユーザー登録機能」はSNSなどのtoCサービスであれば多くの場合は誰でも自由に新規ユーザーを登録できる仕様で問題ないですが、toB SaaSになると「管理者のみが新規ユーザーの登録が可能」というような制約が加わる場合があります。そのときに適切な認可制御の実装がされていないと「管理者以外でも新規ユーザーが登録可能」という「仕様起因の脆弱性」が生まれます。
アプリケーションの仕様起因の脆弱性を防ぐために
このように、仕様起因の脆弱性は一般化して考えることが困難な性質のものが多いです。
以下で紹介するこれまでの記事でも、前提となる仕様を置いた上で観点のパターンを提示し解決策を提示しています。まずはこれらの記事をお読みいただき、観点の例を学び、ご自身の開発中サービスで同様の機能のものを確認してもらうのが良いでしょう。
次のステップとして、それらに共通するような性質は何かを見出し、新規の機能を開発するときにも「そのような性質のものはないか」と想像力を働かせて設計するのが大事になります。
仕様の脆弱性によく見られる共通点
いくつかの頻繁に見られる共通点について簡単に解説します。これらの観点と、その相似形を考えて常に想像力を働かせることが大事です。
1. クライアントサイドを信頼しすぎている
仕様起因の脆弱性は「クライアント側で表示していないから大丈夫」「クライアント側で送信する前にバリデーションを行っているから大丈夫」のように、クライアント側で制御を行っていることでセキュリティを担保しようとしている場合に起こることが多いです。
しかしクライアント側の制御はご存知のようにブラウザの開発者ツールや専用のプロキシツールを用いれば閲覧も改ざんも簡単です。知識を持った悪意のある攻撃者には、単にUIから見えないことは何のハードルにもならず、APIとの通信内容やヘッダに何が入ってるかなどもすべて確認可能なのでこのような方針でセキュリティを担保するのは不十分と言えるでしょう。
また、このようにクライアントサイドの挙動を信用しすぎることで以下の2. 3. のような共通の問題も起こりえます。
2. 認可制御が不十分
UI上では「管理者からの操作しか受け付けてない」「特定のテナント内同士での処理しか受け付けてない」「特定のユーザーからの操作しか受け付けてない」というものを想定して、パラメータにそれらの操作対象リソースのID等を含んで送信元ユーザーと操作対象リソースの所有関係の確認を行わないまま処理を進めると、悪意のある攻撃者のパラメータ改ざんによって認可制御の不備が起こりえます。
3. 推測可能な値をパラメータに用いてしまう
「A社のユーザーがアップロードしたファイルを、A社のユーザーだけがみられるようにしたい」というような場合に、URLが「/img/2022/06/30/A-Company/pdf/000000001.pdf」となるような形でアップロードして、システムから呼び出しているようなケースです。「クライアントからはブラウザで遷移させない形でダウンロードしているからURLが露出することは無いし大丈夫だろう」のように考えていると推測で当該URLにアクセスされ、情報漏えいに繋がります。
4. レスポンスやエラーメッセージに余分な情報が含まれている
レスポンスやエラーメッセージはユーザーにとっても開発者にとっても重要な情報を含んでいる場合がありますが、不必要な情報をそれらに付加してしまった場合は攻撃者にとってのヒントとなる場合があるので注意しましょう。
仕様起因でない脆弱性への対処
本記事で紹介するのは一般化しづらい脆弱性に関する知識ですが、逆に体系的に学びやすい脆弱性も存在します。冒頭で触れたXSSやSQLインジェクションがそうです。
これらの脆弱性に関しては世の中に複数教材がありますが、Flatt Securityでは脆弱なコードの修正演習まで可能な、演習主体で学ぶ「KENRO」というサービスを提供しています。
是非、無料のトライアルをお試しください。
「アプリケーション仕様とセキュリティ観点解説記事」の紹介
簡単な解説とともにこれまで発表してきた記事を発表順に紹介します。
ログイン機能
タイトルの通りログインフォームやその周辺機能を実装する際に気をつけておきたい部分を解説しています。 ログインフォームのよくある仕様を以下のように分類し、それぞれの観点と対策を解説しています。
- メールアドレスとパスワードのみのパターン
- 上記フォームの入力後にPINコードの入力を追加で求めるパターン
- PINではなくログイン用リンクを登録メールアドレスに送信するパターン
また大変ありがたいことに、こちらの記事にはTwitter、はてなブックマークなどで多くのコメントを頂きました。
その中で「自前でログインフォームを実装するのはこの記事で述べられているように大変だからIDaaSを利用すべき」というご意見もいただきました。確かにIDaaSを使えばセキュアな実装へのハードルは下がるのですが、注意して利用しないとリスクにつながってしまうこともあるのです。
そのようなIDaaSの一つである「Firebase Authentication」を利用する際の注意点をまとめた記事もありますので、よろしければこちらもご一読ください。
ファイルアップロード機能
こちらの記事では「ファイルアップロード」に関わる様々なセキュリティ観点を解説しています。
ファイルアップロードもtoB、toCに関わらず、様々な用途で実装される機能であると思います。 こちらの記事では以下のパターンについての観点と対策を解説しています。
- アイコンや写真のアップロード
- 業務データのCSV bulk import
- 本人確認書類のアップロード
多くのファイルアップロードはこれらのいずれかに属するものだと考えますので、もしファイルアップロード機能を提供されている場合はご一読ください。
セキュアなURL生成
WebサービスにおいてURLのパターンからシステムの構造が把握できるというケースは少なくありません。またそれを利用されてしまい「本来公開する意図のなかったファイルが第三者に漏洩してしまう」というようなセキュリティ事故の事例も存在します。
本記事では他社に共有するようなURLの生成について、
- URLが推測可能なパターンかどうか
- 推測は不可能でも漏洩する可能性のあるものかどうか
という観点で解説を行っています。
また、対策についてもアプリケーションの仕様によって方法は変わります。そちらについても記事中でどのように対策を考えるとよいかのヒントを提供しています。
クーポン機能
こちらはECサービスやデリバリーサービス等toCのWebサービスで多く見られる「クーポン機能」についてのセキュリティ観点を解説しています。 クーポン実装の様々なケースを想定して観点と対策を記述しています。
内容としては
- 利用条件のあるクーポン
- 公開区分のあるクーポン
などの取り扱いについて解説を行っています。 クーポンは金銭的な面に影響する機能でもありますので、もし実装されている方はご一読ください。
認可制御
いくつかのアプリケーションでは「あるユーザーにはどのような操作ができるか」ということを制御しているものがあります。
このような「認可制御」の観点においてどのような観点で確認を行えばよいか解説したものがこちらの記事になります。
認可制御はアプリケーションごとに様々な実装パターンがあります。その中でも本記事では「マルチテナントのToB SaaS」というものを想定して解説を行っています。 以下のような観点が自社のサービスに関係しそうだと思った際にはご一読ください。
- 権限を持たない機能の操作が可能
- 他テナントの操作が可能
- 権限の昇格が可能
マイページ機能
「ユーザー」を登録して利用するタイプのアプリケーションではログインページ同様にユーザー自体の情報を表示したり変更するための「マイページ」があると思います。そのようなマイページにおいて本記事内では「絶対的なURL」「相対的なURL」と定義し、それぞれについて観点と対策を解説しています。
「アプリケーション仕様とセキュリティ観点」チェックシートの配布
ここまで各記事を紹介してきました。どの記事も開発者の方々のお役に立てればと思い執筆しましたが、開発を行っている際に記事を一つ一つ参照するのは大変かと思います。 そこで、今までの記事で出てきた観点とその対策の仕方をチェックリストにしましたので、開発の際にはぜひこちらを活用いただければ幸いです。
チェックリストはマークダウンで記載しているので、GitHubのIssueやPull Requestを作成する際にそのままコピペすることで開発時にどこをみるべきか等が確認できるようになります。
ダウンロードは下記のGitHubリンクよりどうぞ。
終わりに
本記事で紹介したような仕様起因の脆弱性は、ツールのセキュリティ診断では検出しにくいのですが、診断を行う上で非常に重要な観点となっています。
弊社では、ツール診断だけでなく、手動による診断も行っているため、ロジックの不備等、アプリケーションの本来の仕様と実装の差異から来るであろう問題点についても検出することが可能になっています。
過去に診断を実施したが不安や課題がある、予算やスケジュールに制約がありどのように診断を進めるべきか悩んでいる等、お困り事にあわせて対応策をご提案いたしますので、まずはお気軽にお問い合わせください。
数百万円からスタートの大掛かりなものばかりを想像されるかもしれませんが、上記のデータが示すように、診断は幅広いご予算帯に応じて実施が可能です。ご興味のある方向けに下記バナーより料金に関する資料もダウンロード可能です。
また、Flatt Securityはセキュリティに関する様々な発信を行っています。 最新情報を見逃さないよう、公式Twitterのフォローをぜひお願いします！
ここまでお読みいただきありがとうございました。
