パスワードを忘れた？ アカウント作成
Close
2526 story

/.J の XSS 対策 13

ストーリー by tach
ご迷惑をおかけしました 部門より
近頃巷を賑わせている XSS（クロスサイトスクリプティング）問題だが， /.J でもいくつかの脆弱性が発見されている．そのたびに修正してきた のだが，付け焼き刃の対策では根本的な修正にならないと考え，コード に手を入れ，問題が起きにくいように修正した．

いままで危険をさらしながら運用してきたことで，ユーザのみんなには 謝らないといけない．これからも /.J をよろしく．

対策の内容はおおまかにいうと以下の 2 点だ．
  • フォームからの値を読むときは，デフォルトでエスケープする．ただし，HTML 入力を行うものだけは例外．
  • テンプレートの見直しをして，危険そうなところにフィルタを挿入．

フォームからの入力をチェックすることで，ほとんどの問題を回避 できる．そもそも，クロスサイトスクリプティングはフォームから の入力に問題がある場合がほとんどなので，この対策はかなり有効 だと思われる．

また，出力時にフィルタをかますことによって，入力チェックと あわせて 2 重の対策が施されることになる．これで，ほとんどの クロスサイトスクリプティングを防ぐことができるだろう．

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

/.J の XSS 対策 More

  • お疲れさまです (スコア:2, 興味深い)

    by office (5894) <office@ukky.net> on 2002年03月14日 4時08分 (#71511) ホームページ 日記
    最後まで確認されていた脆弱点の２ヶ所も、先ほど修正されたことを確認しました。

    slashdot.jpやosdn.jpの皆様とはかなり激しい論争？までさせて頂きました。お騒がせして申し訳ありませんでした。

    slashdot.jpがメディアとして信じることができないかも？というような面まで突っ込みを入れましたが、個人的にはその点に関しても最終的には納得のいく反応を得られました。

    私はコーディングのことはさっぱりわかりませんが、ITセキュリティマネジメント的には信頼できる体制になったように確信しています。

    今後とも宜しくお願いします。(_o_)
    --
    office

  • 入出力のエスケープ (スコア:2, すばらしい洞察)

    by who-am-i (2922) on 2002年03月14日 11時29分 (#71595)

    フォームからの入力をチェックすることで，ほとんどの問題を回避できる．そもそも，クロスサイトスクリプティングはフォームからの入力に問題がある場合がほとんどなので，この対策はかなり有効だと思われる．

    Web開発者のみなさん、間違ってもこれがXSS対策の全てだとは思わないように!

    ここ [ryukoku.ac.jp]でも言われているように、エスケープの必要の有無は、本来は出力時に決定されるわけです。

  • セクションにクッキーのパスが通るようにもなりましたね。
    書き込めなくなる問題も直ったかしら？こちらは書き込めなくならないと検証できないけれども。

    #オーバーホールお疲れさま。＞tachさん

  • q 要素 (スコア:1)

    by ill (3048) on 2002年03月14日 16時54分 (#71685)

    微妙にオフトピ気味ですが微妙に話題的に近いので便乗して:)

    現在では、投稿をする時に HTML の blockquote は使用できるのですが、 q は使用できない(たぶん)ですよね。

    これって利用できるようになりませんかね。微妙に不便なので。

    --
    っと・・・。

    • Re:q 要素 (スコア:1)

      by tix (7637) on 2002年03月15日 17時42分 (#72137) ホームページ
      あまり説得力のある答えではないのですが、ぼくの予想では q 要素は IE （など？）で引用符が表示されず混乱の元になるため使えないのだと思います（ここ [blooberry.com]には HTML の要素のブラウザごとの挙動がまとめられており、参考になります）。

      だったら（一部の？）テキストブラウザだと i 要素が無視されたりして混乱しないのかというと、そこは引用符が表示されたりされなかったりよりは混乱が少ないということで……。だめですか？
      --
      鵜呑みにしてみる？
      シェア
      親コメント
  • なんか偉そうなサブジェクトですが。

    > 付け焼き刃の対策では根本的な修正にならないと考え，コードに手を入れ，問題が起きにくいように修正した．
    というような、信頼するに足る一定のポリシーでメンテナンスが行われていること

    及び

    「問題があったので修正を行った（あるいは、問題があるのでこうやって回避して欲しい）」ということがユーザーに随時告知されること

    が、とても重要だと思います。個人的には、特に、ユーザーへの告知が適切に行われないサービスは安心して使うことができません。安全かどうか、もさる事ながら、安全であるかどうかに運営サイドが留意しているかどうか、が見えないと不安です。
    そういう観点から、このような告知が行われたことで、/.Jを安心して利用することが出来ると思えるようになりました。ありがとうございます。

  • で、もちろん (スコア:0)

    by Anonymous Coward on 2002年03月14日 8時26分 (#71529)
    開発元へフィードバックしますよね？
    • 私がslashdot.jpさんから聞いた限りでは、「最後まで残っていた２ヶ所」というのはslashdot.jp特有の問題だったそうです。何故ここに脆弱性が残ることになったかというこれまでのChange Log分析もなされたようです。

      で、(slashdot.jpでも用いられている）slashcodeの最新版についても調査されているそうで、これについては問題箇所はもうなさそうだ ということでした。

      ただ、現実にはslashcode 2.0系列？など独立に維持されているバージョンがあるとも聞いてます。
      それらについてはどの程度コードが見直されているかどうかはわかりません。

      --
      office
      シェア
      親コメント

    • Re:で、もちろん (スコア:0)

      by Anonymous Coward
      開発元へフィードバックしますよね？
      ハァ？ なんで掲示板ユーザが開発元に連絡せにゃならんのだ？
      • 経緯がわからないと、なんだかさっぱり分からないですよね。

        slashdot.jp(osdn.jp)「掲示板ユーザが自分で開発元に連絡するのが筋」
        office「掲示板ユーザが開発元に連絡せにゃならんのだ？」

        ってのが論点の一つだったのです。ここ暫くその論争で、
        slashdot.jp上、私の掲示板上、メール、あげくの果てには2ch上でそれぞれの主張があり、このほど収まった次第です。

        「掲示板ユーザが開発元に連絡しなければならない、ということはない」
        というのが結論です。
        --
        office
        シェア
        親コメント
        • 「掲示板ユーザが開発元に連絡しなければならない、ということはない」
          その結論は、どこを見れば確認できるのでしょう？
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall