Limited content reflection or content spoofing

Sometimes our reporters mention an issue, where they could reflect content into a Google web application in a specific, limited way. For example, they might be able to show a text message in the body of the page. To describe that issue, OWASP uses the name "Content Spoofing" or "Text injection".

If the reflected content is limited (e.g. it's just text, or a safe subset of HTML that cannot result in an XSS) we don't consider it a vulnerability in itself under our VRP. It's useful, and sometimes necessary in web applications to reflect some parameter values in HTTP responses. Usual places that allow you to reflect the content are:

  • error messages to display passed as a GET/POST parameter
  • 404 pages
  • search result pages
  • web pages that send an e-mail message from @(google|youtube|...).com address with partially-controlled message contents.

Web applications often reflect the content posted by the user, and as long as there is proper escaping or sanitization to prevent e.g. XSS and referrer leak, that's an accepted risk for us.

Commonly-reported attack scenario uses content reflection to start a social-engineering attack. For example, the attacker displays a Google page with controlled content, and convinces the victim users to perform some actions, exploiting their belief that the message is authored by Google. Even considering this vector, most of the times we believe the security impact is too low for us to file a bug and issue a reward. Our reasoning is that social engineering attacks will (unfortunately) continue to work regardless, as the attacker might instead send a phishing e-mail with a spoofed From: address with similar success rate.

To put that into context, social engineering attacks very rarely meet the bar for the reward or credit. For those few that are accepted by the panel, attack scenario needs to be really clear and convincing - most likely this involves chaining a few vulnerabilities into an attack you yourself would fall for.

We made a conscious decision to focus on solving the more pressing problems that endanger our users data (like XSS or Authorization issues) first, and addressing the more subtle issues later. Reports pointing out limited content reflection will usually not qualify for a reward or credit under Google VRP.