アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
直接のウィルス配布実行犯じゃなくても。。 (スコア:0, オフトピック)
なにが、”最高のセキュリティ”、”過失はなかった”"(1)類似犯罪を誘発しかねない,(2)警察の捜査に支障をきたす恐れがある"だか。
<a href="http://www.itmedia.co.jp/news/articles/0505/25/news086.html"></a>
<a href="http://itpro.nikkeibp.co.jp/free/NCC/NEWS/20050525/161517/"></a>
本当に何も反省せず口だけの<a href="http://d.hatena.ne.jp/keyword/%a5%
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:-1, オフトピック)
単純に無知が故と考えていると、オタク系エンジニアが落ちやすい落とし穴に落ちますよ。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:1, 参考になる)
#カカクメソッド最強
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:1, すばらしい洞察)
オタク的な偏執さが無いとやってられないような気がする > セキュリティ対策。
相応のポスト、給与、時間とマンパワーが貰えているならともかく、そういった
幸せなケースは少ないんじゃないかな?
ところで、後学のために「オタク系エンジニアが落ちる落とし穴」がどんなものか、
教えていただけますか?
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:2, 参考になる)
この話には古い技術基盤で提供されているサイトという前提条件がつきます。
またオタク系とは、技術的妄執の多寡ではなくて、コミュニケーション能力が欠如もしくは不足している人を指します。
SQL Injectionが発生するのはどのような時かを考えれば分かると思いますが、この場合問題になるのはPrepareを使わずにSQL文を動的に作成している場合において、チェックと置換を行わなかったら起こるというのが基本ですよね。
Prepareが使えないCGI環境において、入力値の徹底をさせるにはテストによるものだけでは不十分です。
私が見たものだと、GETパラメータとPOSTの場合のTEXT BOXのリクエストパラメータのチェックは全て行っていたがものの、それ以外のチェックは行っていなかったなんてのがありましたし、リファラをチェックしていてホワイトボックステストでは脆弱性がみつけられないようになっていたなどというのもありました。
# /.erならば、これがどれほど危険かはよくお分かりになるものとおもいますが、こんなのは対策しているうちに入らないですよね。
この場合は、コードレビューによる洗い出しとあいなるわけですが、多くのWEBアプリ開発においては掛けられる開発コストは極わずかであり、近年はますます内容が高度化しているため、そのような費用が出ません。
この条件化において、一番手っ取り早い解決策は、SQL文は動的に作成せずプリペアを利用しているかどうかのコードチェックのみにする事で、つまり利用するプラットホームを最低でもプリペアが使えるレベルにしてもらうという事なのですが(そうすれば動的にSQL文を使っているかどうかだけ見ればいいので)、そのような決定権を持っている人は移行リスクや移行コストなどを考えるわけですから、ただ言っただけでは許可が下りません。
そこで提案・交渉となるわけですが…いくつか見てきた物だと、どうも技術者側の提案は「安全になります」の一点張りか、補足説明があっても技術用語の羅列で終わってしまう内容で、論点がすれ違っているわけです。
例えばSQL Injectionが突かれた例を見せ、経営に対してどのような影響がでるかという方向からの説得やら (カカクコムのおかげで大分やりやすくなりましたが、それでも自社の規模を見て「注目されてないから」と言われる場合は多くあります) 、とりあえずPreparedStatement をなんとかするべく、パフォーマンスや開発工数の短縮に関しての長期視点でのコストの予想曲線を書いたりとか、なるべくお金に関わるように言えばいいのですが…。
というわけで、交渉のところで大体失敗するのですね。そして穴に関する知識があっても、実際ミスでふさいでいない部分が残っていたりしています。
お金を管理する人たちの多くは技術者じゃありませんので技術視点でせめても仕方ないにもかかわらず、困ったものです。経営者の怠慢と言うならば、それを指摘し、正常な方向にもっていくのも、十分おまえらの仕事じゃないのかと思うのですがね。
私が関わってきた技術者だけですと言い切ってもらえるのなら、それはそれで安心なのですが…。
>オタク的な偏執さ
は必要でしょうが、オタク的な交渉能力のなさは要りません。
プログラムの作成だけに目を向けていられるのであれば問題はないでしょうが、事コストと絡めて上から攻められると、どうしてもチェックをもらさなければならないということはあるのではないですか?
もっとも、この話はカカクコムにはホボ当てはまらないでしょう。
あそこは近年、十分キャッシュをためてきていて安全性に対するコストを支払っても十分に黒字をたたき出すことは可能だったはずですし、実際セキュリティ監査も入れていたようですから。
しかし、セキュリティ監査を入れていてもSQL Injectionの穴が塞がれてなかったとは、内部で何が起きていたのでしょうね。
監査会社が低レベルだったのだろうか。
それに、こういう話はあと数年もつかもたないかでしょうね。
数年後には、いい加減ここらの技術移行は完了している…と思いたい…。
長文、失礼致しました。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:2, 参考になる)
>Prepareが使えないCGI環境において、
(Perlによる)CGI = prepareが使えない
という意味であるとしたら、それは少し間違いです。
DBIモジュールにprepareはちゃんと実装されています。
Perl本体に実装されているわけではないですが、DBIモジュールはPerlでDBを扱う際には開発効率の観点からも広く使われていますので。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:0)
分かりにくかった。失礼。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:2, おもしろおかしい)
2次元キャラ・声優・制服等で釣れちゃう事(違)。
#ヘタに知識が多いが故に、
#視野狭窄に陥りやすく(一方向からしか見れない)、
#想定の範囲外の事が起きた場合のパニックが半端じゃない。
#ってのはあるのかも知れない。オタク系に限らないけど。
--
「なんとかインチキできんのか?」
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:2, おもしろおかしい)
> 2次元キャラ・声優・制服等で釣れちゃう事(違)。
類推可能でアレなホスト名/パスワードだから、一台に侵入されたが最後全サーバを蹂躙されてしまうというのが「オタク系エンジニアが落ちる落とし穴」だと思っていたのですが…。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:0, フレームのもと)
>教えていただけますか?
無理言いなさんな。「ああおれって真実が見えていて鋭い指摘しちゃってかっこいい」って
いい気になってるんだから、いい気分でいさせてあげなさいよ。野暮だねまったく。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:0)
上司が「ウチはSQLインクジェットは大丈夫か?」と聞いてきた
↓
冷やかな目で見てしまい、間違いを訂正できなかった。
↓
上司が取締役の前で「SQLインクジェット」と言った。
↓
上司との関係が悪化した
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:0)
「SQLインジェクション」と聞くと「あぁ、キャブレターより高効率だ」と連想してしまうこと。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:1, すばらしい洞察)
セキュリティ対策においては無知自体が罪(の一部)であり過失(の一部)です。
ましてや、WEBアプリケーションに限らず情報処理系に身をおきDBを使用するアプリケーションを扱う者であればSQLインジェクションの対策などは基本中の基本です。
>”無知が故”
無知が全ての原因ではないが、今回については多くの部分で問題の根幹になっている事は確かでしょう。
また、そんな基本すらなされていなかった状態で”過失はなかった”、"最高のセキュリティ"などとよく言える者だということです。
Re:直接のウィルス配布実行犯じゃなくても。。 (スコア:1, すばらしい洞察)
そして隠蔽もだ。 同じ穴を突かれる危険性は高い。