domas.mituzas wrote:

well, servers give out Content-type: text/plain, so that is a flaw of a browser,
if it handles non-text/html documents as html. On the other hand, all downloads
might be served from *.wikidownloads.org, so *wikipedia or *wikimedia cookies
would not apply.

bugzilla_wikipedia_org.to.jamesd wrote:

Reporter noted that "I've tested on opera,safari,ie,camino (mac os x) and ie
(win32) and mozilla,konqueror (linux) only ie (on both mac and win32) and safari
with the problem".

Users of the affected browsers should not vie wthe text file - their password
will be stolen if they do. Changing password before you view it will cause the
new one to be stolen instead, then you can change back later.

Apparently no one remembered to update this bug report...

1.4cvs & 1.3.5 include stricter checks on uploads to help close the gaping holes
in IE, and we've moved the uploads on Wikipedia to an alternate domain for now
to reduce exposure to the main wikis.

1.4cvs now uses a generated token instead of the hashed hashed password for the
'remember my password' mode. This has also been backported to Wikipedia's
servers, but isn't yet included in 1.3 release as it makes some database
changes. This should be more secure against dictionary attacks to recover the
plaintext, but is still usable to login if you can snarf it.

In Windows XP SP2, IE now has a security option "Open files based on content,
not file extension". You might think that turning this off would close the
security hole, but unfortunately you'd be wrong; it still interprets ".txt" as
"it's okay to think this is HTML and run JavaScript, even though neither the
Content-Type header nor the 'extension' you think you see look like '.html' at
all". Sigh.