APIセキュリティテスト

はじめに：APIセキュリティテストの概要

攻撃者にとって、APIは重要な攻撃対象です。機密データや必要なアプリ機能へのアクセスを許可する設計であり、その詳細な手順が記されていることもあります。結果、攻撃者にとっては具体的かつ詳細な攻撃マニュアルとなるのです。SDLCのプロセスやAppSec、製品セキュリティ、品質管理の各チームは、こうした目的のためにAPIセキュリティ検査を組み入れる必要があります.  

APIはセキュリティを確保するため、APIセキュリティ評価の過程で検査されます。アプリのセキュリティ評価と異なり、API評価では潜在的な欠陥を探り、APIを通じて送受信されるデータの整合性を確認します. 

また、APIに危険なマルウェアが含まれていないか、外部からの不正アクセスが行われていないかも確認されます。ソフトウェアは常に脆弱性に晒され、攻撃者がその欠陥を突いて重要なデータを奪う手口があるため、現在のソフトウェア開発においてAPIセキュリティ評価は不可欠です。APIには数多くのセキュリティリスクが存在します。

‍

なぜAPIの安全確保にテストが重要なのか

前述のとおり、APIはアプリ間で情報を送受信する手段です。悪意ある者が貴社のAPIの機密性を損なえば、ウェブサイト内の機密情報が流出する恐れがあります。

その他、APIセキュリティ侵害による悪影響として、次のような事象が考えられます：

• 顧客データやプライバシーの漏洩。（万が一、ダークウェブに流出して販売されたら）
• ウェブサイトや事業への攻撃。企業の評価や実績に悪影響を及ぼす可能性があります。
• 利用者数や収益の減少。
• 過失による訴訟リスク。

多くのアプリの主要機能はAPIによって提供され、プログラマーには企業のサービスへ直接アクセスする手段が与えられています。企業全体の安全を保つためには、APIが定められた要件を満たし、不正確または有害な情報に対して耐性を持つ必要があります。

従来の動的アプリセキュリティテスト（DAST）では、APIは部分的にしか検査されません。企業のフロントエンドがAPIと連動していない場合、従来のDASTではAPIエンドポイントを検出できないのです。したがって、各APIの出力に存在する問題に着目した、最新かつ柔軟なAPIセキュリティ評価手法の導入が重要です。

仕組み

API検査には複数の種類が存在します。ソースコードには潜在的な脆弱性を示す兆候が隠れている場合があります. 

静的評価やシステム構成評価では、こうした傾向と履歴を調査し、脆弱なプログラムやモジュールを特定します。対話型API検査は、APIの反応に応じた継続的な問い合わせを行い、潜在的なリスクを明らかにします。

例えば、SQLインジェクションに弱いREST APIルートに対し、対話型モニタリングツールが問い合わせを行うと、APIからの応答によってデータベースの整合性が攻撃に晒されていることが示される場合があります。

このようなセキュリティ評価は、問い合わせを送信して応答を確認するため、「逆行型セキュリティ評価」と呼ばれることもあります。

APIセキュリティテストを利用する利点

標準的なAPI検査により、脆弱性や企業にとってのリスク要因を特定し、防ぐことが可能です. 

特に、APIセキュリティ評価は評価対象のAPIに合わせ、企業全体の方針やベストプラクティスに基づいて実施されます。シングルページウェブアプリ、IoT、スマートフォンアプリで利用されるAPIは、より高度なレベルで検査されます。API解析ツールは、APIが求める入力を把握することで、隠れた脆弱性を巧妙に見つけ出すことができます。

また、APIセキュリティテストツールは、アプリのフロントエンドでのデータ入力検証だけでなく、API自体の機能を検証することで、正確な動作を担保する手助けをします。

APIが公開APIガイドラインから逸脱している箇所を発見することも、セキュリティ評価で可能です。例えば、あるルートが特定のHTTPステータスを返すことが期待されるにもかかわらず、異なる値を返した場合、監査担当者が該当する関係者に通知します。これにより、APIを利用するプログラマーが定められたガイドラインに沿ったユーザーインターフェースを受け取ることが保証されます。

‍

APIセキュリティテストの種類

以下は主なAPIセキュリティ評価の種類です：

FAST - 自動化セキュリティテストのフレームワーク

大きな手間をかけることなく、セキュリティテストの範囲を大幅に拡大できます。FASTは、fuzzerや既存の脆弱性注入ツールを用い、各機能テストに対して動的に1000回のセキュリティチェックを生成・実行します。WallarmのFASTには、DevOpsチームが短期間でアプリの安全性を管理するための多くの特徴があり、WallarmはAPI Security Platformという製品も提供しています。

DAST - 動的アプリセキュリティテスト

APIエンドポイントに対してライブな（動的な）チェックを実施することは、API評価の最適な方法とされています。いくつかのSASTやSCAツールもAPI対応ですが、API向けに設計されていない旧式のDASTツールで過度なテストを行うのは避けるべきです. 

即時性のあるAPIセキュリティ分析は、実際の攻撃を再現します。これにより、貴社やチームが構築したソフトウェア、またオープンソースライブラリへの依存による脆弱性を特定できます. 

動的評価とSAST、SCAを組み合わせることで、より信頼性の高いAPIセキュリティ評価手法を構築できますが、APIを守るための出発点としては、DASTが最適です。

SAST - 静的解析セキュリティテスト

SASTは、プログラムの基礎コードにセキュリティ上の欠陥がないかを検査する手法です。

CASEツールの一形態である静的評価は、コードを実行せずにソースコードを調査します。プログラムやシステム内のコーディングミス、設計上の欠陥、セキュリティホールの発見に用いられます。

Software Composition Analysis (SCA) - ソフトウェア構成分析

SCAは、ソフトウェア開発において、構成要素とその関連性を検出するための手法です。アプリの設計評価、問題のあるソフトウェアの特定、または特定機能に必要なコード量の把握に利用されます。

Authentication - 認証

環境やシステム、ネットワークへアクセスする際、認証はユーザーやデバイスの存在を確認する手段です。すべてのアプリでユーザー認証は必要であり、ログイン・パスワード認証、多要素認証、API認証などさまざまな方法が用いられます。

APIにおいては、パスワードを用いて個人の認証を行います。プライベート、パブリックどちらのAPIでもこの方式が利用されます。

Authorization - 認可

API認可プロセスでは、個人の資格情報を確認し、アプリ機能の利用許可を与えます。これは、適切なヘッダーやトークンを含むHTTPリクエストを送信することで実施され、APIはリクエストの有効性に関する詳細を返します。

Fuzz testing - ファズテスト 

ファズテストは、ランダムまたは誤った情報をAPIに送ることで、ネットワークを破壊したりセキュリティ上の不具合を発見する手法です。不正な侵入者が機密情報にアクセスしたり、APIを乗っ取る原因となります。

接続の両端からのファズテスト攻撃により、システムの停止や機密情報の流出が狙われることもあります。特に、サーバー側で不正なデータを送信する手法が用いられます。

APIテストで守れる脆弱性とは

APIセキュリティ評価では、APIに関連する様々な脅威を検出できます。OWASPが定義した上位3つのAPI欠陥は、セキュリティ評価の最初の焦点として貴重な情報を提供します：

• API1 オブジェクトレベル認可の欠陥
• API2 ユーザー認証の欠陥 
• API3 過剰なデータ露出 
• API4 リソース不足・レート制限の欠如
• API5 機能レベル認可の欠陥
• API6 大量割当
• API7 セキュリティ設定ミス
• API8 インジェクション
• API9 不適切な資産管理
• API10 ログ記録・監視不足

‍

APIセキュリティテストチェックリスト

セキュリティテストに関する情報は既にいくつか紹介されました。これらを整理し、評価計画を立て実施する際に利用できるチェックリストとしてまとめます: 

• 独立したテスト環境を構築する。業務に影響を与えずにAPI評価を行えるよう、まず通常の動作を前提とした機能テストを作成し、適切なツール群で実行する。
• 同一のツールを使用すると、極端なシナリオでのセキュリティテストに起因する問題が浮上する場合があります。したがって、各デプロイ環境を区別できる仕組みを持つことが望ましい。
• ‍すべてのAPIの役割や認証方式に関して包括的なドキュメントを作成する。様々な権限や機密資産へのアクセスを持つユーザーを対象にテストを行い、これらが許可されていないリソースにアクセスを試みるシナリオを用意する。
• APIをブラックボックスと考えず、常にバックエンドの抜け穴を見抜く努力を続ける（例：大量割当、SQLインジェクションなど）。
• ‍制限を超えるデータを用いた評価を実施する。たとえば、属性の追加、設定された制限の超過、または必要に応じたSQLインジェクションのコマンド送信などが含まれます。
• ‍すべてのエラー応答において内部情報の漏洩を注視する。

高負荷時の異常な挙動が機密性を損なわないよう、パフォーマンステストにセキュリティ評価を組み込むことも忘れずに。