1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
#use wml::debian::translation-check translation="1d1c1ba842e225bf68a6fed5744786cc779234f7" maintainer="Lev Lamberov"
<define-tag description>обновление безопасности LTS</define-tag>
<define-tag moreinfo>
<p>В Django были обнаружены многочисленные проблемы безопасности:
<a href="https://www.djangoproject.com/weblog/2015/jan/13/security/">https://www.djangoproject.com/weblog/2015/jan/13/security/</a></p>
<p>В Debian 6 Squeeeze они были исправлены в версии 1.2.3-3+squeeze12
пакета python-django. Разработчики основной ветки разработки описывают эти
проблемы следующим образом:</p>
<ul>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0219">CVE-2015-0219</a>
<p>- Подделка заголовка WSGI из-за объединения символов подчёркивания/тире</p>
<p>Когда заголовки HTTP помещаются в окружение WSGI, они
нормализуются путём преобразования букв в верхних регистр, преобразования всех тире в
подчёркивания, и добавления префикса HTTP_. Например, заголовок X-Auth-User
в окружении WSGI стал бы HTTP_X_AUTH_USER (и в Django словаре
request.META).</p>
<p>К сожалению, это означает, что окружение WSGI не различает
заголовки, содержащие тире, и заголовки, содержащие подчёркивания:
X-Auth-User и X-Auth_User оба становятся HTTP_X_AUTH_USER. Это означает,
что если какой-то заголовок используется важным для безопасности образом (например,
передача аутентификационной информации от внешнего прокси), даже
если прокси очищает входящее значение X-Auth-User, злоумышленник
может оказаться способным предоставить заголовок X-Auth_User (с
подчёркиванием) и обойти эту защиту.</p>
<p>Для того, чтобы предотвратить подобные атаки, и Nginx, и Apache 2.4+ по умолчанию
выполняют очистку заголовков, содержащих подчёркивания, в исходящих
запросах. Встроенный сервер Django, используемый для нужд разработки, теперь делает то же самое.
Не рекомендуется использовать этот сервер Django для важных проектов,
но соответствующее поведение общих серверов снижает
изменение поведения при развёртывании.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0220">CVE-2015-0220</a>
<p>- Возможная XSS-атака через передаваемые пользователем URL перенаправлений</p>
<p>В некоторых случаях Django полагается на пользовательские входные данные (например,
django.contrib.auth.views.login() и i18n) для перенаправления пользователя на
URL, отмеченную как <q>при успехе</q>. Проверки безопасности для этих перенаправлений (а именно
django.util.http.is_safe_url()) не выполняют очистку символов пробела
в тестируемых URL, поэтому URL вида "\njavascript:..." считаются безопасными. Если
разработчик полагается на is_safe_url() в плане предоставления безопасных целей для
перенаправления и помещает такие URL в ссылку, то они могут быть подвержены XSS-атакам.
Эта ошибка в настоящее время на актуальна для Django, поскольку мы лишь помещаем URL
в заголовок ответа Location, а браузеры в них игнорируют
код JavaScript.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0221">CVE-2015-0221</a>
<p>- Отказ в обслуживании в django.views.static.serve</p>
<p>В предыдущих версиях Django вид django.views.static.serve() считывал
передаваемые файлы по одной строке за раз. Поэтому большой файл без символов
новой строки приводил к использованию объёма памяти равного этому файлу.
Злоумышленник может использовать эту проблему и вызвать отказ в обслуживании
путём одновременного запроса множества больших файлов. Теперь указанный вид выполняет чтение
файла по кускам, что предотвращает использование большого количества памяти.</p>
<p>Тем не менее, заметьте, что этот вид содержит предупреждение о том, что он
недостаточно безопасен для использования в серьёзных проектах и должен использоваться только с
целью разработки. Следует провести аудит ваших проектов и
передавать ваши файлы через полноценный внешний
веб-сервер.</p></li>
</ul>
<p>Заметьте, что версия Django, используемая в Debian 6 Squeeze, не
подвержена <a href="https://security-tracker.debian.org/tracker/CVE-2015-0222">CVE-2015-0222</a> (Отказ в обслуживании в базе данных с
ModelMultipleChoiceField), поскольку эта возможность отсутствует
в данной версии.</p>
<p>В Debian 6 <q>Squeeze</q> эти проблемы были исправлены в пакете python-django версии 1.2.3-3+squeeze12</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/lts/security/2015/dla-143.data"
# $Id$
|
