Security/CSP/Test Plan

From MozillaWiki
< Security‎ | CSP
Jump to: navigation, search

Test Plan for CSP

This page will outline things that need to be tested to ensure an implementation of the "CSP" security mechanism works properly. This page is currently Under Construction and is being fleshed out slowly.

Testing Basic Restrictions

Via HTTP header install the most relaxed policy, "allow *,data".

  1. Verify inline script violates policy
  2. Verify external scripts do not break policy
  3. Verify failure of string-to-code conversions

Verify failure of string-to-code conversions

  1. Event listener extraction (string-based callbacks in JS
  2. eval() breaks
  3. setTimeout(string, msec) breaks
  4. setTimeout(identifier, msec) works
  5. setInterval(string, delay) breaks
  6. setInterval(identifier, delay) works
  7. new Function(string) fails
  8. Other forms of function work:
    1. x = function() { ... }
    2. function x() { ... }
  9. javascript: URI scheme is disallowed
  10. data: URI scheme is allowed, even in script tags' src attributes.
  11. MIME-type enforcement for script and JSON is in place

Pre-defined Functions as Event Handlers

Make sure new functions can't be registered as event handlers (but ones pre-defined before load can). In essence, can register new event handlers through Javascript but not HTML.

  1. foo.onclick = bar; OK
  2. foo.onclick = "bar"; FAIL
  3. foo.addEventListener(bar); OK
  4. foo.addEventListener("bar"); FAIL

XBL restrictions

  1. Works through chrome: and resource: schemes
  2. Fails through other schemes (like http:)

Restrictive Policy Testing

Test for false negatives using policy "allow none". Brute force one or two URIs for each directive, including an XHR test to verify the "allow" directive.

Relaxed Policy Testing

Test for false positives using policy "allow none". Brute force one or two URIs for each directive, including an XHR test to verify the "allow" directive. Ensure that data: URIs fail.

Host item/source Testing

(Test parsing of various complex sources, parsing and policy-based use)

Use policy "allow self,https://foo.com:443" and verify:

  1. wrong port breaks in all directives
  2. wrong scheme breaks in all directives
  3. wrong host breaks in all directives
  4. right source works in all directives

Also verify breakage with XMLHttpRequest (source, port, scheme, all)

Battery of Randomized Complex Policies

Improvise.

Policy Intersection Testing

  1. Attempt to use META tag to loosen policy, verify failure
  2. Attempt to use META tag to tighten policy, verify success
  3. Verify no change when intersecting identical policies

Policy URI

  1. Policy-URI mixed with other directives: verify failure (fail closed)
  2. Policy-URI alone in HTTP header, policy in META: verify that the policy is fetched
  3. Policy-URI alone in META tag, policy in HTTP header: verify fetched policy
  4. Policy URI alone in only META tag: verify fetched policy
  5. Policy URI alone in only HTTP header: verify fetched policy
  6. Policy URI different in META and HTTP: verify both are fetched and intersected
  7. Policy URI identical in META and HTTP: verify only one is fetched