SQLインジェクション後のバックドア？
クライアントのライブサイトにインジェクションの脆弱性を見つけました。次のようになります。
$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" . $Pword . "'";
私はウィキペディアの例を使用して「ハッキング」に成功したので、かなり脆弱なはずです。
このサイトは長年このようになっています。
私はそれを修正する方法を知っていますが、私はSQLをあまり知らないので、バックドアについて心配しています。
これを修正した後も露出されますか？どのようなバックドアが残される可能性がありますか？
たとえば、攻撃者がmysqlのユーザーやパスなどの完全なアクセス権をすでに取得していて、将来的にインジェクションが不要になる可能性はありますか？ユーザーを変更して合格する必要がありますか？ほかに何か？
データベースは複数のサイトで使用されるため、クロスドメインが有効になっていることを確認します。
@Adnanが言うように、最悪は「完全な妥協とバックドアの存在」です。どうして？ SQLをいじくり回しても、システム自体が危険にさらされることはありませんが（バックアップからデータベースをリロードするだけで設定する必要があります）、SQLを使用してシステムと対話するプログラムには、はるかに高い機能があります。
たとえば、PHPテンプレートスニペットを含むテーブルがある可能性があります。攻撃者はそれを編集して悪意のあるコードを追加できます。SQLテーブルから何かが実行されている場合（または、ファイル-ファイルをwebフォルダーにダンプできる場合、攻撃者はそれを使用して自分のPHPを挿入して実行することができます）、問題が発生する可能性があります。
したがって、テーブル内のすべてのデータが使用されている場所を見つけます。保存または実行されている場合は、これが悪用可能かどうかを確認します（前者の場合、攻撃者がそれを使用してWebフォルダーに任意のテキストを配置できるかどうかに依存します。後者の場合、それはほとんど常に問題です）。その場合、システムが危険にさらされている可能性があり、クリーンインストールを実行することができます。
そうでない場合は、テーブルで問題を探し、存在する場合は修正してください。ユーザー名/パスワードを変更していることを確認してください（不正なアカウントがないか確認してください）
興味深いことに、SQLiteではATTACH DATABASEコマンドは 直接脆弱性を導入する に使用できます。
同様に、SQL * Plusの SPOOL command は、インジェクションで複数のコマンドを実行できる場合に使用できます。
上記の2つのいずれかを使用している場合は、データの使用方法に関係なく、クリーンインストールが適切です。
SQLインジェクションだけでは、システム全体が侵害される可能性があります。データベースから読み取りおよび書き込み操作を介してローカルファイルシステムにアクセスするには、多くの方法があります。データベースが「ルート」として実行されていると考えてみましょう。そうすれば、/ etc/shadowファイルを読み取るのは簡単です。また、データベースのローカルユーザーテーブルを読み取ることができ（ユーザーを選択し、mysql.usersから渡すなど）、簡単なハッシュをクラックした後5月を使用してホストにSSH接続できると仮定します。同じ資格情報（パスワードの再利用を悪用）。また、おそらくより一般的には、データベース自体からオペレーティングシステムコマンドを実行できます。 Xp_cmdshellはSQL Serverで使用でき、ユーザー定義関数はMySQLで作成できます。Oracleでこれを行う方法はたくさんあります-Java関数の作成は1つだけです！
データベースが危険にさらされており、それをロックダウンまたは強化する手順を踏んでいない場合は、最悪の場合、攻撃者がオペレーティングシステム自体に昇格した特権を持っていると想定できます。