MediaWiki

開発者向けセキュリティ

This page is a translated version of the page Security for developers and the translation is 29% complete.
Languages:

MediaWiki 開発者として、あなたにはレビューと監査が簡単なスタイルで安全なコードを書く責任があります。 この記事では、セキュリティに関連する問題点と、MediaWiki 開発者がこれらのセキュリティ問題に対処するために使用する成功事例に焦点を当てています。 コーディング スタイルの問題点については、MediaWiki コーディング規約をお読みください。

WMF Tech Days 2012 のウィキメディア財団セキュリティ エンジニア Chris Steipp によるプレゼンテーション

あらゆる MediaWiki 開発者は、Web アプリケーション開発および PHP の経験のレベルに関係なく、この記事を注意深く読み、定期的にこの資料に精通する必要があります。 さらに、すべての開発者は、クロスサイト スクリプティング (XSS)、クロスサイト リクエスト フォージェリ (CSRF)、SQL インジェクション に関する記事を注意深く読む必要があります。記事には、これらの一般的な脆弱性のそれぞれの詳細な説明が記載されています。 開発者向けセキュリティ チェックリスト は一般的な開発タスクの便利なリファレンスを提供します。

なぜセキュリティが重要か

ウェブ アプリケーションのセキュリティは、ネットワーク世界における重要な問題です。 セキュリティ上の脆弱性を持つウェブサイト群は、マルウェア、スパム、フィッシングなどの不正なグローバル インフラストラクチャの重要な構成要素となっています。 Bot herders crawl the web looking for websites with security vulnerabilities, and then use the vulnerabilities to hijack them. 乗っ取られたウェブサイトは、ブラウザーの脆弱性を利用したり、ソーシャル エンジニアリングによってあからさまにマルウェア (ウイルス) を訪問者に配布します。 ダウンロードしたマルウェアは、クライアントのコンピューターを、銀行口座情報の窃盗、スパムの送信、サービス妨害の脅威によるウェブサイトからの金銭強奪を目的とした組織犯罪のグローバル ネットワークの構成要素である「ゾンビ」に変えてしまうのです。

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.


セキュリティ脆弱性と攻撃の概要

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 authorize 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 serialization in new code.

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

Historical

関連項目


下位ページ


Retrieved from "https://www.mediawiki.org/w/index.php?title=Security_for_developers/ja&oldid=5683011"