query_posts()自体はエスケープ処理がされていないようでしたので、esc_sql()をGET情報の各パラメーターに対して当てることにしました。
※GET情報が配列の場合には配列の各要素を対象
尚、query_posts()は非推奨とのことですので、後々はpre_get_postsフックを使うようにします。
WordPress では $_GET、$_POST の値は WordPress 内部で先にエスケープ処理されていますので、扱う時は wp_unslash() しなくてはなりません。
query_posts() をなぜ使うべきでないかについてはこちらを読んでください。
メインクエリーを改変したい場合は pre_get_posts フックを使用してください。
メインクエリーとは別に新しいクエリーを発行したい場合は、WP_Query の新しいインスタンスを生成するか、get_posts() を使ってください。
これら WP_Query オブジェクトのパラメーターは、内部で適切にサニタイズされますので SQL 文に行うエスケープ処理は必要ありませんが、外部変数を扱う時には細心の注意を払うようにしてください。不明に思ったら実際に問題となる文字列を入力して自分の目で結果を確かめるのが一番です。
参考:
Data Sanitization and Validation With WordPress
WordPress で外部から来る変数を扱う時の注意点
Seisuke Kuraishiさん、ありがとうございます。
> WordPress では $_GET、$_POST の値は WordPress 内部で先にエスケープ処理されていますので、扱う時は wp_unslash() しなくてはなりません。
テーマ内で自前でテンプレートファイルを作成し、その中でGET・POTを扱う場合にはも、Wordpress内部で先にエスケープ処理してもらえるんでしょうか？
外部変数（GET・POST情報など）からSQL文を作成する過程で、基本的には、esc_sql()、wp_unslash()を利用しサニタイズする必要があるが、WP_Queryオブジェクトを利用する場合には、エスケープ処理機能を有するのでesc_sql()の必要がなく、wp_unslash()のみで良いという解釈であっていますでしょうか？
===
余談ですが、別のこちらが立てたトピックでSeisuke Kuraishiさんからご指摘いただいた「解決済みステータスへの変更」についてなのですが、本トピックもそうだったのですが、一人相撲で解決した（つもりになっている）ものについて、本当に解決しているのかどうかの判断をする自信がないものもあります。
そのため、その場合、しばらくは誰しもが書き込める状態にしてお区ということも、運営的にはダメなのでしょうか？
この余談部分は、後で削除します。
基本的な仕様については書いた通りです。ただ私がそう書いたからといってそれを鵜呑みにせず、自分の目で目的のデータが安全かどうかを必ず検証してください。別の誰かが書いたコードが先に wp_unslash() をかけているかもしれませんし、WordPress に予期せぬバグがあるかもしれません。実際のコードの文脈(コンテキスト)で実際のデータの状態を見ずにそれが安全か安全でないかを論じることには意味がないのです。心配なら自身で納得のいく検証・無害化ロジックを作ってください。詳しいことは先に紹介した参考リンク先に書いてありますので目を通してください。
余談ですが、別のこちらが立てたトピックでSeisuke Kuraishiさんからご指摘いただいた「解決済みステータスへの変更」についてなのですが、
こちら異なる話題ですので以下に新しいトピックを立ててください。
https://ja.forums.wordpress.org/forum/6
Seisuke Kuraishiさん、ありがとうございました。
勝手に私がwp_unslash() をSQLインジェクション対策で利用すると読み違えてしまい、複雑な投稿をしてしまいました。申し訳ないです。
今回は、GET値を基にWHERE句をquery_posts()で作成しようとし、GET値に対しSQLインジェクション対策を自前でする必要がなるのかと疑問になり投稿させていただきました。
query_posts()に関しては、Seisuke Kuraishiさんのご指摘の通り、使用しないように書き換えを行う予定です。
ありがとうございました。
