随分前の話ですが、SQL injection は Web application に限った話ではない。Client-server systemでも深刻な事態をもたらすといった意見が上がっていましたね。
SQL injection を防ぐもうひとつの方法 で簡単に説明しましたが、 SQL injection が深刻な事態をもたらす根本的原因は、扱う data に十分な access control がなされていないことにあります。DB への接続 user を共用していれば、その user ですべての data を扱うことができるので、当然 SQL injection 攻撃を受けると大問題ですね。
でも、client-server system では構成によりもっと問題がある場合があるんです。では、ちょっと client-server system について考えてみましょう。
Client-server 構成は基本的に intranet で利用されているので network 構成はこんな感じが多いと思います。
もしくは、Application server もなく client から直接 DB 叩いているかもしれません。
さて、今回は DB への接続 user を共用した場合の話です。DB に接続する場合の認証情報はどこに保存されているか考えてみましょう。
Application server を利用している場合には application server に、application server を利用していない場合には client に保存されていると思います。
Application server を利用している場合では、Web application の場合と同様に application server に対する攻撃を封じてやるよう対策を行えばいいです。Web application を host する secure な network 構成 で書いたような直接 DB server へ全く access できないような network 構成にして、cient 側には必要な service しか提供できないように firewall を構成する。もちろん application は全く脆弱性が存在しないように作成する必要があります。
ところが、application server が無い状態ではどうなるでしょうか？
認証情報は client に保存されます。こちらの場合、基本的に DB 接続用の認証情報が漏えいすると考えたほうがよいでしょう。Application に暗号化して埋め込んでもその暗号化 logic まで client に存在するため、一定の skill を持っている人であれば解析されます。
このような構成は基本的に取るべきではないでしょう。どうしても application server を利用できない場合には、共通の user など用意せず DBMS 側の access control を利用すべきです。この構成では must といっても問題ないでしょう。
なお、application server を利用しない場合でも、DB へ access する application を通常利用している OS account とは別のaccount で起動した process で扱うことにより一応保護することはできます。原理としては Windows Service にみる別の資格情報で process を起動する安全な方法 な感じです。ただ、この方法をとったとしても application server を利用する場合ほどの security を確保することはできません。また、user の account が "BUILTIN\Administrators" なんかに所属している場合には当然全く意味をなしません。