Issue metadata
Sign in to add a comment
|
XSDB: GetCanonicalMimeType shouldn't require strict equality of the mime type |
||||||||||||||||||||||
Issue description
XSDB protection depends on detecting that a HTTP response carries a document that needs protection. This detection is based on the mime type reported in the HTTP response. This detection might not work, because it is overly strict (requires the actual mime type to be strictly^H^Hcase-insensitively equal to the expected mime type). In particular:
- Some Google APIs appear to use json+protobuf in responses:
Content-Type: application/json+protobuf; charset=UTF-8
- Some random pages [1] on the internet claim that alternate MIME types with suffix +json are being widely used. So far I did find an example of application/stream+json [2] and application/activity+json [3].
[1] https://stackoverflow.com/a/6999397/4692014
[2] https://tools.ietf.org/id/draft-snell-activity-streams-type-01.html
[3] https://www.w3.org/TR/activitystreams-core/#media-type
,
Jan 4 2018
This probably should also apply to mime types suffixed with +xml (and prefixed with xml+ ?).
,
Jan 4 2018
WIP CL @ https://chromium-review.googlesource.com/c/chromium/src/+/850551
,
Jan 8 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/83e1435de92b64c192588c0d6827bf1cae9d64e2 commit 83e1435de92b64c192588c0d6827bf1cae9d64e2 Author: Lukasz Anforowicz <lukasza@chromium.org> Date: Mon Jan 08 17:50:16 2018 GetCanonicalMimeType should recognize application/json+protobuf as JSON. This CL: 1. Adds unit tests for GetCanonicalMimeType (covering mime types recognized before as well as new mime types recognized after the CL). 2. Tweaks GetCanonicalMimeType to 2.1. Recognize "+json" and "+xml" suffix 2.2. Allow canonical json and xml mime types as a prefix (i.e. allow both application/json and application/json+protobuf) 3. Is trying to be careful to keep treating image/svg+xml and application/jsonp as "others". Bug: 799155 Change-Id: I62a25833a4533cbafccd5b5f1987233ea847df25 Reviewed-on: https://chromium-review.googlesource.com/850551 Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Cr-Commit-Position: refs/heads/master@{#527668} [modify] https://crrev.com/83e1435de92b64c192588c0d6827bf1cae9d64e2/content/common/cross_site_document_classifier.cc [modify] https://crrev.com/83e1435de92b64c192588c0d6827bf1cae9d64e2/content/common/cross_site_document_classifier.h [modify] https://crrev.com/83e1435de92b64c192588c0d6827bf1cae9d64e2/content/common/cross_site_document_classifier_unittest.cc
,
Jan 8 2018
,
Jan 8 2018
creis@: we need to make a decision whether to merge the fix to M64. Let me set NextAction to the next Monday - by that time we should have enough date (hopefully including XSDB-UKM) to make that decision (I note that the stable cut date is tentatively planned for Jan 18th).
,
Jan 9 2018
Adding labels to ensure release engineers/TPMs can keep track of this bug and doesn't miss merge.
,
Jan 15 2018
The NextAction date has arrived: 2018-01-15
,
Jan 18 2018
RE: #c6-c7 AFAIR, we've discussed this bug and came to a conclusion that we don't need to merge to M64.
,
Jan 18 2018
Once M65 rolls to stable, we should update the list of protected mime types on https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Recommendations-for-Web-Developers
,
Mar 15 2018
The NextAction date has arrived: 2018-03-15 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by creis@chromium.org
, Jan 4 2018