適切なセキュリティ対策が実施されない理由 37
ストーリー by reo
パッチワーク楽しいな 部門より
パッチワーク楽しいな 部門より
ある Anonymous Coward 曰く、
gihyo.jpの「なぜ PHP アプリにセキュリティホールが多いのか?」という記事にて、「セキュリティ対策が確実に実施されない理由」が述べられている。
記事ではその理由として、「重複を廃した効率的なコードを目指したために多重のセキュリティ対策を行わず、その結果対策漏れが発生する」、そして「誤ったセキュリティ対策が完全であるという思い込み」が挙げられている。記事では対策として「セキュリティ対策とコーディングのベストプラクティスは相反することを理解する」などとが述べられており、入力・ロジック・出力のすべての段階で (多重チェックになるものの) データのバリデーションを行うべき、としている。
完璧主義のプログラマとしては重複はできるだけ廃したいところだが、どこにどのような穴が存在するかは分からないわけで、確かにこのような方向性は有用だろう。
仕組みの理解 (スコア:2)
私も人のこと言える立場じゃありませんが「仕組み」を理解していないのも原因かと。
よくわからないけど、ネットに落ちてたサンプルコードつかったら動いたのでそのまま使ってるとかもあるでしょうし、
ネット上の古い情報を元に対策して結局はその対策自体も効果が薄かったとか。
本当はちゃんと調べたり検証しないといけないんですけどね。
入力、ロジック、出力でのそれぞれの動きを理解出来ていれば多少はマシになるんじゃないかとも思います。
セキュリティ, 何それ? (スコア:1)
これで説明は十分なんじゃないかな.
アプリケーションプログラミングにセキュリティの考慮を期待した時点で, システムとしては負けだと思います.
Re: (スコア:0)
＞ネットに落ちてたサンプルコードつかったら動いたので
そういうのってじっくりコード読み込んでしまうと、気づいたら原型とどめないほどリファクタリングしちゃってることがあるので怖いです。（しかもファイルサイズは2/3くらいに減っている）
それくらい「定番」と呼ばれ検索上位に来るようなものはだいたい古い。リファレンス見てobsoletedで非推奨な記法がされていないかとかくらい見たいところですね。
効率的なコードが非セキュアとな？ (スコア:1)
＞「重複を廃した効率的なコードを目指したために多重のセキュリティ対策を行わず、その結果対策漏れが発生する」
これがなぜ漏れの原因になるんだか。コードのシンプルな美しさにこだわる人がそんな愚をおかすようなことはないと思います。
一般的な入力値のチェックは汎用性が高いので組込みの関数やクラスになっていったりしてますし、チェック用の共通のAPI作っておけば逆に漏れがなくてよさそうなもんだけどなあ。
逆にあげつらわれてる例は複雑すぎる巨大なCMSばかりのような...
Re: (スコア:0)
最初に作った人:Geek、改修した人:新人
なんかよくわからないけどここがこうだからここをこうすればいいだろうと改修した結果穴が出来るということなら理解できますね
コードに必要なセキュリティとは属人化(誰でも読むことが出来る、理解できる)だと思います。
Re: (スコア:0)
それは非属人化。
Webアプリの進化そのものだから？ (スコア:0)
なぜPHPだけ、と条件を縛るのかはわかりません。あえて考えるとすれば、PHPの進化がそのままWebアプリの進化となっていた時期があった、ということではないかと。さまざまなアイディアとそれを実現するための実装が山のように出てきて、それがそのまま整理されていない状況といった感じ。
Re: (スコア:0)
新規でWebDBの開発はじめるのに、何も縛りがなければ、今はだいたいの人はRubyを使うという状況なんですかねえ。
もうPerlとかもダメ？
新規はRuby一強なんでしょうか？
Re: (スコア:0)
Ruby信者乙
ruby? 久しぶりに聴いた (スコア:0)
T/O
最近のoutputは何？
それは (スコア:0)
時間がない、責任がない、等あるけど
結局は通常時問題にならないから
問題がおきなければ修正されない
Re: (スコア:0)
それもよくあるけれども、今回はそれとは違って
自己過信でわざと多重チェックをしない件が問題になってるんじゃないでしょうか
そんなの妄想じゃないの？ (スコア:0)
無駄だと思えようが、必要な機能を満たしていなければただの不具合
そんな事を理由にする人なんて本当にいるのかね？
DBやらHTMLやらJSONやら、対象が違えば処理内容が異なって当然
重複？無駄？それはあなた自身の事だよね
Re: (スコア:0)
何が面白くないのかわからんけど、話がまったくかみ合っていないぞ
完璧主義のプログラマなら (スコア:0)
functionの最初の行で事前条件が満たされている事を検査するもんじゃないの?
Re:完璧主義のプログラマなら (スコア:1)
完璧主義じゃなくても入り口にassert並べたりするよなー。
...てことでassertでコケたらエラーページ吐くようにしてみるとか。
完ぺき主義ではないけれど (スコア:0)
> 重複はできるだけ廃したいところだが、どこにどのような穴が存在するかは分からないわけで
むしろ、どこに穴が生まれるか判らないからこそ、重複を避けたいと思うんだけど…。
この重複と表現している部分が元記事を読んでも、正直良く判りません。
重複を避けるの意味を、PHPでよく使う処理をfunctionにまとめることだと思ったんですが、
それが何故セキュリティホールにつながっていくのか、そこもイマイチ判然としません。
もし何か私が誤解しているようなら、ぜひ指摘していただけないでしょうか。
Re: (スコア:0)
入力チェック処理をどこで行うかということですね。
理論的には１回で大丈夫なんだけど
プログラマは完璧ではないし、ミスることはあるので
入力チェックはなるべく複数のところで行った方がより確実だよってことですね。
例えば、一番最初に入力チェックをやるのは当たり前として
DBへのアクセスの前にもチェックを行う方がより安全でしょう。
自分の場合は表示の部分でも出来るだけチェックして、たとえ変なタグがDBに入力されても問題が起きないようにしているけどね。
特に複数の人で作っていると、DBも必ずしも安全とはいえないし（誰が変なプログラム作るかわからないしw）
そんなプログラム作る人ほど他人のせいにしてくる人も多いから、共通モジュール作る時などは特に注意するね。
Re: (スコア:0)
「重複を廃した効率的なコードを目指したために多重のセキュリティ対策を行わず、その結果対策漏れが発生する」
というのは用意されたチェック関数だけだと危険、ということではないでしょうか？
関数に渡す前にチェック、更に関数の中でチェックと多重にチェックしていても
どちらも同じチェック関数だったら、チェック関数にバグがあった場合に一気に穴になりますよね？
あくまでもそれぞれの箇所で
・入力は信用しない
・出力は(自分自身の手で)安全にしておく
というのが推奨されるんじゃないかと。
数値しか入らないフィールドは一度数値型を通すとかそういう対策含めてですね。
文字列の場合はなかなか難しいところがあるとは思いますが。
また大垣か (スコア:0)
入力チェックは当然行うべきだがそれはセキュリティ対策ではない。
出力で「バリデーション」してエラーになったらどうしたらいいの? サニタイズ言うなキャンペーンが浸透してきたから言い換えてみただけとしか思えないんだけど。あらゆる出力が可能性として現に存在する場合は(バイナリファイルのダウンロードとか)どうすりゃいいの? テーブル名を動的に外部から与えるアプリケーションなんてありそうにもないものまで想定を強いるくせにその程度のことも想定してないの?
Re: (スコア:0)
そのうち「バリデーション言うなキャンペーン」が出来て、最終的には「セキュリティ言うなキャンペーン」が誕生する予感。
Re: (スコア:0)
> また大垣か
まさにこれ。
このおっさんはどこかピントの外れた記事しか書けなくて、そのたびに各所から総突っ込み受けてるゴミクズ。
記事書く前に徳丸本（ソフトバンククリエイティブ 体系的に学ぶ 安全なWebアプリケーションの作り方）を熟読してこいって感じ。マジレスしてるヤツもなんだかなぁ。
こういうPHP叩きのトピックって認証され易いけど (スコア:0)
ぶっちゃけRubyとかも大概だと思うけどね
BSD厨を彷彿とさせる「んなもん標準配布物じゃねえから関係ねえ」という姿勢といい
某vi厨に「Rubyって1.8系でしか動かないライブラリが沢山ある」ってDisられたら
速攻で「1.8.7の今後について」とまだ2.0も出てない内から足切り予告
つまるところアレでしょ？
「Ruby最新版にはセキュリティホールが確認されてない」
「うちら標準配布物以外のものに関しては、全然全く知ったこっちゃねえから」
「もう師走で、2.0の影も形も見えねえけど、最新版以外は再来年で終了な？ 後はどうなろうと知んね」
「最新版で動かねえアプリ？ んなもん知んね」
「標準で付属してる以外のライブラリ？ ますます関係ねえ」
っていうスタンスなんでしょ？
要は、そんな有様で「適切なセキュリティ対策を実地してる」って言えるの？ ってことなんだよ
一番使われてるRubyがどうかじゃなく、自分らの好きなバージョンだけ対策して、それで適切なセキュリティ対策？ アホかと……
別にRubyを挙げたのは、他意があっての事じゃなくて、単純にこないだのフレーム祭りが9月と最近だったんで挙げたまで
他所も似たようなもんだと思うし、アンチRubyistってわけじゃないよ
ともかくPHPはDisられすぎ
叩きトピも簡単に認証しすぎ
他所だって大して変わらん癖して、PHPばかり叩くのはいい加減にしろと言いたい
Re:こういうPHP叩きのトピックって認証され易いけど (スコア:1)
Ruby を追いかけてないのでよくわからんのだけど要するに
１．互換性を重視していないのでアップデートすると動かないことが多い
２．動かない（かもしれない）のでアップデートしない人が多くなる
３．結果的に脆弱性を残したシステムが量産される
ってことですか？
Re:こういうPHP叩きのトピックって認証され易いけど (スコア:1)
このコメントのようなステレオタイプな批判って、PHPほどではないにしろRubyにも多いですね。
いつもどことなくピントがずれているのも、両言語で共通な気がします。
親コメントですが、さすがにおかしい。
Ruby1.9系列が最初にリリースされたのは2007年のことで、それから現在まで4年にわたって、
前バージョンである1.8系列のメンテナンスが続けられているわけです。
先日のruby公式サイトでのアナウンスでは2013年6月で1.8.7のメンテナンスを終了すると宣言しましたが、
約5年間も前バージョンのメンテを続けるのは、他のプロジェクトと比較しても決して短いとはいえないでしょう。
親コメントの「某vi厨」のフレームとは、日本語版vimのメンテナとして有名なKaoriyaさんが引き起こした騒動ですね。
http://www.kaoriya.net/blog/201109/20110913 [kaoriya.net]
rubygemsというかなり基本的なライブラリが、マイナーバージョンアップで互換性のない変更をしたために、
氏が使っていたアプリが動かなくなったのを、「rubyの言語的性質のせいである」と
（あまり客観的な根拠を示さずに）Webサイトで主張したため、「そんなもん単にrubygemsの問題でしょ？なんでrubyのせいになるの？」
とrubyコミュニティが反論したというものです。
親コメントでは、これをもって「うちら標準配布物以外のものに関しては、全然全く知ったこっちゃねえから」という態度であって
rubyコミュニティがセキュリティを軽視している表れだと主張していますが、
これは「PHPアプリでセキュリティ問題が発生するのはPHPのせいだ」というのと同じくらい、雑というか、飛躍した主張だと思います。
Javaのシステム開発でも、基盤となるライブラリのバージョンを上げるときはしばしば互換性が問題になるし、事前にテストするのが普通です。
Kaoriya氏の場合、マイナーバージョンアップだからと安易にrubygemsをupdateしたのが軽率だったのでしょう（ご本人も認めていますが）。
ましてや、1.8系列メンテ終了の決定が、このフレームの影響でなされたというのはさすがにあほらしい。
たいした話じゃないでしょこれ。
PHPやrubyが、この種の、安易な弱い者たたき的批判を許すのは、（少なくとも過去に）互換性なりセキュリティを軽視していた時期があったために、外部の人たちに対して悪いイメージがついたためなのでしょう。
しかし、私の知るかぎりでは、どちらのコミュニティも、現在では相当に注意深くなっているという印象です。
こういう、特定の言語のイメージを利用した安易な批判は、実際には正しくないことが多いし、少なくとも建設的でないと思うので、
止めて欲しいですね。
Re: (スコア:0)
いやいや、1.8系の中で互換性なんて保たれてないから。互換性がそこそこあるのはもう一個下の1.8.xの単位でしょ?
Re: (スコア:0)
認証って？
Re: (スコア:0)
> 要は、そんな有様で「適切なセキュリティ対策を実地してる」って言えるの？ ってことなんだよ
> 一番使われてるRubyがどうかじゃなく、自分らの好きなバージョンだけ対策し
> て、それで適切なセキュリティ対策？ アホかと……
最新版に付いていく更新が行えないような環境で適切なセキュリティとかそれこそ阿呆の所業だろ。
それが嫌なら自分で使ってる版に相当するパッチ当てていけ。
それが面倒ならディストリがバージョン上げずにパッチあててくれてるんだからそれ使え。
セキュリティってのはまず現実を見るところから始まるんだ。何でも他人のせいにしてることこそ論外なんだよ。
> ともかくPHPはDisられすぎ
単に広く使われていることによって使う方も幅が広がって、お馬鹿な使われ方をされる
結果としての件数が多いからこういう話をまとめやすくなってるだけ。PHPに限った話じゃないが、
例としてPHPが出てくるってのはそれだけ使われてるってことでしかないの。
Re:こういうPHP叩きのトピックって認証され易いけど (スコア:2)
言語の仕様次第でお馬鹿な使われ方されやすいのと、そうでないのがあるんでないかな？
で、PHPは前者と思っている人が多い。
自分も色々な言語やってからPHP見たけど動きゃいいみたいな作り方しててそれ以降見る気しない。最近は違うのかもしれないけど。
Re: (スコア:0)
言語仕様の問題より、それをずっと使ってきてる連中のコミュニティがお馬鹿な使い方を代々受け継いでいってたりしますね。野良の独学プログラマが変な使い方するならともかく、こうやって大家の師匠が老害化するとかいかんだろう。
http://d.hatena.ne.jp/ryoasai/20110109/1294581985 [hatena.ne.jp] こんなのが好例で、使っているのはJavaでありながらとあるSIと言うコミュニティで代々COBOL的な使い方が受け継がれていってるみたいな。
PHPもオブジェクト指向になっていったりよりパフォーマンスのいい関数が追加されていったりしてるのに、新規の機能は使いたがらずわけのわからない代替の抽象化までして非推奨の機能をしつこく使ってる人居ますし。
金がかかる事はしない (スコア:0)
・保守契約もしてもらえない、やり捨てのような3次受け4次受けは、
検収さえ抜ければ関係無いので、対策するだけ無駄
・検収される側より検収する側の方が、技術的に無知なのが当たり前ですし。
Re: (スコア:0)
同感です。
こういった事象は、純粋な技術論で考えた理由よりも、
実際の現場で生じた結果論のほうが正解に近いと思います。
SQLインジェクション対策の基本の1つである「すべてのリテラルを文字列として処理」 (スコア:0)
数値型は数値で処理する……よね？
Re: (スコア:0)
日本のとある大企業をお客様としている外資大手の日本支社のプロジェクトでは
Javaを使っているのに数値も基本全部、文字列で行っています。
ですのでそのような常識を疑われたほうが良いでしょう。
# その大手企業はアカウント乗っ取りができる脆弱性のあるサイトを絶賛放置で大公開中ですがｗ
# 普通は数値の型を使いますよねえ、計算のとき一々変換するのが激しくだるいです。
Re: (スコア:0)
割り算で困った結果になったりしませんか？
Re: (スコア:0)
もしかして、参加中のプロジェクトですか？（＾＾）
そんなサニタイズ脳の記事はほっといてこれでも読んどけ (スコア:0)
妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション [hatena.ne.jp]