I’ve always thought the fact that MediaWiki sometimes lets editors embed JavaScript could be dangerous.

Also, I’m also surprised an XSS attack like hasn’t yet been actually used to harvest credentials like passwords through browser autofill[0].

It seems like the worm code/the replicated code only really attacks stuff on site. But leaking credentials (and obviously people reuse passwords across sites) could be sooo much worse.

[0] https://varun.ch/posts/autofill/

▲

hrmtst93837 3 hours ago | parent | next [-]

I think autofill-based credential harvesting is harder than it sounds because browsers and password managers treat saved credentials as a separate trust boundary, and every vendor implements different heuristics. The tricky part is getting autofill to fire without a real user gesture and then exfiltrating values, since many browsers require exact form attributes or a user activation and several managers ignore synthetic events.

If an attacker wanted passwords en masse they could inject fake login forms and try to simulate focus and typing, but that chain is brittle across browsers, easy to detect and far lower yield than stealing session tokens or planting persistent XSS. Defenders should assume autofill will be targeted and raise the bar with HttpOnly cookies, SameSite=strict where practical, multifactor auth, strict Content Security Policy plus Subresource Integrity, and client side detection that reports unexpected DOM mutations.

▲

stephbook 6 hours ago | parent | prev | next [-]

Chrome doesnt actually autofill before you interact. It only displays what it would fill in at the same location visually.

	▲	varun_ch 6 hours ago \| parent [-]
		but any interaction is good for Chrome, like dismissing a cookie banner

▲

af78 7 hours ago | parent | prev [-]

Time to add 2FA...