Update CORB documentation links

OWASP documentation has seemed to move to
https://cheatsheetseries.owasp.org. The source can be found on
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/, but
all of the old material that our CORB documentation links to is now
hosted on their new site.

R=yhirano@chromium.org

Change-Id: I7c171f709816d69615ff82c10b8bb8fc9c51e08a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2134569
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#755925}

services/network/cross_origin_read_blocking_explainer.md

@@ -52,11 +52,11 @@ CORB mitigates the following attack vectors:
   * CORB prevents this class of attacks, because a CORB-protected resource will
     be blocked from ever being delivered to a cross-site `<script>` element.
   * CORB is particularly valuable in absence of other XSSI defenses like
-    [XSRF tokens](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Synchronizer_.28CSRF.29_Tokens)
+    [XSRF tokens](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern)
     and/or
-    [JSON security prefixes](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers).
+    [JSON security prefixes](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection).
     Additionally, the presence of XSSI defenses like
-    [JSON security prefixes](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+    [JSON security prefixes](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
     can also be used as a signal to the CORB algorithm that a resource should be
     CORB-protected.
 
@@ -196,7 +196,7 @@ CORB handles the following cases for JSON:
       certain number of bytes. This would avoid buffering and parsing
       in an unbounded amount of memory.
  * JSON served with
-   [an XSSI-defeating prefix](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers):
+   [an XSSI-defeating prefix](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection):
    As a mitigation for past browser
    vulnerabilities, many actual websites and frameworks employ a convention of
    prefixing their fetchable resources with a string designed to force a
@@ -217,17 +217,17 @@ CORB handles the following cases for JSON:
    strong signal to the CORB algorithm that a resource should be CORB-protected.
    As such, these prefixes should trigger CORB protection in almost every case,
    no matter what follows them. This is argued to be safe because:
-     * [A JSON security prefix](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+     * [A JSON security prefix](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
        would cause a syntax error (or a hang) if present in a document served
        with a JavaScript MIME type such as `text/javascript`.
-     * [JSON security prefixes](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+     * [JSON security prefixes](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
        are not known to collide with binary
        resources like images, videos or fonts (which typically require
        the first few bytes to be hardcoded to a specific sequence - for example
        `FF D8 FF` for image/jpeg).
      * Collisions with `text/css` stylesheets are theoretically possible, because
        it is possible to construct a file that begins with
-       [a JSON security prefix](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers),
+       [a JSON security prefix](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection),
        but at the same parses fine as a stylesheet.
        `text/css` is therefore established as an exception, even though the
        practical likelihood of such a scenario seems low.
@@ -328,7 +328,7 @@ HTML or XML resource) based on the following:
     that sniffs as JSON is CORB-protected
   * `text/plain` that sniffs as JSON, HTML or XML is CORB-protected
   * Any response (except `text/css`) that begins with
-    [a JSON security prefix](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+    [a JSON security prefix](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
     is CORB-protected
 
 The sniffing is necessary to avoid blocking existing web pages that depend on
@@ -553,12 +553,12 @@ Examples:
 * **Correctly-labeled stylesheet with a JSON security prefix**
   * Resource used in a `<link rel="stylesheet" href="...">` tag:
     * Body: a stylesheet that begins with
-      [a JSON security prefix](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+      [a JSON security prefix](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
     * `Content-Type: text/css`
     * No `X-Content-Type-Options` header
   * Expected behavior: **no difference**,
     because CORB sniffing for
-    [JSON security prefixes](https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Protect_against_JSON_Hijacking_for_Older_Browsers)
+    [JSON security prefixes](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection)
     is not performed for responses labeled as `Content-Type: text/css`.
   * WPT test: `fetch/corb/style-css-with-json-parser-breaker.sub.html`