ウェブアプリの脆弱性にどう対応してますか?

戸高芳広 曰く、 "現在ITproで「【緊急連載　今本当に必要なセキュリティ対策】」という連載が始まっている。この記事の中でカカクコムの穐田CEOは、「自社内では考えうる限り最高のシステムだと思っていたが，実際診断を受けたらそうとは言えないと指摘された」と述べている。

慢心した馬鹿だと思われるでしょうが、私にはこの人の気持が良く解ります。 個人的な話で恐縮ですが、今年の初めに報告されたAWSTATSの脆弱性の時には、私が脆弱性の情報をまだ掴んでいなかった1月19日から私のサイトに対して多数の攻撃が行なわれていました。インターネットからウェブアプリへのアクセスを認めないポリシーだった為、クラックは免れましたが、もし公開されていれば私のサーバはSELinux ターゲットポリシーを有効にしていたにも関わらず、スクリプトキディの遊び場になっていた事でしょう。

カカクコムに対する攻撃の詳細が報告されなかったり、ホワイト(グレイ)ハット的行為が日本では糺弾され、多少セキュリティに関心がある程度では、なかなかサービスを守りきるのが難しくなってきているように個人的に思います。
スラッシュドット諸志は、特にウェブアプリの脆弱性に対して、そしてクラッカーの手にサーバが落ちた時に備えて、どのような対策やポリシーを用意しているのでしょうか。"

お題、把握してますか

[Anonymous Coward]

どれだけ頑張っても事故る確率は残るわけで、それをどうハンドリング、ケアしますか、という話なのでは。

何故に「俺流 これがセキュアな web アプリケーションの書き方」みたいな話になっているのか。

WAF

[passa (9748)]

Web Application Firewall使えばほとんど防げるのに、、

商用(アプライアンス)だったら
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

[Anonymous Coward]

＞Web Application Firewall使えばほとんど防げるのに、、

どこかの社長の「最高レベルのセキュリティ」と同じ意識ですね。
というかこういう製品は、正しいWhite Listを作らないと使い物になりませんし、望んだ効果も得られません。
上の方にありますが、taint perlを使っておきながら$foo = ($foo =~ /^(.*)$/)[0] とかするような人には効果は得られません。
正しいWebアプリケーションを作れない人／会社が、正しいWhite Listを作れるという、説得力のある理由がみつかりません。

# もちろん、これらの製品を正しく設定すれば有用である事には異議はありません。

Re:WAF

[Anonymous Coward]

と慢心して、サーバの上に乗っけたアプリケーションの穴に気付かなかったんですよね。
自分の行った対策がどのレベルを保護しているのか理解できないと無意味。

Re:WAF

[kokugojiten (22778)]

ほとんど防げるのに、、

　この一言が中途半端ですね。
　むしろ「～使えば防げない攻撃はない」位言って欲しかった。（笑）
　そしたらもっと釣れたのに。
　
　

Javaの例だと

[gogler (17154)]

2,3年前は、色々気をつけていましたが、XSSやSQLInjectionぐらい
なら、今ではフレームワークが解決してくれますね。
これはトリッキーな機能や設計を防ぐ手段にもなっています。

最近は、パラメータの改ざんに注意を払うようにしてます。
機能としての汎用性を犠牲したり、あらゆる入力パラメータを
想定して開発するといった若干精神論的なアプローチでまだまだ
これだ！という解決策はありません＾＾；

また、CSRFへの対応も難しいですね。単純な仕組みならAjaxで簡単に
自動なんたらを作れてしまうし。ちょっとJavaScriptを知っていれば
ブラウザ開いて適当な文字列を入力エリアに配置し、送信。送信確認。
と全て自動で何かを行われてしまうサイトを作られてしまうでしょう。

自動化の危険性を顧客（サービス利用者も含め）に伝えるのも仕事の
一つですかね。

対策

[yellow tadpole (7084)]

いかに対策しようと思っても、顧客が費用を払ってくれないと
どうにもならないって事があるよね。
「はやくシステムを稼動して欲しい」っていう要求ばかり強いと、
こちらも人の子だから「じゃセキュリティは後回しにして・・・」っていう事にもなりかねない。怖い怖い。

要所要所で「対策しないとヤバいっすよ」って一応は言うよ。
そういう点では価格コム等の件は脅しに使える優れた事例ではあります。

「対策に金出さないとやられますよ、知りませんよ」
「そうは言っても予算が」
「じゃ頑張って予算を獲得して連絡してくださいね。それまでは絶対責任持てません」
「わかりました」

しかし担当者はいつまで経っても連絡してこない。
業を煮やして電話すれば

　　　「あ、あの人辞めましたよ」

そっか、辞めたのか・・・。

かくして私も転職するのです。

--
〜◍

とあるSNSサイト

[kacchan6 (19477)]

価格.comで問題になった時に、
とあるSNSサイトのログインページに、
' or '' = '
と、よくあるフレーズを入力したらログインできたので、
管理者に状況を報告してあげました。
これでボランティア２件目でした。

ウェブでの商用サービスは、
「ユーザが多い分システムが枯れているのかな」
って思っていたんですが、ただの妄想に過ぎませんでした。

素人が作っているんでしょうか。
作っている最中に、普通に「これはマズイ」って思いませんかね。

Re:とあるSNSサイト

[sen (197)]

> 素人が作っているんでしょうか。
> 作っている最中に、普通に「これはマズイ」って思いませんかね。

素人さんが作っているのであれば「まだ」救いがあるのでしょうが、
考えにくいでしょうね。お金もらって商売している人がこのような状況を
作り出しているのでしょう。
# ある意味では「素人」になるのでしょうが。

多分「マズい」ということに素で気づいていない、に100ガバス。

Re:とあるSNSサイト

[kokugojiten (22778)]

知らないことを認識するのってすごいスキルだとおもけどね。
ドカチンにそれ言っても犬にしゃべれと・・・（略）

Re:とあるSNSサイト

[Elbereth (17793)]

SNSサイトなんて数えるほどしかないんですから、
これを見て総当り攻撃するバカが出て問題になったら
犯罪教唆にあたりませんかね?

素人が報告しているんでしょうか。
書き込んでいる最中に、普通に「これはマズイ」って思いませんかね。

Re:とあるSNSサイト

[Elbereth (17793)]

いや……その……将来ユーザーになりうる人にとって利益～って、
じゃあ現在のユーザーを危険にさらしてもOKなんですか。ふーん。

Office Vs ACCS事件とか昨今のセキュリティ欠陥報告で何が問題に
なっていて、
何でJVN [jvn.jp]みたいなとこができて、報告者側と欠陥を
もっているとこの間でコーディネイトしているのか理解できてます?

#私はJVN万能論者でもないですけどね。

報告から1ヶ月たっていようが、ある程度対象者をしぼれる状態で
ゲロっちゃったてのは、「俺サイトの欠陥みつけて報告しちゃってるんですよ」
みたいに自慢したいのか、単にその後起こりうる影響を考えることが
できない軽率な人なのかどちらかだと思われるんですよ。

で、(欠陥報告自体はともかくとして)、そういう軽率なやり方を詭弁で
擁護していると、さらにイタい人がわいたなぁと思われます。

Re:とあるSNSサイト

[Elbereth (17793)]

この件では全く関係のない私のスキルを勝手に推量して死ねだの
何だのといちゃもんをつけるのかよく分からないんですが……

とりあえず

[Anonymous Coward]

　・バリデーションされていない入力データは有害。
　・サニタイズされていない出力データは有害。

だけでも認識されていればそこそこ安心できそう。

Re:とりあえず

[Anonymous Coward]

perlのCGIなら、taintperl 強制で、バリデーション済のデータかどうかをperlにチェックさせるというのはどうですかね。
「perl -wT が通らないCGI? そりゃダメだね、怖くて使えないよ」って意識が広がれば成功。

#面倒になって $foo = ($foo =~ /^(.*)$/)[0] をやったことがあるのでAC

Re:とりあえず

[maoyam (16680)]

こんなフィルターをヒマな時に作ってみたんですけどね。
使えますかね？

正規表現を利用した入出力バッファ・チェック・ライブラリ：
http://www.toshima.ne.jp/~maoyam/buffer_checker/index.html

セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

他レスにもあるように、
とりあえず入出力のサニタイズですかね。。

後出来る限りPreapareでのDBアクセス。
ただDBアクセスせずに式入力(そんなのあるか？)みたいなのだとコマンドインジェクションも。。。
やはりサニタイズ？？

ただ、それでも漏れはありますし、プラットホームの脆弱性でサニタイズだけでは対応できないこともありますから。
おきた場合の対処のマニュアルも重要。

>慢心した馬鹿。

ええ。思います。
オフとぴ気味、別議論になりそうですが、セキュリティ対策とは侵入対策、改竄対策、ウィルス感染対策などの受けだけを、また技術的防御策だけを指すものではありません。
万一、感染、改竄された場合の対処のマニュアル等も含めた総合的なものです。

たとえばパターンファイルが間に合わずにウィルス感染してしまった場合でも、今度は２次感染者を出さない為の対策ができているかもセキュリティ対策です。
普通は感染したら、即座にネットワークから切り離しますよね？そのPCからの２次感染しゃを出さない為に。
サーバーなら尚更です。

今回カカクコムは自分のサーバーが改竄によりウィルス感染しているのを知りながら、情報収集の為と称して稼動を続けエンドユーザーに多くの２次被害者を出しました。
”２次被害者をださない”この視点が全く欠けている。

セキュリティ意識がと技術がこの時点で引く過ぎる。
”考えられる最高レベルのセキュリティ対策をしてきたつもり”とはIT関係者なら口が裂けても言える状態ではない。

あの事件でカカクコムを擁護している人間は、カカクコムはある時点から完全な加害者であるという意識を持っていない人が大勢。

感染、改竄に気がつかない間->カカクコムは完全な被害者。責任の大半は攻撃者。
感染、改竄に気がついた後運営していた間->カカクコムはユーザーから見て完全な加害者。ユーザーの感染の責任の大半はカカクコム

そこをよく考えてみてほしい。。

Re:セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

引く過ぎる。->低すぎる。TYPOすまん。

Re:セキュリティは防御だけでは不完全。。。

[kokugojiten (22778)]

感染、改竄に気がついた後運営していた間->カカクコムはユーザーから見て完全な加害者。ユーザーの感染の責任の大半はカカクコム

　被害者は被害認識後、適切な対応が出来ないと加害者ですか・・。ほんとに迷惑な被害だな。
　攻撃者は「今対応することを強制」することができるんだもんね。

Re:セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

知識の低い一般ユーザーならば、まだ許せるが

”最高のセキュリティ対策”を詠ってるIT企業なら2次感染対策は当たり前でしょう。 ”今対応すること”も。 (自分が感染し2次感染がおきることがわかっていた上で)何も対策せず、多くのユーザーの2次感染を引き起こしたのですから、言い訳は効かない。

今回のカカクコムの一番の間違いは個人的にはここだと思ってる。 #SQLインジェクション対策や防御をおざなりにしていいという話ではない。

#例えるなら、防火壁で建物建てて、防火は完璧といって室内にスプリンクラーつけず、消火器設置もなし。窓も一般の窓。家の中には可燃物一杯ｗｗ。
#で、最高の火災対策と吹聴すると。あほかと。

Re:セキュリティは防御だけでは不完全。。。

[kokugojiten (22778)]

>”最高のセキュリティ対策”を詠ってるIT企業なら2次感染対策は当たり前でしょう。 ”今対応すること”も。 (自分が感染し2次感染がおきることがわかっていた上で)何も対策せず、多くのユーザーの2次感染を引き起こしたのですから、言い訳は効かない。

＃いくらやっても平行線でしょうな。

としたうえで

見物客からは金取らないで直接経済的な利益のある情報を与えるサービスで

「知ってて理解してて対策出来てる」事や
「非常時にどうするかをあらかじめ　ないしは　納得されるほど迅速に的確な対応をするための知識や知恵を持ってて適用する」

事を要求するってのは　どうも「知ってる側」のエゴのようなきがするんでさ。

経営的に見ても　

・分間○○○万稼ぐ
・社会的意義も大きいサイト
・ウィルス感染してしまいました
・でもまだ運用できてます

ってなったときに

１．運用全止めで直るまで対策する。
２．運用しながら対策。（直ったら自分から報告 or だまっとく）
３．放置。

だったら　カカクコムの取った対策は　３の様に言われているが
普通の経営者だったら２を取りたいしカカクコムもそうしたでしょ。

１だったら１で（結果しかみない）ステークホルダー様が（彼らにとって訳のわからない）サイトの停止にお怒りなすったでしょう。

また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ　技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。
＃この意味からも、あらかじめ調べておくってのは大事だね。

「知らない人」ってのは「知らない」事を「知らない」んだよ。
だから自分の知ってる中で最高とか誇っちゃうの。
どんな状況であれ「知ってる」事に金を払っている訳じゃなければ相手に「自分が知ってる」事を強要するのは勝者の論理とおもうぜ。

でも　だんだん良くなってるじゃん　カカクコム。

それでも俺は使いたいなぁ。

Re:セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

経営者側が２を取りたいのは解るが、モラル適にも、技術的にもやってはいけない事。

問題はカカクコムは
”２次感染が起きる事を知ってた”って事。
２次感染が起きる事を知った上で数日間運用をつづけた。

語幣を恐れずにいえば２次感染が起きる事を知ってた上で利益を優先し、故意にユーザーを2次感染させたって事。

＋知らなかった以降、問題を起こし、知った後でも、
過失はない

なんて発言をしている。
http://itpro.nikkeibp.co.jp/free/SI/NEWS/20050525/161513/

防御技術がもし本当に完璧だったとしても、運用過失は間違いなくあった訳だ。

なのに過失はないなんて発言をしている。

”考えられる最高レベルのセキュリティ対策をしてきたつもり”
も事件後の言葉。事件に何も学んでいる様には見えない。

こういう企業は同じ事を繰り返す。学ぶつもりも無いし、学んだとしても利益優先でそれを生かすモラルが無いわけだから。
私には本当の意味で、何も反省しているようには見えない。

だから、カカクコムには厳しい事をいうべきだと思う。
それが私の考え。

平身低頭謝るなら、まだ対策していこうという気があるように見えるんだけどね。
口だけで証拠は出さない。運用は滅茶苦茶だったじゃ擁護の価値はない。

Re:セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

知らなかったんなら
”過失はない。”
”最高のセキュリティが破られた”

なんていわずに、

”最高のつもりがガタガタでした。ごめんなさい。一から出直します。"

って言えばいいんだよ。。
それならまだ反省してるな。これからは大丈夫になっていくな。。と見えるのに。。

Re:セキュリティは防御だけでは不完全。。。

[Non Skill (25960)]

＞ステークホルダー様が（彼らにとって訳のわからない）サイトの停止にお怒りなすったでしょう

ならば２次感染者を故意に出していいとでも？

>また技術者にしても、結果的に対策できなかったカカクコムの技術力はばれてしまったわけですが、そんなピンチの超高緊張時にゃ　技術者も技術的な問題の対策力も調査力も判断力も半減ですよ。

だからこそ一時的に止めた上でログなり何なりを元に、ゆっくり調査・対策すべき。
結果的にその方が判断力の回復が早い。
ログすら取ってないんなら、運用として最悪。

ノーガード、のちカカクメソッド

[heath_yam (16773)]

何もせず相手がボロを出すのを待ちます（ｗ
あとは、詳細を伏せ「わが社の対策は完璧だった」で押し切ります。

--
ヒースキット山口 heath yamaguchi

Re:ノーガード、のちカカクメソッド

[Anonymous Coward]

「インターネット安全安心相談 [srad.jp]」に泣きつく、とか。

何かヘンなことが起こっている！をどうやって監視する

[Livingdead (18685)]

サニタイジングなどの必要な(予想のつく)対策を施していても、何事においても完璧ってことはないので、「何かヘンなことがおきている」ってのをどうやって監視するかも重要ですよね。と、ひとことで言っても、ファイルシステム上で監視したりネットワークの出入り口で監視したりログインやプロセスの実行をログったりとたくさんありますよね。個人で実験的に挙げているサーバだとそこまで手が回らないので、どっか抜けちゃうんですよね。

個人レベルだと「できるだけ気をつける」か「サーバ上げるのやめる」かの二択になっちゃうなぁ。

--
屍体メモ [windy.cx]

500円

[Anonymous Coward]

ユーザ数*500円の資金を常に用意しています。

Re:500円

[Anonymous Coward]

貴殿には500円を受領する資格がありますが、送金にかかる事務手数料などの諸経費と相殺されてしまうため、 支払いを省略させて頂きます。

# powered by J∀SR∀C

とりあえず

[Elbereth (17793)]

しばらく前の日付の辞職願と、しばらく身をひそめるセーフハウス、
当座の生活資金あたりを用意しておけば何とか逃げられるんじゃないかと
思ったりして。徹底するならパスポートも用意しておいた方がいいかも。

え、そういう話ではない?

Javaの例だと

[Anonymous Coward]

Write once, run away.
ソースコードに名前など残しません。

サーバ管理者の視点

[Anonymous Coward]

自分に責任が降りかからないよう、お客さんや周りの人間に、 「Webアプリの脆弱性経由でクラックされることもあるんだよ～」 という地道な啓蒙活動してます・・・ 万が一侵入されたら、サーバ管理者のせいにされそうで怖いんですもの。 開発側にも言ってるんだけど、なかなか意識してもらえなくて・・・

原始的な方法としては

[uxi (5376)]

PHPの場合
SQLインジェクション対策には
PEAR::DB->quoteSmart()
XSS対策には
htmlentities()
かな、、、

--
uxi

とりあえず

[Anonymous Coward]

DBへのアクセスはPreparedStatement。
原理的にSQLインジェクションは発生しないので。

でも結局のところは一生懸命情報を収集するしかないのですけれどね。

Re:とりあえず

[0-9a-zA-Z_.+!*'(),-\ (6182)]

likeには気をつけましょうね。
PostgreSQLのJDBCだと、 % はエスケープされずそのまま渡されます。
バージョンによって違うかもしれませんが。

他のＤＢはどうなんでしょう？

Re:とりあえず

[Anonymous Coward]

条件分岐で検索条件が変わる時は
その分だけのPreparedStatement作るんですか？

Re:とりあえず

[tit (23686)]

その場合は都度、PreparedStatementを生成してあげれば良いかと思います。
情報源は定かではないのですがJavaの場合、PreparedStatementを生成する際に
コンパイルされたSQL文はキャッシュされるはずですので
Statementを都度生成するより効率的です。

誰か詳しい人、補足をお願いします…；

Re:とりあえず

[kai_kamome (4560)]

Javaの場合ってか、Oracleの場合はSQLの字句を比較して過去の解析
結果を使いまわすキャッシュがあったはずです。
あらかじめPrepareしておけばこのキャッシュから探す手間も
省けます。
が...
条件によってSQLを動的に生成するという事は、下手するとキャッシュ
にヒットしないんじゃない？

私だったら、デカイSQLでRDBMS側に条件判断させる事も検討します。
そうしないと、SQL動的生成する部分に脆弱性っつかバグが紛れ込む可能性
が出てきますから。
# 実行計画次第ですがね。

--
wild wild computing

Re:とりあえず

[SteppingWind (2654)]

オンライン・トランザクション処理でミリ秒単位のレスポンスを要求するシステムではPreparedStatementの使用が事実上必須ですね.

Oracleの場合, SQLのコンパイルにかかる時間は(もちろんSQLの記述によって全く異なりますが)おおよそ数100msのオーダー, 一方コンパイル済みのSQLをキャッシュから探すのが数msのオーダーです. そのため秒間数10～数100程度の問い合わせがあるシステムでは, 動的SQLを使うとデータが十分にバッファリングされてIO負荷に問題の無い場合でもCPUネックでシステムが回らなくなる場合があります. 一般には多くの業務システムでSQLキャッシュヒット率は95%以上が望ましいと言われていますが, 経験的には大規模システムで確実に回す場合, 最低でも98%. 99%以上もあたりまえって感じです.

あと, ある程度以上の規模のシステムではRDBMSサーバとアプリケーションサーバが分離されていてネットワークで繋がっているという構成も多いです. この場合RDBMSサーバ側でできるだけ条件判断を行わせてRDBMSサーバとアプリケーションサーバ間のネットワークに余分なデータを流さないというのも性能に効いてきたりします.

Re:とりあえず

[Anonymous Coward]

ORACLEの場合、8だか9だかあたりからパフォーマンスの為に設定によって動的SQLでも似たものはキャッシュ使うようになってるとか聞いたような。
実際以前よりは動的SQLにパフォーマンスに難が無くなりました。
Prepare構文に変換出来るものは内部的に変換してキャッシュ率上げるとか。。うろ覚え。違ってたらごめんなさい。

それでも最初からPrepare使った方が早いですし、インジェクション対策にもなるので良いのは変わりませんが。

Re:とりあえず

[Anonymous Coward]

動的SQL文が増えるとSQLトレースもノイズだらけになりますし、
そのコンパイル時間によってOSとDBサーバアプリのI/O WAITも
隠蔽され、性能分析/改善が難しくなります。

まず最初に動的SQL潰しをやってから真面目に分析しましょう、
なんて話はよくありますし、その分改善コストがかさみます。

単発ツールなら別ですが、システム開発であればPreparedは必須で、
動的SQLの使用は許可制が良いかと。
# オフトピックですいません。

Re:とりあえず

[Anonymous Coward]

貼っておきます。
NULLとUNKNOWNを積極的に活用するSQLの書き方 [no-ip.info]

しかし，webアプリの検索フォームなどでは，プリペアドステートメントは使えない場合が多かった．検索条件項目が複数存在していて，いずれの項目も必須で無い場合，項目が入力されているかどうかをチェックし，それに合わせてSQL 文の WHERE 句の内容をツギハギしなければならないからだ．

SQL文そのものも，そしてそれにセットする引数の個数も可変なので，プリペアドステートメントを使うのは無理だったのである．

今回思いついたのは，このような条件で，プリペアドステートメントを使う方法である．

Re:とりあえず

[kokugojiten (22778)]

># しかしSQLインジェクションってクラサバの頃からある話だと思うんだけどなぁ。
># 何でWebアプリだけ問題にされるのか不思議。
    間接的にでもインターネットにつながってる事が必須のＤＢだからじゃないでしょうか。

何も用意していない人、素直に挙手を!!

[Anonymous Coward]

　
　(冫、)ノ　＜ ﾊｲ 私もその一人です
　　　　　　　　　　　　ごめんなさいッッ
　
　
＃絶対ＡＣ

1から100まで

[Anonymous Coward]

htmlspecialchars

Re:1から100まで

[Anonymous Coward]

htmlspecialcharsはXSS対策にはなりますが、SQLインジェクション対策やコマンドインジェクション対策にはならないんじゃ。。

どこのサイト作ってる方ですか？
使用しているサイトなら使用やめますｗｗ。

Re:1から100まで

[Anonymous Coward]

slashdot.jpです。
二度と閲覧しないでください。

Re:1から100まで

[Nabisuko (229)]

ENT_QUOTESのオプションをつけていればSQLインジェクション対策にはなるんじゃないの？

Re:1から100まで

[Non Skill (25960)]

;delete * from XXXX(テーブル名);

破壊目的ならクォートなしでも(処理系により)可能。

Re:1から100まで

[Non Skill (25960)]

*一個じゃまだったと書こうとしてそのままボタン押してしまった。。。orz.

ちなみにさっきのはGembaseという超マイナー言語。
普通は

;delete from XXX; ですな。

;truncate XXXX;
でも可。