不特定多数の方に開放したホームページ上で販売を行うネットショップ・オンラインショップにおける電子商取引では、ユーザーの入力情報を保護する事が必須であり、更に外部からの攻撃に備え十二分な対策を講じる必要があります。
<< クッキーの設定と取得
HTTP仕様としてcookieヘッダに最低限必要なのは[Name=Value]であり、更に項目を続ける場合には[ ; ]を付加します。
しかし、セキュリティ上必要な設定があるので実質[Name=Value]だけでなく、いくつか正確に設定しておく必要がある項目があります。
1つは[Domain]、もうひとつは[Path]、そしてもうひとつはSSLで保護されたページである場合にセットする[secure]フラグ、更にこれらを含む場合に設定しなければならない[Version]です。
[Domain]は、ショッピングカートを運用するサイトのURL、[Path]は、その[Domain]内でcookieを有効にするパスです。
[Domain]、[Path]を省略するとそれぞれ、CGIファイルのURL、[/]ルートパスとなりますが、いずれも明記しておく方が安全です(もちろんcookieをセットしているCGIのURLが下位レベルにあり、cookieを有効にしたい[Domain]がサイトのルートURLである場合は必然的に明記する必要があります)。
当然、cookieをセットするCGIのあるドメイントップと[Domain]が異なる場合はセットできませんが、同じドメインで[http]と[https]間であればセット可能なので専用SSLの場合にはそのまま利用できます。
共有SSLの場合には、ドメイントップがSSL専用のURLとなる場合が多いと思いますが、その場合にはSet cookieによって相互にcookieを設定する事はできない為、セキュリティ強度が下がるリスクを抱えつつ若干強引な工夫が必要となります。
[secure]フラグについては、[http]ではcookieヘッダにはセットせず、かつ[https]の場合は、必ずセットする事です。
この[secure]フラグをSSLで保護された[https]ページからセットした場合には、SSLで保護された[https]ページから取得する場合に限り常にcookieを返し、[http]ページから取得する事はできません。
これにより、途中からの割り込みを排除した上で[secure]フラグをヘッダにセットしたSSLで保護された[https]ページ(守るべき個人情報を含むユーザー情報が入力されるページ)間を遷移する際に更に強固なセキュリティ確保が可能です。
[Version]は、初期のHTTPのcookie仕様では[1]のみです。
因みにcookieで[secure]フラグをセットしている場合にHTMLのmetaタグや画像ファイル、他ページへのアンカーリンクがある場合にURLが[http]となっているとWindowsでは「セキュリティで保護されていない情報が含まれるけどいい?」といった旨のポップアップメッセージが表示されます。
これが気になる場合には(必ず気になると思いますが)、セキュアページにあるリンクなどのプロトコルは全て[https]とします。
但し[secure]フラグをセットした[https]ページから[http]ページに遷移する際には、ブラウザによっては「暗号化されたページを出ようとしてるよ」とか「暗号化したページから暗号化していないページに移動してるけどホントにいい?」といった旨のポップアップメッセージが出力される場合があります。
ショッピングカートに必要な品質確保する為の大前提の対策。
セキュリティを考える上でショッピングカートCGIの対策を講じただけでは不足です。
ショッピングカートCGIで利用する複数のファイルと公開するウェブサーバ上のセキュリティ設定とディレクトリ保護、ウェブサーバへのアップロード、ターミナルエミュレータ利用におけるセキュアな接続なども必要です。
また、ログインID、パスワードはセキュアなウェブサーバ、セキュアなFTPソフト、セキュアなターミナルエミュレータにおいても徹底管理が必須です。
ネット上でショッピング機能を利用する場合、「一連の操作をしているユーザー」を特定する為にはcookie/クッキーの設定が不可欠です。
ここまでのセキュリティは最低限必要であり、cookieの実装によりショッピングカートを一応組み込む事はできますが、残念ながら完全にセキュリティが確保されるわけではありません。
また、善意のアクセスの拒否か、またはセキュリティ確保の二者択一を迫られるケースもあります。