【ITニュース解説】Irish-Name-Repo 1 - picoCTF '19 (web)

このニュース記事は、ウェブアプリケーションのセキュリティチャレンジである「picoCTF '19」の中から、「Irish-Name-Repo 1」という課題を題材に、ログイン機能を迂回して管理者ページへアクセスする方法を解説している。システムエンジニアを目指す初心者にとって、ウェブアプリケーションがどのように動作し、どのような脆弱性があるのかを理解する良い機会となるだろう。

まず、このチャレンジの目的は、通常の認証プロセスを経ずに管理者ページへ到達することだ。ログインを迂回するということは、ウェブアプリケーションがユーザー名とパスワードをデータベースと照合する仕組みを「騙す」ことを意味する。チャレンジを始める前に、ウェブサイトのあちこちをクリックしてヒントを探すのが良い実践方法だと記事は述べている。そこで「SQL」という言葉が見つかる。この「SQL」というヒントは、データベースに対する不正な操作、いわゆる「SQLインジェクション」という脆弱性が存在する可能性を示唆している。

SQLインジェクションとは、ウェブサイトの入力フォームを通じて、開発者が意図しないSQLコマンドをデータベースに送り込み、不正な操作を行わせる攻撃手法のことだ。ウェブアプリケーションの多くは、ユーザーが入力した情報（例えばログイン時のユーザー名やパスワード）を元にSQLクエリ（データベースへの命令文）を組み立て、データベースに問い合わせを行う。このとき、ユーザーの入力が適切に処理されないと、悪意のあるSQLコードが混入し、データベースがそのコードを実行してしまう。

このチャレンジでは、「Burp Suite（バープスイート）」というツールを使用する。Burp Suiteは、ウェブブラウザとウェブサイトの間で行き交う通信（HTTPトラフィック）を傍受（プロキシ）し、その内容を記録・表示・改変できる非常に強力なツールだ。これにより、ブラウザからウェブサイトに送られるリクエスト（要求）や、ウェブサイトからブラウザに返されるレスポンス（応答）を詳細に分析し、必要に応じて書き換えることができる。今回のケースでは、ログインリクエストを送信する際に、その内容をBurp Suiteで確認し、悪意のあるコードを挿入するために利用する。

具体的な解決手順を見ていこう。まずは管理者ログインページに戻り、ユーザー名に「admin」、パスワードには何も入力せずにログインを試みる。このリクエストをBurp Suiteで捕捉し、「HTTP history」タブから該当する「POST」リクエストを探し出す。POSTリクエストとは、ブラウザからウェブサイトへデータを送信する際によく使われるHTTPメソッドの一つだ。見つけたら、そのリクエストをBurp Suiteの「Repeater（リピーター）」という機能に送る。Repeaterは、同じリクエストを何度も送信したり、内容を少しずつ変えて試したりするのに便利な機能だ。

いよいよ、SQLインジェクションの肝となるペイロードを挿入する。ペイロードとは、攻撃のために送り込むデータやコードのことだ。今回は、パスワードの入力欄に「' OR 1=1 --」という文字列を挿入する。この文字列がどのようにログインをバイパスさせるのか、その仕組みを詳しく見ていこう。

通常のログイン処理において、データベースに送られるSQLクエリは、概ね次のような形を想像できるだろう。「SELECT * FROM users WHERE username='<ユーザー名>' AND password='<パスワード>'」。これは、「usersテーブルから、指定されたユーザー名とパスワードに一致するユーザーの情報をすべて取得せよ」という命令文だ。

ここに、ペイロード「' OR 1=1 --」がパスワードとして挿入されると、SQLクエリは以下のように変化すると考えられる。

SELECT * FROM users WHERE username='admin' AND password='' OR 1=1 --'

この変更されたクエリを各部分に分解して見ていこう。

• '（シングルクォート）: まず、ペイロードの先頭にあるシングルクォートは、元のSQLクエリでパスワード入力部分を囲むために使われていた文字列リテラル（固定の文字列値）を意図的に閉じてしまう役割を果たす。これにより、パスワード入力部分がそこで終了し、その後の文字列がSQLコマンドとして解釈される余地が生まれる。

• OR 1=1: 次に来る「OR 1=1」は、「または、1は1に等しい」という意味の条件式だ。1が1と等しいというのは、どのような状況でも必ず真となる、常に正しい条件だ。SQLの論理演算子「OR」は、左右どちらかの条件が真であれば、全体として真となる特性がある。したがって、たとえ元の「username='admin' AND password=''」の部分が偽（正しいパスワードが入力されていないため）であったとしても、「OR 1=1」が真であるため、クエリ全体の条件式は常に真と評価される。これにより、データベースは「条件が常に真なので、ユーザー名がadminのユーザーを認証する」と判断してしまう。

• --（ハイフン2つ）: 最後に「--」が続く。これは、多くのSQLデータベースシステムにおいて「コメントアウト」を表す記号だ。この記号以降の文字列は、データベースによってSQLコマンドとして解釈されず、無視される。元のSQLクエリには、パスワードの文字列を閉じるためのシングルクォートが最後に残っているはずだが、この「--」によってそれがコメントアウトされ、SQLの構文エラーが発生するのを防ぐ。結果として、意図しないシングルクォートが原因でクエリが破損することなく、私たちの注入した「OR 1=1」がスムーズに実行される。

このようにして、「' OR 1=1 --」という短い文字列は、元のSQLクエリを改変し、「ユーザー名が'admin'であるか、そうでなくても常に正しい条件を満たすユーザーを探せ」という命令に変えてしまうのだ。結果として、パスワードが空であっても、データベースは「admin」ユーザーの認証を許可し、ログインが成功する。

このチャレンジでは、リクエストの中に「debug」というパラメーターが含まれている点にも注目だ。このパラメーターは「0」または「1」のようなブーリアン値（真偽値）を取る可能性があり、有効にすると、ウェブアプリケーションがデータベースに送信した実際のSQLクエリを表示してくれる。これは、SQLインジェクションを試す上で非常に有用な機能だ。自分が入力したペイロードがどのようにSQLクエリに影響を与え、どのような形でデータベースに送られているのかを直接確認できるため、ペイロードの調整や脆弱性の理解を深めるのに役立つ。

最終的にこの手順を通じてログインバイパスに成功し、管理者ページにアクセスすることで、フラグ「picoCTF{s0m3_SQL_c218b685}」が得られる。このチャレンジは、SQLインジェクションという非常に一般的なウェブアプリケーションの脆弱性を実践的に学ぶための優れた教材となるだろう。システムエンジニアを目指す上で、このような攻撃手法とそれに対する防御策を理解することは、安全なシステムを設計・開発するために不可欠な知識である。