SSL対応は必須

ネットショップは必ずSSLに対応しないとダメ？

SSL対応は必須

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

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

<< CGIのハイパーリンク・URL直接入力での呼び出しを禁止する

注意が必要なショッピングカートCGIプログラム4

　SSLに対応していないショッピングカートCGIプログラムは利用しない事です。

　SSLに対応するか否かは、当然、大前提としてウェブサーバに依存する事ですが、ショッピングカートCGIにも関係します。

　いずれも後述しますが、SSLの安全性を活かす為の1つとしてセキュアなcookieの設定をショッピングカートCGIが行う必要があるからです。

重要な入力データを保護するSSL

　ユーザーが入力した個人情報を保護する為には、通信を暗号化して流れるデータを保護するSSLが必要です。

　因みに後述しますが、「SSLを利用せず、Perlなどで実装可能なcryptを利用する」事はセキュリティを確保した事にはなりません。

SSLを使わなくてもPerlならcryptっていう暗号化が・・・では不完全

　crypt(UNIX・DES暗号化の仕組みを利用)などを利用してプログラム上で暗号化を施す事が出来る場合があります。

　cryptを利用する場合でより強力に暗号化する場合には、(他のサブルーチンなどで利用するしないを含め記号なども勘案し、記号・数字・文字といった)文字種と文字数を増やし、乱数を発生させ、暗号化の種を使って暗号化、ハッシュ(連想配列・書式：[%変数])に格納し、受け取る際には、自分で仕込んだ暗号であっても元の値そのままでは確認できないのでハッシュの要素指定と元の値を比較して一致していれば[true]を返す仕様になっています。

　作った本人が直接値を見られない為、暗号化としてはとても強力といえば強力ですが、暗号化されたその値を不正に入手された場合には、元の値がわからないとしても暗号化された情報をそのままスクリプトに渡す事によって「プログラム側で暗号化された中身と一致するかどうか」を判定するので何を疑うことなく、通常同様処理します。

　ここでスクリプト内の入力チェックやサニタイジングが甘いと、たとえば[ | ]パイプと一緒に全く異なるコマンドを仕込まれて予期せぬ動作をしてユーザー情報やパスワード、入力データがブラウザ上で確認できてしまったり、悪意ある攻撃者のサーバに情報を送信したりといった攻撃につながりかねないので、やはり入力チェックとサニタイジングは重要になります。

　それ以前に、cryptなどの暗号化は、IDやパスワードなどの暗号化を意図しており、たとえば個人情報を含むユーザー入力情報全てをcryptで暗号化する事は想定されていませんし、実際に全て暗号化する事は現実的ではありません。

　現代ほどセキュリティに配慮する必要がなかった(不正入手して悪用、いたずらしようとする攻撃がほとんどなかった)時代には、内容自体を暗号化する事でネットワーク上で取得されても解読できないという一定の効果がありましたが、現代はそれだけではセキュリティにならないのでcryptがあるから安心というわけにはいかなくなりました。

　cryptを利用するか否かに関わらず、こうした場合には、まさにSSLによって通信を保護する必要があります。

>> エラーメッセージで墓穴を掘らない

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

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

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

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

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

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

cookieのセキュリティ設定

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

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

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

　また、善意のアクセスの拒否か、またはセキュリティ確保の二者択一を迫られるケースもあります。

2004-2008-someday