皆さん、こんにちは！セキュリティバイブル主筆ライターの私がお届けする、今日のセキュリティ講座へようこそ。
Webの世界は本当に便利になりましたよね。スマホをタップするだけで買い物ができるし、銀行の残高もすぐに確認できます。でも、この便利な裏側には、常に「落とし穴」が潜んでいることを忘れてはいけません。
今回は、皆さんがサービスを開発・運用する上で、ぜひ知っておいてほしい「APIリクエストの改ざん検知」について、家の鍵や泥棒に例えながら、優しく、そして実践的に学んでいきましょう！
目次
1. APIリクエストって、そんなに危ないの？ ～泥棒の視点から考える～
2. なぜ今、API通信の「改ざん検知」が重要なのか？
3. 「通信の署名」って何だろう？ ～郵便物の封蝋に例えてみよう～
4. HMAC（Hash-based Message Authentication Code）でAPI通信を守る
- HMACの仕組み
- PythonによるHMAC署名生成のコード例
- サーバー側でのHMAC検証のコード例
5. デジタル署名（RSAなど）でさらに強固に！
- デジタル署名の仕組み
- Pythonによるデジタル署名生成・検証のコード例
6. 防御のポイント：これだけは押さえておきたい！
- タイムスタンプとNonce（ナンス）の活用
- HTTPS/TLSとの併用は絶対！
- 秘密鍵/プライベートキーの厳重な管理
- 署名対象データの選定
- エラーハンドリング
7. まとめ：一歩ずつ、安全な未来へ
—
1. APIリクエストって、そんなに危ないの？ ～泥棒の視点から考える～
皆さんが開発するWebサービスやアプリは、ほとんどの場合、裏側で「API」と呼ばれる仕組みを通じてデータのやり取りをしています。例えば、
- 「商品Aをカートに入れる」
- 「ユーザーBのパスワードを変更する」
- 「口座から1000円を送金する」
といった操作は、すべてAPIリクエストという「指令書」がサーバーに送られることで実行されます。
想像してみてください。もし、この「指令書」が、皆さんの知らないところで書き換えられたり、悪用されたりしたらどうなるでしょうか？
攻撃のメカニズム：泥棒はこう狙う！
1-1. パラメータ改ざん（指令書の書き換え）
泥棒が郵便物を盗み見て、中の指示を書き換えるようなイメージです。
- 例1：ECサイトでの改ざん
- あなたが「商品Aを100円で注文する」というAPIリクエストを送ったとします。
- 途中で泥棒がそのリクエストを捕まえ、「100円」を「0円」に書き換えてサーバーに送りつけたら？ 無料で商品を手に入れられてしまいますよね。
- 例2：送金指示の改ざん
- あなたが「自分の口座から友人Cの口座へ1000円を送金する」というAPIリクエストを送ったとします。
- 泥棒が「友人Cの口座」を「泥棒自身の口座」に、あるいは「1000円」を「1000万円」に書き換えてしまったら……？ 大変なことになります。
1-2. リプレイ攻撃（指令書の使い回し）
泥棒が、一度使われた指令書を何度もコピーして使い回すようなイメージです。
- 例：オンラインゲームのアイテム購入
- あなたがゲーム内で貴重なアイテムを1つ購入したとします。これは「アイテムXを1つ購入する」というAPIリクエストがサーバーに送られて実行されます。
- 泥棒がこのリクエストを盗聴し、全く同じリクエストを何度もサーバーに送りつけたらどうでしょう？ 同じアイテムを不正に何個も手に入れられてしまいます。
- 銀行の送金APIなら、一度の送金指示が何度も実行されてしまう、といった深刻な事態も起こり得ます。
API通信の改ざんは、皆さんのサービスにとって金銭的損失、信用失墜、ユーザーデータ破壊など、計り知れない損害をもたらす可能性があります。怖いですよね。
2. なぜ今、API通信の「改ざん検知」が重要なのか？
「あれ？ XSSの話じゃなかったの？」と思われた方もいるかもしれません。今回のテーマはXSSそのものではありませんが、非常に密接な関係にあります。
XSS（クロスサイトスクリプティング）は、悪意のあるスクリプトをWebページに埋め込み、ユーザーのブラウザ上で実行させる攻撃でしたよね。これにより、攻撃者はユーザーのセッションクッキーを盗んだり、ブラウザ上で不正な操作を行わせたりできます。
もし、XSSによってユーザーのセッション情報が奪われてしまったら……？
攻撃者はそのセッション情報を使って、まるで正規のユーザーであるかのように、不正なAPIリクエストを送りつけることが可能になってしまいます。
つまり、XSSのような脆弱性でセッションが乗っ取られた後に、そのセッションを使った不正なAPIリクエストが実行されるのを防ぐのが、今回の「API通信の改ざん検知」の役割なんです。
ユーザーのブラウザとサーバー間の「通信の信頼性」を確保することが、Webサービス全体のセキュリティを守る上で非常に重要になる、ということですね。
3. 「通信の署名」って何だろう？ ～郵便物の封蝋に例えてみよう～
では、どうすれば泥棒が指令書を改ざんしたり、使い回したりするのを防げるのでしょうか？
一番効果的なのが「署名（デジタル署名）」という仕組みです。
昔、重要な手紙や文書が改ざんされていないことを示すために、「封蝋（ふうろう）」という特別なロウで封印し、家紋や印鑑を押していましたよね。もし封蝋が破られていれば、誰かが中身を改ざんしようとした、あるいは開けたことがすぐに分かります。
デジタル署名も、これと似たような考え方です。
APIリクエストという「指令書」に、送信者が「これは私が送ったもので、内容は一切改ざんされていません！」という証明として、特別な「デジタルなハンコ」を押すイメージです。
受信者（サーバー）は、このハンコが本物かどうか、そして指令書の内容とハンコがピッタリ合っているかを検証します。もし少しでも改ざんされていたら、ハンコと内容が合わなくなり、「これは怪しい！」とすぐに検知できるわけです。
この「デジタルなハンコ」にはいくつか種類がありますが、今回は特にAPI通信でよく使われる「HMAC」と「デジタル署名」について見ていきましょう。
4. HMAC（Hash-based Message Authentication Code）でAPI通信を守る
HMACは、API通信の改ざん検知によく使われる技術の一つです。「共通の秘密の鍵」を使って、メッセージ（APIリクエストの内容）の「署名」を作成・検証します。
HMACの仕組み
1. 秘密の鍵の共有: 送信者（クライアントアプリなど）と受信者（サーバー）は、あらかじめお互いだけが知っている「秘密の鍵」を共有しておきます。これは、家の合鍵のようなものです。
2. 署名（MAC）の生成: 送信者は、APIリクエストの重要な部分（URL、パラメータ、ボディ、そして「いつ送られたか」を示すタイムスタンプなど）を全部集めて一つの文字列にします。この文字列と秘密の鍵を使って、特定の計算（ハッシュ関数）を行い、短い「署名（MAC）」を生成します。
3. 署名の添付: 生成された署名を、APIリクエストのHTTPヘッダーなどに含めてサーバーに送ります。
4. 署名の検証: サーバーは、受け取ったAPIリクエストから送信者と同じように署名対象の文字列を作り、共有している秘密の鍵を使って同じように署名を計算します。
5. 一致確認: サーバーが計算した署名と、クライアントから送られてきた署名がピッタリ一致すれば、「このリクエストは途中で改ざんされていない、本物だ！」と判断します。もし一致しなければ、改ざんされたと判断してリクエストを拒否します。
PythonによるHMAC署名生成のコード例（クライアント側）
ここでは、Pythonを使ってクライアント側でHMAC署名を生成し、APIリクエストのヘッダーに付与する例を見てみましょう。
import hmac
import hashlib
import time
import json
import requests
import base64
— 設定情報 —
API_KEY = “your_api_key_here” # クライアント識別子 (例: ユーザーIDやアプリID)
SECRET_KEY = “your_super_secret_key”.encode(‘utf-8’) # サーバーと共有する秘密鍵 (バイト列にする)
API_BASE_URL = “http://localhost:8000/api/v1/order” # APIのエンドポイントURL
def generate_hmac_signature(method: str, path: str, body: dict, timestamp: int, api_key: str, secret_key: bytes) -> str:
“””
HMAC署名を生成する関数
:param method: HTTPメソッド (GET, POSTなど)
:param path: APIのパス (例: /api/v1/order)
:param body: リクエストボディ (辞書型)
:param timestamp: 現在のUnixタイムスタンプ (秒)
:param api_key: クライアント識別子
:param secret_key: 共有秘密鍵 (バイト列)
:return: base64エンコードされたHMAC署名文字列
“””
# 署名対象となる文字列を作成
# 重要なのは、サーバー側も全く同じ順序、同じ形式でこの文字列を生成することです。
# ここでは、メソッド、パス、タイムスタンプ、APIキー、ボディのJSON文字列を結合しています。
# ボディは常にソートしてJSON化することで、順序による差異を防ぎます。
body_json = json.dumps(body, sort_keys=True, separators=(‘,’, ‘:’)) if body else “”
# 署名対象文字列の生成。改行コードなどで結合すると、サーバー側との差異が生じやすいので注意。
# 一般的には特定の区切り文字（例: . や &）を使うか、単に連結します。
# ここでは改行で結合していますが、環境によっては問題になる場合があるため注意してください。
# より堅牢にするには、str.join()や固定フォーマットの使用を推奨します。
# 例: signature_base = f”{method}.{path}.{timestamp}.{api_key}.{body_json}”
signature_base_string = f”{method}\n{path}\n{timestamp}\n{api_key}\n{body_json}”
# HMAC-SHA256を使って署名を生成
# 署名対象文字列をバイト列にエンコード
hmac_obj = hmac.new(secret_key, signature_base_string.encode(‘utf-8’), hashlib.sha256)
# 生成されたダイジェストをbase64エンコードして文字列として返す
return base64.b64encode(hmac_obj.digest()).decode(‘utf-8’)
— APIリクエストの準備 —
method = “POST”
path = “/api/v1/order”
request_body = {
“item_id”: “ABC123”,
“quantity”: 1,
“price”: 100,
“user_id”: “user_123”
}
timestamp = int(time.time()) # 現在のUnixタイムスタンプ (秒)
HMAC署名を生成
signature = generate_hmac_signature(method, path, request_body, timestamp, API_KEY, SECRET_KEY)
リクエストヘッダーに署名とタイムスタンプ、APIキーを含める
headers = {
“Content-Type”: “application/json”,
“X-Api-Key”: API_KEY,
“X-Signature”: signature,
“X-Timestamp”: str(timestamp)
}
APIリクエストを送信
try:
response = requests.post(API_BASE_URL, headers=headers, data=json.dumps(request_body))
response.raise_for_status() # HTTPエラーがあれば例外を発生させる
print(f”APIリクエスト成功！ ステータスコード: {response.status_code}”)
print(f”レスポンス: {response.json()}”)
except requests.exceptions.HTTPError as errh:
print(f”HTTPエラー: {errh}”)
except requests.exceptions.ConnectionError as errc:
print(f”接続エラー: {errc}”)
except requests.exceptions.Timeout as errt:
print(f”タイムアウト: {errt}”)
except requests.exceptions.RequestException as err:
print(f”その他のエラー: {err}”)
サーバー側でのHMAC検証のコード例（Python – Flaskを想定）
次に、サーバー側（ここではPythonのFlaskフレームワークを想定）で、送られてきたリクエストのHMAC署名を検証する例を見てみましょう。
from flask import Flask, request, jsonify
import hmac
import hashlib
import time
import json
import base64
app = Flask(__name__)
— 設定情報 (サーバー側も同じ秘密鍵を持つ) —
SECRET_KEY = “your_super_secret_key”.encode(‘utf-8’) # クライアントと共有する秘密鍵 (バイト列にする)
API_KEYS = { # 認証するAPIキーのリスト (実際はDBなどから取得)
“your_api_key_here”: {“name”: “MyClientApp”, “secret”: SECRET_KEY}
}
TIMESTAMP_TOLERANCE_SECONDS = 300 # タイムスタンプの許容範囲 (例: 5分 = 300秒)
def verify_hmac_signature(method: str, path: str, body_bytes: bytes, timestamp_str: str, api_key: str, expected_signature: str) -> bool:
“””
HMAC署名を検証する関数
:param method: HTTPメソッド
:param path: APIのパス
:param body_bytes: リクエストボディ (バイト列)
:param timestamp_str: タイムスタンプ文字列
:param api_key: クライアント識別子
:param expected_signature: クライアントから送られてきた署名
:return: 署名が有効ならTrue、そうでなければFalse
“””
# 1. APIキーの存在と秘密鍵の取得
client_info = API_KEYS.get(api_key)
if not client_info:
print(f”Unknown API Key: {api_key}”)
return False
client_secret_key = client_info[“secret”]
# 2. タイムスタンプの検証 (リプレイ攻撃対策)
try:
request_timestamp = int(timestamp_str)
current_timestamp = int(time.time())
# タイムスタンプが古すぎる、または未来すぎる場合は拒否
if not (current_timestamp – TIMESTAMP_TOLERANCE_SECONDS <= request_timestamp <= current_timestamp + TIMESTAMP_TOLERANCE_SECONDS):
print(f"Timestamp out of range. Request: {request_timestamp}, Current: {current_timestamp}")
return False
except ValueError:
print("Invalid timestamp format.")
return False
# 3. 署名対象文字列の生成 (クライアント側と全く同じロジックで！)
# リクエストボディをJSONとしてパースし、ソートして再度JSON文字列に変換
# クライアント側と同じく、ボディが空の場合は空文字列
if body_bytes:
try:
body_dict = json.loads(body_bytes.decode('utf-8'))
body_json = json.dumps(body_dict, sort_keys=True, separators=(',', ':'))
except json.JSONDecodeError:
print("Invalid JSON body.")
return False # JSON形式でない場合は検証失敗
else:
body_json = ""
# クライアント側と全く同じ署名対象文字列を作成
# 改行コードなどで結合すると、サーバー側との差異が生じやすいので注意。
signature_base_string = f"{method}\n{path}\n{timestamp_str}\n{api_key}\n{body_json}"
# 4. サーバー側でHMAC署名を再生成
hmac_obj = hmac.new(client_secret_key, signature_base_string.encode('utf-8'), hashlib.sha256)
calculated_signature = base64.b64encode(hmac_obj.digest()).decode('utf-8')
# 5. 送られてきた署名と計算した署名を比較 (hmac.compare_digestでタイミング攻撃を防ぐ)
if hmac.compare_digest(calculated_signature, expected_signature):
return True
else:
print(f"Signature mismatch. Calculated: {calculated_signature}, Expected: {expected_signature}")
return False
@app.route('/api/v1/order', methods=['POST'])
def create_order():
# ヘッダーから必要な情報を取得
api_key = request.headers.get("X-Api-Key")
signature = request.headers.get("X-Signature")
timestamp = request.headers.get("X-Timestamp")
# ヘッダー情報の存在チェック
if not all([api_key, signature, timestamp]):
return jsonify({"message": "Missing required headers (X-Api-Key, X-Signature, X-Timestamp)"}), 400
# HMAC署名検証
# request.data はリクエストボディの生バイト列を取得
if not verify_hmac_signature(request.method, request.path, request.data, timestamp, api_key, signature):
return jsonify({"message": "Invalid or tampered request signature"}), 401 # 認証失敗
# 署名検証が成功した場合のみ、リクエストを処理
try:
request_data = request.json # 検証済みなので、安全にJSONとしてパース
print(f"Valid request received for API Key: {api_key}. Order data: {request_data}")
# ここでデータベースへの保存などのビジネスロジックを実行...
return jsonify({"status": "success", "message": "Order placed successfully", "order_id": "ORD_XYZ789"}), 200
except Exception as e:
print(f"Error processing order: {e}")
return jsonify({"message": "Error processing request"}), 500
if __name__ == '__main__':
# 開発環境での実行。本番環境ではWSGIサーバー (Gunicorn, uWSGIなど) を使用
app.run(debug=True, port=8000)
ポイント！
- 秘密鍵の管理:
SECRET_KEYは絶対に外部に漏らしてはいけません。環境変数や専用のキー管理サービス（KMS）で厳重に管理しましょう。 - 署名対象の統一: クライアントとサーバーで、どの情報をどのような順序で結合して署名対象文字列にするか、厳密にルールを決め、完全に一致させる必要があります。少しでも異なると署名検証は失敗します。
- タイムスタンプ: リプレイ攻撃を防ぐために、署名対象にタイムスタンプを含め、サーバー側で「古すぎるリクエスト」や「未来のリクエスト」を拒否するロジックは必須です。
TIMESTAMP_TOLERANCE_SECONDSを設定し、許容範囲を決めましょう。 hmac.compare_digest(): 署名比較には、必ずこれを使ってください。単なる==演算子だと「タイミング攻撃」という脆弱性の原因になることがあります。
5. デジタル署名（RSAなど）でさらに強固に！
HMACは共通の秘密鍵を使うため、クライアントとサーバーが同じ鍵を知っている必要があります。これは、特に多数のクライアントが存在する場合や、クライアント側が完全に信頼できない環境（Webブラウザ上のJavaScriptなど）では管理が難しくなることがあります。
そこで登場するのが「デジタル署名」です。これは「公開鍵暗号」の技術を応用したもので、HMACよりもさらにセキュリティレベルを高めることができます。
デジタル署名の仕組み
デジタル署名では、「秘密鍵」と「公開鍵」というペアの鍵を使います。
- 秘密鍵: 署名する側（クライアント）だけが持ち、誰にも見せてはいけません。
- 公開鍵: 署名を検証する側（サーバー）が持ち、誰に公開しても安全です。
1. 鍵ペアの生成: クライアントは、秘密鍵と公開鍵のペアを生成します。
2. 公開鍵の共有: クライアントは、生成した公開鍵をサーバーに渡しておきます。
3. 署名の生成: クライアントは、APIリクエストの内容と自分の秘密鍵を使って、特別な「デジタル署名」を生成します。
4. 署名の添付: 生成された署名を、APIリクエストのHTTPヘッダーなどに含めてサーバーに送ります。
5. 署名の検証: サーバーは、受け取ったAPIリクエストの内容、クライアントから送られてきた署名、そしてクライアントの公開鍵を使って、署名が本物かどうかを検証します。
- もし内容が少しでも改ざんされていたら、公開鍵では検証できません。
- もし違うクライアント（秘密鍵を持っていない泥棒）が署名したものなら、そのクライアントの公開鍵では検証できません。
デジタル署名のメリットは、秘密鍵を共有する必要がないため、クライアントごとの秘密鍵管理が容易になる点、そして「否認防止」の機能がある点です。つまり、「この署名は確かに私が行ったものです」と後から否定できない（署名を偽造できない）という証明になります。
Pythonによるデジタル署名生成・検証のコード例（概念的）
デジタル署名の実装はHMACより複雑になりますが、基本的な流れは同じです。
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import serialization
import time
import json
import base64
— 鍵ペアの生成 (通常は一度だけ行い、安全に保存します) —
def generate_rsa_key_pair():
# 秘密鍵を生成
private_key = rsa.generate_private_key(
public_exponent=65537,
key_size=2048 # 鍵の長さ。2048ビット以上が推奨
)
# 公開鍵を取得
public_key = private_key.public_key()
return private_key, public_key
— 秘密鍵と公開鍵のPEM形式への変換 (保存・転送用) —
def serialize_private_key(private_key):
return private_key.private_bytes(
encoding=serialization.Encoding.PEM,
format=serialization.PrivateFormat.PKCS8,
encryption_algorithm=serialization.NoEncryption() # 本番ではパスフレーズで暗号化推奨
).decode(‘utf-8’)
def serialize_public_key(public_key):
return public_key.public_bytes(
encoding=serialization.Encoding.PEM,
format=serialization.PublicFormat.SubjectPublicKeyInfo
).decode(‘utf-8’)
— クライアント側: 署名生成 —
def sign_request(private_key, method: str, path: str, body: dict, timestamp: int) -> str:
“””
APIリクエストにデジタル署名を行う関数
:param private_key: 署名に使う秘密鍵オブジェクト
:param method: HTTPメソッド
:param path: APIのパス
:param body: リクエストボディ
:param timestamp: タイムスタンプ
:return: base64エンコードされた署名文字列
“””
body_json = json.dumps(body, sort_keys=True, separators=(‘,’, ‘:’)) if body else “”
signature_base_string = f”{method}\n{path}\n{timestamp}\n{body_json}”
# 署名対象文字列をバイト列に変換
data_to_sign = signature_base_string.encode(‘utf-8’)
# 秘密鍵で署名を生成
signature = private_key.sign(
data_to_sign,
padding.PSS( # PSSパディングスキームを使用 (RSA署名の推奨方式)
mgf=padding.MGF1(hashes.SHA256()),
salt_length=padding.PSS.MAX_LENGTH
),
hashes.SHA256() # SHA256ハッシュアルゴリズムを使用
)
return base64.b64encode(signature).decode(‘utf-8’)
— サーバー側: 署名検証 —
def verify_signature(public_key, signature: str, method: str, path: str, body: dict, timestamp: int) -> bool:
“””
デジタル署名を検証する関数
:param public_key: 検証に使う公開鍵オブジェクト
:param signature: クライアントから送られてきたbase64エンコードされた署名
:param method: HTTPメソッド
:param path: APIのパス
:param body: リクエストボディ
:param timestamp: タイムスタンプ
:return: 署名が有効ならTrue、そうでなければFalse
“””
body_json = json.dumps(body, sort_keys=True, separators=(‘,’, ‘:’)) if body else “”
signature_base_string = f”{method}\n{path}\n{timestamp}\n{body_json}”
data_to_verify = signature_base_string.encode(‘utf-8’)
decoded_signature = base64.b64decode(signature)
try:
# 公開鍵で署名を検証
public_key.verify(
decoded_signature,
data_to_verify,
padding.PSS(
mgf=padding.MGF1(hashes.SHA256()),
salt_length=padding.PSS.MAX_LENGTH
),
hashes.SHA256()
)
return True # 検証成功
except Exception as e:
print(f”Signature verification failed: {e}”)
return False # 検証失敗
— 使用例 —
if __name__ == ‘__main__’:
# 鍵ペアを生成 (実際は一度生成してファイルなどに保存)
client_private_key, client_public_key = generate_rsa_key_pair()
# クライアントの公開鍵をPEM形式でサーバーに渡す (実際は登録済みの公開鍵を使う)
server_knows_public_key_pem = serialize_public_key(client_public_key)
# サーバー側ではPEM文字列から公開鍵オブジェクトにデシリアライズして使用
server_public_key = serialization.load_pem_public_key(server_knows_public_key_pem.encode(‘utf-8’))
# クライアント側のリクエスト準備
method = “POST”
path = “/api/v1/payment”
request_body = {“amount”: 5000, “currency”: “JPY”, “to_account”: “ACC_456″}
timestamp = int(time.time())
# クライアントで署名を生成
client_signature = sign_request(client_private_key, method, path, request_body, timestamp)
print(f”クライアント生成署名: {client_signature}”)
# サーバー側で検証 (送られてきたリクエストデータと署名を使用)
is_valid = verify_signature(server_public_key, client_signature, method, path, request_body, timestamp)
if is_valid:
print(“署名検証成功！リクエストは本物で改ざんされていません。”)
else:
print(“署名検証失敗。リクエストは不正か、改ざんされています。”)
# — 改ざんされた場合の例 —
print(“\n— 改ざんされたリクエストの検証 —“)
tampered_body = {“amount”: 500000, “currency”: “JPY”, “to_account”: “ACC_456”} # 金額を改ざん！
is_valid_tampered = verify_signature(server_public_key, client_signature, method, path, tampered_body, timestamp)
if is_valid_tampered:
print(“【エラー】改ざんされたリクエストがなぜか検証成功してしまいました！”)
else:
print(“改ざんされたリクエストは正しく検知されました。”)
ポイント！
- 鍵管理: 秘密鍵は絶対に漏洩させてはなりません。漏洩すれば、攻撃者が偽の署名を作成できてしまいます。
- 鍵の更新: 定期的に鍵ペアを更新する「鍵のローテーション」も重要です。
- 証明書: 信頼性をさらに高めるには、公開鍵を「X.509証明書」として認証局（CA）に署名してもらい、その証明書ごとクライアントに渡す方法もあります。
6. 防御のポイント：これだけは押さえておきたい！
HMACやデジタル署名を使った改ざん検知は強力な防御策ですが、いくつかの重要なポイントを押さえることで、より盤石なセキュリティを築くことができます。
6-1. タイムスタンプとNonce（ナンス）の活用
リプレイ攻撃を防ぐための最も重要な要素がタイムスタンプです。
- タイムスタンプ: リクエストが送信された時刻を署名対象に含め、サーバー側で「現在の時刻から見て、許容範囲（例：前後5分以内）を外れたリクエストは拒否する」というルールを設けます。
- Nonce（ナンス）: 「Number used once」の略で、「一度だけ使われるランダムな値」のことです。署名対象に含め、サーバー側で「このNonceは過去に使われたことがあるか？」をチェックし、もし使われていたら拒否します。これにより、同じリクエストが複数回送られてくるのを確実に防げます。タイムスタンプと併用することで、より強固なリプレイ攻撃対策になります。
6-2. HTTPS/TLSとの併用は絶対！
今回の「署名」による改ざん検知は、あくまで「途中で内容が書き換えられていないか」をチェックするものです。
しかし、通信そのものが盗聴されてしまうと、署名対象のデータや生成された署名、さらにはHMACの秘密鍵（共有鍵の場合）などが漏洩するリスクがあります。
これを防ぐのがHTTPS（TLS/SSL）です。HTTPSは通信路を暗号化し、盗聴や中間者攻撃から保護します。
署名による改ざん検知は、HTTPSによる暗号化の上に成り立って初めて、その真価を発揮します。 どちらか一方だけでは不十分で、必ず両方セットで利用しましょう。
6-3. 秘密鍵/プライベートキーの厳重な管理
HMACの共有秘密鍵も、デジタル署名のプライベートキーも、これが漏洩してしまえば、攻撃者が正規の署名を偽造できてしまいます。まさに「家の合鍵」が泥棒の手に渡るようなものです。
- 環境変数: アプリケーションコードに直接書き込まず、環境変数として渡す。
- キー管理サービス（KMS）: AWS KMS、Azure Key Vault、Google Cloud KMSなどの専用サービスを利用し、鍵の生成、保存、利用を安全に行う。
- アクセス制限: 鍵が保存されているサーバーやファイルへのアクセス権限を厳しく制限する。
6-4. 署名対象データの選定
「何を署名対象にするか？」は非常に重要です。
- HTTPメソッド（GET, POSTなど）
- APIパス（
/api/v1/orderなど） - クエリパラメータ（
?param=value） - リクエストボディ全体
- タイムスタンプ
- クライアント識別子（APIキーなど）
これらのうち、リクエストの「意図」を変えうる重要な情報は、すべて署名対象に含めるべきです。そして、クライアントとサーバーで、署名対象文字列の生成ロジックが完全に一致していることが非常に重要です。
6-5. エラーハンドリング
署名検証に失敗した場合、サーバーはどのように応答すべきでしょうか？
基本的には、401 Unauthorized や 403 Forbidden といったHTTPステータスコードを返し、リクエストの処理を拒否すべきです。
ただし、エラーメッセージで「なぜ失敗したのか」を具体的に伝えすぎると、攻撃者にヒントを与えてしまう可能性があるので注意が必要です。「署名が無効です」のような抽象的なメッセージに留めるのが一般的です。
7. まとめ：一歩ずつ、安全な未来へ
今回は、APIリクエストの改ざん検知という、Webサービスを安全に運用する上で非常に重要なテーマについて深掘りしました。
泥棒が指令書を書き換えたり、使い回したりするのを防ぐために、HMACやデジタル署名という「デジタルなハンコ」がいかに有効か、ご理解いただけたでしょうか。
セキュリティ対策は、一度やれば終わりではありません。新しい攻撃手法が日々生まれる中で、私たち開発者も常に学び、対策をアップデートしていく必要があります。
今回ご紹介した仕組みは、一見複雑に見えるかもしれませんが、一つ一つの要素を分解して理解すれば、決して難しいものではありません。
「家の鍵をしっかりかける」「郵便物に封蝋をする」といった身近な防犯対策と同じように、Webの世界でも基本的な仕組みを理解し、適切に実装することが、皆さんのサービスとユーザーを守る盾となります。
焦らず、一歩ずつ対策を学んでいきましょう！安全なWebサービスは、皆さんの努力の積み重ねでできています。
それでは、また次回のセキュリティ講座でお会いしましょう！
コメント