ハッキングAPI

Webアプリケーション

• Webサーバー上で動作するソフトウェアのこと
• クライアント/サーバーモデルに基づいて機能する
  • クライアント: ブラウザ
  • サーバー: Webサーバー

認証・認可の略称

Authと略すと認証・認可どちらのことを指しているかわからないため、下記のように分ける

• AuthN: 認証(AutheNtication)
• AuthZ: 認可(AuthoriZation)

API用語

• リソース
  • 要求されたデータ
• シングルトンリソース
  • 一意なオブジェクト
  • /api/user/{user_id}/
• コレクション
  • リソースグループ
  • /api/profiles/users
• サブコレクション
  • 特定リソース群の中にあるコレクション
  • /api/user/{user_id}/setttings
• APIゲートウェイ
  • Webアプリケーションへのエントリポイントとして機能するAPI管理要素
  • リクエストの目的を達成するために、必要なマイクロサービスにリクエストを渡す
  • 受信トラフィックを監視し、不正なリクエストをフィルタリングする
  • 認証、認可、SSLによる暗号化、レート制限、ロードバランシングなども提供

RESTfulな設計

MUSTではなくSHOULD

1. 統一されたインターフェース(Uniform Interface)
   • あらゆるクライアント端末で同じようにアクセスできるようにする
2. クライアント/サーバー型(Client/Server)
3. ステートレス(Stateless)
   • 各リクエストがサーバーによって最初に受信されたものであるかのように振る舞う
   • 渡されるトークンを利用して、ステートフルな機能を提供する
4. キャッシュ可能(Cacheable)
   • レスポンスがキャッシュ可能かクライアントに示す
5. レイヤーシステム(Layered System)
   • クライアントはサーバーのアーキテクチャを知る必要はない
6. コードオンデマンド(Code on Demand)

GraphQL

• クライアントがサーバーに要求するデータ構造を定義できる
  • 必要なデータを1リクエストで取得できる
  • 必要ないカラムを取得せずに済む
• RESTful
• POSTメソッドで単一のエントリポイントに問い合わせる
• 3種類の操作
  • クエリ(R)
  • ミューテーション(CUD)
  • サブスクリプション
    • イベント発生時にデータを送受信するのに利用

API仕様の記述言語

• OpenAPI Specification 3.0(OAS)
  • 旧Swagger
• RESTful API Modeling Language(RAML)

OWASP API SECURITY TOP 10

情報漏えい

• 機密データを非特権ユーザーと共有してしまうこと
• WPのユーザー一覧取得APIは認証・認可なしに結果を返すらしい?
• 詳細なエラーメッセージによる漏洩
  • ログイン失敗時の「ユーザーIDが存在しません」 など

1. オブジェクトレベルの認可不備(BOLA: Broken Object Level Authorizaion)

• APIに最も多く存在する脆弱性の1つ
• API利用者にアクセス権限のないリソースへのアクセスを許可してしまった場合に発生
  • 例: アクセス制御のないシングルトンリソースへのリクエスト

2. ユーザー認証の不備(Broken User Authentication)

• API認証処理におけるあらゆる脆弱性のこと
• 認証保護メカニズムを実装していないか、実装が不適切な場合に発生する

脆弱性が潜むポイント

• トークン生成処理
  • トークンのランダム性が不十分
• トークンの取り扱い
  • トークンの保管
  • ネットワーク上でのトークンの送受信
  • ハードコードされたトークン
• パスワード初期化や他要素認証などの登録メカニズム
  • メールアドレスと送られた6桁の数値でパスワード初期化できるケース
  • 初期化APIの実行回数に制限がない場合、100万回リクエストすればパスワード初期化できる

3. 過剰なデータ露出(Excessive Data Exposure)

• API利用者が不要な情報をフィルタリングすることを期待して、レスポンスに不要なデータを含めてしまう
• 名前を尋ねただけで生年月日やメールアドレスなど個人情報を回答してしまうような感じ

4. リソースとレート制限の不足(Lack of Resources and Rate Limiting)

• サービス停止につながる(DoS攻撃)
• レート制限を回避する攻撃者はAPIプロバイダに追加コストを発生させる可能性あり
• レート制限実装したら、ちゃんと効いているかテストする

5. 機能レベルの認可不備(BFLA: Broken Function Level Authorizaion)

• BOLAとの違いは、リソースへのアクセスに関する問題ではなく、アクションを実行する際の認可の問題であるということ
  • BOLA: 支払履歴、ユーザー名、メールアドレス等へのアクセス
  • BFLA: 送金処理、口座情報の更新

6. マスアサイメント

• アプリケーションの意図する以上のパラメータをリクエストに含め、それらが内部オブジェクトに反映されてしまう問題
  • usernameを変更するエンドポイントにrole=ADMINパラメータを追加してリクエストしたら管理者になれてしまうようなケース
• RoRの脆弱性で聞いたことある

7. セキュリティ設定ミス(Security Misconfiguration)

設定ミスの例

• ヘッダの設定
  • X-Powered-By: 不必要なバックエンド技術の公開
    • 脆弱性のある技術が使われている場合、容易に攻撃方法を見つけられてしまう
  • X-XSS-Protection: クロスサイトスクリプティングの防止
  • X-Response-Time: レスポンス時間の違いをサイドチャネルとしての悪用されるケース
    • ResponseTimeの違いであるリソースが存在しないのかアクセス制御されているのか判別できる
• 通信経路の暗号化
  • 機密情報を提供するAPIは必ずTLSを利用してデータを暗号化する
• デフォルトアカウント
• 不要なHTTPリクエストメソッドの受け入れ
• 入力検証・サニタイズの不備
  • 悪意あるスクリプトのアップロード
• 詳細なエラーメッセージ

8. インジェクション脆弱性(Injection Flaws)

• SQLインジェクション、システムコマンドインジェクションなど
• 入力値検証していないと発生する

9. 不適切な資産管理(Improper Assets Management)

• サービス終了済み、あるいは開発中のAPIの公開で発生する
• サービス終了済みのAPIはパッチの適用がされていないため脆弱になりがち
• 開発中のAPIは一般的に本番APIと比べて安全ではない

10. ビジネスロジックの欠陥(BLF: Business Logic Flaws)

• API利用者が指示した正しい方法でのみAPIを利用するという性善説に基づいた前提により発生する
  • フールプルーフが必要
  • APIキーやトークンなどの流出は常に発生するので、その前提でのアクセス制御が必要
• 利用者がウェブアプリケーションとやり取りするためにブラウザを使い、リクエストを見ないと仮定した場合に発生する
  • リクエストのパラメータは簡単に見えるし書き換えられるので、その前提で設計する

受動的偵察(Passive Reconnaissance)

• 対象システムと直接やり取りすることなくターゲットの情報を取得する行為
• 調査していることをターゲットに意識させることなく、対象の攻撃対象領域を発見し、文章化することが目標
• OSINT(Open Source Intelligence)を活用する

探す情報

• APIエンドポイント
  • 能動偵察の対象にする
• 認証情報(キー、シークレット、ユーザー名、パスワード)
• バージョン情報
• APIドキュメント
• APIの事業目的
  • 潜在的なビジネスロジックの欠陥についての洞察が得られるかも

プロセス

1. 幅広いデータ収集

• 検索
  • APIの利用方法や設計、アーキテクチャ、事業目的など一般的な情報の収集
  • 業界関連の情報
• 攻撃対象領域の調査
  • DNS Dumpster
  • OWASP Amass

2. 適応と取捨選択

• フェーズ1での発見をベースに、OSINTの調査方針を決定する

3. 攻撃対象領域の文書化

• 興味深い発見をすべて文書化し、スクリーンキャプチャを取得する

能動的偵察(Active Recon)

受動的偵察によって得られた情報を、ターゲットから直接的に情報を得て検証する

手法

• ポートスキャン
• 脆弱性スキャン
• ping
• HTTPリクエストの送信
• APIの実行

フェーズ

0. クイックウィンを得る

• 脆弱性を発見したら攻撃を試してみる(テストの許可をもらえているなら)

1. 検出スキャン

• 調査の出発点となるサービス・ポートを明らかにするのが目的
• Nmapを利用する

2. ハンズオン分析

• ブラウザやAPIクライアントを使ってWebアプリケーションの調査を行う
• リクエストを取得して精査し、APIのリンクとドキュメントを分析し、関連するビジネスロジックを理解する

3つの視点

3つの視点からアプリケーションを検討する

1. ゲスト
   • 新規ユーザーはこのサイトをどのように利用するか
   • ゲストはAPI利用可能か
   • このグループが実行できるアクションはなにか
2. 認証済ユーザー
   • 認証されると何ができるか
   • ファイルアップロードできるか
   • Webアプリケーションはユーザーが認証されたことをどのように認識するか
3. 管理者
   • 管理者が管理するためにログインする場所はどこか
   • ページのソースコードには何が書かれているか
   • どのようなプログラミング言語で開発されているか
   • Webサイトのどの部分が開発中か

3. ターゲットスキャン

• 検出スキャンで見つけた対象に対する詳細なスキャン
• 特定のAPI、バージョン、Webアプリケーションの種別、発見されたサービスのバージョン、プロトコル、ポート、ビジネスロジックなどに焦点をあてる

例

• APIが非標準ポートで動作していること検出したら、そのポートを詳しく調べるようスキャナを設定
• WordPress使っているなら、/wp-json/wp/v2にアクセスできるか調査

APIでのBASIC認証

• 毎リクエストユーザー名とパスワードを送信するため、盗聴の機会が増える
  • 登録処理の一部としてBASIC認証を行ってトークン発行し、後続の処理ではトークンで認証する

ブルートフォース攻撃

IDとパスワード

• APIにブルートフォース攻撃を防ぐ仕組みがなければ有効
• ターゲット特有の単語リストを生成することで攻撃の成功率をあげられる
• 「過剰なデータ露出」で明らかになった情報を活用する
  • ユーザーIDとパスワードの一覧を作成する
  • 多要素認証が有効か、デフォルトパスワード利用しているか、アカウントが有効化などが明らかになることも

パスワード初期化

• パスワード初期化の本人確認コード検証プロセスにおいて試行回数の制限が存在しない場合に有効

多要素認証

• OTPの強度が不十分で試行回数や有効期限のレート制限が実装されていなければ有効

パスワードスプレー攻撃

• ユーザーリストと少数のパスワードリストを組み合わせ、試行回数などの制限を回避して認証の突破を試みる攻撃
  • 10回のログイン試行しか許可されていない場合、可能性の高い9つのパスワードを試す
• 偵察中に発見したパスワードポリシーを考慮して可能性の高いパスワードリストを作成する必要あり
• ユーザーリストを最大限活用することが成功させるコツ

クレデンシャルスタッフィング攻撃(Credential Stuffing)

• パスワードリスト攻撃
• 他のサービスなどで漏洩したID・パスワードを利用した攻撃

トークンが偽造される原因

• 低いランダム性
• 推測可能

JWTの悪用

NONE攻撃

• ハッシュアルゴリズムにnoneを指定されているJWTを発見したら利用可能
• ペイロードを自由に変更できる
  • ユーザーIDをrootやadminなどに変更してリクエストに使ってみる

アルゴリズム変更攻撃(Algorithm Switch Attack)

• APIプロバイダが送信されたJWTの署名やアルゴリズムを検証してない場合に発生
• 署名を検証していない場合、署名を削除して送信したらリクエストが通るかも
• アルゴリズムを検証してない場合、noneに書き換えたらペイロードを変更してもリクエストが通るかも
• アルゴリズムをRS256からHS256に変更できる場合、公開鍵で作成した署名でリクエストが通るかも

JWTクラック攻撃

• 署名ハッシュに利用されるシークレットを解読し、有効なJWTを作成する攻撃
• オフラインで実行されるため、プロバイダとやり取りしない(攻撃を検知されない)