|
35 | 35 | browsers: ["chrome", "firefox", "safari", "edge", "and_chr", "and_ff", "ios_saf"],
|
36 | 36 | },
|
37 | 37 | xref: "web-platform",
|
| 38 | + // The Wylecial breaks the link checker with bad HTTP code response, so disabling this for now. |
| 39 | + // localBiblio: { |
| 40 | + // "Wylecial": { |
| 41 | + // "date": "2020-08-25", |
| 42 | + // "title": "Stealing local files using Safari Web Share API", |
| 43 | + // "Author": "Pawel Wylecial", |
| 44 | + // "href": "https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html" |
| 45 | + // } |
| 46 | + // } |
38 | 47 | };
|
39 | 48 | </script>
|
40 | 49 | </head>
|
|
176 | 185 | <li>If |url| is failure, return <a>a promise rejected with</a>
|
177 | 186 | {{TypeError}}.
|
178 | 187 | </li>
|
| 188 | + <li>If |url|'s [=URL/scheme=] is not "http" or "https", return |
| 189 | + <a>a promise rejected with</a> {{TypeError}}. |
| 190 | + </li> |
179 | 191 | <li>Set |data| to a copy of |data|, with its {{ShareData/url}}
|
180 | 192 | member set to the result of running the <a>URL serializer</a>
|
181 | 193 | on |url|.
|
@@ -464,6 +476,45 @@ <h2>
|
464 | 476 | guard against this, but implementors will want to be aware that it is a
|
465 | 477 | possibility.
|
466 | 478 | </li>
|
| 479 | + <li> |
| 480 | + <p> |
| 481 | + Share targets that dereference a shared URL and forward that |
| 482 | + information on might inadvertently forward information that might |
| 483 | + be otherwise confidential. This can lead to unexpected information |
| 484 | + leakage if shares reference content that is only accessible by that |
| 485 | + application, the host on which it runs, or its network location. |
| 486 | + </p> |
| 487 | + <p> |
| 488 | + Malicious sites might exploit share targets that leak information |
| 489 | + by providing URLs that ultimately resolve to local resources, |
| 490 | + including, but not limited to, "file:" URLs or local services that |
| 491 | + might otherwise be inaccessible. Even though this API limits shared |
| 492 | + URLS to "http:" and "https:", use of redirects to other URLs or |
| 493 | + tweaks to DNS records for hosts in those URLs might be used to |
| 494 | + cause applications to acquire content. |
| 495 | + </p> |
| 496 | + <p> |
| 497 | + To avoid being used in these attacks, share targets can consume the |
| 498 | + URL, retrieve the content, and process that information without |
| 499 | + sharing it. For instance, a photo editing application might |
| 500 | + retrieve an image that is "shared" with it. A share target can also |
| 501 | + share the URL without fetching any of the referenced content. |
| 502 | + </p> |
| 503 | + <p> |
| 504 | + Share targets that fetch content for the purposes of offering a |
| 505 | + preview or for sharing content risk information leakage. Content |
| 506 | + that is previewed and authorized by a user might be safe to |
| 507 | + forward, however it is not always possible for a person to identify |
| 508 | + when information should be confidential, so forwarding any content |
| 509 | + presents a risk. In particular, the {{ShareData/title}} might be |
| 510 | + used by an attacker to trick a user into misinterpreting the nature |
| 511 | + of the content. |
| 512 | + <!-- |
| 513 | + , as demonstrated in the [[Wylecial]] <a data-cite= |
| 514 | + "Wylecial#">proof of concept attack</a> |
| 515 | + --> |
| 516 | + </p> |
| 517 | + </li> |
467 | 518 | </ul>
|
468 | 519 | </section>
|
469 | 520 | <section class="appendix informative">
|
|
0 commit comments