The issue is that normally a user has to enter their password in Chrome or, if you want their cookies, you need to modify the chrome binary itself to steal them. The problem with headless chrome is that any application can now steal these cookies. Before if you wanted to do that with local malware you needed to do something much more noisy (create a fake chrome window, etc). You couldn't just do a File.read("chrome/cookies.txt").
Now you can, and that is stupid. To enable headless mode should require root.
If you can run code with the same privileges as Chrome (under an authenticated user account), then on most desktop OSes, you can do whatever Chrome can do, including access the password
store.
This may be a more convenient way to do so, but ultimately it's an attack that's rather hard to defend against under the usual desktop user-based access control model.
If the passwords are encrypted at rest via secure enclave then that isn't true[0] aside from other noisy attacks[1]. Yes local untrusted code is bad and a dedicated attacker attacking a specific target can probably escalate to stealing a full chrome cookies file, but that type of attack won't be worked into random malware floating around.
>The issue is that normally a user has to enter their password in Chrome or, if you want their cookies, you need to modify the chrome binary itself to steal them
or you could go to the site, autofill the password, then extract the password input's value using the dev console.
To reproduce, or utilize [it's a feature not a bug ;)] Whenever I forget my password to enter on a secondary device and don't want to unlock the keychain, I just go the site, logout, let it autofill the password and paste my lame script in the console. Whee!
var inputs = document.getElementsByTagName('input');
for(var i = 0; i < inputs.length; i++) {
if(inputs[i].type.toLowerCase() == 'password') {
alert(inputs[i].value);
}
}
Now you can, and that is stupid. To enable headless mode should require root.