ウェブアプリの脆弱性にどう対応してますか? 73
ストーリー by yoosee
日々の弛まぬ努力、だけでは足りなくなりつつあるかも 部門より
日々の弛まぬ努力、だけでは足りなくなりつつあるかも 部門より
戸高芳広 曰く、 "現在ITproで「【緊急連載 今本当に必要なセキュリティ対策】」という連載が始まっている。この記事の中でカカクコムの穐田CEOは、「自社内では考えうる限り最高のシステムだと思っていたが，実際診断を受けたらそうとは言えないと指摘された」と述べている。
慢心した馬鹿だと思われるでしょうが、私にはこの人の気持が良く解ります。
個人的な話で恐縮ですが、今年の初めに報告されたAWSTATSの脆弱性の時には、私が脆弱性の情報をまだ掴んでいなかった1月19日から私のサイトに対して多数の攻撃が行なわれていました。インターネットからウェブアプリへのアクセスを認めないポリシーだった為、クラックは免れましたが、もし公開されていれば私のサーバはSELinux ターゲットポリシーを有効にしていたにも関わらず、スクリプトキディの遊び場になっていた事でしょう。
カカクコムに対する攻撃の詳細が報告されなかったり、ホワイト(グレイ)ハット的行為が日本では糺弾され、多少セキュリティに関心がある程度では、なかなかサービスを守りきるのが難しくなってきているように個人的に思います。
スラッシュドット諸志は、特にウェブアプリの脆弱性に対して、そしてクラッカーの手にサーバが落ちた時に備えて、どのような対策やポリシーを用意しているのでしょうか。"
お題、把握してますか (スコア:5, すばらしい洞察)
何故に「俺流 これがセキュアな web アプリケーションの書き方」みたいな話になっているのか。
WAF (スコア:3, 参考になる)
商用(アプライアンス)だったら
Teros [teros.com]とか
TrafficShield [f5.com]とか
NetContinuum [netcontinuum.com]とか
SecureSphere [imperva.com]とか
商用(ソフトウェア)だったら
InterDo [kavado.com]とか
AppShield [watchfire.com]とか
# F5に買われたのか、、
オープンソースならmod_security [modsecurity.org]
使えば防げるよ。
他にもあるけど、こんなに出てるのね。
# 仕事中だけど、ま、いいや
ぱ
Re:WAF (スコア:2, すばらしい洞察)
どこかの社長の「最高レベルのセキュリティ」と同じ意識ですね。
というかこういう製品は、正しいWhite Listを作らないと使い物になりませんし、望んだ効果も得られません。
上の方にありますが、taint perlを使っておきながら$foo = ($foo =~ /^(.*)$/)[0] とかするような人には効果は得られません。
正しいWebアプリケーションを作れない人／会社が、正しいWhite Listを作れるという、説得力のある理由がみつかりません。
# もちろん、これらの製品を正しく設定すれば有用である事には異議はありません。
Re:WAF (スコア:1, 参考になる)
自分の行った対策がどのレベルを保護しているのか理解できないと無意味。
Re:WAF (スコア:1)
この一言が中途半端ですね。
むしろ「～使えば防げない攻撃はない」位言って欲しかった。（笑）
そしたらもっと釣れたのに。
Javaの例だと (スコア:2, 参考になる)
なら、今ではフレームワークが解決してくれますね。
これはトリッキーな機能や設計を防ぐ手段にもなっています。
最近は、パラメータの改ざんに注意を払うようにしてます。
機能としての汎用性を犠牲したり、あらゆる入力パラメータを
想定して開発するといった若干精神論的なアプローチでまだまだ
これだ！という解決策はありません＾＾；
また、CSRFへの対応も難しいですね。単純な仕組みならAjaxで簡単に
自動なんたらを作れてしまうし。ちょっとJavaScriptを知っていれば
ブラウザ開いて適当な文字列を入力エリアに配置し、送信。送信確認。
と全て自動で何かを行われてしまうサイトを作られてしまうでしょう。
自動化の危険性を顧客（サービス利用者も含め）に伝えるのも仕事の
一つですかね。
対策 (スコア:2, 興味深い)
どうにもならないって事があるよね。
「はやくシステムを稼動して欲しい」っていう要求ばかり強いと、
こちらも人の子だから「じゃセキュリティは後回しにして・・・」っていう事にもなりかねない。怖い怖い。
要所要所で「対策しないとヤバいっすよ」って一応は言うよ。
そういう点では価格コム等の件は脅しに使える優れた事例ではあります。
「対策に金出さないとやられますよ、知りませんよ」
「そうは言っても予算が」
「じゃ頑張って予算を獲得して連絡してくださいね。それまでは絶対責任持てません」
「わかりました」
しかし担当者はいつまで経っても連絡してこない。
業を煮やして電話すれば
「あ、あの人辞めましたよ」
そっか、辞めたのか・・・。
かくして私も転職するのです。
〜◍
とあるSNSサイト (スコア:2, 興味深い)
とあるSNSサイトのログインページに、
' or '' = '
と、よくあるフレーズを入力したらログインできたので、
管理者に状況を報告してあげました。
これでボランティア２件目でした。
ウェブでの商用サービスは、
「ユーザが多い分システムが枯れているのかな」
って思っていたんですが、ただの妄想に過ぎませんでした。
素人が作っているんでしょうか。
作っている最中に、普通に「これはマズイ」って思いませんかね。
Re:とあるSNSサイト (スコア:1)
> 作っている最中に、普通に「これはマズイ」って思いませんかね。
素人さんが作っているのであれば「まだ」救いがあるのでしょうが、
考えにくいでしょうね。お金もらって商売している人がこのような状況を
作り出しているのでしょう。
# ある意味では「素人」になるのでしょうが。
多分「マズい」ということに素で気づいていない、に100ガバス。
Re:とあるSNSサイト (スコア:1)
ドカチンにそれ言っても犬にしゃべれと・・・（略）
Re:とあるSNSサイト (スコア:1)
これを見て総当り攻撃するバカが出て問題になったら
犯罪教唆にあたりませんかね?
素人が報告しているんでしょうか。
書き込んでいる最中に、普通に「これはマズイ」って思いませんかね。
Re:とあるSNSサイト (スコア:1)
じゃあ現在のユーザーを危険にさらしてもOKなんですか。ふーん。
Office Vs ACCS事件とか昨今のセキュリティ欠陥報告で何が問題に
なっていて、
何でJVN [jvn.jp]みたいなとこができて、報告者側と欠陥を
もっているとこの間でコーディネイトしているのか理解できてます?
#私はJVN万能論者でもないですけどね。
報告から1ヶ月たっていようが、ある程度対象者をしぼれる状態で
ゲロっちゃったてのは、「俺サイトの欠陥みつけて報告しちゃってるんですよ」
みたいに自慢したいのか、単にその後起こりうる影響を考えることが
できない軽率な人なのかどちらかだと思われるんですよ。
で、(欠陥報告自体はともかくとして)、そういう軽率なやり方を詭弁で
擁護していると、さらにイタい人がわいたなぁと思われます。
Re:とあるSNSサイト (スコア:1)
何だのといちゃもんをつけるのかよく分からないんですが……
とりあえず (スコア:1, 参考になる)
・サニタイズされていない出力データは有害。
だけでも認識されていればそこそこ安心できそう。
Re:とりあえず (スコア:1, 参考になる)
「perl -wT が通らないCGI? そりゃダメだね、怖くて使えないよ」って意識が広がれば成功。
#面倒になって $foo = ($foo =~ /^(.*)$/)[0] をやったことがあるのでAC
Re:とりあえず (スコア:1)
使えますかね？
正規表現を利用した入出力バッファ・チェック・ライブラリ：
http://www.toshima.ne.jp/~maoyam/buffer_checker/index.html
セキュリティは防御だけでは不完全。。。 (スコア:1, 参考になる)
とりあえず入出力のサニタイズですかね。。
後出来る限りPreapareでのDBアクセス。
ただDBアクセスせずに式入力(そんなのあるか？)みたいなのだとコマンドインジェクションも。。。
やはりサニタイズ？？
ただ、それでも漏れはありますし、プラットホームの脆弱性でサニタイズだけでは対応できないこともありますから。
おきた場合の対処のマニュアルも重要。
>慢心した馬鹿。
ええ。思います。
オフとぴ気味、別議論になりそうですが、セキュリティ対策とは侵入対策、改竄対策、ウィルス感染対策などの受けだけを、また技術的防御策だけを指すものではありません。
万一、感染、改竄された場合の対処のマニュアル等も含めた総合的なものです。
たとえばパターンファイルが間に合わずにウィルス感染してしまった場合でも、今度は２次感染者を出さない為の対策ができているかもセキュリティ対策です。
普通は感染したら、即座にネットワークから切り離しますよね？そのPCからの２次感染しゃを出さない為に。
サーバーなら尚更です。
今回カカクコムは自分のサーバーが改竄によりウィルス感染しているのを知りながら、情報収集の為と称して稼動を続けエンドユーザーに多くの２次被害者を出しました。
”２次被害者をださない”この視点が全く欠けている。
セキュリティ意識がと技術がこの時点で引く過ぎる。
”考えられる最高レベルのセキュリティ対策をしてきたつもり”とはIT関係者なら口が裂けても言える状態ではない。
あの事件でカカクコムを擁護している人間は、カカクコムはある時点から完全な加害者であるという意識を持っていない人が大勢。
感染、改竄に気がつかない間->カカクコムは完全な被害者。責任の大半は攻撃者。
感染、改竄に気がついた後運営していた間->カカクコムはユーザーから見て完全な加害者。ユーザーの感染の責任の大半はカカクコム
そこをよく考えてみてほしい。。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
被害者は被害認識後、適切な対応が出来ないと加害者ですか・・。ほんとに迷惑な被害だな。
攻撃者は「今対応することを強制」することができるんだもんね。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
”最高のセキュリティ対策”を詠ってるIT企業なら2次感染対策は当たり前でしょう。 ”今対応すること”も。 (自分が感染し2次感染がおきることがわかっていた上で)何も対策せず、多くのユーザーの2次感染を引き起こしたのですから、言い訳は効かない。
今回のカカクコムの一番の間違いは個人的にはここだと思ってる。 #SQLインジェクション対策や防御をおざなりにしていいという話ではない。
#例えるなら、防火壁で建物建てて、防火は完璧といって室内にスプリンクラーつけず、消火器設置もなし。窓も一般の窓。家の中には可燃物一杯ｗｗ。
#で、最高の火災対策と吹聴すると。あほかと。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
＃いくらやっても平行線でしょうな。
としたうえで
見物客からは金取らないで直接経済的な利益のある情報を与えるサービスで
「知ってて理解してて対策出来てる」事や
「非常時にどうするかをあらかじめ ないしは 納得されるほど迅速に的確な対応をするための知識や知恵を持ってて適用する」
事を要求するってのは どうも「知ってる側」のエゴのようなきがするんでさ。
経営的に見ても
・分間○○○万稼ぐ
・社会的意義も大きいサイト
・ウィルス感染してしまいました
・でもまだ運用できてます
ってなったときに
１．運用全止めで直るまで対策する。
２．運用しながら対策。（直ったら自分から報告 or だまっとく）
３．放置。
だったら カカクコムの取った対策は ３の様に言われているが
普通の経営者だったら２を取りたいしカカクコムもそうしたでしょ。
１だったら１で（結果しかみない）ステークホルダー様が（彼らにとって訳のわからない）サイトの停止にお怒りなすったでしょう。
また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ 技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。
＃この意味からも、あらかじめ調べておくってのは大事だね。
「知らない人」ってのは「知らない」事を「知らない」んだよ。
だから自分の知ってる中で最高とか誇っちゃうの。
どんな状況であれ「知ってる」事に金を払っている訳じゃなければ相手に「自分が知ってる」事を強要するのは勝者の論理とおもうぜ。
でも だんだん良くなってるじゃん カカクコム。
それでも俺は使いたいなぁ。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
問題はカカクコムは
”２次感染が起きる事を知ってた”って事。
２次感染が起きる事を知った上で数日間運用をつづけた。
語幣を恐れずにいえば２次感染が起きる事を知ってた上で利益を優先し、故意にユーザーを2次感染させたって事。
＋知らなかった以降、問題を起こし、知った後でも、
過失はない
なんて発言をしている。
http://itpro.nikkeibp.co.jp/free/SI/NEWS/20050525/161513/
防御技術がもし本当に完璧だったとしても、運用過失は間違いなくあった訳だ。
なのに過失はないなんて発言をしている。
”考えられる最高レベルのセキュリティ対策をしてきたつもり”
も事件後の言葉。事件に何も学んでいる様には見えない。
こういう企業は同じ事を繰り返す。学ぶつもりも無いし、学んだとしても利益優先でそれを生かすモラルが無いわけだから。
私には本当の意味で、何も反省しているようには見えない。
だから、カカクコムには厳しい事をいうべきだと思う。
それが私の考え。
平身低頭謝るなら、まだ対策していこうという気があるように見えるんだけどね。
口だけで証拠は出さない。運用は滅茶苦茶だったじゃ擁護の価値はない。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
”過失はない。”
”最高のセキュリティが破られた”
なんていわずに、
”最高のつもりがガタガタでした。ごめんなさい。一から出直します。"
って言えばいいんだよ。。
それならまだ反省してるな。これからは大丈夫になっていくな。。と見えるのに。。
Re:セキュリティは防御だけでは不完全。。。 (スコア:1)
ならば２次感染者を故意に出していいとでも？
>また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ 技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。
だからこそ一時的に止めた上でログなり何なりを元に、ゆっくり調査・対策すべき。
結果的にその方が判断力の回復が早い。
ログすら取ってないんなら、運用として最悪。
ノーガード、のちカカクメソッド (スコア:1)
あとは、詳細を伏せ「わが社の対策は完璧だった」で押し切ります。
ヒースキット山口 heath yamaguchi
Re:ノーガード、のちカカクメソッド (スコア:0)
何かヘンなことが起こっている！をどうやって監視する (スコア:1)
個人レベルだと「できるだけ気をつける」か「サーバ上げるのやめる」かの二択になっちゃうなぁ。
屍体メモ [windy.cx]
500円 (スコア:1, おもしろおかしい)
Re:500円 (スコア:1, おもしろおかしい)
# powered by J∀SR∀C
とりあえず (スコア:1)
当座の生活資金あたりを用意しておけば何とか逃げられるんじゃないかと
思ったりして。徹底するならパスポートも用意しておいた方がいいかも。
え、そういう話ではない?
Javaの例だと (スコア:1, おもしろおかしい)
ソースコードに名前など残しません。
サーバ管理者の視点 (スコア:1, 興味深い)
原始的な方法としては (スコア:1)
SQLインジェクション対策には
PEAR::DB->quoteSmart()
XSS対策には
htmlentities()
かな、、、
uxi
とりあえず (スコア:0)
原理的にSQLインジェクションは発生しないので。
でも結局のところは一生懸命情報を収集するしかないのですけれどね。
Re:とりあえず (スコア:1)
PostgreSQLのJDBCだと、 % はエスケープされずそのまま渡されます。
バージョンによって違うかもしれませんが。
他のＤＢはどうなんでしょう？
Re:とりあえず (スコア:0)
その分だけのPreparedStatement作るんですか？
Re:とりあえず (スコア:1)
情報源は定かではないのですがJavaの場合、PreparedStatementを生成する際に
コンパイルされたSQL文はキャッシュされるはずですので
Statementを都度生成するより効率的です。
誰か詳しい人、補足をお願いします…；
Re:とりあえず (スコア:1)
結果を使いまわすキャッシュがあったはずです。
あらかじめPrepareしておけばこのキャッシュから探す手間も
省けます。
が...
条件によってSQLを動的に生成するという事は、下手するとキャッシュ
にヒットしないんじゃない？
私だったら、デカイSQLでRDBMS側に条件判断させる事も検討します。
そうしないと、SQL動的生成する部分に脆弱性っつかバグが紛れ込む可能性
が出てきますから。
# 実行計画次第ですがね。
wild wild computing
Re:とりあえず (スコア:3, 参考になる)
オンライン・トランザクション処理でミリ秒単位のレスポンスを要求するシステムではPreparedStatementの使用が事実上必須ですね.
Oracleの場合, SQLのコンパイルにかかる時間は(もちろんSQLの記述によって全く異なりますが)おおよそ数100msのオーダー, 一方コンパイル済みのSQLをキャッシュから探すのが数msのオーダーです. そのため秒間数10～数100程度の問い合わせがあるシステムでは, 動的SQLを使うとデータが十分にバッファリングされてIO負荷に問題の無い場合でもCPUネックでシステムが回らなくなる場合があります. 一般には多くの業務システムでSQLキャッシュヒット率は95%以上が望ましいと言われていますが, 経験的には大規模システムで確実に回す場合, 最低でも98%. 99%以上もあたりまえって感じです.
あと, ある程度以上の規模のシステムではRDBMSサーバとアプリケーションサーバが分離されていてネットワークで繋がっているという構成も多いです. この場合RDBMSサーバ側でできるだけ条件判断を行わせてRDBMSサーバとアプリケーションサーバ間のネットワークに余分なデータを流さないというのも性能に効いてきたりします.
Re:とりあえず (スコア:1, 興味深い)
実際以前よりは動的SQLにパフォーマンスに難が無くなりました。
Prepare構文に変換出来るものは内部的に変換してキャッシュ率上げるとか。。うろ覚え。違ってたらごめんなさい。
それでも最初からPrepare使った方が早いですし、インジェクション対策にもなるので良いのは変わりませんが。
Re:とりあえず (スコア:1, 興味深い)
そのコンパイル時間によってOSとDBサーバアプリのI/O WAITも
隠蔽され、性能分析/改善が難しくなります。
まず最初に動的SQL潰しをやってから真面目に分析しましょう、
なんて話はよくありますし、その分改善コストがかさみます。
単発ツールなら別ですが、システム開発であればPreparedは必須で、
動的SQLの使用は許可制が良いかと。
# オフトピックですいません。
Re:とりあえず (スコア:1, 興味深い)
NULLとUNKNOWNを積極的に活用するSQLの書き方 [no-ip.info]
Re:とりあえず (スコア:1)
># 何でWebアプリだけ問題にされるのか不思議。
間接的にでもインターネットにつながってる事が必須のＤＢだからじゃないでしょうか。
何も用意していない人、素直に挙手を!! (スコア:0)
(冫、)ノ ＜ ﾊｲ 私もその一人です
ごめんなさいッッ
＃絶対ＡＣ
1から100まで (スコア:0)
Re:1から100まで (スコア:0)
どこのサイト作ってる方ですか？
使用しているサイトなら使用やめますｗｗ。
Re:1から100まで (スコア:2, おもしろおかしい)
二度と閲覧しないでください。
Re:1から100まで (スコア:1)
Re:1から100まで (スコア:1)
破壊目的ならクォートなしでも(処理系により)可能。
Re:1から100まで (スコア:1)
ちなみにさっきのはGembaseという超マイナー言語。
普通は
;delete from XXX; ですな。
;truncate XXXX;
でも可。