API とWebhookのセキュリティ
WebhookはリバースAPIと言われるように実質ただのAPIです。
一方的に送るのがWebhookなんて言われますが
送信元を確認仕返せるAPIがなければビジネス利用できるセキュアな実装と言えないので
方向がただ逆になったという理解で良いでしょう。
アクセスをオープンにして待っている（突っ込まれる）側は逆になるので
セキュリティリスクを負う側、テスト工数負荷が多くなるのも逆側になります。
クライアント側がまだできていない場合はPostmanといったツールを使ったりcurlコマンドで送信したりで脆弱性診断を行うケースもあります。この場合、完成時の挙動に関し想像力を働かし想定し得るリスクに関してよくすり合わせておく必要性があります。
curl –proxy “ローカルプロキシのIP:ポート番号”-X POST “対象APIのURI” -H “リクエストヘッダ” -d “リクエストボディ”
API とWebhookの共通のセキュリティ観点
トークンやシグニチャによる要求元確認
重要な処理の実行時は有効期限や要求元の一意性をサーバ側で担保できるトークンやシグニチャを利用しましょう。
その際、パスパラメータ、クエリパラメータ値ではなくリクエストボディもしくはヘッダーで送りましょう。
暗号化通信の担保
非暗号通信だめ絶対、ZoomもE2Eの暗号化の問題があったりiOSのVPN接続時の暗号化が不完全である問題など今非暗号か問題は意外とホットだったりします。
検証環境で80番ポートを開けていても本番では443ポートだけにするなど平文通信を受け付けないようにしましょう。
パスパラメータ、クエリパラメータ値に機微情報を入れない
クレジットカード番号やマイナンバーなんかは論外なので見かけませんが、ユーザID、電話番号、アクセスキーなどが入っていることがまま見かけます。
ヒストリーやリファラ、クリップボードからなどで情報が漏洩します。
リクエストボディもしくはヘッダーで送りましょう。
CORSの設定不備
CORSは以前の記事で紹介した通り、異なるオリジンのサーバーにある選択されたリソースへのアクセスを許可することができる仕組みのことです。
意図しないリクエスト元から情報取得される可能性があります。以下の①かつ②の場合では認証後のコンテンツが盗まれる可能性があります。
①Access-Control-Allow-Origin:*
②Access-Control-Allow-Credentials: true
AWSのS3やCognitoではAccess-Control-Allow-Originが何もしないと*になるなど注意が必要です。
広く一般に公開するAPIではOriginのホワイトリスト化は困難と想定されますので、やはりクッキーだけの制御だけでなくヘッダーやボディパラメータのシグニチャやトークンの実装が必要となります。
Webhookの独自のセキュリティ観点
開発者の方でればGithubのwebhooksなどでcommit情報などを知っている方も少なくないでしょう。
リバースAPI意外にもその特性から、HTTPプッシュAPIやWebコールバックなどと呼ばれることがあります。
一方的に突っ込んで更新するWebhookではIP制限は無意味です。
攻撃者はレスポンスは受け取る必要がないので、IPを偽装して送りつければ良いのです。
リダイレクトループ対策
受け手側のエラーが302リダイレクトする場合などを想定していない場合、無数に再送ループが発生し負荷がかかり最悪サービスが止まります。
ブルートフォース対策でも利用されるExponential Backoffなど
pythonならretryで簡単に実装できます。
Step1 pipでretryをインストールする
$pip install retry
Step2 retryモジュールを読み込む
from retry import retry
Step3 exponential Backoffを実装したい関数の前に@retry()を設置する
sleep timeを「1, 2, 4, 8」としたい場合
@retry((ValueError, delay=1, backoff=2)
sleep timeを「1, 2, 3, 4」としたい場合
@retry(ValueError, delay=1, jitter=1)
APIの独自のセキュリティ観点
REST APIが流行っていることやスマートフォン・ファーストの開発が台頭することでAPIの開発が増えており、セキュリティの問題も露見しています。
APIエンドポイントアクセスコントロール
APIエンドポイントアクセスコントロールの観点とは、
まず前提としてセッション(Cookie)、JWT、OAuthなどのアクセスコントロールします。
そして、重要処理に関するAPIの実行にアクセストークン等の一意性の保証する実装がある上で
他人のアクセストークンを利用できるなど認可制御の問題がある確認する観点です。
安全でないAPI Key
独自実装の際に多いですがAPIキーそのものが推測可能、UNIXTIMEをハッシュしただけなどといった場合簡単に偽装されて悪用されます。多くの人が利用しているフレームワークやライブラリから生成するのが基本ですが、独自生成する場合は第三者が知り得ないサーバサイドで生成した値を利用するようにしてください。
特定のHTTPメソッドを利用したVBAACの回避
VBACC(Verb Based Authentication and Authrization Control)とは動詞ベースの認証及び認証管理です。
みなさんはPOST、PUT 、DELETE、PATCHメソッドというHTTPメソッドをご存知かと思いますが、
要するに想定していないメソッドがそのAPIで実行できてしまわないかという観点です。
データの更新が伴うPOST、PUT 、DELETE、PATCHメソッドが実行できてしまえば攻撃者に狙われた際のリスクは高いと想定されます。
以上です。参考になれば幸いです。