|Site engagement can be gamed by tricking the user into many navigations|
|Reported by ma7h1a...@gmail.com, May 16||Back to list|
VERSION Chrome Version:58.0.3029.110 stable Operating System: Windows 10 enterprise VULNERABILITY DETAILS chrome version 58 disabled flash execution by default if user want to use flash,he must click the flash area and confirm the notice window to open it. but this bug shows a way to make a redirection between two pages without any notice to open it and make an attack. need user iteract --- click jacking(make a small game) click about 300 times and the flash could execute REPRODUCTION CASE please put them on a local webserver, i used apache + php and use the new.html to performance this attack the result.png shows the attack result
Issue 722726 has been merged into this issue.
I /suspect/ this is a result of the fact that we don't really disable Flash by default, we instead disable Flash for most sites based on the site engagement score. See Issue 699300 .
Site engagement score is specifically, by design, not a security barrier, so this is not a security bug. The site engagement folks might be interested in addressing this gaming of the metric though, so leaving as a bug for now.
if the "engagement score" is used to do those things,then it is actually a security barrier and once the attacker use it on a "low engagement score" he could even only use a remote file with any extension(.jpg,the most common) to make a flash-cross-domain-csrf and stolen user's important information
Maybe what we should talk is the flash player is being enabled without any notifications to the user. This is the point, since once the flash player is enabled, payloads other than a CSRF is available to be deployed. Personally I think this is a security vulnerability since it performs like a "primer" in the bullet. Waiting for a warhead to come is not a good idea.
Issue 722941 has been merged into this issue.
it might be a functional bug to be able to game the site engagement service but this is not a security bug as the design for site engagement specifically states: "Site engagement will never be used to silently grant privacy or security sensitive permissions."  Flash might be running but the fact that Flash is running is not a security issue per se, since it's still running inside the Chrome sandbox and would require bugs to gain execution and escape that sandbox.  https://docs.google.com/document/d/1GQE9gguqVMgXvR68jZyIsBhHVoAJb9m4fTn6omfqj4M/edit#heading=h.k4pjrzlnm098
ok,thanks for handle this problem. although it just block some attacks by accident hope it could be fixed
Navigation from link clicks does not generate any site engagement. The user needs to explicitly type in a URL in the omnibox or some other kind of more direct navigation in order to earn engagement from just visiting a URL. If a site manages to get the user to interact with it sufficient, engagement will naturally go up (that's the whole definition of engagement really). So this is really working as intended: a site that manages to get a user to stay on it and interact it with for a while will naturally gain engagement. If there's no other comments here, I'm going to WontFix this since it's working as intended.
wait. who renamed this issue? the original issue seems "chrome flash default-disabled bypass (was: Security: chrome flash default-disabled bypass)" rename it to something totally unrelated to security, and then WontFix it? Boring.
As mentioned in #3, "Site engagement score is specifically, by design, not a security barrier, so this is not a security bug."
WontFixing as per c#12. Please reopen if there are any more comments.
|► Sign in to add a comment|