User blog:KockaAdmiralac/Security issues


 * Disclaimer: author of this blog is not a security expert and is only speaking from experience with seeing, finding and dealing with security issues across . He is also not affiliated with Staff.

Hello. I'm and this is my first blog on, but if you've been around for some time you might have seen me already help users in chat, forum and message walls. I'm also currently a content moderator of w:c:dev, where I've published and contributed to several scripts and applications. I have not been writing blogs on since around February 2016, so if anything in this blog sounds weird, please be painfully honest (and preferably constructive) about it in comments.

This blog is supposed to outline what kinds of possible security issues you should be aware of while on, what should you do against them and what is already being done against them. Some content of this blog might be too technical for a user that does not face editing personal and wiki-wide custom JavaScript/CSS often, which is why I intend to post future security-related blog posts on.

What are security issues
Security issues on are issues usually related to the ability to, in any way, take control of another user's account while not being Staff. The security issues I'm talking about in this blog are not users' own unhealthy security habits (and therefore Terms of Use violations), such as sharing passwords with others or staying logged in on public computers.

Security issues I'm referring to are related to errors in 's code that let users do unexpected things, from being given unrestricted control of what JavaScript is run in browsers of other users (and therefore control of their actions) to getting direct access to 's servers and database. While the latter never actually happened on (as far as I know), some minor security issues can potentially result in unregulated cross-wiki vandalism, wikis being closed and/or elevated permissions being assigned to users that abused said security issues.

Recent history of security issues on
Just a quick recap of things that used to be possible on but aren't anymore:
 * It was pointed out on in 2012 that code pages located in articles anybody can edit are a security issue. This was temporarily resolved with a new usergroup being created.
 * Four years later, after the introduction of JavaScript review, the pages have been moved to MediaWiki namespace and the user group has been deprecated.
 * A troll back in August 2015 compromised a Staff account and closed some wikis. In response to that:
 * MediaWiki pages on have been whitelisted so administrators can only edit some of them. This was done because system messages were often displayed without escaping in the wiki interface, making the wiki prone to XSS if abused.
 * A review process for JavaScript has been introduced.
 * Admins used to be able to insert raw HTML into articles from a MediaWiki namespace page using the  tag. This was a very high security risk so the tag has been retired on November 6th, 2015. The tag is still usable, but only pages that aren't in the MediaWiki page whitelist can be supplied to it, rendering the tag useless for non-Staff users.
 * A Staff account has been compromised around March 1st and after it was noticed on July 6th, Staff accounts were prevented from removing their login restrictions. All Staff accounts now cannot be logged into through the same form as regular users.

Importing code from untrusted sources
Importing code from pages that other users can edit and that isn't explicitly approved by Staff is a security issue. Importing JavaScript from articles/user subpages that aren't protected so only administrators can edit them means that any user can make you execute any JavaScript by editing these pages, which in turn means allowing any user to use your account to promote themselves to any user group you can promote to, make your account vandalize across several wikis without your knowledge, etc.

It is generally recommended to only import scripts from MediaWiki namespace, preferably from, but if you really want to import pages like this (which also gives the benefit of importing personal code without it having to go through JavaScript review) make sure they are protected so as few as possible users can edit them.

Writing insecure code

 * While this section is mostly aimed at script developers, non-technical users might also detect (potentially) insecure code by looking at the examples mentioned below. Future blog posts about this will be posted on .

Sometimes, insecure code will pass even through the JavaScript review team. It is your job to make sure users of your script or wiki are secure by not making your scripts insecure. A few things you can do to make sure your code isn't insecure are:
 * Don't allow inserting arbitrary HTML into the page. Things like this allow users to, through  tags, make other users execute any JavaScript, which has the consequences mentioned above.
 * Don't concatenate HTML. If you are doing things like with user input not being escaped, they are security issues and you should consider using jQuery, UI-js or the DOM API for building the interface for your script. They abstract HTML into JavaScript objects that you can more safely use. This might be just my opinion, but raw HTML has no place inside JavaScript.

https://vignette.wikia.nocookie.net/kocka/images/2/29/ESB_security_issue.png/revision/latest/scale-to-width-down/500 A security issue in my sandbox on Encyclopedia SpongeBobia, which has been resolved in December 2017. Cause of the issue was, as expected, insecure HTML concatenation.

Copying code
Sometimes, insecure code is copied across several places before a security vulnerability is discovered. Without knowing where all instances of a code lie, it would be hard to fix the security vulnerability. An example of this is WikiStatistics, which used to be copied into Common.js of several non-English wikis. After OneTwoThreeFall discovered the security issue in there, he disabled the script from executing, but that was not the only instance of that script executing, and it took some time to find and remove other instances of this code. It is unknown whether there are still instances of it elsewhere.

In general, do not copy code unless you know exactly what you're doing. If you want to suggest a modification to the code you'd usually copy, assuming the script is hosted on the, it might be much better to suggest the feature you need on the talkpage of the related script. If the script is not hosted on and you want to change something in it to adapt it for your wiki, it might be worth moving that script to, so you should probably suggest that on the Script Suggestions board.

This does not apply to importing code using (s) or ImportJS.

How does deal with security issues
As it is primarily 's job to secure their platform, they have taken several steps in that way:
 * After Staff accounts getting compromised several times, they have introduced a different login process for Staff that has tightened security.
 * JavaScript review has been introduced, because freely editable JavaScript on wikis has always been a security risk and after the 2015 security issues they have decided to reduce that risk. Now all wiki-wide JavaScript has to be reviewed by a select group of Staff before it gets delivered to all other users. This makes publishing changes to JavaScript much slower than it was before, but, unless it's the weekend, JavaScript pages generally get reviewed in less than a day and the wait is worth the security it brings in return.
 * The security report form is where accepts all reports of possible security issues. It is generally responded to faster than other contact forms and if issues reported here are confirmed to be security issues they will be prioritized for fixing over any other bugs or features. If the issue isn't in 's codebase but wiki-wide JavaScript, a member of the content review team may delete/comment-out the vulnerable code until the security issue is resolved.

How should users deal with security issues
https://vignette.wikia.nocookie.net/kocka/images/b/bd/ESB_security_report.png/revision/latest/scale-to-width-down/500 A proper security report of the security issue shown above.
 * Report the issue via the security report form. Provide as many details as you can about the issue, as the Staff member that will be reviewing your request is most likely not a security expert and only supposed to deliver your report to engineers for resolving.
 * Do not exploit the issue. This, at best, may lead to your exploits getting deleted and at worst getting globally blocked for an indefinite amount of time.
 * If you aren't sure whether the issue you found is a real issue, you can discreetly attempt to reproduce the issue. Attempting to reproduce a security issue in a wiki with many users is a bad idea, as somebody could notice you successfully reproducing it and abuse it before it's resolved, and it should only be done if reproduction is absolutely needed and the issue can only be reproduced in a public environment. Otherwise, it would be better if you reproduced the security issue on your testing wiki or, if your test wiki is visited by users often as well, found a wiki specifically for security tests and keep it hidden from everybody else.
 * Lastly, do not try to fix an issue in 's codebase with JavaScript. JavaScript is very limited in what it can prevent from happening and the issue may be more widely spread than you expected to find, which is why these issues should be left for Staff to resolve.

Conclusion
Be aware that the security of users on is a top priority and any kind of threat to it should not be taken lightly. Practice responsible disclosure.
 * Thanks to Speedit, TheGoldenPatrik1 and FelineIva for suggesting changes to the blog!