アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
ステートフルなWebアプリ？ (スコア:0)
いわゆる「ステートフルなWebアプリ」な
開発形態やFrameworkが普及すると、
このてのミスも減ってくる、のではないでしょうか？
というのは、こういう
「見せないけど実はHTMLに紛れさせてる情報」の類を
サーバ側のステートの一部として
容易に管理できるようなアプリ構成/FWになっていれば、
わざわざそれをHTMLにも書き出そうなどと思う人はいなくなるだろうから、です。
GUIアプリを作ってたころ、
パスワとかを変数に格納することはあっても、
それを必要もないのにGUIコントロールにして画面に貼り付ける人など、
いなかったと思います。
でもWeb畑では、Hiddenだのなんだので、それに近いことが横行している。
そしてパスワなどの危ない情報は「Hiddenに入れないよう注意」しろと言われる。
(言い換えれば、ステートレスアーキテクチャのせいで、「必要がある」ケースが過剰に広がってしまった、とも。)
これ、開発体制というかFWが吸収すべき事柄の1つではないか？と思います。
Re:ステートフルなWebアプリ？ (スコア:2, 参考になる)
Javaなり、ASP.NETなり、Pythonベース、Rubyベース、Perlベースなど。
しかし、そのフレームワークを理解しないまま、セッション管理をしようとすると、
ミスが起きます。
例えば、あなたのような、プログラミング一般の知識はあるけど、Webプログラミングの知識に
乏しい人が、セッション管理フレームワークに対しての調査もせずに、自分のヒラメキだけで
セッション管理システムを構築するような場合です。
Googleの場合は、まさかセッション管理用のトークンをHTMLソースに埋め込んでいたわけでは無いと思います。
ですので、ミスではなく、単に認識の相違です。
Googleは、サブカレンダーを匿名カレンダーとして公開する用途は想定していなかった。
（非公開か、作成者を明かして公開かの2パターンしか考えていなかった）
利用者は、ブラウザ上に表示される情報だけで匿名である、と判断してしまった。
公開したMS WordやExcelのドキュメントに、実名がメタデータとして埋め込まれていたのと同じようなものです。
Re: (スコア:0)
これが、欧米人と日本人の匿名（ＨＮ）文化の差違を表しているのだろう。
Ｗｅｂ上だろうが本名で行動する欧米人と、本名を隠しＨＮを纏う日本人。
Re: (スコア:0)
Re: (スコア:0)
あれらはハンドルネームと同じです。本人特定できない代物。
そういえば本名隠して通名で犯罪働く連中もいますし。
真名と仮名という言葉があるように区分けするのは日本人っぽくおもうが、大抵の文明は区分けします。
Re: (スコア:0)
>>同じようなものです。
前に学術雑誌に論文を投稿したとき、レフリーリポートがワードのファイルで送られてきたんだけど
ファイルのプロパティの作成者に本人の名前が入力されてたことがあった。
もちろん、本来はレフリーは匿名になっているから名前は明かされないはずなんだけど
それでわかちゃった。
今はレフリーが書いたワードのファイルをそのまま送ってくるなんてことはしないだろうが
作成者に名前が入っちゃうことを知らない人はまだいるんだろうな。
Re:ステートフルなWebアプリ？ (スコア:1)
ということは、少なくともその雑誌では添付されたレポートファイルをそのまま投稿者に転送しているのだろうと推測できます。
Re: (スコア:0)
>Javaなり、ASP.NETなり、Pythonベース、Rubyベース、Perlベースなど。
WicketやSeasideなどのようなヘビーな意味での「情報を維持」するタイプのフレームワークは
まだあまり普及してるとは言えないと思います。
一方、「JavaにはHttpSessionクラスが有るよ」程度の薄い意味でのフレームワークは無数に有ります。StrutsもRailsもそれ。
どちらも原理はまあ同じです。
ただ、その足回りのHttpSessionなりなんなりといった薄いクラスの「上」に
どれだけ多くの情報を乗せるか、
そしてその情報の乗せ方をどれく
Re:ステートフルなWebアプリ？ (スコア:1, 参考になる)
＃元コメントの人は、WEB関連の開発をしたことがないのでしょうけど
＃何でこんな話が無くならないのかは、HTMLを使って認証機能を作ってみるのがいいですよ
＃HTMLやブラウザやURL（URI）にパスワードとIDを保存しないまま、画面が変わる度にどうやって
＃認証し、セッションを維持するのか等、面白い経験を出来ますよ。
＃
＃単体アプリケーションならIDとパスワードなんて認証が終わったら捨ててもいいかもしれないデータですしね。。。
Re: (スコア:0)
それをクッキー（inputのhiddenでも別によさげ）にでも保持させると思います。
これだと問題はあるのでしょうか。
Re:ステートフルなWebアプリ？ (スコア:1, 参考になる)
その場合だと再送攻撃対策としてhttps必須だよね。
普通はハッシュだけでなく多層に防衛策を講じるよね。
Re: (スコア:0)
で、要件に合わせてより高度に暗号化という感じで。
Webセキュリティの常識みたいなものって、
あまり教わる機会がなかったりしますね。
Re: (スコア:0)
Re: (スコア:0)
どれくらいセキュリティ的に強くなるんですか?
ほとんど変わらない気がしますが。
Re: (スコア:0)
Re: (スコア:0)
単純にHTMLのソースやCookieを見てもパスワードがわからない、
という効果があるね。
Re: (スコア:0)
ハッシュされたパスワードをクッキーに入れておいて、
セッション毎にそれをサーバ側のパスワードをハッシュしたものと
比較することで認証すると言っているのだから、事実上、
パスワードを流しているようなものなんだよね。
そのハッシュ化されたパスワードを盗んで、クッキーに入れれば
第三者がアクセスできるよね。
他の人がコメントしてるように、同じパスワードをあちこちで使った
ときに、別のサイトのパスワードまでは盗まれないという効果しか
ないんじゃないかな。
ランダムな文字列を使ったセッションキーを認証後に発行して
クッキーに食わせておいた方が、パスワードをハッシュしたモノを
食わせておくよりナンボかましだと思う。
ちゃんとsrc ipaddrは覚えておいて、かつキーもちゃんと削除
しないとだめだし、最初の認証でパスワードを盗まれたら同じだけど。
Re: (スコア:0)
といいたかっただけなんで、おおむね同意です。
Re: (スコア:0)
これだと盗み見られても正規の手段（ログイン画面でパスワード入力するとか）で成りすまされることはない。
それに同じパスワードを複数箇所で使用していたとして、その内一つから漏れても軒並みアウトにはならない。
また盗聴対策でTSLを使っても生パスワードをサーバに送る以上サーバロジック上は見えるのだから、通信中でなくサーバ上で盗まれる可能性は残る。ハッシュ値だと盗まれても生パスワードは知られることはない（はず）
サーバからクライアントならばそもそも論外。
オフトピ（Re:ステートフルなWebアプリ？ (スコア:0)
肝心な本文で、親コメントへの呼びかけや説明を
「＃」で始まる文章で書いているのに違和感を感じます。
「＃」で始まるのは、「独り言」とかを書いたりするもの
だと思っていますが間違ってますかね?
つまり「論外の部分」を示すものだと。
せっかくなところを「論外」にしちゃもったいない。
Re: (スコア:0)
>＃認証し、セッションを維持するのか等、面白い経験を出来ますよ。
変わるたびというのは、画面遷移のことでしょうか？
遷移するごとにパスワードとIDをクライアント/鯖間でやり取りしろ、ということでしょうか？
…それはちょっと有り得なくないですか？
ひとたびログインしたなら、その後にやり取りしなければならないのは、トークン(勘合符)だけだと思いますが…
ふつう、画面遷移するごとにログインをする、というわけじゃなく、
最初にログインしたという「状態」をクラサバ間で持ちまわ
Re: (スコア:0)
トークンが盗まれたらどうなりますか？