DVWAでSQLインジェクションを試す
タイトルのまんま。
このくらいなら有名ですし、どんな手順で学べばよいかウォームアップになるので。
まずはDVWAがインストール直後だと仮定して設定変更。
ログイン後に左ペイン下部の「DVWA Security」をクリック。
セキュリティレベルをHighに変更した後、Submit。
画面左下のSecurity Levelが選択したものに変わっていることを確認。
選択可能なレベルは4段階あり、説明をGoogle翻訳にかけ、意訳すると
- Low ... ノーガード戦法。勉強用の簡素なコード。
- Middle ... すこし保護したつもりでやっぱりガバガバ。
- High ... Middleよりめんどくさくなってる。Low, Middleでは全データを取得することができた方法が、数個のデータしか得られなかったり、通用しないことがある。
- Impossible ... 基本的な方法ではまず突破不能。
CTFsってコンテストあるの初めて知りました。無知!
設定が終わったら早速攻撃を試しましょう。
左ペイン中段真ん中辺り「SQL Injection」を選択。
攻撃に関する参考リンクがあるので、一通り目を通すと良いでしょう。
「Click here to change your ID」をクリック。
例のアレを入れましょう。コメントアウトはMariaDBに合わせて'#'で
なんかたくさん出てきた。
なにが起きたのか、ソースコードを見ましょう。
画面右下の「View Source」をクリック。
ポップアップウィンドウ最下部左下に「Compare All Levels」ボタンがあるので、クリックして各レベルと比較しましょ。
まずはHigh
8行目。文字列連結でパラメタを埋め込んでいます。露骨。
今回入力したパラメタと合わせると
SELECT first_name, last_name FROM users WHERE user_id = '' OR '1' = '1' # LIMIT 1;
user_idが空文字列 OR '1' = '1'で必ずTrueになり、コメントアウトでそれ以降のLIMITが無効になるので、すべてのデータが出てきます。
なお、sqli_から始まる関数は非推奨です。
よく見てみると、セッション経由で値を送信してますね。
データ送信の手順が複雑になりましたが、セキュリティ的には無意味です。
つぎにImpossible
13行目。プリペアドステートメントをつかっており、SQL構文も文字列として扱われるため、同様の方法では攻撃失敗します。 ちゃんとPDOを用いてます。 さらに、18行目ではアプリケーション側で取得されるべきデータ数の確認も行っています。 ダメ押しでCSRF対策もしてるようですね。
とまあ、こんな感じで
「攻撃について学ぶ」→「攻撃してみる」→「ソースを読んで見る」
で勉強できます。すばらしいアプリです。
つづくかな?
ここから雑記
たぶんちゃんと勉強してきた人にとっては、そんなあからさまにガバガバなコードを書く人が存在するの?と思われますが、実際います。
以前数カ月だけいた忌まわしい経験を積ませていただいた職場では、あちこちで文字列連結によるSQLが組まれていました。
数少ない技術に詳しい先輩曰く、セキュアなコードに関わることに限らず、わかりやすいやつをコピペしてしまうんだそうです。
そしてそのわかりやすいものがどんどん広まり、修正しようがなくなるそうです。
嫌いな上司が「あれは閉じたネットワークだしいいでしょ(※不特定多数の利用あり)」「あれにはWAFを導入すればいい!費用は○○(システム部長)もちで」と言っていたのはいい思い出です。
愚痴ですはい。
自分も知らず知らずの間にダメなコーディングをしてると思うと怖いです。
仮に調べてコピペするにしても、いろいろ比較して、より良い方法を選択することぐらいはしたいなと思いました(こなみかん)。
そしてそのような余裕ぐらいはもてる開発を心がけたいですね。
私の場合は、まず仕事を探しましょう。
