At 9:40 AM -0800 12/15/09, John Panzer wrote:
long-standing hole in browsers that gives ~equivalent information to
phishers, and this is not one I've heard of them using (perhaps you
have). It's a good opportunity to look at what attack vectors this
has enabled in the real world
http://www.azarask.in/blog/post/socialhistoryjs/
http://www.schillmania.com/random/humour/web20awareness/
http://www.niallkennedy.com/blog/2006/03/automatic-favor.html
http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html
This may be a less-than-thorough list, I'm just copying across from a
bookmarks folder I retained about this particular exploit.
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html
https://www.indiana.edu/~phishing/browser-recon/
At 10:11 AM -0800 12/15/09, Breno de Medeiros wrote:
I don't buy the CSS history stealing argument, that's all. CSS history
stealing is essentially a cross-domain cookie API without user opt-out
option. So I wonder how long before browsers turn off this 'feature'.
Stanford released a fix (Firefox addon) for it a few years ago; I
don't expect browsers to integrate anything similar until we've
shifted into full isolation mode (thread isolation for each tab is
moving toward this, and single-site browsers have the right idea;
give each site its own virtual environment and retrieve final data
from *those* to interact with, allowing an extra layer of
interpretation so the user can see colored links (and other data
overlaid) that the remote site doesn't have any way to be aware of,
unless the top/privileged layer specifically *opts in* to sending
that data back down the chain), because we're currently at a fairly
stable pattern as far as the convenience/security balance goes.
-Shade
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
