1

私の質問のほとんどは本質的に理論的なものです。なぜなら、「偉大な頭脳はアイデアについて話し合う」と考えており、書記官は構文について話し合っているからです。

とにかく..これが状況です

ユーザーから入力を受け取るシステムがありますが、その入力はクエリで使用されません（まったく）。この入力には、多くのコード スニペットが含まれています。過去に、入力をエスケープしてデータベースに保存しました。スラッシュ関数の追加と削除は一切使用せず、次のように preg_replace を使用する独自の手順を使用します。

$data = preg_replace("/\;/", "&#59;", $data);//
$data = preg_replace("/</", "&lt;",   $data);
$data = preg_replace("/>/", "&gt;",   $data);
$data = preg_replace("/\"/", "&quot;",$data);
$data = preg_replace("/\(/", "&#40;", $data);

しかし、以下の問題が発生しました。

ときどき、ソフトウェアがデータを誤ってエスケープし (私のソフトウェアにはバグがないため)、実際のデータが何であったかを見つける方法がありません。時々、エスケープ手順を更新します。つまり、異なる入力は異なる方法でエスケープされます。

ユーザーには、投稿を編集するオプションがあります。したがって、データを2回エスケープするのを防ぐために、エスケープされたデータを彼に提示する（またはデータをエスケープ解除する）必要があることを意味します......最終的に、エスケープされていないデータをユーザーから直接に保存するという結論に達しましたデータベース。表示の前にエスケープします（他の目的はありません..クエリなどでは使用できません）。それ以外の場合は、元のデータを変更していません。

私の質問::

クエリで使用されていない場合や、表示前にエスケープされている場合でも、データベース内のエスケープされていないユーザー データは依然として危険ですか?

スラッシュを使用したエスケープは、< を <.. などの文字を変更してエスケープするよりも等しい/優れている/異なる..

データが適切にエスケープされている場合 (すべての特殊文字を意味します)、XSS 攻撃に引き続き使用できます。SQL インジェクションは論外です。

4

2 に答える 2

12

実際に表示するまでは、データを表示用にエンコードしないでください。保存するときは、保存するためにエンコードし、送信するときは送信するためにエンコードします。適切なタイミングで適切なエンコードを行うことで、これらの問題を処理できます。

于 2012-07-23T21:00:55.457 に答える
0

はい、危険です。ユーザーは簡単にコードを挿入して、データベースに対して独自のクエリを実行できます (このデータをクエリするつもりがない場合でも)。

于 2012-07-23T21:03:05.083 に答える