JavaScriptのセキュリティ
新居雅行
てください。
認証の話なんですが、クライアントのクッキーに、サーバのユーザテーブルにあるソ
ルト付きハッシュにしたデータをそのまま置いておくのってまずいのでしょうか？
通信系路上は、通信の度に変化するチャレンジを使ってハッシュを作るので、毎回ク
レデンシャルの値は違いますが、ステートレスで稼働させているので、どうしてもパ
スワードに相当するものをクライアントに置いておかないといけません。
もちろん、ハッシュなのでデータを見てもわかりません。また、他のサーバに接続し
たときには抜き出すことはできませんし、javascript:でプログラムを買い手も取り出
せないので、クロスサイトスクリプティング以外では取り出せないと思います。もち
ろん、ブラウザを操作して覗き見して…というシナリオもありますが、これを「安全」
と見るかどうかですね。
とりあえず、ユーザ名とハッシュしたパスワードをクッキーに入れておき、認証を継
続できるようにしました。クッキーに入れないというオプションも作っています。そ
して、時間がくれば、チャレンジの期限とクッキーの期限設定の両方で、認証をやり
直させるところまで、とりあえず一通りできました。
_______________________________________________________________
新居雅行/Masayuki Nii <n...@msyk.net> <ms...@mac.com>:iChat Ready
Web Site <http://msyk.net> / INTER-Mediator [for Web App] http://msyk.net/im
Twitter: @msyknii (Japanese), @MasayukiNii (English) / Facebook: Masayuki Nii
Atsushi Matsuo
> 認証の話なんですが、クライアントのクッキーに、サーバのユーザテーブルにあるソ
> ルト付きハッシュにしたデータをそのまま置いておくのってまずいのでしょうか？
> 通信系路上は、通信の度に変化するチャレンジを使ってハッシュを作るので、毎回ク
> レデンシャルの値は違いますが、ステートレスで稼働させているので、どうしてもパ
> スワードに相当するものをクライアントに置いておかないといけません。
明らかにまずいというケースがすぐに思いつかないのですが、クッキーに保存す
るのは抵抗があります。より安全な設計にするとすれば、クッキーではなくセッ
ションに格納するほうが好ましいと思います。
--
松尾 篤
http://www.famlog.jp/
新居雅行
---“Re: [IM-ML-J] JavaScriptのセキュリティ”によりますと
>
> 明らかにまずいというケースがすぐに思いつかないのですが、クッキーに保存す
> るのは抵抗があります。より安全な設計にするとすれば、クッキーではなくセッ
> ションに格納するほうが好ましいと思います。
それも考えたました。一般のWebフレームワークはそうしているのですが、それは、セ
ッションの記録のときに１度だけネットワークを通し、サーバにパスワード情報が行
っているので、それをサーバの中で取り出しているわけで、「安全」ですよね。もっ
とも、CodeIgniterは暗号化したデータを飛び交わせているので、さらに安全なのか。
IMの場合、セッションで記録しても、それをクライアントに転送しないといけません。
そうなると、パスワードそのものがネットワークを移動する機会がかえって増えると
思い、クッキーにしたのでした。安全性をどう評価するかによりますが、ネットワー
クよりクッキーの方が安全かと考えたのです。
Atsushi Matsuo
IMならではの事情があるのですね。
セッション情報をクッキーに格納するフレームワークでは認証用のデータをどの
ように保存していたりするのか気になりますが、クッキーの内容変更や改竄を検
知するような仕組みぐらいは大抵備わっていたような気がします。
ただ、現状では何とも言えないので、このあたりはもう少しソースコードを読ん
だり、調べてからコメントしたいと思いますが、他の方のご意見等も聞いてみた
いです。
--
松尾 篤
http://www.famlog.jp/