事情起因#
ある内部テストのターゲットから、登録は公開されていないですが、バイトパルスのlationさんに復元してもらい、学びの姿勢で再現してみました。ターゲットのアドレス
注入方法の探求#
ターゲットを開くと、以下のようになっています：
見た目は「簡単な」ログインボックスです。burpを使ってrepeaterを開始して探求します。
見た目は普通で、usernameとpasswdの 2 つのフィールドしかありません。まずはユニバーサルパスワードを試してみましょう。
ログインに失敗しました。ここで小技を紹介しますが、burpでパラメータを変更する際には、自分で追加した部分を選択してctrl+Uで URL エンコードを行うことをおすすめします。
adminにシングルクォートを追加しても何の反応もありませんでした。後ろにand 1=1やand 1=2を追加しても何の反応もありませんでした。
passwdフィールドにシングルクォートを追加しても何の反応もありませんでした。
エラーインジェクションを試してみます：
これも何の反応もありませんでした。ワイドバイトインジェクションを試してみます：
エラーが発生しました。エラーステートメントを閉じるために試してみます：
テストの結果、--+の他にも#と-- -も閉じることができることがわかりました。
インジェクションデータ#
いつものように、列数をクエリします：
エラーが発生しましたが、エラーメッセージにnear 'der by 3と表示されているので、私たちのorが消えてしまったことがわかります。ダブルワイトで回避してみましょう：
order by 3は問題ありませんが、order by 4でエラーが発生しました。union selectでエコーフィールドを確認します：
直接エコーされるのは「ログイン成功、flag は flag1 テーブルにあり、列名は key1」と表示されます（ここでは少し重なって表示されています）。値を確認しましょう。
変化はありませんでした。
エラーインジェクションの場合、
information_schemaデータベースへの読み取り権限が必要です。
information_schemaデータベースへの読み取り権限がない場合、列名とテーブル名を推測する必要があります（難しいです）。
それでは、以前のエラーインジェクションを使用してデータをクエリしましょう：
注意：%df%27の後ろには%があります。
参考記事：
以上です。