私はSQLインジェクションから身を守ろうとしており、以下を使用しています。
mysql_real_escape_string($string);
HTMLを投稿すると、次のようになります。
<span class="\"className\"">
<p class="\"pClass\"" id="\"pId\""></p>
</span>
real_escape_stringが他にいくつのバリエーションを追加するかわからないので、いくつかを置き換えて他のバリエーションを見逃したくない...これを次のような正しい形式のHTMLに「デコード」するにはどうすればよいですか。
html_entity_decode(stripslashes($string));
mysql_real_escape_string（）のマニュアルページには、エスケープされている文字が示されています。
mysql_real_escape_string（）は、MySQLのライブラリ関数mysql_real_escape_stringを呼び出します。この関数は、\ x00、\ n、\ r、\、'、"、および\x1aの文字の前に円記号を付加します。
これらのエスケープ文字をエスケープされていない形式に置き換えることで、エスケープを正常に元に戻すことができます。
mysql_real_escape_string()ただし、HTMLをサニタイズするために使用するべきではありません...Webページデータを出力する前にHTMLを使用する理由はありません。これは、データベースに入れようとしているデータにのみ使用する必要があります。消毒プロセスは次のようになります。
入力
mysql_real_escape_string()出力
htmlspecialchars()印刷する前に、ユーザー定義のデータを実行しますMySQLiやPDOなどの別のデータベースドライバーを使用すると、プリペアドステートメントを使用できるようになります。これにより、ほとんどの入力をエスケープできます。ただし、それらを切り替えたり利用したりできない場合は、必ず使用してmysql_real_escape_string()ください...データを挿入する前にのみ使用してください。
あなたはすべてを台無しにしてしまいました。
データがスラッシュで返された場合、それは2 回エスケープされたことを意味します。余分なスラッシュを削除する代わりに、最初からスラッシュを追加するべきではありません。
言うまでもなく、エスケープは時代遅れであり、そうすべきです
エスケープ文字列の代わりに。
したがって、決してエスケープしたり、デコードしたりしないでください。
問題は解決しました。
mysql_real_escape_stringユーザーが提供したデータをデータベースに格納する際の SQL インジェクションを防ぐために使用されますが、 PDOを使用したデータ バインディングを使用する方が適切な方法です (たとえば)。エスケープをいじる代わりに、それを使用することを常にお勧めします。
そうは言っても、後で表示する方法に関する質問については、データが保存された後、データを取得すると、「エスケープ解除」する必要なく、データが完全で有効になります。独自のエスケープ シーケンスを追加しない限り、そうしないでください。
次の関数を使用して、HTML ページで表示中にスラッシュを削除します。
ストリップスラッシュ();
例えば。$html=stripslashes($html); または $html=stripslashes($row["fieldname"]);
さて、私はこれを昔ながらの方法で試してみましたが、これまでのところ、私のアプローチに問題はありません。明らかにそれは少し粗雑ですが、仕事を成し遂げます：
function mysql_unreal_escape_string($string) {
$characters = array('x00', 'n', 'r', '\\', '\'', '"','x1a');
$o_chars = array("\x00", "\n", "\r", "\\", "'", "\"", "\x1a");
for ($i = 0; $i < strlen($string); $i++) {
if (substr($string, $i, 1) == '\\') {
foreach ($characters as $index => $char) {
if ($i <= strlen($string) - strlen($char) && substr($string, $i + 1, strlen($char)) == $char) {
$string = substr_replace($string, $o_chars[$index], $i, strlen($char) + 1);
break;
}
}
}
}
return $string;
}
これは、ほとんどの場合をカバーする必要があります。
私が見ることができるようにフォーマットで何が起こっているのかわかりませんが、あなたのhtmlフォーム
<span class="\"className\"">
<p class="\"pClass\"" id="\"pId\""></p>
</span>
単純にする必要があります。
<span class="className">
<p class="pClass" id="pId"></p>
</span>
戻ってきたら、データベースに入れる前に mysql_real_escape_string() を使用してエスケープし、SQL インジェクション攻撃を受けないようにします。
したがって、テキストが次に行く場所の準備ができている値をエスケープしています。
データベースから取得すると (またはそのいずれかを html としてユーザーに表示する)、ユーザーを XSS 攻撃から保護するために htmlentities() などを使用して、次の場所 (html) に備えて再度エスケープします。
これは、まぶたの内側に刺青する必要があるマントラ FIEO、フィルター入力、エスケープ出力の EO 部分を形成します。
このルーチンにデコーダ ルーチンが付随していないのはなぜだろうと思っていました。おそらく、エスケープされていない場合とまったく同じように MySQL によって解釈されます。を実行すると、エスケープされていない結果が得られます$row=mysql_fetch_array($res, MYSQL_ASSOC)';
他の多くの回答が明らかな問題を見逃していたと思います...
入力されたコンテンツで mysql_real_escape_string を使用しています (準備済みステートメントを使用しない場合と同様)。
あなたの問題は出力にあります。
現在の問題は、html_entity_decode を呼び出していることです。元のテキストを復元するために必要なのは、ストリップスラッシュだけです。html_entity_decode は、引用符を変更しているため、引用符などを台無しにしているものです。プレーンテキストだけでなく、実際にhtmlを出力したい（これは、html_entitiesなどを使用する場合です）。エンコードしたいものをデコードしています。
テキスト バージョンのみを表示する場合は、エンティティを使用できます。悪いタグが気になる場合は、striptags を使用して、必要なタグ (b、i など) のみを許可してください。
最後に、適切な順序でエンコードおよびデコードすることを忘れないでください。mysql_real_escape_String(htmlentities($str)) を実行した場合は、html_entity_decode(stripslashes($str)) を実行する必要があります。操作の順序が重要です。
更新: html_entity_decode もスラッシュを削除することに気づきませんでした。そのページには明確に文書化されていませんでした。ただし、提示するほとんどのhtmlはエンティティとして残したいので、自動的に実行します。そうしない場合でも、ケースバイケースで、dbクラスの外でその決定を行うことを好みます。そうすれば、スラッシュがなくなったことがわかります。
元の投稿者は htmlentities (または tinymce が彼のために行っているような彼の入力プログラム) を実行しているようで、彼はそれをコンテンツに戻したいと考えています。したがって、必要なのは html_entity_decode($Str) だけです。