20

私はSQLインジェクションについて読んでいましたが、ユーザーがユーザー名を入力してログインできるフォームがある場合、それがどのように機能するかを理解しています。私が得られないのは、ログインページのないWebサイトがSQLインジェクションに対してどのように脆弱であるかということです。

http://thecybersaviours.com/how-to-find-out-if-a-website-is-vulnerable-to-sql-injection

テストするには、「」または「=」を追加するだけです。これがエラーの有無を判断するのにどのように役立つのかわかりません。作成中のクエリはどこにありますか。

4

6 に答える 6

21

SQLインジェクションは、他の情報を取得するために、Webサイトインターフェイスを介してデータベースにSQLコマンドを発行する試みです。つまり、この情報は、ユーザー名やパスワードなどの保存されたデータベース情報です。

データベースインスタンスに接続するスクリプトまたはページを保護するための最初のルールは、ユーザー入力を信頼しないことです。

あなたの例は、SQLステートメントで誤って引用された文字列を終了しようとしています。これを理解するには、最初にSQLステートメントを理解する必要があります。パラメータにaを追加する例では'、「インジェクション」は次のタイプのステートメントを期待しています。

SELECT username、password FROM users WHERE username ='$ username'

そのステートメントにを追加する'ことで、SQLパラメーターまたはクエリを追加できます。' OR username --

SELECT username、password FROM users WHERE username ='' OR username-'$ username

これはインジェクションです（クエリの再形成の1つのタイプ）。ユーザー入力は、事前に作成されたSQLステートメントに挿入されたステートメントになります。

一般に、SQLインジェクションメソッドには次の3つのタイプがあります。

  • クエリの再形成またはリダイレクト（上記）
  • エラーメッセージベース（そのようなユーザー/パスワードはありません）
  • ブラインド注射

SQLインジェクション、脆弱性のテスト方法、 SQLインジェクションの理解と克服、およびインジェクションの回避に関するStackOverflowのこの質問（および関連する質問）を読んでください。

編集：

SQLインジェクションについてサイトをテストする限り、「シンボルを追加する」よりもはるかに複雑になることを理解してください。あなたのサイトが重要であり、あなた（またはあなたの会社）がそれを買う余裕があるなら、プロの侵入テスターを雇ってください。それができない場合、この優れた例/証明は、注入テストを実行するために使用する可能性のあるいくつかの一般的な手法を示すことができます。SQLインジェクションとデータベース引き継ぎシナリオのいくつかのテストを自動化できる SQLMapもあります。

于 2012-04-23T13:35:24.573 に答える
5

SQLインジェクションは、クエリで使用される前に適切にエスケープされていない、ユーザーが影響を与える可能性のある任意の入力に対して実行できます。

1つの例は、次のようなget変数です。

http//www.example.com/user.php?userid=5

ここで、付随するPHPコードが次のようになる場合：

$query = "SELECT username, password FROM users WHERE userid=" . $_GET['userid'];
// ...

ここでもSQLインジェクションを簡単に使用できます。

http//www.example.com/user.php?userid=5 AND 1=2 UNION SELECT password,username FROM users WHERE usertype='admin'

（もちろん、スペースはに置き換える必要がありますが%20、これはより読みやすくなります。さらに、これはいくつかの仮定を行う単なる例ですが、アイデアは明確である必要があります。）

于 2012-04-23T13:28:35.153 に答える
2

クライアントからの入力はすべて脆弱になる方法です。すべてのフォームとクエリ文字列を含みます。これには、すべてのHTTP動詞が含まれます。

アプリケーションをクロールし、インジェクションが発生する可能性がある時期を検出できるサードパーティのソリューションがあります。

于 2012-04-23T13:23:49.700 に答える
1

ログインページは、データベースと対話するデータベース駆動型Webサイトの唯一の部分ではありません。

データベースクエリの作成に使用されるユーザーが編集可能な入力は、SQLインジェクション攻撃の潜在的なエントリポイントです。攻撃者は、この攻撃を通じて管理者としてサイトにログインする必要はありませんが、他のことを行うことができます。アプリケーションのデータベースとの相互作用の性質に応じて、データの変更、サーバー設定の変更などを行うことができます。

入力にa'を追加することは、通常、エラーが発生するかどうか、またはサイトで予期しない動作が発生するかどうかを確認するための非常に優れたテストです。これは、ユーザー入力が生のクエリの作成に使用されており、開発者がクエリ構造を変更する一重引用符を予期していなかったことを示しています。

あるページはSQLインジェクションに対して安全であるかもしれませんが、別のページはそうではないかもしれないことに注意してください。たとえば、ログインページは、このような攻撃に対して強化される可能性があります。ただし、サイトの他の場所にある別のページが広く開かれている可能性があります。したがって、たとえば、管理者としてログインしたい場合は、他のページのSQLインジェクションを使用して管理者パスワードを変更できます。次に、SQLを挿入できない完全なログインページに戻り、管理者としてログインします。

于 2012-04-23T13:24:51.977 に答える
0

テストはデータベースを照会するページで実行する必要があるため、通常はログインページです。これは、最も害を及ぼす可能性があるページですが、安全でないページである可能性もあるためです。

通常、データベースクエリは安全なログインの背後にありますが、アイテムのリストなど、ハッカーがクエリ文字列の最後にSQLインジェクションを追加する可能性があるかどうかを気にしない場合は、

SQLインジェクションの鍵は、インジェクションを行う人がデータベースにクエリを実行していることを知っている必要があるため、データベースにクエリを実行していない場合、SQLインジェクションを実行できないことです。フォームがデータベースに送信している場合は、SQLインジェクションを実行できます。ストアドプロシージャを使用して選択/挿入/更新/削除するか、データベースにアクセスするすべてのステートメントを準備またはエスケープすることを常にお勧めします。

于 2012-04-23T13:24:25.557 に答える
0

自分自身を保護する最も簡単な方法は、インラインSQLステートメントの代わりにストアドプロシージャを使用することです。

次に、「最小特権」権限を使用し、テーブルへの直接アクセスではなく、ストアドプロシージャへのアクセスのみを許可します。

于 2012-04-23T13:26:22.127 に答える