アカウント名:
パスワード:
これまでのサイト攻撃は、OSの不備やホームページをネットに提供するプログラムのミスなどを突くケースが多かった。今回は、プログラムに欠陥がなくても、コンピューターが正規の命令か悪意のある命令かは判断できない点を突き、命令をそのまま実行させて支配下に置いていた。
#自分の個人サイトでは手を抜くけどw
kakaku.comはApacheやIISだけで「ホームページをネットに提供」していたわけではなく、独自のプログラムを構築してサービスを提供していたわけですが、そのうちの一部分がIISなりだったというだけでしょ? また、社会的な責任という面を考慮した場合に、OSやIISなどの脆弱性をつかれたわけではなかったのかもしれませんが、入門書でも載っているようなSecureプログラミングを知らない(または手抜きした)人が実装もテストもしていたということで、利用者がウィルス感染したりという被害が出ているわけですから、kakaku.comを擁護するような内容の記事が問題だと思うわけです。 kakaku.comが自身を正当化することを、メディアが鵜呑みにしたような記事を載せることに抵抗を感じずにはいられません。
入力された値のバリデーションを正しく行うことは、Secureプログラミングの基本だと思うのだが、、、
どういうわけか、入力をサニタイズするという場当たりな対処方法ばかりを宣伝するおかしなセキュリティ屋が多いですが、彼らはプログラミングの素人なんでしょう。ちっちゃいおもちゃCGIプログラムくらいしか作ったことがないとか。
その場にある脆弱なプログラムを取り急ぎ直すのに入力のサニタイズという方法が即効性がある場合もあるのでしょうが、どのように使われるかわからない入力値をどうやって完全にサニタイズするんでしょうか。サニタイズ漏れや、過剰なサニタイズでバグを生んだりしかねないでしょう。
セキュアプログラミングの文脈で「サニタイズ」とかいう言葉を持ち出すセキュリティ屋は信用するな、とまで言ってもいいかもしれない。文脈通りに正しい文字列連結のプログラミングをしていれば、この種の脆弱性は最初から生じないのです。
Yahoo! Blog が入力値をサニタイズしまくって記事投稿時にエラーばっかり吐きまくりやがるので (不正な文字列がどうたらこうたらとか。。。んで、書いた記事全文がフイになる。ブラウザの機能で戻ってもスッカラカンになっちゃうの)、一部ユーザーに反感買いまくりだったりするわけですが、やっぱり彼らもシロートなんだろうなぁ。。。
。。。ん? /. のコメント欄でもそんなエラーに出くわした記憶が。。。??
Darren Reed: 気に入らないのは「特権分離」とやらを使うのが 唯一の方法だということだ。皮肉なタ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
プログラムに欠陥がなくても? (スコア:2, すばらしい洞察)
Re:プログラムに欠陥がなくても? (スコア:2, 興味深い)
#自分の個人サイトでは手を抜くけどw
Re:プログラムに欠陥がなくても? (スコア:2)
あなたの記事の解釈が間違っていると思われます。
「OSの不備」は、読んで字の如くOSの脆弱性を指すと思い
ます。「ホームページをネットに提供するプログラム」は、
サーバソフトウェアのことで、Apache HTTP Serverや
Internet Information Server等を指しているのではないで
しょうか。
上記のように解釈すれば、記事全体の話の筋が通ると思います。
Re:プログラムに欠陥がなくても? (スコア:1)
が、ずいぶん好意的な解釈ですね(笑)
kakaku.comはApacheやIISだけで「ホームページをネットに提供」していたわけではなく、独自のプログラムを構築してサービスを提供していたわけですが、そのうちの一部分がIISなりだったというだけでしょ?
また、社会的な責任という面を考慮した場合に、OSやIISなどの脆弱性をつかれたわけではなかったのかもしれませんが、入門書でも載っているようなSecureプログラミングを知らない(または手抜きした)人が実装もテストもしていたということで、利用者がウィルス感染したりという被害が出ているわけですから、kakaku.comを擁護するような内容の記事が問題だと思うわけです。
kakaku.comが自身を正当化することを、メディアが鵜呑みにしたような記事を載せることに抵抗を感じずにはいられません。
Re:プログラムに欠陥がなくても? (スコア:1, 興味深い)
結局ソレだよな。
サイトの更新頻度からして技術と広報の連携は取れていると見えるだけに、
今までにない新しい攻撃手法みたいな言い方は、解っててミスリードを誘っているとしか思えねえ。
擁護?正当化? (スコア:1, 興味深い)
問題がIISでもphpBBでもなくDBの設定であるって言うのは、プログラム作者ではなくkakaku.comが悪いと言っているように思うのは気のせいですか。
asahiの記事を読み直した方がいいんじゃないか?と思うのは気のせいですか。
「ソフトの不備ではなく、データベースの安全設定が不十分だった点を悪用された。」(一部引用)
#というより、この記事を読んで擁護や正当化と取る人もいるなんて、このコメントを見るまで思わなかった。
Re:擁護?正当化? (スコア:0)
#740120 はなぞのばくはつを、とげた。
「と思うのは気のせいですか。」を3連発するなんて、よほど腹が立ったんだろうなあ。
何故腹が立ったのか俺には解らんけど。
pivo 氏が疑問に思ってるのは、多分
> これまでのサイト攻撃は、OSの不備やホームページをネットに提供する
> プログラムのミスなどを突くケースが多かった。
> 今回は、プログラムに欠陥がなくても、コンピューターが正規の命令か
> 悪意のある命令かは判断できない点を突き、命令をそのまま実行させて
> 支配下に
Re:擁護?正当化? (スコア:0)
「OSやIIS、phpBBは悪くない。
悪いのは設定をしたkakaku.comだけだ。」
ってasahiが言ってるって書いてるのに。
疑うとしたらMSの社員の筋だと思うのだが。
「winにもIISには問題ないから安心して使えます。
今回の問題はユーザが設定を謝ったから起きただけです。
通常はなんの問題もありません。」
#、、、うぐっ、吐き気が
Re:擁護?正当化? (スコア:0)
不適切な(正しいとは言い難いってゆーかむしろ間違ってる)報道をしていて、
それが(意図するか否かに関わらず)「kakaku.com への擁護」になってしまっている。
と言うのが現状です。
気のせいでもなんでもなく、
Re:プログラムに欠陥がなくても? (スコア:0)
無知や面倒くさがりでこうなったのなら、どれほど救いがあった事かと思いますよ。
Re:プログラムに欠陥がなくても? (スコア:0)
> サーバソフトウェアのことで、Apache HTTP Serverや
> Internet Information Server等を指しているのでは
> ないでしょうか。
別 AC ですが。
ネタ元 AC さんは「単純なプログラムミスなの
Re:プログラムに欠陥がなくても? (スコア:0)
Re:プログラムに欠陥がなくても? (スコア:1)
(正)本当にクラックの方法が記事どおりだとしたら
typoです(T_T)
Re:プログラムに欠陥がなくても? (スコア:1)
バリデーションというよりもサイニタイジングと言わないか?
俺のまわりだけか・・。
バリデーション=数値範囲チェック、仕様に添った型で有るか
サニタイジング="aaa && sendmail hoge@hoge `tail` ..."みたいなトリッキーな文字列を掲示板に投稿するとか検索フォームにPOSTとかしてないかをチェック。
というイメージがあるんですけどね。。
Re:プログラムに欠陥がなくても? (スコア:1)
サイニタイジング の検索結果のうち 日本語のページ 約 63 件中 1 - 4 件目 (0.21 秒)
サニタイジング の検索結果のうち 日本語のページ 約 2,800 件中 1 - 10 件目 (0.04 秒)
英語のスペルはぐぐればすぐ出てきますが、「sanitizing」。
ですので、多分2文字目のイは余分です。
ちなみに、バリデージョンは英語スペルが「Validation」で
「Varidation」のtypoが多いみたいですね。
意味は似てないこともないけど、認証とか保証とか検証とかの
意味があてられているようですね。
#私の言うことは例のクレタ人並みに信用できますので!
Re:プログラムに欠陥がなくても? (スコア:0)
バリデージョン の検索結果 4 件中 1 - 4 件目 (0.34 秒)
バリデーション の検索結果 約 34,300 件中 1 - 10 件目 (0.11 秒)
Re:プログラムに欠陥がなくても? (スコア:2, おもしろおかしい)
あっこれすごく多いです! きっとこれです!
Re:プログラムに欠陥がなくても? (スコア:1)
サニタイズ?何それ (スコア:1)
どういうわけか、入力をサニタイズするという場当たりな対処方法ばかりを宣伝するおかしなセキュリティ屋が多いですが、彼らはプログラミングの素人なんでしょう。ちっちゃいおもちゃCGIプログラムくらいしか作ったことがないとか。
その場にある脆弱なプログラムを取り急ぎ直すのに入力のサニタイズという方法が即効性がある場合もあるのでしょうが、どのように使われるかわからない入力値をどうやって完全にサニタイズするんでしょうか。サニタイズ漏れや、過剰なサニタイズでバグを生んだりしかねないでしょう。
セキュアプログラミングの文脈で「サニタイズ」とかいう言葉を持ち出すセキュリティ屋は信用するな、とまで言ってもいいかもしれない。文脈通りに正しい文字列連結のプログラミングをしていれば、この種の脆弱性は最初から生じないのです。
Re:サニタイズ?何それ (スコア:1)
後学のために正しくはサニタイズとはどういう処理か詳しく教えてください。
Re:サニタイズ?何それ (スコア:1)
英語を使う人間がサニタイズと使うからって、そのまま使うケースがあまりに多過ぎる気がするな。
あっちの人間って、新しい単語を作っても、辞書に載っていなければ通じないから、既存の単語を良く用いる。
それと違い漢字って、漢字自体が意味を持つから、「無害にする」とか「殺菌する」なんて言葉の英語を外来語として使わずに、「特殊文字の無害化」って多くの人が見ても分かり易く表現した方が良いんじゃないの?
「特殊文字をサニタイズしていないから」みたいな「対象」がはっきり分かる表現ならば分かりやすいけど。
CGIのソースを指差し「サニタイズして」なんて言っていると、言われた人はモニターをイソプロピルアルコール等で消毒....
その後、「サニタイズしてくれた?」なんて聞くと「ちゃんとしておきましたよ」なんて....
後日、「しかし結果として“最高の対策”とは呼べない部分はあったと思う」
http://www.itmedia.co.jp/news/articles/0505/25/news086.html
なんていう羽目になるかも。
# だけど「無過失らしい」....
Re:サニタイズ?何それ (スコア:1)
ご指摘ありがとうございます。本当に言葉の意味を理解して使っているのかと、自分で反省中です。
Re:サニタイズ?何それ (スコア:1)
なのでシステムの規模や処理内容などで使い分ければ良いんでないでしょうか。
もちろん、出力時の対処の方がシステムの拡張性は高いと思いますが。
どちらにしても「設計」「規約による縛り」「試験」は大切ですね。
Re:サニタイズ?何それ (スコア:1)
そういう意味ではおっしゃるようなメタ文字のエスケープやディレクトリのチェックを(どの時点でやろうとも)サニタイズと呼んでいいような気がします。言い方の問題かな、と。
しかし、確かにユーザーからの入力値チェックで済ませるというのは場あたり的かもしれないですね。その後どう使われるかがはっきりしてる小さいプログラムしか書かないので、ちょっと気付きませんでした。
それでも単純に「入力値」とか「入って来た値」とか言ったとき、プログラムに入って来た(main()に入って来た?)値なのか、その関数に入って来た値なのかは状況いかんな気もします。関数に入って来た値を利用する前にエスケープ処理などをやらせる関数を、sanitize()とか名付けたり、「入って来た値は使う前にサニタイズしないとね」みたいな言い方はよくします。やはり言い方、名付け方の問題?
名前がついているのは便利 [rubycolor.org]ですしね。
Re:サニタイズ?何それ (スコア:1)
Yahoo! Blog が入力値をサニタイズしまくって記事投稿時にエラーばっかり吐きまくりやがるので (不正な文字列がどうたらこうたらとか。。。んで、書いた記事全文がフイになる。ブラウザの機能で戻ってもスッカラカンになっちゃうの)、一部ユーザーに反感買いまくりだったりするわけですが、やっぱり彼らもシロートなんだろうなぁ。。。
。。。ん? /. のコメント欄でもそんなエラーに出くわした記憶が。。。??
むらちより/あい/をこめて。
Re:サニタイズ?何それ (スコア:1)
セキュリティとは違うのかもしれませんが、データを入力するユーザーが間違える可能性を考慮しないというのはまずいのではないでしょうか。たとえば電話番号の入力を要求しているのにアルファベットが来たら、チェックして正しいデータを入れてもらうようにしないと。
しかし、電話番号を入れるときにハイフンを使うな、というwebをよく見かけるけど、10桁の数字って確認しにくいんだよなあ。ハイフンくらいプログラムの内部で処理してくれればいいのに。
---- 6809
Re:サニタイズ?何それ (スコア:1)
#740324 さんの書くサニタイジングのコードというのは、どんな文なんでしょうか? サニタイズというくらいですから、文字列を削るコードなんですよね。
Re:プログラムに欠陥がなくても? (スコア:0)
>外部からの命令を受け付けなくすることなどの設定が必要だ。対策済みの企業も少なくない。
このくだりが
>入力された値のバリデーションを正しく行うことは、
>Secu
Re:プログラムに欠陥がなくても? (スコア:0)
OpenSSHの「特権分離」と同じことではないの?
これを入力のされた値のチェックに当たるかかと言われてもなぁ。
Re:プログラムに欠陥がなくても? (スコア:2, おもしろおかしい)
修正しているそばから改ざんする [nikkeibp.co.jp]というレベルの高い攻撃 [impress.co.jp]を仕掛けてくる、スーパーハカーによるサイバーテロ [kakaku.com]だったんだよ!
#んなワケねーだろ
Re:プログラムに欠陥がなくても? (スコア:2, 興味深い)
かかわらず「犯人追跡」だの「侵入経路の特定」だの理由をつけて
サイトの運営を続けていたわけです。
顧客を危険に晒してるのに順番がおかしいです。
ナメきってると思いました。私はもう利用しません。
# 直接の顧客は私のようなサイトの利用者じゃないでしょうけど
私一人なら痛くもかゆくもないでしょうけど、
こう思ってる人がどれくらいいるんでしょうね。
ま、これに懲りて安全なサイトにはなるでしょうけどね。
Re:プログラムに欠陥がなくても? (スコア:1)
>かかわらず「犯人追跡」だの「侵入経路の特定」だの理由をつけて
>サイトの運営を続けていたわけです。
サイトの運営を続けるのは、俺はそれ自体が悪だとは思えないけど。
既出の穴でパッチ当てているブラウザでは感染しないのだろ?被害が小さいと判断するのはおかしな判断とは思えない。
被害の可能性や被害者への連絡を4日後に行なったのは遅い気もするが、4日でしかないとも言えるんじゃないの?
Re:プログラムに欠陥がなくても? (スコア:1)
利用者側の判断として「パッチを当てているから大丈夫」ってのはいいでしょう。
サービス提供者側が「パッチを当てていれば大丈夫」と判断するのはどうなんでしょう。
もっと踏み込んで「パッチを当ててないやつが悪い」というニュアンスを感じます。
もちろんパッチを当ててないやつも少しは悪い、というか自業自得の面はあるでしょう。
だからといってサービス提供者側がそれをアテにするのは間違った態度です。
サービスを受ける側も提供する側も被害を広めない・受けない努力が必要です。
それは、サービスを受ける側ではたとえばパッチを当てることです。
サービスを提供する側ではたとえばサイトの運営を即時停止することです。
不特定多数が利用するサイトですから、サービスを受ける側に素人さんがいることは
容易に想像がつくはずです(つかなきゃ馬鹿です)。
もう一度言います。顧客を危険に晒してまでサイト運営を続けたのは間違いです。
Re:プログラムに欠陥がなくても? (スコア:1)
>容易に想像がつくはずです(つかなきゃ馬鹿です)。
それはそうなんだけどさ、IEでも古い奴やパッチ当てて無い奴の中には、開いたページのエレメントをscriptで拾って他所に送信可能だよね。
これは容易に想像が付く問題だから、scriptは起動しないように切っておくべきだろうけど、必須のサイトは多く存在する。
そう言ったscript必須のサイトは閉鎖すべきなんですか?
カカクコムでの穴を突くパッチって、最近供給された奴じゃないよね。かなり以前でしょ。
俺は「信用済みサイト」以外はscriptの実行は認めていない。当然/.も信用していない。
でも、こんな奴ばかりじゃないことは容易に想像がつくはずです。
ちょっとでも危険ならば即閉鎖すべきなんだろうか?
即閉鎖した場合、書き換え方法がログから特定出来なければ、廃業すべきってことになりそうだよね?穴塞がずに再開出来る訳ないだろうし。
って事は、社員がログが残らないように工作した場合は廃業?
クラッカーがログを消して出て行った場合でも廃業?
パケットキャプチャーする時間くらい与えても俺は良いと思うけど。
ただ俺も一つ気になる点がある。
何度も変えられた様だけど、それならば早い段階で犯人のIPアドレス分かっていた様な気がする点。
その段階でトップページで告知すべきなんじゃ?と。
俺は、しばらく「アクセス出来ない状況」で「変だな」と思ってたら、その後ニュースで流れて知ったよ。
ウイルス感染被害者への配慮ならば、仮のサーバー立てて、早い内に告知すべきだったのではと思う。
「アクセス出来ない状況」って、閉鎖していたが仮サーバー立ててなかったのでしょ?
Re:プログラムに欠陥がなくても? (スコア:1)
>別サーバたててお知らせ出すぐらいはやっても良かったんじゃないでしょうか?
「お知らせ出すぐらいは」ってのが難しいんじゃ?
お知らせの告知を出すと、ばれたと思われクラッカーが再攻撃してこない可能性もあるよね。
ログの削除と重なれば手口の特定が非常に難しくなるよ。
そうすると、停止したサーバーの再開は困難 => ネット専業だから廃業と言う流れに。
バランスを考えると「手口が判明しだい告知などの対処」がベストの様な気が俺はするね。
逆に、ウイルス配信で即停止すべきと言うのがルールならば、ライバル社がサーバー管理者をたらし込めば、ウイルス配信しログ削除が可能だよね。
2億とか出されればぐらつく奴はいると思うけど。
サーバー管理者で、自分の管理下にあるサーバーのログの削除は技術的には可能と思っている人はいるんじゃ?
話があれば、自宅サーバー立てて真面目に出来るか検証可能だよな。その後受けるか連絡すれば良いんだし。
進入経路も書き換え手口も分からん。ログも削除されている。そう言った状況で犯人の特定が出来る確率は少ないんじゃないの?
ウイルス配信で即停止すべきと言うのがルールならば、俺は逆にセキュリティーが保てなくなる様な気がする。
Re:プログラムに欠陥がなくても? (スコア:1)
「既知の脆弱性や攻撃手法で攻撃をテスト」って、単なる一通り?
パッチ当てているか否かって問題ならばそれで直ぐ分かると思うが、CGIなどの不備って、そんな簡単に分かれば苦労しないと思うけど。
>しかし結果として“最高の対策”とは呼べない部分はあったと思う」(穐田社長)
http://www.itmedia.co.jp/news/articles/0505/25/news086.html
と言っているくらいなんだから、「最高の対策」と呼べる対策はそもそも存在していたのでは?
例えば、バッファオーバーフローの脆弱性も今でもたまにぽつぽつと穴が公表されるよね。
テストプログラム回して簡単に脆弱性があるか分かれば苦労しない気がするけど。
ついでに、
「当社に過失はなかったが、詳細は明らかにできない」「今回の件は、過失や重過失に類するものではない」と「無過失」と述べている点と、
>SQLインジェクションによるものだったする一部報道については「私どもから発表した事実ではない」(穐田社長)と、肯定も否定もしなかった。
と言っている点は気になるな。
OS、wwwサーバー、スプリクト言語辺りのどれかに未知の穴でもあったって言う話?
>不正アクセスの手口は「判明している」(穐田社長)としながらも「類似犯罪のヒントとなる情報は出したくない」と、詳細は明かさなかった。
からは、パッチの提供がまだされていない様な印象を俺は受けたけど、どうなんだろう?
Re:プログラムに欠陥がなくても? (スコア:1)
「その通り」って、「SQLインジェクションによるものだった」ってこと?
仮にそうだったとすると、彼の無過失の主張は戯言なのかな?
それと、SQLインジェクションって情報流したのは情報の漏洩?情報の管理が出来ていないってことか?
まぁ、掲示板は読めるけど書けない現状(読み込みCGIは可)を考えると、書き込みの特殊文字の無効化をミスった感じは濃厚だけど、彼は無過失を主張するんだな。
Re:プログラムに欠陥がなくても? (スコア:0)
Re:プログラムに欠陥がなくても? (スコア:1)
レイヤ違い (スコア:1, 興味深い)
ただ、asahiの記事で問題にしているのはSQLインジェクションで実行されるDBアカウントを使って、「DBを乗っ取った」ことに関して。
権限がしっかりと制限されていれば、SQLインジェクションを使われても情報流出は最小限に抑えられる。
しかし、権限が制限されていないと、DB内の情報が全て攻撃者に漏れてしまうので危険。
(ユーザIDが流出するだけで済んだはずなのにメールアドレス等の個人情報が流出した等)
という話だと思われるが。
#記事では「SQLインジェクション」と呼ばれる手法を『利用』ではなく『応用』って書かれてる。
#SQLインジェクションが使えるっていうアプリケーションの脆弱性が無ければ侵入はできなかったとは思うが。
#ただ、ここまでの話は「データベースを支配下に置いていった」というasahiの記事が正しければの話。
#単にSQLインジェクションでデータを抜いただけなら話は別。
Re:レイヤ違い (スコア:0)
> しかし、権限が制限されていないと、DB内の情報が全て攻撃者に漏れてしまうので危険。
> (ユーザIDが流出す
Re:プログラムに欠陥がなくても? (スコア:1)
Re:プログラムに欠陥がなくても? (スコア:1)
「プログラム」= サーバとか、OSとか、ソフトウェア製品のこと
SQLインジェクションの問題 = データベースの設定の問題
朝日新聞(のデスク)にとって、Webアプリケーションという概念は存在しないのでしょう。
予想される記者とデスクのやりとり:
デスク:プログラムの欠陥を直していなかったのが原因なのか?
記者:いえ、パッチは適用していたそうです。
デスク:じゃあ、なんで起きたんだ。
記者:SQLインジェクションという脆弱性だそうです。
デスク:やっぱり欠陥を直していなかったんじゃないのか?
記者:直すパッチはないんだそうです。
デスク:どうしてないんだ?
記者:kakaku.com だけの問題だからだとか。
デスク:設定がまずかったということか?
記者:そんなとこですかねえ。
報道で伝えるべきは、ソフトウェア製品の脆弱性パッチをあてているだけではだめで、個別に開発したWebアプリケーション固有の脆弱性を、検査するなりして、排除しないといけないということなんですがねえ。
Re:プログラムに欠陥がなくても? (スコア:1)
Re:プログラムに欠陥がなくても? (スコア:0)
「思い込まない」「鵜呑みにしない」がセキュリティの第一歩だと教えてあげませう。
欠陥じゃない脆弱性だ (スコア:0)
欠陥(バグ)とは、意図したとおりに動作しないもののこと。
カカクコムのプログラムは、開発者の意図どおりには動いていたんだから、
欠陥じゃないぞ。
Re:欠陥じゃない脆弱性だ (スコア:1)
ユーザー「これこれこういう条件だと、アプリがOSごと落ちるんですけど、これってバグですよね?」
メーカー「いえ、仕様です」
というのは欠陥とは言わないのか。
知らなかった。
# s○nyめ……。
Re:欠陥じゃない脆弱性だ (スコア:1)
動作的には正しいのですから。
逆に言えば、OSごと落ちるように作ってあって、落ちなかったら「欠陥」ですね。
Re:欠陥じゃない脆弱性だ (スコア:0)
「意図したとおりに動作しない」は、安全に動作しなかったという意味で「意図したとおりに動作しなかった」わけだろ。だから、脆弱性は常に欠陥。でなきゃ、「このような結果を招いたのもプログラムの仕様です」とか言うんか?
Re:欠陥じゃない脆弱性だ (スコア:1)
世の中にいっぱい(割合は不明)ありそうな気がします。
その場合は安全に動作しなくても、「それは仕様です。」
と答えて正解。
#もちろん反論としては
「それは(公序良俗に照らし合わせて)常識外です。」が
ありますが。