アカウント名:
パスワード:
ユーザがフラッシュをアップロードできて、かつサーバ管理者がそのフラッシュが機能するように object タグやら embed タグやらを付けて表示するようにしてると危険ってことでしょ?
Flash が危険なのか、サーバ管理者が危険なのか。
対策と
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
もうここまでくるとよくわからん (スコア:0)
ユーザがフラッシュをアップロードできて、かつサーバ管理者がそのフラッシュが機能するように object タグやら embed タグやらを付けて表示するようにしてると危険ってことでしょ?
Flash が危険なのか、サーバ管理者が危険なのか。
対策と
そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
正しくWebアプリケーションを組んで運用していれば、Cookieを盗まれようがJavaScriptを実行されようが何も問題が起きないのに、粋がってXSS話が飛び交うここ半年(とくにここ数カ月)に凄く違和感を感じています。
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
たとえばSlashdotではID/Passwordの認証後はCookieの値で認証してますが、仮にこのCookieを第三者が取得して利用しても、引き出せる情報は何ら致命的なものはありません。せいぜい本当のメールアドレスぐらいですが、これが表に出ても問題になりません。問題になるのは問題のある行動を行っている人だけですから。
# 「匿名性」が売りな仕組みなんかは相手にしないので知りません。
# と言いつつACで書いてるオレ。
仮にNet銀行とか重要っぽい情報を扱わなければいけない場合で且つCookieにSession idを含ませたい場合は、Session idを毎回検証すべきです。具体的な検証方法としてはアクセス元のIP addressとSession idのハッシュ値を埋め込み検証に使用すること等があげられます。
マルチホームなネットワークからのアクセスで、たびたび出口のアドレスが変わるから不可能、とよく問題にされますがそもそもそういうネットワークがどれだけ存在するかリサーチした結果なのか謎です。
# 「マルチホーム = 出口のアドレスが変わる」ってのは間違い。
また、マルチホームなネットワークユーザへの対処として、予めGatewayのアドレスを複数登録できる仕組みを用意すれば十分です。
他にも手段はあると思いますよ。少なくともフレームワークが用意してくれるセッション管理の仕組みにおんぶにだっこな人たちには想像できない部分かも知れませんが。
# 本来クライアント証明書などを導入させるべきなんですが、
# 「ユーザの利便性」という神話に負けて導入できてないところばっかですな。
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:1)
> 且つCookieにSession idを含ませたい場合は、Session idを毎回
> 検証すべきです。具体的な検証方法としてはアクセス元のIP
> addressとSession idのハッシュ値を埋め込み検証に使用するこ
> と等があげられます。
Cookie が盗めるなら IP address も同時に盗めますが?
source IP spoofing では、情報を盗む系は実現出来ないけど、
情報更新系の攻撃は成立しそうな。
また、
> マルチホームなネットワークからのアクセスで、たびたび出口の
> アドレスが変わるから不可能、とよく問題にされますがそもそも
> そういうネットワークがどれだけ存在するかリサーチした結果な
> のか謎です。
:
> また、マルチホームなネットワークユーザへの対処として、予め
> Gatewayのアドレスを複数登録できる仕組みを用意すれば十分です。
IPアドレスが毎回変わりうることも問題ではありますが、別の人間が
同一IPでアクセスしうるケースが多いことのほうが問題と思ってます。
そういう場所からアクセスすれば、IP spoofing なしで乗っ取りが可能です。
たとえば社内のむかつくあいつのセッションをハイジャックしてやろう、とか。
アクセス制御方式が分かって、Cookie や BASIC認証情報のような
クライアントを識別するための情報が盗まれたら、どうしたって
攻撃手段が残ると思いますが?
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
> source IP spoofing では、情報を盗む系は実現出来ないけど、
> 情報更新系の攻撃は成立しそうな。
そもそもTCPのコネクションが確立しないって罠
ってゆーかTCP Wrapperその他の存在意義は何処。
後半はもはや壱アプリケーションの問題ではなくなっている罠
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
ってこれも既にFlashが云々の話じゃなくなってる罠...
まぁ+SSL組み合わせればいいんじゃないの?
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:1)
オフトピックすまんです_o_。
「そもそもXSSを「脆弱性」とするのがヘン」に対する反論だったもので。この時点でオフトピック化してるわけで。
> まぁ+SSL組み合わせればいいんじゃないの?
まだSSLの知識が万全じゃないのであれですが、サーバ証明だけじゃ、
前コメントの後半のパターンは防げないですよね?
SSLセッションIDを常にチェックしていればいいわけですけど、
*ずっと*張りっぱなしなんですっけ?
ま、いいか。また調べます_o_。
XSSはともかくとして、ブラウザのバグで漏れることを考えると、
開発者側としては、「盗まれて当たり前」な意識も必要とは思う。
でも、盗まれない保証がないと完全な防御も出来ないと
今のところ思っている。なのでBASIC認証+SSL推奨。ということで。
あと、ページ挿げ替えとか出来る点についてはどうなのかなぁ?
既に過去のトピックで議論されてることだからいまさら
突っ込まなくてもいいか…。
というわけでこの話題終わり_o_。
Re:そもそもXSSを「脆弱性」とするのがヘン (スコア:0)
> 問題になりません。問題になるのは問題のある行動を行っている
> 人だけですから。
当人にとって何が漏れたら困る情報なのかは、あなたが決めることではない。実務経験のある人ならこんな事言えないはずだよね。
> たびたび出口のアドレスが変わるから不可能、とよく問題にされ
> ますがそもそもそういうネットワークがどれだけ存在するかリサ
> ーチした結果なのか謎です。
リサーチもなにも、現に事実じゃん。例えば富士通からのアクセスは
t3.fujitsu.co.jp
t2.fuji