httphttps間のでセッションIDの受け渡しにおいてのhttp

Question

http<>https間のでセッションIDの受け渡しにおいてのhttps専用のクッキーと、http+https兼用のクッキーの計2つを発行するやり方について教えてください。

httpで買い物カゴに商品を入れてhttpsで顧客情報を入力してもらうサイトを作成しています。
どちらの情報もセッションで管理しているのですが、他のサイトで質問させて貰った際、http<>https間のでセッションIDの受け渡しには、「SSLページと非SSLページが必要なサイトの場合、https専用のクッキーと、http+https兼用のクッキーの計2つを発行するというやり方が安全です。」との回答を頂きました。

ですが、私が知識不足で、どうしたらこれが実現出来るのかさっぱり分からないでいます。
ヤフーの知恵袋で質問した時に回答を頂いたのですが、理解出来ないでいます。
http://detail.chiebukuro.yahoo.co.jp/qa/question …

http<>https間ではPOSTやGETでSIDを渡しています。
これにどのようにクッキーの発行をすれば「安全」なサイトになるのでしょうか？

httpで入力したものはhttpsでも見れる。httpsで入力したものはhttpでは見れない。という動きになれば正解なのですよね？（すみません、これすらも分からないでいます）

別々のクッキーを発行する意味もよく理解出来ないでいます。

説明と合わせて、実際のコードも書いて頂くととても参考になります。

ご教授、よろしくお願いいたします。

通報する

buraigasho · Accepted Answer

>なぜ「さらにSSLから抜けるときはこのIDは破棄される」のでしょうか？
session_regenerate_id()で毎回異なるIDを作成する為です。。。

>「SSLで以下を実行
>setcookie("CHKID", "ID番号",0,"","",TRUE);」
>は何の為にしているのでしょうか？
>非SSLでこのクッキーの内容が見れないのは分かりますが、
>このクッキーは何の為にあって、何に使われるのでしょうか？
>SSLでのセッションと何の関係があるのでしょうか？
非SSLとSSLで共通して使うデータは、買い物かごの中身。
SSLだけでセキュアな環境でしか扱わないデータは個人情報！
つまり、ログイン情報です。

サイト作りの問題ですが、大体のサイトが、ログイン画面をSSLで、その他を非SSLで、そして決済画面をSSLでという具合で作られていると思います。
この「ログイン」と「決済」では連続して流れる場合と非SSLといったりきたりという場合が想定されます。
一度ログインしてブラウザを閉じてもいないのに再度ログインするのは面倒というユーザーのために、セッションとクッキーを駆使して、ログイン状態の維持を行なっています。
そういったプログラムのために、セキュアなクッキーや兼用できるクッキーというものを保持しようとするプログラムを作っているわけです。

SSLを使う意義やSSLで扱わなければいけないデータの定義、SSLで扱わないデータというのを考えれば理解できると思うのですが・・・

でも、理解というのはその人の考えなので、私の理解を押し付けているのかもしれませんね。
とりあえず、理解を後回しで、プログラムを作ってみて、運用。
テスト運用で危険なところやデータが安全じゃないところを探し出し、そのときにセキュアな仕組みを考えて組み込んでみてはいかがですか？

buraigasho · Answer

ん～～～やっぱりごちゃごちゃになっています。

SSLで格納したSESSION変数はなくなりますし、コードも変になってます。。。。

あくまでクッキーのお話ですので、セッションIDはいったん忘れてください。

SSLで以下を実行
<?php
setcookie("CHKID", "ID番号",0,"","",TRUE);
?>

非SSLで
<?php echo $_COOKIE['CHKID']; ?>
をしても表示されませんが、SSLでこのコードを実行すると表示されると思います。
これがhttps専用クッキー

SSL・非SSLどちらでも以下を実行
<?php
setcookie("CHKID2", "ID番号2",0,"","",FALSE);
?>
クッキーは破棄されていないですし、セキュア属性もついていないので、SSL・非SSL両方で利用できます。これがhttp+https兼用クッキーです。

セッションIDは
SSLで利用する際に盗聴防止の為新しいものに変えます。それが

session_regenerate_id()

そして、SSL通信なのでこのIDは暗号化されているため、安全。
さらにSSLから抜けるときはこのIDは破棄されるので、安全。

という仕様です。

セッションIDとクッキーが混ぜ混ぜになっているので理解の為今一度勉強してみてください。

質問は、
１、セッションIDはひとつです。お試しのコードはセッション変数を使っていますので、
session_name(＊＊);はひとつでいいです。
session_start();が余分。

２、はい。
３、いいえ。
４、上記の回答をご参考に・・・

Webページで取り扱うデータの流れを考えたときに、SSLと非SSLのデータの流れもフロー図なりアクティビティ図なりで明確にされてからですと、クッキーやセッションIDの流れも理解できるのではないでしょうか。

buraigasho · Answer

ごめんなさい。
ん～言葉にすると色々と違いが出てきますねぇ。私の言い回しもおかしいので混乱してしまう・・・

とりあえず、mitan3354さんが理解されている内容は間違っていません。

個人情報用のクッキーはhttps専用クッキー(SSLで発行したセッションID）
買い物かご情報などのhttpとhttpsで兼用したい情報はhttp+https兼用クッキー(セッション変数)

という考え方でしたほうがよいのかと・・・

ん＝＝＝説明いまいちですねぇ。。。
私が勉強の時に使っているサイトをご紹介します。
そちらですと絵も交えて本当にわかり易いです。

セッションとクッキーとSSLについてのページ
http://www.geocities.jp/sugachan1973/doc/funto62.html

参考URL：http://www.geocities.jp/sugachan1973/doc/funto62.html

buraigasho · Answer

そもそもセキュアなサイト作りをしたいとおっしゃっていますので、ご自身のサイト作りを根底から考え、何がしたいということを明確にされたほうがいいと思います。
何が安全？という基準はサイト作りによりますし、設計の問題でもあると思います。
入力内容を最高の安全レベルで操作されるならページを遷移する際に内容破棄という手段もあります。

質問されている専用クッキーと兼用クッキーの2つを発行される場合、同様のセッション情報で行き来するのですから、当然httpでもhttpsでも内容は確認できるはずです。

もし、httpsからhttpに戻る場合、入力内容が見れなくするには、セッション情報を破棄すればそうなります。

ただし、セッション情報が破棄されていますので、httpからhttpsに戻る場合、入力内容は残りません。

ここで破棄をする場合としない場合の切り分けを考えますと、入力した人かそうでないかになると思います。

それを踏まえて、前回書かれているコードは、クッキーは、今見ている人が入力した人かどうかをチェックする道具として使用していますので、入力した人であれば、セッション情報を公開してみせるといった方法です。

セッションとクッキーの使い方を一度確認してみてはいかがでしょうか？

http<>https間のでセッションIDの受け渡しにおいてのhttp

>なぜ「さらにSSLから抜けるときはこのIDは破棄される」のでしょうか？

ん～～～やっぱりごちゃごちゃになっています。

この回答への補足

ごめんなさい。

この回答への補足

そもそもセキュアなサイト作りをしたいとおっしゃっていますので、ご自身のサイト作りを根底から考え、何がしたいということを明確にされたほうがいいと思います。

この回答への補足

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング