ja:devel:security
目次
プラグイン開発者のためのセキュリティガイドライン
DokuWikiのプラグインの開発はとても簡単なので、PHPの初心者でも作ることができます。あなたの作ったプラグインがDokuWiki全体のセキュリティを危険にさらしていないか確かめるため、このページで概説するガイドラインに従ってください。
原文1)
このページは完成しているわけではありません。もっとより深い情報・リンク・例を必要としています。
原文2)
よくある問題
よくあるセキュリティ問題と、それを回避する方法です。3)
クロスサイトスクリプティング(XSS)
DokuWikiのプラグイン機構はプラグイン開発に非常に柔軟性を与えています。特に、syntaxプラグインの場合、DokuWikiのフレームワークはプラグインが生のプロセスされていない出力を書き出すことを可能にしています。4)
そのためクロスサイトスクリプティングの問題があるのです。5)
Cross Site Scripting refers to an attack where malicious JavaScript code is introduced into a website. This can be used to redirect innocent users to malicious websites or to steal authentication cookies. This is the most common issue in DokuWiki plugins. To avoid it the simple answer is to always escape all output using the htmlspecialchars or rawurlencode; although there are cases where this is not straightforward.
Unless plugin developers are extremely careful, it is easy to write a plugin that works as intended, but also has unintended 'features' that may be of benefit to an attacker. Cross Site Scripting is an example of this.
| Q: | どんなタイプのDokuWikiに脆弱性がありますか？6) |
|---|---|
| A: | 脆弱性のあるプラグインを使っていて、「htmlの埋め込み」か「phpの埋め込み」のどちらかが許可されていると、脆弱性が高くなります。もし「phpの埋め込みを許可」している場合は、暗黙的に「htmlの埋め込みを許可」していることになります。そして、「htmlの埋め込みを許可」していると、攻撃者は脆弱性のあるプラグインを利用して簡単に攻撃ができるようになります。脆弱性のあるプラグインがインストールされていて、ユーザー自身の登録を許可し、ページの編集を許可しているDokuWikiシステムで、特に脆弱になります。7) |
| Q: | どのプラグインが危険ですか？8) |
|---|---|
| A: | Syntaxプラグインがそういった問題をもっともはらみやすいです。しかし、どのプラグインでも出力htmlが脆弱なものになりえます。もちろん、すべてのプラグインが脆弱なわけではありません。9) |
| Q: | どうやってそれをするのですか？12) |
|---|---|
| A: | HTMLにJavaScriptを埋め込む場所は2カ所あります。 1. <script>と</script>タグの間たとえば <script>alert('XSS attack')</script> 2. HTML要素固有のイベントとして 多くのHTMlタグは固有のイベントをもっています。 <div/>の場合であれば<div onmouseover=“alert('XSS attack')”></div>といったイベント処理ができます。こういったイベントはたくさんあり、このイベントがが起こればスクリプトが起動してしまいます。onmouseoverはHTMLでレンダリングされたオブジェクト(object, image, paragraphなど何でも）上にカーソルが入るとイベントが発生します。3.属性値の置換 これは <div class=&{alert('XSS')};></div>といったものです。4. URIの一部 ごく一部のプラグインは外部のオブジェクトを読み込む機能を提供しています。このような機能は、 <object data=“javascript:alert('XSS attack')”/>といったスクリプトで攻撃されます。13) |
| Q: | どうやって攻撃を止められますか？14) |
|---|---|
| A: | 大まかには３つの方法、すなわち「入力の制限」「入力の検査」「出力のエンコード」があり、すべて必要となるかもしれません。 1.攻撃スクリプト中に含まれる文字を制限します。 connectT()メソッドにできるだけ制限の厳しい正規表現をしていします。たとえば、[a-zA-Z0-9]や\wしか許されていなければ攻撃者はたいしたことはできないでしょう。2. プラグインが受け取る入力が好意的だと想定してはいけません。 すべての入力に悪意が含まれている可能性があるので、入力のチェックには特に注意を払わなければいけません。たとえば、もしプラグインがユーザーに柔軟なHTML属性値の制御をできるようにしている場合、「入力の制限」によって攻撃を防ぐことはむずかしいかもしれません。しかし、固有のイベントをユーザーに与える ・・ この効果は「HTMLの埋め込みを許可する」フラグが可能にしています。・・ この場合、ユーザーが指定できるのはすべてのエレメントが固有のイベントを含まないでほしいわけです。これはユーザーの入力をパースして許されている属性値だけを使っているかをチェックするほうが、禁止されている属性値をパースするより安全です。これは、許されるものを「whitelistingする」と呼び、禁止するものを「blacklistingする」ことよりも優先されます。 3. 出力のエンコード 最後は、プラグインが外から受け取ったもの（ユーザーから・外部サイトから）を出力するところで、出力が適切にエンコードされていることを確認しなければいけません。プラグインに関していえば、URLエンコード（空白を +や%20に置換するなど）や、HTMLエンコード（>を<に置換するなど）によって可能でしょう。多くのプラグインの場合、そういった幅広い文字が使われても正しく機能するかどうかをチェックする必要があります。15) |
need practical examples of whitelist/blacklist REGEXs, whitelisting attributes, when to use htmlspecialchars() and rawurlencode() and how to review a plugin.
外部コードの読み込み
This attack allows an attacker to inject (PHP) code into your application. This may occur on including files, or using unsafe operations functions like eval or system.
Always filter any input that will be used to load files or that is passed as an argument to external commands.
情報の漏洩
This attack may lead to exposal of files that should usally be protected by DokuWiki's ACL or it might expose files on the server (like /etc/passwd).
Always filter any input that will be used to load files or that is passed as an argument to external commands.
Always use DokuWiki's ACL check functions when accessing page data.
SQLインジェクション
This attack is rarely relevant in DokuWiki because no database is used. However if your plugin accesses a database always escape all values before using them in SQL statements.
More info:
セキュリティ問題に関する報告は・・
もし、プラグインの問題に遭遇してしまったら、メールで作者に知らせてください。
また、そのプラグインページにあるdataのsecurityissueフィールドに問題の情報を記してください。このフィールドは赤い警告ボックス内に表示され、メインのプラグインリストから外されます。
問題が解決されて、新しいバージョンがリリースされたら、このフィールドはまた削除してください。
原文16)
1)
Creating plugins for DokuWiki is very easy even for novice PHP programmers. To make sure your plugin does not compromise the security of the whole DokuWiki it is installed on, you should follow the guidelines outlined on this page.
2)
this page is in a very raw state and should be extended with more indepth info, links and examples.
3)
Here is a list of common security issues and how to avoid them.
4)
DokuWiki's plugin mechanism gives plugin developers a great deal of flexibility. In the case of syntax plugins in particular, the framework gives plugins the ability to write raw unprocessed output.
5)
And therein lies the problem of Cross-site scripting.
6)
What types of DokuWiki installations are vulnerable?
7)
DokuWikis that use one of the vulnerable plugins and have “allow HTML” set to false or have “allow php” set to false. If you “allow PHP” then you implicitly “allow HTML” - if you “allow HTML” then an attacker has an easier way to do the sorts of attacks that are possible via vulnerable plugins. DokuWikis that allow users to register themselves and allow such users to edit any page are particularly vulnerable - if they have a vulnerable plugin.
8)
Which plugins are at risk?
9)
Syntaxplugins are most likely to have this sort of problem. But any plugin that writes output could be vulnerable. Of course, not all plugins are vulnerable.
10)
How does the attack work?
11)
The attacker will try to include JavaScript in the use of a plugin, somehow. The details of the attack will vary depending on how the plugin works
12)
And how might they do that?
13)
-:: There are a couple of places where JavaScipt can be included in HTML:
1. between
2. as an intrinsic event. Many HTML tags can use intrinsic events, like say
3. As attribute value substitutions. This may look something like
4. as part of a URI. Quite a few plugins provide a way to include a remote object (eg Flash, RealPlayer, etc). This might look something like
1. between
<script> and </script> tags - eg <script>alert('XSS attack')</script> 2. as an intrinsic event. Many HTML tags can use intrinsic events, like say
<div/>. This might look something like <div onmouseover=“alert('XSS attack')”></div>. There are a large number of intrinsic events. When the even occurs, the script will fire. onmouseover will fire when the user moves their pointing device (pointer) over the rendered version of the HTML tag (object, image, paragraph, whatever).3. As attribute value substitutions. This may look something like
<div class=&{alert('XSS')};></div>4. as part of a URI. Quite a few plugins provide a way to include a remote object (eg Flash, RealPlayer, etc). This might look something like
<object data=“javascript:alert('XSS attack')”/>14)
How do you stop the attacker?
15)
There are 3 main methods, which can be summarised as “limit inputs”, “validate inputs” and “encode outputs” - all three may be necessary:
1. Limit the characters that can be included in an attack. In the
2. Don't assume that the inputs that the plugin receives are benevolent. Any of the inputs could be malicious, so you should check them very carefully before using them. For example, if the plugin intends to give the user the ability to control the HTML attributes to give them extra flexibility then it may not be convenient to limit the inputs enough to prevent an attack. However, is it intended to give the user the ability to use intrinsic events? This in effect turns on the “allow HTML” flag. In this case we may want the user to be able to specify all the elements except the intrinsic events. It is usually safer to parse the users input to check that they are only using the permitted attributes, rather than to try to parse out the prohibited attributes. This is often referred to as “whitelisting” the permitted things in preference to “blacklisting” the prohibited ones. This is safer as there are foten ways to bypass the blacklists.
3. Finally, where you are outputting something that you received from outside the plugin (whether from the user or from an external site), you should ensure that the output is appropriately encoded for where it is going to be used. In the context of plugins, this may include URL encoding (eg converting spaces to
1. Limit the characters that can be included in an attack. In the
connectTo() function, specify a regular expression that is as restrictive as you can. For example, if an attacker can only use something like [a-zA-Z0-9] or \w then they are not likely to be able to do an interesting attack.2. Don't assume that the inputs that the plugin receives are benevolent. Any of the inputs could be malicious, so you should check them very carefully before using them. For example, if the plugin intends to give the user the ability to control the HTML attributes to give them extra flexibility then it may not be convenient to limit the inputs enough to prevent an attack. However, is it intended to give the user the ability to use intrinsic events? This in effect turns on the “allow HTML” flag. In this case we may want the user to be able to specify all the elements except the intrinsic events. It is usually safer to parse the users input to check that they are only using the permitted attributes, rather than to try to parse out the prohibited attributes. This is often referred to as “whitelisting” the permitted things in preference to “blacklisting” the prohibited ones. This is safer as there are foten ways to bypass the blacklists.
3. Finally, where you are outputting something that you received from outside the plugin (whether from the user or from an external site), you should ensure that the output is appropriately encoded for where it is going to be used. In the context of plugins, this may include URL encoding (eg converting spaces to
+ or %20) and/or HTML encoding (eg converting < to <). Note that in many cases, such encoding is necessary for a plugin to work correctly with a wide variety of valid inputs.16)
If you encounter an issue with a plugin please inform the author of the plugin via email.
Additionally a
securityissue field with a short description of the problem should be added to the data on the page of the plugin. This will create a red warning box and will delist the plugin from the main plugin list.
Once the issue was fixed and a new release was made, this field should be removed again.ja/devel/security.txt · 最終更新: 2008-08-09 18:42 by chi