Gregory, thanks for the warning. The toolserver will not work for this - its using MySQL 5, which optimizes everything very differently. Plus it is using views instead of tables - again, there are some optimization bugs associated with that. This really has to be on the main wiki - this way we could even compare a large wiki vs a small wiki query optimizations.
One solution would be to disable regex - most queries don't need that.
From my experience, most of the time I need to run simple join and
lookup queries with various filters. "LIKE" has been used a few times, but more often it is simply <,=,>. I guess we can make a list of prohibited fields/tables.
On 8/27/07, Gregory Maxwell gmaxwell@gmail.com wrote:
On 8/27/07, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
Ouch, thanks Simetrical. I guess "user_password" should not be allowed in any "explain" queries. Any other risky ones out there?
On the other hand - this only introduces another possibility of a login - same as going through the regular login page. I can't think how it would be a security risk - automated running through a list of md5 hashes. We could implement a memcached solution so that no more than 10 queries would run per minute.
EXPLAIN SELECT * FROM user WHERE user_name='Simetrical' AND user_password REGEXP '^[0-7].*'; ... It should only take a maximum of 128 queries to read the entire MD5 one bit at a time starting with no starting info. This isn't the same as a bruteforce shortcut. You can't solve this with a delay or a captcha.
There are a bunch of fields that need to be protected (rc_ip, for example.. user prefs.. watchlist table...). To really make the tool useful is has to be very flexible in what it accepts. I looked at building something like this for toolserver users a while back and decided it would be too much work to get it right.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l