冷たい方程式（20） 2人目の脱落者
週が替わってもムツミさんは復帰しなかった。報告に訪れた八木社長の話によると、やはり疲労が相当たまっていたようで、ドクターストップがかかったらしい。とりあえず、今週いっぱいは休養して、来週のことは週末時点での体調を見て決めるそうだ。
とはいえ、ムツミさんの復帰をのんびり待っていることは、開発の進捗状態から考えてもできないだろう。少なくとも、渕上マネージャが放置しておかないだろうな、と思っていたら、八木社長から報告があった30分後に、あたしと亀井くんはその対応策を知らされた。
「片寄さんが抜けた分、一部のタスクをサードアイにやってもらうように話をつけた」渕上マネージャは、いつものように前置き抜きで始めて、あたしを見た。「設計書など必要なものを送っておくように。割り当てタスクは後で知らせる」
あたしはタスクボードを見た。確かにホライゾンレーンのタスクカードの数が減っているようだ。
「分かりました」
続けて渕上マネージャは、亀井くんに、ムツミさんの代理としてホライゾンチームのサポートを行うよう命じられた。
「亀井くんですか」あたしはちょっと不安を感じずにいられなかった。「私がやった方が……」
「何か問題でも？」渕上マネージャは素っ気なく聞いた。「日比野くんは、シフト管理機能で手一杯だろう。亀井くんのテーブル設計はほとんど終わっているし、もともと管理系の担当者として、ホライゾンシステムとの窓口になるはずだった」
「それはそうですが……」
「亀井くんにもマネジメントの経験となるだろう」
あのチームの中で、ムツミさんが果たしていたであろう役割を、あたしは思い浮かべていた。Servlet もTeeda もろくに理解していないメンバーが、Unitテストだけで済むようにインターフェイスの粒度を設計し、上がってきたロジックをWebアプリケーションとして成立するように編み上げていく。しかも、自分の実装もこなさなければならない中で。社内SEというぬるま湯につかってきた亀井くんに、そこまでの芸当が可能だとは、とても思えない。
あたしの心配をよそに、亀井くんはやたらと張り切っていた。
「大丈夫ですよ」亀井くんは胸を張った。「ムツミさんが戻ってきたときには、タスクボードを空にしてみせますから」
「余計なことしなくていいから」あたしはたしなめた。「現状維持すれば御の字なんだからね」
あたしの心配なぞ、どこ吹く風とばかりに聞き流し、勇んで開発室に乗り込んでいった亀井くんだったが、半日もしないうちに顔をしかめて戻ってきた。
「あいつら、何にも知らないんですよ」亀井くんは、吐き捨てるように言った。「Teeda のページテンプレートの意味も理解してないし、id を合わせる必要性も知らない、S2Daoの@Argumentsアノテーションさえ見たことがない、って感じで。よく、今までやってこられたな、って言いたくなりますよ」
「まあ、それは……」あたしは先日見たホライゾンチーム作のソースを思い出した。「……そうだろうね」
「これ、見てくださいよ」亀井くんは、自分のPCでEclipseを開くと、バージョン管理システムからいくつかのソースを落とした。管理系の画面らしい。「ほら」
あたしは開かれたソースを見た。従業員マスタを、何かの条件で検索しているようだ。
「ああ、なるほど」あたしは嘆息した。「これはひどいねえ」
where句やorder by句を、文字列の連結で作ってしまっている。ウェルカムSQLインジェクションなコードだ。
「ですよね」亀井くんはプンプン怒っている。「渕上さん、あれだけ細かく進捗確認してるくせに、こういうところをチェックしたりしないんですかね」
「そんなスキルも時間もないんだろうね」あたしは応じた。ある程度の知識があっても、フレームワーク毎の定石などは、やはりやってみないと分からないところがある。
「それに、渕上マネージャが見るときまでには、ムツミさんが修正してたんだろうし」
そう言いながら、あたしは、もう何度目になるか分からないが、ホライゾンシステムを選定したことを後悔していた。こんな素人に毛が生えた程度のプログラマを、何食わぬ顔で送り込んでくる八木社長にも困ったものだが、体調を崩してまで必死でメンバーのコードを修正していたムツミさんに対しても、同情すると同時に苛立ちを感じる。そんなことするぐらいなら、多少、時間がかかってでもメンバーに基礎を学習させた方が、最終的には生産性が上がるだろうに。
「とにかく、もうイヤになりましたよ、あいつらには」
「まだ3時間でしょ」あたしはたしなめた。「あんた、忍耐ってものがないの？」
「さっき使い果たしました」亀井くんはきっぱり答えた。「もっとマシな奴らをよこすように、八木社長に電話した方がいいんじゃないですか？」
ホライゾンシステムに余剰人員などいない。そのことは、昨日、来社した八木社長からムツミさんの具合を聞いたときに、ついでに確認してみた。そのときの言葉を借りるなら、「逆さに振ってもチリひとつ落ちない」という状態らしい。本来なら、ムツミさんを含めて4名も1つの案件に拘束されるような事態は、絶対に避けたかったにちがいない。
あたしがそう言うと、亀井くんは肩を落とした。
「やっぱ、そうですか」
「もう一度、渕上さんに話してみようか」
「いえ、いいです。もうちょっと何とかやってみます……っていうか、奴らにやらせてみます」
亀井くんは決意も新たに戻っていった。
その日は火曜日で、ホライゾンチームメンバーの進捗報告を行う日だった。いつもなら、ムツミさんが子供を心配する母親よろしく付き添うのだけど、今日は亀井くんが代行だ。
実を言えば、この進捗報告が一番心配だった。ソース上の不備なら、あとでいくらでもリファクタリングできるけど、渕上マネージャに細部の瑕疵を突っ込まれたとき、亀井くんでフォローできるだろうか。ましてや、これから渕上マネージャがチェックするのは、ムツミさんによってフィルタリングされていない、未熟そのもののソースだというのに。
悪い予感ほど当たる。うまくいきそうにないときは、必ずうまくいかない。見てほしくないコードほど、マーキングしたように目立つ。そんな数々のいまいましい法則が、この日も適用された。
最初の１人――例のフレッシュな人材だった――の進捗報告が開始されてから10分後。いつもよりはるかに短い時間で亀井くんは戻ってきた。その顔には、ゆで卵だと思っておでこで割ったら生卵だった、とでもいうような呆気に取られた狼狽が浮かんでいる。
「早いね」あたしは声をかけた。「どうしたの？」
亀井くんは席に座ると、ふーっとため息をついた。
「あいつ、いきなり泣き出しました」
「は？」あたしは驚いた。「泣いた？」
「はい。男のくせにボロボロと」亀井くんはお手上げというように天を仰いだ。「いい加減にしてほしいですよ」
亀井くんによると、進捗報告を開始してすぐに、渕上マネージャは例によってスケジュール遅延の原因を聞いたらしい。訊かれたメンバーは、ムツミさんが休んでいるため、思うように進まない、と正直に答えたそうだ。
「そしたら渕上さんが、ソースを確認し始めて」亀井くんは深いため息をついた。「まあ、いろいろおかしなところがあるじゃないですか。それを上から順に指摘していったんですよね」
その際、いくつかきつい言葉が投げつけられたらしい。メンバーは少しの間、それに耐えていたが、唐突にポロポロと涙をこぼし始めたという。
「ま、それで、さすがに渕上さんも進捗報告を中断したというわけです」乾いたうつろな笑いが亀井くんの口からもれた。「泣きますか、普通？」
あたしも呆れて、しばし言葉を失った。ユーザー企業の担当者などに無理難題を押しつけられたエンジニアが、つい怒鳴り返してしまったとか、辞意を宣言してしまったとか、ひどい場合になると手を出してしまった、というのは、たまに耳にするが、泣き出したというのはちょっと聞かないパターンだ。あたしだって、仕事のことで泣いたことは一度や二度ではないけど、それはトイレでとか、非常階段の踊り場でとかであって、人前でというのはない。
「……で、その彼は？」
「さあ、知らんですよ、なんか、泣きながら帰ってしまったみたいですけど」
亀井くんが投げやりに答えたとき、渕上マネージャがゆっくりと戻ってきた。内心はどうあれ、いつものように無表情で、世はなべてこともなし、という顔だ。
「亀井くん、次のホライゾン社員の進捗報告を行う」平板な声が命じた。「準備したまえ。2分後に開始する」
「さっきの泣き虫くんはもういいんですか？」亀井くんは――たぶん嫌みで――聞いたが、渕上マネージャは無視して出て行ってしまった。
「やれやれ。懲りない人ですね」
「次は泣かさないように、きちんとフォローするのよ」あたしは釘を刺した。「ムツミさんが戻ってきたとき、1人も残ってなかったら困るから」
「片寄さんも、あんな奴らの尻ぬぐいをさせられてたなんて、とっても気の毒ですよ」
あたしの意見は少し違うが、それを表明する前に、亀井くんはさっさと立ち上がって出て行ってしまった。
45分後、八木社長が飛んできた。渕上マネージャは、まだ進捗報告を受けている途中だったので、あたしが応対した。
「どうもご迷惑をおかけして申しわけありません」
深々と頭を下げた八木社長を制して、あたしは気になっていたことを聞いた。
「で、えーと……」そういえば、名前も知らなかった。「彼はどうですか？ 大丈夫ですか？」
「とりあえず今日は帰らせましたが……」八木社長は苦しそうな顔で答えた。「……ちょっと繊細なやつでして」
「そうですか」繊細というのとはちょっと違う気がするが、そこを突っ込んでも仕方がない。「こちらの管理にも問題があったと思うんですけどね」
「いえいえ、とんでもありません」八木社長は小さく頭を下げた後、ためらいがちの小声で続けた。「すぐに代わりの人員を、と言いたいところなんですが……」
本当の目的はこっちだな、と気付いた。さすがにもうストックがないのだろう。
「人がいないんですよね」あたしは確認した。
「はい、残念ながら」
だからといって、はいそうですか、と受け入れるわけにはいかない。
「残り2人ではちょっと難しいのじゃないですか？」
「はい、おっしゃるとおりです。その代わりというわけではないですが、片寄が月曜日か、遅くとも火曜日から復帰できることになりました」
「身体の方は大丈夫なんですか？」亀井くんが喜ぶだろうな、と思いながら聞いた。「あまり無理されても」
「本人は大丈夫だと言っていますので」
「あの、もし何なら、スケジュールの調整を渕上と相談してみましょうか？」
「いえ、大丈夫です」八木社長は拳を固めて宣言した。「死ぬ気でやらせますから」
――死なれても困るんだけど
そういう精神論で何とかなる段階を、すでに超えてしまっている気がする。そんなふうに、すぐに安請け合いすると、足元を見られて買い叩かれますよ、と忠告してあげたいところだが、客の立場のあたしが言うのもおかしな話なので黙っていた。何とかやってもらうしかないのも確かだ。
「分かりました。できるだけフォローはします」
「よろしくお願いします」
泣きながら職場から逃亡したホライゾンのメンバーの顔を、あたしたちが再び目にすることはなかったけれど、そのことに驚く人は誰もいなかった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
不治ソフト
亀井くんにはマネジメント以前に別の勉強が必要なんじゃないか？
BEL
>何食わぬ顔で送り込んでくる八木社長にも困ったもの
>多少、時間がかかってでもメンバーに基礎を学習させた方が、最終的には生産性が上がる
>体調を崩してまで必死でメンバーのコードを修正していたムツミさんに対しても、同情すると同時に苛立ちを感じる
ここでどなたかがコメントしてたことを主人公も思っているようですね。
>辞意を宣言してしまったとか、ひどい場合になると手を出してしまった、というのは、たまに耳にする
聞いたことない。。少なくとも後者は
>その代わりというわけではないですが
最初からいるはずだった人が"代わりに"っておかしいな。。
東海林さん降臨はひっぱるなあ。1人ではないだろうに一緒に誰が来るんだろう。
細川くんかなあ。川嶋さんが来て亀井くん乗り換えとかだったら面白い
rurie
亀井君は人事考課表を読み上げられて
初めて後悔するタイプだなｗ
greed
>東海林さん降臨はひっぱるなあ。1人ではないだろうに一緒に誰が来るんだろう。
常駐ではない、と書いてあるので、たまにしかこないのでは？
Edosson
ネズミ叩きのネタが無いじゃないか。ホライゾンはどうでもいいし。
しかし、このペースじゃ、プロジェクト崩壊でエピローグかな。
東海林さんvsネズミは目にすることができるんだろうか。
saboten
ホライゾン側のムツミさんフィルター作戦が機能しなくなり、
徐々に問題が顕著になっていますが、いまだに溝が埋まりませんね。
ふっちー・亀井君はホライゾンPGの能力が低いと感じるだろうし、
ホライゾンPGとしては、今さらフレームワークをどうこう言われても理不尽にしか映らないでしょうね。
打開のカギは主人公かサードアイか…
しかし、八木社長はムツミさんから現状の報告を受けてないのかなぁ。
二人脱落した状況で乗り切れると考えてるなら、無策すぎるし、
既に見限っているなら精神論はフェイクだけど…キャラがいまいち掴めない。
yas
> 「ムツミさんが戻ってきたときには、タスクボードを空にしてみせますから」
空になっているのが開発室でなければ良いが。
elseorand
泣き出したのは、渕上マネージャも流石に面食らっただろうな。
蓋し技術的素人でも、自己学習できなくても働いてくれるだけマシと思います。
後は教育を怠らないこと、１～２割はプログラマーとして精鋭になってくれます。
ですが、使い物にならない割合が、
Joel on Softwareで「いくら成績優秀でも40～60%はプログラマーにはなれない。」なんて言われているように、会社としては看過できない割合で、
これは義務教育から大学の間で予め排除していただけると、
ありがたいのですよね。
捕鯨
進捗会議で他人がなじられてるのを見ると暗い興奮を覚えて一緒にチクチクやるような最低な人間になって仕事を辞めたことを思い出した。
rurie
そういえばこの職場では他人の足を意図的に引っ張る人が居ないね。
自分の能力を相対的に良く見せるのに
互いの足を引っ張り合ったり、責任を押し付けあったりする人たちに
嫌気がさして仕事を辞めた事を思い出したｗ
今思い返してもあれは地獄だった・・・
うとぅん
ソース全部がこんなノリだったら・・・。
もう割とキレていいレベルな気がしますね・・・。
趣味でしかプログラミングしたことが無い香りが漂っています。
いや、趣味でもインジェクション対策くらいはするか・・・。
まぁ、実際の開発現場でも、業務経験2年とかあってもこれ系やる人いますよね。
類二
>これは義務教育から大学の間で予め排除していただけると、
>ありがたいのですよね。
高校や大学はプログラマー養成学校じゃない。
そういうことは専門学校に求めるべきで、専門学校はそこに存在意義があるだろう。
とむ
進捗報告の場で、ソースコードレビューをやっているってのは、おかしくないかい？＞渕上マネージャ
個別にレビューやってたら、時間は足らなくなるし、他の人へのレビュー基準の周知にもならなくない？
ウェルカムSQLインジェクションなコードは、インターネットで公開するシステムでなく社内利用のシステムで、炎上プロジェクトならば、後でリファクタリングすれば良いと考えて、とりあえずは修正せず進めてよいと思える点なのではないのだろうか？
elseorand
>>類二さん
高校・大学に養成はしてもらわなくてもいいのですが、
「私には絶対無理だ」と挫折してもらえると助かるという話です。
更に大学は「ポインタ分からない人間は、単位は一切不可」としてくれると、
とてもありがたいのです。
「ポインタ理解できなくても、計算機を修めた」なんて大学が単位出しているくらい、現状甘甘ですから。
CMP
みなさんがだめだこりゃと言うほど、ウェルカムSQLインジェクションなコードにはなってないと思うのは俺だけかな・・・？
もちろん、作者が見せているソースだけの話でですよ。
「見せているソースでもここがだめだ！」って教えてくれるとありがたいです。
ちなみ現場では、趣味でもプログラミングをしたことない実務経験3年以上の自称プログラマはいくらでもいますよ。
一番びっくりしたのは、あるWebアプリケーション開発で追加投入された人なのですが、休憩時間に「この手の仕事の経験あるの？」という質問に対し「JavaやJavaScriptはわかりませんが、得意なプログラミング言語はJSPなので大丈夫です！」と真顔で答えた実務経験4年目の（ｒｙ。
fuse
>「見せているソースでもここがだめだ！」って教えてくれるとありがたいです。
文字列連結でやるなら、シングルコーテーションのエスケープをやらないとダメですね。
普通はパラメータークエリをつかって、かつ必要なワイルドカードなどのエスケープをするって話だとおもいます。
ほまらら
>ウェルカムSQLインジェクション
そりゃまあ、安全に組むに越したことはないんでしょうけど・・・
インターネット上からのアクセスが可能だってんならともかく、
社内の勤怠管理でSQLインジェクションかまされるって、
どういう会社ですかそりゃ。
「悪意のあるユーザが端末に触れる事はない」という言質を一発取って、
Formレベルで入力可能文字設定してバリデーションかけりゃ十分でしょう。
っつーか、サンプルコードで変数化してるのは『日付』と『コード（多分）』っぽいし、
SQLインジェクションを気にするべき所ですかねコレ。
kazu
selectkindとかはバリデーション使って、禁止文字が入らないようにしてるんじゃないの？
くくな
たまたまこのコードでは、SQLインジェクションの可能性は低いかもしれんけど、
こういうコーディングする奴は、その可能性があるケースでも、
同じノリでやるに決まってる。
主人公は、そこを問題にしてるんでしょうね。
組込系
>ウェルカムSQLインジェクション
専門外なのでよく分かりませんが、14話の自宅のPCや携帯からエントリする機能があるからダメなんじゃないかしら。
別の通りすがり
ちょっとしたコードで本質的に安全なクエリになるのに、そうしない人の気が知れない。
つか、この程度のやりかたメンバーに教えとけってことだよな。
regc
yasさん、類二さん、elseorandさん
ええと、現状の（情報系）専門学校ではC言語のポインタを理解していなくても、
卒業できてしまいます
それは、１８歳人口の減少に伴い、専門学校に進学してくる学生が「お客さん」に
なってしまっているからです。企業でも「お客さん」には厳しことはなかなか言え
ませんが、それと同じで専門学校では「お客さん」である学生に対して、なかなか
「ポインタ程度も理解できない」学生に対して単位を出さない（卒業させない）と
は言えません。専門学校の経営層は完全に素人なので、目に見える情報処理技術者
試験の合格率やら就職内定率にしか関心はないため、講師の「せめてポインタぐら
い理解して卒業しなさい」という考えもオーバーライドされてしまいます
専門学校に来る学生たちにも問題があります。専門学校は無試験なため、高校時代
勉強が苦手でテスト受験が嫌な学生が集まります。そのような学生が多数を占めて
しまうと、「これまでも勉強しないで何とかなってきたんだから、これからも何と
かなるに違いない」と講師がどのような教材で教えても、学生は理解しようとはし
ません
かくして、専門学校ではあり得ないほど単純化した教材を、あり得ないほど時間を
かけて教えるのが精一杯になってしまうのです。いわゆる、できる学生にとっては
まったく物足りない教育しかできないのです
以前にもできない学生はいました。しかし彼らは途中でやめてしまうか、プログラ
マ以外の職に就いていましたが、最近では「ポインタすら理解できない」学生が、
堂々とプログラマとして（場合によってはSEとして）就職してゆきます。そのうち
のごく少数の学生は、就職後目覚めることもあるかもしれませんが、一般に予後は
とても悪いようです
とても、今後の世界に展望が持てるとは言いがたいのがこの世界です
大木
>>更に大学は「ポインタ分からない人間は、単位は一切不可」としてくれると、
とてもありがたいのです。
どこからが、ポインタを理解したと言えるのか。
そして、ポインタが分かったから如何なのよ。
って気持ちはありますけどね。
スタックオーバフローを起こすコードが分からなかったとしても、
スタックオーバフローを起こさないコードはポインタを正確に
理解していなくてもわかるから。
ただ、「実体」と「実体でないもの」の区別ぐらいは、
ポインタに限らずできないとなぁ・・・
そういう意味で、「実体でないもの」をまとめて「ポインタ」と
呼ぶのは分かりやすいし、意図を伝えやすい(述語と言うよりも
ポインタの方がより多くのプログラマに伝わる)。
ただ、そういうのは年寄りがゲーム機をまとめて「ファミコン」と
言うのに似てる気がする。
いなくなったのは二人とも、
亀井さんと渕上さんの共同戦果ですねえ。
渕上さんは当然として、
亀井さんもなかなか。
このぶんじゃ片寄さんが倒れたのも、
半分くらい亀井さんのせいだとしても不思議はないですな。
部屋にでも押しかけたのか？
>Joel on Softwareで「いくら成績優秀でも40～60%はプログラマーにはなれない。」なんて言われているように
ジョエルさんが一人前のプログラマーと認識しているのは、
ライブラリの裏の裏まで知り尽くして使いこなせるようなプログラマーですからねえ。
そんなものにはなれない人間が６割いても、いや９割くらいまでなら、
ライブラリの裏までの知識が必要な局面にのみフォローすれば、
大丈夫でしょう。
会社を興して天才のみを集めて会社を作る気があるような人はともかく、
そうではない人間は、適材適所で適当な仕事を割り振って、
なんとかしないと。
あえてないものねだりをしていても愚痴にしかなりません。
そもそも今、本当の意味でポインタの意味が分からないとできない仕事って、
どれだけあります？
Javaとかでもわかってないとたまにわけのわからないバグを仕込むかもしれませんが、
たまにバグを出したからといって使えないというほど贅沢な職場はどこの業界でもあまりないでしょう。
名も無き哲学者
>精神論で何とかなる段階
精神論でなんとかなった現場って一度も見たことないんだが
自分が幸せなだけなんだろうか
CMP
>>答えてくれた皆様
回答ありがとうございました。
ここでは問題なくても、他も同じなら・・・ってことですね。
ついでに、もうひとつ質問いいですか？
そもそもSQLインジェクションは
①UI側（もしくはクライアント側）で対応すべきなのか
②サーバ側で対応すべきなのか
③両方で対応すべきなのか
ちなみに私は①でやるべき派です。
ぽんた
もう何年も現場ソースとか見てない俺ががんばって見てみるぞ！
ふむ、確かに今回のケースではSQLiな部分はチェックがしっかりしていれば機能としては問題ないように見え
ますね。
でも、チェックがしっかりしていなかったら、または名前とか不定な文字列検索とかだとどうすんだ！
って話になるとそもそもSQLi・XSS・CSRF・etc..とかいったセキュリティ対策はプログラマ個人がどうこうと
いう問題ではなく、プロジェクトとしての開発規約やガイドラインがどうなのかって話になります。
（出番だよ、渕上マネージャ！）
それよりも、employmentEndFlagの条件がIS NULLだったり（最近はDBや貼り方によってindexは効くといっても
フラグにnullを定義する気持ち悪さ的な）
DAOのメソッド名がマジックナンバーとかだったりする設計の問題のほうが気になるのは、俺の見方のほうが古い
からですか、そうですか。
あと、ちょっと気になるのが「知っている・いない」ということが連載を通してクローズアップされすぎて対人
論法（個人攻撃）的な側面になっちゃてる感じがします。（ここのコメントのやりとりに感化されたか？（笑））
ここを見た若い人が知識さえあればステキな開発ができるんだ！と思ってしまわないか多少心配です。
（もっとも「教われども学ばず」というのはこういうことだよ！というオチが最後にあるのかも知れませんが）
今や知識なんて探そうと思えばgoogleの中にありますからね。それより様々な考え方（メタ知識）を身につけて
欲しいですね。（なにこの上から目線）
ぽんた
なんか改行がズレてるな！きっとなんかカッコイイこと言おうとしたせいだな！
カッコわるいな！
BEL
>常駐ではない、と書いてあるので、たまにしかこないのでは？
あ、そうでしたね。
もしかして東海林さんサイドはストーリーにはあまり絡んでこないのかなあ。
>①UI側（もしくはクライアント側）で対応すべきなのか
>②サーバ側で対応すべきなのか
>③両方で対応すべきなのか
どういうシステムを想定しているかによって答え方は変わりますが、
サーバーでやるのは大前提で、必要に応じてクライアントでもやります。
だって、サーバー側でやらなかったら、自分が作ったクライアント以外の
何かでアクセスされたら無防備ってことですからね。
そもそも文系の大学を出た人とか大学を出なかった人とかが普通に技術者に
なるし、大学や専門で学んだことって、実務で必要な知識・技術のうち
微々たるものにしかならないので、新人は基本何も知らないくらいに思っとく
べきですね(新人研修だって大した技術身につかないし)。
そりゃ、基礎だけでも身に着けた状態で来てくれればありがたいですが、
それよりも、新人は柔軟性・吸収力・従順さがあった方がのちのちありがたい。
別の通りすがり
ちょっと一緒に仕事するのマジ勘弁な人続出でカルチャーショックだわ。
まー、俺と仕事するのもマジ勘弁だろうけど。
ポインタなんかわかって当然。
SQLインジェクションの対処方法はggrks。
マジでクラクラするわ。
みなさま、どうも。リーベルＧです。
コメント欄が活発で嬉しい限りです。
それで、ひとつお願いなのですが。
いわゆる丸数字ですが、使っているPC/Macや、ブラウザの種類によっては、文字化けする可能性がありますので、できれば避けていただけると嬉しいです。
最近のブラウザなら問題なく表示できるとは思うのですが。
次週のサブタイトルは、ドリカムの曲名です。
へろへろ
おお、作者降臨だ。
>次週のサブタイトルは、ドリカムの曲名です。
といわれてググって見たら、
「沈没船のモンキーガール」とか、
「かくされた狂気」とか、
「ウソにきまってる」とかの、
あんまりなものばかり目に付くから困る…。
「決戦は金曜日」はどっちかというと前作っぽいし、「WINTER SONG」か
「未来予想図」あたりと予想。
fuse
>そもそもSQLインジェクションは
呼び出されるクラスが、呼び出すクラスのやることを想定することはできないので、基本的に呼び出されるクラスの側の責務としてSQLインジェクションをさせないつくりにする必要があるとおもいます。
呼び出す側(Viewなど)でチェックするかどうかは、呼び出す側の都合で変わります。
Webシステムの入力画面を想定されているなら、おそらく両方でやることになるとおもいます。
elseorand
>>regcさん
はい、専門学校を話題にしなかったのは、仰る通りの点です。
そもそも勉強する習慣が身についている専門卒は殆ど見かけません。
（まぁ大卒でも、受験時代を思い出してもらうのに少々の手間はかかりますが）
>>まりもさん
現状はつくってくれるだけありがたいとは思っていますよ。
ただポインタを理解できない人のIT業界での生存率は高いように見えないため、
悲惨だからあまり来てくれるなと思うわけです。
（生存率：マネジメントの適正もなく生ける屍と化したPMは死亡と判定します）
saboten
>今や知識なんて探そうと思えばgoogleの中にありますからね。それより様々な考え方（メタ知識）を身につけて欲しいですね。
同感ですね。
むしろ、ggr技術の高い人がエース級だったり。
ポインタとかセキュリティの話は、勉強会で数日あれば習得できるレベルなので、
会社に技術的な空洞がない限り、そんなに問題視しなくてもいいと思いますね。
アセンブラ経験者としては、
CCOBOL等の古い言語やC以外で、
メモリアドレスを意識する機会がそんなにあったっけかなー?という感じです。
参照型とかオーバーフローとかそういうレベルかな？
wm
>そもそもSQLインジェクションは
データベースに挿入する直前ですね。だから、普通はプリペアドステートメントを使えば防げるという話になるんですよ。
>ポインタとかセキュリティの話は、勉強会で数日あれば習得できるレベルなので、
そんなに楽な話なら・・・というかたぶん、知識を習得しても実践出来ない人がいるんじゃないかな？
（前の60％がプログラム出来ないみたいな話で。）
つか、体系的にポインタとかセキュリティの話を叩き込めるような講座なりなんなりがあるのなら、教えていただけるとありがたい。
elseorand
>>sabotenさん
ポインタとかは教える側はとりあえず勉強会なら数日ですが、
相手が理解するところまでフォローすると平均数ヶ月な感覚です。
（ただし、数年繰り返し教えてもどうやっても理解できない人は数割は居ます）
後は、Googleの中には存在はしますが、適切なものを選択してくれるとは限らないわけで・・・
エース・精鋭「なら」、ggったり人から聞いたりして、適切な物を素早く選択できますね。
あとポインタはCで、Javaには直接は関係ありませんが、
間接的に参照とstatic、グローバル変数の危険性の理解の時に関わってきます。
あと出番は少ないですが、高速な定期バッチ処理が必要で、
マルチスレッド処理を組まなければならないときは、
ThreadLocalで楽はできますが、理解していない人間だと思わぬコーディングをしますね。
error401
関係無い話で恐縮だがちょっと一言。
ポインタ（と再帰）に関しては、Joel Spolskyの「Javaスクールの危険」(http://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA) が興味深いので、読んだことが無い人は読むと良いと思う。
そして、それを契機に日本ではちょっとした議論が巻き起こった。「Javaスクールの危険」でググると関連記事を見つけられる。
これらを読んで、Joelが期待するような「優秀なプログラマ」にはならなくても良いと考えるも良し、ポインタと再帰なんてできて当然と考えるも良し。
ボビムシ
泣き出して、来なくなったんですね。
さすがに「人前泣き」は聞かないですけど、「来なくなった」はよくありますね～。うちの会社でも最近ありました。
PGとしては割と優秀だと思っていた２年生なんですが、文中で語られているように「繊細」なのか、「根性」が足りないのか、「うつ」なのか。
多分上記全部が少なからず当てはまるんですが、自分が抜けた後の周りの事も考えてほしいものです（うつは仕方ないですが）。
やはり中学校、高校あたりで、きつめのクラブ活動で心身ともに鍛えて、根性つけてもらいたいです。心身ともに鍛えられた人だと、人前で泣いて仕事を放棄する事なんてないでしょうね。
あってもきっと周りも納得するレベルの事が発生した場合でしょう。
saboten
>そんなに楽な話なら・・・というかたぶん、知識を習得しても実践出来ない人がいるんじゃないかな？
（前の60％がプログラム出来ないみたいな話で。）
まぁそうですね。全部が全部勉強会だけで理解できるわけではないので、
実践で技術を磨くことにはなると思いますが、経験者がフォローできるなら、
組織的に見て、そこまでクリティカルな話ではないと思います。
60%の話でいえば、
どれだけ努力してもポインタを理解できない人がいるということですかね。
習熟度に差はあるでしょうが、
指摘された内容を理解できないというのは稀だと感じますね。
というか、このふるい的な理論は、煽り要素メインな感じがしますねwww
技術のバックグラウンドをどこに置くかは属するハッカー文化というか、
各個人の主張によると思うので、
個人的に新人には伸び伸びと技術を身につけて欲しいですねー。
くくな
知識はいらん、ググればいい、なんて言ってる人がいますが、
ネット接続不可、携帯持ち込み不可、という環境はけっこうあって、
そういう場所だと全く使い物にならんですね。
何から何まで暗記しとけとは言わないけど、基本的な部分ぐらいは、
身体に覚えこませておいてほしいもんです。
error401
個人的な感想ですが、知識もスキルも無い人はググれる環境にいても必要な情報を得ることができないか、誤った情報を鵜呑みにしてしまう可能性がありますね。
例えば、S2Daoでデータベースアクセスをする方法がわからないとき、最初に見つかったのがバインド変数を使わない文字列連結方法だった、みたいなことがありえます。
また、知らない知識をググって手に入れることができる人でも、どう設計すれば良いかレベルの問題は、ちょっとググった位では手に入れられません。
シフトを自動で組みたい、という要求があったとき、これもちょっとググってもわからない問題です。
くくな
個人的には、ググる前に、ドキュメントを読んでほしいもんです。
saboten
はは、もちろんググるのが全てとは言いませんが、
ある程度のメタ知識があれば必要なものを調べれるので
ある特定の知識がないこと = 能力が低い に直結しないということです。
経験はもちろん必要ですよー。
error401
いやその必要なものを調べられるだけの、ある程度のメタ知識が無い人が問題だ、ということを言いたいんですが…。
saboten
>error401
ええ。私もメタ知識が重要だと思っていますが、何か問題でも？
error401
だめだ、かみ合わない。
申し訳ないが、この件については私は離脱。
wm
>このふるい的な理論は、煽り要素メインな感じがしますね
煽り的な要素があるのは同意ですが、
>どれだけ努力してもポインタを理解できない人がいるということですかね。
>習熟度に差はあるでしょうが、
>指摘された内容を理解できないというのは稀だと感じますね。
こちらはどうでしょうね？
肉体的な話なら「なぜか」みんなすぐ納得するんですけど、「脳みそ」の話になるとなかなか納得しないんですよね。
まぁ、努力すれば、誰でもバク転やらヘッドスピンやらできるとでも思ってるよーなもんですよ。
BEL
今現在、日常的に仕事でプログラミングしている人の半分以上が
ポインタの基本的な理論すら理解していないんじゃないでしょうか。
特にJavaや.NETなどから開発を始めた人とかは。
(そもそも言語がそういうのはフレームワークに任せましょって趣旨だろうし)
HTTPヘッダ等の内容をほとんど理解してなくてもWEB開発ができたり
SMTPコマンドを全く知らなくてもメール送信プログラムを組めたり、
更には、エンジンの仕組みを知らなくても車を運転する仕事ができるのと、
似たようなことになってるんでしょうね。
理解していなくても、求められている程度には実際に開発がこなせている。
良くも悪くもそういう時代なんだと思います。
そういう人たちが、本当は理解していなきゃいけない領域に踏み込んだ時には
問題が起きるのでしょうね。(.NETなら、ポインタ知らないでunsafe使うとか)
(広く一般的に普及しているソフトウェアでも、
未チェックのバッファ云々の脆弱性とか紛れ込むのはこういう原因でしょうか。)
ただ、入門書なり研修では、本来はメモリがこうなってああなって、って
部分をある程度は触れてほしいですね。
そのうえで君たちは便利なものを使っているんだよ、と。
＞個人的には、ググる前に、ドキュメントを読んでほしいもんです。
ホントそう思います。そして論理的定義を理解できるようになってほしいです。
正式なドキュメントを参照すればいいのにググって引っかかったブログなんかを
参考にして、自分で裏付けをとらずに「こうすればできるらしい」程度の根拠で
対応するからちぐはぐな結果になる。
別の通りすがり
大学や専門学校で、ポインタを使う言語を勉強するときに、ポインタもわからん奴がいるよねって話でしょ。話広げすぎ。
elseorand
>>BELさん
>そういう人たちが、本当は理解していなきゃいけない領域に踏み込んだ時には
危険だと分からないから、平然と地雷原に突入しますよ、ほんとに・・・
よくあるところでPHPの比較演算子＝＝は地雷の一つですね。
＝＝＝との違いを知らずにつくる人が多くて・・・
C系やJavaしか知らないのに、ドキュメント読まずに、
「動けばいいや」な人が陥っていたりします。
逆に社内の新人・若手向けの勉強会では、
新人・若手に冷や水浴びせるためによく話題にしますね。
名無し
作者が降臨したことはわりとみんなスルーなのですね。
既に次回タイトルが決まってるってことでリーベルさんは締め切りに追われてというより計画的に書いてるのかな、ということがわかりましたね。
ひょっとして最初におおかたのプロットはできているのかな。
saboten
>まぁ、努力すれば、誰でもバク転やらヘッドスピンやらできるとでも思ってるよーなもんですよ。
マシン性能が向上した現在、
高度なプログラミング技術が要求される場面なんてほとんどないので、
ヘッドスピンレベルの特殊な技能は一部の人間にしか必要ないでしょう。
浅く広く吸収早くて、応用の効くSE,PGは使えますが、
ポインタ分からんのwwwとか、.Net使えないのwwwとか、microsoftうはwww
とか言ってる、にわかjoel氏みたいな人は、
選民意識というか、プライドが高すぎて手に負えないですね。
とか言って煽ってみるテスト。
クリケット
うまく言えないけど
サオリさんはいかにも女性的な考えの人ですね。
うまく書けてるなあ
身近にモデルでもいるんでしょうか。
error401
ド素人問題は、現実世界でもここまで来ているようです。
何というか、暗澹たる気持ちになります。
『エンジニア人月０円セールと、ござ先輩に見た未来』
http://d.hatena.ne.jp/iad_otomamay/20120529/1338304867
ほ
組み込み業界では未だに8bitCPUとかメモリ数KBとかあるから
ポインタやアセンブラなんかが必須な世界も存在します。
それにこれらは別に高度なプログラミングじゃないっていうか、この世界では基本中の基本。
よーは環境によって必要なものは異なるって思います。
Javaを知らない私からすればJavaの方が”高度”に見えますもん。
rurie
実際外国の人件費と比較されたら日本企業は太刀打ちできないよね。
ここ5年でドル円相場が120円→80円になったので
日本人の給料はドルに換算すると1.5倍になりました。
世界的に見ればホライゾンのフレッシュな人材たちも
高給取りの分野に入りますもん。
いぬ
アタマとカラダの問題ってのは厄介なもんで。
プロ野球選手は「俺には無理そうだな」と思っても
小説家なら「俺にも出来るかも」と思ってしまったり。
100km/hのボールを投げるのも
文章で人の心を動かすのも
冷蔵庫を持ち上げるのも
ポインタを理解するのも
煽りに耐えるのも
落ち込まないのも
泣かずに頑張るのも
出来る人は簡単に出来るけど
出来ない人にはどれも同じくらい難しいですよね
名無し
クリケットさん
「体調を崩す要因を、特売セールが開けるほど抱えているのだから。」
「ウェルカムSQLインジェクションなコードだ。」
とかちょっとイラっときそうな表現がまた少しオタクっぽいというかそんな感じもあってリアリティがあるんですよねー。
モデルがいるとするとその人はこれを見てどう思ってるでしょうね。
ぽんた
おや、投稿したちょっと後に作者さんが来てたのか！
むードリカムの曲名か。。。
じゃぁ、俺の予想は「うれしはずかし朝帰り」で。（おい）
wm
>プロ野球選手は「俺には無理そうだな」と思っても
>小説家なら「俺にも出来るかも」と思ってしまったり。
経験者は、その状況が頭の中にあるんですよね。だから、一部の状況を聞いただけで全体を補完して判断できる。
上でUIで云々の話だけど、きちんと勉強した人ならば、クライアントとサーバ群の位置関係が頭の中にあるからおかしいって分かるんだろね。
>出来る人は簡単に出来るけど
>出来ない人にはどれも同じくらい難しいですよね
まぁ、そのとおりです。あとIT関係が他の業種に比べて難しいのはとりあえず、コピーしたら出来ちゃうって所ですかね。その為に難しさが伝わらない。
他、おそらく、簡単に使えるものは無意識のうちに簡単に作れるとでも思ってますよね。
ottama
文字列連結でSQLを作ったらSQLインジェクションウェルカムってのは…?
ここで使われてるフレームワークは知らないんだけど、普通は外部から来た変数を
SQL文にぶち込んでいいようにサニタイズする機能とか使うんじゃないの?
error401
> ottama
> ここで使われてるフレームワークは知らないんだけど、普通は外部から来た変数を
> SQL文にぶち込んでいいようにサニタイズする機能とか使うんじゃないの?
それは「普通」じゃありません。
Webアプリケーションの脆弱性に興味があるのなら、それ系の書籍を1冊買って読んだほうが良いと思います。個人的には、「徳丸本」でググって検索できる書籍がお勧めです。
もっと興味がある場合は「サニタイズ言うなキャンペーン」でググると良いと思います。
ottama
え? それが普通じゃなかったら何が普通???
「サニタイズ言うなキャンペーン」でも、意味が曖昧なサニタイズって言葉を
使うなってだけで、SQLに渡す項目をエスケープ処理するのは当たり前って
話だと思うけど。
くくな
>ここで使われてるフレームワークは知らないんだけど、普通は外部から来た変数を
>SQL文にぶち込んでいいようにサニタイズする機能とか使うんじゃないの?
いやだから、それをやってないから、ウェルカムと言ってるんだろう。
espre
本文中の例、S2Daoなら、外部SQLファイルを使って、
SELECT *
FROM employeeMaster
WHERE employeeKind = /*selectKind*/'aaaa'
/*IF dateFrom != null*/ AND enabledDate >= /*dateFrom*/'2012-5-1' /*END*/
/*IF dateTo != null*/ AND enabledDate < /*dateFrom*/'2012-6-1' /*END*/
AND employmentEndFlag IS NULL
ORDER BY employeeNo, emoloyeeDate
のようにやるのが正道。
これで、自動的に、PreparedStatementが使用されるので、
画面から直接入力された文字列でも、サニタイズとか考えないでいい。
それをやらないで、文字列連結でwhere句を生成して、そのまま渡してるっぽいから、
ウェルカムSQLインジェクション、と言ってるんでしょう。
error401
> ottama
またまた徳丸氏の記事なんですがここを基点に情報を得ると良いと思います。
『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』
http://d.hatena.ne.jp/ockeghem/20111109/p1
CMP
error401さんが紹介してくれた『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』を見てて、自分の甘さに気が付きました。
セキュリティの基本として、「フリーワードでの入力を無くす」と「どうしても必要な場合はプレースホルダを使用するなどのできる限りの安全性を高めた上で使用する」と考えてました。
私がまずかったのは「フリーワードでの入力さえ無ければSQLインジェクションなんて使用できないだろ」という安易な考えでした。
いくらでもやる方法はあったのですね・・・。
幸い、私が関わった案件は外部公開のないものなので大丈夫ですが、外部公開してたらと思うとぞっとします。
ひとつ成長する場を提供してただいた本コラムと、成長するためのヒントを提供してくれた全てのコメントに感謝。
ぽんた
みなさんが親切で気持ち悪いので（笑）私からもちょいと補足を。
入力値のエスケープ（サニタイズ）とプリペアドステートメントの使用はSQLIの防止など特定の目的では結果として同じになるとしても、データ面など別の面では機能が異なることになるので留意が必要です。
保存されたDBの入力値をWeb系ではない他システムと連携するような場合やWeb系ではない他システムからの入力データをWeb系で表示するような場合などです。
こういったことは将来的な機能やIFの設計などにも関わってくるため、プロジェクト全体としてどうするのかを先に決めておく必要があります。
前投稿で（「うれしはずかし朝帰り」じゃないよ）、規約やガイドラインの問題といったのはそういうことです。
BEL
インジェクション対策としてストアドプロシージャを利用するべき、
と、耳にしたことは少なくありません。しかし、ストアドの中で
文字列連結してSQL文が実行されていた(SQL SERVERではsp_executesql)
のでインジェクション対策になっておらず萎えたことがあります。
この場合ストアドを修正するか呼び出し側で対策する必要があります。
特に、ストアドとそれを呼び出す側のプログラムを別の人が作っている場合
対策が漏れることになります
今では、そのシステムにおいてSQLインジェクションが行えないことを
原理的に裏付けない限り、完全な対策とは言えないと思うようになっています。
>危険だと分からないから、平然と地雷原に突入しますよ、ほんとに・・・
「あ、こんなことできるんだ」って感覚が先行しちゃうんですよね。
正常系ばかり探求して、論理的に考えないから潜在的な危険性を見過ごしてしまう。
>作者が降臨したことはわりとみんなスルーなのですね。
>既に次回タイトルが決まってるってことでリーベルさんは締め切りに追われてとい
>うより計画的に書いてるのかな、ということがわかりましたね。
スルーした意図はなかったのですが以前の連載では降臨したことあったので。
前作の最後で次は12月ごろに連載するとまで言ってましたから、
結構計画的なのでしょうね。
k
>「悪意のあるユーザが端末に触れる事はない」という言質を一発取って、
>Formレベルで入力可能文字設定してバリデーションかけりゃ十分でしょう。
結局のところ「やるやつが悪い」「できるようにしてるやつが悪い」の線引きをどこにするかなんでしょうけど、SQLインジェクションは
・知ってれば対策できる
・知ることも容易い
・対策して組んでも殆ど工数に影響しない
等々考えると「できるようにしてるやつが悪い」に収まりそうですけども。
>っつーか、サンプルコードで変数化してるのは『日付』と『コード（多分）』っぽいし、
>SQLインジェクションを気にするべき所ですかねコレ。
知ってる人はこんな組み方絶対にしない（労力が大して変わらないから）わけで、皆さんが問題にしてるのはそこじゃないですかね。
運用上被害が出そうか、というとまあ確かに確率的には低いんじゃないでしょうか。
でも被害出ちゃったら結構痛々しいことになりますし、確率を0にできるならしておきましょうよ。
>1.UI側（もしくはクライアント側）で対応すべきなのか
>2.サーバ側で対応すべきなのか
>3.両方で対応すべきなのか
1はそもそも「派」として存在することが許されませんね。ｗ
派で争うなら2か3のどっちか。
> 入力値のエスケープ（サニタイズ）とプリペアドステートメントの使用はSQLIの防止など特定の目的では結果として同じになるとしても、データ面など別の面では機能が異なることになるので留意が必要です。
> 保存されたDBの入力値をWeb系ではない他システムと連携するような場合やWeb系ではない他システムからの入力データをWeb系で表示するような場合などです。
SQLインジェクションの話で何故「表示時」の話が出てくるのか…。
「なんかエスケープっぽい」ってことでHTMLエスケープと混同してるんだとしたら、それとは目的もタイミングも全く別物ですよー。
少なくともプリペアドステートメントは関係ないです。
別の通りすがり
脆弱性を突くのは、悪意ある第三者のコードなんだから、クライアント側の対策なんてできないよねってことがわからない人がいる予感。
ぽんた
＞SQLインジェクションの話で何故「表示時」の話が出てくるのか…。
＞「なんかエスケープっぽい」ってことでHTMLエスケープと混同してるんだとしたら、それとは目的もタイミングも全く別物ですよー。
サニタイズや入力時にうんぬんという言葉がでていたので、一般的な処理の混同があるのかなと推測して、サニタイズとかはセキュリティ面だけではなく、他の面も考慮して決める必要があるよと言いたかっただけだが、今見てみると確かに俺の書き方も悪いな。
混同をここで長々と説明するのもアレなので、よく説明されたリンクを貼っとこう。（しかしタイトルが凄いな）
http://nlogn.ath.cx/archives/000835.html
まぁ、最初から混同してないよ、ということであれば邪推だったかな。
k
> サニタイズや入力時にうんぬんという言葉がでていたので、一般的な処理の混同があるのかなと推測して、サニタイズとかはセキュリティ面だけではなく、他の面も考慮して決める必要があるよと言いたかっただけだが、今見てみると確かに俺の書き方も悪いな。
ああ、理解しました。
>> 保存されたDBの入力値をWeb系ではない他システムと連携するような場合やWeb系ではない他システムからの入力データをWeb系で表示するような場合などです。
これは「サニタイズ」に限った話だったんですね。
としても前提がおかしいですね。
>> 入力値のエスケープ（サニタイズ）とプリペアドステートメントの使用はSQLIの防止など特定の目的では結果として同じになるとしても
「結果として同じ」にはなり得ないです。
同じにはなり得ないからダメだ、という話の流れですよ。＜コメント欄
つまりSQLインジェクション対策としての「サニタイズ」など今時あり得ないということです。
ほまらら
SQLインジェクションについて、無知なコメント晒して顔から火が出そうです。
どうも自社のローカルルールに染まりきって、勉強をおろそかにしたツケが回ったようだ。
銀河の黒歴史がまた１ページ・・・
まずは皆さんの挙げてくれた記事やコメントを精読して、セキュリティ対策の知識を身につけたいと思います。
１０年後でも通用するエンジニアでありたいですね。
ギギアル
そもそも私からしてみれば、SQLインジェクションの問題は
ワークフレーム側の設計の問題も大きいと思うのよねぇ。
先ず、SQLって言語は、本来ポインタ的な存在(変数の変数。関数の変数。
述語の述語)はLIKE演算子やSIMILAR TO演算子を除いて存在しない。
で、ポインタ的な存在を作りこんでしまうのがSQLインジェクションの
問題。
大きく分けて、
1.文字列連結する馬鹿
2.プリペアドステートメントの設計が馬鹿
に分かれるとおもう。１は論外だけど、2についても現状
1.多くの処理系でgroup by,partition by,order byの指定の
カラム名を「文字列」として渡せてしまう。
2.インラインビューのクエリを文字列として渡せる処理系がある。
などなど・・・・いらねぇ機能&墓穴ばっかり。
で、そんな機能ばっかりを分からずに使っちまう馬鹿がいると。
プリペアドステートメントを信頼しすぎて。
別に、order byにしたって、殆どの処理系でCASE文使えるんだから、
カラム名を「文字列」として渡すのは、墓穴を掘ってるとしか思えねぇ。
「穴だらけ」なのと、「穴は少ないが既知の攻撃に対して脆弱」は
殆ど同じ。正直、IPSなどで対処した方が安全なんじゃないかと。
まぁ、ここで書く事ではないが、どうしても言っときたかったので。
ぽんた
もう一息だな。がんばってみよう。
＞「結果として同じ」にはなり得ないです。
＞同じにはなり得ないからダメだ、という話の流れですよ。＜コメント欄
文章を補間してみたよ。カッコの中が意図通りに補間したもの。やっぱ長くなるな（笑）
「入力値のエスケープ（サニタイズ）とプリペアドステートメントの使用はSQLIの防止など特定の目的（に限った話し）では（SQLIが防止された、という観点からの）結果として同じ（動作）になると（仮定）しても、データ面など別の面では機能が異なることになるので留意が必要です。」
つまり、k氏の言うように「結果として同じ」にはなり得ない事例のひとつとしてデータの中身をあげています。
で、なんでデータの中身が変わると俺が思ったのかは、ottama氏の最初のコメから。
以下、説明のための引用以外に他意はないです。不快に思ったら申し訳ない。＞ottama氏
＞ここで使われてるフレームワークは知らないんだけど、普通は外部から来た変数を
＞SQL文にぶち込んでいいようにサニタイズする機能とか使うんじゃないの?
入力で変数をサニタイズするということは、シングルクォートも含めて実態参照化されてDBに保存して出力ではそのまま出してるのではと思ったんだよね。
あくまで推測なのでこれが外れていたなら邪推だねということは、前回の投稿の通り。
＞つまりSQLインジェクション対策としての「サニタイズ」など今時あり得ないということです。
ありえないと思うかどうかは別として、上のようなコメントがあったので。。。サーセンでしたk先生！
まぁ、Googleで「SQLインジェクション対策」を検索すると未だに１位な対策な状況を見るとどうかなとは思う。
へろへろ
>ギギアルさん
>別に、order byにしたって、殆どの処理系でCASE文使えるんだから、
>カラム名を「文字列」として渡すのは、墓穴を掘ってるとしか思えねぇ。
経験不足なのをまるだしでお尋ねします。
CASE文とorder byが機能的に代替できる場合ってどういう状況でしょうか？
order by：
・後に記述する列名の序列で、取得した結果の並び替えを行う
CASE：
・特定の行の値を条件によって判定し、変更する
また、前者は取得した結果全てに適用されるもの、後者は取得した各1行ずつ
個別に適用されるものと覚えているので、たとえばCASE文で並び替えの順序
を設定して、あとで並び替えるということもできないと思うのですが……。
k
> つまり、k氏の言うように「結果として同じ」にはなり得ない事例のひとつとしてデータの中身をあげています。
いや全然違うんですけど…。
SQLインジェクション対策としての「サニタイズ」などありえないので、他の差異を挙げる事に意味はありませんよ。
むしろ読む人に「サニタイズでも目的を果たせるのか」と勘違いさせる可能性を考えると、意味がないどころか有害。
>> つまりSQLインジェクション対策としての「サニタイズ」など今時あり得ないということです。
> ありえないと思うかどうかは別として、
んー…、SQLインジェクション対策を「サニタイズ」で済ますどうかは個々人の「流儀」の話だとでも？
> へろへろさん
ご本人ではありませんが、多分ちょっとズレてます。ｗ
ギギアルさんのは、SQLの「カラム名」「テーブル名」あたりを（入力値による）文字列連結で組み立ててSQL投げれちゃうよね、という話だと思います。
プレースホルダーを使えない箇所を可変にしてSQL投げれちゃう、っていう仕様はそもそもどうなん？と。
y
一昔前の仕事のことを思い出した。
ほんとに地獄だった・・