worldwide open-source software

Инструменты пользователя

Инструменты сайта

Вы посетили:
wiki:devel:security

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

Предыдущая версия справа и слеваПредыдущая версия
Следующая версия		Предыдущая версия
wiki:devel:security [2025/01/03 17:07] – [Security Guidelines for Plugin Authors] vladpolskiywiki:devel:security [2025/01/03 17:48] (текущий) – [Reporting Security Issues] vladpolskiy
Строка 18: Строка 18:
  
  
-===== Cross Site Scripting (XSS) =====+===== Межсайтовый скриптинг (XSS) =====
  
-This is probably the most common vulnerability to be found in DokuWiki plugins.+Это, вероятно, самая распространенная уязвимость, встречающаяся в плагинах DokuWiki.
  
-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.+Cross Site Scripting относится к атаке, при которой вредоносный код JavaScript внедряется на веб-сайт. Это может использоваться для перенаправления невинных пользователей на вредоносные веб-сайты или для кражи аутентификационных cookie-файлов.
  
-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 work with raw unprocessed output. This means the wiki page data which reaches your plugin has not been processed at all. And there will be no further processing on the output after it leaves your plugin.+Механизм плагинов DokuWiki дает разработчикам плагинов большую гибкость. В случае с плагинами синтаксиса, в частности, фреймворк дает плагинам возможность работать с сырым необработанным выводом. Это означает, что данные страницы вики, которые достигают вашего плагина, вообще не были обработаны. И не будет никакой дальнейшей обработки вывода после того, как он покинет ваш плагин.
  
-===Escaping output=== +===Выход из режима экранирования=== 
-At an absolute minimum the plugin should ensure any raw data output has all HTML special characters converted to HTML entities using the [[phpfn>htmlspecialchars()]] function. DokuWiki provides a convenient shortcut called [[xref>hsc()]] for the function. URLs values should be escaped using [[phpfn>rawurlencode()]].+Как минимум, плагин должен гарантировать, что все выходные необработанные данные будут содержать все специальные символы HTML , преобразованные в сущности HTML с помощью функции [[phpfn>htmlspecialchars()]]. DokuWiki предоставляет удобный ярлык [[xref>hsc()]] для этой функции. Значения URL-адресов следует экранировать с помощью [[phpfn>rawurlencode()]].
  
-Also any wiki data extracted and used internally (eg. user names) should be treated with suspicion.+Кроме того, следует с подозрением относиться к любым данным вики, извлеченным и используемым внутри компании (например, именам пользователей).
  
-===Input checking=== +===Проверка входных данных=== 
-Check always all your input. Use whitelists, filters, conversions to the exact data type you mean e.g. from a number inputted as mixed php value to integer and more to ensure you have __only__ data you allowed.+Всегда проверяйте все ваши входные данные. Используйте белые списки, фильтры, преобразования в точный тип данных, который вы имеете в виду, например, из числа, введенного как смешанное значение php, в целое число и т. д., чтобы убедиться, что у вас есть __только__ разрешенные вами данные.
  
-Please also refer to our chapter on processing [[request vars]] like ''_GET'', ''_POST'' or ''_SERVER''.+Также ознакомьтесь с нашей главой об обработке [[wiki:devel:request_vars|переменных запросов]], таких как ''_GET'', ''_POST'' или ''_SERVER''.
  
  
-==See also:==+==Смотрите также:==
  
-  * [[wp>Cross-site scripting]] +  * [[wp>Cross-site scripting|Межсайтовый скриптинг]] 
-  * [[http://ha.ckers.org/xss.html|XSS Cheat Sheet]]+  * FIXME[[http://ha.ckers.org/xss.html|Шпаргалка по XSS]]
  
-==== Typical Vulnerability Examples ====+==== Типичные примеры уязвимостей ====
  
-Below are some very common problems shown. The examples are very simple to make the general problem clear. Your plugin is probably more complicated, but you need to keep track of the same vulnerabilities.+Ниже показаны некоторые очень распространенные проблемы. Примеры очень просты, чтобы сделать общую проблему понятной. Ваш плагин, вероятно, сложнее, но вам нужно отслеживать те же уязвимости.
  
-=== Syntax Bodies ===+=== Синтаксис Тела ===
  
-Many simple syntax plugins will take some user input and format it in custom HTML.+Многие простые плагины синтаксиса принимают часть введенных пользователем данных и форматируют их в виде пользовательского HTML .
  
-Example: Here is a abridged syntax plugin to wrap a given input in a bold tag.+Пример: Вот плагин сокращенного синтаксиса, позволяющий выделить заданный ввод жирным шрифтом.
  
 <code php> <code php>
 class syntax_plugin_bold extends DokuWiki_Syntax_Plugin { class syntax_plugin_bold extends DokuWiki_Syntax_Plugin {
-    // common plugin functions ommited+    // общие функции плагина опущены
  
     public function connectTo($mode) {     public function connectTo($mode) {
Строка 66: Строка 66:
     public function render($format, Doku_Renderer $renderer, $data) {     public function render($format, Doku_Renderer $renderer, $data) {
         if($format != 'xhtml') return false;         if($format != 'xhtml') return false;
-        $renderer->doc .= '<b>' . $data[0] . '</b>';  // no escaping+        $renderer->doc .= '<b>' . $data[0] . '</b>';  // без экранирования
     }     }
 } }
 </code> </code>
  
-As you can see, the raw input data captured in the lexer pattern is just passed on to the render method, where no escaping at all is done. Malicious users could introduce what ever JavaScript and HTML code they want.+Как вы можете видеть, необработанные входные данные, захваченные в шаблоне лексера, просто передаются в метод рендеринга, где экранирование вообще не выполняется. Злонамеренные пользователи могут вводить любой код JavaScript и HTML , который они хотят.
  
-The fix is simple: proper escaping.+Решение простое: правильный побег.
  
 <code php> <code php>
 class syntax_plugin_bold extends DokuWiki_Syntax_Plugin { class syntax_plugin_bold extends DokuWiki_Syntax_Plugin {
-    // common plugin functions ommited+    // общие функции плагина опущены
  
     public function connectTo($mode) {     public function connectTo($mode) {
Строка 89: Строка 89:
     public function render($format, Doku_Renderer $renderer, $data) {     public function render($format, Doku_Renderer $renderer, $data) {
         if($format != 'xhtml') return false;         if($format != 'xhtml') return false;
-        $renderer->doc .= '<b>' . htmlspecialchars($data[0]) . '</b>'; //escaping+        $renderer->doc .= '<b>' . htmlspecialchars($data[0]) . '</b>'; //экранирование 
     }     }
 } }
 </code> </code>
  
-=== Forms ===+=== Формы ===
  
-When your plugin provides a form it is very common to validate the input and redisplay the form with the received user input when a validation error occurs.+Когда ваш плагин предоставляет форму, очень часто требуется проверить вводимые данные и повторно отобразить форму с полученными данными пользователя в случае возникновения ошибки проверки.
  
-Example: The following shows a form vulenerable to an XSS attack because it does not escape the user provided input correctly:+Пример: ниже показана форма, уязвимая для атаки XSS, поскольку она не экранирует правильно введенные пользователем данные:
  
 <code php> <code php>
 <form action="" method="post"> <form action="" method="post">
     <input type="text" name="q" value="<?php echo $_REQUEST['q']?>" />      <input type="text" name="q" value="<?php echo $_REQUEST['q']?>" /> 
-    <input type="submit" />                     //no escaping+    <input type="submit" />                     //без экранирования
 </form> </form>
 </code> </code>
  
-Providing ''%%"><script>alert('bang')</script>%%'' as user input would exploit the vulnerability.+Предоставление данных ''%%"><script>alert('bang')</script>%%'' в качестве входных данных пользователя приведет к эксплуатации уязвимости.
  
-To fix the form use the [[phpfn>htmlspecialchars|htmlspecialchars()]] or DokuWiki shortcut [[xref>hsc|hsc()]] function:+Для исправления формы используйте функцию [[phpfn>htmlspecialchars|htmlspecialchars()]] или функцию DokuWiki shortcut [[wiki:xref:hsc|hsc()]]:
  
 <code php> <code php>
 <form action="" method="post"> <form action="" method="post">
     <input type="text" name="q" value="<?php echo hsc($_REQUEST['q'])?>" />     <input type="text" name="q" value="<?php echo hsc($_REQUEST['q'])?>" />
-    <input type="submit" />                                      //escaping+    <input type="submit" />                                      //экранирование
 </form> </form>
 </code> </code>
  
-In general it is recommended to not hand-craft forms, but use DokuWiki's [[form|form library]].+В целом рекомендуется не создавать формы вручную, а использовать [[wiki:devel:form|библиотеку форм]] DokuWiki .
  
-=== Classes and other Attributes ===+=== Классы и другие атрибуты ===
  
-Often plugins will accept multiple parameters and options that are used to modify the output of the plugin.+Часто плагины принимают несколько параметров и опций, которые используются для изменения выходных данных плагина.
  
-Imagine a plugin accepting the following input to display a message box:+Представьте себе плагин, принимающий следующие входные данные для отображения окна сообщения:
  
 <code> <code>
Строка 130: Строка 130:
 </code> </code>
  
-In the render method of this syntax there might be code like this:+В методе рендеринга этого синтаксиса может быть такой код:
  
 <code php> <code php>
-$renderer->doc .= '<div class="msg_' . $class . '">'  //$class can be everything+$renderer->doc .= '<div class="msg_' . $class . '">'  //$class может быть чем угодно 
                        . htmlspecialchars($message)                        . htmlspecialchars($message)
                 . '</div>';                 . '</div>';
Строка 139: Строка 139:
 </code> </code>
  
-As you can see the message itself is properly escaped, but the class is not. Instead of escaping it might be more sensible to use a whitelist of allowed classes instead with a default fallback:+Как вы видите, само сообщение правильно экранировано, но класс — нет. Вместо экранирования может быть разумнее использовать белый список разрешенных классов с резервным вариантом по умолчанию::
  
 <code php> <code php>
-$allowed = ['notice', 'info', 'warning', 'error'];   // whitelist+$allowed = ['notice', 'info', 'warning', 'error'];   // белый список 
 if(!in_array($class, $allowed){                          if(!in_array($class, $allowed){                         
-    $class = 'notice'; // unknown input, fall back to a sane default+    $class = 'notice'; // неизвестный ввод, вернуться к разумному значению по умолчанию
 } }
 $renderer->doc .= '<div class="msg_' . $class . '">' $renderer->doc .= '<div class="msg_' . $class . '">'
Строка 151: Строка 151:
 </code> </code>
  
-===input URLs ===+===входные URL-адреса ===
  
-When a plugin accepts URLs as input you need to make sure, users can not pass the ''%%javascript://%%'' pseudo protocol.+Когда плагин принимает URL-адреса в качестве входных данных, необходимо убедиться, что пользователи не смогут передать ''%%javascript://%%'' псевдо-протокол.
  
-Here is an example how a very simple check could look like, to make sure only http and https URLs are used.+Вот пример того, как может выглядеть очень простая проверка, позволяющая убедиться, что используются только URL-адреса http и https.
  
 <code php> <code php>
-// empty URL on protocol mismatch+// пустой URL при несоответствии протокола 
 if(!preg_match('/^https?:\/\//i', $url)) { if(!preg_match('/^https?:\/\//i', $url)) {
     $url = '';     $url = '';
Строка 164: Строка 164:
 </code> </code>
  
-===== Cross Site Request Forgery (CSRF) =====+===== Подделка межсайтовых запросов (CSRF) =====
  
-This vulnerability often appears into plugins due to the lack of understanding of this issue, often confused with the XSS.+Эта уязвимость часто появляется в плагинах из-за отсутствия понимания этой проблемы, ее часто путают с XSS.
  
-Cross Site Request Forgery refers to an attack where the victim's browser is tricked by a malicious site to ask for a page on a vulnerable site to do an unwanted action. The attack assumes the victim's browser has credentials to change something on the vulnerable site.+Подделка межсайтовых запросов относится к атаке, при которой вредоносный сайт обманывает браузер жертвы, запрашивая страницу на уязвимом сайте для выполнения нежелательного действия. Атака предполагает, что браузер жертвы имеет учетные данные для изменения чего-либо на уязвимом сайте.
  
-===Adding security token===+===Добавление токена безопасности===
  
-DokuWiki offers functions to help you deal against CSRF attacks. [[xref>getSecurityToken()]] will create a token that should be used to protect any authenticated action. It has to be included in links or forms triggering that action. All forms created with the [[form|form library]] will have security tokens added automatically, for handcrafted forms the [[xref>formSecurityToken()]] function can be used.+DokuWiki предлагает функции, которые помогут вам бороться с атаками CSRF. [[https://codesearch.dokuwiki.org/xref/dokuwiki/inc/common.php?r=&mo=3231&fi=116#116|getSecurityToken()]] создаст токен, который следует использовать для защиты любого аутентифицированного действия. Он должен быть включен в ссылки или формы, запускающие это действие. Все формы, созданные с помощью [[wiki:devel:form|библиотеки форм]] будут иметь автоматически добавленные токены безопасности, для форм, созданных вручную, можно использовать функцию [[https://codesearch.dokuwiki.org/xref/dokuwiki/inc/common.php?r=&mo=4438&fi=157#157|formSecurityToken()]].
  
  
-It is your resposibility as the plugin author to actually check the token before executing authorized actions using the [[xref>checkSecurityToken()]] function.+Вы как автор плагина несете ответственность за фактическую проверку токена перед выполнением авторизованных действий с использованием функции [[https://codesearch.dokuwiki.org/xref/dokuwiki/inc/common.php?r=&mo=3783&fi=133#133|checkSecurityToken()]].
  
 ==See also== ==See also==
  
-  * [[wp>Cross Site Request Forgery]] +  * [[wp>Cross Site Request Forgery|Подделка межсайтовых запросов]] 
-  * [[https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29|OWASP explanation]]+  * [[https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29|Объяснение OWASP]]
  
-==== Typical Vulnerability Example ====+==== Типичный пример уязвимости ====
  
-Below is the simplest example to start. You may have a more complicated plugin of your own to secure, here is just a simple example based on form.+Ниже приведен простейший пример для начала. У вас может быть более сложный плагин для защиты, вот простой пример на основе формы.
  
-Imagine you want to know something which can be answered to Yes or No, you would have a form of this type:+Представьте, что вы хотите узнать что-то, на что можно ответить «Да» или «Нет», у вас получится форма такого типа:
  
 <code html> <code html>
Строка 196: Строка 196:
 </code> </code>
  
-Then you process this form as follows:+Затем вы обрабатываете эту форму следующим образом:
  
 <code php> <code php>
Строка 206: Строка 206:
 </code> </code>
  
-So a user is connected to answer this question, but he doesn't know the response yet. Let's take time to think and browse the web... +Итак, пользователь подключен, чтобы ответить на этот вопрос, но он пока не знает ответа. Давайте уделим время размышлениям и просмотрим веб-страницы… Теперь пользователь посещает вредоносный веб-сайт, который знает или нет, что пользователь может быть подключен к вашему DokuWiki. На этом веб-сайте разработчик включил этот HTML- тег изображения:
-Now the user is visiting a malicious website, one which know, or not, that the user may be connected to your DokuWiki. In this website, the developer included this HTML image tag:+
  
 <code html> <code html>
Строка 213: Строка 212:
 </code> </code>
  
-What will the user's browser do then?+Что тогда будет делать браузер пользователя?
  
-The browser will process this image as any other and will send a request to this URL. Your plugin will then see that ''$_GET['yn']'' is set and will call the ''do_something_with_yn()'' function.+Браузер обработает это изображение как любое другое и отправит запрос на этот URL . Ваш плагин увидит, что ''$_GET['yn']'' установлено, и вызовет ''do_something_with_yn()'' функцию.
  
-That's one of the examples of CSRF. Now, how to fix this security hole?+Это один из примеров CSRF. Теперь, как исправить эту дыру в безопасности?
  
-==== Prevent CSRF ====+==== Предотвращение CSRF-атак ====
  
-Remember your form above? Let's add an input in it:+Помните вашу форму выше? Давайте добавим в нее ввод:
  
 <code html> <code html>
Строка 232: Строка 231:
 </code> </code>
  
-Do you see the first input? Yes? Good. Now you have to check the security token when you receive the form, before processing it:+Видите первый ввод? Да? Хорошо. Теперь вам нужно проверить токен безопасности при получении формы, перед ее обработкой:
  
 <code php> <code php>
Строка 242: Строка 241:
 </code> </code>
  
-As the malicious website will never find the value of the "sectok" hidden input, your form is no longer vulnerable to CSRF.+Поскольку вредоносный веб-сайт никогда не найдет значение скрытого ввода «sectok», ваша форма больше не уязвима для CSRF.
  
-**Note:** If the security token is not valid, the ''checkSecurityToken()'' function displays a message which informs the user.+**Примечание**: Если токен безопасности недействителен, ''checkSecurityToken()'' функция отображает сообщение, информирующее пользователя.
  
  
  
-===== Remote Code Inclusion =====+===== Удаленное включение кода =====
  
-This attack allows an attacker to inject (PHP) code into your application. This may occur on including files, or using unsafe operations functions like [[phpfn>eval()]] or [[phpfn>system()]].+Эта атака позволяет злоумышленнику внедрить код (PHP) в ваше приложение. Это может произойти при включении файлов или использовании небезопасных функций операций, таких как [[phpfn>eval()]] или [[phpfn>system()]].
  
-**Always filter any input** that will be used to load files or that is passed as an argument to external commands.+**Всегда фильтруйте любые входные данные**, которые будут использоваться для загрузки файлов или которые передаются в качестве аргумента внешним командам.
  
-===== Information leaks =====+===== Утечка информации =====
  
-This attack may lead to the exposure of files that should usually be protected by DokuWiki's ACL or it might expose files on the server (like ''/etc/passwd'').+Эта атака может привести к раскрытию файлов, которые обычно должны быть защищены ACL DokuWiki , или может раскрыть файлы на сервере (например, ''/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**.+**Всегда используйте функции проверки ACL DokuWiki при доступе к данным страницы.**
  
-===== SQL injection =====+===== 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.+Эта атака редко актуальна в DokuWiki, поскольку база данных не используется. Однако, если ваш плагин обращается к базе данных, всегда экранируйте все значения перед их использованием в операторах SQL.
  
-More info:+Дополнительная информация:
  
-  * [[wp>SQL injection]]+  * [[wp>SQL injection|SQL-инъекция]]
  
  
-===== Reporting Security Issues =====+===== Сообщение о проблемах безопасности =====
  
-If you encounter an issue with a plugin please inform the author of the plugin via email, optionally putting [[andi@splitbrain.org|Andi]] or the [[:mailinglist]] on CC.+Если у вас возникли проблемы с плагином, сообщите об этом автору плагина по электронной почте, при желании указав [[andi@splitbrain.org|Andi]] or the [[wiki:mailinglist|список рассылки]] on CC.
  
-Additionally a ''securityissue'' field with a short description of the problem should be added to the [[plugin:repository|data]] on the page of the plugin. This will create a red warning box and will delist the plugin from the main plugin list.+Дополнительно к [[wiki:lugin:repository|данным]] на странице плагина ''securityissue'' следует добавить поле с кратким описанием проблемы . Это создаст красное предупреждающее поле и исключит плагин из основного списка плагинов.
  
-Once the issue was fixed and a new release was made, this field should be removed again.+После устранения проблемы и выпуска новой версии это поле следует снова удалить.
wiki/devel/security.1735913270.txt.gz · Последнее изменение: — vladpolskiy