不要なウェブ Method 診断の際、発生する問題及び対応方法

概要

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を通じて、動作有無を確認後、応答値を介して攻撃成功有無を判断することができる。

Method 要求 — 【▲ 許可されたMethod要請時のステータスコード(上 : 200 OK / 下 : 403 Forbidden)】

PUT, DELETE Methodの機能が成功に行われた場合、要請成功を意味するステータスコード200で応答し、この場合、脆弱性があると判断する。ステータスコードが403の場合、攻撃に失敗したため、脆弱性はないと判断できる。しかし実際に攻撃を行ってもOPTIONS Methodの結果と応答結果が違う場合がある。

今回は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などに対して検知及び遮断機能が含まれている。

不要なウェブ Method 許可有無テスト

前の二つの仮定をテストするために下記の図のように環境を構成し、システムごとにPUTとDelete MethodをDENYもしくはALLOWで設定し、OPTIONS Methodの応答と動作結果が一致しない場合に対してテストを行ってみた。

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の応答が動作結果と一致しないと予測した。

Method許可テストCASE1 — 【▲ CASE 1環境構成(フレームワークとウェブサーバの有効化)】

区分	WAF	FRAME WORK	WEB SERVER
CASE 1「REST API適用」	–	DENY	ALLOW

【▲ CASE 1のDELETE Method DENY/ALLOW有無】

CASE 1に関する設定ファイルの内容は下記になる。

Method許可テストCASE1(ログ) — 【▲ 設定ファイル内容(左：フレームワーク(FLASK) – DENY DELETE / 右：ウェブサーバ(Apache) – ALLOW DELETE】

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

Method許可テストCASE2構成 — 【▲ CASE 2環境構成(フレームワークとウェブサーバの有効化)】

区分	WAF	FRAME WORK	WEB SERVER
CASE 2「REST API適用」	–	ALLOW	DENY

【▲ CASE 2のDELETE Method DENY/ALLOW有無】

CASE 2に関する設定ファイルの内容は下記になる。

Method許可テストCASE2（ログ） — 【▲ 設定ファイル内容(左：フレームワーク(FLASK) – ALLOW DELETE / 右：ウェブサーバ(Apache) – DENY DELETE】

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の応答が動作結果と一致しないと予測した。

Method許可テストCASE3構成 — 【▲ CASE 3環境構成(WAFとフレームワークの有効化)】

区分	WAF	FRAME WORK	WEB SERVER
CASE 3「WAF内に遮断ポリシー」	DENY	ALLOW	–

【▲ CASE 3のMethod設定値】

Method許可テストCASE3ログ — 【▲ 設定ファイル内容(左：WAF – DENY DELETE / 右：フレームワーク(FLASK) – ALLOW DELETE 】

CASE 3のWAFポリシーとフレームワークの設定内容は下記になる。

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の応答が動作結果と一致しないと予測した。

Method 許可テストCASE4構成 — 【▲ CASE 4環境構成(WAFとフレームワークの有効化)】

区分	WAF	FRAME WORK	WEB SERVER
CASE 4「WAF内に遮断ポリシー」	DENY	–	ALLOW

【▲ CASE 4のMethod設定値】

Method 許可テストCASE4ログ — 【▲ 設定ファイル内容(左：WAF – DENY DELETE / 右：ウェブサーバ – ALLOW DELETE 】

CASE 4のWAFポリシーとウェブサーバの設定内容は下記になる。

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」を応答する。

このように応答の違いはインフラ及びネットワークの構成上に適用されているセキュリティ機器とそのインフラを構成しているシステムに違うセキュリティポリシーが適用されているため発生しており、これを通じいて攻撃者がネットワーク構成などの情報収集することができるので問題になる。

Method 相関関係図 — 【▲ OPTIONS Methodの応答と実際DELETE Method動作結果間の相関関係構成図】

対応方法

一致されたセキュリティポリシー反映

インフラ及びネットワークの構成上に適用されているセキュリティ機器とそのインフラを構成しているシステムに対して一致されたセキュリティポリシーを適用するべきである。セキュリティポリシーが一致されていない場合、攻撃者はネットワークの構成などの情報を収集することができるため、問題になる。一致されたセキュリティポリシーを反映することで攻撃の危険を減らし、各システムごとの統制力が改善できる。

区分	WAF	WEB SERVER
一致されたポリシー	DENY	DENY
一致されたポリシー	ALLOW	ALLOW
一致されていないポリシー	ALLOW	DENY
一致されていないポリシー	DENY	ALLOW

【▲ 一致された / 一致されていないポリシー反映の例】

リソースごとのMethod制限

リソースごとに適切な要請Methodを指定し、Methodがリソースに合っていない場合、エラーのステータスコードを応答するべきである。Apacheの場合、httpd.conf設定ファイルの中に\を通じて、サービスの運用上に必要なMethodを記載したり、\を通じて制限するMethodを記載して制限することができる。下記の図の場合は、\を通じて全体のディレクトリにGET, POST Methodを除外したすべてのMethodをアクセス拒否する設定で、ディレクトリパスを変更することでやむを得ずDELETE, PUT Methodの許可が必要な場合、リソースごとに管理できる。

不要 Method 説明 — 【▲ Apacheの不要なウェブMethod制限説明(左 : LimitExceptパラメータ / 右 : Limitパラメータ)】

ユーザー権限検証

REST APIの適用などの利用でDELETE, PUT Methodの遮断ができない場合、ユーザーごとに権限を付与し、権限を持っているユーザーの要請Methodのみ応答するべきである。標準認証方法を利用してユーザーごとに権限を付与し管理することができる。権限を利用して管理する場合、下記のセキュリティ原則を守らなければならない。

セキュリティ原則	説明
最小権限	作業実施に必要な権限のみ持ち、使用しない場合、除去する。
権限分離	作業実施が可能な権限をリソースタイプで分離する。
Fail Safeデフォルト値	システムの全てのリソースに対してのユーザーの基本アクセスレベルは許可が、明示的に付与されていない限り拒否するべきである。
URL情報漏出除去	URLにトークン情報がある場合、ウェブログにロギングされて悪用される可能性があるため、除去する。

【▲ 権限検証時のセキュリティ原則】

まとめ

今回は不要なウェブMethodに対して調べてみた。Methodの場合は意識しないと見逃しやすい設定で、攻撃者はいつでもMethodを利用して悪質な攻撃ができる。この分析レポートを参考にし、適切な対処を行うことを推奨する。

[blogcard url=” https://cyberfortress.jp/contact/ “]

参考資料

[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/

Written by CYBERFORTRESS, INC.