気の向くままに辿るIT/ICT/IoT
ショップ構築

サイバー攻撃と対策

ホーム前へ次へ
サイバー攻撃の対策はどうしたらいい?

サイバー攻撃と対策

ネットショップにおけるセキュリティ対策

 不特定多数の方に開放したホームページ上で販売を行うネットショップ・オンラインショップにおける電子商取引では、ユーザーの入力情報を保護する事が必須であり、更に外部からの攻撃に備え十二分な対策を講じる必要があります。

<< cookie保護のタイミングと対策

アクセスが集中した時の対処

 これは設置するショッピングカートに限ったことではないですが、仮にアクセスが集中した時の対処を予め行っておく事ができれば自サイトにおけるDoS[Denial Of Service]攻撃(サービスを不能にする為にアクセスを集中させる攻撃)対策になります。

 もっともDoS攻撃はウェブサーバ自体へのダメージを与える事が目的であり、更に様々な種類のDoS攻撃があるので、この対策で防御できるのはほんの一部です。

セッションIDが搾取されるケース

 セッションが悪用されるケースとしてはセッションハイジャックとセッションフィクセーションがあります。

セッションハイジャック

 セッションハイジャックの場合「そのままのセッションを利用してその本人になりすます行為」と「発行されたセッションからセッションの構造を予測してあり得るセッションを作り上げ、あたかもシステムから発行されたセッションを装う」という事が想定されます。

 後者の場合には対策を講じる事ができるものとできないものがあり、システムで発行したセッションIDをテーブルに格納しておき、且つ、一定時間経過した場合、保持された状態となっているセッションIDを削除するという仕組みがあれば、現在、存在するセッションかどうかの判定ができますから、存在しないセッションに関しては防御できますが、たまたま、存在するセッションであった場合には対処できません。

 前者の場合には一応の対策を講じる事はできますが、さもすると善意のアクセス者を排除してしまう可能性があります。

 それは万一、同一セッションがあった場合に先に以降の操作をした方を正常処理し、後からの操作を排除するという対策を取るとこの可能性を残します。

 仮に、このチェックがない場合には、まるでユーザーを特定できない場合と同じように善意の方の選択商品・サービスや各種入力情報も期待通りとはならないでしょうし、セッションが同一なので善意のアクセス者の入力した個人情報を修正画面や確認画面で確認できてしまう可能性もあります。

セッションフィクセーション

 更に、悪意あるアクセス者が普通にカートを利用してセッションを取得した後、セキュリティが甘いPCを乗っ取った善意のアクセス者にそのセッションを保持させ、悪意あるアクセス者がリモート操作するという攻撃があります。

 悪意あるアクセス者がリモート操作している場合にシステムを破壊しようとする行為に関しては、入力チェックやサニタイジングをしっかり行う事で防御する事が可能です。

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

 クロスサイトスクリプティング攻撃(入力チェック・サニタイジングなしで入力をそのまま表示する等ウェブを動的に生成する場合に悪意あるスクリプトをユーザーのブラウザに送信、結果としてブラウザに環境変数などの一覧を表示したり、その過程でcookieを搾取したりする攻撃)対策としては、十分な入力チェックと入力値としての[ . ]や[ / ]をsed([s/.//g;]...etc.)等によってサニタイジング(無害化)しておく事である程度低減される事が期待されます。

SQLインジェクション攻撃

 セッションハイジャックとセッションフィクセーションいずれの場合も、SQLインジェクション攻撃(システムで利用しているSQL文に入力値としてandやor条件を渡し、実質無条件状態を作り出す攻撃)の可能性がありますが、これも入力チェックとサニタイジングをしっかり行っておけば防御する事ができます。

 しかし、セッションハイジャックにしてもセッションフィクセーションにしても、悪意あるアクセス者が普通にショッピングし、PCを乗っ取られた善意のアクセス者に商品・サービスが届くような場合、存在しない住所や連絡先を入力される場合といった場合の低次元な嫌がらせにはシステム側としては対策を講じる術がありません。

 ただ、こうした行為は呆れるほど低次元・低レベルであり、セッションハイジャックやセッションフィクセーションを行う技術を持つ一方で、こんな低レベルな事をするケースはほとんどないでしょうし、あるとすれば逆恨みを含めた相当の恨みを買っているなど限定的なケースでしょうから普通に真摯な姿勢で運営している場合にはそれほど気にする事ではないかもしれません。

入力値における[ / ]や16進コードも要注意

 ウェブサーバ自体の脆弱性を突くウイルスやスパイウェア、クロスサイトスクリプティング攻撃、SQLインジェクション攻撃は、[ / ]や16進コードを利用する事によって入力チェックやサニタイジング、IDS[Intrusion Detection System:侵入検知システム]をすり抜けられてしまう、迂回されてしまうといった事も想定されますのでスクリプトにおいて排除しなくてはならない16進コードも十二分に入力チェックとサニタイジングを行っておく必要があります。

OSコマンドインジェクション攻撃

 OSインジェクション攻撃(OSのコマンド操作を行う権限を奪取し、悪意のあるコマンドを仕込む攻撃)は、admin権限がはく奪されサーバをリモート操作する事により行われるので、ウェブサーバ自体のセキュリティを万全にし、OSのセキュリティアップデートがある場合には適用する(レンタルサーバの場合にはセキュリティのしっかりしたところを選ぶ)と同時にウェブサーバ利用者は、開発・自作したCGI、入手したCGIなどにおいて入力チェックとサニタイジングをしっかり行っておけばかなり低減させる事ができます。

ディレクトリトラバーサル攻撃

 ディレクトリトラバーサル攻撃(入力値にファイルパス・URLパスにおける相対パス[/][./][../]などを入れてサーバサイド・クライアントサイドにおいて想定しないファイルを指定してパイプ[ | ]コマンド等を仕込む攻撃)対策としては、十分な入力チェックと入力値としての[ . ]や[ / ]をsed([s/.//g;]...etc.)等によってサニタイジング(無害化)しておく、[.httpd.conf]や[.htaccess]で正規表現を利用してサイト上でアクセスできる(アクセスできない)拡張子やファイル名を指定しておく、ファイル名をディレクトリ名に利用しない、想定しやすいようなディレクトリ構成やファイル名称付けをしない等ディレクトリやファイルの名称に工夫を凝らす事である程度低減される事が期待されます。

 悪意ある攻撃者は、そのファイルが存在するしないに関わらず自動的に想定ファイル名を生成し、アクセスしてくるので、これが短時間に集中して行われるとDoS攻撃ともなりえます。

いずれの攻撃も個人情報が搾取される危険性

 これらの攻撃はいずれも直接的、間接的に個人情報を搾取される危険性があるので、大まかに言うと「第三者に開放するスクリプトを含むシステム」においては前述のようなこれらの対策は最低限実施する必要があります。

公開されるべきではない後悔するウェブサイト

 最低限のこれらの対策さえ実質行う事ができないウェブサイトは公開されるべきではありません。

 人的な情報搾取ではなく、ネットワーク上で情報が流出するケースにおいて、これらの対策が施されていないものも散見されます。

 実質対策が欠落しているシステムは、他人や他者の作ったプログラムやスクリプトに依存し、入手したスクリプトにおいてセキュリティ対策を全く考慮しない、BtoBのシステム提供であっても開発サイクルにおける管理がズサン、結果的に納期におされ実質手抜きとなるケースも含め一般に公開されるべきではありませんし、プログラムやスクリプトの知識なく、ネットショップを開設したい一心で付け焼刃の知識で正常系の操作ができるからOKといった程度のウェブサイトは論外です。

 最低限のこれらの対策さえ実質行う事ができない状況にあるにも関わらず公開されるウェブサイトは、個人運営にしても、企業が運営するにしても最終的に顧客に被害が及ぶ事になり、顧客軽視の姿勢である事は否めません。

>> cookieまたは他のユーザー特定方法を完全保護できればよいのだが・・・

ショッピングカートCGIに求められる最低限の品質

 ショッピングカートに必要な品質確保する為の大前提の対策。

ショッピングカートCGIとその他のセキュリティ確保

 セキュリティを考える上でショッピングカートCGIの対策を講じただけでは不足です。

 ショッピングカートCGIで利用する複数のファイルと公開するウェブサーバ上のセキュリティ設定とディレクトリ保護、ウェブサーバへのアップロード、ターミナルエミュレータ利用におけるセキュアな接続なども必要です。

 また、ログインID、パスワードはセキュアなウェブサーバ、セキュアなFTPソフト、セキュアなターミナルエミュレータにおいても徹底管理が必須です。

cookieのセキュリティ設定

 ネット上でショッピング機能を利用する場合、「一連の操作をしているユーザー」を特定する為にはcookie/クッキーの設定が不可欠です。

セキュリティの必要性と限界

 ここまでのセキュリティは最低限必要であり、cookieの実装によりショッピングカートを一応組み込む事はできますが、残念ながら完全にセキュリティが確保されるわけではありません。

 また、ある条件下における善意のアクセスの拒否か、またはセキュリティ強度の緩和の二者択一を迫られるケースもあります。

ホーム前へ次へ