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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

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

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

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

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

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

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

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

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

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

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

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

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

独立行政法人 情報処理推進機構(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サイトを目指しましょう。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

この記事では、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インジェクションですが、リスクはゼロではありません。定期的な脆弱性診断は有効性の高い対策と考えてよいでしょう。


Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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


Security Serviceへのリンクバナー画像

BBsecコーポレートサイトへのリンクバナー画像

セキュリティ緊急対応のバナー画像

セキュリティトピックス動画申し込みページリンクへのバナー画像

診断結果にみる情報セキュリティの現状
~2019年下半期 診断結果分析~

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

SQAT® Security Report 2020年春夏号

BBSecの診断について

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

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

2019年下半期診断結果

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

脆弱性診断脆弱性検出率2019年下半期

診断の結果、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プロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。


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

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像