Security for developers/zh

Presentation by Wikimedia Foundation Security Engineer Chris Steipp from the WMF Tech Days 2012

As a MediaWiki developer, you have a responsibility to write secure code in a style that is easy to review and audit. This article focuses on the issues related to security and on the best practices used by MediaWiki developers to address these security issues. For issues of coding style, please read the MediaWiki coding conventions.

Every MediaWiki developer should carefully read this article, regardless of their level of experience in web application development and with PHP, and periodically re-familiarise themselves with this material. Additionally, every developer should carefully read the articles on Cross-site scripting (XSS), Cross-site request forgery (CSRF), and SQL injection , which each provide more detailed explanations of each of these common vulnerability types. The security checklist for developers provides a useful reference for common development tasks.

为什么安全很重要

Web应用程序安全是网络世界中的关键问题。 存在安全漏洞的网站是全球恶意软件、垃圾邮件和网络钓鱼等非法活动的重要基础。 Bot herders crawl the web looking for websites with security vulnerabilities, and then use the vulnerabilities to hijack them. The hijacked website will distribute malware (viruses) to visitors, either via browser vulnerabilities or overtly by social engineering. The downloaded malware turns the client's computer into a "zombie" that is part of a global network of organised crime aimed at stealing bank account details, sending spam, and extorting money from websites with denial-of-service threats.

Demonstrable security

It's not enough to assure yourself that you are perfect and that your code has no security vulnerabilities. Everyone makes mistakes. All MediaWiki core code, and a good deal of MediaWiki extensions code, is reviewed by experienced developers to verify its security. This is a good practice and should be encouraged.

Write code in such a way that it is demonstrably secure, such that a reviewer can more easily tell that it's secure. Don't write code that looks suspicious but is, on careful examination, secure. Such code causes unnecessary reviewer anxiety.

Overview of security vulnerabilities and attacks

This document has a strong focus on the following attacks and security risks. Each MediaWiki developer should be familiar with these issues and have at least a passing understanding of them.

跨站脚本（XSS）

For detailed information on avoiding XSS vulnerabilities in MediaWiki, read the Cross-site scripting article. Cross-site scripting (XSS) vulnerabilities allow an attacker to inject malicious code into a website. XSS vulnerabilities are caused by a web application not properly escaping data from external sources (such as GET data, POST data, RSS feeds or URLs). The range of attacks that can be made via XSS are very diverse, ranging from harmless pranks to the hijacking of an authenticated user's account.

Primary defenses: To avoid XSS attacks, the basic principles are:

• Validate your input
• Escape your output

You can skip validation, but you can never skip escaping.

Escape everything. Escape as close to the output as possible, so that the reviewer can easily verify that it was done.

Note that output encoding (escaping) is context sensitive.

So be aware of the intended output context and encode appropriately (e.g. HTML entity, URL, JavaScript, etc.)

The OWASP Abridged XSS Prevention Cheat Sheet is a useful and up to date quick reference guide for mitigating XSS issues.

If you are writing JavaScript, please ensure that you understand DOM-based XSS, and how to prevent it in your code.

跨站请求伪造（CSRF）

For detailed information on avoiding CSRF vulnerabilities in MediaWiki, read the Cross-site request forgery article. Cross-site request forgery (CSRF or XSRF) attacks use authentication credentials cached in a victim's browser (such as a cookie or cached username and password) to authorise malicious HTTP requests. The malicious HTTP request can be sent in many ways. As long as the requests are processed by a web browser that has cached authentication credentials, a CSRF attack can be attempted.

Primary defenses: Our primary defense mechanism against CSRF attacks is to add edit tokens to HTML forms.

SQL注入

For detailed information on avoiding SQL injection, read the SQL injection article.

SQL injection relies on poorly validated input being used in a database query, possibly allowing an attacker to run arbitrary SQL queries on your server.

The attacker may then be able to fetch private data, destroy data or cause other unintended responses. In the worst case, the injected code could allow the attacker to gain full control of the system by exploiting multiple vulnerabilities in the database server, system utilities and operating system.

Primary defenses: The primary defense against SQL injection is to use MediaWiki's built-in database functions. Avoid using direct SQL queries at all costs.

serialize() / unserialize()

unserialize() can lead to arbitrary code execution. To prevent this MediaWiki developers should always use json instead of php serialisation in new code.

Primary defenses: Use FormatJson::encode() and FormatJson::decode() instead of PHP's native serialisation.

Historical

• register_globals, has not been an issue since MediaWiki 1.24 +.

参见

• Security checklist for developers – a checklist of common development tasks, and the security measures necessary for those tasks
  • phan-taint-check-plugin – a static analysis tool specifically for MediaWiki that checks your extension for common security flaws. Run as part of Phan .
  • PhpStorm project security – for developers who use the PhpStorm development environment
• 安全 – How to report security issues in Wikimedia software
• Common vulnerabilities
  • 跨站脚本
  • Cross-site request forgery
  • SQL injection
  • Open Web Application Security Project (OWASP) – general overview of vulnerabilities
• 手册:安全 – information for MediaWiki system administrators how to harden your MediaWiki installation

子页面

• Security for developers/Architecture
• Security for developers/Tutorial