調べてみました。
対象は
Web コンテンツに
① データベースと連携してページを生成しているもの
② 動的コンテンツで、何らかのデータを入力できるもの
対策は
① HTTP経由で送られてくるデータの全てに。
GETやPOSTなどのクエリーやCookieの値、HTTPヘッダなどなどからのもの全てに。
* SQLで使える特殊文字をエスケープする。
例 ： 「 ' → '' 」 「 ￥ → ￥￥ 」
特殊文字例 ： ! " # $ % & ' ( ) * + , - . / : ; < = >
特殊文字例 ： ? @ [ \ ] ^ _ ` { | }
エスケープ処理（例）
重複する「"」の前に￥をつけてエスケープ処理をする
「￥"」 「￥'」 「'￥n'」 「"￥￥n"」
また、
文字列の扱いを「'」（シングルクォート）でした場合、
「"」（ダブルクォート）はエスケープしなくてよい。
「'」（シングルクォート）はエスケープします。
コレだけでは完全に対策が不完全。
文字列をエスケープして登録しても、データベースに登録される時に
エスケープ文字は自動的に削除されてデータベースに登録される為、
次にデータベースから呼び出した際には、
エスケープされていない元のデータが呼び出されることになる。
この文字列がSQLに使用されるのでSQLインジェクションが成立してしまう。
② データベースやファイルなどに保存されたデータを呼び出すクエリーなどにも。
対策前 ： SELECT name FROM user where id = '$id' AND number > $number
対策後 ： SELECT name FROM user where id = '$id' AND number > '$number'
* $numberをシングルクオーテーションで囲う
③ マルチバイト文字にも。（シフトJISやEUC-JP、UTF-8などの2バイト文字などのこと）
2バイト目に1バイト文字の文字コードを含んで変換された文字が対象
例 ： （0x27「'」、0x5C「\」等）
適正に文字変換したつもりが、「'」が残って変換されている場合がある。
対策① ： クライアント側の文字コードにSHIFT_JISを使うのをやめてEUC-JPなどを使う。
対策② ： マルチバイトを扱う関数を通して、1バイトの文字コードを整理
Perlの場合 ：Encode::from_to($str, "sjis","sjis");
PHPの場合 ：mb_convert_encoding($str, 'SJIS', 'SJIS')
他にも対策箇所があるので更なる精進が必要のようです。
