@nifty掲示板に重大なXSS脆弱性が発覚 63
ストーリー by Oliver
ユーザ入力は一切信じるな 部門より
ユーザ入力は一切信じるな 部門より
Anonymous Coward曰く、"日経IT Proが伝えるところによると、@niftyの掲示板にクロスサイトスクリプティング(XSS)脆弱性が見つかり、緊急メンテナンス中だとのこと。記事によると、@niftyの掲示板ではHTMLのタグを自由に書けるようになっていたとのことで、スクリプトを動かすタグを書けてしまったようだ。スラッシュドットでもタグは書けるが、安全なものしか使えないように制限されているわけで、いまどき自由にタグを使えたとは信じがたい。記事によると、広報室は、10カ月以上にわたって問題の存在に気付かなかったと答えているそうだ。"
参考サイト (スコア:4, 参考になる)
Re:参考サイト (スコア:0)
とありますね。何ともはや。
担当者にそれなりの教育をってのもありますが、情報が判断可能な然
パソコン通信風土 (スコア:1, すばらしい洞察)
あそこって、パソコン通信時代の遺産(機材とかではなく管理体制とか人的な面)が多く残っていますから。
WebフォーラムもTTYフォーラムとWeb掲示板系を変な形で融合した結果、インターウェイ以上にやたら使いにくくて中途半端です。
そういうわけで、今はThe Netに移行するための産みの苦しみなのかもしれません。
Re:参考サイト (スコア:0)
しゃちょーの理解があるんなら、外注すればいいんでは?
マトモな業者を見つけるのが大変かもしれませんが。
エンジニアの質が低すぎるのでは (スコア:3, 興味深い)
楽天日記の場合、タグのサニタイジングは要素名で判断、Javascript対策は全文検索をかけて半角文字でdocumentのような javascriptで使われる文字列が見つかると危険と判断しているようです。ユーザーも困っているようで苦情書き込みも見つけました。半年前まで興味深く見守り何度か間接的に注意を投げましたがこんな状況です。
楽天日記はログインしたままでユーザー間の日記を往復しているユーザーが多く、また奪ったアカウントは買い物や個人情報のアクセスにも使えるためセッションを奪えるとなかなか便利に使えます。
１年前はJavascriptもばんばん使える状態で、そこから継ぎ接ぎの改良を重ねてやっとこの状態。
方法論間違えた無駄な努力。小学校なら「よくがんばりましたで賞」を上げますが、この場合は無能のレッテルを貼る以外に術無し。
開発に当たるチーム/個人の基本性能が不足しているように思えます。
大手で知っているのは楽天くらいですが、他にもトップページや検索ボックスはさすがにサニタイジングしているものの hidden 要素で指定されている値を偽装してやると一発で壊れたり、問題のあるサイトは山ほどあります。コーヒーのブルックスも注文画面の一部でXSSが成立しますし、まぁ日常利用するサイトの大半、特に中堅に位置し大手のように識者からのチェックが入っていない割にユーザーを抱えているところとか恐ろしい話になっています。
某MLでもFAQ気味の質問に対してセキュリティ的にヤバい返答が入り古老があわててフォローに入るといった場面も最近になって見受けられるようになりました。
つい最近発見したXSS、、というか一切のサニタイジングを考慮しておらずGETメソッドからSQLクエリが投げれるように見えるサイトはMLの投稿歴から察するに言語歴が最低でも3年あり、現在は某ベンチャーのトップエンジニア兼社長をやっている人がコードを書いていたりします。
XSSのような危険性を持つサイトの大半はそれを指摘したり間を置いて試すと一見修正が入ったように見えるのですが突っ込んで調べるとぼろぼろ不具合が出てきます。開発者に然るべき能力が欠如しているとしか思えません。
動けばいい だけのプログラムが随分と増えてきたように思います。
また開発を指揮管理する層や発注者、リスクヘッジすべき部署にいる人や経営者の大半の認識も「動いたらそれでええんとちゃうんかい」なレベルに止まっているように思えてなりません。
Re:エンジニアの質が低すぎるのでは (スコア:3, 興味深い)
受けることになりました。
最初は、うざったいと思っていたのですが、蛇の道はヘビというか
もちはもちやというべきか、結構自信を持っていたのにボコボコに
されました。
決して安いものはないのですが、その道の第３者に診断して
もらうのはそれだけの価値があると思いますが。
Re:エンジニアの質が低すぎるのでは (スコア:2, 参考になる)
# 眠気に任せて暴走中
Re:エンジニアの質が低すぎるのでは (スコア:2, 参考になる)
関係者とお見受けします。私の知ってる人かも知れませんね。お疲れ様です。
スレ元の楽天は調べたことがありませんが、MyYahoo!のシステムも酷いもんでした。一々報告してられません。利用してるわけでもないし。
tcupも昔はとても素早く対応してくれたのですが、今や報告しても完全に無視されたままです。
掲示板の記事にタグが書き込めるとまずいということは、XSSの概念が知られるよりずっと以前から判っていたことですし、危険性は非常に高いです。
ブラウザのバグをついてPCに感染するJavaScriptで記述可能なウイルスなどもありますし、また、掲示板そのものを媒介として、掲示板を渡り歩くウイルスというのも可能です。
さらに、他サイト（１サイトとは限らない）の攻撃コードを、掲示板読者に密かに踏ませ、自分は手を汚さずに、対象サイトを停止させたり、時にはBackDoorを仕掛けさせたりすることも可能です。
office
エンジニアは一般職？ (スコア:1, 興味深い)
毎日就職ナビにセッション乗っ取りの脆弱性があります。
一応、指摘したんだけど。対策されないままです。
説明会の予約、試験の予約を取り消せたり、
個人情報を変更できちゃったり。
他、ショッピングサイトによくある脆弱性も減らないねぇ。
『https://hoghoge/product_list.cgi?cid=c001』
こんな感じのURLでGET引数を偽装する事でSQL叩けるって現状
query = "SELECT id, name FROM product WHERE category_id='" + cid + "'";
こんな事やっているだけだから、
cid=c001'; DELETE FROM product WHERE id='%
のようにcidを偽装すれば商品情報全部吹っ飛ぶぞ。
# 参照制約ついていたら、ある程度ガードされるけど。
アクセス権限もきちんとしておらず、ビューも使わない。
こんなんでいいのか日本のエンジニア！
Re:エンジニアは一般職？ (スコア:1, 興味深い)
そのときは、入ってきた値の、たとえば「'」を「\'」に変換するというような事をやっていたのですが…
設計者が「そんなことやらないでください」とか言って、削除してしまいました…
「その値はリストボックスですから、チェックする必要はないですよね？」とかって言われて。
いえ、危ないって証拠をつきつけても、「そんなことをやる人はいません」ってつっぱねられまして…。
# ついでにそこ、GETでした
必ずしも、現場のプログラマが悪い場合だけではないということを、理解しておいていただけると嬉しいのです。
# なぜ、そこまで抵抗したかというと、ほんの少しでも高速化したかったそうな…
# そのわりには、サーバ増強に頑固に反対してたな。
Re:エンジニアは一般職？ (スコア:2, おもしろおかしい)
似たような状況でいくら口で言っても理解しないので
そいつの眼前で実際にDBぶっ飛ばして証明したら怒られました。
# だったらやる前に止めろよ
Re:エンジニアは一般職？ (スコア:2)
やっぱり想像力が足りない人は設計やっちゃいかんよ。
# と妄想力最大！
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:エンジニアは一般職？ (スコア:1)
そこら辺の処理は暗黙のうちに要件と仕様に含まれていて削っちゃいけない処理だと思うのです
ちなみにPOSTでもＧＥＴでも削っちゃダメ
ユーザーが意図的に誤動作を引き起こせることには変わりないから
でも、まぁ 高速化したいけど サーバー増強に反対する気持ちはわからんでもないかな
サーバー増強はいろいろと面倒だし
Re:エンジニアは一般職？ (スコア:0)
>そこら辺の処理は暗黙のうちに要件と仕様に含まれていて
要件は提案専門のプランナーが定めてまして、仕様…というか構造設計というかは、その技術者が定めておりました。
つまるは、「そういう仕様です」
高速化 (スコア:0)
# 1%も速くなるとは思えないのでAC
Re:高速化 (スコア:0)
ただアンケートやユーザー登録など項目が多くなればそれだけチェックコストも高くなるはずです。
しかし高速化を求めるなら他によりよい方法はいくらでもあると思います。ってゆーか誰のためのサービスで何を目的とした高速化なのか、担当者の発言はそれを見失っているように思えます。
Re:高速化 (スコア:0)
>それで、何割速くなりました？
># 1%も速くなるとは思えないのでAC
手元では測定不能なほど小さな時間でした。
ぇぇ。1%どころか0.01%ですらなく、測定不能なのです（泣
Re:高速化 (スコア:0)
ボトルネックはDBとの接続でしたので、全体の実行時間は測定できる程度には長かったのですが…ということで。
Re:エンジニアは一般職？ (スコア:0)
そんな状況にしておく必然性が全く理解出来ないんだけど...。
> ビューも使わない。
ゴメンナサイ、金が無いのでMySQLです。
Re:エンジニアは一般職？ (スコア:0)
WHERE id = '$id';
とかそうですね。
昔ボルチモアテクノロジーがやっちゃっていたと思います。セキュリティ製品売ってるのにねぇ。
m(__)m (スコア:0)
Re:毎日就職ナビ (スコア:0)
試して笑ったAC
Re:エンジニアの質が低すぎるのでは (スコア:1)
少なくとも未だに知人のスペースで動いているGeoCitiesのゲストブックもボコボコ [geocities.co.jp]です。
Re:エンジニアの質が低すぎるのでは (スコア:1, すばらしい洞察)
SSLを正しく運用出来、またネットワーク設計に長けているような人でも、
IEは嫌いだからとか、ECMAscriptを調べるの嫌だからとか、
WebServerのアーキテクチャに興味が無かったり、等々が因して、
穴を作ってしまう例も多いですよね。
セキュリティ対策というのは危機管理なのだから、
どれだけ広範に危機の可能性を想像し対策を検討出来るかどうかが
要であるし、たとえ個人的に嫌いな技術でもそれが世に普及しているならば、
きちんと抑えておかなきゃダメなんだよと、口うるさく言ってるわけなのだが・・。
たとえ、高くとも。。。 (スコア:1, 参考になる)
私「ちょっと、見てみますね。(うちのシステムじゃないんだけど)」
私「...」
私「製造元に対応させたらどうですか。」
顧客「いろいろとあって。。。」
私「保守の範囲じゃないですか?。」
顧客「保守契約結んでいない。。。」
私「問い合わせに対してだけなら、○○だけ対策すればいいですが、
あれやら、これやらも直さないとダメですよ。」
顧客「じゃあ、○○だけしてもらえます?」
このあと、どうなったかは知らない。官庁関係なんだが。
エンジニアの質の問題よりも発注側で作る人と、チェックする 人が同一としている点がまず問題。
多くの場合、その後の保守の方が問題なのにその点を考慮して ない発注者側の問題の方がおおきい。
何事も稟議・予算獲得といった縦割り杓子定規での範囲でしか 担当者が動けず、発想や思考が硬直している。
# 多くの企業でもそうだが。
意志決定の迅速さや、裁量をある程度あたえなければ、こういった 人間が増えていくんでしょうね。
さて、問題の私の作業費用は、ベンチ等の什器をあっちやら こっちやらたどって、手元には一応来ました。
# だから、そういう事やってるから、ダメなんだって。
Re:エンジニアの質が低すぎるのでは (スコア:0)
特にセキュリティ意識が低いというか、
セキュリティという単語の意味を知らないとか（ぉ
車道のど真ん中をテクテク歩いているかのよう。
田舎の道路ならまだしも、都会の主要道のような
交通量の多いところでは、危険だっちゅうの
Re:エンジニアの質が低すぎるのでは (スコア:0)
＞開発を指揮管理する層や発注者、リスクヘッジすべき部署にいる人や経営者の大半の認識も「動いたらそれでええんとちゃうんかい」なレベルに止まっている
ってことは、上も下も全然ダメダメってことですよね。
何から手をつけりゃいいんでしょうか？
XSS 対策 (スコア:3, 参考になる)
できることは、読み、また読ませて、どうすればいいのかを広めることでしょう。
@IT: クロスサイトスクリプティング対策の基本 [atmarkit.co.jp]
@IT: Webアプリケーションに潜むセキュリティホール 第2回 顧客データがすべて盗まれる？！ [atmarkit.co.jp]
CERT/CC: How To Remove Meta-characters From User-Supplied Data In CGI Scripts [cert.org]
識者の方、他にも「これは読んどけ」ってのあったらお願いします。
Re:XSS 対策 (スコア:4, 参考になる)
Re:XSS 対策 (スコア:1)
まー個人情報保護法案も施行されていくことだし、一通り眺めといてもいいのでは？
個人情報扱う上で責任ある立場の人は特に。
「論考」以下のネットワークセキュリティ云々 つうのがよろしい感じであります。
XSSと直接関係ない...と思いますか。そうですか。
Re:XSS 対策 (スコア:1)
クロスサイトスクリプティング攻撃に対する電子商取引 サイトの脆弱さの実態とその対策 [etl.go.jp]
なんだかなぁ、な話。 (スコア:1, 興味深い)
メッセージボード [nifty.com]とnoteブック [nifty.com]（日記CGI）は、
使えるタグは制限されてたりして。
メッセージボード [nifty.com]は〈I〉〈B〉〈FONT〉。
noteブックは〈FONT〉〈B〉〈I〉〈A HREF...〉。
とこんだけ。実はスラドより厳しかったり。
・・・だってのに、大元の方でそれやってたんだねぇ。
なーにやってんだか・・・・・。
＃一@homepage利用者なAC。
Re:なんだかなぁ、な話。 (スコア:1)
FONTやAにJavaScriptやスタイルシートが指定できたりしませんよね？
試してみて下さい・・・とは言いませんが（笑）。
Re:なんだかなぁ、な話。 (スコア:1, 参考になる)
<a href="javascript:..." だとか、
<a onClick="..." はちゃんとカットされてます。
でも、<a href="http://" onClick="barfoo" とかやると、なんかリンクが変・・。
実害は無さそうなのですが。
でもって、 (スコア:1)
メッセージボードのタグは、設定でOFF(＝使用不可)にも出来るんだよなぁ…古いサービスの方がきちんと考えられているというのもなんだかなぁ。
ま、この手の話は、サービス提供者(@nifty)ではなくて、ホントにプログラムを組んだ人／組織による、ってことなんでしょうけど。
最近のニュースでは (スコア:0)
# 今回の話題とは違うんでしょうが、個人サイトに指摘する場合には注意を
Re:最近のニュースでは (スコア:1, 興味深い)
Re:最近のニュースでは (スコア:0)
ネットワークの場合、大抵はクレーマー扱いで無視されますが、紳士に対応するとことは逆に対策を教えてくださいってパターンありません？
Re:最近のニュースでは (スコア:0)
指名停止されたりすることもあるので、気付いたら黙ってないと。
＃某人工衛星メーカーのように…。
注意の仕方 (スコア:0)
＃と思ってたら実は人間じゃなかったとか？
いくらでもある (スコア:0)
大手がやってたから問題になっただけで、こんなのいくらでもあるでしょ。
無料掲示板のレンタルサービスとか。タグが使えるタイプの無料掲示板は大抵スクリプト通るよ。
scriptタグだけ使えないようにしても、＜meta http-equiv=Refresh＞で飛ばせたり
＜a ... onMouseOver=...＞ とかできたり、＜img src=.... ＞でブラクラ作れたりと、
ほんとそんな掲示板ばっかり。 /.みたいな掲示板はむしろ少数でしょう。
大手だからこそ (スコア:0)
Re:大手だからこそ (スコア:0)
某企業系列からの強力な推薦もあった @@@ 系の研究プロジェクトからスピンアウトした実績もある某社に@千万払って作らせたサイトはこれ以上無いくらいに惨憺たる様だったりします。外面は繕いましたが張りぼてです。IBM や NEC と一緒にあいみつとったところです。
私は完成後に企画として雇われそのサイトと付き合いながらプログラムを覚えていったのですが、学べば学ぶほど目の前のブツと肩書きの立派な某社が物作りの資
Re:大手だからこそ (スコア:0)
今回の件に限って言えばそんなに技術的に難しいものを要求しているわけではありませんし、きちんとテスト段階で「不正なタグを通さないかどうか」はチェックされてしかるべきだったでしょう。
ただ何よりもまずかったのは、ずっと前から気づいていた人がいてきちんとNiftyに報告していた人（私もその一人です）がいたにもかかわら
安全なタグ？ (スコア:0)
悪意のあるサイトへのアクセスにより発生するため、
スラドで使えるアンカータグも十分危険だと思います。
要は使えるタグの問題ではなく、XSS対策の有無の問題ですよね？
#毎回view-source使ってリンク先のソースをチェックしてから
#アクセスしている人なんていますか？
#悪意のあるサイトからバックして戻る際も気をつけないと...。
Re:安全なタグ？ (スコア:1, 参考になる)
> 悪意のあるサイトへのアクセスにより発生するため、
逆ですよ。悪意あるサイト(A)からXSS対策していないサイト(B)へのリンクを踏んだときに、(B)のサイトの情報漏えい等をひきおこす問題です。
> スラドで使えるアンカータグも十分危険だと思います。
リンク先に悪意があっても、スラドにXSS脆弱性がなければ、スラドのクッキーを盗まれることはないです。
Re:安全なタグ？ (スコア:0)
リンク先を確認してクリックするのは自己責任。
リンク張らなくても URL を書き込む事は出来るわけでね。
Javascript 必須でアンカーをブラインドするサイトはどうかと思いますが、利用者にも必要な知識が求められてよいと思います。
利用者に知識を求めちゃダメ (スコア:0)
利用者は便利に使いたいから利用するだけであって、勉強したいとは思っていません。
むしろ、どんなアホウがどんな滅茶苦茶やっても大丈夫なようにシステムを設計しないといけません。
まぁ実際にはどんなに頑張ってもそれを上回る凄腕orアホウが出てきてし
Re:利用者に知識を求めちゃダメ (スコア:0)
無理でしょう。
世の中の仕組みもそうでは。誰でも外歩く時も信号や歩道の意味程度はわきまえているハズです。
単に URL を見て自分がどのサイトが提供するサービスを利用しようとしているのか、個人情報やカード番号を流す時にブラウザの
Re:なら見なければいい。 (スコア:0)
#と、こういうのと一緒で言い続けないと(ても、か)分らないわけだ