4

現在、プロジェクトの 1 つで次の行を使用しています。

htmlspecialchars($value,ENT_QUOTES,'UTF-8');

したがって、 &, ', ", <,> をエンコードします。私の質問があります (いくつかの内部コーディングの理由として、私はそれを検討しています) & をエンコードしないことに関連するセキュリティリスクはありますか?したがって、次の行を使用するとセキュリティが生成される場合リスク/リーク:

$value=str_replace('&amp;','&',$value);

<,>,'," については、HTML インジェクションに使用できるため、なぜエンコードする必要があるのか​​ は完全に明らかです。しかし、理由はわかりません（これまでのところ、特別な理由は見つかりませんでした）。

編集：

データベースへのアクセスが数回言及されたように。私はそこにドクトリンをパラメータで使用しています...そのため、データベースは（比較的）SQLインジェクションから節約されるべきです。

上記の変換は、html インジェクションを防ぐためだけに行われましたが、現在、ほとんどのデータが extJS によって作成されたフィールドに配置されているため、... の&amp;代わりにテキスト フィールドが表示されるため、「&」変換が邪魔になり&ます。

悲しいことに、アーキテクチャ エラーのため、htmlspecialchars 全体と str_replace の部分を 1 つの場所でしか実行できません (実行したとしても)。そして、私は区別することはできません。したがって、 に関する私の質問もあり&ます。

4

3 に答える 3

4

ユーザー入力を受け入れ、それを式として評価するか、Web ページに出力するか、SQL ステートメントに直接挿入する場合は常に、セキュリティ リスクが存在します。htmlspecialcharsSQL インジェクション攻撃で使用される一重引用符や二重引用符など、悪意のある目的に使用される可能性のある一部の (すべてではない) 文字をエンコードします。htmlspecialchars入力セキュリティには使用しないでください。安全でない可能性のある文字を削除、エンコード、またはエスケープするには、専用の洗練された方法を使用する必要があります。考慮されていないあらゆる種類の特殊文字とフィルター回避技術があります (IE6 や US-ASCII など)。htmlspecialchars個人的には、適切な入力ではない特殊文字を削除することを好みます (英数字以外の入力を削除する JavaScript: input = input.replace(/\W/g, '');)。

JavaScript を使用してクライアント側でユーザー入力をサニタイズ/エスケープし、ユーザー入力を式として評価することを避け、SQL アクションに準備済みステートメント (PDO など) を使用することが常に重要です。

あなたのアプリケーションをもっと見ることができれば、セキュリティ上の問題があるかどうかをより正確に判断できるでしょう.

于 2012-12-28T09:16:24.193 に答える
2

エンコードしないことに伴うセキュリティリスクはあります&か？

Netscape 4ベースのブラウザを実行している人にはセキュリティ上のリスクがあり&{...}ます。属性には、JSを実行するためのバックドアメソッドがあります。今日Netscapeユーザーがいないことを願っていますが、将来の奇妙なブラウザが不正な形式のHTMLを解析する方法を知っている人はいます...

&エスケープすることはHTMLマークアップにとって間違いなく正しいことであり、エスケープしないと出力が混乱する可能性があるという機能上のリスクがあります。例えば。マークアップ= cut&copy&paste、出力= cut©&paste。

現在、ほとんどのデータはextJSによって作成されたフィールドにあるため、「＆」変換はテキストフィールドのように邪魔になり、＆の代わりに＆が表示されます。

これは別のエラーです。問題を回避しようとするのではなく、それを見つけて修正する必要があります。フィールドをどのように作成し、それらを作成するコードにデータを取り込みますか？

JavaScript変数に値を挿入する場合は、HTMLでエスケープするのではなく、JSでエスケープする必要があります。2つのコンテキストは異なる処理を必要とします。考えられる回避策は、ドキュメントのHTMLコンテンツ（通常はdata-属性）のデータを非表示にして、そこからJSで読み取ることです。

于 2012-12-28T23:23:41.890 に答える
1

htmlspecialcharsセキュリティとは何の関係もありませんが、それらの文字は特別であると言う HTML 仕様に関係しています。セキュリティのために、他の種類のエスケープがあります。具体的には、データベースに何かが挿入される直前に行われるエスケープが重要ですが、それhtmlspecialcharsは使用されません。

htmlspecialchars次のような HTML テキストを出力する場合はいつでも使用します。

<div id="here" class='here'> or here </div>

この理由は、最初hereにリテラルの引用符が含まれていると、HTML で構文エラーが発生するためです。2 番目hereと二重引用符、または 3 番目hereと小なり記号も同様です。大なり記号はそれほど危険ではないと思いますが、バランスのために置き換えられています (間違っている場合は誰かが訂正してください)。アンパサンドは、誰かが を表示したい場合&quot;、エスケープせず"に代わりに表示されるように置き換えられます。適切htmlspecialcharsに&amp;quot;すると、目的の .html にレンダリングされる HTML が表示されます&quot;。

Blender が言うように、それはテキストが望むように見えるようにするためです。セキュリティとは何の関係もありません。

EDIT：というか、HTMLセキュリティで行うことができます（ちょうど私に起こりました）。誰かが最初の部分hereを"><script src="http://malicio.us/code"/><p id="... に置き換えたとしましょう。それが適切にエスケープされていれば、何も起こりません。属性内の奇妙なテキストにすぎません。しかし、そうでない場合...それでも、少なくともSQLセキュリティとは何の関係もありません。

于 2012-12-28T09:16:46.527 に答える