ECサイトに必要なセキュリティ（前編）～サイト設計時に考えるセキュリティ対策

インターネットが普及し、ネットショッピングが日常的なものとなった今、私たちの買い物のスタイルは大きく変化しました。実店舗での買い物よりも、インターネットでの買い物の方が多いという方も増えたのではないでしょうか。ユーザーにとって買い物の利便性は格段に向上した一方、ECサイトやクレジットカード情報を狙ったサイバー攻撃は増加しています。

経済産業省はガイドラインにおいて、すべてのECサイトに対するセキュリティ診断（脆弱性診断）の義務化を検討しており、セキュリティ対策の強化を推奨しています。多くのECサイト事業者もこの流れを受けて、改めてセキュリティ対策の見直しを迫られています。

本記事では、ECを運営する事業者の皆様に向けて、これからの時代に欠かせない「ECサイトに必要なセキュリティ対策」をテーマに、前後編に分けて連載します。

前編である今回は「ECサイトの設計時に考えるセキュリティ」と題して、ECサイトの開発段階からセキュリティ対策を考えておくべき理由と、対策するべきポイントについて解説します。後編は「対策必須の脆弱性診断ってなに？」と題して、すべてのECサイト事業者に対して、実施の義務化が予定されている「セキュリティ診断（脆弱性診断）」についてご紹介します。

狙われるECサイト

日本クレジット協会の調査^※によると、クレジットカードの不正利用被害は年々増加しており、2023年の不正利用被害額は540.9億円に上ります。同調査で2014年の不正利用被害額は114.5億円となり、クレジットカード情報を悪用した被害が約10年で5倍近く増加していることになります。クレジットカード情報を取り扱う事業者は、適切なセキュリティ対策を講じることが不可欠です。

※ 日本クレジット協会｜四半期調査：クレジットカード不正利用被害額調査（2024年9月版）

また、日本ネットワークセキュリティ協会（JNSA）の調査では、Webサイトからの情報漏えい被害にあった組織の平均被害金額は非常に高額であることが明らかになっています。個人情報のみが流出した場合の平均被害額は2,955万円、クレジットカード情報を含む情報漏えいの場合3,843万円となっており、いずれも高額です。

これらのデータが示すように、ECサイトの事業者の皆様が取り扱う個人情報・クレジットカード情報は悪用されるリスクが高く、情報が漏えいした際の被害も甚大です。万が一情報漏えいが起こってしまうと、企業の信用を大きく損なうだけでなく、顧客からの信頼喪失や賠償責任、さらには法的責任を追及されることもあります。

ビジネスの継続性を守り、顧客に安心して利用してもらうためにも、ECサイトにおけるセキュリティ対策は「コスト」ではなく「必要不可欠な投資」と言えるでしょう。

セキュリティ対策は開発・設計段階から

ECサイトのセキュリティ対策は、単にリリース前のセキュリティ診断を実施すれば済むものではありません。ECサイトの設計段階からセキュリティを考慮することが、後々のリスクやコストを大きく左右します。開発プロセスの初期からセキュリティ要件を組み込み、上流工程で適切な対策を講じることで、セキュリティ診断後の脆弱性対応にかかる修正工数やコストを削減できます。また、手戻りを減らすことで品質低下と遅延を防ぎ、プロジェクトをスムーズに進行できます。

セキュリティ知識をもつメンバーがおらず、開発工程でセキュリティを意識することが難しい場合は、セキュリティコンサルタントによる支援サービスを用意していますので、ぜひご検討ください。

EC事業者に求められるセキュリティ要件

ECサイトの設計時に考慮すべきセキュリティ対策を、「アプリケーション」「インフラ」「サービス」の観点から分類し、それぞれの詳細について解説します。

アプリケーションレベルのセキュリティ対策

ECサイトにおけるアプリケーションのセキュリティは、ユーザーからの入力や、システムの動作に対する不正な操作を防ぐことが中心です。攻撃を防ぐための代表的な対策は以下の通りです。

1. サニタイジングと入力値チェック

不正な操作を防ぐためには、ほとんどの機能でサニタイジングと入力値チェックが必要です。まずはサニタイジングの具体例として、SQLインジェクション対策のプリペアードステートメントとXSS（クロスサイトスクリプティング）対策のエスケープ処理を紹介します。

• SQLインジェクション対策
  ECサイトには、会員情報や注文情報などのユーザー入力をデータベースに登録する機能が必要です。適切な対策を講じずにユーザー入力をそのままSQL文に組み込むと、攻撃者により不正なSQL文を挿入され、データの改ざんや漏えいを引き起こすSQLインジェクション攻撃のリスクが生じます。SQLインジェクション攻撃を防ぐために有効なのが、「プリペアードステートメント」機能です。プリペアードステートメントを使用すると、SQL文の構造とデータ部分を分離し、ユーザーの入力を安全な形で処理できます。
• XSS対策
  ECサイトでは、お問い合わせフォームや注文ページなど、ユーザーが入力した文字列を画面に表示する機能を実装することがよくあります。しかし、ユーザーの入力した文字列がそのままブラウザに描画されるようになっていると、攻撃者が悪意のあるJavaScriptを埋め込み、閲覧したユーザーのブラウザ上で不正なスクリプトを実行させる「XSS（クロスサイトスクリプティング）攻撃」が発生するリスクがあります。XSS攻撃を受けると、ログインに必要な情報を盗み取られたり、ユーザーに気づかれないまま勝手に注文を確定されたりと、深刻な被害が発生する可能性があります。
  XSS攻撃を防ぐためには、「エスケープ処理」が必要です。エスケープ処理とは、HTML内で特別な意味を持つ文字（<,>,&," など）を無害化し、ブラウザ上で正しく表示されるようにする技術です。多くのプログラミング言語やフレームワークには、適切なエスケープ処理を行う機能が備わっていますが、どのHTML要素にユーザー入力を埋め込むかによって適用すべきエスケープ処理の種類が異なります。
• サニタイジングの全般的な考え方
  プリペアードステートメントやエスケープ処理のように、ユーザーの入力に悪意のある文字列が含まれていた場合でも無害化する処理を「サニタイジング」と呼びます。これは、入力データが直接システムに悪影響を与えないようにする重要な対策の1つです。今回は紹介しませんでしたが、HTTPヘッダインジェクションやメールヘッダインジェクションなど、ユーザーの入力をそのまま使ってしまうことが原因の脆弱性は他にもあります。こうしたリスクを避けるためには、できる限りプログラミング言語やフレームワークの標準機能を用いてユーザーの入力を無害化することと、文字列結合やテンプレート文字列でユーザーの入力を挿入する処理を実装した時は、悪意ある入力によってインジェクション系の攻撃が可能になっていないかを考える必要があります。
• 入力値チェックの重要性と具体例
  ユーザー入力の文字種や長さを制限する入力値チェックは、サニタイジング処理が適切に行われていない場合でも、攻撃を未然に防ぐ効果的な手段となります。例えば、電話番号の入力フォームでは、数字とハイフン以外を入力する必要はないので、数字とハイフン以外の文字が入力された場合には入力を受け付けず再入力を促すことで、改行や特殊記号を入力に含めた攻撃を防げます。
• サーバ側での入力値チェック
  入力値チェックの実装において重要なことは、サーバ側でのチェックを必ず行うことです。ユーザーが送信するデータは、セレクトボックスやチェックボックス、ラジオボタン、パラメータやCookieといったさまざまな方法で送られるため、どの方法であってもすべての入力値を徹底的にチェックする必要があります。特に、ブラウザ側での入力値チェックは、ユーザーによる不正操作を防ぐための初歩的な対策に過ぎません。高度な技術を持った攻撃者は、ブラウザ側でのチェックを簡単に回避できます。ブラウザ側の入力値チェック処理が実装されていても、不正な入力を防ぐ目的のサーバ側の入力値チェック処理を省略してはいけません。
• 特殊な入力方法と業務要件に基づくチェック
  セレクトボックスやチェックボックス、ラジオボタンなどのように入力できる値が制限されている入力方法でも、高度な操作を行えば任意の文字列を送信できます。そのため、あらゆる入力値に対して入力値チェックが必要です。ECサイトでは、ユーザーの操作結果を記録するカート機能などが存在しますが、これらの値をそのまま処理するのではなく、業務要件に基づいてしっかりとチェックすることが重要です。例えば、カートに入れられた商品が購入上限数を超えていないか、選択できないはずの支払方法が選択されていないかなどを検証することで、意図しない不正注文を未然に防げます。
• 入力値チェックとサニタイジングの併用
  入力値チェックは業務要件に基づく制限事項を設けるために行われますが、すべての脆弱性を防ぐことはできません。例えば、XSS攻撃やSQLインジェクション攻撃に用いられる記号「<」や「'」などは、メールアドレスに使うことが許可されています。メールアドレスの入力値チェックでこれらの記号の使用を禁止してしまうと、ユーザーの入力体験を損なうため禁止するわけにはいきません。このような場合、ユーザーの入力を受け取る時には入力値チェック、ユーザーの入力を使う時にはサニタイジング、という2重の対策を実施する必要があります。

2. CSRF対策

CSRF（クロスサイトリクエストフォージェリ）攻撃は、罠サイトにHTTPリクエストを送信するプログラムを設置し、だまされて罠リンクをクリックしたユーザーのブラウザに意図しない操作を強制的に行わせる攻撃です。例えば、CSRF攻撃が可能なECサイトでは、なりすまし注文によって商品を攻撃者が指定した住所に配送させるといったことが可能になってしまいます。

これを防ぐため、CSRFトークンを用いる対策が効果的です。CSRFトークンは正規の入力フォームからのリクエストであることを確認するための一意の識別子で、セッション内でのみ有効です。CSRFトークンが第三者に推測されないようにするため、フレームワークの標準機能を使用することが推奨されます。

3. ログイン機能の強化

ログイン機能を強化するために、下記3つの方法が挙げられます。

アカウントロック	ログイン失敗が一定回数を超えた場合に、一定時間アカウントにログインできないようにすることで、有効なメールアドレスとパスワードの組み合わせを機械的に探すブルートフォース攻撃を防ぎます。
ワンタイムパスワード	ログイン時に一度限りのパスワードを要求することで、メールアドレスやスマートフォンなど正規の利用者のみがアクセスできることを確認します。他サービスの情報漏えいなどでメールアドレスとパスワードが漏えいしていても、不正ログインを防ぐことができます。
エラーメッセージの注意	ログイン時にログインIDとパスワードを個別にチェックし、エラーメッセージで「ログインIDが間違っています」や「パスワードが間違っています」というメッセージを表示すると、存在するログインIDやパスワードの情報が攻撃者に漏えいしてしまいます。ログイン時の検証はログインIDとパスワードの組み合わせで行い、誤りがあった場合には「ログインIDまたはパスワードが間違っています」と表示することで、攻撃者に情報を渡さないようにする必要があります。

インフラレベルのセキュリティ対策

インフラ面でのセキュリティ対策は、システム全体を保護し、外部からの攻撃を防ぐことが主な目的です。アクセス制御やネットワーク層での防御が該当します。これらの対策は、アーキテクチャ設計時点で導入方法を考慮する必要があります。

1. WAFとIP制限

WAF（Web Application Firewall）は、Webアプリケーションに対する攻撃を検知し、防御する役割を担います。例えば、アプリケーションレベルのセキュリティ対策と合わせて多重の防御を構成できます。攻撃が確認されたIPアドレスからのアクセスを遮断したり、内部からのアクセスのみが想定されるサーバにアクセスできるIPアドレスを制限したりすることで攻撃を阻害します。

2. HTTPSとCORS

会員情報やクレジットカード情報の盗難、サイトの改ざんを防ぐため、ECサイトを提供する通信をHTTPSプロトコルで保護します。また、認証サービスや決済代行サービスを利用してECサイトを構築する場合、異なるドメイン間でのデータ共有が発生するため、適切なCORS（Cross Origin Resource Sharing）の設定が必要になることがあります。HTTPSとCORSの設計はドメインと密接に関わるため、ドメイン割り当ての設計時にHTTPSとCORSについても考慮しておくことが重要です。

3. ログの取り扱い

ログには、システムの動作状況やユーザーのアクセス情報が記録されるため、個人情報やクレジットカード情報をログに残さないことが大前提です。また、ログの保持期間を最小限に設定し、不要なデータを残さないことで被害リスクを低減できます。加えて、アクセス制御や暗号化を施すことで、情報漏えいが起こってしまった場合の被害を軽減することが求められます。

4. 本番データのアクセス制御

データのアクセス権限は最小限に設定し、特に本番環境のデータには一般の開発者がアクセスできないよう制限することで、開発者のアカウント漏えいやヒューマンエラーによる情報漏えいのリスクを大幅に低減できます。ログ以外のデータについても保持期間を最小限に抑え、情報漏えいが発生した場合の被害を最小限にすることが重要です。

5. DoS攻撃対策

DoS（サービス拒否）攻撃は、自動プログラムによってサーバに過剰な負荷をかけ、サービスをダウンさせる脅威です。その対策として、タイムアウト設定とIP制限が有効です。特に、応答に時間がかかる入力パターンが存在するとDoS攻撃に利用されてしまうため、応答時間が一定を超えるリクエストは切断し、リソースの過剰消費を防ぐことが重要です。また、IP制限を活用して特定の攻撃元からのアクセスをブロックし、悪意のあるリクエストがサーバに溜まらないようにすることも有効です。

不正注文検知システムの導入

ECサイトで行われる不正注文は大きく3つに分けられます。

• 第三者による、なりすまし注文
• 内容を改ざんされた注文
• サービス品質が下がる注文

このような不正注文を成立させてしまうと、発覚した際に注文自体をキャンセルする必要があります。この場合、その時点までに発生した決済手数料や物流コストなどはECサイト運用者の負担となり、利益を圧迫します。また、頻繁な不正注文は他のユーザーの信頼を失う原因にもつながり、将来の売り上げにも影響が出てしまいます。そのため、不正注文を早期に検知するセキュリティ対策が必要になります。

1. 第三者によるなりすまし注文への対策

第三者によるなりすまし注文への対策として、3Dセキュアの導入や不正検知サービスの導入が効果的です。

3Dセキュアとは、第三者によるクレジットカードの不正利用を防止するために、決済時に追加の本人認証を行う仕組みです。具体的にはカード発行会社から送信されるワンタイムパスワードをSMSやメールで受け取り、入力することで本人確認を行います。たとえカード情報が盗まれたとしても、3Dセキュアによる本人認証を突破することは困難です。

また、不正検知サービスを導入することによって、注文者のカード情報、配送先、商品、金額などの注文情報からリスクを総合的に判断し、疑わしい取引をブロックします。不審な取引パターンをリアルタイムで検知し、不正注文による損害や顧客トラブルを未然に防ぐことが可能です。

2. 内容の改ざんされた注文への対策

ECサイトでは、複数のタブを使った操作によって意図しない注文が成立してしまうリスクがあります。例えば、1つ目のタブでカートに入れた商品を注文確定の前段階まで操作し、2つ目のタブでカート内に商品を追加した場合、一部のECプラットフォームでは追加された商品計算に反映されず、不正確な金額で注文が完了してしまうことがあります。

これを防ぐには、セッションを適切に管理し、注文開始時点のカートの状態と注文確定前のカートの状態を比較する仕組みが必要です。また、カート内の不正な変更（商品数や価格の改ざんなど）をリアルタイムで検出できるシステムを導入することも有効です。

3. サービス品質を下げるための注文への対策

サービス品質が下がる注文として、転売を目的とした大量注文があります。一度の注文で購入できる商品数を制御することも効果的ですが、同一アカウントや複数アカウントによる複数回の注文についても対策することが重要です。例えば、注文情報やIPアドレスなどをもとに不正注文である可能性を算出し、ECサイト運用者に通知を行うサービスの導入を検討する必要があります。

おわりに

ECサイトで押さえたいセキュリティ要件は多岐にわたり、1つの対策だけでは十分とは言えません。設計段階から「アプリケーション」「インフラ」「サービス」の観点でリスクを洗い出し、各機能に応じた適切な対応を行うことが不可欠です。サニタイジングやCSRF対策、ログイン機能の強化などの対策を講じることで、不正アクセスや情報漏えいのリスクを大幅に軽減できます。

こうした対策が正しく実装されているかをチェックするために、経済産業省が示すガイドライン内で義務化が予定されているセキュリティ診断（脆弱性診断）の実施をおすすめします。この詳細については、後編で紹介します。

ラックでは、ECサイトのセキュリティ対策に悩むお客様の課題に合わせて、適切で柔軟な伴走型の支援を提案いたします。ECサイトのソリューションについてお悩みがございましたら、ぜひお気軽にお問い合わせください。

ECサイト事業者向け セキュリティ対策 ホワイトペーパーを公開中

本連載の前編・後編の内容に、検出されやすい脆弱性情報を追加してまとめたホワイトペーパーを公開中です。ホワイトペーパーは資料ダウンロードサイトより入手いただけます。