This is a bug, but not a vulnerability, as there is no exploit.
It may be possible for a logged-in user to send his or her own
cookie to a website of his or her choice, by cleverly concocting
an email address with quote and angle bracket. But the user had
to have his or her own cookie already, to be logged-in, so there
is no new information revealed, and no escalation of privileges.
[SA-2002:01] Slashcode login vulnerability
RISK FACTOR: HIGH
The attacker can then take over the user's account. If the user is
an administrator of the victim Slash website, the attacker can take
nearly full control of that site (post and delete stories, edit
users, post as other users, etc.).
/.は大丈夫? (スコア:1)
ここ(slashdot)もPerlを使っていると思いますが、対策は十分なのでしょうか?
>そのうちどれほどがこういう対策に労力を割いているんでしょうか。
という言
Re:/.は大丈夫? (スコア:1)
/.-J [srad.jp](いや、OSDN Japanもか?)の対応がかなりアレゲな気がするのは私だけでしょうか。
やぱし、直したらちゃんと皆さんへお詫びと説明をしないといけないとおもいます。 [osdn.co.jp]
Re:/.は大丈夫?(-1:flamebeit) (スコア:0)
という疑いを拭いきれない。
/.-Jにご執心のようですね。
#Tea Roomは毎日拝見しております。
Re:/.は大丈夫?(-1:flamebeit) (スコア:1)
SourceForge の見られ方とか、責任分岐点のあり方とか、
かなりの意識の違いがあるとしか思えない。
/.-Jも/.もスクリプトを前提としてはいないでしょ。
「なもの、ブラウザの責任だ」といいたいに違いない。
勝手にデータを渡すのは、ブラウザだよ?
Re:/.は大丈夫? (スコア:3, 参考になる)
(それ以前にも、 パターンA [sourceforge.net]、 パターンB [sourceforge.net]、 パターンC [sourceforge.net] と3回も指摘があったにもかかわらず。さらに言うと、jbeefがslashdot.jpに連絡した2件 [srad.jp]はこれらとも別パターンなので、少なくとも5パターンが過去にあったのかな。)
そして、その修正から6時間後、さらに新たにクロスサイトスクリプティング脆弱性が指摘 [sourceforge.net]されています。 このときようやく問題点を正しく理解なさったようで、このときは、
という反応があり、そして、 ご本人からBUGTRAQへ報告がなされる [securityfocus.com]こととなったようです。 取り急ぎ訳: