New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 660133 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Blocking:
issue 543161



Sign in to add a comment

Full hash responses are parsed correctly only for certain threat types

Project Member Reported by vakh@chromium.org, Oct 27 2016

Issue description

In ParseMetadata, if match.threat_type() isn't one of the following, we consider the response invalid and return UNEXPECTED_THREAT_TYPE_ERROR:
* API_ABUSE
* MALWARE_THREAT
* POTENTIALLY_HARMFUL_APPLICATION
* SOCIAL_ENGINEERING_PUBLIC

This is incorrect since it fails to parse any full hash responses for other threat types, such as UWS.
 

Comment 1 by vakh@chromium.org, Oct 27 2016

Status: Started (was: Assigned)

Comment 2 by vakh@chromium.org, Oct 27 2016

Cc: awoz@chromium.org kcaratt...@chromium.org
Failure to parse the metadata should not lead to discarding the entire full hash response. Consider the following case:
1. example.com/hello goes on the API blacklist.
2. due to a change/bug in the server code related to metadata, the server stops sending the metadata or sends it in a different format.
3. Clients fail to parse the metadata and discard all full hash responses for that full hash.
4. example.com/hello can now not only abuse API, it can also start phishing since Chrome would always discard the full hash response for that full hash.


I am going to change the code in V4GetHashProtocolManager::ParseMetadata() to record the cases when metadata parsing fails (i.e. no change in UMA recording), but that won't discard the full hash response.

kcarattini@, awoz@: Let me know if you think that's incorrect. I'll CC you on the CL.

Comment 4 by vakh@chromium.org, Oct 27 2016

Status: Fixed (was: Started)

Sign in to add a comment