今、危険な脆弱性とその対策
―2021年上半期の診断データや攻撃事例より―

Share
キーボードと虫眼鏡

私たちの生活を支えるWebサイトは、攻撃者からみると、個人情報や機密情報などデータの宝庫であり、魅力的なターゲットになってしまっています。その理由は、Webサイトの多くに脆弱性が存在していることがあるためです。

本記事では、診断会社として多くの企業・組織への診断実績がある弊社の視点で、2021年上半期の診断結果、また攻撃事例などを振り返り、脆弱性対策に有効な手段を考えます。

Webサイトはなぜ狙われる?
―そこに脆弱性があるから

ハッカーがターゲットにしている対象のグラフデータ(The 2021 Hacker Reportより)

サイバー攻撃の対象は、Webサイトが最も高く、ハッカーのほとんどがWebサイトを攻撃しているといっても過言ではありません。

私たちの生活は公私共に、Webシステムに支えられており、Webサイトは個人情報や機密情報の宝庫です。そして、残念ながらWebサイトの多くには脆弱性が存在していることがあります。宝の山に脆弱性があるとなれば、悪意ある者に狙われてしまうのは当然といえます。

2021年上半期Webアプリケーション脆弱性診断結果

弊社では、様々な脆弱性診断メニューをご提供しております。その中で最もニーズの高いWebアプリケーション脆弱性診断について、2021年上半期(2021年1~6月)の結果をご紹介いたします。この半年間で14業種のべ610社、3,688システムに対して診断を行いました。

業種やシステムの大小にかかわらず、多くのWebアプリケーションになんらかの脆弱性が存在しています。検出された脆弱性をカテゴリ分けした内訳は円グラフのとおりです。

上半期診断結果脆弱カテゴリ別の円グラフ

このうち、例として、4割近くを占める「システム情報・ポリシーに関する問題」と、1割強程度ではあるものの、危険度の高い脆弱性が目立つ「入出力制御に関する問題」に分類される脆弱性の検出数をご覧ください(下記、棒グラフ参照)。

既知の脆弱性が検出されている、あるいはすでにベンダサポートが終了しているバージョンのOSやアプリケーションソフトの使用が数多く見られます。また、Webアプリケーションにおける脆弱性の代表格ともいえる「クロスサイトスクリプティング」や「SQLインジェクション」は、いまだ検出され続けているのが現状です。こうした脆弱性を放置しておくとどうなるか、実際に発生したインシデントの例を見てみましょう。

脆弱性を悪用した攻撃事例1:
既知の脆弱性が存在するWordPress

脆弱性のあるWordPressの悪用例

Webサイトの構築を便利にするCMS(Contents Management System)のうち、WordPressは世界でダントツのシェア40%以上を誇っています(CMS不使用は約35%、その他のCMSはすべて一桁パーセント以下のシェアです)*1。CMSの代名詞といえるWordPressですが、その分サイバー攻撃者の注目度も高く、脆弱性の発見とこれに対応したアップグレードを常に繰り返しています。

2021年に入ってからも10件以上の脆弱性が報告*2されているほか、国内でもWordPressを最新バージョンにアップデートしていなかったことで不正アクセスを受けたとの報告*3が上がっています。

脆弱性を悪用した攻撃事例2:SQLインジェクション

その対策が広く知れ渡っている今でも、「SQLインジェクション」は診断結果の中に比較的検出される項目です。

SQLインジェクション攻撃による国内情報流出事例

2021年も、実際にSQLインジェクション攻撃を受けたという報告*4が複数上がっています。

「SQLインジェクション」や「クロスサイトスクリプティング」のような、比較的知られている脆弱性に起因するインシデント事例は、企業のセキュリティ対策姿勢が疑われる結果につながり、インシデントによる直接的な被害だけでは済まない、信用の失墜やブランドイメージの低下といった大きな痛手を受ける恐れがあります。

最も危険な脆弱性ランキング

最も悪用された脆弱性ワースト30

脆弱性対策は世界的な問題です。2021年7月、アメリカ、イギリス、オーストラリア各国のセキュリティ機関が、共同で「Top Routinely Exploited Vulnerabilities(最も悪用されている脆弱性)」の30件を発表しました。

出典:https://us-cert.cisa.gov/ncas/alerts/aa21-209aより弊社作成

2021年にかけてサイバー攻撃グループが悪用していることが示唆されているものが多く含まれており、いまだ世界中の多くの企業や組織では、前述の脆弱性に対して未対応であることがうかがえます。

上記一覧からおわかりのとおり、ほとんどが、業務利用されているおなじみの製品群です。リモートワークの促進やクラウドシフトといったIT環境の変化が、既知の脆弱性に悪用する価値を与えているのです。各セキュリティ機関は、特にVPN製品に関する脆弱性に警鐘を鳴らしています。

思い当たる製品がある場合は、まずは侵害の痕跡(IoC:Indicator of Compromise)があるか確認し、必要に応じて対処する必要があります。そして可能な限り早急にパッチを適用する必要があります。いずれの製品にもセキュリティパッチがリリースされています。

最も危険なソフトウェアエラー 「CWE TOP25」2021年版

危険な脆弱性に関する情報として、米MITRE社より、「2021 CWE Top 25 Most Dangerous Software Weaknesses(最も危険なソフトウェアエラーTop25 2021年版)」も発表されています。CWE(Common Weakness Enumeration)は、ソフトウェアにおける共通脆弱性分類です。脆弱性項目ごとに一意のIDが決められ、そのタイプごとに体系化されています。

出典:https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html より弊社翻訳

前年度と比較して順位を上げている項目については、特に脅威が高まっていると言えます。自組織のセキュリティの弱点と関係しているかといった分析や優先的に対策すべき項目の検討などに役立つ情報です。

脆弱性の対策に有効な手段とは?

多くのWebサイトに脆弱性が存在していることについて述べてまいりました。脆弱性の放置は、サイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。たとえサイバー攻撃をすべて防ぎきることはできないにしても、セキュリティ対策をどのように講じてきたかという姿勢が問われる時代です。基本的なセキュリティ対策を怠っていたばかりに、大きく信頼を損ねる結果とならないようにしたいものです。

Webサイトにおける脆弱性の有無を確認するには、脆弱性診断が最も有効な手段です。自組織のセキュリティ状態を把握して、リスクを可視化することが、セキュリティ対策の第一歩となります。脆弱性診断を効果的に行うコツは、「システムライフサイクルに応じて」「定期的に」です。脆弱性の状況は、新規リリース時や改修時ばかりでなく、時宜に応じて変化することに注意が必要です。

変化という意味では、脆弱性情報のトレンドを把握するのも重要です。この点、様々なセキュリティ機関やセキュリティベンダなどが情報配信を行っていますので、最新状況のキャッチアップにご活用ください。

弊社では昨年8月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

リスク評価、セキュリティ対策検討の初動である、脆弱性診断および脆弱性情報の収集が、健全な事業活動継続の実現に寄与します。

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー

Share

中小企業がサイバー攻撃の標的に!
Webサイトのセキュリティ対策の重要性
―個人情報保護法改正のポイント―

Share
PCのイラストとプロテクトマーク

2022年(令和4年)4月1日に改正個人情報保護法(令和2年改正法)の全面施行が予定されています。いま、攻撃者にとって格好のターゲットとなるWebサイトを狙ったサイバー攻撃は、大企業のみならず中小企業も狙われており、サイバーセキュリティに対する意識が低いなどセキュリティ課題が明らかになっています。本記事では、個人情報保護法改正の全面施行に向け、改正点を解説し、最新のサイバー攻撃の種類と手口、セキュリティ対策を改めて整理します。

サイバー攻撃や組織における管理またはシステムの設定不備・不足等が原因となり、個人情報を含む機密情報の漏洩事故および事件が相次いで発生しています。東京商工リサーチの調べ*5によれば、2020年に上場企業とその子会社で個人情報漏洩または紛失事故・事件を公表したのは88社、漏洩した個人情報は約2,515万人分とされています。個人情報の漏洩または紛失事故・事件は年々増加の傾向にあり、同社の調査結果を見ても2020年は社数では最多、事故・事件の件数は2013年に次いで過去2番目に多い水準となっています。

出典:東京商工リサーチ「上場企業の個人情報漏えい・紛失事故」調査(2020年)

改正個人情報保護法への対応

個人情報の保護においては、2022年(令和4年)4月1日に改正個人情報保護法(令和2年改正法)の全面施行が予定されています。また海外でも法の整備が進んでおり、日本企業と関連性の深いところでは、例えば8月にブラジル個人情報保護法(LGPD)、2022年6月頃にタイ個人情報保護法(PDPA)の施行があります。多くの組織にとって、自組織やサプライチェーン内の関係組織かを問わず、国内外における個人情報保護体制の整備・見直しが必要であり、改正個人情報保護法への対応は重要課題の一つといえるでしょう。

個人情報保護法改正のポイント

個人情報保護法の主な改正点は以下のとおりです。

また、これら以外ではデータの利活用が促進されることもポイントです。この観点からは「仮名加工情報」について事業者の義務が緩和されることと、情報の提供先で個人情報となることが想定される場合の確認が義務化されることが定められました。企業のWebサイトでは利用者の閲覧履歴を記録する仕組みとしてCookieを使用し、デジタルマーケティング等に活用しているところも多いでしょう。Cookieにより取得されるデータは他の情報と照合するなどして個人の特定につながり得るため、保護を強化する声が高まっていたこともあり、改正個人情報保護法では取り扱いに慎重を期するよう求めています。

中小企業を狙ったサイバー攻撃

Cookieのみならず、Webサイトでは個人情報や決済情報など、様々な機密扱いの重要情報を取り扱っていることがあります。それらが漏洩する事故・事件が発生した場合、組織は金銭的損失や信用失墜に陥るだけでなく、個人情報の所有者(本人)から利用停止・消去請求があった場合には「情報資産」も失う可能性があります。

サイバー攻撃においてWebサイトが格好のターゲットであることはご存知のことでしょう。また、攻撃者に狙われるのは大企業ばかりではありません。経済産業省からの報告資料*2によれば、全国の中小企業もサイバー攻撃を受けていることが明らかになっています。というのも、中小企業の多くは大企業に比べてサイバーセキュリティに対する意識が低く、被害者になると考えていないことから攻撃を受けていること自体に気付いていなかったり、セキュリティに対する知識や対策に必要な資源が不十分であるために原因の特定や対策の実施が困難だったりするためです。

独立行政法人 情報処理推進機構(IPA)が2021年3月に公開した「小規模ウェブサイト運営者の脆弱性対策に関する調査報告書」では、小規模Webサイトの運営およびセキュリティ対策、さらには脆弱性対策の実態を調査したアンケート結果とそれに対する見解が述べられています。

IPAが調査の中で、サイバー攻撃の対象となり得る、脆弱性を作りこむ可能性があるWebサイトの機能・画面を選定し、それらが実装されているかを確認したところ、「ユーザによるフォームの入力(問合せ、掲示板等を含む)」が56.5%、「サイト内の検索と結果表示」が36.9%、「ユーザへのメール自動送信」が36.9%、「入力された情報の確認のための表示」が34.6%で上位を占めました。なお、これらはWebサイトの規模の大小にかかわらず多くのWebサイトに共通して実装されている機能・画面であり、当社の脆弱性診断でも検査の対象となっているものです。

Webサイトのセキュリティ対策において、脆弱性を可能な限り作りこまない設計となっているか、脆弱性を発見するための情報収集や検査は実施しているか、対応するための体制や仕組みはあるか、といった事柄はとても重要になります。

中小企業がより危険視されているのは、こうした事柄を実現するための「人員が足りない」「予算が確保できない」といった課題(下図参照)があり、さらにセキュリティ対策に関する知識不足や、意識の甘さがあることからサイバー攻撃のターゲットになりやすいことが理由に挙げられます。また、脆弱性に関する知識についても、情報漏洩につながる危険性のある「SQLインジェクション」や「OSコマンドインジェクション」等について具体的な内容を知らないという回答が約50%~60%に上りました。

出典:IPA「小規模ウェブサイト運営者の脆弱性対策に関する調査報告書」

サイバー攻撃の種類と手口

サイバー攻撃は多種多様なものが存在しますが、最近では特に次のような攻撃が大きな問題となっています。

① 分散型サービス運用妨害(DDoS)攻撃
  攻撃対象に対して複数のシステムから大量の通信を行い、
  意図的に過剰な負荷を与える攻撃
② ランサムウェア攻撃
  データを暗号化したり機能を制限したりすることで使用不能な状態にした後、
  元に戻すことと引き換えに「身代金」を要求するマルウェアによる攻撃
③ ビジネスメール詐欺
  従業員や取引先などになりすまして業務用とみられる不正なメールを送ることで
  受信者を欺き、金銭や情報を奪取する攻撃
④ Webサービスからの個人情報窃取
  Webサービス(自社開発のアプリケーションや一般的に使用されているフレームワーク、
  ミドルウェア等)の脆弱性を突いて、個人情報を窃取する攻撃
  ※前段で触れた、情報漏洩につながる危険性がある
  「SQLインジェクション」や「OSコマンドインジェクション」もこれに分類されます。

それぞれの攻撃の目的および手口や対策の例を以下にまとめました。金銭的利益は攻撃目的の大半を占めますが、それ以外を目的とした攻撃も多数確認されています。その他代表的な攻撃や目的については、「サイバー攻撃を行う5つの主体と5つの目的」で参照いただけます。

Webサイトの脆弱性対策

改正個人情報保護法の全面施行に向けて、組織は個人情報をさらに厳格に管理する必要があります。前述のとおり、6か月以内に消去する短期保存データも「保有個人データ」に含まれるようになるため、例えば、期間限定のキャンペーン応募サイトなども今後は適用範囲内となります。公開期間は短くとも、事前にしっかりとセキュリティ対策の有効性を確認しておく必要があるでしょう。

情報の安全な管理を怠り流出させた場合、それが個人情報であれば罰則が適用される可能性があり、取引先情報なら損害賠償を要求されることが想定されます。また、ひとたびセキュリティ事故が起これば、企業の信用問題にも陥りかねません。

2021年3月にIPAが公開した「企業ウェブサイトのための脆弱性対応ガイド」では、脆弱性対策として最低限実施しておくべき項目として以下7つのポイントを挙げています。

(1) 実施しているセキュリティ対策を把握する
(2) 脆弱性への対処をより詳しく検討する
(3) Webサイトの構築時にセキュリティに配慮する
(4) セキュリティ対策を外部に任せる
(5) セキュリティの担当者と作業を決めておく
(6) 脆弱性の報告やトラブルには適切に対処する
(7) 難しければ専門家に支援を頼む

脆弱性対策を行うためには、まずWebサイトに脆弱性が存在しているかを確認することから始めましょう。脆弱性診断を行い、Webサイトのセキュリティ状態をきちんと把握することで内包するリスクが可視化され、適切な対応を講じることが可能となります。また、Webサイトの安全性を維持するには、定期的な診断の実施が推奨されます。定期的な診断は、新たな脆弱性の発見のみならず、最新の攻撃手法に対する耐性の確認やリスク管理にも有効です。

セキュリティ対策を外部の専門業者に依頼する場合に、「技術の習得や情報の入手・選別が難しい」といった課題もあります。弊社では昨年8月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

Webサイトは、いまや企業がビジネスを行う上で不可欠なツールの一つとなっている一方で、安全に運用されていない場合、大きな弱点となり得ます。脆弱性対策を行い、セキュリティ事故を未然に防ぐ、そして万が一攻撃を受けた際にも耐え得る堅牢なWebサイトを目指しましょう。


セキュリティレポート資料ダウンロードページボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


SQAT® Security Serviceページへのバナー

BBSecコーポレートサイトへのバナー

Share

SQLインジェクションの脆弱性、企業が問われる2つの責任とは

Share

この記事では、XSS(クロスサイトスクリプティング)と並ぶ、Webアプリケーションの代表的脆弱性といえる「SQLインジェクション」について解説します。

XSSとSQLインジェクションの違いや、SQLインジェクション攻撃が実際に行われるまでの手口、セキュリティ会社がどのようにSQLインジェクションの脆弱性の有無を判断しているかなどを解説します。また、SQLインジェクションを放置した責任を企業が問われた裁判の判決も紹介し、最後にSQLインジェクションの対策方法を考えます。

SQLインジェクションとは

「SQLインジェクション」とは、データベースを操作する「SQL」という言語を悪用して、Webアプリケーションの入力フィールドに悪意のあるSQL文を入力するなどして行うサイバー攻撃のことです。SQLインジェクション攻撃によって、なりすまし、Webサイトの改ざん、あるいはデータを盗んだり破壊したりといったことが可能になります。

XSSとSQLインジェクションの違い

もうひとつの代表的な脆弱性であるXSSは、Webサイトにアクセスしているユーザに対して攻撃を行います。一方、SQLインジェクションは、攻撃対象がユーザではなくデータベースです。データベースに登録されている全てのデータが攻撃対象になり得るという点で、SQLインジェクションの方が、被害が発生した場合の規模がより大きくなる傾向があります。管理者にとって見つかったらとても嫌な脆弱性のひとつです。

SQLインジェクション攻撃が行われる仕組み

SQLとはデータベースを操作するための言語です。MySQL、PostgreSQL、Oracleなど、さまざまなデータベースで広く使われており、これらのデータベースは、すべてSQLインジェクションの攻撃を受ける可能性があります。

「Shodan(ショーダン)」というちょっと変わった検索エンジンでは、Webサイトのコンテンツではなく、インターネットに存在するコンピュータやIoT機器を探せるのですが、このShodanで「sql」と検索すれば、サーバヘッダに「SQL」が入ったコンピュータやサーバの一覧が山ほどリストアップされます。

サイバー攻撃者は、しばしばこうした情報をもとに標的を探し出し、一覧の中から、SQLインジェクションの脆弱性が放置されているサーバをさまざまな方法で絞り込み、攻撃を実行します。

脆弱性診断の現場でSQLインジェクションはどのぐらい見つかるのか

弊社が実施しているWebアプリケーション脆弱性診断の2020年上半期統計(14業種延べ533企業・団体。4596システムの診断結果)では、SQLインジェクションは、検出される全脆弱性(システム全体の83.9%)のうち1%ほどとなっています。被害が発生した場合のインパクトが極めて大きな脆弱性ですので、これは決して小さい数字であるとは言えません。

SQLインジェクションを検出する方法

一般的なやり方としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断します。こうした文字列を「診断文字列」と呼ぶことがあります。ちなみに、SQLインジェクションの脆弱性が存在する場合に、個人情報の取得ができるかどうかまでを実際にやってみるのがペネトレーションテストです。

SQLインジェクションの脆弱性を突かれた被害事例、企業が負う2つの責任

SQLインジェクションの脆弱性への対策を怠った結果、Webサイトが攻撃を受けて被害が発生してしまった場合、企業はどのような責任を負うことになるのでしょうか。

運営責任

あるショッピングサイトの被害事例からご紹介しましょう。このサイトでは、SQLインジェクションによる攻撃を受け、クレジットカード情報を含む最大10万件の個人情報が漏えいしました。その結果、営業停止による機会損失に加え、顧客に対する賠償用買い物ポイントの付与、お詫び状送付、被害者対応、インシデントの調査などに多くの費用がかかりました。

これは、欠陥を含むシステムを運営していた代償であり、「運営責任」を問われたかたちです。

開発責任―東京地裁判決より

続いて、運営責任ではなく、システムの「開発責任」を問われた例として、2014年にあった裁判の判決(平成23年(ワ)第32060号)をご紹介します。

とある企業の依頼で開発、納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性が存在し、その結果、不正アクセスによる情報漏えい事故が発生しました。開発を依頼した側の企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として裁判に訴えました。東京地方裁判所はそれを認め、開発会社には約2,200万円の損害賠償支払いが命じられました。

SQLインジェクションはより過失度が大きい脆弱性

情報漏えいとは? 代表的な原因や求められる対応策」で解説していますが、どんな情報が漏えいしたかによって、情報漏えいの深刻度は異なります。たとえば、メールアドレスとセットでそれに紐付くパスワードも漏えいしていたとしたら、メールアドレスのみが漏えいした場合と比べ、事態はより深刻です。

そして、データベースに保存されるのは重要な情報ですから、そこを攻撃対象とするSQLインジェクションは、対策の優先順位が非常に高い脆弱性だといえます。対策を怠り、事故を招いた場合、社会やユーザからは非常に厳しい目が向けられるでしょう。

たとえば、納品したオンラインショッピングのシステムにSQLインジェクションの脆弱性が存在していたら、上述のように債務不履行、納品物の瑕疵とみなされ、SQLインジェクションの脆弱性を放置したままWebサイトを運営していたら、管理義務を果たしていないとみなされる可能性があるのです。

さらに言えば、Webサイトの開発責任が他社にあり、他社から賠償を受けられたとしても、Webサイトの運営側ではエンドユーザに対してなんの申し開きも立ちません。たとえばこれは、食中毒を出したレストランが、顧客に対して「傷んでいた食材を納品した卸業者が悪い」と言えないのと同じことなのです。

SQLインジェクション対策

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

まず、DevSecOpsの考えのもとでセキュアコーディングを行ったり、開発段階で脆弱性が作り込まれていないかソースコード診断を行ったりすることは、コストパフォーマンスの高い、きわめて有効な対策です。

さらに、近年、SQLインジェクションをはじめとするWebアプリケーション脆弱性に対処する仕組みが、アプリケーションやミドルウェア、開発環境側で整いつつあります。脆弱性のあるWebアプリケーションへの悪意ある通信をブロックするWeb Application Firewall(WAF)の普及も進んでいます。

2021年現在、最新のアプリケーションと開発環境を用いて新規にWebアプリケーションを開発するなら、たとえセキュリティを意識せずに開発に取り組んでいたとしても、SQLインジェクションの脆弱性が作り込まれることは少なくなってきているといえるでしょう。

しかしながら、すべての開発会社が最新の環境で開発を行える、ということはありません。DevSecOpsも、開発の考え方としてはまだ新しく普及はこれからという面があり、また、ソースコード診断を行うことができるような予算やスケジュールを確保できないことも多いでしょう。さらに、開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。

こうした実情に対して有効なのは、Webアプリケーションの定期的な脆弱性診断です。SQLインジェクションによるリスクを考えると、これはサイトを運営するならばぜひとも実施すべき対策、といえるでしょう。

まとめ

  • SQLインジェクションとはデータベースを操作する「SQL」という言語を悪用して行うサイバー攻撃、あるいはその脆弱性のことです。
  • Webサイトにアクセスしているユーザを狙うXSSと違って、Webサイトに登録済みのデータを狙うSQLインジェクションでは、より規模の大きい被害が発生する傾向があります。
  • 多くのデータベースではSQL言語が使われており、それらのデータベースはすべて潜在的にSQLインジェクションの攻撃を受ける可能性があります。
  • SQLインジェクション攻撃では、大規模な個人情報漏えいが起こる可能性が高く、そうなった場合、企業は運営責任を問われます。
  • SQLインジェクションの脆弱性を作り込んでしまった会社に損害賠償を命じる判決が下されたこともあります。
  • 最新の環境で開発を行えば発生しづらくなってはいるSQLインジェクションですが、リスクはゼロではありません。定期的な脆弱性診断は有効性の高い対策と考えてよいでしょう。

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

ソースコード診断の必要性とは?目的とメリットを紹介

Share

ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。ソースコード診断を行うことで防げるサイバー攻撃や、ソースコード診断ならではの強み、ソースコード診断とDevSecOpsとの関連、上手な利用手順などを解説しています

企業が提供するWebサービスや、社内で活用するさまざまな業務用アプリケーションを検査、評価する方法はいくつも存在しています。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは?

ソースコード診断とは、アプリケーションのソースコード(開発者が書いたプログラム)を解析して、セキュリティを含めて品質上の問題となるバグを検出する診断です。無料の診断ツールや、セキュリティベンダーが提供する診断サービスがあります。診断対象はWebアプリケーションを始めとして、スマートフォンやIoT機器上で動くアプリケーションにまで広がっています。

ソースコードを開示するため、ソースコード診断はホワイトボックステストと呼ばれます。これに対して、ソースコードや設計書を見ずに、システムの外部からアクセスして脆弱性や動作を検証する方法をブラックボックステストと呼びます。

ソースコード診断の特徴とメリット

ブラックボックステストでは検出が難しい脆弱性がソースコード診断なら検知できる場合があります。具体的には 「ソースコード診断で検出できる脆弱性」で後述します。

ブラックボックステストは、すでにソフトウェアあるいはシステムが機能していることを前提とした、リリース前あるいはリリース後に実施します。これに対して、ソースコード診断はその前段である開発プロセスから実施できるため、テスト結果を受けてプログラムを修正することが可能です。

開発の手戻りを減らすことでコストや工数削減につながります。詳細は「ソースコード診断の有効性」を参照してください。

ソースコード診断を実施する目的

ソースコード診断の目的は、プログラムに作りこんでしまった脆弱性を網羅的に検出することです。開発時に繰り返し実施し、開発者が修正していく運用が想定されています。

システムのセキュリティを確保する方法

開発(Dev)、運用(Ops)、セキュリティ(Sec)を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsではシステムライフサイクルの初期から各段階でセキュリティについて考察、対処していきます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

セキュアプログラミング

ソースコード診断の前に、そもそもシステムの設計・開発段階で、開発者が脆弱性を作りこまないようにする手法があります。これをセキュアプログラミングと呼びます。セキュアプログラミングで開発し、本当に脆弱性を作りこんでいないかどうかソースコード診断でチェックします。

ソースコード診断

ソースコード診断には、ツールを用いて自動的に処理するツール診断(自動診断)と、セキュリティエンジニアが目視で確認する手動診断があります。

効率的に網羅性を確保できる自動診断ツールの支援は欠かせません。

一方手動診断は、機械的に検出できず、人間による判断が必要な脆弱性を発見します。手動のみで行う場合もありますが、多くはツール診断と組み合わせて網羅性と精度を上げていきます。

脆弱性診断(セキュリティ診断)

システムのセキュリティを確保する方法には、ソースコード診断のほかに脆弱性診断(セキュリティ診断)もあります。脆弱性診断とは、システムの外部からアクセスして既知の脆弱性の有無を検証する方法です。システム構築後のさまざまなフェーズで実施します。

診断対象は、Webアプリケーションスマホアプリケーション、サーバ(OS等)ネットワークインフラなどさまざまです。

なお「セキュリティ診断」という名称で、脆弱性診断サービスが提供されている場合もあります。

ソースコード診断の有効性

ソースコード診断は開発フェーズ初期から実施可能です。リリース直前やリリース後に脆弱性が発見される可能性を抑えることで、より効率的で信頼性の高いシステム開発が可能になります。

CPE-Coreとはソースコード内の脆弱性と品質面の問題を検査する当社の自動自動静的解析ツールです。

ソースコード診断で検出できる脆弱性

一般的な脆弱性診断では検出しにくい脆弱性も、ソースコード診断では発見できる場合があります。たとえば未使用のコード、ログの改ざん、ログファイルやエラーメッセージへの機密情報の出力などは、ソースコードを直接確認することで検知可能になります。

以下、代表的な脆弱性(セキュリティバグ)について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオバーフロー

プログラムを実行する際に確保するメモリ上のバッファ領域に対して、このサイズを超過するデータを書き込めるようになっているバグです。攻撃者は超過する部分に不正なプログラムを書いて実行します。

フォーマットストリング

プログラム中の、書式設定用の関数(フォーマットストリング)の引数の処理に関するセキュリティバグです。正しくは、引数として不正な値が入力された場合には、処理を止めてエラーメッセージを返さなければなりません。

SQLインジェクション/コマンドインジェクション

SQL(データベースを定義、操作する言語)文や、その他のコマンドが入力された場合でも、エラーにせずに処理してしまうバグです。攻撃者の観点からは、コマンドを注入(インジェクション)する形になるため、この名が付いています。攻撃の入り口はアプリケーション上の通常の入力欄で、ここに不正な値を入力することで攻撃を開始します。

クロスサイト・スクリプティング

悪意のあるスクリプト(プログラム)をユーザのコンピュータに注入して、複数のWebサイトをまたいで(クロスサイト)行う攻撃や、その攻撃で利用される脆弱性を指します。

まとめ

・ソースコード診断はソースコード(開発者が書いたプログラム)を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・ソースコード診断のためのツールを効果的に活用しながら、熟練の技術者が手動でソースコード診断を行う


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

業界別診断結果レーダーチャート

Share

2019年下半期 Webアプリケーション診断

診断対象を業界別に分類し、当社報告書内で使用している、入出力制御、認証、セッション管理、重要情報の取り扱い、システム情報・ポリシーといったカテゴリごとに、検出された脆弱性をリスクの重大性で評価してレー ダーチャート化した。レーダーチャートの算出方法は、集計期間に検出された脆弱性の平均値から、システムごとに判定した結果の平均値である。今回は、オリンピック・パラリンピックを目前に控え、新しい試みを続ける観光・宿泊・運輸(航空・旅客)業などの「ホスピタリティ」業界をピックアップし、分析した。

「高」リスク以上の脆弱性が検出されたシステムであっても、正しい対処を施せば影響は最小化できる。また、事故を未然に防ぐための方法を、官公庁などがガイドラインや対策提言などとして発表しているので、これらも参考にしていただきたい。

ホスピタリティ業界

図1 検出された脆弱性の平均値

ホスピタリティ業界(観光・宿泊・運輸)分野のシステム脆弱性診断の平均値は図1のとおり。システム情報・ポリシーにおいてやや数値が低いものの、平均して大きな問題が検出されたシステムは少ない。

しかし注意を喚起したいのが、このレーダーチャートがあくまでも「平均」であることだ。殆どのシステムは平均値を上回る、あるいはほぼ平均値に近い値であったものの、大きく平均を下回るシステムも存在した。特に入出力制御とセッション管理においてその傾向が顕著であった。なお、システム情報・ポリシーは総じて平均に近い値であった。オリンピック・パラリンピックに向けて活況な業界の現状と課題について考えていく。

電子商取引(BtoC-EC)の活況と課題

2019年5月に経済産業省が公表した「平成30年度 我が国におけるデータ駆動型社会に係る基盤整備」によれば、日本のBtoC-ECのサービス系分野において、最も市場規模が大きいのが旅行サービスである。2018年のBtoC-ECの市場規模は3兆7,186億円にのぼり、全体の約56%を占める。ここでいう「旅行サービス」とは、旅行代理店への申し込み、航空機利用(国内便・国際便)、鉄道(新幹線・その他在来線)、バス利用、ホテル・旅館の宿泊費に関して、消費者の国内外を問わず日本の事業者に支払いが発生する市場を指す(ビジネスで利用する「出張」は除外)。牽引するのはインターネット専業の旅行代理店(通称:OTA :Online Travel Agency)で、国内のサイトをはじめ、エクスペディアやBooking.comといった外資系OTAも目立っている。特にインバウンドにおいては外資系OTA抜きでは成り立たないといっても過言ではない。

旅行サービス業においてBtoC-ECは、航空券やホテル予約における空席や空室といった「在庫」管理に直結している。例えば、客室数という確定サービス枠が存在し、空室を「在庫」として顧客に提示しインターネットを介して予約を受け付け、自動で在庫管理を行う形態は、「在庫数」が明確に定義できるサービスにとって非常に親和性の高い形態である。

しかし、市場が成長を続ける一方でセキュリティの甘さも課題として浮かんできた。

2018年にセキュリティ企業のTrustwaveが犯罪被害にあった世界19カ国の企業・団体など数千社を対象に行った調査結果では、宿泊業・旅行業を含む「ホスピタリティ産業」は、小売、金融に次いで3番目に被害が多く、全体の10%を占めた。特にクレジットカード払いができるシステムが狙われている。またセキュリティ企業のDashlaneが2018年に実施した調査では、旅行関連サイト55社の89%でパスワードポリシーや認証機構に問題があったとの結果が報告されている。さらにシマンテックの研究者による調査では、54カ国約1,500のホテルにおける67%もの予約サイトがサードパーティサイトに予約参照コードを意図せず漏らしているリスクを内包しているという報告がなされている。同調査では、ホテルサイトの4分の1以上(29%)が、顧客への予約受領のメールに記載している予約管理システムへのリンクを暗号化していないとも述べている。実店舗を狙ったサイバー攻撃は減少傾向にあるものの、電子商取引ではむしろ増加傾向にあるといえるだろう。

OTAに関しては観光庁が2015年に「オンライン旅行取引の表示等に関するガイドライン」を策定し、旅行業のオンライン取引で表示すべき内容やその表示方法について細かく規定した。しかしセキュリティ対策については触れられておらず、各企業・団体によって対策状況はまちまちであった。2016年、大手旅行会社・中堅運輸会社において情報流出事件が発生したのを受け、「観光庁・旅行業界情報共有会議」が発足された。「中間とりまとめ」において旅行業情報セキュリティ向上のため早急に講ずべき対策が提言され、2018年には「旅行業者における情報セキュリティ確保に係る安全ガイドライン」策定の予算が支出されたものの、2020年1月の段階では、公表されていなかった。ただし、社団法人日本旅行業協会/社団法人全国旅行業協会が2014年に「旅行のウェブ取引に関するガイドライン(改訂版)」を出しており、事実上これがスタンダードになっているともいえる。

一方、国土交通省ではサイバーセキュリティ戦略本部の「重要インフラ分野における情報セキュリティ確保に係る安全基準等策定指針」に依拠する形で、航空・物流・鉄道・空港の各分野に対し、個別に「情報セキュリティ確保に係る安全ガイドライン」を策定している。また、鉄道、バス・バスターミナル、タクシー、宿泊施設の各業種に対しては個別の「情報セキュリティ対策のチェックリスト」を公開して対策を促している。

インバウンドサービスの動向

ホスピタリティ業界において今年開催のオリンピック・パラリンピックを目前に脚光を浴びているのが、訪日外国人観光客を対象とするインバウンドサービスである。日本が「観光立国」を打ち出したのは今から17年ほど以前に遡る。小泉首相(当時)による「観光立国懇談会」が平成15年(2003年)に発足し、2006年には「観光立国推進基本法」が成立した。2015年以降、国際貿易収支上、観光業は「輸出産業」となっている。また、2019年の世界経済フォーラムの観光競争力レポートでは第4位と、2017年より2回連続で上位にランクインしている。日本の評価を押し上げた項目としては「安全・安心」、「保険・衛生」、「ICTの普及」がある。

世界観光機関(UNWTO)によれば、今後のインバウンドサービスのカギとなるのはデジタル技術、特にバーチャル・アシスタントとリアルタイムデスティネーションであるとしている。国土交通省では令和元年度の施策として、主要観光地の多言語対応、全国3万カ所の主要観光地・防災拠点で無料Wi-Fi整備を進めるとともに、「キャッシュレス・消費者還元事業」として中小・小規模事業者のキャッシュレス決済の普及に力を注いでいる。観光庁も、2018年には「外国人観光旅客利便増進措置に関する基準」、「公共交通機関における外国人観光旅客利便増進措置ガイドライン」を策定した。同ガイドラインでは「インターネットによる予約環境の整備」として「インターネット上でクレジットカード等による決済も可能であることが望ましい」としている一方で、セキュリティに関しては、「公衆無線LAN等を整備するにあたっては、以下を参照されたい」として、「Wi-Fi提供者向けセキュリティ対策の手引き」(平成28年総務省)、「公衆無線LANセキュリティ分科会報告書」(平成30年3月総務省)を挙げているのみである。

旅行者はパスポート、支払い情報、詳細な旅程など、データの宝庫を持ち歩く存在といえる。さらに旅行者は、旅行先では利便性を優先し、セキュリティ意識が通常より甘くなりがちであることから、攻撃者にとっては格好の「獲物」となりやすい。先のTrustwaveのレポートによれば、調査対象のアメリカ人の70%以上が公共のWi-Fiへの接続や公共のUSBステーションでのデバイス充電、Wi-Fiへの自動接続を有効化することで自分自身の情報をさらす行為をしていた。なお、個人旅行に比べビジネス旅行の方が、リスクの高い行動をとる人が多い。

新たな取り組み-VR/ARを活用した観光コンテンツ

こうした中、セキュリティ要件を組み込まないガイドラインを基に「VR/AR等を活用した観光コンテンツ」が独り歩きしている現実もある。VR(Virtual Reality:仮想現実)が現実世界から得られる感覚情報を遮断して人工的に再現した感覚情報に置き換えるのと対照的に、AR(Augmented Reality:拡張現実)は現実空間を起点としデジタル情報を付加し、CGや動画を合成表示する。RPGを現実の空間と重ねるスマホゲームなどがARの代表である。ARに固有のセキュリティやプライバシーを考慮する必要があると主張する研究者もいる。

2019年にはサイバーセキュリティカンファレンスRECONにおいて、VRのハッキングが紹介された。観光に関するVRコンテンツは観光庁・文化庁がそれぞれ個別にガイドラインを公表しているが、どちらもセキュリティ要件を含んでいない。また経済産業省の補助事業として、特定非営利活動法人映像産業振興機構(VIPO)が「VR等のコンテンツ制作技術活用ガイドライン2018」を公表しているが、やはりセキュリティについては触れられていない状況だ。データセキュリティのみならず、個人情報(位置情報)保護、プライベート空間権利(公的空間の境界)等の課題もある。これらに関して今春以降、矢継ぎ早にガイドラインが発行されることが予想されるが、現在設計・開発中の案件については、ガイドラインが発行されてからセキュリティ要件を追加することになり、いびつな構造になってしまう。

まずは設計・開発の段階から「セキュリティ・バイ・デザイン」の思想を実践するとともに、ガイドラインに盛り込まれるであろう最低限のセキュリティ要件は予め組み込んでおくことが肝要だろう。どんな要件がガイドラインに組み込まれるか、あるいはガイドラインの最低基準以上の対策が必要なものは何かといった、専門家の知見が必要になる。これからインバウンド関連の事業を展開するのであれば、是非にも開発段階からのセキュリティ診断を実施することをお勧めする。

図 2 国際観光収支の推移(観光庁資料より当社作成)
出典:https://www.mlit.go.jp/common/001186621.pdf

ガイドライン一覧

その他の業種はこちら



Share

脆弱性診断の必要性とは?ツールなど調査手法と進め方

Share

脆弱性診断はアプリケーションやサーバ、ネットワークに、悪用できる脆弱性がないかを診断します。ライフサイクル別にどんな診断が必要か、ツール診断と手動診断、ペネトレーションテストとの違いなどを解説します。

企業が施すセキュリティ対策は広範かつ複雑になっています。外部からのサイバー攻撃や、内部での情報の持ち出しなど、セキュリティの脅威が多様化しているためです。企業が保護すべき情報、アプリケーション、機器の種類・数などが拡大していることも理由に挙げられます。

これに伴い、情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法がいくつも存在します。この記事では、その中の 「脆弱性診断」を取り上げて、その定義、特徴、メリット、実際の利用方法などを紹介します。

脆弱性診断とは

脆弱性診断とは、 既知の脆弱性を悪用できるか検証することです。Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど対象は多岐に渡ります。

アプリケーションの脆弱性診断には、既知の攻撃パターンを送付して対象システムやソフトウェアの挙動を確認する 「ブラックボックステスト」という方法があります。「ブラックボックステスト」では、実装時における脆弱性は検出できますが、そもそもプログラムの設計図であるソースコード中に存在する脆弱性を網羅的には検査することには適していません。

この場合、ソースコード開示のもと「ソースコード診断」する方法が有効です。「ソースコード診断」は「ブラックボックステスト」に対して 「ホワイトボックステスト」とも呼ばれます。また、「ソースコード診断」はさらに、プログラムを実行しないで行う 「静的解析」と、実行して行う 「動的解析」に分類できます。

それぞれの脆弱性診断は、目的・実施タイミング・検知できる脆弱性が同じではありません。重要なのは、システムライフサイクルの各フェーズで、適切な診断を実施し、洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することです。脆弱性診断は一度実施したらそれで終わり、というものではありません。

脆弱性診断が必要な理由

情報セキュリティ事故を未然に防ぐため        

攻撃者より先にシステムに隠れた脆弱性を検出して対策することで、攻撃や事故発生の確率を下げることができます。ひとたび個人情報やクレジットカード情報の漏えい事故が発生すれば、さまざまな対応・復旧費用や対策工数の発生は避けられません。ブランドの毀損や企業イメージの低下も招きます。

サービス利用者の安心のため

パソコンやインターネットを補助的に利用していた昔と異なり、現在はWebサービスやアプリケーションそのものが利益を生み出しています。生活や経済がネットワークなしに成り立たない現在、脆弱性診断などのセキュリティ対策は、事業を継続しサービス利用者の安心を守るため、欠かせないものとなっています。

脆弱性診断の種類

診断対象により、さまざまな脆弱性診断サービスがあります。まず、企業が開発したWebアプリケーションが挙げられます。問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。

次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査する プラットフォーム診断があります。

そのほか、近年増加の一途をたどる スマホアプリケーション IoT機器を対象とした脆弱性診断もあります。

(株式会社ブロードバンドセキュリティのサービス分類に基づく)

脆弱性診断とペネトレーションテストの違い

脆弱性診断とペネトレーションテストは、双方とも脆弱性などを検出する点では似ていますが、目的と方法が少し異なります。脆弱性診断は既知の脆弱性を網羅的に検出することを目的としています。

ペネトレーションテストは、「侵入テスト」の名前のとおり、疑似的なサイバー攻撃を仕掛けてセキュリティ対策の有効性を評価するために実施します。技術的アプローチだけでなく、対象となる組織の構成や、業務手順、ときには物理的な施設の特徴すら加味して、攻撃シナリオを作成する「レッドチーム演習」と呼ばれるテストを実施することもあります。

シナリオに沿ってペネトレーションテスターが攻撃を実行し、システムに侵入できるか、ターゲットとする資産(多くは知的財産)にたどり着くことができるかどうかなどをテストします。ペネトレーションテストは脆弱性診断と比べて、技術力はもちろん、より幅広い見識やセンスが求められます。

ツール診断と手動診断の特徴

ツール診断とは、脆弱性診断ツールと呼ばれるコンピュータプログラムを実行して、その応答から脆弱性を検知していくもので、自動診断とも呼ばれます。脆弱性診断ツールには、たとえばWebアプリケーション診断の場合に、検査コードと呼ばれる不正なHTTPリクエストを送信し 擬似攻撃するプログラムがあります。

これに対して手動診断は、技術者がプロキシツールを介してWebブラウザでサイトにアクセスした際に発生するリクエストを書き換える形で、脆弱性を確認する方法です。ツール診断と比べ検査項目も広く、また細かな検査ができるのが特徴です。

「ツール診断」による脆弱性診断

「ツール診断」では、セキュリティベンダーが、商用または自社開発した診断ツールを用いて脆弱性を見つけ出します。機械的に不正なHTTPリクエストを送り付ける疑似攻撃を行いますが、クラッカーによる攻撃とは異なり、あくまでも 脆弱性を見つけ出すことが目的であるため、システムを破壊することはありません。

ツール診断は機械的な検査であるため、過検知や誤検知なども含まれることが多く、その結果は担当者が補正することで正確な情報が得られます。比較的手軽に行えることから、開発段階で実施されることも多い診断です。また、定期的な簡易診断として用いることで、コストを低減しつつ最新の状態を保つことができるといった利用方法もあります。

「手動診断」による脆弱性診断

手動診断は、経験と専門性を持つ技術者によって実施され、機械的な判断では見落としてしまう 画面遷移・分岐にも対応できるメリットがあります。発見した脆弱性の再現手順や、最新動向を加味した対策方法などを提示してくれるのも、手動診断ならではの特徴と言えます。

ツール診断と手動診断は、どちらが優れていると比較するものではありません。それぞれの 特長を生かし、予算に合わせて組み合わせることで、コストパフォーマンスを発揮できるでしょう。

脆弱性診断の進め方

セキュリティベンダーに脆弱性診断を依頼する際は、まず 診断する範囲を決めます。組織にとって重要度が高い部分、すなわちサイバー攻撃を許してはいけないシステムやサーバ、Webアプリケーションを選定します。

診断が終了するとベンダーからレポートが提供され、報告会が行われることもあります。レポートに記載された脆弱性には深刻度などがスコア化されていることもあります。内容に応じて優先度をつけて、脆弱性をふさぐ必要があります。

脆弱性診断のまとめ

企業の情報システムが複雑かつ大規模になった現在、カード情報や個人情報・機密情報を狙う内外からの脅威に対して、企業もさまざまな予防手段を打っていく必要があります。情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法として「脆弱性診断」があります。

・脆弱性診断とは既知の脆弱性を悪用できるか検証すること
・検査対象はWebアプリケーション、スマホアプリケーション、サーバ、ネットワークなど多岐に渡る
・脆弱性診断を行う対象は組織にとっての重要度に基づいて選定する


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

診断結果にみる情報セキュリティの現状

Share

SQAT® Security Report 2020年春夏号

2019年下半期 診断結果分析

BBSecの診断について

当社では、Webアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT、パブリッククラウド、ソースコード、標的型攻撃に対するリスク可視化等、様々な局面における診断サービスを提供することで、お客様のニーズにお応えしている。

当社の脆弱性診断サービスは、専門技術者による高精度の手動診断と独自開発のツールによる効率的な自動診断とを組み合わせ、検出された脆弱性に対するリスク評価について、右表のとおりレベル付けしている。お客様のシステム特性に応じた脆弱性の検出、リスクレベルの評価、個別具体的な解決策の提供が適切に行えるよう、高い頻度で診断パターンを更新し、診断品質の維持と向上に努めている。

2019年下半期診断結果

当社では、2019年7月から12月までの6カ月間に、14業種延べ537企業・団体、4808システムに対してシステム脆弱性診断を行った。情報セキュリティ対策に重きを置く企業・組織側の姿勢もあり、診断案件数は年々増加している。脆弱性の検出率は次ページのとおりである。

診断の結果、Webアプリケーション診断では、脆弱性が検出されたシステムが全体の81.5%と、前年同期(2018年下半期)の84.9%に比べて微減しているものの、依然として高い割合である。ネットワーク診断においては、脆弱性検出率はシステム全体の47.8%であり、2017年下半期以降、減少傾向にあるが、およそ半数のシステムに何らかの脆弱性が検出されている。

検出された脆弱性のうち、早急な対処が必要な「高」レベル以上のリスクと評価された脆弱性は、Webアプリケーションでは26.9%、ネットワーク診断では30.4%検出されている。前年同期比(2018年下半期「高」レベル検出率:Webアプリケーション27.6%/ネットワーク診断 17.8%)でいうと、Webアプリケーションはほぼ横ばいだったが、ネットワークは12.6ポイント増えておりリスクレベルの高い脆弱性が増加傾向にある。当サイトでは、 「2019年下半期カテゴリ別脆弱性検出状況」とし、当社診断で検出された脆弱性を各性質に応じてカテゴライズし、評価・分析をした結果をまとめた。以降、診断カテゴリごとに検出数が多かったものの中から、特筆すべきことに焦点を当ててリスクや対策を述べる。

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

Webカテゴリ結果の31.4%を占める「システム情報・ポリシーに関する問題」のうち、最も検出数が多かったのは、「脆弱なバージョンのOS・アプリケーションの使用」である。脆弱なバージョンのOS、アプリケーションを使用している場合、既知の脆弱性の影響を受ける可能性がある。最新バージョンへのアップデートが望ましいが、システム環境における制約等の理由でバージョンアップができないのであれば、必要なセキュリティパッチがすべて適用されていることを確認すべきである。

次にWebカテゴリ結果の検出割合が多かったのは、19.7%を占める「セッション管理に関する問題」。最も検出されたのは、「不適切なセッションタイムアウト」であった。ログインセッションのタイムアウト値が適切に設定されていないと、長時間操作を行わずアイドル状態のままでもセッションが維持されることから、セッションハイジャック等の攻撃が成功する確率が高まるほか、サービス運用妨害(DoS)攻撃につながる可能性もある。セッションタイムアウトは、Webアプリケーションのデフォルト設定として一般的に採用されている30分が望ましいが、ユーザビリティを考慮してタイムアウト値を長くする場合は、追加のリスク緩和策を講じることが推奨される。

ネットワーク診断結果

NWカテゴリ結果の52.3%が「通信の安全性に関する問題」であった。なかでも、「推奨されない暗号化方式の受け入れ」(検出割合は右表を参照)の検出数がトップであり、第2位の「推奨されないSSL/TLS通信方式の使用」と比べて2倍以上の差がある。

サーバがブロック長64ビットのブロック暗号をサポートしている場合、誕生日攻撃(birthday attack)を介して長い期間暗号化されたセッションを復号・解読される「SWEET32」と呼ばれる攻撃の影響を受ける可能性がある。「NVD(National Vulnerability Database)」などに本脆弱性の影響を受ける製品は公表されており、ベンダからも正式な対策が公開されていて、ベンダ情報を参照のうえ対策することが望ましい。

SSL/TLS通信において、強度の低い暗号化方式(RC4、3DESなど)が許容されていると、既知の脆弱性を悪用した攻撃(平文回復攻撃など)により、攻撃者に暗号化されたデータが解読される危険性がある。また、強度が低いハッシュアルゴリズム(SHA-1など)が許容されていると、衝突攻撃に弱くなり証明書の偽造等が可能となる恐れがある。鍵長が128ビット未満の暗号方式については、総当り(Brute-Force)攻撃への耐性が低く、中間者(Man-in-the-Middle)攻撃などの標的になりうる。強度の低い暗号化方式やハッシュアルゴリズムは使用を停止し、SSL/TLSによる通信の保護には鍵長が128ビット以上の暗号化方式を実装するべきである。SSHプロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。

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


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

Webアプリケーションに求められる「二極のスコープ」による診断

Share

SQAT® 情報セキュリティ瓦版 2020年1月号

Webアプリケーションの脆弱性は時として深刻な被害にもつながる、看過できない脅威です。「攻撃者の視点」でセキュリティホールを特定する脆弱性診断に加え、「開発者の視点」から問題を特定するソースコード診断も重要です。前者はアプリケーションの「外」から脆弱性を検出するのに対し、後者はアプリケーションの「内」から問題部位をピンポイントで検出します。両者を連携させることが、Webアプリケーションのセキュリティを効果的に高めるカギになります。


脆弱性はどこから生まれるか

そもそも、Webアプリケーションでセキュリティの脅威となる脆弱性が生まれるのは、「プログラムの処理において、開発者が意図していない動作が行われないようにする」という点で適切な制御ができていないことに原因があります。

Webアプリケーション開発において広く利用されているPHPで検出された脆弱性の例を挙げましょう。2019年10月、nginxとPHP-FPMを組み合わせた一部の環境で、PHPプログラムの内部処理の不具合により不正なリモートコードが実行され得る脆弱性(CVE-2019-11043)が発見されました。この脆弱性は、具体的には、「使用される値(URL)に対して、入力値としての妥当性が確認されないことを想定しておらず、適切に制御されない」という不備に起因するもので、サポートが終了しているバージョンおよび対策済みバージョン未満のすべての現行版が影響を受けました。

PHPは、WordPressをはじめとする多くのWebアプリケーションで利用されており、当該脆弱性の影響は、PHPベースのアプリケーションを開発する多くの組織に及んでいます。警察庁の最近の調査によれば、同庁のインターネット定点観測においても、当該脆弱性を狙った攻撃を目的とする探索行為が観測されています。

Webアプリケーションを開発する組織は、こうした脆弱性の影響により、さまざまな対応に追われることになります。開発言語の脆弱性に加えて、アプリケーションのプログラミングで発生する脆弱性も、発覚がライフサイクルの後工程になればなるほど、対応のための負荷が増大します。なお、後者の脆弱性については、開発サイクルの可能な限り手前の工程で問題を特定・解消できていれば、修正にかかるコスト、影響範囲ははるかに小さく済みます。その意味で、Webアプリケーションのソースコードを点検することには、大きな意義があります。

 

Webアプリケーションの構造

プログラムは、「入力」→「ロジック」→「出力」の3つの処理で構成されています。脆弱性を作り込まないためには、これらすべての処理を制御し、意図しない動作が起きないようにすることが重要であり、「入力」「ロジック」「出力」の各処理が適切に制御しているかを、「内部」すなわちソースコード診断により検証し、あわせて、「外部」から確認できる挙動(リクエスト・レスポンス)を検証することで、問題の検出精度を高めることができます。

なお、こうした二極からの検証は、「ホワイトボックステスト」、「ブラックボックステスト」とも呼ばれます。前述したように、車の検査に例えるとわかりやすいかもしれません。両者にはそれぞれ異なる役割があり、両者を組み合わせることで、より信頼度の高い検査をすることが可能になります。

 

脆弱性に関する業界ガイドライン

業界標準のガイドラインもWebアプリケーションの脆弱性を評価する際に役立ちます。代表的なものとして、本稿では「OWASP Top 10」と「CWE Top 25」をご紹介します。

OWASP Top 10は、Webアプリケーションの脆弱性を、「悪用のしやすさ」、「蔓延度」、「検出しやすさ」、「技術面への影響」、「ビジネスへの影響」といった観点からランク付けし、最も重大なWebアプリケーションセキュリティリスク(「Most Critical Web Application Security Risks」)Top 10を選出しています。一方、CWE Top 25は、ソフトウェア開発で起こり得るプログラミングエラーを体系的に分類した項目リストであるCWE(共通脆弱性タイプ一覧)をベースにしたものです。リストの各項目に対し、米国の脆弱性情報データベースNVDの評価を加味して危険度のスコアを算出し、最も危険性が高いと評価されるソフトウェアエラー(「Most Dangerous Software Errors」)Top 25を選出しています。

Webアプリケーションの観点でいうならばOWASP Top 10が「ブラックボックステスト」であり、CWE Top 25は「ホワイトボックステスト」と考えることができます。

 

 

攻撃活動を先んじて制する

Webアプリケーションの脆弱性は、攻撃者にとって魅力的な標的です。悪用可能な脆弱性を常に探している彼らは、Webアプリケーションの構造設計やロジックを想定して仮説を立て、解析・検証し、特定の状況・環境・条件下において発現する不具合を見つけ出そうとします。お気づきでしょうか?実は、こうした攻撃者の行動パターンの裏をかくこと、攻撃者の行動に先んじてそれを阻むような手を打つことが、セキュリティ対策になり得るのです。いち早く脆弱性を見つけ、問題を解消することが重要です。この意味でも、リリース前に問題の検出に取り組むことは重要です。ソースコードレビューや単体試験などの段階でのソースコード診断は、効果的なタイミングの一例となります。

 

上流での対処を促進

脆弱性になるべく上流工程で対処する取り組みを促進することも重要です。たとえば、近年注目を集めているアプローチで、「シフトレフト」というものがあります。これは、ソフトウェア開発で生じる各種課題への対処をできるだけライフサイクルの早期の段階へとシフトさせていこうという考え方で、手戻りを防ぎ、品質を落とすことなく時間やリソースを効果的に節減することを目指すものです。セキュリティ対策においては、プログラムが想定しない動作をしないことを検証するための工程を前倒しすることで、セキュリティ強化・コスト削減・生産性向上といった面からも着実な成果が期待できます。開発ライフサイクルに明示的にセキュリティを組み込む、「DevSecOps」を推進するのも一案です。

リリースの直前でプログラムの問題が発覚した場合、状況によっては設計を根本から見直す必要が生じるかもしれません。リリース後の診断で重大な脆弱性が明らかになった場合は、サービス停止という事態もありえます。問題の修正にかかるコストや時間は、発覚が後になるほど膨らみ、致命的なビジネス損失を招く恐れがあります。早期の段階で不具合検出のためのリソースを投入することは、結果として最良の費用対効果を得られることにつながります。

 

 

「二極のスコープからの診断」がカギ

開発工程において常に生み出される可能性がある―これが、Webアプリケーション脆弱性に見られる1つの特徴です。リスクを最小化するカギは、できるだけ上流で脆弱性の芽を摘む体制を構築し、かつ、「内と外」の二極から脆弱性評価を行うことです。複眼的な軸を持つことは、評価の客観性を向上させ、対策時の優先度の判断や、サービスの継続・改修といった経営的意思決定におけるスピードと精度を高めることにもつながります。自組織の脆弱性診断では何を見ているのか?―こう自問してみて心もとなく感じた方は、ぜひ、この二極がカバーできているかを、改めて確認してみてください。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share