- PR -

鍵のアイコンが出ないSSLのページ

投稿者投稿内容
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2005-09-15 10:13
おはようございます。
引用:
開発側から見ると、ログイン機能のあるアプリケーションでは、https
オンリーでの開発を行いたいですね。
http,httpsが混在する画面遷移でCookieの盗聴まで考慮すると、
https用Cookieとhttp用Cookieの2つを管理しないといけないので^^;


そういえば、Cookieのことを失念していました。
確かに http/https用を分けるのは大変そうですね。
それにユーザにとっても、切り替わりの度に面倒な思いをしそうな気が…。
※上手く作れば無問題なのでしょうか?
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2005-09-15 13:22
こんにちは。

引用:

そういえば、Cookieのことを失念していました。
確かに http/https用を分けるのは大変そうですね。
それにユーザにとっても、切り替わりの度に面倒な思いをしそうな気が…。
※上手く作れば無問題なのでしょうか?



CookieにはSecure属性というものが存在するのですが、
Secure属性が設定されていないCookieはhttp,httpsのURLへ送信される。
Secure属性が設定されたCookieはhttpsのURLにしか送信されない。
という動作をします。
Cookieが送られるか送られないかの違いなので、ユーザの視点で見た場合
に切り替わりの都度面倒な思いをすることはありません。

ただ、問題となるのは開発サイドでSecure属性を意識せずに(Defaultでは
無設定で動作します。)設計されている場合です。この場合、暗号化され
ていないSessionIDが垂れ流されますので、盗聴される可能性があることに
なります。この場合アプリケーションの動作上で問題が発生することはない
ので、開発者が気付いていないケースが多いかな。
と個人的には思っております。

上手く作ることが出来れば問題ないですが、上手く作るのは大変なコストが
かかりそうですね。
http,https共有サイトの作成経験はありません^^;
KENCH
ベテラン
会議室デビュー日: 2004/09/15
投稿数: 82
お住まい・勤務地: FBI,CIA,KGB,MI6にマークされているためシークレット
投稿日時: 2005-09-16 09:05
引用:

masaさんの書き込み (2005-09-15 13:22) より:
こんにちは。

無設定で動作します。)設計されている場合です。この場合、暗号化され
ていないSessionIDが垂れ流されますので、盗聴される可能性があることに



とても割って入れるレベルの会話ではないのですが、
僕のスレなので話に混ぜて下さい(笑)

SessionIDが漏れても、実際のデータが暗号化されていれば
問題が無いと考えるのは無謀ですか?
SessionIDが漏れると盗聴される可能性があるというのがピンと
来ていないのですが。
ここで語れないほど大変な話ならサイトなりを紹介していただけるとうれしいです、
勉強します。
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2005-09-16 09:48
おはようございます。
引用:
CookieにはSecure属性というものが存在するのですが、
Secure属性が設定されていないCookieはhttp,httpsのURLへ送信される。
Secure属性が設定されたCookieはhttpsのURLにしか送信されない。
という動作をします。
Cookieが送られるか送られないかの違いなので、ユーザの視点で見た場合
に切り替わりの都度面倒な思いをすることはありません。


ありがとうございます。Secure属性で、送る側がふるいにかけられるのですね。
だとすれば作り手の問題…、としてもコレ ( http/https の使い分け ) を設計して提案する手間は、やはりかけてられなさそうですね。

引用:
SessionIDが漏れても、実際のデータが暗号化されていれば
問題が無いと考えるのは無謀ですか?


私もプログラミングはやりますが、決してプロではないので詳しくは言えないのですが…、おそらく「セッションハイジャック」がキーワードになると思います。
@ITさんでも、解説している記事があるようです。

http://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2005-09-16 12:55
こんにちは。

引用:

ありがとうございます。Secure属性で、送る側がふるいにかけられるのですね。
だとすれば作り手の問題…、としてもコレ ( http/https の使い分け ) を設計して提案する手間は、やはりかけてられなさそうですね。


APサーバレベルでサポートされているケースもあるようですが、その場合にどれほどの
手間がかかるのかは私にはちょっと分かりません
ということを補足しておきます。

引用:

引用:
SessionIDが漏れても、実際のデータが暗号化されていれば
問題が無いと考えるのは無謀ですか?


私もプログラミングはやりますが、決してプロではないので詳しくは言えないのですが…、おそらく「セッションハイジャック」がキーワードになると思います。
@ITさんでも、解説している記事があるようです。

http://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html


前提として、「ログイン機能があるアプリケーション」では
と記述しましたが、SessionIDに紐づくデータに重要な情報が含まれない場合は
問題ないですね。
重要なデータが含まれているならば、angelさんのおっしゃる通り
「セッションハイジャック」の危険が発生することになります。
KENCH
ベテラン
会議室デビュー日: 2004/09/15
投稿数: 82
お住まい・勤務地: FBI,CIA,KGB,MI6にマークされているためシークレット
投稿日時: 2005-09-16 17:35
引用:

masaさんの書き込み (2005-09-16 12:55) より:
前提として、「ログイン機能があるアプリケーション」では
と記述しましたが、SessionIDに紐づくデータに重要な情報が含まれない場合は
問題ないですね。
重要なデータが含まれているならば、angelさんのおっしゃる通り
「セッションハイジャック」の危険が発生することになります。


了解です。私はSessionIDは16進のえらい桁の文字列しか見たこと
なかったものでして、SessionIDとはまったく無秩序な文字列が生成されるもの
だとばかり思っていたのですが、教えていただいたページを見ると
そうではないんですね。
勉強になりました。他のページも全部よんでみます。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-09-16 18:11
暗号化の話しか出てこないけど、SSLには出所を証明すると言う機能もあるんですよね。どちらかと言うとこちらのほうが重要だと思います。実際パケットを覗き見するなんて、同じLANに繋いでいる同僚か家族でもなきゃ、現実には困難でしょう?

おれおれ証明書が駄目なのも、送信する時だけで入力画面がSSLになってないのも、出所を証明する機能を果たしていないからですよね。本当はSSLひとつでファーミングやDNSハイジャックやらの成りすましを、あらかた防げるはずなんですけどねぇ。

#@ITはhttpsでも繋がるけど記事は読めないと言う不思議なつくりになってますね。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-09-17 02:53
脱線 & 反応も遅くてすみません。

勝手証明書とか、オレオレ証明書とか、ナンチャッテ証明書などは、
ニュアンスの違いはありますが、好みの問題かな、と思います。

でも、こう云った物を自己署名証明書というのはちょっと違和感があります。
自己署名証明書というのはあくまでも技術的な用語であって、危険性が伝わらない気がします。
そもそもルート証明書も自己署名証明書であるわけですし。

個人的にはオレオレ証明書がしっくり来ますね。
「俺が署名している証明書だから信用しろ」って云う感じだと思います。

DNSハイジャック/ポイズニング単体の攻撃に対してはSSLはかなり有効だと思います。
しかし、ファーミングへの対策としては十分だとは言い切れないと思います。
怪しげなルート証明書が1つでも追加されてしまえば、それを利用して偽の証明書を作れますから。
DNSハイジャック/ポイズニング、hostsファイル書き換え等と併用する必要がありますけどね。

ところでMSIEやFirefox等の証明書ストアってどこに格納されているんでしょうか?
証明書のリストやハッシュを保存して定期的に比較すれば、変な証明書が増えたりしていないかチェック出来そうな気もしますけど。

スキルアップ/キャリアアップ(JOB@IT)