Hi devs,
I've been investigating MediaWiki within my Bachelor's thesis
"Application
of security test tools in open source" at the Free University of Berlin
(FU Berlin) [1].
Basically, I am looking for security measures which have been taken to
prevent security leaks/vulnerabilities especially with security test
tools
MediaWiki is one of the most popular applications across the web. So the
attack area maybe quite large.
I have searched across the wiki itself, the mailist list and repo.
I have noticed some things, I'd like like to remark:
You advise, as most projects do, to turn "register_globals" off to
decrease attack possibilities [3]. A security reponse team [2] handles
security vulnerabilities and patches them immediately. Most releases do
include security fixes.
I am sure that you do anything you can to assure security.
Spite the recommondations and the security team. Does this team
or any other group/person take any measures to assure security with
testing tools, with a special test plan or functional requirements?
Thanks in advance,
Michael
[1] https://www.inf.fu-berlin.de/w/SE/ThesisFOSSSecurityTools
[2] http://www.mediawiki.org/wiki/Security
[3]
http://meta.wikimedia.org/wiki/Documentation:Security#General_PHP_recommend…
--
<NO> OOXML - Say NO To Microsoft Office broken standard
http://www.noooxml.org
At the risk of asking a stupid question: what is the status of category
intersections? I guess this is really directed to Brion, Tim, and anyone
capable of doing commits. Is there any interest/motivation in making it
happen? I think a lucene index is the way to go - if someone coded an
interface, could someone capable of doing it (Tim?) set up the index?
Best Regards,
Aerik
--
http://www.wikidweb.com - the Wiki Directory of the Web
http://tagthis.info - Hosted Tagging for your website!
Hi,
I have written an extension for a custom tag, and that extension creates
checkboxes
But, apparently, checkboxes handlers are automatically overwritten by
setupCheckboxShiftClick() in wikibits.js so my own onclick() action is lost.
How can I keep my own onclick() handler for my checkboxes ?
Pb showing on http://wiki.jmol.org/index.php/Sandbox
Thanks for any help,
Nico
Hi,
We have been using the Cite extension on our wiki's.
http://www.mediawiki.org/wiki/Extension:Cite/Cite.php
However, there is a need for a different type of referencing..
We have a list of items that are constantly referenced on multiple pages.
It would be nice to have an extension where you can define all items in one
place
then use them on different pages on the same wiki.
Has anyone else come across this need?
Thank you!!
I would like to know why MediaWiki is encoding SQL parameters instead of
using prepared statements with placeholders.
I just know advantages on using prepared statements, like security from
possible SQL injections, speed by having SQL statements preparsed and
the code is easier to write and read.
Prepared statements using MySQL directly:
http://devzone.zend.com/node/view/id/686
Prepared statements using MDB2:
http://pear.php.net/manual/en/package.database.mdb2.intro-execute.php
Could you guys explain why not using prepared statements in MediaWiki code?
On Tue, Apr 29, 2008 at 3:53 PM, Samuel Klein <meta.sj(a)gmail.com> wrote:
[snip]
> Image dumps haven't worked reliably since sometime in 2005. I blogged about
> this in mid-2006, at which point I believe there was a bittorrent option but
> no other; the bittorrent option hasn't worked for over a year.
> http://downloads.wikimedia.org/images/ used to offer a few 2006-era
> dump links; those too are now gone.
[snip]
For several months one of the Wikimedia systems was configured to push
images out to a system of mine with several terrabytes set aside, via
the then-development version 3 of rsync. (prior versions of rsync were
unable to cope with the large number of files)
This worked fairly well at the time and I handed out snapshots to a
number of other people who requested them.
The feed seems to have stopped in early January. I never bothered
looking into why, since I haven't been doing much with them recently
and no one has asked me for a new snapshot lately.
Bittorrent is pretty much non-viable for maintaining a mirror of
images (and nearly so for even making the initial several tbyte
transfer).
2008/4/28 Anthony <wikimail(a)inbox.org>:
> On Mon, Apr 28, 2008 at 12:59 PM, David Goodman <dgoodmanny(a)gmail.com> wrote:
> > First and hopefully uncontroversial step: make user and user talk
> > space non searchable via google etc. That will at any rate diminish
> > the tendency to use Wikipedia as a personal web site.
> First step should be to add a single checkbox to Wikipedia's internal
> search to search *all* namespaces, without having to check every
> single box. (Or is there already a way to do that?)
OH YES PLEASE.
> Anyone wanna file a bug report for me?
I'm cc'ing this to wikitech-l, there's a lot of really good active
work in progress right now on the search. (That's why the internal
search is productively usable now, as opposed to not being.)
- d.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've been getting a *lot* more complaints about bad diff renderings in
the last couple days, which may be related to the recent upgrade of the
wikidiff2 extension (triggered by PHP upgrades on the Fedora servers).
Some notes on my quest to track it down:
https://wikitech.leuksman.com/view/Diff_hell
I don't have a lot of data points, but:
* 1000 test hits total
* all hits used wikidiff2 extension
* 515 hits were to Fedora machines
* 8 Fedora hits gave bogus results
* quick command-line-based tests didn't have any failures
The Ubuntu boxes are running a slightly older version of wikidiff2 which
doesn't add the inline classes, but that shouldn't make any difference.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgSeTUACgkQwRnhpk1wk47vQgCfTS8G+dfMMK8B5LlChDZWPEQV
F3kAnRYo41k0YQt6504m01MQWHwa4eom
=KezH
-----END PGP SIGNATURE-----
I can already see some of this by greping wfReadOnly() on /includes. This
function simply reads a file on the disk, so it is not cached, nor
per-transaction. Therefore it can change in the short time one operation of
an a larger set of operations was called, and the next. This can cause
broken "transactions" on occasion.
I suspect this is what caused the logging problems. It only occurred during
heavy traffic or when someone was rapidly doing something (I got a report
from someone using a commons mass deletion script) and somewhat randomly
(only a portion of the time). This is consistent with the wfReadOnly() check
that used to be in LogPage.php.
--
View this message in context: http://www.nabble.com/Use-of-wfReadOnly%28%29-in-non-entry-point-functions-…
Sent from the Wikipedia Developers mailing list archive at Nabble.com.