Webサイト（Webアプリケーション）に対するスーパー簡易的な脆弱性診断のやり方として、当記事では下記の２つの方法をご紹介します。
②番は、この記事を書いている時点（２０２４年１０月）での最新版である「２０２１年版のOWASP Top 10」において、深刻度がランキング１位の脅威となった「アクセス制御の不備」に関する脆弱性に対するスーパー簡易的な診断方法です。
なお、①②のどちらもWebサイトの制作者本人に向けた内容となっています。当記事は、自分の制作物に脆弱性が潜在していないか不安を感じたときに、スーパー簡易的に診断できる方法の紹介を目的としています。他人のWebサイトを診断するようなシーンを想定していませんので、①②のどちらも制作者本人でなければ実行できないことをご了承下さい。
それでは以降で①②それぞれのやり方をご説明します。
Webアプリケーション開発やWebサイト制作においては、開発・制作効率を高めるために様々なオープンソースソフトウェア（OSS）が活用されています。例えばフレームワーク、ライブラリ、Wordpressやそのプラグインなどです。このページでは便宜のために、以下でそれらのソフトウェアのことを全てまとめて「OSS等」と言います。
OSS等は開発が盛んなのでどんどんバージョンアップしていきますが、それが故に新しい脆弱性が発生する確率は高く、頻度も多く、それに伴ってOSS等の脆弱性を突くサイバー攻撃が起こる確率も高く、頻度も多いです。平たく言うと「攻撃者が好んで標的にする」という感じです。そのためOSS等を使用する際には脆弱性のリスクに気をつける必要があります。
ここではOSS等に脆弱性があるか否かを確認するために、脆弱性情報のデータベースを製品型番で検索してみる、という脆弱性診断の方法を説明します。
大まかな流れは次の通りです。
開発に用いているOSS等やWebサイトで使用しているOSS等のうち、脆弱性診断したいものをリストアップし、それぞれのバージョンをメモに記して下さい。
「JVN iPedia」とは、平たく言うと脆弱性の情報を無料で閲覧・検索できるサービスです。
【URL】https://jvndb.jvn.jp/
「脆弱性対策情報データベース検索」という部分（下の画像の赤枠部分）に、OSS等の名称を入れて検索すると、当該製品の脆弱性がJVNに登録されているか否かを確認できます。
上の画像のように、検索結果に「該当するデータがありません。」と表示された場合は、JVNのデータベースには当該OSS等の脆弱性情報が登録されていないことを示しています。この場合は「OSS等の脆弱性」は問題無さそうだと判断できますが、しかしこの段階ではまだ断定しません。（後述のStep4でもう少し検索してみます）
続いて、OSS等に脆弱性がある場合の例をご紹介します。
上の画像のように、検索結果に当該OSS等が表示される場合は、それ自体に脆弱性があることを示しています。（この例では Apache HTTP Server を検索しました）
各行の先頭列の「JVNDB-」で始まるリンク部分をクリックすると、その脆弱性の情報を閲覧できます。
上の画像は脆弱性情報の中にある、「影響を受けるシステム」の項目の部分です。
この例を見ますと、「2.4.0以上2.4.60未満」と表示されています。これはその文言のとおり、このプログラムのバージョンが上記の範囲である場合は脆弱性があることを意味しています。
Step1でメモしたバージョンが上記に該当する場合は「脆弱性がある」と判断し、その範囲外である場合は「脆弱性は無い」と判断します。
【補足】
脆弱性のページの中に「共通脆弱性識別子(CVE)」という項目がある場合は、そこに表示されているCVE識別番号を念の為メモしておくと良いです。そうする理由は、当該脆弱性に対する対処方法を探す（Web検索する）際に役立つことがあるからです。
【重要】けっこう間違えがちなこと
下記の２つのバージョンは、どちらが新しいバージョンですか？
バージョンの数値は連続する数値ではありません。ピリオドで区切って解釈して下さい。
「1 . 23 . 4」は、1、23、4に分けて読んでください。
左側の１は、「メジャーバージョン」というバージョンを表す値です。
真ん中の２３は、「マイナーバージョン」というバージョンを表す値です。
右側の４は、「パッチバージョン」というバージョンを表す値です。
このようにして「1.23.4」と「1.5.67」を比べると、どちらも左のメジャーバージョンは１で同じです。
続いて真ん中のマイナーバージョンの値を比べると、前者は２３で、後者は５です。２３の方が５よりも大きい、つまり新しいマイナーバージョンということになります。
よって「1.23.4」と「1.5.67」を比べると、「1.23.4」の方が新しいです。
JVN iPediaで型番を検索しても該当する製品がなかった場合でも、念の為Google等で「ソフトウェア名 ＋ 脆弱性」をキーワードにして検索してみると良いです。
なぜそうするかと言うと、一般的な呼称のソフトウェア名と、正式なソフトウェア名が異なる場合があるからです。
JVNでは正式名称で登録されているため一般呼称で検索してもヒットしない可能性があります。一方、Googleの検索結果は検索キーワードに完全一致するものだけでなく、似たようなキーワードのWebページも検索結果の一覧に表示されるので、JVNに登録は無いけれど、実は脆弱性があるかも？ と気付けるかも知れないからです。
ほとんどの場合はソフトウェアをアップデートすれば良いです。ただしその時点の最新版でもまだ改善されていないこともあり、そのようなときは設定の調整などが必要となります。アップデートするだけで良いのか否かを判断するのは難しいので、OSSの公式サイトや「フォーラム」を確認してみると良いです。エンジニアの方にわざわざ説明するまでもない気がしますが、フォーラムとはユーザーや開発者が参加するコミュニケーションの場であり、そこでは当該OSSに関する様々な情報の共有や共助がおこなわれていますので、脆弱性に関する情報も得られると期待できます。また、有名なOSSの脆弱性はIT系のニュースサイトや個人ブログなどでも話題になりやすく、それらに対処方法が書かれていることもあります。それらの情報を探したいときは、「CVE識別番号」を検索キーワードにすると良いです。
２０２１年版のOWASP Top 10では、最も深刻な脆弱性として「アクセス制御の不備」がランキング１位となっています。
【補足】
OWASP Top 10とは、Webアプリケーションのセキュリティに関する重大な脅威のうち、深刻度が高いものから順に選ばれた１０種類の脆弱性のランキングです。これは「OWASP」というWebセキュリティ関連の非営利組織が選定するもので、数年おきの頻度で公表されています。
ランキングの決め方は、多数の企業や団体から提供されたデータをもとにして、脆弱性の発生確率や「悪用されやすさ」、「ダメージの大きさ」などを評価して決められているそうです。
アクセス制御の不備だけを診断すれば大丈夫というわけではありません。他にも発生確率や危険性が高い種類の脆弱性がランクインしています。特に３位の「インジェクション」は致命的な侵害に直結する強烈な脆弱性です。また５位の「セキュリティの設定ミス」も発生確率はやや高く、OWASPの統計では最大発生率が19.84%となっています。ほか２０２１年版で初登場１０位となった「SSRF」は、本来は到達できないはずの領域にもリーチし得る危険性を持っており、今後は増加する可能性もあるとのとこで注目されています。
このように複数の種類の脆弱性があるなかで、今回ご紹介する「アクセス制御の不備」の診断だけで十分だとは言えません。しかしインジェクション攻撃の脆弱性診断を素人がやるのは危険ですし（ミスるとデータ破壊が起こり得ます）、その他のものは個別の環境毎に診断内容は大きく異なりますし、いずれもスーパー簡易的に脆弱性診断するのが難しいです。そのため当記事では、ランキング１位の「アクセス制御の不備」だけに絞ることとしました。これだけで十分ではないとしても、１位の脆弱性なのですから、これを検出するだけでもWebサイトの安全確保には相当に寄与できるはずです。
大まかに言うと、
『特定のユーザーだけにアクセスを許可しているページやデータに関して、そのユーザー以外の者がアクセスできるようになってしまう脆弱性』
です。
例えば、とあるユーザーの個人情報が含まれるページを別のユーザーが閲覧できてしまうとか、Webサイトの管理者だけがアクセスできるページに攻撃者がアクセスできてしまう、というような脆弱性です。
この脆弱性は、例えば下に挙げるような問題を引き起こします。
この脆弱性は、アクセスの許可・拒否などを制御する箇所において、「Webブラウザから送信される値」を未検証のまま使用している場合に発生します。ここで言うWebブラウザから送信される値とは下記のようなものです。
ほか、次のようなプログラムの場合でもこの脆弱性は発生し得ます。
続いて②番（フォームからPOST）の場合。
このようにPOSTのパラメータの値を受け取ってアクセスを制御する、というような仕組みになっているプログラムにおいて脆弱性が発生し得ます。
最後、③番（Cookie）の場合も①②と同様で、Cookieに保存されている値に基づいてアクセス制御をおこなっているプログラムで脆弱性が発生し得ます。
要するに、クエリストリングやPOSTパラメータなど、「ユーザー側で書き換えることができる箇所の値」に基づいてアクセス制御をおこなってはダメということです。もしどうしてもそのような値を使用しなければならない場合には、受け取った値を検証してセッション状態や権限に矛盾がないか判定するようにプログラミングする必要があります。
ソースコードを確認するのが一番簡単で手っ取り早いです。
具体的な手順は後述しますが、簡単に言うと次のような流れになります。
通常、診断会社がおこなう脆弱性診断ではこのような検査はおこないません。診断会社の場合は「診断ツールを使用して、リクエスト＆レスポンスの内容を解析する」という検査方法を用います。診断ツールの使い方は単純ではなく、しかも原理をきちんと理解したうえで作業しないとWebサイトのデータを破壊してしまうリスクがありますので、それは「スーパー簡易的」とは言えません。そのため当記事ではツールを使用せず、ソースコードを確認する方法を説明することとしました。脆弱性診断の専門知識がなくてもプログラマーなら誰でも簡単にできる方法ですので、ぜひお試し下さい。
ここでは、Webアプリケーションにおいて断トツでシェアが多いプログラミング言語である「PHP」を例にして説明します。
【参考例】
find . -name "sample.php" | xargs grep '\$_GET'
上記の参考例は、カレントディレクトリにある sample.php に対し $_GET という文字列で正規表現検索するコマンドです。LinuxのWebサーバーにおいてソースコードの内容を検索する場合は、このコマンドを参考にしてスーパーグローバル変数等が含まれているか否か検索してみて下さい。
サーバーにアップされているソースコードではなく、ローカルPCに保存しているソースコードを確認する場合には、普段からご使用されているエディターソフトに備わっている検索機能でスーパーグローバル変数等を検索して下さい。
そしてもし検索にヒットする箇所が有った場合は、その値がどのように使用されているかを次のStep.2以降で確認します。
もし検索にヒットする箇所が無い場合は、次のStep.2と3を飛ばして、Step.4へ進んで下さい。
プログラムがスーパーグローバル変数等の値を受け取った後、その内容を検証してから使用しているのか、あるいは未検証のまま使用しているのかを確認して下さい。
この例のようにスーパーグローバル変数等を未検証でSQL文に直接放り込んでいるような場合は、かなり高い確率でアクセス制御の脆弱性がありそうです。しかもそれだけでなく、より凶悪なSQLインジェクションの脆弱性もありそうです。
この例のようにスーパーグローバル変数等を未検証で条件分岐に使用している場合は、かなり高い確率でアクセス制御の脆弱性がありそうです。
この例のように一旦変数に代入していても、その変数が例１・２のように使用されている場合は未検証ですので、この場合も脆弱性がある可能性はかなり高いです。
このような形で、プログラムに渡されたスーパーグローバル変数等の内容が検証されている場合には、その検証内容をご確認下さい。
下記のようにアクセス権限の正当性がきちんと検証されていれば問題ありません。
診断対象のphpファイルを検索＆確認した後は、そのphpファイルにインクルードされている他のphpファイルがあるか確認してください。
上の例のようにインクルードがある場合には、そのphpに対してもStep.1から3までのチェックをおこなって下さい。
【言葉の定義】
Step.4では被インクルードphpをチェックしました。もしそこでスーパーグローバル変数等の値を代入した変数があり、かつそれを検証する仕組みになっていない場合には、その変数がインクルード元phpで使用されているかどうか確認して下さい。
例えば被インクルードphpにおいて、「$argument」という変数に未検証の値が代入されている場合は、インクルード元phpにおいて、SQL文やif文の中で「$argument」が使用されているか否かをご確認下さい。
このように、被インクルードphpでもインクルード元phpでも未検証のまま「$argument」が使用されている場合は、脆弱性がある可能性が高いと判断できます。
なお、インクルード元のphpは複数あることも多いかと思います（一つの被インクルードphpを複数のphpで共用するなど）。その場合は該当する全てのphpのソースコードを同様に確認して下さい。
Step.1～5までを文章で読むと難しそう＆面倒くさそうと感じてしまうかも知れませんが、実際にやっていることは「ただのテキスト検索」ですので、とても簡単です。
Step.2の説明において赤文字で強調しましたが、SQLに未検証の値が使用される場合は、アクセス制御の不備の問題だけでなく、より危険なSQLインジェクションの脆弱性がある可能性が高いです。
また、exec()など外部プログラムを使用する箇所で未検証の値が使用される場合は、これも非常に危険なOSコマンドインジェクションの脆弱性がある可能性が考えられます。
もしそういう安全性の低いプログラムになっている場合、セキュリティをあまり意識されずに作られたことが明白ですので、当該Webサイトには他の種類の脆弱性も沢山あるだろうと予測できます。ですので、なるべく早く当社のような専門会社による脆弱性診断サービスをご依頼頂いたほうが良いです。
また、既に不正アクセスや情報漏洩等があるかもしれないという場合には、被害確認等のためのデジタル・フォレンジック調査もご検討下さい。
メール