4

私は今かなり混乱しています。もしあなたが私のために物事を片付けてくれるなら、知りたいです.

最新の Anon/Lulsec 攻撃の後、私は自分の php/mysql セキュリティに疑問を抱いていました。

そこで、PHP と Mysql の両方を保護するにはどうすればよいかを考えました。

質問:引用符に関して、PHP と Mysql を処理するためのベスト プラクティスは何ですか?

  • 特にフォームでは、html を保護するためにある種の htmlspecialchars が必要ですよね？
  • PHPはフォームでまったく悪用できますか? 必要な保護はありますか？
  • クエリの直前にreal_escape_string を使用する必要がありますか? PHP内ですでに使用するのは間違っている/悪いでしょうか(sanitize_post関数を参照)?

現在、私は次の機能を使用しています。この関数は、すべての $_POST および $_GET 変数を「サニタイズ」します。これは「安全」ですか？

function sanitize_post($array) {
    global $db;
    if(is_array($array)) {
        foreach($array as $key=>$value) {
            if(is_array($array[$key])) {
                $array[$key] = sanitize_post($array[$key]);
            } elseif(is_string($array[$key])) {
                $array[$key] = $db->real_escape_string(strtr(stripslashes(trim($array[$key])), array("'" => '', '"' => '')));
            }
        }            
    } elseif(is_string($array)) {
        $array = $db->real_escape_string(strtr(stripslashes(trim($array)), array("'" => '', '"' => '')));
    }
    return $array;
}

MySQL 5.1.54 で PHP 5.3.5 を使用しています。

ありがとう。

4

7 に答える 7

6

mysql_real_escape_stringは注目に値します。

ただし、直接クエリは泥沼であり、安全な方法とは見なされなくなりました。組み込みの引用、エスケープなどの副次的な利点を持つPDO 準備済みステートメントとバインディングパラメーターについて読む必要があります。

于 2011-08-11T17:47:55.460 に答える
6

ベスト プラクティスは、常に準備済みステートメントを使用することです。これにより、SQL インジェクションが不可能になります。これは、PDO または mysqli のいずれかで行われます。すべての mysql_* 関数を忘れてください。それらは古くて時代遅れです。

于 2011-08-11T17:49:44.020 に答える
3

質問: 引用符に関して、PHP と Mysql を処理するためのベスト プラクティスは何ですか?

それは簡単です: PDO::prepareやmysqli_prepareなどで、準備済みステートメントを使用します。

于 2011-08-11T17:49:54.940 に答える
2

「普遍的な消毒」のようなものはありません。それがすべてであるため、引用符だけと呼びましょう。

引用するときは、次のような特定の出力のテキストを常に引用します。

  1. mysqlクエリの文字列値
  2. likemysqlクエリの式
  3. htmlコード
  4. json
  5. mysql正規表現
  6. php正規表現

それぞれの使用法は異なる構文コンテキスト内に存在するため、それぞれの場合について、異なる引用符が必要です。これは、PHPへの入力ではなく、特定の出力で引用符を作成する必要があることも意味します。magic_quotes_gpcこれが、のような機能が壊れている理由です（常にオフになっていることを確認してください!!!）。

では、これらの特定のケースで引用するためにどのような方法を使用するでしょうか？（私を自由に訂正してください。もっと現代的な方法があるかもしれませんが、これらは私のために働いています）

  1. mysql_real_escape_string($str)
  2. mysql_real_escape_string(addcslashes($str, "%_"))
  3. htmlspecialchars($str)
  4. json_encode()-utf8のみ！私はiso-8859-2に自分の関数を使用しています
  5. mysql_real_escape_string(addcslashes($str, '^.[]$()|*+?{}'))-この場合、バックスラッシュが2回エスケープされるため、preg_quoteを使用できません。
  6. preg_quote()
于 2011-08-11T18:02:19.620 に答える
2

mysql_real_escape_string() などを使用して労力を無駄にしないでください。PDOで準備済みステートメントを使用するだけで、SQL インジェクションは不可能です。

于 2011-08-11T17:50:08.170 に答える
0

私は通常、PHP 関数stripslashesを使用strip_tagsし、変数が $_POST (または使用する内容に応じて $_GET) を介して、およびmysql_real_escape_stringクエリ中に入ってくるときに変数を使用します。（これが「正しい」かどうかはわかりませんが、これまでのところうまくいきました。）PHPの組み込みの検証フィルターを使用して、電子メールアドレス、URL、データ型などをチェックすることもできます.PDOはおそらく防止するのにまともです. SQLインジェクションですが、まだ経験がありません。

于 2011-08-11T17:46:23.117 に答える
0

基本的なワークフローは

$data = $_POST['somefield which will go into the database'];

... do data validation ...

if (everything ok) {
    $escaped_data = escape_function($data);
    $sql = " ... query here with $escaped_data ... ";
    do_query($sql);
}

基本的に、データベース挿入のためにエスケープされたデータは、データベース挿入にのみ使用する必要があります。50個の値のうち2つまたは3つだけが実際にdbの近くにある場合、すべてを前処理し、dbエスケープされた値ですべてのデータを上書きしても意味がありません。

htmlspecialchars についても同様です。HTML タイプの表示を目的としている場合を除き、htmlspecialchars を介してデータを送信しないでください。

特定の目的のためにフォーマットされた DB にデータを保存しないでください。他の目的のために別の形式でデータが必要になった場合は、エスケープを元に戻す必要があるためです。生/未フォーマットのデータを常にデータベースに保存します。注意: mysql_real_escape_string() と company で行われたエスケープは、実際にはデータベースに保存されません。データが安全にデータベースに取り込まれることを確認するためだけに存在します。実際にデータベースに保存されるのは、生のエスケープされていない/引用されていないデータです。データベースに入ると、それは「安全」です。

例えば、移送される囚人の手錠としての逃避機能を考えてみてください。囚人がどちらの監獄にいる間も、袖口は必要ありません。

于 2011-08-11T17:47:21.537 に答える