Right. Instead of debating the headline, this is the real question. The current behavior is that "someone on a 2FA authenticated session can disable 2FA". OK, so what?
Google is intentionally leaving this route open to lessen the impact of a lost authenticator. Probably this is a very significant cost savings for them -- although I don't know what their account recovery policy is for "lost" 2FA.
I'd say one risk factor here is that if someone is able to piggyback your session (e.g. CSRF) specifically into the 2FA Settings API, they may be able to get your 2FA disabled in a way that meaningfully exposes your account to a wider attack.
Another risk is similar to why you should require a password to be re-entered in order to change a password. The user is already in an authenticated session, and yet, it's still considered best practice to prompt for the existing password at the same time. This can't merely be as a second layer of CSRF protection, right? If your CSRF is broken, fix your CSRF.
I would assume the theory is to prevent an opportunist attacker with a small time window of access to your session (keyboard) from getting longer term access to your account.
Particularly for accounts that have long-lived sessions that don't have to use 2FA very often because of the cached session, you might not notice for quite some time that 2FA is no longer active.
As with most things in security, it's a double-edged sword.
Google is intentionally leaving this route open to lessen the impact of a lost authenticator. Probably this is a very significant cost savings for them -- although I don't know what their account recovery policy is for "lost" 2FA.
I'd say one risk factor here is that if someone is able to piggyback your session (e.g. CSRF) specifically into the 2FA Settings API, they may be able to get your 2FA disabled in a way that meaningfully exposes your account to a wider attack.
Another risk is similar to why you should require a password to be re-entered in order to change a password. The user is already in an authenticated session, and yet, it's still considered best practice to prompt for the existing password at the same time. This can't merely be as a second layer of CSRF protection, right? If your CSRF is broken, fix your CSRF.
I would assume the theory is to prevent an opportunist attacker with a small time window of access to your session (keyboard) from getting longer term access to your account.
Particularly for accounts that have long-lived sessions that don't have to use 2FA very often because of the cached session, you might not notice for quite some time that 2FA is no longer active.
As with most things in security, it's a double-edged sword.