This appears to be increasingly common in recent weeks. We should probably stop recently-created accounts from using user Javascript, in the same way that was done with page moves for the Willy on Wheels page-move vandalism outbreak.
Alternatively, it may be possible to make these kinds of attacks significantly more difficult, by, for example, blacklisting the use of certain functions in user JS?
-- Neil
Neil Harris wrote:
This appears to be increasingly common in recent weeks. We should probably stop recently-created accounts from using user Javascript, in the same way that was done with page moves for the Willy on Wheels page-move vandalism outbreak.
Alternatively, it may be possible to make these kinds of attacks significantly more difficult, by, for example, blacklisting the use of certain functions in user JS?
What sort of attacks are you talking about? People cannot (or shouldn't be able to) execute JavaScript on anyone else's computer, only their own.
What sort of attacks are you talking about? People cannot (or shouldn't be able to) execute JavaScript on anyone else's computer, only their own.
Something like: * when opening a page, emulate a click on the 'rename' button * fill the new name with 'big penis <old name>' * submit form
A vandal on fr: did that, renamed >50 pages in a few seconds... Was reverted, of course :)
Nicolas Weeger
Nicolas Weeger wrote:
What sort of attacks are you talking about? People cannot (or shouldn't be able to) execute JavaScript on anyone else's computer, only their own.
Something like:
- when opening a page, emulate a click on the 'rename' button
- fill the new name with 'big penis <old name>'
- submit form
You don't need JavaScript to do that.
Timwi
Timwi wrote:
Nicolas Weeger wrote:
What sort of attacks are you talking about? People cannot (or shouldn't be able to) execute JavaScript on anyone else's computer, only their own.
Something like:
- when opening a page, emulate a click on the 'rename' button
- fill the new name with 'big penis <old name>'
- submit form
You don't need JavaScript to do that.
Timwi
Indeed not, but it lowers the bar to admit a rather greater number of Skript Kiddies. See the exploit script that's currently knocking about.
-- Neil
Neil Harris wrote:
Timwi wrote:
You don't need JavaScript to do that.
Indeed not, but it lowers the bar to admit a rather greater number of Skript Kiddies. See the exploit script that's currently knocking about.
It would be actually useful to work on decent rate limiters, which would apply to all client scripts.
-- brion vibber (brion @ pobox.com)
On Tue, May 24, 2005 at 03:27:18PM -0700, Brion Vibber wrote:
Neil Harris wrote:
Timwi wrote:
You don't need JavaScript to do that.
Indeed not, but it lowers the bar to admit a rather greater number of Skript Kiddies. See the exploit script that's currently knocking about.
It would be actually useful to work on decent rate limiters, which would apply to all client scripts.
To whoever is going to write such a limiter: please don't apply it to users with bot flag. Thanks. :-)
Tomasz Wegrzanowski wrote:
On Tue, May 24, 2005 at 03:27:18PM -0700, Brion Vibber wrote:
Neil Harris wrote:
Timwi wrote:
You don't need JavaScript to do that.
Indeed not, but it lowers the bar to admit a rather greater number of Skript Kiddies. See the exploit script that's currently knocking about.
It would be actually useful to work on decent rate limiters, which would apply to all client scripts.
To whoever is going to write such a limiter: please don't apply it to users with bot flag. Thanks. :-)
And, just to link several discussion threads together, how about a nice hook routine, set_BOPM_candidate(), that could be called from various places in the code to mark an IP as eligible for a BOPM scan?
Then, we could call this for all manner of vandal-suggestive-but-not-conclusive events, such as rapid editing, being reverted by admins, page-blanking, creating very large pages, and so on. As we think of new heuristics, we can just put this call in.
For example, editing a user Javascript page might be one. Or creating several accounts in rapid succession. ;-)
Keeping a whitelist of recently-scanned-and-found-OK IPs will prevent this from being annoying for special cases such as ISPs, shared proxies and bots.
A failed BOPM scan would then apply only a _short term_ IP block to the open proxy: perhaps a week -- but it could do it across all languages and projects. At the end of the week, the block would automatically clear itself. Then the cycle can start all over again. The net effect would be to hugely change the balance of power between open proxy using vandals and the admins trying to clean up their messes, as the vandals' ability to create damage would be automatically throttled by their ability to acquire new open proxies.
-- Neil
Neil Harris wrote:
And, just to link several discussion threads together, how about a nice hook routine, set_BOPM_candidate(), that could be called from various places in the code to mark an IP as eligible for a BOPM scan?
How about an offline script that anyone can run to check IPs for being an open proxy? That way it's not Wikimedia's responsibility because the "portscans" will be coming from Wikimedians' own home computers.
A failed BOPM scan would then apply only a _short term_ IP block to the open proxy: perhaps a week
I don't like this because then vandals only need enough proxies to fill a week, and then they can re-use the old ones because the blocks will expire.
Instead, I think they should be blocked indefinitely, but anyone wishing to edit from such an IP should get a sensible message about the open-proxy problem and NOT a screen telling them they're "blocked".
Timwi
Timwi (timwi@gmx.net) [050527 15:06]:
Instead, I think they should be blocked indefinitely, but anyone wishing to edit from such an IP should get a sensible message about the open-proxy problem and NOT a screen telling them they're "blocked".
http://en.wikipedia.org/wiki/Template:Blocked_proxy is what most people use on en:.
Editable - tweak as appropriate.
- d.
Hello Timwi,
Friday, May 27, 2005, 8:04:46 AM, you wrote:
Instead, I think they should be blocked indefinitely, but anyone wishing to edit from such an IP should get a sensible message about the open-proxy problem and NOT a screen telling them they're "blocked".
Here's the clash with another problem discussed - what about anonymity? What if someone wants to contribute (vastly), but cannot afford to show his real IP-address (for example, these contributions may lead him to jail in his country)?
You can't block open proxies for sure.
wikitech-l@lists.wikimedia.org