https://bugzilla.wikimedia.org/show_bug.cgi?id=19161
x127 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from x127 <[email protected]> 2009-06-11 22:15:13 UTC --- As it seems there is no wish for secrecy, let me discuss this attack in the open. (Most can be infered from the comments so far, anyway....) Basically, an external website could redirect wikimedia users to any of the smaller wikimedia projects where they will likely not have an account yet. This might happen in a hidden frame without the user noticing anything at all. Then, the external website would correlate the timestamps of the account creation log from the smaller wikimedia project with its web server log to obtain a mapping of IP addresses and usernames. This attack assumes that it is possible to lure many wikimedia users to an external site. I can think of two ways to do that. The obvious way would be to add the external URL as a source or citation for various articles. If the attacker does not mind violating the copyrights of third parties, the linked content may even appear relevant. This form of attack would mostly target wikipedian who watch the recent changes to fight vandalism. Another way to do it would be to use a website already in place. There may be websites out there which are openly hostile to some wikimedia projects and interested in figuring out the identity of senior editors. Furthermore, it is possible that some of the senior editors already monitor these websites, so there may not even be a need to lure them there. (Note: all of these assumptions are speculative from what I have read years ago on /. or something.) As others have remarked, there are other ways to determine the IP address of editors. One could put external links on their talk pages or send them via IRC, or one could mail them mails containing web bugs. All these methods target users specifically and scale badly. The attack described above, on the other hand, scales well. There are probably numerous wikimedia projects with a low account creation rate, and to each of them there could be a redirect every few seconds with the time correlation between the logs being maintained. In practice, the attack speed would only be limited by the number of wikimedia users visiting the external website. Assuming attackers are able to lure a significant percentage of the community to their site, I would call the impact of this attack an "unofficial checkuser database". Disabling account creation from external referers would certainly complicate the attack. One might try to trick people into clicking an internal link on a wikimedia page loaded in a frame. This would greatly decrease the time correlation, making it more difficult to match users. Also, users would probably have to realize that they are browsing a wikimedia site and some may not click on the desired link. I am not very well versed in web security, but from what I have found with a search engine, there existed exploits in the past for browsers as well as media plugins to redirect users to websites with a fake referer. The general opinion seems to be that it is not good security practice to rely on the referer not being tampered with. >From a purely philosophical position, database changes (such as account creation) resulting from a HTTP GET seem to go against the spirit of RFC 1945, where the POST method was specifically created for such purposes. In conclusion, I would call into question whether automatic account creation is a overall good thing from a user point of view. If instead of automatically creating a user account upon detection of cookie information, one would simply put a button (so that on could utilize the POST method) on the page called "create account for $USER", the overall usability would not decrease that much. After all, most users do not spend that much time visiting projects they never visited before. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
