エスケープ処理について

現実問題として、管理画面がログインが必須だからという理由で脆弱性が多い状況はありがちなのですが、以下のような理由でエスケープ処理（またはプレースホルダの利用）はすべきです。

そもそも、エスケープ処理が必要な理由は、セキュリティのためではありません。たとえば、O'Reillyというという人名かつ出版社がありますが、人名検索で O'Reilly を検索しようとすると、エスケープ処理のないプログラム（あるいはプレースホルダを使用していない場合、以下同様）では、エラーとなり、目的を達することができません。すなわち、エスケープ処理をしていないプログラムは、脆弱性があるという以前に、目的を達成できない不完全なプログラムということになります。

SQL文の文字列（正確には文字列リテラルと言います）の中にシングルクォート（アポストロフィを兼ねる）がある場合、シングルクォートを重ねることになっていますが、これはSQLの文法上の要求です。前記のように、エスケープ処理を怠ったプログラムは、機能的に不完全であり、その理由は、SQLの文法上の要求をさぼっているからにほかなりません。

現実問題として、ログイン後にSQLインジェクション脆弱性がある場合、その悪影響を受ける局面はゼロではないものの限られます。
しかし、これは私の個人的な感覚ですが、「攻撃を受けなければ、SQLの文法を満たしてなくても、そして機能的に不完全でも構わない」というのは、プロの開発者としてとても恥ずかしいことのように感じます。難しいことを言う前に、まずSQLの文法くらい守ったらどうでしょうか?

上記の感覚に立てば、攻撃を受ける可能性がある（高い）場合はSQLの文法を守り、攻撃を受ける可能性がない（少ない）場合はSQLの文法違反もよしとするのは、かえって煩わしいように思います。攻撃の影響があるかないか、多いか少ないかを判断するのは、それなりに技量が必要であり、そのような技量を持つ方は私の知る限り、前記のようなサボりを考えたりはしません。

…とキツめの表現をしてしまいましたが、現実的な脅威についてもふれておかなければなりません。

SQLインジェクションの影響は、大目に見積もっても任意SQLの実行であり、それにより以下のような悪影響の可能性があります。

• データベース内の情報がすべて漏洩する
• データベース内の情報がすべて改変される
• データベース内の情報がすべて削除される
• （場合によっては）データベースサーバー内のファイルが漏洩あるいは改ざんされる
• （場合によっては）データベースサーバー上で任意のコマンドが実行される
• ログイン機能にSQLインジェクション脆弱性がある場合は認証を回避される場合がある

管理機能にログインできる権限のある人が、元々上記の権限を持っている場合、仮にSQLインジェクション脆弱性があっても、新たに脅威が増すということはありません。強いて言えば、悪意の管理者を想定した場合、犯人を追跡しにくくなる、ということはありえます。

上記から、質問者さんの環境では、ひょっとすると管理機能にSQLインジェクションがあっても許容可能であるのかもしれませんが、それは状況を仔細に調べないと確かなことは言えません。

であれば、「これはSQLの文法上の約束として必要なのだ」と淡々とエスケープ処理をした方が、心情的に受け入れやすいのではないでしょうか。
なお、エスケープ処理という表現を使ってきましたが、これは確かに面倒なもので、間違いやすく、間違えたことによる脆弱性が入りやすいので、エスケープ処理ではなくプレースホルダの利用を強くおすすめします。

PHPで、入力値について、エスケープ処理をするように、という記述よく見ます

何故エスケープ処理をしなければならないかを理解する必要があります。

(IPA)安全なウェブサイトの作り方
ここから閲覧できる「安全なウェブサイトの作り方」(pdf)の「1. ウェブアプリケーションのセキュリティ実装」は最低限参照ください。
アプリケーションを作成するにあたってのセキュリティに関わる注意事項はほぼ網羅されています。（不足があったり新たな注意事項がある場合は適時改訂されます）