これがリクエストログに表示されるのを見たところです。彼らは何を達成しようとしていましたか?
完全なリクエスト文字列は次のとおりです。
properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /*
編集:グーグル検索が有用なものを返さなかったので、私は同じことに遭遇した人々に質問をしたかったです。
これは単なる注射のテストです。攻撃者が出力でxQを確認できる場合、インジェクションが可能であることがわかります。
この特定のクエリからの「リスク」はありません。
開発者は、どんな注入メカニズム、形式、または意味にも注意を払うべきではありません-これらは彼のビジネスのどれでもありません。
1つだけの原因がありますすべての無限注入の原因-不適切な形式のクエリクエリが適切にフォーマットされている限り、SQLインジェクションは不可能です。 SQLインジェクションの方法ではなく、クエリに焦点を当てます。
Char()
関数は各値を整数として解釈し、それらの整数のコード値によって指定された文字に基づいて文字列を返します。 Char()
では、NULL値はスキップされます。この関数はMicrosoft SQL Server、Sybase、MySQL内で使用され、CHR()
はRDBMSで使用されます。
SQLのChar()
関数は、(たとえば)addslashes()
for PHP=がSQLクエリ内の予防策として使用されている場合に便利です。Char()
挿入されたクエリ内の引用符の必要性を取り除きます。
Char()
を使用したSQLインジェクションに対して脆弱な一部のPHPコードの例は、次のようになります。
$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;
addslashes()
が使用されている間、末尾の引用符がないため、スクリプトは入力の適切なサニタイズに失敗します。これは、次のSQLインジェクション文字列を使用して/etc/passwd
ファイルをロードするために悪用される可能性があります。
ソース: http://hakipedia.com/index.php/SQL_Injection#Char.28.29