> What this means is that client script can access those cookies which means that if you can get a piece of XSS onto the site – just as you can on the Aussie Farmers site – you can steal cookies containing passwords if you can get a customer to load the XSS payload
The author is saying that, putting the password in a cookie means that, if there is an XSS vulnerability somewhere, it can be trivially used to steal usernames and passwords, since the XSS can be used to inject code on the site that can grab the values from document.cookie and append them to a hidden iframe.
It's really unclear, but I think it's a loose reference to an older hack that involves patching javascript's Array to steal data when parsing JSON. The references to 'old array' and 'new array' in the screenshot seem to be the tipoff. This is my best guess at least.
I don't know if it's what Troy was implying, but JSON as a cookie payload along with the seemingly ubiquitous "parsing JSON using YAML and the YAML parser executing it as arbitrary code" vulnerability seems like it'd at least be worth attempting to attack there.
(Probably not what Troy was thinking, since that'd result in server-side SQLi or arbitrary code execution problems, not client-side ones like XSS. Also, I thnik Troy is more a .Net/asp kind of guy, not a Ruby-ist - which might make that YAML parser issue in Ruby/Rails not something he's concerned about)
The author is saying that, putting the password in a cookie means that, if there is an XSS vulnerability somewhere, it can be trivially used to steal usernames and passwords, since the XSS can be used to inject code on the site that can grab the values from document.cookie and append them to a hidden iframe.