入力「サニタイズ」は偽物です。
入力をフィルタリング(*)したりエスケープしたりしてインジェクションの問題から身を守ろうとするべきではありません。別のコンテキストに入れるときまで生の文字列で作業する必要があります。その時点で、そのコンテキスト ( mysql_real_escape_string
MySQL クエリおよびhtmlspecialchars
HTML 出力用) 用の正しいエスケープ関数が必要になります。
(WordPress は のような独自のエスケープ関数を追加しますesc_html
が、原則として違いはありません。)
(*: まあ、電子メール アドレスが実際に電子メール アドレスであることを確認する、パスワードが適切であることを確認するなど、アプリケーション固有の要件を除いて。入力時に制御文字を除外するための合理的な議論もあります。段階ですが、これが実際に行われることはめったにありません)。
htmlentities() を使用して、アクセントを持つことができる入力フィールドを変換しています。
そうしないことを強くお勧めします。データベースには未加工のテキストが含まれている必要があります。列を HTML としてエンコードすると、列に対してデータベース操作を実行するのが非常に難しくなります。<
やなどの文字"
を非 ASCII 文字と同時にエスケープしています。データベースからデータを取得し、それをページにコピーする以外の理由で使用すると、データに誤った HTML エスケープが含まれることになります。ページにテキストを書き込む最後の瞬間まで HTML エスケープしないでください。
ASCII 以外の文字をデータベースに入れるのに問題がある場合、それは別の問題であり、HTML でエンコードされたデータを格納するなどの持続不可能な回避策を講じるのではなく、最初に解決する必要があります。Content-Type
ここには、PHP とデータベースが適切な UTF-8 で通信できるようにするための投稿が多数ありますが、主なことは、ヘッダー/メタを使用して、HTML 出力ページ自体が正しく UTF-8 として提供されるようにすることです。次に、たとえば を使用して、MySQL 接続が UTF-8 に設定されていることを確認しますmysql_set_charset()
。
データを入力する SQL 文字列を作成するときは、mysql_real_escape_string() を使用します。
それは正解です。これを行う限り、SQL インジェクションに対して脆弱ではありません。テンプレート出力側ではなくデータベース側で HTML エスケープを行っている場合、HTML インジェクション (XSS の原因) に対して脆弱になる可能性があります。データベースを通過していない文字列(例: から直接フェッチされたもの$_GET
) は、HTML エスケープされていないためです。