![[dir] プログラミング](https://logo-imagecluster.img.mixi.jp/photo/comm/59/80/105980_186s.jpg){kind=logo}
皆様に質問させてください・・・（＞＿＜；）
ただいま、BASIC認証で苦戦中・・・。
というか、無理な仕様に苦戦中・・・。（ー＿ー）
えっと、BASIC認証でログインしてきた人の識別はできますか？
例えば「.htaccess」ファイルに
user1:passpass1
user2:passpass2
と書いた場合、BASIC認証で、
「user1」でログインした場合と、
「user2」でログインした場合とで、
ログイン後の画面の「ようこそxxxxxさん！」の
「xxxxx」の部分の表示を変えたいと考えています。
（というか、そういう無理な仕様を伝えられて困ってます；；）
可能でしょうか！？
ご存知の方、おられましたら、ごきょうじゅくださいっっ！！！
みな
|
|
|
|
コメント(44)
BASIC認証が 認証機能として その機能に足らないという 提言が いぜんから 出ているが、そのかわりの提案も 同時に示すべきだとおもうのだが・・・（クライアント証明書を使おうとか、公開暗号鍵方式にしようとか じぶんが いいと 思う代替案もかいてほしいかったな。）
BASIC認証いがいに てがるな認証機能を提案できないからじゃないのか?
がるさんも blogでかいてるように BASIC認証でも SSLなら OKだと おもうぜ・・・SSLが 破られたらなんて 書いもあったけど ID&パスワードをつかってる 認証機能は 全滅だし なんでも いいんじゃね？
というわけで SSLでつかうのを 前提として PHPで BASIC認証で やっても いいんじゃね？
BASIC認証いがいに てがるな認証機能を提案できないからじゃないのか?
がるさんも blogでかいてるように BASIC認証でも SSLなら OKだと おもうぜ・・・SSLが 破られたらなんて 書いもあったけど ID&パスワードをつかってる 認証機能は 全滅だし なんでも いいんじゃね？
というわけで SSLでつかうのを 前提として PHPで BASIC認証で やっても いいんじゃね？
がるです。
…なんだか思ったよりも会話が発展しているようなので。
To さだちん@酒呑(元HG)さん
「セキュリティってのは費用（コスト、手間、気合い）対 効果の最たる物」というご発言そのものについては、私もYesだと思います。
ただ、一方で「ないほうがまし」なものもまた存在します。
ちょいと噛み砕いて。
何も認証がかかっていなければ、それなりに使う人間が危機管理なり危険意識なりをもてるのですが。
現実問題として「有効性が皆無に近い」Basic認証を用いることで「認証がかかってるから安全だろう」と人間の意識にふたをしてしまう分だけ、よりいっそう危ないケースが発生しえます。
これは、実際に「ECサイトの管理画面でSSLを用いていないBasic認証を使い、ユーザが"IDとパスワードを入力しているんだから安全なはずだろ？"」と誤認されたケースがあります。
To ＠Workgroupさん
んと……………「BASIC認証でも十分であると誤認できる」物はきっと多々(苦笑
閑話休題。
たぶん、認証って言葉の定義からきちんと入るべきだと思うのですが。九分九厘、その定義をすると、Basic認証って入らないんですよね(苦笑
To てと☆さん
「そのかわりの提案も 同時に示すべきだとおもうのだが」おっしゃるとおりです。
ただ…PHPであれば、とりあえずsession関数郡というものがあると思うのですがいかがでしょうか？
ログイン周りについては、その辺だけを追加実装すればとりあえず何とか設定次第ではBasic認証よりは「まし」だと思うのですが。
私は中の実装までをC言語レベルで確認したうえで限りなく否定的ですので、自作で認証系のクラス郡を持ってますが。
んでまぁ「ユーザを特定したいわけじゃなくてとりあえず経路をある程度秘密にしておきたい」なら、SSLでBasic認証(…個人的にはせめてDigest認証)ってのも、ないわけじゃないと思うです。
# 生理的にちょっと…ってのはありますが、冷静に技術検証して、とりあえず「一番まずい部分」はおおむねヘッジできてるので。
ちなみにBasic認証の「技術者として嫌悪感を感じるもうひとつ」はPHP_AUTH_PWの存在です。
…冷静に考えて「この仕様ってどうよ？」とか思ってしまいます正直。
以上雑感で恐縮ですが。
…なんだか思ったよりも会話が発展しているようなので。
To さだちん@酒呑(元HG)さん
「セキュリティってのは費用（コスト、手間、気合い）対 効果の最たる物」というご発言そのものについては、私もYesだと思います。
ただ、一方で「ないほうがまし」なものもまた存在します。
ちょいと噛み砕いて。
何も認証がかかっていなければ、それなりに使う人間が危機管理なり危険意識なりをもてるのですが。
現実問題として「有効性が皆無に近い」Basic認証を用いることで「認証がかかってるから安全だろう」と人間の意識にふたをしてしまう分だけ、よりいっそう危ないケースが発生しえます。
これは、実際に「ECサイトの管理画面でSSLを用いていないBasic認証を使い、ユーザが"IDとパスワードを入力しているんだから安全なはずだろ？"」と誤認されたケースがあります。
To ＠Workgroupさん
んと……………「BASIC認証でも十分であると誤認できる」物はきっと多々(苦笑
閑話休題。
たぶん、認証って言葉の定義からきちんと入るべきだと思うのですが。九分九厘、その定義をすると、Basic認証って入らないんですよね(苦笑
To てと☆さん
「そのかわりの提案も 同時に示すべきだとおもうのだが」おっしゃるとおりです。
ただ…PHPであれば、とりあえずsession関数郡というものがあると思うのですがいかがでしょうか？
ログイン周りについては、その辺だけを追加実装すればとりあえず何とか設定次第ではBasic認証よりは「まし」だと思うのですが。
私は中の実装までをC言語レベルで確認したうえで限りなく否定的ですので、自作で認証系のクラス郡を持ってますが。
んでまぁ「ユーザを特定したいわけじゃなくてとりあえず経路をある程度秘密にしておきたい」なら、SSLでBasic認証(…個人的にはせめてDigest認証)ってのも、ないわけじゃないと思うです。
# 生理的にちょっと…ってのはありますが、冷静に技術検証して、とりあえず「一番まずい部分」はおおむねヘッジできてるので。
ちなみにBasic認証の「技術者として嫌悪感を感じるもうひとつ」はPHP_AUTH_PWの存在です。
…冷静に考えて「この仕様ってどうよ？」とか思ってしまいます正直。
以上雑感で恐縮ですが。
BASIC認証は、HTMLや画像など静的なコンテンツを含めてディレクトリまるごと認証を入れられるのが、便利なところですよね。
そういう意味でチョイスしてしまうのだと思います。
例えば、mixiでは一時、認証なしで外部から日記中の画像ファイル（静的コンテンツ）にはアクセスできたらしいので、BASIC認証を使わなかったからこその弊害とも言えるのではと。
（現在は、画像ファイル名を定期的に変動させることで、
キャッシュでの通信の効率化と、外部直リンク防止を両立させていると聞きました。多分REFERERなんかとも組み合わせしてもっと慎重にはなってるでしょうけど）
といって、下手な場所にhtpasswdファイルをおいたり
.htaccessファイルを含めてアクセス制限を入れてなかったりする事例も多いし、
パスワードリトライするアタックに対しての制限がなかったり
（もしかしてapacheの機能であるのかな、知らなくてすいません）
通信経路途中でtcpdumpすればパスワードまる見えだしで、
BASIC認証(PHPのBASIC認証を含めて）が決して堅牢なものとは言えないというのも同感です。
SSLで通信を暗号化しても、キーロガーされれば無意味だろうし、
加えて、クライアント認証入れても
ログインしっぱなしで離席したり、ブラウザのパスワード保存機能を使われたり、さらにそれが盗難にあったりするとやっかいで、
いいだすとキリがないというのも正直なところかなと。
もちろん、そのサイトが想定しているユーザー層によっても違ってくるでしょうけど。
クライアント側のIPアドレスで制限を加えると、ある用途
（例えば、管理職が社内サーバーにクライアント認証+IP制限でアクセスするなど）
には有効かもしれませんが、
不特定多数に相手の用途だとIP登録時のその身元確認などの管理コストも必要だし、
NATやProxy経由でアクセスされると、結局そこ経由からは全クライアントがIP制限をかいくぐることになりそうですし・・・
といって、ワンタイムパスワードや生体認証使わせるにはコストかかりそうだし・・・
結局、守りたいものとのコストバランスというところに
落ち着きそうなんでけど、どうなんでしょう？
そういう意味でチョイスしてしまうのだと思います。
例えば、mixiでは一時、認証なしで外部から日記中の画像ファイル（静的コンテンツ）にはアクセスできたらしいので、BASIC認証を使わなかったからこその弊害とも言えるのではと。
（現在は、画像ファイル名を定期的に変動させることで、
キャッシュでの通信の効率化と、外部直リンク防止を両立させていると聞きました。多分REFERERなんかとも組み合わせしてもっと慎重にはなってるでしょうけど）
といって、下手な場所にhtpasswdファイルをおいたり
.htaccessファイルを含めてアクセス制限を入れてなかったりする事例も多いし、
パスワードリトライするアタックに対しての制限がなかったり
（もしかしてapacheの機能であるのかな、知らなくてすいません）
通信経路途中でtcpdumpすればパスワードまる見えだしで、
BASIC認証(PHPのBASIC認証を含めて）が決して堅牢なものとは言えないというのも同感です。
SSLで通信を暗号化しても、キーロガーされれば無意味だろうし、
加えて、クライアント認証入れても
ログインしっぱなしで離席したり、ブラウザのパスワード保存機能を使われたり、さらにそれが盗難にあったりするとやっかいで、
いいだすとキリがないというのも正直なところかなと。
もちろん、そのサイトが想定しているユーザー層によっても違ってくるでしょうけど。
クライアント側のIPアドレスで制限を加えると、ある用途
（例えば、管理職が社内サーバーにクライアント認証+IP制限でアクセスするなど）
には有効かもしれませんが、
不特定多数に相手の用途だとIP登録時のその身元確認などの管理コストも必要だし、
NATやProxy経由でアクセスされると、結局そこ経由からは全クライアントがIP制限をかいくぐることになりそうですし・・・
といって、ワンタイムパスワードや生体認証使わせるにはコストかかりそうだし・・・
結局、守りたいものとのコストバランスというところに
落ち着きそうなんでけど、どうなんでしょう？
がるです。
To てと☆さん
んと…。
どーゆー認証機能を使うかにもよるのですが。私がしっているかぎりにおいて、通常の(或いはまっとうな)認証で「HTTP通信をwatchしてると パスワード見れちゃう」っていうのは、ないです。
或いはより正しく言うのであれば
・最初の一回を除いてあとはIDだのパスワードだのはやりとりしない
ものだと思ってます。
で。それと比較して、Basic認証は「毎回、暗号化すらされていないIDとパスワードが」流れ続けるのが問題であると私は認識しております。
ですので、危険度は、私は「比べものにならないほど異なる」と認識しておりますが如何でしょうか？
もし「一回でも毎回でも流れるんなら一緒じゃん」という発想であれば………それはそれで、まぁ、という感じなのですが。
To てと☆さん
んと…。
どーゆー認証機能を使うかにもよるのですが。私がしっているかぎりにおいて、通常の(或いはまっとうな)認証で「HTTP通信をwatchしてると パスワード見れちゃう」っていうのは、ないです。
或いはより正しく言うのであれば
・最初の一回を除いてあとはIDだのパスワードだのはやりとりしない
ものだと思ってます。
で。それと比較して、Basic認証は「毎回、暗号化すらされていないIDとパスワードが」流れ続けるのが問題であると私は認識しております。
ですので、危険度は、私は「比べものにならないほど異なる」と認識しておりますが如何でしょうか？
もし「一回でも毎回でも流れるんなら一緒じゃん」という発想であれば………それはそれで、まぁ、という感じなのですが。
２回目移行の通信では生パスワードではなく生のsessionIDが流れているが、
それは生パスワードを流すよりかは、傍受・詐称されにくいということですよね。
ちなみに、sessionを使えない静的コンテンツは、別の方法で制限かける形になるのでしょうか？
いや、もちろん、BASIC認証が甘いからこそ、いろいろなソリューションが提案されているというは分かりますし、私自身もあまり使うことはないのです。
ただ、用途によっては、BASIC認証のほうが向いているものもあるんではないかな・・とふと考えたわけです。
もちろん、その危険性を分かって選んでいるか、安易に選択しているかでは、大きく意味が異なるでしょうけど。
それは生パスワードを流すよりかは、傍受・詐称されにくいということですよね。
ちなみに、sessionを使えない静的コンテンツは、別の方法で制限かける形になるのでしょうか？
いや、もちろん、BASIC認証が甘いからこそ、いろいろなソリューションが提案されているというは分かりますし、私自身もあまり使うことはないのです。
ただ、用途によっては、BASIC認証のほうが向いているものもあるんではないかな・・とふと考えたわけです。
もちろん、その危険性を分かって選んでいるか、安易に選択しているかでは、大きく意味が異なるでしょうけど。
がるです。
To SAGさん
> ２回目移行の通信では生パスワードではなく生のsessionIDが流れているが、
> それは生パスワードを流すよりかは、傍受・詐称されにくいということですよね。
んと…少なくとも私は、sessionIDを生では流さないですね。
前後に乱数(正しくはランダムな長さのランダムな文字列)を入れた上で暗号化してます(Rijndael使用)。
生sessionIDは…寿命を短くしてなお、どうしても分析とかされちゃうんじゃないかと思うと私は怖かったりしますがどうなんですかねぇ実際。
> ちなみに、sessionを使えない静的コンテンツは、別の方法で制限かける形になるのでしょうか？
色々と「sessionで静的コンテンツを制御する」方法があるです。
…そういえばこの話は、最近mixiが引っかかって色々トラブル起こしてましたね(苦笑
日記だかの画像が「URI貼り付けたら外から丸見え」とかで。
つまりはそういうトラブルを招くことになると思います。
> ただ、用途によっては、BASIC認証のほうが向いているものもあるんではないかな・・とふと考えたわけです。
> もちろん、その危険性を分かって選んでいるか、安易に選択しているかでは、大きく意味が異なるでしょうけど。
おそらく、用途次第では「BASIC認証でもよい」モノはあると思うのですが。最低限、SSLが必須になりますよね？
で。SSL認証の証明書取るのも、結構、時間だのコストだのかかります。
だとすると、そこらあたりを一通り鑑みてなお「Basic認証でよい」状態が発生するとは、正直あまり思えないです。
で。ちと前後しますが。22番でヤマハタさんがおっしゃってるとおり「この辺りのシステムって一度作ってしまうと使いまわしが効きますので」一回作ってあとは使い回してます。
まぁ「すでにSSL取ってるドメインのマシン」なら、コストが下がるのですが。
ちなみに使用頻度は「希に」です。皆無ではないです。
具体的には「別にいいじゃん一般に公開したって」というものを「とりあえずおざなりに認証もどきでお茶を濁す」ような場合、割と積極的に使います(苦笑
To 幻夜祭さん
これはあくまで私の経験だけのお話なのですが。
当人「漏洩していない」と思いこんでいて、調べてみるとあちこちに漏れてた、なんて事は多々あります。Basic認証で(ちょっと言うのが憚られるレベルで危ない情報が)漏れていた事も１度や２度ではありません。「漏れてる可能性があるけど確定はできない」程度であれば…なにをかいわんや。
あと、この手の話は「実際に漏れたか」ではなく(漏れちゃまずいんです)、どのように漏れる可能性があってそれがどの程度考えられるか、という考察が大切なのだと思いますが如何なものでしょうか？
少なくとも「こういう防御手段によってもれを防いだ」というお話がないと、あまり意味がないように思われます。
以上雑感で恐縮ですが。
To SAGさん
> ２回目移行の通信では生パスワードではなく生のsessionIDが流れているが、
> それは生パスワードを流すよりかは、傍受・詐称されにくいということですよね。
んと…少なくとも私は、sessionIDを生では流さないですね。
前後に乱数(正しくはランダムな長さのランダムな文字列)を入れた上で暗号化してます(Rijndael使用)。
生sessionIDは…寿命を短くしてなお、どうしても分析とかされちゃうんじゃないかと思うと私は怖かったりしますがどうなんですかねぇ実際。
> ちなみに、sessionを使えない静的コンテンツは、別の方法で制限かける形になるのでしょうか？
色々と「sessionで静的コンテンツを制御する」方法があるです。
…そういえばこの話は、最近mixiが引っかかって色々トラブル起こしてましたね(苦笑
日記だかの画像が「URI貼り付けたら外から丸見え」とかで。
つまりはそういうトラブルを招くことになると思います。
> ただ、用途によっては、BASIC認証のほうが向いているものもあるんではないかな・・とふと考えたわけです。
> もちろん、その危険性を分かって選んでいるか、安易に選択しているかでは、大きく意味が異なるでしょうけど。
おそらく、用途次第では「BASIC認証でもよい」モノはあると思うのですが。最低限、SSLが必須になりますよね？
で。SSL認証の証明書取るのも、結構、時間だのコストだのかかります。
だとすると、そこらあたりを一通り鑑みてなお「Basic認証でよい」状態が発生するとは、正直あまり思えないです。
で。ちと前後しますが。22番でヤマハタさんがおっしゃってるとおり「この辺りのシステムって一度作ってしまうと使いまわしが効きますので」一回作ってあとは使い回してます。
まぁ「すでにSSL取ってるドメインのマシン」なら、コストが下がるのですが。
ちなみに使用頻度は「希に」です。皆無ではないです。
具体的には「別にいいじゃん一般に公開したって」というものを「とりあえずおざなりに認証もどきでお茶を濁す」ような場合、割と積極的に使います(苦笑
To 幻夜祭さん
これはあくまで私の経験だけのお話なのですが。
当人「漏洩していない」と思いこんでいて、調べてみるとあちこちに漏れてた、なんて事は多々あります。Basic認証で(ちょっと言うのが憚られるレベルで危ない情報が)漏れていた事も１度や２度ではありません。「漏れてる可能性があるけど確定はできない」程度であれば…なにをかいわんや。
あと、この手の話は「実際に漏れたか」ではなく(漏れちゃまずいんです)、どのように漏れる可能性があってそれがどの程度考えられるか、という考察が大切なのだと思いますが如何なものでしょうか？
少なくとも「こういう防御手段によってもれを防いだ」というお話がないと、あまり意味がないように思われます。
以上雑感で恐縮ですが。
> 前後に乱数(正しくはランダムな長さのランダムな文字列)を入れた上で暗号
サーバ側だけで暗号化処理させて通信させると、そのをままそれを偽装したり、ブラウザのセキュリティーホールから取り出しできそうな気がしますので、公開鍵をブラウザに渡して、ブラウザ側で暗号化処理させて送り出すということなんですかね。
もちろん時限させるのでしょうけど。
> そこらあたりを一通り鑑みてなお「Basic認証でよい」状態が発生するとは、正直あまり思えないです。
セキュアな目的で認証を使うのではなく、ユーザー識別程度でよい場合とかはありえるんじゃないですかね。
ヤマハタさんが例にだされた
> 開発用サイトに一般ユーザが迷い込んでこないようにブロックする。
とか、
サイト公開前に、あるコミュニティーにだけ限定公開するとか
守るべきデータはなにもないけど、サーバ負荷削減のためにユーザー数を限定したときとか、
性善説がなりたつ程度の人数のイントラネットでのグループウエアとか
サイト作っちゃったあとでユーザー限定したほうがいいかな程度のものとか
＃あまり具体的になってないけど（笑）
> 最低限、SSLが必須になりますよね？
”ある用途においては”その通りだと思います。
ただ、想定されている用途の範囲に違いがあるんだと思いますが
SSL程度では満足できないケースもありますよね。
IP制限とかクライアント証明書もつかうべきケースとか
トークンや生体認証を使う以外にも
登録された携帯のメールアドレスにワンタイムパスワード送るとか
紙のハッシュ票を配るとか
コストのかからない方法もあるでしょうし、そういうのもあわせ技として、使うべき用途もあるんじゃないですかねぇ。
サーバ側だけで暗号化処理させて通信させると、そのをままそれを偽装したり、ブラウザのセキュリティーホールから取り出しできそうな気がしますので、公開鍵をブラウザに渡して、ブラウザ側で暗号化処理させて送り出すということなんですかね。
もちろん時限させるのでしょうけど。
> そこらあたりを一通り鑑みてなお「Basic認証でよい」状態が発生するとは、正直あまり思えないです。
セキュアな目的で認証を使うのではなく、ユーザー識別程度でよい場合とかはありえるんじゃないですかね。
ヤマハタさんが例にだされた
> 開発用サイトに一般ユーザが迷い込んでこないようにブロックする。
とか、
サイト公開前に、あるコミュニティーにだけ限定公開するとか
守るべきデータはなにもないけど、サーバ負荷削減のためにユーザー数を限定したときとか、
性善説がなりたつ程度の人数のイントラネットでのグループウエアとか
サイト作っちゃったあとでユーザー限定したほうがいいかな程度のものとか
＃あまり具体的になってないけど（笑）
> 最低限、SSLが必須になりますよね？
”ある用途においては”その通りだと思います。
ただ、想定されている用途の範囲に違いがあるんだと思いますが
SSL程度では満足できないケースもありますよね。
IP制限とかクライアント証明書もつかうべきケースとか
トークンや生体認証を使う以外にも
登録された携帯のメールアドレスにワンタイムパスワード送るとか
紙のハッシュ票を配るとか
コストのかからない方法もあるでしょうし、そういうのもあわせ技として、使うべき用途もあるんじゃないですかねぇ。
沢山の方々のご意見とても参考になりました。
このトピを見てから、認証技術の「深さ」を
実感し、認証関係のサイトや本を読み返したりも
しました。
ＢＡＳＩＣ認証の脆弱性につきましては、
良く理解できました。
少しばかり、ＢＡＳＩＣ認証がいかに
脆弱であるかの議論から離れまして、
お題の答えを知りたくなりました。
それでは、このトピのお題に戻りまして
「ユーザＩＤ」「パスワード」をユーザに
入力させて、ユーザ認証し、
ログイン後の画面の「ようこそxxxxxさん！」を
表示してくれという、顧客要求に対して
ＢＡＳＩＣ認証の変わりに具体的に
どのような提案をするのが一番良いと思われますか？
もし皆さんが合意できる結論に達したら、
とても良いトピになりますよね。
（既に大変勉強になりましたが・・・）
では、これまでの皆さんの返信を参考に
私の提案から行ってみます。
身勝手ながら、不十分な点を補完して頂くことを
期待しております。
１．ログイン画面にＳＳＬを適用する。
２．ＢＡＳＩＣ認証は全く利用しない。
３．ログイン画面のフォームから入力された
ユーザＩＤ・パスワードをＤＢと照合し、
照合できた場合に、セッションを開始する。
但し、セッションにはクッキーを利用し、
セッションＩＤは、桁数などが不規則で
値がランダムなＩＤとなるように生成する。
セッションに期限を設ける。
４．ログイン認証を行ったあとの
「ようこそxxxxxさん！」の画面にはＳＳＬを
適用せず、セッションが有効かの確認を行う。
セッションが有効かどうかの確認は、
セッションがスタートしているかと
クライアントのＩＰアドレスが前回と同じかの
確認を行う。
不備な点は多々あると思いますが、
ご指摘お願い致します。
このトピを見てから、認証技術の「深さ」を
実感し、認証関係のサイトや本を読み返したりも
しました。
ＢＡＳＩＣ認証の脆弱性につきましては、
良く理解できました。
少しばかり、ＢＡＳＩＣ認証がいかに
脆弱であるかの議論から離れまして、
お題の答えを知りたくなりました。
それでは、このトピのお題に戻りまして
「ユーザＩＤ」「パスワード」をユーザに
入力させて、ユーザ認証し、
ログイン後の画面の「ようこそxxxxxさん！」を
表示してくれという、顧客要求に対して
ＢＡＳＩＣ認証の変わりに具体的に
どのような提案をするのが一番良いと思われますか？
もし皆さんが合意できる結論に達したら、
とても良いトピになりますよね。
（既に大変勉強になりましたが・・・）
では、これまでの皆さんの返信を参考に
私の提案から行ってみます。
身勝手ながら、不十分な点を補完して頂くことを
期待しております。
１．ログイン画面にＳＳＬを適用する。
２．ＢＡＳＩＣ認証は全く利用しない。
３．ログイン画面のフォームから入力された
ユーザＩＤ・パスワードをＤＢと照合し、
照合できた場合に、セッションを開始する。
但し、セッションにはクッキーを利用し、
セッションＩＤは、桁数などが不規則で
値がランダムなＩＤとなるように生成する。
セッションに期限を設ける。
４．ログイン認証を行ったあとの
「ようこそxxxxxさん！」の画面にはＳＳＬを
適用せず、セッションが有効かの確認を行う。
セッションが有効かどうかの確認は、
セッションがスタートしているかと
クライアントのＩＰアドレスが前回と同じかの
確認を行う。
不備な点は多々あると思いますが、
ご指摘お願い致します。
＞28 ginnezさん
＞えー、、、Basic認証を考えている時点で、DB利用は仕様に＞入っていないんじゃないかと思います。ので、
あれっ？
「ようこそxxxxxさん！」の
xxxxxのところは、元のお題の仕様でもＤＢから取ってくるんだと
思ってました。ユーザＩＤをそのまま
xxxxxに表示するってことですね。
しかしながら、ファイルでユーザを管理するとなると
運用面で大変そうです。
「ＤＢベースとすべきか
ファイルベースとすべきかという点までも
自由に提案者が選択できます。」
と、定義してご意見を頂けると
これまた、非常に興味深いのですが・・・
しかしながら、議論が発散しないように、
ファイルベースに限定しましょう！
27の「ＤＢ」は「ファイル」に読み替えて下さい。
＞えー、、、Basic認証を考えている時点で、DB利用は仕様に＞入っていないんじゃないかと思います。ので、
あれっ？
「ようこそxxxxxさん！」の
xxxxxのところは、元のお題の仕様でもＤＢから取ってくるんだと
思ってました。ユーザＩＤをそのまま
xxxxxに表示するってことですね。
しかしながら、ファイルでユーザを管理するとなると
運用面で大変そうです。
「ＤＢベースとすべきか
ファイルベースとすべきかという点までも
自由に提案者が選択できます。」
と、定義してご意見を頂けると
これまた、非常に興味深いのですが・・・
しかしながら、議論が発散しないように、
ファイルベースに限定しましょう！
27の「ＤＢ」は「ファイル」に読み替えて下さい。
トビのもともとのお題としては、htpasswdファイルでのBASIC認証ありきみたいなので
（用途的にBASIC認証で必要充分なものと判断されていると仮定するならば）
shimixさんによる
echo "ようこそ" . $_SERVR['REMOTE_USER'] . "さん！";
ということなんだと思いますが、
ある特定用途を想定して、考えて見ましょうということですよね。
特定用途を想定いうのは、
たとえば社内・学内のイントラシステムだと、大抵は外部アクセスの効率化とWebウィルスチェックのためにProxyを経由させるので、IPの一意チェック入れてもあまり意味がないとか
アカウント管理はメールアカウントやWindowsログインと連動させるのでDBやファイルでなくLDAPやNISを使うのでそういうケースは除外するとか、
ヤマハタさんの指摘されているような、ログイン画面さえ検索エンジンを含めてブロックさせたいとか
金融システムなど被害が多きなものは別ですよとか。
（逆にいうと、通信の傍受とクラック対策だけで考えればいいという用途ともいえるのかなぁ）
その前に、SSLで暗号化するのは前提として、
・すべてのPHPでHTTP認証(headerにBasicやDigetsと書いてブラウザに再送信を要求するもの）でいいのか
・独自の認証を初回のログインフォームでやらせて、残りは
セッションで引き継ぎsessionIDとクライアントIPで継続性チェックするか
・あわせ技で、暗号化sessionID+クライアントIPも確認するが、セッションハイジャック対策で毎回HTTP認証も行うべきか
の選択がまずくるのかなぁと思ったんですが、どうなんでしょう。
なお、ユーザーアカウント管理はファイルを前提にとのことですが、
パスワード３回間違えたらそのアカウントは無効
（管理者が身元確認のうえパスワード再発行で解除）
とかやりたかったらファイルよりもＤＢのほうが作りやすくないですかね。
アカウントごとにログイン時のIPアドレスを記憶させたいとか
ブラウザクラッシュなどでログアウトできなかったけど一定時刻後は再ログインできるように時刻を記憶させたいとか
するならなおさら。
あと（apacheでの）BASIC認証やDigest認証を使わない場合での
漏洩しては困る静的コンテンツの対策なんですが
・テンポラリを作って一定時間後にcronで掃除
・fileをスルーさせる認証つきのPHPを経由
しかやったことがないのですが、もっと効率のよいやり方があるですかね。
アイデアをお伺いしたいところです。
（用途的にBASIC認証で必要充分なものと判断されていると仮定するならば）
shimixさんによる
echo "ようこそ" . $_SERVR['REMOTE_USER'] . "さん！";
ということなんだと思いますが、
ある特定用途を想定して、考えて見ましょうということですよね。
特定用途を想定いうのは、
たとえば社内・学内のイントラシステムだと、大抵は外部アクセスの効率化とWebウィルスチェックのためにProxyを経由させるので、IPの一意チェック入れてもあまり意味がないとか
アカウント管理はメールアカウントやWindowsログインと連動させるのでDBやファイルでなくLDAPやNISを使うのでそういうケースは除外するとか、
ヤマハタさんの指摘されているような、ログイン画面さえ検索エンジンを含めてブロックさせたいとか
金融システムなど被害が多きなものは別ですよとか。
（逆にいうと、通信の傍受とクラック対策だけで考えればいいという用途ともいえるのかなぁ）
その前に、SSLで暗号化するのは前提として、
・すべてのPHPでHTTP認証(headerにBasicやDigetsと書いてブラウザに再送信を要求するもの）でいいのか
・独自の認証を初回のログインフォームでやらせて、残りは
セッションで引き継ぎsessionIDとクライアントIPで継続性チェックするか
・あわせ技で、暗号化sessionID+クライアントIPも確認するが、セッションハイジャック対策で毎回HTTP認証も行うべきか
の選択がまずくるのかなぁと思ったんですが、どうなんでしょう。
なお、ユーザーアカウント管理はファイルを前提にとのことですが、
パスワード３回間違えたらそのアカウントは無効
（管理者が身元確認のうえパスワード再発行で解除）
とかやりたかったらファイルよりもＤＢのほうが作りやすくないですかね。
アカウントごとにログイン時のIPアドレスを記憶させたいとか
ブラウザクラッシュなどでログアウトできなかったけど一定時刻後は再ログインできるように時刻を記憶させたいとか
するならなおさら。
あと（apacheでの）BASIC認証やDigest認証を使わない場合での
漏洩しては困る静的コンテンツの対策なんですが
・テンポラリを作って一定時間後にcronで掃除
・fileをスルーさせる認証つきのPHPを経由
しかやったことがないのですが、もっと効率のよいやり方があるですかね。
アイデアをお伺いしたいところです。
がるです。
To YamaHiroさん
個人を認証するのであれば、最低限PHPにあるsession関数郡＋DBか、または一式自作、もしくは既存のFrameworkにある認証クラス郡を用いるのがよろしいかと思います。
一番よいのは…Framework使用でしょうか。
To SAGさん
> セキュアな目的で認証を使うのではなく、ユーザー識別程度でよい場合とかはありえるんじゃないですかね。
これについてはYesだと思います。
ただ問題なのは、認証って単語使った瞬間に、なんでか「セキュアだ」と誤認される方が多くて…まぁいろいろと困ったこともありました(苦笑
なので、きちんとそのあたりが説明できて、かつ用途に合致してるなら、Basic認証もありだと思ってます。
で、静的コンテンツですが。
私はおおむね「fileをスルーさせる認証つきのPHPを経由」に近い方法で、プログラム制御を普通にしてます。
で…パラメタにpathを書かせるといろいろとアタックしやすいので。私はmap fileってのを用意してます。
To 幻夜祭
> このトピはBASIC認証についてでしょ？
> なんでセキュリティの話になるのでしょうか…。
Basic認証がセキュリティ的に危険なうえに、それを認識していないケースが多々あるから、です。
> 例えば１０名程度のサークルがあったとして、
> 部活動か何かの写真をＷｅｂ上に載せて共有したいとして、
> 運営者には一定のログ解析知識くらいはあったとして、
> このような用途でも皆様は本気のセキュリティ組むんですかね？
状況とクライアント要求と予算次第、ですね。
部活動の内容、メンバーの立ち居地、写真の性質などによっては、ある程度厳重なセキュリティが必要な可能性も否定できませんので。
あと。ログ解析は「もれたことを把握」できても「もれることを予防する」効果はありませんので念のため。
幻夜祭さんが認識されているいないではなく、文章的に「誤認される可能性」を感じたので(いろいろな方が読んでいる場所ですし)。
ケースbyケースという単語にしかならないのですが。とはいえ、その単語に寄りかかって無考察になるケースも少なくないので。
自戒もこめて、こういう議論は時々するようにしています。
以上私見と雑感で恐縮ですが。
To YamaHiroさん
個人を認証するのであれば、最低限PHPにあるsession関数郡＋DBか、または一式自作、もしくは既存のFrameworkにある認証クラス郡を用いるのがよろしいかと思います。
一番よいのは…Framework使用でしょうか。
To SAGさん
> セキュアな目的で認証を使うのではなく、ユーザー識別程度でよい場合とかはありえるんじゃないですかね。
これについてはYesだと思います。
ただ問題なのは、認証って単語使った瞬間に、なんでか「セキュアだ」と誤認される方が多くて…まぁいろいろと困ったこともありました(苦笑
なので、きちんとそのあたりが説明できて、かつ用途に合致してるなら、Basic認証もありだと思ってます。
で、静的コンテンツですが。
私はおおむね「fileをスルーさせる認証つきのPHPを経由」に近い方法で、プログラム制御を普通にしてます。
で…パラメタにpathを書かせるといろいろとアタックしやすいので。私はmap fileってのを用意してます。
To 幻夜祭
> このトピはBASIC認証についてでしょ？
> なんでセキュリティの話になるのでしょうか…。
Basic認証がセキュリティ的に危険なうえに、それを認識していないケースが多々あるから、です。
> 例えば１０名程度のサークルがあったとして、
> 部活動か何かの写真をＷｅｂ上に載せて共有したいとして、
> 運営者には一定のログ解析知識くらいはあったとして、
> このような用途でも皆様は本気のセキュリティ組むんですかね？
状況とクライアント要求と予算次第、ですね。
部活動の内容、メンバーの立ち居地、写真の性質などによっては、ある程度厳重なセキュリティが必要な可能性も否定できませんので。
あと。ログ解析は「もれたことを把握」できても「もれることを予防する」効果はありませんので念のため。
幻夜祭さんが認識されているいないではなく、文章的に「誤認される可能性」を感じたので(いろいろな方が読んでいる場所ですし)。
ケースbyケースという単語にしかならないのですが。とはいえ、その単語に寄りかかって無考察になるケースも少なくないので。
自戒もこめて、こういう議論は時々するようにしています。
以上私見と雑感で恐縮ですが。
30 SAG さん
＞その前に、SSLで暗号化するのは前提として、
・すべてのPHPでHTTP認証(headerにBasicやDigetsと書いてブラウザに再送信を要求するもの）でいいのか
＞・独自の認証を初回のログインフォームでやらせて、残りは
＞セッションで引き継ぎsessionIDとクライアントIPで継続性チェックするか
＞・あわせ技で、暗号化sessionID+クライアントIPも確認するが、セッションハイジャック対策で毎回HTTP認証も行うべきか
＞の選択がまずくるのかなぁと思ったんですが、どうなんでしょう。
なるほど大変勉強になりました。
自分のコメントでもＩＰの確認について記載していましたが
少し問題点を思い出しましたので補足します。
クライアントＩＰが動的に変わってしまって
ＩＰの確認処理を入れると上手く動かない例を
どこかで見たような気もしますが、
詳細忘れてしまいました。（すみません具体例がなくて）
32 kanosa さん
＞ファイルでもDBでも実現できればいいということなのかなと
そうですね。
SAG さんの言われているとおり、
実際はＤＢを利用することになりそうですが
どちらでも、実現できればいいということですね。
33 がる さん
＞To YamaHiroさん
＞個人を認証するのであれば、最低限PHPにあるsession関数郡＋DBか、または一式自作、もしくは既存のFrameworkにある認証クラス郡を用いるのがよろしいかと思います。
＞一番よいのは…Framework使用でしょうか。
そうですね。自作してしまうとリスクも大きいので
枯れたFrameworkを使うに越したことはないですね。
勉強になります。
コメント有難うございました。
＞その前に、SSLで暗号化するのは前提として、
・すべてのPHPでHTTP認証(headerにBasicやDigetsと書いてブラウザに再送信を要求するもの）でいいのか
＞・独自の認証を初回のログインフォームでやらせて、残りは
＞セッションで引き継ぎsessionIDとクライアントIPで継続性チェックするか
＞・あわせ技で、暗号化sessionID+クライアントIPも確認するが、セッションハイジャック対策で毎回HTTP認証も行うべきか
＞の選択がまずくるのかなぁと思ったんですが、どうなんでしょう。
なるほど大変勉強になりました。
自分のコメントでもＩＰの確認について記載していましたが
少し問題点を思い出しましたので補足します。
クライアントＩＰが動的に変わってしまって
ＩＰの確認処理を入れると上手く動かない例を
どこかで見たような気もしますが、
詳細忘れてしまいました。（すみません具体例がなくて）
32 kanosa さん
＞ファイルでもDBでも実現できればいいということなのかなと
そうですね。
SAG さんの言われているとおり、
実際はＤＢを利用することになりそうですが
どちらでも、実現できればいいということですね。
33 がる さん
＞To YamaHiroさん
＞個人を認証するのであれば、最低限PHPにあるsession関数郡＋DBか、または一式自作、もしくは既存のFrameworkにある認証クラス郡を用いるのがよろしいかと思います。
＞一番よいのは…Framework使用でしょうか。
そうですね。自作してしまうとリスクも大きいので
枯れたFrameworkを使うに越したことはないですね。
勉強になります。
コメント有難うございました。
> クライアントＩＰが動的に変わってしまって
> ＩＰの確認処理を入れると上手く動かない例
あ、確かにモバイルでハンドオーバーさせたり
NATルータでLAN型接続すると、コネクション毎に違う外部IPでコネクションされたりすることがあるかも知れないです。
httpのコネクションは行って返ってで終わりですから、
ルータにとっては次のコネクションのことなんかは、しったことじゃないですもんね。
ところでちょっと気になっている点があるので、
明るいかた教えてください。
（ドキュメント読んでもフォーカスが違うのか、それらしいものにあたらないので）
sessionIDがランダムで充分にユニークでかつIPを連結させて、寿命を短くし、さらに暗号化していたとします。
その暗号化と復元処理はどこで行うことになるのでしょう？
いや、通常のセッションなら、sessionIDを受け取ったブラウザはそのままcookieなりに記憶されて、それをまたそのままサーバーに戻すことになりますよね。
ブラウザ側でやるのはこれと同じままで、
サーバーで暗号化してそれをそのままブラウザとやり取りして受け取ったサーバーが復元しているだけあれば、
結局その暗号化されたsessionIDをそのまま偽装すればXSS可能にならないかなというのが気になるのです。
（サーバーのtmpにできるsessionファイル名は隠蔽できても）
もしかして、ブラウザ内でcockieデータを暗号化してサーバーに送り返すとか、
反対に暗号化済みのもの受け取ってブラウザで復元して戻すといったことをやらせているでしょうか？
またmixiの例で恐縮ですが、たしかmixiのセッションをXSSで乗っ取って、勝手に日記を書くワームがでたことがありましたよね。
なので、通信の傍受と同様に、XSS対策も重要な気がしてるんです。
> ＩＰの確認処理を入れると上手く動かない例
あ、確かにモバイルでハンドオーバーさせたり
NATルータでLAN型接続すると、コネクション毎に違う外部IPでコネクションされたりすることがあるかも知れないです。
httpのコネクションは行って返ってで終わりですから、
ルータにとっては次のコネクションのことなんかは、しったことじゃないですもんね。
ところでちょっと気になっている点があるので、
明るいかた教えてください。
（ドキュメント読んでもフォーカスが違うのか、それらしいものにあたらないので）
sessionIDがランダムで充分にユニークでかつIPを連結させて、寿命を短くし、さらに暗号化していたとします。
その暗号化と復元処理はどこで行うことになるのでしょう？
いや、通常のセッションなら、sessionIDを受け取ったブラウザはそのままcookieなりに記憶されて、それをまたそのままサーバーに戻すことになりますよね。
ブラウザ側でやるのはこれと同じままで、
サーバーで暗号化してそれをそのままブラウザとやり取りして受け取ったサーバーが復元しているだけあれば、
結局その暗号化されたsessionIDをそのまま偽装すればXSS可能にならないかなというのが気になるのです。
（サーバーのtmpにできるsessionファイル名は隠蔽できても）
もしかして、ブラウザ内でcockieデータを暗号化してサーバーに送り返すとか、
反対に暗号化済みのもの受け取ってブラウザで復元して戻すといったことをやらせているでしょうか？
またmixiの例で恐縮ですが、たしかmixiのセッションをXSSで乗っ取って、勝手に日記を書くワームがでたことがありましたよね。
なので、通信の傍受と同様に、XSS対策も重要な気がしてるんです。
皆様、具体的な方法、いろいろとお教えいただき、
本当にありがとうございます！！！！感謝でつっ！！！
お教えいただいた、PHPのBASIC認証を使う場合、
すべてのPHPファイルに、
同様の記述を書く必要があるような気がします。（＞0＜）
.htaccessに記述すれば、そのディレクトリ以下、
ぜーんぶに、ベーシック認証できちゃうので、
PHPのBASIC認証は、
最終的には使えないと判断されました。（鬼先輩に…）
「うまくいったー！！！！」って自慢げに報告したんスけどね（＾＾；）ｖ
.htaccessのBASIC認証を使って、
IDごとの処理をするのは難しいですよね。。。
非常に残念ナリなぁ。ｑ（・_・；）ｐ
皆様、ご回答、ありがとうございましたぁ〜♪
いろいろ勉強になりました！
まだまだ修行が足りない女なので、
やさしい目で見守ってくだつぁい。宜しくっすｖ
みな
本当にありがとうございます！！！！感謝でつっ！！！
お教えいただいた、PHPのBASIC認証を使う場合、
すべてのPHPファイルに、
同様の記述を書く必要があるような気がします。（＞0＜）
.htaccessに記述すれば、そのディレクトリ以下、
ぜーんぶに、ベーシック認証できちゃうので、
PHPのBASIC認証は、
最終的には使えないと判断されました。（鬼先輩に…）
「うまくいったー！！！！」って自慢げに報告したんスけどね（＾＾；）ｖ
.htaccessのBASIC認証を使って、
IDごとの処理をするのは難しいですよね。。。
非常に残念ナリなぁ。ｑ（・_・；）ｐ
皆様、ご回答、ありがとうございましたぁ〜♪
いろいろ勉強になりました！
まだまだ修行が足りない女なので、
やさしい目で見守ってくだつぁい。宜しくっすｖ
みな
> すべてのPHPファイルに、
> 同様の記述を書く必要があるような気がします。（＞0＜）
そりゃそうなんですが、include('認証実行ファイル');の１行だけですし・・・
それさえも漏れそうだというレベルの話なら、
htpasswdのBASIC認証の方が、はるかに安全かもしれませんね（汗）
> .htaccessのBASIC認証を使って、
> IDごとの処理をするのは難しいですよね。。。
そんなことはないです。
すでに何度もでてきてますが、
$_SERVER['REMOTE_USER']に、そのIDが入っていますから
あとはそのIDをキーにして
名前なり、メールアドレスなり、その人のプロフィールなり
そのシステムで欲しているデータに変換すればよいだけのことなんで。
その変換テーブルをどう用意するかは
そのデータをどうやって入手してどう記憶させているかの仕様次第です。
> 同様の記述を書く必要があるような気がします。（＞0＜）
そりゃそうなんですが、include('認証実行ファイル');の１行だけですし・・・
それさえも漏れそうだというレベルの話なら、
htpasswdのBASIC認証の方が、はるかに安全かもしれませんね（汗）
> .htaccessのBASIC認証を使って、
> IDごとの処理をするのは難しいですよね。。。
そんなことはないです。
すでに何度もでてきてますが、
$_SERVER['REMOTE_USER']に、そのIDが入っていますから
あとはそのIDをキーにして
名前なり、メールアドレスなり、その人のプロフィールなり
そのシステムで欲しているデータに変換すればよいだけのことなんで。
その変換テーブルをどう用意するかは
そのデータをどうやって入手してどう記憶させているかの仕様次第です。
38 SAG さん
＞あ、確かにモバイルでハンドオーバーさせたり
＞NATルータでLAN型接続すると、コネクション毎に違う外部IPでコネクションされたりすることがあるかも知れないです。
＞httpのコネクションは行って返ってで終わりですから、
ルータにとっては次のコネクションのことなんかは、しったことじゃないですもんね。
やっぱり、セッション管理でIPを確認することにも問題が残りますね〜
例示有難うございます。
＞通信の傍受と同様に、XSS対策も重要な気がしてるんです。
暗号化等々、明るくは無いのですが・・・
通信傍受とXSS対策は別に考えないといけないのでは
ないでしょうか？
暗号化は、通信傍受の対策に有効だと思います。
盗聴に対しては、HTTPS以外に現在有効な対策は
無いと言い切っている雑誌記事もありましたが・・・
盗聴対策とは別に、XSS対策として、
例えば、入力フォームに
ランダムなワンタイムチケットを
非表示で埋め込んでおいて、POSTします。
POSTを受け取ったサーバでは保持していた
ワンタイムチケットを照合するとかでは
だめなんでしょうか？
＞あ、確かにモバイルでハンドオーバーさせたり
＞NATルータでLAN型接続すると、コネクション毎に違う外部IPでコネクションされたりすることがあるかも知れないです。
＞httpのコネクションは行って返ってで終わりですから、
ルータにとっては次のコネクションのことなんかは、しったことじゃないですもんね。
やっぱり、セッション管理でIPを確認することにも問題が残りますね〜
例示有難うございます。
＞通信の傍受と同様に、XSS対策も重要な気がしてるんです。
暗号化等々、明るくは無いのですが・・・
通信傍受とXSS対策は別に考えないといけないのでは
ないでしょうか？
暗号化は、通信傍受の対策に有効だと思います。
盗聴に対しては、HTTPS以外に現在有効な対策は
無いと言い切っている雑誌記事もありましたが・・・
盗聴対策とは別に、XSS対策として、
例えば、入力フォームに
ランダムなワンタイムチケットを
非表示で埋め込んでおいて、POSTします。
POSTを受け取ったサーバでは保持していた
ワンタイムチケットを照合するとかでは
だめなんでしょうか？
> 通信傍受とXSS対策は別に考えないといけないのでは
> ないでしょうか？
たしかに、おっしゃるとおりですね。
いや、BASIC認証はセキュアではないという話の流れから、
ではSSLし独自の認証システムを作って通信傍受対策をすれば
セキュアといえるのだろうかという論点だったんです。
とくにsessionIDだけで継続チェックしていると
運用トータルで考えると、逆に弱くなるケースもあるのかもしれないのではと。
>盗聴に対しては、HTTPS以外に現在有効な対策は
>無いと言い切っている雑誌記事もありましたが・・・
パスワードのみに関していえば、チャレンジ/レスポンスのDigest認証でパスワードを秘匿するという方法もあるのだと思います。
それの応用で、sessionIDを秘匿するというソルーションがもしかして、存在するのかなと。。。
もちろんDigest認証と同様に、ブラウザがそれに対応していないといけないでしょうから、難しそうですね。
それに、たとえ、sessionIDを秘匿できたって、
結局ブラウザにセキュリティーホールがあれば、
IDや生パスワードや生sessionIDごと、XSSやワームでやられてしまうので、私のいっていることは自己矛盾してますね(笑）
＞ワンタイムチケットを照合するとかでは
たしかに！そういう方法ありますね！
一度つかったら二度と使えないチケットですね。
サイトのナビゲーションとして、ブラウザで「戻る」とか、
別ウインドウを開いて分岐してさらに本筋に戻るといったナビゲーションかなければ、シンプルにつくれそうですね。
逆に複雑なナビゲーションのあるサイトだと
照合も、それなり複雑になりそうな気がしますので
汎用モデリングする部分が、やっかいそうですが。
あまりゆるくすると、のっとり対策にならないでしょうし。
> ないでしょうか？
たしかに、おっしゃるとおりですね。
いや、BASIC認証はセキュアではないという話の流れから、
ではSSLし独自の認証システムを作って通信傍受対策をすれば
セキュアといえるのだろうかという論点だったんです。
とくにsessionIDだけで継続チェックしていると
運用トータルで考えると、逆に弱くなるケースもあるのかもしれないのではと。
>盗聴に対しては、HTTPS以外に現在有効な対策は
>無いと言い切っている雑誌記事もありましたが・・・
パスワードのみに関していえば、チャレンジ/レスポンスのDigest認証でパスワードを秘匿するという方法もあるのだと思います。
それの応用で、sessionIDを秘匿するというソルーションがもしかして、存在するのかなと。。。
もちろんDigest認証と同様に、ブラウザがそれに対応していないといけないでしょうから、難しそうですね。
それに、たとえ、sessionIDを秘匿できたって、
結局ブラウザにセキュリティーホールがあれば、
IDや生パスワードや生sessionIDごと、XSSやワームでやられてしまうので、私のいっていることは自己矛盾してますね(笑）
＞ワンタイムチケットを照合するとかでは
たしかに！そういう方法ありますね！
一度つかったら二度と使えないチケットですね。
サイトのナビゲーションとして、ブラウザで「戻る」とか、
別ウインドウを開いて分岐してさらに本筋に戻るといったナビゲーションかなければ、シンプルにつくれそうですね。
逆に複雑なナビゲーションのあるサイトだと
照合も、それなり複雑になりそうな気がしますので
汎用モデリングする部分が、やっかいそうですが。
あまりゆるくすると、のっとり対策にならないでしょうし。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
