アカウント名:
パスワード:
という2種類ですよね。 前者に付いては、要は「Cookieを盗まれても大丈夫」な仕組みにしておけば問題ない。 たとえば、セッションキーをCookieで保持するようにしているのであれば、そのセッションキーを生成する時にクライアントのIPアドレスを含むデータをMD5して作るとかすれば、他のIPアドレスからのセッションハイジャックは検出できる。
Proxy通してると同一IPになっちゃう可能性もあるけど、クライアントが自分でProxyを通すようにしているのであれば、それはクライアントの責任だし、一部CATV局みたいに、強制的にProxy通させているような場合はCATV局の責任。企業とかでFireWall通っている場合にはその企業の責任。
あと、CATVで同一IPアドレスになるのはProxyを強制しているからではなく、IP Masqueradeでプライベートアドレスを使わせているからだね。
あと、IPアドレスの完全一致でチェックするようにすると企業ユーザが使えなくなる(複数台のProxyサーバで負荷分散しているためにコネクションごとにIPアドレスが変わる)ことが多いのが現実だから、アドレスの最下位を無視するなどして幅を持たせてチェックせざるを得ない。となると、同じプロバイダにダイヤルアップしている者からの攻撃が防げなくなる。
素人はすっこんでたほうがいいよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
XSSで引き起こされる被害 (スコア:1, すばらしい洞察)
という2種類ですよね。
前者に付いては、要は「Cookieを盗まれても大丈夫」な仕組みにしておけば問題ない。
たとえば、セッションキーをCookieで保持するようにしているのであれば、そのセッションキーを生成する時にクライアントのIPアドレスを含むデータをMD5して作るとかすれば、他のIPアドレスからのセッションハイジャックは検出できる。
Re:XSSで引き起こされる被害 (スコア:1)
あと、CATVで同一IPアドレスになるのはProxyを強制しているからではなく、IP Masqueradeでプライベートアドレスを使わせているからだね。
あと、IPアドレスの完全一致でチェックするようにすると企業ユーザが使えなくなる(複数台のProxyサーバで負荷分散しているためにコネクションごとにIPアドレスが変わる)ことが多いのが現実だから、アドレスの最下位を無視するなどして幅を持たせてチェックせざるを得ない。となると、同じプロバイダにダイヤルアップしている者からの攻撃が防げなくなる。
素人はすっこんでたほうがいいよ。
Re:XSSで引き起こされる被害 (スコア:1)
> IP Masqueradeでプライベートアドレスを使わせているからだね。
もちろんそういう場合もありますが、トランスペアレントキャッシュで proxy を強制している場合もありますね。
Re:XSSで引き起こされる被害 (スコア:0, フレームのもと)
Re:XSSで引き起こされる被害 (スコア:1)