開発エンジニアのMASAE.Mです。
前回の記事(vol3)ではレスポンス設計に関する内容を記載しました。
本記事ではWeb APIにおける「セキュリティ設計」について記載します。
WebAPIのセキュリティを考えるにはブラウザの持つセキュリティ機能の理解や、WebAPIを意図しない形で使われないよう、既知の攻撃手法を知っておくことが大切です。
前半はブラウザが持つ同一生成元ポリシーという機能について、後半はよくある攻撃と対策についてご紹介します。
４セキュリティ設計
4.1. 同一生成元ポリシーとクロスオリジンリソースシェアリング
ブラウザのセキュリティ機能に同一生成元ポリシーというものがあります。
この機能は異なる生成元のウェブページが互いのリソースにアクセスすることを防ぎます。
4.1.1同一生成元ポリシーとは
サイトにJavaScriptを埋め込んだ場合、JavaScriptが同一ホスト（ドメイン）のデータにアクセスするのは許可されますが、スキーム(httpなどのプロトコル）やホストが異なっているとアクセスは許可されません。
異なる生成元のリソースを共有するにはクロスオリジンリソースシェアリングの対応が必要です。
4.1.2 クロスオリジンリソースシェアリング（CORS）とは
異なる生成元からのアクセスに対して、特定の生成元だけ許可する仕組みです。
クロスオリジンリソースシェアリングの仕組み：
サーバー側はあらかじめアクセスを許可する生成元一覧を持ちます。
※リソースがどこから読まれてもいいものであればAccess-Contol-Allow-Originに「*」を設定します。
Access-Contol-Allow-Origin: https://www.example.com
クライアントはリクエストの時にOriginというリクエストヘッダに自分のドメインを設定します。
Origin: https://www.example.com
Originの値が、許可する生成元一覧にあればレスポンスを返します。
Access-Contol-Allow-OriginというレスポンスヘッダにOriginと同じ値を入れます。
Access-Contol-Allow-Origin: https://www.example.com
4.2.Web APIへの攻撃パターンとその対策
作成したWeb APIが不正な使われ方をしないためには、セキュリティを考える必要があります。
WebAPIを狙った攻撃は以下の3パターンが考えられます。
1 第三者が攻撃する
2 ユーザが攻撃する
3 プログラムのミスなどで大量リクエストが発生する
4.2.1 第三者が攻撃する例
第三者の攻撃はWebAPIの通信内容を盗聴したり、データ登録でJavaScriptを埋め込まれることが考えられます。
攻撃例①：通信内容の盗聴
HTTPの通信は情報を平文のままやり取りを行います。
そのためツールを使えば他人の通信内容を簡単に見ることができます。
対策：
HTTPSの利用です。
HTTPSの通信は情報を暗号化してやり取りを行います。
そのためツールを使って人の通信を取得しても、暗号化してあるため内容を解読できません。
攻撃例②：XSS（クロスサイトスクリプティング）
XSSとは、ユーザが入力内容にJavaScriptを仕込むことで、データを画面に表示する際に勝手にJavaScriptが実行されるものです。クッキーに含まれるセッション情報を取得し、攻撃者に送るJavaScriptを記載すれば、情報を盗むことができます。
WebAPIの場合、JavaScriptを含む入力データをそのまま保存すると、ブラウザでGETしたときにJSON が画面表示されJavaScriptが実行される危険があります。
対策：
入力に対して適切なチェックを入れます。
保存の際JavaScriptで必要になるスラッシュや<>といった記号をエスケープし、JavaScriptとして成り立たなくさせます。
またレスポンスのJSONがHTMLと解釈されないように、Content-Typeにapplication/jsonを設定する方法もあります。
攻撃例③：XSRF（またはCSRF）
XSRFとはクロスサイトリクエストフォージェリ（Cross Site Request Forgery）の略語です。
悪意のあるサイトにユーザがアクセスし操作をすると、別のサイトにリクエストが行われ、ユーザが意図しない処理が実行される仕組みです。
商品の高評価を送信させランキングを操作したり、掲示板に犯罪予告を書き込ませ、意図せず操作したユーザが誤認逮捕されるといったことがあります。
対策：サーバーの値を変更するアクセスはGETメソッドでは行わず、PUTやPOST、DELETEを使用することです。（攻撃用のコードを埋め込めなくなるため）
フォームに対しては、ワンタイムトークンやセッションごとのトークンを埋め込み、そのトークンがないアクセスは拒否する方法があります。攻撃用のリクエストにはその都度変わるトークンを持たせられないため、攻撃をはじくことができます。
4.2.2 ユーザが攻撃する例
ユーザの中には通信を解析して、例えばショッピングサイトでポイントを不正に入手したり、ランキングを操作したりしようとする人がいます。
攻撃例①：パラメータの改竄
例：ショッピングサイトでポイントを消費する処理のAPIがあり、パラメータの値を所持ポイントから引き算しているとします。この仕組みを利用すると、パラメータにマイナスの値を渡したら、ポイントを増やすことができます。
対策：パラメータの値のチェックや整合性確認の処理を入れることです。
攻撃例②：リクエストの再送信
例：ポイント受け取りのリクエストを2回実行し、2倍のポイントを取得するというものです。
※成功しているリクエストを送るので、パラメータが適切かどうかでは判断できないことがあります。
対策：
状態管理を適切におこないます。
同じユーザから同じアクセスがあったらエラーにするなどチェックを入れることです。
4.2.3 プログラムのミスなどで大量リクエストが発生する
サーバーに負荷をかける目的で大量リクエストを送ってくること（Dos攻撃）もありますが、意図せず大量のリクエストを発生させるプログラムを書いてしまうこともあります。
攻撃例：大量リクエスト
状況：APIは特にプログラムからの呼び出しが多いです。
開発者の技術不足で、無駄にリクエストを送るプログラムを書く可能性があります。
悪意ある人がサーバーダウンさせる目的で大量にリクエストを送る可能性もあります。
対策：
APIの実行数に制限を付けることです。
単位時間当たり何回までと設定しておけば、それを上回るリクエストはエラーで返し、サーバーを守ることができます。
まとめ
今回の記事では、「同一生成元ポリシー」と「よくある攻撃と対策」についてご紹介しました。
4回シリーズでお送りしましたWeb APIの設計ですが、WebAPIについて理解の一助となれましたら幸いです。
上記の記事に関してご質問ございましたら、お問い合わせください。