Closed13

ZAP の CacheableScanRule が具体的に何をしているか見ていく

snakasnaka

冒頭のコメントの訳

長くて分かりづらい...

Detect "storable" and "cacheable" responses. "Storable" implies that the response can be stored in some manner by the caching server, even if it is not served in response to any requests.
"Cacheable" responses are responses that are served by the caching server in response to some request.

storable "および "cacheable "応答を検出する。"storable "は、その応答がリクエストに応答して提供されなくても、キャッ シングサーバーが何らかの方法で保存できることを意味する。
"キャッシュ可能 "な応答は、何らかのリクエストに応答してキャッシュサーバによって提供される応答である。

Unlike "CacheControlScanner", this rule does not attempt to determine if the various cache settings are "incorrectly" set (since that depends on the response contents, and on the context), but instead, looks at the conditions defined in rfc7234 to determine if a given request and response are storable by rfc7234 compliant cache servers, and subsequently retrievable from the cache (ie, "cacheable"):

CacheControlScanner」とは異なり、このルールは、さまざまなキャッシュ設定が 「正しく」設定されているかどうかを決定しようとはしない(なぜなら、それは 応答の内容とコンテキストに依存するからである)。そのかわりに、rfc7234で 定義されている条件を見て、与えられたリクエストと応答が、rfc7234に 準拠したキャッシュサーバーによって保存可能であり、その後キャッシュから 取得可能であるかどうかを決定する(すなわち、「キャッシュ可能」である):

A cache MUST NOT store a response to any request, unless:

  • The request method is understood by the cache and defined as being cacheable, and o the response status code is understood by the
    cache, and
  • the "no-store" cache directive (see Section 5.2) does not appear in request or response header fields, and
  • the "private" response directive (see Section 5.2.2.6) does not appear in the response, if the cache is shared, and
  • the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see Section 3.2), and
  • the response either:
    • contains an Expires header field (see Section 5.3), or
    • contains a max-age response directive (see Section 5.2.2.8), or
    • contains a s-maxage response directive (see Section 5.2.2.9) and the cache is shared, or
    • contains a Cache Control Extension (see Section 5.2.3) that allows it to be cached, or
    • has a status code that is defined as cacheable by default (see Section 4.2.2), or
    • contains a public response directive (see Section 5.2.2.5).

Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.

キャッシュは、以下の条件が満たされない限り、どんなリクエストに対するレスポンスも保存してはならない。

  • リクエストメソッドがキャッシュによって理解され、キャッシュ可能と定義されていること、およびレスポンスのステータスコードがキャッシュによって理解されていること。
  • リクエストまたはレスポンスのヘッダーフィールドに「no-store」キャッシュディレクティブ(セクション5.2を参照)が含まれていないこと。
  • キャッシュが共有されている場合、レスポンスに「private」レスポンスディレクティブ(セクション5.2.2.6を参照)が含まれていないこと。
  • キャッシュが共有されている場合、リクエストにAuthorizationヘッダーフィールド([RFC7235]のセクション4.2を参照)が含まれていないこと、またはレスポンスが明示的に許可している場合(セクション3.2を参照)。
  • レスポンスが以下のいずれかを含んでいること。
    • Expiresヘッダーフィールドを含む(セクション5.3を参照)。
    • max-ageレスポンスディレクティブを含む(セクション5.2.2.8を参照)。
    • s-maxageレスポンスディレクティブを含み、かつキャッシュが共有されている場合(セクション5.2.2.9を参照)。
    • キャッシュ可能とするキャッシュコントロール拡張を含む(セクション5.2.3を参照)。
    • デフォルトでキャッシュ可能と定義されているステータスコードを持つ(セクション4.2.2を参照)。
    • publicレスポンスディレクティブを含む(セクション5.2.2.5を参照)。
      なお、上記の要件はいずれも、キャッシュコントロール拡張によって上書きされる可能性があります(セクション5.2.3を参照)。
snakasnaka

does the "no-store" cache directive appear in request or response header fields?

  • 前述の条件に該当しない、かつ、以下のいずれかに no-store が含まれている場合、alert を出す
    • pragma ヘッダー ( Request / Response )
    • Cache-Control ヘッダー ( Request / Response )
  • Evidence ヘッダーの directive
    • ex. no-store

https://github.com/zaproxy/zap-extensions/blob/bc014a042ce48619e4d1c1a8c8c0abced4ce41f6/addOns/pscanrulesBeta/src/main/java/org/zaproxy/zap/extension/pscanrulesBeta/CacheableScanRule.java#L134-L159

snakasnaka

does the Authorization header field appear in the request, if the cache is shared (which we assume it is for now) if so, does the response explicitly allow it to be cached?

  • ケース1: 以下に該当する場合、alert を出す

    • 前述の条件に該当しない
    • リクエストに Authorization ヘッダーが存在する
    • レスポンスに Cache-Control ヘッダーが存在する
      • それに以下のいずれかの directive が含まれていない
        • must-revalidate
        • public
        • s-maxage
  • ケース2:以下に該当する場合、alert を出す

    • 前述の条件に該当しない
    • リクエストに Authorization ヘッダーが存在する
    • レスポンスに Cache-Control ヘッダーが存在しない
  • Evidence は authrization: (固定値)

https://github.com/zaproxy/zap-extensions/blob/bc014a042ce48619e4d1c1a8c8c0abced4ce41f6/addOns/pscanrulesBeta/src/main/java/org/zaproxy/zap/extension/pscanrulesBeta/CacheableScanRule.java#L184-L235

snakasnaka

指摘の意図

リクエストに Authorization ヘッダーが含まれる、なんらかの認可されたリクエストに対するレスポンスの Cache-Control ヘッダーに no-storeprivate が含まれていない。

つまり、キャッシュサーバとしてはキャッシュ可能なレスポンスであるが、アプリケーション側から明示的なキャッシュの扱い方が示されていない。

アプリケーションはキャッシュされることを意図していない可能性があるため、それをアラートとして上げている。

snakasnaka

in addition to the checks above, just one of the following needs to be true for the response to be storable

  • 以下のすべてを満たす場合、alert を上げる
    • 前述の条件に該当しない
    • レスポンスに Expires ヘッダーが存在しない
    • レスポンスに Cache-Control ヘッダーに以下が存在しない
      • max-age
      • s-maxage
      • public
    • レスポンスの Status Code が Cacheable [1] ではない
  • Evidence は Status Code
    • ex. 302

https://github.com/zaproxy/zap-extensions/blob/bc014a042ce48619e4d1c1a8c8c0abced4ce41f6/addOns/pscanrulesBeta/src/main/java/org/zaproxy/zap/extension/pscanrulesBeta/CacheableScanRule.java#L237-L332

脚注
  1. 次の Status Code は Cacheable : 200、203、204、206、300、301、404、405、410、414、501 ↩︎

snakasnaka

check if the stored response does not contain the no-cache cache directive, unless it is successfully validated

  • 前述の条件に該当しない、かつ、 レスポンスの Cache-Control ヘッダーに no-cache が含まれる場合、alert を上げる
  • Evidence は no-cache

https://github.com/zaproxy/zap-extensions/blob/bc014a042ce48619e4d1c1a8c8c0abced4ce41f6/addOns/pscanrulesBeta/src/main/java/org/zaproxy/zap/extension/pscanrulesBeta/CacheableScanRule.java#L334-L358

このスクラップは4ヶ月前にクローズされました