0

私は最近、私が取り組んでいるサイトの 1 つに対してセキュリティ監査を実行しました。これは Acunetix Web Vulnerability Scanner で行われました。これは、私が整理している一連の結果で返されました。

XSS に関するヒットがたくさん出てきましたが、誤検知かどうかはわかりません。

次のようなコード:

if(isset($_GET['variableNameX']))
    $var_to_use_in_app = mysql_escape_string(trim($_GET['variableNameX']));

XSS に対応するように戻ってきています。クエリ文字列を含むページは、XSS に対して開かれている可能性があるとして戻ってきますか?それとも、私がこのサーバー側を処理していることを知るのに十分なほど賢いですか?

助けてくれてありがとう。

4

5 に答える 5

5

querystringパラメーターにHTMLが渡された場合、それをページに表示しますか？もしそうなら、それは誤検知ではありません。

言い換えれば、合格した場合は次のようなものがあります： http ://www.example.com/?myVar=Test

また、HTML / Scriptをテストせずに、myVarの結果をページに表示すると、誰かが次のように変更する可能性があります。http: //www.example.com/? myVar=<b> Test </ b＆gt ;

またはこれらの線に沿った何か：http： //www.example.com/？myVar = <script > + doSomethingBad（）+ </ script＆gt ; （おそらくエンコードされています...しかし、あなたは考えを理解します）

于 2009-03-16T17:58:37.890 に答える
5

$var_to_use_in_app = mysql_escape_string(trim($_GET['変数名X']));

それは一般的に間違ったことです。アプリケーションで内部的に使用される文字列は、常にプレーン テキスト バージョンである必要があります。そうすれば、文字列操作のどれもそれを壊すことはなく、ページに間違ったものを出力することはありません.

たとえば、送信された文字列がある場合:

O'Reilly

mysql_escape_string は次のようにエスケープします。

O\'Reilly

その文字列を HTML ページに出力すると、ばかげているように見えます。そして、それをフォームフィールドに出力してから再度送信すると、別のバックスラッシュが得られ、それが 2 つのブラックスラッシュに変わり、再度編集すると 4 つ、8 つに変わります...そしてすぐにあなたは何百ものバックスラッシュで構成される文字列。これは、悪質な magic_quotes 機能がオンになっている、よく書かれていない CMS やサーバーでよく見られる問題です。

次に、名前の最初の 2 文字を取得してデータベース クエリに入力する場合は、部分文字列を切り取ります。

O\

それをクエリに連結します。

SELECT * FROM users WHERE namefirst2='O\';

おっと、構文エラーです。その文字列は現在終了していません。事前にエスケープされた文字列に対する文字列処理の変種は、セキュリティ上の問題に簡単に陥る可能性があります。

このアプローチの代わりに、SQL または HTML で区切られたリテラルに連結する最終出力段階を除いて、アプリケーション内のすべての場所で文字列を単純なエスケープされていないテキスト文字列として保持します。SQL の場合:

"SELECT * FROM users WHERE name='".mysql_real_escape_string($name)."';"

「実際の」関数名に注意してください。単純な古い mysql_escape_string は、東アジア文字セットや ANSI SQL_MODE が設定された接続/データベースなどのまれなケースでは失敗するため、通常は常に「実際の」バージョンを使用する必要があります。

mysql_real_escape_string と同じで、名前が短い関数 (例: m()) を定義して、これを少し見にくくすることができます。または、より良いのは、mysqli のパラメーター化されたクエリを見てください。

HTML の場合、エスケープは htmlspecialchars() 関数を使用して行う必要があります。

<div id="greeting">
    Hello, Mr. <?php echo htmlspecialchars($name); ?>!
</div>

echo(htmlspecialchars()) を実行する関数を定義できますが、これを少し見苦しくするために短い名前 (例: h()) を付けます。

htmlspecialchars への呼び出しを見逃した場合、スキャナはサイトが XSS に対して脆弱であることを正確に示しています。しかし、あまり気の毒に思う必要はありません。他のほとんどすべての PHP プログラマーが同じ過ちを犯します。

mysql_[real_]escape_string は、ここではまったく役に立ちません。なぜなら、HTML でテキストを分割する文字は、'&'、'<'、および属性では '"' だからです。 SQL 文字列リテラルなので、mysql_escape_string はまったく触れません。

<script>alert("I'm stealing your cookies! "+document.cookie);</script>

次の場所にのみエスケープされます。

<script>alert("I\'m stealing your cookies! "+document.cookie);</script>

セキュリティに関する限り、これは何の助けにもなりません。

于 2009-03-17T05:44:26.150 に答える
1

Acunetix は適切なツールですが、手動ベースのアプリ侵入テストに代わるものではありません。潜在的なエクスプロイトを追跡するロジックがありません.....

それは確かに銀行で使用されており、正式な作業を行うために提案書 (承認済み) で使用することを推奨しています。動的に生成されるページが多数あり、予算や時間が問題となるかなり複雑なアプリを使用している場合は、Acunetix などのツールを使用して起動し、アプリの潜在的なホット スポットの方向を示します。その後、手動でテストするか、コードをステップ実行するかに関係なく、手動でこれらの領域に焦点を当てることができます。これは、侵入テストの家がストライプを獲得する場所です。

クライアントには、大規模なアプリを徹底的に処理するためのリソースがありません。

ああ、多くの偽陽性があることに注意してください。

于 2009-03-18T13:28:04.523 に答える
0

特定のツールはわかりませんが、一般的なケースでは同等性の問題を解決する必要があるため、サーバー側でツールを処理していることを「認識」できる可能性はほとんどありません。それ以外に、ツールはmysqlインスタンスにアクセスすることもできますか？どうやって知るのでしょうか？

于 2009-03-16T17:57:48.813 に答える
0

私が使用したツールの多くは、誤検知で戻ってきます。実際のコードを監査している場合、潜在的な脆弱性を返している可能性があり、後で出力されていなくても、$_GET または $_POST 変数が通常の変数に割り当てられている可能性があります。

安全を期すために、すべてをチェックして、誤検知がないと仮定する必要があります。

于 2009-03-16T19:44:28.307 に答える