#概要
HTTP(Hypertext Transfer Protocol)はウェブクライアントがウェブサーバにデータを要求するためにMethodという手段を利用する。Methodは要求内容によって、GET, POST, HEAD, PUT, DELETE, OPTIONSなどで分類され、それぞれに定義された行為を行う。PUT, DELETE Methodの場合、サーバ内のファイルを作成及び削除することが可能である。認可されていないユーザーにより、操られる可能性があるため、事前予防の観点で脆弱性の存在有無を診断し、対応が必要である。
| Method | 説明 |
|---|---|
| GET | GETはサーバに指定したURIに位置する情報を要請 |
| HEAD | ヘッダー情報をサーバに要求する方法。機能はGETと一緒だが、サーバは応答データのところになにも記述しない。 |
| POST | データをメッセージボディーに含んで入出力ストリームを通じて処理する方法で、GET Methodとは違って、データサイズの制限がない。 |
| PUT | メッセージに含まれているデータを指定したRequest-URI名で保存。 |
| DELETE | Request－URIに指定されているリソースをサーバから削除 |
| 【▲ HTTP Methodの説明】 |
PUT, DELETE Methodの動作有無を確認するために下記の図のようにOPTIONS Methodを通じて、動作有無を確認後、応答値を介して攻撃成功有無を判断することができる。
【▲ OPTIONS Methodの応答】
PUT, DELETE Methodの機能が成功に行われた場合、要請成功を意味するステータスコード200で応答し、この場合、脆弱性があると判断する。ステータスコードが403の場合、攻撃に失敗したため、脆弱性はないと判断できる。しかし実際に攻撃を行ってもOPTIONS Methodの結果と応答結果が違う場合がある。
【▲ 許可されたMethod要請時のステータスコード(上 : 200 OK / 下 : 403 Forbidden)】
今回はOPTIONS Methodの結果と実際攻撃結果が違う原因と結果について詳細に分析してみよう。
#事前情報
OPTIONS Methodの応答結果によって、攻撃結果が及ぼす影響について二つの仮定を設定し、各項目ごとに分類しててテストを行った。本格的なテストの前にテストの条件について使用されるREST APIとWAFについて簡単に確認してみよう。
# 仮定 1 : ウェブサーバにREST APIを提供した場合
# 仮定 2 : セキュリティ機器(WAF)が特定のMethod要請を遮断した場合
##1) REST(REpresentational State Transfer) API
RESTはウェブのメリットを最大に活用できるアーキテクチャスタイルで、サーバとクライアント間の通信方法の一つである。ウェブサイトのテキスト、イメージなど、すべてのリソースに対して固有のURIを付与し、HTTP Methodを通じて当該リソースに対して、作成、照会、修正、削除動作を行うなど制約条件の集合である。RESTfulはこの制約条件(アーキテクチャスタイル、アーキテクチャ原則)を全て満足することを意味する。
| URI | REST規則満足有無 |
|---|---|
| GET /members/delete/1 | ✕ |
| DELETE /members/1 | 〇 |
| 【▲ REST API規則例】 |
例えば、要請URIにdeleteのような行為の表現(単語)がURIに入っているとREST規則に満足しないため、機能の要請はURIではなく、 Methodを利用して要請されるべきである。
##2) WAF(Web Application Firewall)
WAFはウェブ攻撃に特化されたソリューションでウェブサービス（OSI 7 LayerのApplication層HTTP(80)）に試す脆弱性攻撃を検知及び遮断する動作をする。SQL Injection, XSS, 要請Methodなどに対して検知及び遮断機能が含まれている。
【▲ WAFの構成アーキテクチャ】
#不要なウェブMethod許可有無テスト
前の二つの仮定をテストするために下記の図のように環境を構成し、システムごとにPUTとDelete MethodをDENYもしくはALLOWで設定し、OPTIONS Methodの応答と動作結果が一致しない場合に対してテストを行ってみた。
【▲ 不要なウェブMethod許可有無のテスト環境構成図】
| 区分 | WAF | FRAME WORK | WEB SERVER |
|---|---|---|---|
| CASE 1「REST API適用」 | - | DENY | ALLOW |
| CASE 2「REST API適用」 | - | ALLOW | DENY |
| CASE 3「WAF内に遮断ポリシー」 | DENY | ALLOW | - |
| CASE 4「WAF内に遮断ポリシー」 | DENY | - | ALLOW |
| 【▲ ケースごとのDELETE Method DENY/ALLOW有無】 |
##1) CASE 1
フレームワークとウェブサーバの設定の違いがある場合、OPTIONS Methodの応答が動作結果と一致しないと予測した。
【▲ CASE 1環境構成(フレームワークとウェブサーバの有効化)】
| 区分 | WAF | FRAME WORK | WEB SERVER |
|---|---|---|---|
| CASE 1「REST API適用」 | - | DENY | ALLOW |
| 【▲ CASE 1のDELETE Method DENY/ALLOW有無】 |
CASE 1に関する設定ファイルの内容は下記になる。
【▲ 設定ファイル内容(左：フレームワーク(FLASK) - DENY DELETE / 右：ウェブサーバ(Apache) - ALLOW DELETE】
【▲ CASE 1プロセス】
Step 1. OPTIONS要請を通じてウェブサーバから許可されているMethod値確認
(Allow : HEAD, GET, OPTIONS, PUT → DELETE Method 無し = 制限)
Step 2. サーバ側から制限されたMethodのDELETE要請試し
Step 3. ステータスコード405受信(DELETE Method攻撃不可)
▶ OPTIONS Methodの応答、動作結果一致
##2) CASE 2
【▲ CASE 2環境構成(フレームワークとウェブサーバの有効化)】
| 区分 | WAF | FRAME WORK | WEB SERVER |
|---|---|---|---|
| CASE 2「REST API適用」 | - | ALLOW | DENY |
| 【▲ CASE 2のDELETE Method DENY/ALLOW有無】 |
CASE 2に関する設定ファイルの内容は下記になる。
【▲ 設定ファイル内容(左：フレームワーク(FLASK) - ALLOW DELETE / 右：ウェブサーバ(Apache) - DENY DELETE】
【▲ CASE 2プロセス】
Step 1. OPTIONS要請を通じてウェブサーバから許可されているMethod値確認
(Allow : PUT, HEAD, DELETE, OPTIONS, GET → DELETE Method 有り = 許可)
Step 2. サーバ側から制限されたMethodのDELETE要請試し
Step 3. ステータスコード200受信(DELETE Method攻撃可能)
▶ OPTIONS Methodの応答、動作結果一致
##3) CASE 3
WAF内に特定のMethodに対して遮断ポリシーが存在する場合、WAF内から特定の要請に対して遮断し、当該の要請がフレームワークまで到達しないのでOPTIONS Methodの応答が動作結果と一致しないと予測した。
【▲ CASE 3環境構成(WAFとフレームワークの有効化)】
| 区分 | WAF | FRAME WORK | WEB SERVER |
|---|---|---|---|
| CASE 3「WAF内に遮断ポリシー」 | DENY | ALLOW | - |
| 【▲ CASE 3のMethod設定値】 |
CASE 3のWAFポリシーとフレームワークの設定内容は下記になる。
【▲ 設定ファイル内容(左：WAF - DENY DELETE / 右：フレームワーク(FLASK) - ALLOW DELETE 】
【▲ CASE 3プロセス】
Step 1. OPTIONS要請を通じてウェブサーバから許可されているMethod値確認
(Allow : PUT, HEAD, DELETE, OPTIONS, GET → DELETE Method 有り = 許可)
Step 2. サーバ側から制限されたMethodのDELETE要請試し
Step 3. ステータスコード403受信(DELETE Method攻撃不可)
▶ OPTIONS Methodの応答、動作結果不一致
OPTIONS Methodの応答内にDELETE Methodが存在しているとサーバ側から当該MethodをALLOWしていることを確認し、DELETE要請を送信したが、ステータスコードは「200 OK」ではなく、「403 Forbidden」を受信し、OPTIONS Methodの応答と動作結果が一致しないことを確認した。
##4) CASE 4
CASE 3と同じく、WAF内に特定のMethodに対して遮断ポリシーが存在する場合、WAF内から特定の要請に対して遮断し、当該の要請がフレームワークまで到達しないのでOPTIONS Methodの応答が動作結果と一致しないと予測した。
【▲ CASE 4環境構成(WAFとフレームワークの有効化)】
| 区分 | WAF | FRAME WORK | WEB SERVER |
|---|---|---|---|
| CASE 4「WAF内に遮断ポリシー」 | DENY | - | ALLOW |
| 【▲ CASE 4のMethod設定値】 |
CASE 4のWAFポリシーとウェブサーバの設定内容は下記になる。
【▲ 設定ファイル内容(左：WAF - DENY DELETE / 右：ウェブサーバ - ALLOW DELETE 】
【▲ CASE 4プロセス】
Step 1. OPTIONS要請を通じてウェブサーバから許可されているMethod値確認
(Allow : PUT, HEAD, DELETE, OPTIONS, GET → DELETE Method 有り = 許可)
Step 2. サーバ側から制限されたMethodのDELETE要請試し
Step 3. ステータスコード403受信(DELETE Method攻撃不可)
▶ OPTIONS Methodの応答、動作結果不一致
CASE 3と同じく、OPTIONS Methodの応答内にDELETE Methodが存在しているとサーバ側から当該MethodをALLOWしていることを確認し、DELETE要請を送信したが、ステータスコードは「200 OK」ではなく、「403 Forbidden」を受信し、OPTIONS Methodの応答と動作結果が一致しないことを確認した。
#結論
OPTIONS Methodの応答と動作結果の一致有無テストを行った結果は下記の表になる。
CASE 1,2の場合、OPTIONS Methodの応答と動作結果が一致したが、インフラを構成するシステムに特定のMethodを制限するポリシーを持っているWAFの場合、結果が一致していなかった。
| 区分 | WAF | FRAME WORK | WEB SERVER | 結果一致有無 | 攻撃可能有無 |
|---|---|---|---|---|---|
| CASE 1「REST API適用」 | - | DENY | ALLOW | 〇 | ✕ |
| CASE 2「REST API適用」 | - | ALLOW | DENY | 〇 | 〇 |
| CASE 3「WAF内に遮断ポリシー」 | DENY | ALLOW | - | ✕ | ✕ |
| CASE 4「WAF内に遮断ポリシー」 | DENY | - | ALLOW | ✕ | ✕ |
| 【▲ 不要なウェブMethodの許可有無テスト結果】 |
WAFはOPTIONS Methodの要請に対してALLOWされていてウェブサーバへOPTION要請を送信することになる。ウェブサーバ設定はDELETEとOPTIONSの要請に対して全てALLOWになっているため、「200 OK」と共に応答ヘッダー項目の中にALLOWになっているMethodを含んで応答する。しかし、WAFにDELETE Methodの要請に対してDENYになっている場合、DELETEの要請に対して「403 Forbidden」を応答する。
このように応答の違いはインフラ及びネットワークの構成上に適用されているセキュリティ機器とそのインフラを構成しているシステムに違うセキュリティポリシーが適用されているため発生しており、これを通じいて攻撃者がネットワーク構成などの情報収集することができるので問題になる。
【▲ OPTIONS Methodの応答と実際DELETE Method動作結果間の相関関係構成図】
#対応方法
##一致されたセキュリティポリシー反映
インフラ及びネットワークの構成上に適用されているセキュリティ機器とそのインフラを構成しているシステムに対して一致されたセキュリティポリシーを適用するべきである。セキュリティポリシーが一致されていない場合、攻撃者はネットワークの構成などの情報を収集することができるため、問題になる。一致されたセキュリティポリシーを反映することで攻撃の危険を減らし、各システムごとの統制力が改善できる。
| 区分 | WAF | WEB SERVER |
|---|---|---|
| 一致されたポリシー | DENY | DENY |
| 一致されたポリシー | ALLOW | ALLOW |
| 一致されていないポリシー | ALLOW | DENY |
| 一致されていないポリシー | DENY | ALLOW |
| 【▲ 一致された / 一致されていないポリシー反映の例】 |
##リソースごとのMethod制限
リソースごとに適切な要請Methodを指定し、Methodがリソースに合っていない場合、エラーのステータスコードを応答するべきである。Apacheの場合、httpd.conf設定ファイルの中に<LimiteExcept>を通じて、サービスの運用上に必要なMethodを記載したり、<Limit>を通じて制限するMethodを記載して制限することができる。下記の図の場合は、<Directory />を通じて全体のディレクトリにGET, POST Methodを除外したすべてのMethodをアクセス拒否する設定で、ディレクトリパスを変更することでやむを得ずDELETE, PUT Methodの許可が必要な場合、リソースごとに管理できる。
【▲ Apacheの不要なウェブMethod制限説明(左 : LimitExceptパラメータ / 右 : Limitパラメータ)】
##ユーザー権限検証
REST APIの適用などの利用でDELETE, PUT Methodの遮断ができない場合、ユーザーごとに権限を付与し、権限を持っているユーザーの要請Methodのみ応答するべきである。標準認証方法を利用してユーザーごとに権限を付与し管理することができる。権限を利用して管理する場合、下記のセキュリティ原則を守らなければならない。
| セキュリティ原則 | 説明 |
|---|---|
| 最小権限 | 作業実施に必要な権限のみ持ち、使用しない場合、除去する。 |
| 権限分離 | 作業実施が可能な権限をリソースタイプで分離する。 |
| Fail Safeデフォルト値 | システムの全てのリソースに対してのユーザーの基本アクセスレベルは許可が、明示的に付与されていない限り拒否するべきである。 |
| URL情報漏出除去 | URLにトークン情報がある場合、ウェブログにロギングされて悪用される可能性があるため、除去する。 |
| 【▲ 権限検証時のセキュリティ原則】 |
#まとめ
今回は不要なウェブMethodに対して調べてみた。Methodの場合は意識しないと見逃しやすい設定で、攻撃者はいつでもMethodを利用して悪質な攻撃ができる。この分析レポートを参考にし、適切な対処を行うことを推奨する。
#参考資料
[1] REST APIソース(python)
-
https://github.com/kiteco/kite-python-blog-post-code/tree/master/flask-tutorial/restful-apis-with-flask
[2] REST API概念説明 - https://meetup.toast.com/posts/92
-
https://jeong-pro.tistory.com/180
[3] WAF(Web Application Firewall)とは? -
https://ipwithease.com/introduction-to-waf-web-application-firewall/
[4] HTTP Request Method説明 -
https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
[5] APIセキュリティチェック - https://github.com/shieldfy/API-Security-Checklist/blob/master/README-ko.md
- https://restfulapi.net/security-essentials/