3

この質問は、インジェクションを防止するための実績のある関数の実際の代替案を作成することに関するものではなく、自作のインジェクション防止コードの欠陥に気付いていない人々と議論する方法に関するものです!

私は同僚に指摘しようとしていますが、SQL インジェクションに対する彼の「解決策」は私にはかなり安全に思えます。

彼は次のようにしてクエリをクリアします

$query = $_POST['username'];
$look = array('&', '#', '<', '>', '"', '\'', '(', ')', '%');
$safe = array('&amp;', '&#35;', '&lt;', '&gt;', '&quot;', '&#39;', '&#40;', '&#41;', '&#37;');
str_replace($look, $safe, $query);

そして、ログインに進みます

"SELECT * FROM users WHERE username = '" . $query . "'
    AND password = '" . md5($_POST['password']) . "'";

私は彼に PDO または同等のものを使用させようとしていますが、実際にこの保護を破るにはどうすればよいでしょうか? 私には答えがありません。これがどのように危険であり、なぜこのようにしてはいけないのかを彼に説明できないので、本当に悩まされています.

4

3 に答える 3

2

「このアプローチを破ることができるか」という質問は関係ないことをお勧めします。本当の質問は、「すでに作成、テスト、デバッグされ、数千人のユーザーがすでに使用しているソリューションではなく、自家製のアドホックソリューションを使用するのはなぜですか？」です。

于 2013-01-25T15:16:13.130 に答える
2

これはほとんどの典型的な SQL インジェクションの問題をカバーする可能性がありますが、サーバーでマルチバイト文字セットと特定のロケール設定を使用する既知の問題がいくつかあります。

ただし、これは単なるエスケープではありません。実際には、データベースに入力されるデータを変更しています。必要に応じて単純にスラッシュを追加するか、mysqli_real_escape_stringデータを入力するときなどに組み込みのエスケープ メソッドのいずれかを使用することを検討htmlentitiesしてください。これにより、データベースに保存する内容は、特に理由がない限り、常にユーザーが実際に入力したものになります。

さらに良いことに、疑わしい場合は、準備済みステートメントとバインドされたパラメーターを使用してください。そうすれば、SQL インジェクションから完全に安全になります。

于 2013-01-25T15:12:26.643 に答える
1

これは実際には多くの落とし穴を伴う恐るべき「逃避」方法であり、そのうちのほんのわずかしかありません。

  1. このコードは、出力媒体が HTML のみであるという前提で実際にデータを変更しています。私の15年の経験から、それは真実ではないと言えます。データを変更することは常に悪いことであり、将来的に矛盾や多くの苦痛につながります。それらの直接の1つは、そのような「フォーマット」が編集ごとに乗算され、 &ampamp が単なる引用から外れるということです。
  2. 数字による注射。
  3. 識別子によるインジェクション。
  4. 二次注射。

…などなど。
このサイトの厳格な規則により、このような「保護」に適切な言葉を使用することはできませんが、自由に想像してみてください。

于 2013-01-27T09:00:21.607 に答える