#脆弱性 | SQAT®.jp

2024年7月4日2024年7月23日

Linuxサーバーを狙うOpenSSH脆弱性
（CVE-2024-6387）-影響と即時対応策まとめ-

contents

CVE-2024-6387は、OpenSSHサーバーに存在する重大な脆弱性です。
この脆弱性により、リモートから認証なしに任意のコードを実行できる可能性があります。
影響を受けるのは、glibcベースのLinuxシステム上のOpenSSHサーバーです。
脆弱性は、シグナルハンドラーの競合状態に起因します。
Qualys社によって発見され、2024年7月1日に公表されました。
修正バージョンが提供されています。
影響を受けるバージョンは、OpenSSH 8.5p1から9.7p1までです。
対策として、OpenSSHの最新バージョンへのアップデートが推奨されています。

CVE-2024-6387

CVE-2024-6387は、シグナルハンドラーの競合状態により発生します。
この脆弱性により、リモートから認証なしに任意のコードを実行できる可能性があります。
本脆弱性は、以前に対処されたCVE-2006-5051の再発（リグレッション）と考えられています。

影響を受けるバージョン

影響を受けるのは、glibcベースのLinuxシステム上のOpenSSHサーバーです。
影響を受けるバージョンは、OpenSSH 8.5p1から9.7p1までです。
4.4p1より前のバージョンは、過去の脆弱性（CVE-2006-5051およびCVE-2008-4109）のパッチが適用されていれば影響を受けません。
OpenBSDは影響を受けません。
Qualys社のテレメトリ情報によれば、インターネットに公開されたホストの約3割（70万台）が脆弱な状態にあると推定されています。

対策方法

利用中のOpenSSHの最新バージョンへのアップデートが推奨されています。詳細については利用中のディストリビューションの最新情報をご確認ください。
暫定の回避策としてデフォルト設定のSSHファイアウォールルールの削除という方法もありますが、DDoS攻撃に無防備になる可能性があるため、アクセス制御を行った上で実施してください。なお、アップデート後はファイアウォールルールを再設定してください。

攻撃の検証状況

ASLR有効化済みの32ビットLinux/glibc環境で攻撃が成功することが確認されています。
理論上は64ビット環境でも可能と見られますが、現時点で実証されていません。
脆弱性の概念実証（PoC）コードは存在しますが、実際の攻撃活動は確認されていません。(2024/7/3時点)
テスト環境では、PoCを使用してCVE-2024-6387の脆弱性を悪用したリモートコード実行は実現できませんでした。
Qualys社はこの脆弱性の実証コードを公開しない方針です。

【関連情報】

CVE-2024-6387は、以前に対処されたCVE-2006-5051の再発（リグレッション）と考えられています。
OpenBSDは2001年に本脆弱性を防ぐ安全なメカニズムを開発しており、影響を受けません。
脆弱性の深刻度(CVSSv3.1スコア)は8.1「Critical（緊急）」と評価されています。
この脆弱性を悪用するには、平均して6時間から8時間程度の連続した接続が必要であり、攻撃の成功率は低いのではないかとの指摘もあります。

サイバーインシデント緊急対応

Security Report TOPに戻る
TOP-更新情報に戻る

2024年6月14日2024年6月17日

ソーシャルエンジニアリングとは？その手法と対策

今回は、サイバー攻撃の変わり種、システムではなく人間の弱点に付け入る攻撃、ソーシャルエンジニアリングを紹介します。

まずソーシャルエンジニアリングの具体的な手法を挙げ、どのように人間の弱点が利用されるのかを説明し、日本で起こったソーシャルエンジニアリングによる被害実例を紹介します。

途中ちょっと寄り道をして、オレオレ詐欺はソーシャルエンジニアリングなのかどうかについて考えつつ、最後に具体的かつ実践的な対策方法と、逆効果となる、とある対策・管理方針について言及します。

ソーシャルエンジニアリングとは

ソーシャルエンジニアリングは、人の心理を巧みに操り、重要な情報を引き出す手法です。この手法を使った攻撃がソーシャルエンジニアリング攻撃で、攻撃者は情報収集やシステムへの不正アクセスなどを目的に、人を心理的に操作して、攻撃者にとって都合のいい行動を起こさせます。

認知能力、心理など「人間の脆弱性」を攻撃するソーシャルエンジニアリング

アメリカの非営利のセキュリティ研究団体MITRE社の説明によると、ソーシャルエンジニアリングとは、人心を巧みに操り、その弱みにつけこんで、悪意ある相手に利するような行動や情報を引き出すというものです。具体的な例を挙げると、技術的な手段によらずに、口頭による会話といった「社会的（ソーシャル）」な手段で、ID・パスワードなどの重要情報を、巧みなやり方で関係者から直接聞き出す行為などがソーシャルエンジニアリングです。大きくは、人間の認知能力のさまざまな弱点やスキにつけ込む手法全般のことだといえるでしょう。

脆弱性診断サービスを提供するBBSecとして「脆弱性」という観点で申し上げるなら、ソーシャルエンジニアリング攻撃は「システムやソフトウェアではなく人間の脆弱性を突く攻撃」と言うことができます。

ソーシャルエンジニアリングの手法

以下に典型的なソーシャルエンジニアリングの手法を挙げます。

・ショルダーハッキング
　例）パスワード等をユーザの肩越しに覗き見る
・トラッシング（スカベンジング）
　例）清掃員などに変装して標的組織に侵入し、書類やHDDなどのゴミや廃棄物をあさる
・なりすまし電話
　例）システム担当者などになりすましてパスワードなどを聞き出す
・ベイティング
　例）マルウェアを仕込んだUSBメモリを廊下に落とす
・フィッシング（ヴィッシング、スミッシング等含む）
　例）信頼できる存在になりすまし、ID・パスワード、クレジットカードなどの情報を入手する
・ビジネスメール詐欺
　例）取引先などになりすまし、犯人の口座へ振込を行わせる
・標的型攻撃メール
　例）ターゲットに対する入念な調査に基づいて作成した、完成度の高いなりすましメールを送る

たとえば「なりすまし電話」ですが、上記に挙げた例とは逆に、入社したばかりの何も知らない社員を装ってシステム担当者に架電し、やり方がわからないふりをするなどして徹底的にイライラさせて、思わずパスワードを口に出させるなどの方法も存在します。人間の認知能力のスキをつくソーシャルエンジニアリングには、実にさまざまな方法があるのです。

ソーシャルエンジニアリングの最大の特徴とは

人の脆弱性を突くソーシャルエンジニアリングの最大の特徴は、ターゲットを信頼させ、攻撃者に有益な情報の提供などを自発的に行わせてしまう点にあります。MITRE社の説明に「人を操る」とあった通り、権力や暴力を振りかざして重要情報を聞き出した場合、それは単なる脅迫であってソーシャルエンジニアリングではありません。

ターゲットの心を意のままに操作して、自発的に、ときに笑顔で協力させてしまう点にこそ、ソーシャルエンジニアリングを行う犯罪者の真骨頂があります。

ソーシャルエンジニアリングはどのように人間の弱点につけ込むのか

ソーシャルエンジニアリングは攻撃対象が信頼してしまう存在などになりすましてターゲットを信頼させ、心を開かせたり油断させることで行われます。

そのために攻撃者がしばしば目を付けるのが、「権威」に対する人間の弱さです。会社の取締役を装って電話をかける、得意客になりすましたビジネスメールを送る、大手金融機関や有名ブランドをかたったフィッシングメールを送る、などの手口に騙されるのが典型的なケースです。

なお、メールアカウントを乗っ取って旧知の取引先などになりすましたメールを送信することで拡散を図るEmotetは、フィッシングを行うマルウェアであり、ソーシャルエンジニアリングの一類型と言うことができます。

オレオレ詐欺はソーシャルエンジニアリングか

権威以外にも「義務感」「正義感」あるいは「好意」につけ込む方法もよく用いられます。多くの人は、困っている人に出会ったら「助けなければ」と感じます。助ける相手が親しい人物や好感を持てる人物であればなおさらです。

そこで思い浮かぶのがオレオレ詐欺ですが、ちなみに、この手の犯罪は、「ソーシャルエンジニアリング」なのでしょうか？

答えはNoです。ソーシャルエンジニアリングは、コンピュータセキュリティの文脈で使われる言葉であり、コンピュータやシステムへの不正アクセスを行うことを目的のひとつに含むという前提があります。そのため、オレオレ詐欺がソーシャルエンジニアリングと呼ばれることは一般にはほとんどありません。

ニューノーマル、テレワーク時代に気をつけたいソーシャルエンジニアリング

大きな環境変化の最中や直後などは、ソーシャルエンジニアリングの絶好の機会です。平時にはない緊張を強いられることで人々の不安やストレスが増し、感情的に動揺しやすくなるためといわれています。2020年、新型コロナウイルスの感染が一気に拡大した当初も、品薄状態だったマスクの配布をうたうメールやWebサイト、保健所からの連絡を装った攻撃などが複数確認されました。ニューノーマル時代、こうした攻撃に引き続き警戒が必要であることはいうまでもありません。

また、テレワークによって従業員どうしが切り離された就業環境においては、フィッシングメールや標的型攻撃メールの感染確率が上がると言われています。これは、オフィスにいたなら同僚や情報システム部門に「変なメールが届いた」と気軽に相談できていたことが、テレワークによって難しくなるからです。

日本で起こったソーシャルエンジニアリングの実例

2015年に発生した日本年金機構の情報漏えい事件は、「【医療費通知】」という件名の標的型攻撃メールが公開メールアドレスに届き、その添付ファイルを開いたことが発端であったとされています。

また、2017年に大手航空会社がビジネスメール詐欺で数億円をだましとられた事件も、2018年に仮想通貨取引所から暗号資産が流出した事件も、いずれもソーシャルエンジニアリングが攻撃のステップのひとつとして用いられています。

ソーシャルエンジニアリング対策・防止策

では、こうしたソーシャルエンジニアリングを防止する対策方法には、どのようなものがあるのでしょうか。

「ソーシャルエンジニアリングの手法」で挙げた攻撃に対しては、たとえばショルダーハッキングならプライバシーフィルターを利用する、ビジネスメール詐欺ならメールの指示をうのみにせず本人に電話をして確認するなど、さまざまな対策方法が存在します。また、近年攻撃者はSNSを活用してターゲットに関する情報を集めることが知られていますので、SNSの利用に組織としてルールを設けるなどの方法も有効です。研修や教育なども効果があります。

しかしその一方で、人間の脆弱性を突く攻撃を完全に防ぐことはできない、という観点に基づいた対策も、併せて必要になります。攻撃を防ぐ対策と同時に、攻撃が防げなかった場合（成功してしまった後）の対策も考える必要があるのです。BBSecはこの考えのもと、標的型攻撃リスク診断やペネトレーションテストなどのサービスを提供し、攻撃を受けることを前提としたセキュリティ対策に取り組む企業・組織の皆様をご支援しています。

企業が絶対にやってはいけないソーシャルエンジニアリング対策

ソーシャルエンジニアリングは人間の脆弱性を突く攻撃です。だからこそ、対策として絶対にやってはいけないことがあります。それは、騙された人を叱責する、何らかのペナルティを与える等の懲罰主義の管理です。

罰を受けるのを恐れることによって、事故が発生しても報告がなされず、それが、インシデントの発見の遅れを招き、組織にとっての致命傷を生むことがあります。あなたも私も、人間は皆、あやまちを犯す生き物なのです。あやまちを犯すことが覆い隠されてしまうような管理は、何の成果も上げられないでしょう。

まとめ

ソーシャルエンジニアリングとは、人の心を操って重要情報等を聞き出したりすることです。

ショルダーハッキング、フィッシング、ビジネスメール詐欺、標的型攻撃メールなど、さまざまな手法があります。

ソーシャルエンジニアリングは、「権威」「義務」「好感」などに惑わされる人間の弱さをあらゆる手口で突いてきます。

環境が急激に変化する時は、ソーシャルエンジニアリングの付け入るスキが生まれます。ニューノーマルや急速なテレワーク化への対応を迫られる現在も、その例外ではありません。

懲罰主義による管理は、ソーシャルエンジニアリング対策として何の効果もなく、インシデント発生の対応が遅れる要因になります。

Security Report TOPに戻る
TOP-更新情報に戻る

2024年5月1日2024年5月8日

約90％に脆弱性？ BBSec脆弱性診断結果からみえる脆弱性対策のポイント

近年、サイバー攻撃は激化し、組織や個人に甚大な被害をもたらしています。情報漏洩やシステム停止など、社会に与える影響は深刻化し、組織存続に関わるリスクにも発展しかねません。増え続ける脆弱性に対処するために、脆弱性対策を実施することが重要です。本記事では脆弱性対策の重要性と実施のためのポイントを解説します。

脆弱性による脅威

近年、ますますサイバー攻撃は巧妙化、高度化しており、組織や個人に甚大な被害をもたらしています。2023年の不正メール、不正サイト、マルウェアといった脅威の検知数が2021年と比較して1.7倍に増加しているとの報告もあり、情報漏洩やシステム停止など、社会全体に与える影響は深刻なものとなっています。JNSAの発表によれば、2016～2018年の個人情報漏洩一人あたりの平均損害賠償額は28,308円にのぼり、大規模な情報漏洩が発生した場合には、企業にとって致命的な損失となる可能性があります。さらに、サプライチェーンにおける取引停止、ブランドイメージ低下、風評被害など、被害は多岐にわたり、組織存続に関わるリスクにも発展しかねません。

このような状況下で、サイバー攻撃から組織を守るために、セキュリティ対策は必要不可欠といえます。組織存続に関わるリスクにも発展するため、サイバー攻撃への対策は必要不可欠といえます。そして、サイバー攻撃への備えとして重要となるのが脆弱性への対策です。脆弱性とは、ソフトウェアやシステムに存在する欠陥であり、攻撃者にとって格好の標的となります。攻撃者は脆弱性を悪用して、システムへの不正アクセス、情報漏洩、ランサムウェア攻撃など、様々な攻撃を実行することが可能となるのです。しかし、脆弱性対策が十分であるとはいいがたい現状があります。

下の図表は弊社のシステム脆弱性診断の結果から、脆弱性の検出率を半期ごとに集計したものとなりますが、過去から常におよそ90％のシステムに脆弱性が存在するという状況が続いています。さらに、2023年下半期ではそのうち17.0%が危険性の高い脆弱性となっています。

システム脆弱性検出率画像 — SQAT® Security Report 2024年春夏号「診断結果にみる情報セキュリティの現状」より

弊社診断結果を掲載したレポートの詳細ついては、こちらをご確認ください。

近年のサイバー攻撃インシデントの例


発表時期	攻撃概要	原因	影響
2023年11月*1	不正アクセスにより通信アプリ利用者の情報が漏洩	一部のシステムを共通化している韓国の企業を通じて不正アクセスが発生	通信アプリ利用者の情報およそ51万件が不正アクセスで流出
2023年8月*2	内閣サイバーセキュリティセンターが不正侵入被害	メーカーにおいて確認できていなかった、電子メール関連システムによる機器の脆弱性が原因	令和４年10月上旬から令和５年６月中旬までの間にインターネット経由で送受信した個人情報を含むメールデータの一部が外部に漏洩した可能性がある
2023年7月*3	名古屋港統一ターミナルシステム（NUTS）がランサムウェア攻撃により停止した	リモート接続用VPN機器の脆弱性から侵入されて、ランサムウェアに感染	NUTSシステム障害により、コンテナ搬出入作業停止など港湾の物流運営に支障をきたした

近年の脆弱性情報の例


発表時期	CVE	対象製品（範囲）	影響
2024年2月*4	CVE-2023-46805 CVE-2024-21887	Ivanti Connect Secure Ivanti Policy Secure 22系、9系のバージョンが影響を受ける	脆弱性が組み合わされて悪用されると、遠隔の第三者が認証不要で任意のコマンドを実行する可能性がある
2023年9月*5	CVE-2022-42897 CVE-2023-28461	Array Networksが提供するVPNアプライアンス「Array AGシリーズ」 ArrayOS AG 9.4.0.466およびそれ以前の9系のバージョン ArrayOS AG 9.4.0.481およびそれ以前の9系のバージョン	2022年5月以降、少なくとも関連する6件のVPN機器におけるリモートコード実行といった攻撃活動が報告されている
2023年7月*6	CVE-2023-3519, CVE-2023-3466, CVE-2023-3467	NetScaler ADC (旧Citrix ADC) および NetScaler Gateway (旧Citrix Gateway) NetScaler ADC および NetScaler Gateway 13.1 13.1-49.13 より前 NetScaler ADC および NetScaler Gateway 13.0 13.0-91.13 より前 NetScaler ADC 13.1-37.159 より前の NetScaler ADC 13.1-FIPS NetScaler ADC 12.1-55.297 より前の NetScaler ADC 12.1-FIPS NetScaler ADC 12.1-NDcPP 12.1-55.297 より前	クロスサイトスクリプティング、ルート権限昇格、リモートコード実行といった攻撃が発生する可能性がある

脆弱性対策の重要性

ここで今一度、脆弱性とは何なのかを改めて考えてみましょう。脆弱性とは、ソフトウェアやシステムに存在する欠陥のことを指します。プログラムのバグや設計上の欠陥などが原因で発生し、サイバー攻撃者にとって格好の標的となります。そして、脆弱性を悪用されると、攻撃者はマルウェアなどを使ってWebサイトへ不正アクセスし、内部データの盗取、改竄、悪用などが可能になります。その結果、情報漏洩やシステム停止、ランサムウェア感染といった、組織にとって致命的な被害につながる可能性があります。

では、脆弱性をなくせばよいということになりますが、現実的には脆弱性を完全に「なくす」ことは困難です。しかし、「攻撃される的」を減らすことで、リスクを大幅に低減することができます。

これらのリスクを低減するためには、ソフトウェアやシステムのアップデート、セキュリティパッチの適用、脆弱性診断の実施、セキュリティ教育の実施、セキュリティ体制の整備といった対策が重要です。特に、日々変化する脅威に対して、システムのセキュリティ状態を正しく把握するためには、脆弱性診断が効果的です。脆弱性診断を実施することで、システムの脆弱性を洗い出し、適切な対策を実施することが可能となります。システムの状態を知り、必要な対策を怠らないことが、Webサイトやシステムを守ることにつながります。

脆弱性診断を活用した予防措置

攻撃者はより悪用しやすく成果をあげやすい脆弱性を狙ってきます。そうしたことを踏まえ、自組織のWebアプリケーション・システムに脆弱性が存在するのか、また存在した場合どういったリスクのある脆弱性なのかを知り、脆弱性対策を行うことは組織として重要なことです。

脆弱性を悪用したサイバー攻撃への備えとして、BBSecとしては、脆弱性診断を推奨しております。下図の攻撃方法は一例となりますが、影響範囲として機会損失から業務停止まで引き起こされる可能性がある、という実態はどの攻撃方法でも同じです。脆弱性を悪用された場合、どの攻撃方法であってもそういった被害が出る可能性があるため、悪用されやすい脆弱性は早急に対応しなければなりません。

SQAT® Security Reportについて

弊社では年に2回、セキュリティトレンドの詳細レポートやセキュリティ業界のトピックスをまとめて解説する独自レポート「SQAT® Security Report」を発行しています。こちらは弊社で行われたセキュリティ診断の統計データが掲載されていることが主な特徴となります。

SQAT® Security Reportでは、半期のセキュリティ診断で得られたデータから、検出された高リスク以上の脆弱性ワースト10といった情報や、その分析を掲載しています。

2023年下半期高リスク以上の脆弱性ワースト10

他にも、カテゴリ別脆弱性の検出状況や、業界別のレーダーチャートも掲載しております。

2023年下半期Webアプリケーション診断結果業界別レーダーチャート製造業

過去のバックナンバーもSQAT.jpにて掲載しておりますので、ぜひ、お役立てください。特集記事や専門家による解説などもございますので、併せてセキュリティ向上の一助となれば幸いです。

半期（6か月）毎にBBSec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。

最新号「2024年春夏号」のダウンロードはこちら。

SQAT脆弱性診断サービス

Webアプリケーション脆弱性診断-SQAT® for Web-

Webサイトを攻撃するハッカーの手法を用いて、外部から動的に脆弱性を診断することで、攻撃の入口となる可能性のある箇所を検出します。診断は最新のセキュリティ情報に基づき実施されますので、開発時やリリース前ばかりでなく、既存システムに対する定期的な実施といった、現状の脆弱性対策の有効性を確認するために活用することをおすすめしています。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

ネットワーク脆弱性診断-SQAT® for Network

悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。ネットワークを標的とした攻撃のリスクを低減するため、脆弱性を徹底的に洗い出し、システムの堅牢化をご支援します。システムの導入・変更・アップグレード時のほか、運用中のシステムに対する定期チェックにご活用いただけます。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

ウェビナー開催のお知らせ

2024年5月8日（水）12:50～14:00
「知っておきたいIPA『情報セキュリティ10大脅威 2023』～セキュリティ診断による予防的コントロール～」
2024年5月15日（水）12:50～14:00
「知っておきたいIPA『情報セキュリティ10大脅威 2024』～セキュリティ診断による予防的コントロール～」
2024年5月22日（水）14:00～15:00
「対応必須! 情報セキュリティ事故発生時の緊急対応とは～情報漏えい・サイバーセキュリティインシデント発生時にすべきこと～」
2024年5月29日（水）13:00～14:00
「今さら聞けない！PCI DSSで求められる脆弱性診断-4月1日運用開始！PCI DSSv4.0での脆弱性診断実施におけるポイントとは-」
2024年6月5日（水）13:00～14:00
「今さら聞けない！スマホアプリのセキュリティあれこれ」
2024年6月12日（水）13:00～14:00
「クラウド時代に対応必須のセキュリティあれこれ -クラウドセキュリティについて-」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2024年4月1日2024年4月1日

脆弱性管理とIT資産管理
-サイバー攻撃から組織を守る取り組み-

日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

増え続ける脆弱性

脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です（下グラフ参照）。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

増え続ける脆弱性画像 — NVD（米NIST：NATIONAL VULNERABILITY DATABASE）Static Resultsより2010～2023年の登録脆弱性件数

また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

脆弱性管理とその目的

情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

脆弱性管理の必要性

しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

脆弱性管理のライフサイクル

脆弱性管理の標準的な流れは以下の4つのプロセスになります。

各プロセスの概要とポイント


プロセス	概要	ポイント・留意点
資産の把握・管理	IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。	・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。・常にアップデートできていること、管理外の資産（シャドーIT）がないこと。
脆弱性情報の収集	資産管理情報をもとに、自組織に関係する脆弱性情報を収集。	・必要に応じて適切なタイミングで実施。・政府機関や製品ベンダといった信頼できるソースから収集。
脆弱性のリスク評価	脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。	・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
解消策の実行	実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。	・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

脆弱性管理におけるIT資産管理

脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

・ハードウェア： PC、サーバ、ネットワーク機器等
・ソフトウェア： OS、ミドルウェア、アプリケーション等
・ライセンス情報、購入・保守情報、廃棄情報
・利用者（利用部門）、利用状況

IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

脆弱性管理とIT資産管理の連携

IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

適切な脆弱性管理のためのポイント

前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。


漏れなく適時に一元管理	実態に即した評価と対応	プロセスの標準化と見直し
脆弱性管理を統括する部門に情報が集約されていること資産管理、脆弱性情報に漏れがないこと資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること　等	脆弱性情報とその解消策が信頼できる内容であること自組織への影響評価と解消策の要否・優先度の決定が適正に行われること解消策の実施が安全・確実な方法で行われること　等	脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること各プロセスでのトラブル発生時には適宜協議できる状態であること定期的、あるいは必要に応じて適宜手順の見直しを行うこと　等

“漏れなく”管理するには

ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

資産の把握・管理：ソフトウェアコンポーネントの管理

見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

■組み込みソフトウェアに起因する脆弱性が問題となった例：

2021年12月　

Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*7。
悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。

2023年12月

Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3。
リモートコード実行、クロスサイトスクリプティング、ＤｏＳ、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表（SBOM）」の活用が有効です。

SBOM （Software Bill of Materials）
特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
参考情報：https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0」（令和5年7月28日）が発行されていますので、参考にしていただくとよいでしょう。

資産の把握・管理：シャドーITの撲滅

先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

■シャドーITに起因する脆弱性が問題となった例：

2024年 2月

著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
根本的な原因は、自組織で管理すべきCNAMEレコード（ドメインの別名を定義する情報）が、放棄されたドメインを指定したまま放置されていたこと。

シャドーITを発見するには、ASM（Attack Surface Management）が有効です（下イメージ）。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

一般的なASMの特徴とイメージ

インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

脆弱性情報の収集：脆弱性診断で補完

資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム（下記例）に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

・外部に公開されているネットワークセグメント
・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
・主力業務に直結するミッションクリティカルなシステム　等

ASMや脆弱性診断の実施頻度

漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

ウェビナー開催のお知らせ

2024年4月10日（水）13:00～14:00
「DevSecOpsを実現！- ソースコード診断によるセキュリティ対策のすすめ –」
2024年4月17日（水）14:00～15:00
「変化する不確実性の時代における「安心・安全・安定のWebサイト運営」セミナー- Google提唱のサイト信頼性スコアとセキュリティ基準の詳細 –」
2024年4月24日（水）13:50～15:00
「知っておきたいIPA『情報セキュリティ10大脅威 2024』～セキュリティ診断による予防的コントロール～」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2024年1月15日2024年1月15日

クロスサイトリクエストフォージェリ（CSRF）の脆弱性　
-Webアプリケーションの脆弱性入門 4-

「クロスサイトリクエストフォージェリ（CSRF）」は、Webアプリケーションの脆弱性の一つです。この記事では、クロスサイトリクエストフォージェリが何であるか、その攻撃の具体的な仕組みや流れ、想定されるリスクについて解説します。またクロスサイトスクリプティング（XSS）の脆弱性との違い、実際にどのような予防策を取るべきかについても触れます。そしてどのようにして自分のWebサイトやアプリケーションを保護するかについて解説します。

前回までの内容

セッション管理の不備は、Webアプリケーションの脆弱性の一つです。セッションIDが日付・誕生日・ユーザ名など、推測可能なもの作られたりしているなどの問題があると、セッションハイジャック（攻撃者が他のユーザのセッションIDを盗み取り、そのIDを使用してユーザのアカウントに不正アクセスする行為）のリスクを高めます。セッションハイジャックが成立するリスクを高める要因となる脆弱性および攻撃方法には、セッションIDの固定化（セッションフィクセーション）やセッションIDの推測などがあります。脆弱性を悪用した攻撃を防ぐためには、セッションIDを推測困難な値にする、ログイン・ログアウト時に新しいセッションIDを発行する、ワンタイムトークン付与やIPアドレスによる確認などの対策が必要です。

アクセス制御の不備は、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。これにより権限昇格やパストラバーサル（パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスする行為）などのリスクが生じます。主な対策方法として、権限に基づく機能制限、適切なアクセス制御ポリシーの実装などが挙げられます。

セキュリティ対策の実施は常に最新のセキュリティ情報を踏まえて見直し、強化していくことが重要です。セキュリティ専門家に相談するなどして、適切な対策を実施しましょう。

前回記事「セッション管理の不備/アクセス制御の不備の脆弱性 -Webアプリケーションの脆弱性入門 3-」より

クロスサイトリクエストフォージェリ(CSRF)とは

クロスサイトリクエストフォージェリ（CSRF）は、攻撃者が罠として用意した偽サイトを用いてリンクや画像をクリックさせることで、ユーザが意図していないリクエストを強制的に行わせることができる脆弱性です。例えば、SNS（ソーシャルネットワーキングサービス）で「いいね！」をする、銀行の振り込み操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。

クロスサイトリクエストフォージェリ（CSRF）攻撃とは

クロスサイトリクエストフォージェリ攻撃の仕組みは、Webサイトでログインしたユーザからのリクエストがそのユーザが意図したリクエストであるかどうかを識別する仕組みがない場合、外部サイトを経由してユーザが意図しないリクエストを送信させ、それをサーバに受け入れさせるというものです。例えば、銀行のサイトにログインしている状態で攻撃者が仕掛けた罠サイトのリンクURLをクリックすると、ユーザの意図しない送金処理などが実行されてしまう恐れがあります。

クロスサイトリクエストフォージェリ（CSRF）攻撃のリスク

クロスサイトリクエストフォージェリ攻撃の特徴は、攻撃者によってユーザが意図しないリクエストを実行させられ、強制的に、情報の変更や購入処理を実行させられてしまうところにあります。注意すべきは、クロスサイトリクエストフォージェリは、システムやアカウントが保有する機能や権限によって様々な被害を受ける可能性があることです。例えば、ユーザの意図しない売買成立での金銭請求、ログイン情報の変更によるアカウントの乗っ取り、データ削除処理の実行によるデータ消失などがあげられます。

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）の違い

クロスサイトスクリプティングとクロスサイトリクエストフォージェリは、Webアプリケーションのセキュリティ脅威として知られていますが、その仕組みや対策には明確な違いがあります。クロスサイトスクリプティングの基本的な手法は、悪意のあるスクリプトをWebページに挿入し、他のユーザがそのページを閲覧する際にスクリプトが実行される攻撃です。主に出力に対するエスケープ処理の不備が原因で発生します。一方、CSRFは、ユーザがログインしている状態で、攻撃者が仕掛けた誘導URLをクリックさせることで、ユーザの意図しない操作を実行させる攻撃です。この攻撃は、セッション管理やトークンの処理が不適切な場合に主に発生します。企業や開発者は、これらの違いを理解し、それぞれの脅威に対する徹底的な対策や対応を導入することが求められます。注意深くシステムの保護と保守を行い、ユーザの情報を守ることが重要です。

クロスサイトリクエストフォージェリの原因

脆弱性が発生する原因は、Webサイト側でユーザからの正規のリクエストと外部サイトを経由して偽造されたリクエストを区別できないことにあります。セッション管理のためにCookie、Basic認証、またはSSLクライアント認証を使用しているWebサイトでは、このような問題が発生する可能性があります。特に、影響を受けるWebサイトのうち、ログイン後に重要な処理等を行うサイトは、大きな被害につながる可能性があるため、注意が必要です。

クロスサイトリクエストフォージェリ攻撃の対策

クロスサイトリクエストフォージェリ（CSRF）攻撃の対策として、送信されたリクエストが正しい画面遷移によるものであることを確認し、不正な場合には処理を実行しない仕組みを実装してください。画面遷移の制御に利用可能な要素としては、下記が挙げられます。

1. 推測困難かつランダムな文字列（トークン）

2. Originヘッダやカスタムヘッダの値

3. 再認証による本人確認

トークンはセッション単位のリクエストごとに有効とし、別のリクエストに対して使用不可としてください。

セキュリティ対策の取り組み

このような攻撃を理解し適切な対策を導入することは、Webセキュリティを保護する上で非常に重要です。また、クロスサイトスクリプティング攻撃により、クロスサイトリクエストフォージェリの緩和策が無効化される場合もあるため、多方面からの脆弱性対策の実施も重要です。企業担当者はこの攻撃の仕組みを理解し、常に最新の対策情報を取得して、安全な環境を保持する必要があります。特に自社のWebサイトを運営する場合、定期的な調査や検証を行い、対策を強化することが求められます。

まとめ

クロスサイトリクエストフォージェリ（CSRF）は、ユーザがログイン状態のWebサイトにおいて、攻撃者が偽造したリクエストを送信させることで、強制的に情報の変更や購入処理等を行わせるものです。例えば、SNSで「いいね！」をする、銀行の振り込み操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。この攻撃を防ぐためには、サイトが正規のリクエストと偽造されたリクエストを区別するために、正しい画面遷移によるリクエストであることを確認する仕組みを実装することが推奨されます。また、企業やサイトの運営者は、この問題をよく知って、対策をしっかりと行う必要があります。

Security Report TOPに戻る
TOP-更新情報に戻る

2024年1月15日2024年1月16日

診断結果にみる情報セキュリティの現状～2023年上半期　診断結果分析～

SQAT® Security Report 2023-2024年秋冬号

BBSecの脆弱性診断

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しており、高い網羅性とセキュリティ情勢を反映した診断を実現するため、セキュリティエンジニアおよびセキュリティアナリストが高頻度で診断パターンを更新し、診断品質の維持・向上に努めている。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2023年上半期（1月～6月）実施結果より、セキュリティ対策の実情についてお伝えする。

2023年上半期診断結果

Webアプリ/NW診断実績数

2023年上半期、当社では12業種延べ553企業・団体、3,396システムに対して、脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションに
おいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上（緊急・重大・高）の割合は17.5％で、6件に1件近い割合で危険な脆弱性が検出されたことになる。

一方、ネットワーク診断では、なんらかの脆弱性があるとされたシステムは約半数だったが、そのうちの危険度「高」レベル以上の割合は23.8%で、5件に1件以上の割合であった。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2023年上半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

長年知られた脆弱性での攻撃

「Webアプリ編」について、1位、2位は前期同様「クロスサイトスクリプティング（以降：XSS）」と「HTMLタグインジェクション」となった。3位以下は、脆弱性項目は前期からあまり変化はないものの、「SQLインジェクション」が順位を上げた。

3位の「サポートが終了したバージョンのPHP使用の可能性」など、サポートが終了したバージョンのコンポーネント（プログラム言語、ライブラリ等）の使用がワースト10の4項目を占めている。サポート終了とはすなわち、新たに脆弱性が発見された場合でもコンポーネントの提供元は基本的に対処しないということであり、危殆化に対する利用者側での対策が困難となるため、継続利用は危険である。例えば、サポートが終了した製品についての脆弱性情報の公開が契機になり、攻撃コードが公開され、攻撃が活発化することも考えられる。最新バージョンへのアップデートを迅速に、定期的に実施すべきである。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

アクセス制御が不適切な認証機構の検出がランクイン

「ネットワーク編」のワースト10については、ワースト4までが前期と変わらず、5位、6位は順入れ替えという結果で、あまり大きな変動は見られなかったが、8位の「アクセス制御が不適切な認証機構の検出」が前期圏外からランクインした。「アクセス制御が不適切な認証機構」には、特権アカウントやデフォルトアカウント等を使用してログインできる脆弱性も含まれる。特権アカウントがデフォルトのまま、もしくは推測されやすい認証情報で設定されていた場合はさらに危険である。デフォルトアカウントやデフォルトパスワードを使用せず、推測されにくい複雑なパスワードを設定することや、ログイン画面に対するアクセスを強固に制御すること、特権アカウントは必要最小限のユーザにのみ付与することなどが推奨される。

カテゴリ別の検出結果詳細についてはこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月27日2024年1月9日

セッション管理の不備/アクセス制御の不備の脆弱性
-Webアプリケーションの脆弱性入門 3-

セッション管理の不備やアクセス制御の不備が存在すると、情報漏えいや不正アクセスのリスクが高まります。本記事では、セッション管理とアクセス制御についての基本的な知識から、脆弱性の概要、脆弱性を悪用した攻撃の手口、そして攻撃を防ぐための対策方法についてご紹介します。

前回までの内容

SQLインジェクションは、Webアプリケーションの脆弱性の一つです。攻撃者は不正なSQL文を挿入してデータベースを操作することにより、データベースの内容を改ざんし、顧客の情報を不正に取得します。SQLインジェクション攻撃はSQL文の組み立て方法に問題があり、攻撃者が挿入した不正なSQL文を誤った命令文として認識してしまうことで発生します。攻撃を受けてしまった場合、顧客情報や決済履歴などの機密情報が漏洩する恐れがあり、企業の信用やブランドイメージに大きなダメージを与えます。対策方法ととして、プレースホルダを使用したSQL文の構成、特殊文字のエスケープ処理、SQLエラー情報の非表示化、アカウントの適切な権限付与などがあります。これらの対策は、データベースのセキュリティを維持し、攻撃を防ぐために重要です。また、SQLインジェクションの脆弱性を検出する方法として、入力フィールドに本来許可されていない文字列を設定し、Webアプリケーションの反応を観察する方法があります。このようなテストを通じて、企業のセキュリティ担当者がSQLインジェクションの脆弱性に対する問題を理解し、社内で情報を共有し、適切な対策とることで、攻撃を未然に防ぐことが可能になります。また、Webサイトの機能追加や新しい攻撃手法の発見等によって生まれた新たな脆弱性には、定期的にセキュリティ診断を実施することで適切な脆弱性対策をすることができます。

前回記事「SQLインジェクションの脆弱性 -Webアプリケーションの脆弱性入門 2-」より

セッションとは

セッションとは、クライアントがサーバに接続してから切断（あるいはログインしてからログアウト）するまでの一連の流れのことです。この一連の流れを管理することをセッション管理と呼びます。セッション管理はユーザの識別や状態の維持のために必要とされます。例えば、オンラインショッピングサイトで商品をカートに追加した際、その情報はセッションとして保存されます。

セッション管理の不備とは

セッション管理の不備/アクセス制御の不備の脆弱性（2人とデータの紙アイコンマーク）イメージ

Webアプリケーションの中には、セッションID（ユーザを識別するための情報）を発行し、セッション管理を行うものがあります。このときセッションIDを固定化できたり、日付・誕生日・ユーザ名で作られたりしているなど、有効なセッションIDが推測可能であるといったセッション管理の不備があると、セッションハイジャックと呼ばれる攻撃が成立する危険性があります。これにより、攻撃者が本来のユーザになりすまして権利を行使することで、プライベートな情報の閲覧や、設定の変更などが行われる可能性があります。

セッション管理の不備の脆弱性を悪用した攻撃

セッションハイジャック

セッションハイジャックは、攻撃者が他のユーザのセッションIDを盗み取り、そのIDを使用してユーザのアカウントに不正アクセスする行為を指します。有効なセッションIDを推測あるいは奪取する手段が存在している場合に、セッションハイジャックが成立するリスクが高まります。

セッションハイジャックが成立するリスクを高める要因となる脆弱性および攻撃方法には、以下のようなものがあります。

セッションIDの固定化（セッションフィクセーション）

攻撃者が事前にセッションIDを設定し、そのIDをユーザに強制的に使用させることができる脆弱性を悪用してユーザのセッションを乗っ取る攻撃方法です。この攻撃は、ユーザがログインする前にセッションIDが設定され、その後も変更されない場合に発生します。

セッションIDの推測

セッションIDが日付や誕生日、ユーザ名で構成されていたり、連番で発行されていたりするなど、簡単に予測できるものであった場合、攻撃者はそのIDを推測してユーザのアカウントにアクセスできてしまいます。また、セッションハイジャックの原因は多岐にわたり、他の脆弱性を悪用されることで有効なセッションIDが奪取される場合もあります。

Webアプリケーション／ネットワークの脆弱性の悪用

攻撃者によりWebサイトの脆弱性を突かれ、不正にユーザとWebサイトの間に介入されたり、ネットワークを盗聴されたりするなどして、ユーザのセッションIDを奪取される可能性があります。代表的な攻撃手法のひとつには、以前の記事で解説した「クロスサイトスクリプティング」も挙げられます。また、通信のやり取りではセッションIDが暗号化されておらず、平文のままデータのやり取りをしている場合にも、攻撃者に狙われやすくなります。

セッション管理の不備の脆弱性を悪用した攻撃を防ぐための対策方法

セッションIDの取り扱いや、セッションの有効期限の設定などに問題がある場合、攻撃者がセッションを乗っ取ることが容易になり、機密情報を盗み見られたり、不正な操作をされたりするなどのリスクが発生します。では攻撃を防ぐためにどのような対策方法をとればよいのでしょうか。以下に例をご紹介いたします。

セッションIDを推測困難なものにする

攻撃者によってセッションIDを推測されてしまった場合、そのユーザになりすまして、本来アクセスできないサイトに第三者がアクセスできてしまう恐れがあるため、セッションIDは推測困難な値にする必要があります。

ログイン、ログアウトといった処理を行う際は、新しいセッションIDを発行する

ログイン時にセッションIDの正当性を検証することで、攻撃者があらかじめ用意したセッションIDを強制的に使用させられることを防ぎます。

セッションハイジャック対策

有効なセッションIDを奪われないようにすることだけでなく、セッションIDを奪われたとしてもセッションハイジャックを成立させないような環境を作るのが対策のポイントです。

セッションIDとワンタイムトークン付与によるユーザの確認：セッションIDとは別にログイン成功後にワンタイムトークンを発行し、画面遷移ごとにサーバ側で管理しているトークンと照合します。発行するワンタイムトークンは、推測困難かつランダムな文字列で構成する必要があります。
IPアドレスによるユーザの確認：ユーザを特定する情報として、IPアドレスを使用することが可能です。さらに、セッションIDをCookieで管理している場合には、Cookieにsecure属性およびHttpOnly属性を設定することで、攻撃者によるCookie情報奪取のリスクを緩和できます。

対策例としては、上記のとおりですが、セキュリティ専門家への相談も重要です。現在の技術環境では、常に新しい脅威が出現するため、対策は継続的に見直し、強化する必要があります。

アクセス制御の不備とは

アクセス制御の不備とは、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。例えば、一般ユーザとしてログインした際に管理者としての権利を行使できてしまう権限昇格、パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスすることが可能となるパストラバーサルなどです。不正アクセスや意図しない情報の公開をはじめとした、様々なリスクが生じます。

アクセス制御の不備の脆弱性

権限昇格

ログインすることなくユーザとしてシステムに対する操作を実行できたり、一般ユーザが本来与えられていない上位権限（管理者権限等）を一時的に取得することで、システムに対する不正な操作や機能の実行が可能になったりする問題。

パストラバーサル

外部からのパラメータでWebサーバ内のファイル名を直接指定するWebアプリケーションにおいて、URLパラメータを操作して不正なパス名を渡すことで、本来アクセスを許可されていないディレクトリやファイルに対して、攻撃者がアクセス可能になる問題。

不適切な情報の出力

本来権限が与えられているユーザのみアクセスできるものに対して、不正なユーザが本来許可されていない特定のURLにアクセスしたり、操作を行ったりすることで、外部に公開されていない情報（機密情報・ユーザ情報）が閲覧可能になる問題。

アクセス制御の不備を悪用した攻撃を防ぐための対策方法

主な対策方法は以下の通りです。

権限昇格

権限管理を行う際は、外部から値を操作可能なパラメータは使用せずサーバ側で行う実装とし、権限による機能制限を実装する際には、各機能へのアクセス時に実行者のアカウントと権限のチェックを実施します。

パストラバーサル

アプリケーションが取得するファイルは既定のディレクトリに保存し、アクセスするファイルパスを操作できないようにし、サーバ上でアプリケーションを実行するアカウントのアクセス権限を見直します。また、あらかじめ定義したホワイトリストに基づいた入力値検証を実施し、ファイル名に不正な文字列が含まれる場合は、適切なエラー処理を行うことが推奨されます。

不適切な情報の出力

外部への公開が不要なディレクトリやファイルは、外部からアクセスできないように適切なアクセス制御を行います。ログイン認証によるアクセス制御を実施する場合には、適切なセッション管理を伴った認証機構を実装してください。また、アプリケーションの動作に必要がないディレクトリやファイルは削除することを推奨します。

まとめ

セッション管理の不備/アクセス制御の不備の脆弱性（3人と上部にランプがついたアイコンマーク）イメージ

セッション管理の不備は、セッション管理に不備があることで、ユーザになりすまし、プライベートな情報の閲覧や、設定の変更などができてしまう問題です。対策方法としては、セッションIDを容易に推測できないものにし、ワンタイムトークンの発行やIPアドレスによるユーザの確認を行うなど、適切なセッション管理を実装することで、ユーザの情報やデータを安全に保護することができます。

アクセス制御の不備は、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。ユーザに対して、あらかじめ与えられた権限から外れた操作を実行できないようにポリシーを適用することにより、情報の漏えいやシステムの不正操作を防ぎます。

セキュリティ対策を適切に実施することが、Webアプリケーションの安全性を高めるための鍵となります。ユーザの情報やデータを保護するために、セキュリティ専門家への相談、常に最新のセキュリティ情報の収集をすることなどが重要です。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月22日2023年12月27日

SQLインジェクションの脆弱性
-Webアプリケーションの脆弱性入門 2-

SQLインジェクション攻撃は多くの企業やシステムにとって大きな課題となっています。本記事では、SQLインジェクションの基本的な仕組みから、その主な原因とリスクについて解説します。また、企業での対策方法についても紹介します。SQLインジェクションの脆弱性のリスクを認識し、その対策方法を学びましょう。

前回までの内容

クロスサイトスクリプティング（XSS）とは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる（できる）事象を指します。このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼び、これは、ユーザのブラウザ上で不正なスクリプトを実行させ、個人情報等を漏えいさせるという仕組みです。XSSには「反射型」「蓄積型」「DOMベース」の3種類があり、それぞれ異なる方法で攻撃が行われます。XSSの主な原因は、出力の検証や処理が不十分であることです。攻撃者は、例えば、コメント欄や検索ボックスなどユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。対策としては、スクリプト言語における特別な意味を持つ文字や記号を置き換える「エスケープ処理」の実施や、Webアプリケーションファイアウォール（WAF）の活用等があります。また、セキュリティ診断を定期的に行い、リスクを可視化して適切なセキュリティ対策を実施することが重要です。

前回記事「クロスサイトスクリプティング（XSS）の脆弱性 -Webアプリケーションの脆弱性入門 1-」より

SQLインジェクションとは

SQLインジェクションは、Webアプリケーションの脆弱性の一つであり、多くの企業や中小企業がこの攻撃の影響を受ける可能性があります。具体的には、攻撃者が不正なSQL文を挿入することで、データベースを不正に操作することを指します。例えば、攻撃者は不正な文字列や記号を入力値として使用し、データベースの内容を改竄したり、顧客の情報を不正に取得したりすることができます。

SQLインジェクション攻撃の基本的な仕組み

SQLインジェクション攻撃は、不正な文字列や特殊文字を入力値として使用し、データベースの処理や検索を操作する脅威の一つで、悪意のある第三者が、通常の入力欄に異常な構文や文字を注入することで、情報の取得や変更が可能です。

SQLインジェクションの脆弱性が発生する主な原因とリスク

SQLインジェクションは、WebアプリケーションでのSQL文の組み立て方法に問題がある場合に、攻撃者が挿入した不正なSQL文を誤った命令文として認識してしまうことで発生します。SQLインジェクション攻撃により、インシデントが発生した場合、企業の顧客情報や決済履歴などの機密情報が第三者に漏えいする恐れがあります。その結果、企業のセキュリティ対策姿勢が疑われ、インシデントによる直接的な被害だけでは済まない、信用の失墜やブランドイメージの低下といった大きな痛手を受ける恐れがあります。

SQLインジェクション攻撃の事例

2022年に報告されたSQLインジェクションによる情報漏えい事例を紹介します。

国内オンラインショッピングサイトではSQLインジェクションによる攻撃を受け、サービス登録ユーザの氏名、生年月日、メールアドレス、住所などの詳細な個人情報等、275万件以上の情報が漏えいしました*1。その結果、被害の対象となった顧客へのお詫び状の送付、専用のお問い合わせ窓口の設置、個人情報保護委員会や警察への報告、再発防止策の検討を含めたセキュリティ強化、事故に関する継続的な調査対応等に追われました。

データベースの不正操作を許せば、事業活動に必要なデータをすべて消去されるといった最悪の事態も発生しうるため、SQLインジェクションの脆弱性を放置することは非常に危険です。

効果的なSQLインジェクション対策とその実践方法

SQLインジェクションの対策

重要な情報が集まるデータベースは、守るべき優先度がきわめて高く、SQLインジェクション対策としてさまざまな取り組みが行われています。

基本的な対策

プレースホルダを使用したSQL文の構成：プレースホルダは、SQL文における変数の位置を示すために使用され、実際の値は後から安全にバインドされます。特に、バインド処理を実装するライブラリの実装状況によってSQL構文が変化する「動的プレースホルダ」ではなく、SQLの準備段階からSQL構文が変化しない「静的プレースホルダ」の方が、より有効性の高い対策を実現できます。
特殊文字に対するエスケープ処理：運用上の制約等によりプレースホルダを使用したバインド処理が使用できない場合は、特殊文字に対するエスケープ処理を実施することで対策が可能です。なお、エスケープ処理では対策漏れが生じる可能性もあるため、可能な限りプレースホルダを使用することが推奨されます。

保険的な対策

SQLエラー情報の非表示化：エラーメッセージの内容にエラーを起こしたSQL文の情報、使用データベース、テーブル名、カラム名等が含まれる場合、攻撃者に対してSQLインジェクション攻撃を実行するための有益な情報を与えることになります。そのため、エラー情報はクライアントへ出力せずログファイル等で管理することが推奨されます。
アカウントへの適切な権限付与：アプリケーションがデータベースにアクセスする際には、命令文の実行に必要な必要最小限の権限を付与します。これにより、万が一SQLインジェクションが発生しても、被害を最小限に抑えることができます。

SQL文の組み立ては、データベースのセキュリティを維持する上で非常に重要です。セキュアなプラクティスを適用することで、データベースへの攻撃を防ぎつつ、アプリケーションのデータ操作を効率的かつ安全に行うことができます。

SQLインジェクションのテスト方法

システムにSQLインジェクションの脆弱性があるかどうかを調べる方法としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断するというやり方があります。この文字列を「診断文字列」と呼ぶことがあります。

企業のセキュリティ担当者をはじめ、SQLインジェクションの脆弱性に対する問題を理解し、社内で情報を共有し、適切な対策とることで、自組織がSQLインジェクション攻撃を受ける前に被害を未然に防ぐことが可能になるでしょう。

開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。こうした実情に対して有効なのは、Webアプリケーションの定期的なセキュリティ診断です。SQLインジェクションによるリスクを考えると、Webサイト運営者はぜひとも実施すべき対策といえるでしょう。

まとめ

SQLインジェクション攻撃は多くの企業やシステムのセキュリティ上の課題として存在しています。SQLインジェクションは、Webアプリケーションの脆弱性を突いて、不正なSQL文を挿入しデータベースを操作する技術です。主にSQL文の組み立て方法に問題があることで、情報の漏えいやデータの改ざんが可能となります。実際に、国内企業でも情報漏えい事例が発生しており、その影響は甚大です。対策として、プレースホルダの使用、エスケープ処理などが推奨されています。またSQLインジェクションの脆弱性を検出する方法として、定期的にセキュリティ診断を実施し、適切な対策を実施することで、Webアプリケーションのセキュリティを向上できます。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月20日2023年12月25日

クロスサイトスクリプティング（XSS）の脆弱性
-Webアプリケーションの脆弱性入門 1-

クロスサイトスクリプティングはWebアプリケーションの脆弱性の1つです。この記事では、クロスサイトスクリプティングとは何か、その仕組みや種類、そしてそれに関連する脆弱性や攻撃手法について詳しく解説します。さらに、クロスサイトスクリプティングとクロスサイトリクエストフォージェリとの違いや、クロスサイトスクリプティング攻撃を防ぐための対策方法も紹介します。

Webアプリケーションの脆弱性入門

脆弱性は、プログラムの不具合や設計ミスによって発生するセキュリティ上の欠陥です。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクがあります。Webアプリケーションの主な脆弱性にはSQLインジェクション、クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）、セッション管理の不備、アクセス制御の不備があります。脆弱性が悪用されると、機密情報の漏洩、データの改ざん、サービスの停止や遅延、金銭的損失、企業の信頼喪失などの深刻な影響をもたらす可能性があります。対策方法としては、正しい権限管理の実施、定期的なセキュリティチェックの実施、最新のセキュリティパッチの適用などが挙げられます。これらの対策により、脆弱性の早期発見と修正が可能になり、攻撃のリスクを減らすことができます。企業のセキュリティ部門担当者は、社内の機密データや取引先の顧客情報等を守るためにも、脆弱性対策に取り組むことが重要です。

前回記事「Webアプリケーションの脆弱性入門」より

クロスサイトスクリプティング（XSS）とは

クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる（できる）事象を指します。

このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼びます。まず悪意のある第三者が事前にターゲットのWebサイトに特定の文字列のスクリプトを入力値として挿入すると、そのWebサイトにアクセスしたユーザのブラウザ上で挿入したスクリプトが実行されます。これにより、第三者によってブラウザを不正に操作され、ユーザの個人情報が漏えいする、という仕組みになっています。

クロスサイトスクリプティング（XSS）の種類

クロスサイトスクリプティングの脆弱性には主に3つの種類があります。

反射型XSS…攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの
蓄積型XSS…攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの
DOMベースXSS…Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）の違い

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）は、Webアプリケーションのセキュリティ脅威として知られていますが、その仕組みや対策には明確な違いがあります。クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。主に出力の検証が不十分な場合に発生します。一方、クロスサイトリクエストフォージェリ（CSRF）は、ユーザがログインしている状態で、攻撃者が仕掛けた誘導URLをクリックさせることで、ユーザの意図しない操作を実行させる攻撃です。この攻撃は、セッション管理やトークンの処理が不適切な場合に主に発生します。

クロスサイトスクリプティングの脆弱性が発生する原因

クロスサイトスクリプティング（XSS）の脆弱性の主な原因は、出力の検証や処理が不十分であることです。悪意のある攻撃者が特定の文字列やスクリプトを入力し、その内容が未検証のままWebページに表示される場合、クロスサイトスクリプティング攻撃が実行されるリスクが高まります。特に、公開されている企業のWebサイトやアプリケーションで、ユーザからの入力値が適切に処理されず、そのままWebページへの出力処理される場合、情報の漏洩や不正な操作が可能となります。

クロスサイトスクリプティングの脆弱性による影響

脆弱性を放置した場合の影響は、情報の漏洩から不正な操作まで多岐にわたります。攻撃者が悪意のあるスクリプトを挿入することで、顧客の情報を搾取したり、企業の内部情報にアクセスしたりする可能性があります。

クロスサイトスクリプティング攻撃の手法と例

クロスサイトスクリプティング攻撃の手法は、攻撃者が悪意のあるスクリプトを入力し、その内容がそのままWebページへの出力処理に使用されることで、ユーザのブラウザ上でスクリプトが実行されるというものです。例えば、コメント欄や検索ボックスなど、ユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。

クロスサイトスクリプティングの脆弱性への対策

根本的な対策とその重要性

クロスサイトスクリプティングの対策は、リクエストに不正な文字列が含まれていても、それをスクリプトとして機能させないことです。Webページに出力する要素に対して、スクリプト言語等において、その言語にとって特別な意味を持つ文字や記号を別の文字列に置き換える「エスケープ処理」を行います。

対策の重要性は、企業の信頼性や顧客情報の保護に直結しています。特に、自社のWebアプリケーションが公開されている場合、定期的なセキュリティ調査や対策の更新が不可欠です。最後に、社内での知識共有や外部の専門家との相談を通じて、最新の脅威や対策についての知識を更新し続けることが求められます。

WAFを活用したクロスサイトスクリプティングの防御方法

WAF（Webアプリケーションファイアウォール）は、Webアプリケーションへの様々な攻撃を検知し、防御する機能を持っています。通信をリアルタイムで監視し、攻撃と判断された通信を遮断することで、Webサイトの脆弱性が悪用されるのを防ぎます。クロスサイトスクリプティング攻撃やSQLインジェクション攻撃などには、Webアプリケーションへの入力値のチェックなどを行うWAFを用いた防御も考えられます。WAFの導入により、Webサイトのセキュリティレベルを向上させ、ユーザ情報の漏洩やサービスの停止を防げる可能性も高まります。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決とはならない点に注意が必要です。

まとめ

クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。クロスサイトスクリプティングの脆弱性の主な種類には「反射型」「蓄積型」「DOMベース」があり、それぞれ異なる攻撃方法が特徴です。また、XSSとクロスサイトリクエストフォージェリ（CSRF）は両方ともWebアプリケーションの脅威として知られていますが、攻撃の仕組みや対策が異なります。クロスサイトスクリプティングの脆弱性は、出力の検証が不十分な場合に発生し、情報の漏洩や不正な操作が可能となるリスクがあります。対策としては、出力の検証、エスケープ処理などが求められます。

基本的な対策は、Webサイトにおいて、セキュリティ診断によるチェックを定期的に実施してリスクを可視化し、適切なセキュリティ対策を実施することにより、脅威から自社や顧客の情報を保護することとなります。また、企業や組織は、セキュリティ対策の実施や知識の更新をする必要があります。Webアプリケーションのセキュリティを向上させるための知識として、また、日々の開発や運用の中での参考として、本記事を活用してください。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月15日2023年12月20日

APIのセキュリティ
―Webアプリでもスマホアプリでも安全なAPI活用を―

APIはAI、IoT、モバイル、クラウド利用において今や必要不可欠です。利便性があり、利用者も増える一方で、APIを狙ったサイバー攻撃の数も増加傾向にあります。本記事では、APIとは？API連携の仕組みやスマホアプリとの関連、活用のメリットについて触れつつ、APIのセキュリティ対策の一つとして、脆弱性対応の方法ついて解説します。

APIとは

APIとは「Application Programming Interface」の略です。プログラムの機能をその他のプログラムでも利用できるようにするための仕組みです。

ソフトウェアやアプリ、プログラム同士を、APIを介して機能連携させるのが「API連携」です。あるソフトウェアに他のソフトウェアの機能を埋め込むイメージです。API連携によってソフトウェア同士が相互にデータと機能を共有できるようになります。

【APIの活用例】

社内業務システム：チャットAPIを活用してコミュニケーション
会員サービスサイト： SNSアカウント認証APIでログイン
ネットショップ：クレジットカード・認証APIで決済
飲食店サイト：地図情報APIで店舗位置情報表示 × 予約受付APIで予約対応

API活用のメリット

APIには、以下のようなメリットが考えられます。

Web API

「Web API」は、HTTPやHTTPSといったWeb技術により実現される、インターネットを介して情報をやりとりするAPIです。連携するAPI同士が異なるプログラミング言語で構築されていても通信でき、Webブラウザ上でも稼働するWeb APIは汎用性が高く、最も多く活用されているAPIです。

複数のWeb APIを組み合わせて新しいサービスを生み出す”マッシュアップ”が多く行われており、多くの人々が、日々その恩恵を受けていると言えるでしょう。インターネット上には膨大な数のWeb APIが公開されており、今後もマッシュアップは続くものと考えられます。

スマホアプリとAPI

Web APIは、Webアプリケーションばかりでなく、スマートフォンアプリ（スマホアプリ）でも多く活用されています。

例えば、経路案内アプリでは交通機関・運賃・時刻等の情報を的確に検索してくれるAPIが、家計簿アプリでは電子マネーによる決済やクレジットカード決済などの情報を取得して計算してくれるAPIが使用されています。

スマホアプリは、外部との通信をせずにスマホ端末単体で動作するものよりも、インターネットに接続しながら使用するものが圧倒的に多く、ユーザが利用している画面の裏でインターネットを介してサーバとのやりとりが行われており、そこでＷｅｂＡＰＩが稼働しているのです。

スマホアプリのセキュリティについて、SQAT.jpでは以下の記事で解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ瓦版「攻撃者が狙う重要情報の宝庫！ ―スマホアプリのセキュリティ―」

増え続けるAPI活用

国をあげてDXの取り組みが推進されている昨今、AI、IoT、モバイル、クラウド利用において、APIの積極的な活用は不可欠です。

クラウド環境上で動作するアプリ、クラウドネイティブアプリケーションを例にとると、APIを使用している割合は高く、今後さらに増大することが予想されるとの調査結果があります（下図）。

APIに対するセキュリティ脅威

利便性が高いAPIですが、利用が増えれば、そこに存在する様々なデータを攻撃者が狙ってきます。APIに対するセキュリティ脅威の例は以下のとおりです。

APIによって機能や取り扱う情報はそれぞれですが、金融情報のような資産に紐づくデータ、医療情報のような機微情報に関するデータなど、流出して悪用されると深刻な被害につながりかねません。APIを開発・利用する上で、セキュリティは必ず考慮する必要があるということです。

APIのセキュリティ脅威について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ玉手箱「APIのセキュリティ脅威とは」

APIを狙ったサイバー攻撃の増加

APIに対する攻撃は増加傾向にあるとの観測結果が報告されています（下グラフ）。

なお、このグラフで多くの割合を占めている「ローカルファイルインクルージョン」は、攻撃者が対象システムのローカル上のファイルを読み込ませることで、領域外のファイルやディレクトリにアクセスできるようにしてしまう脆弱性です。情報漏洩、任意のコード実行、認証回避、DoS（サービス運用妨害）などの被害につながる恐れがあります。攻撃されたAPIサーバを「踏み台」とした内部/外部ネットワークへのさらなる攻撃やマルウェア感染などが想定されるため、危険度の高い脆弱性と言えます。

また、100ヶ国を対象にしたアンケート調査では、API攻撃による情報漏洩を経験している組織が90％以上にのぼるとの結果も報告されています（下グラフ）。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASP（Open Web Application Security Project）が、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したもので、今回は2019年の初版リリースから4年ぶりの第二版となります。

APIのセキュリティ対策

ここまで見てきたＡＰＩセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

開発中、リリース後、更新時といったいかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

また前段の「スマホアプリとAPI」でも述べたように、APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

BBSecでは

スマホアプリ脆弱性診断

悪意ある第三者の視点で、対象アプリに影響を及ぼす恐れのある脅威と関連リスクをあぶり出します。実機を使った動的解析とAPK（Android）・IPA（iOS）ファイルの静的解析を実施します。

Webアプリケーション脆弱性診断

また、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。弊社診断エンジニアによる、より広範囲で網羅的な診断を検討している方は、手動で診断する、「Webアプリケーション脆弱性診断」がおすすめです。

ウェビナー開催のお知らせ

2024年1月24日（水）13:50～15:00
「Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る