多くの場合、侵入者がツール インジェクションを使用すると、ツールがテーブル名とフィールド名を解読できないことがわかります。これは、すべてのツールがテーブル名とフィールド名を含む独自の辞書を持っているためです。フィールド名がこのディクショナリに含まれないように変更されると、使用するツールはフィールド名とテーブル名を推測できなくなります。次の記事では、SQL インジェクションに対する防御線を構築するために手動インジェクションを分析するところから始めます。
侵入者は、ページにインジェクション脆弱性があるかどうかを判断するための簡単な判定条件を構築します。一般的な手順は次のとおりです。
ここで検出されるページはhttp://127.0.0.1/111/view.asp?id=198
1
です。侵入者 サイトを手動で挿入する場合は、手動挿入中にエラー メッセージが返されるようにブラウザを設定する必要があります。手順は次のとおりです。
ブラウザを右クリックして [プロパティ] を選択します。ポップアップ ダイアログ ボックスの [詳細設定] タブをクリックします。以下に示すように:
図 1
次に、「わかりやすい HTTP エラー メッセージを表示」の前にあるフックを削除し、最後に「適用」ボタンをクリックします。
2. 侵入者は次の URL をブラウザに送信します:
http://127.0.0.1/111/view.asp?id=198 および 1=1
SQL インジェクションの脆弱性がある場合、データベースにクエリを実行できます。 1 は Ignore なので、通常のページが返されます。このとき、侵入者はこのページをhttp://127.0.0.1/111/view.asp?id=198と判断します。注入されることが予想されます。何らかのエラー メッセージが返された場合、初歩的な侵入者がサイトを放棄する可能性があります。
3. 侵入者はさらに次の URL をブラウザに送信します。
http://127.0.0.1/111/view.asp?id=198 および 1=2
1=2 は恒等不等式です。サイトがデータベース クエリをサポートしている場合は、次の図に示すような情報が返されます。
図 2
一般に、上図に示すように侵入者が現れた場合、このサイトが SQL インジェクション攻撃を実行できることは基本的に確実です。
ただし、多くの場合、侵入者は、単一引用符を使用するだけでターゲット サイトに SQL インジェクションの脆弱性があるかどうかをすぐに判断し、次の URL をブラウザに送信できます。
http://127.0.0.1/111/view.asp? id=198'if 次の情報が返された場合、インジェクションの脆弱性が存在する可能性が半分以上あることを示します:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft] [ODBC Microsoft Access Driver] 文字列の構文エラークエリ式「id =1」にあります。 /list.asp、50 行目
4. この時点で、侵入者はサイト データベースのテーブル名をクエリする特別な SQL クエリ ステートメントの構築を開始し、次のステートメントを URL に送信します:
http://127.0.0.1/ 111/view.asp?id= 198 and contains(select * from admin)
このステートメントはデータベースにクエリを実行し、管理テーブルが存在するかどうかを確認します。存在する場合は、通常のページが返され、テーブルが存在しない場合はエラーが返されます。ページが返されます。一般に、侵入者はまず一般的に使用されるテーブル名をテストします。これは、一般的なインジェクション ツールのパスワード ディクショナリに存在するテーブル名とフィールド名でもあります。テーブル名が一般的に使用されるテーブル名に含まれていない場合、侵入者はソーシャル エンジニアリングを使用してテーブル名を推測します。この場合、侵入者がテーブル名を推測できる可能性は低くなります。
5. テーブル名を取得した後、侵入者はデータベースのフィールド名をクエリするクエリ ステートメントの作成を開始し、次のステートメントを URL に送信します:
http://127.0.0.1/111/view.asp?id=198 contains(select user from admin)
this ステートメントは、データベース内の admin テーブルに user フィールドが存在するかどうかを問い合わせます。存在する場合は、通常のページが返されます。存在しない場合は、エラー ページが返されます。
7. 次に、侵入者はフィールド ID の値の決定を開始し、ID の値をクエリする次のステートメントを構築します: http://127.0.0.1/111/view.asp?id=198 および存在します (ID を選択します) from admin where id=1 )
が正しい場合は正しいページを返し、間違っている場合はエラー ページを返します。
6. テーブル名とフィールド名を推測した後、侵入者は管理者アカウントの長さを推測するクエリ ステートメントの作成を開始し、次のステートメントを URL に送信しました:
http://127.0.0.1/111/view.asp?id =198 および存在します(select id from admin where len(user)<6 and id=1)
このステートメントは、ユーザー フィールド内のユーザー名の長さの範囲をクエリするものであり、長さが 6 未満であることを意味します。正しければ通常のページに戻り、間違っていればエラーページに戻ります。
スコープを狭め、次のステートメントを作成してユーザー名の特定の長さを決定します:
http://127.0.0.1/111/view.asp?id=198 and doesn't contains(select id from admin where len(user)=) 5 および id=1)
正しい エラーが発生した場合は、通常のページが返されます。 エラーが発生した場合は、エラー ページが返されます。
8. 次に、侵入者は、管理者のユーザー名を照会するステートメントを作成する最終ステップに入り、次のステートメントを URL に送信します: http://127.0.0.1/111/view.asp?id=198 and assigns( select count(*) from admin where left(user,1)='a')
この文はユーザー名の左側からaまでのユーザー名を推測するもので、正解であれば通常のページに戻ります。間違っている場合は、1 つずつエラー ページに戻ります。2 番目のステートメントは (user,2)='ad' などとなります。
侵入者がユーザー名とパスワードを取得すると、注入は完了に近づきます。
防御方法としては、非常に簡単です。テーブル名やフィールド名が一般的に使用されているテーブル名やフィールド名に含まれていない場合、侵入者はソーシャル エンジニアリングを使用して推測します。管理者によって変更されたテーブル名とフィールド名が非常に複雑であるため、攻撃者が侵入する可能性があります。それでも攻撃者が目的を達成できない場合は、インターネットからいくつかのアンチインジェクションパッチをダウンロードして適用するという別の簡単な防御方法があります。方法は、サイト ファイルを変更し、侵入者によって送信されたステートメントをフィルタリングするフィルタリング ステートメントを追加することです。はい、ここではその原理については説明しません。