[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[DONE] wml://{security/2015/dla-143.wml}

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- --- english/security/2015/dla-143.wml	2016-04-09 01:32:24.000000000 +0500
+++ russian/security/2015/dla-143.wml	2016-06-07 14:32:17.696832908 +0500
@@ -1,80 +1,81 @@
- -<define-tag description>LTS security update</define-tag>
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+<define-tag description>обновление безопаÑ?ноÑ?Ñ?и LTS</define-tag>
 <define-tag moreinfo>
- -<p>Multiple security issues have been found in Django:
+<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>For Debian 6 Squeeeze, they have been fixed in version 1.2.3-3+squeeze12
- -of python-django. Here is what the upstream developers have to say about
- -those issues:</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 header spoofing via underscore/dash conflation</p>
+<p>- Ð?одделка заголовка WSGI из-за обÑ?единениÑ? Ñ?имволов подÑ?Ñ?Ñ?киваниÑ?/Ñ?иÑ?е</p>
 
- -    <p>When HTTP headers are placed into the WSGI environ, they are
- -    normalized by converting to uppercase, converting all dashes to
- -    underscores, and prepending HTTP_. For instance, a header X-Auth-User
- -    would become HTTP_X_AUTH_USER in the WSGI environ (and thus also in
- -    Django's request.META dictionary).</p>
- -
- -    <p>Unfortunately, this means that the WSGI environ cannot distinguish
- -    between headers containing dashes and headers containing underscores:
- -    X-Auth-User and X-Auth_User both become HTTP_X_AUTH_USER. This means
- -    that if a header is used in a security-sensitive way (for instance,
- -    passing authentication information along from a front-end proxy), even
- -    if the proxy carefully strips any incoming value for X-Auth-User, an
- -    attacker may be able to provide an X-Auth_User header (with
- -    underscore) and bypass this protection.</p>
- -
- -    <p>In order to prevent such attacks, both Nginx and Apache 2.4+ strip
- -    all headers containing underscores from incoming requests by
- -    default. Django's built-in development server now does the same.
- -    Django's development server is not recommended for production use,
- -    but matching the behavior of common production servers reduces the
- -    surface area for behavior changes during deployment.</p></li>
+    <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>- Possible XSS attack via user-supplied redirect URLs</p>
+<p>- Ð?озможнаÑ? XSS-аÑ?ака Ñ?еÑ?ез пеÑ?едаваемÑ?е полÑ?зоваÑ?елем URL пеÑ?енапÑ?авлений</p>
 
- -    <p>Django relies on user input in some cases (e.g.
- -    django.contrib.auth.views.login() and i18n) to redirect the user to an
- -    <q>on success</q> URL. The security checks for these redirects (namely
- -    django.util.http.is_safe_url()) didn't strip leading whitespace on the
- -    tested URL and as such considered URLs like "\njavascript:..." safe. If
- -    a developer relied on is_safe_url() to provide safe redirect targets
- -    and put such a URL into a link, they could suffer from a XSS attack.
- -    This bug doesn't affect Django currently, since we only put this URL
- -    into the Location response header and browsers seem to ignore
- -    JavaScript there.</p></li>
+    <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>- Denial-of-service attack against django.views.static.serve</p>
+<p>- Ð?Ñ?каз в обÑ?лÑ?живании в django.views.static.serve</p>
 
- -    <p>In older versions of Django, the django.views.static.serve() view read
- -    the files it served one line at a time. Therefore, a big file with no
- -    newlines would result in memory usage equal to the size of that file.
- -    An attacker could exploit this and launch a denial-of-service attack
- -    by simultaneously requesting many large files. This view now reads the
- -    file in chunks to prevent large memory usage.</p>
- -
- -    <p>Note, however, that this view has always carried a warning that it is
- -    not hardened for production use and should be used only as a
- -    development aid. Now may be a good time to audit your project and
- -    serve your files in production using a real front-end web server if
- -    you are not doing so.</p></li>
+    <p>Ð? пÑ?едÑ?дÑ?Ñ?иÑ? веÑ?Ñ?иÑ?Ñ? Django вид django.views.static.serve() Ñ?Ñ?иÑ?Ñ?вал
+    пеÑ?едаваемÑ?е Ñ?айлÑ? по одной Ñ?Ñ?Ñ?оке за Ñ?аз. Ð?оÑ?Ñ?омÑ? болÑ?Ñ?ой Ñ?айл без Ñ?имволов
+    новой Ñ?Ñ?Ñ?оки пÑ?иводил к иÑ?полÑ?зованиÑ? обÑ?Ñ?ма памÑ?Ñ?и Ñ?авного Ñ?Ñ?омÑ? Ñ?айлÑ?.
+    Ð?лоÑ?мÑ?Ñ?ленник можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? пÑ?облемÑ? и вÑ?зваÑ?Ñ? оÑ?каз в обÑ?лÑ?живании
+    пÑ?Ñ?Ñ?м одновÑ?еменного запÑ?оÑ?а множеÑ?Ñ?ва болÑ?Ñ?иÑ? Ñ?айлов. ТепеÑ?Ñ? Ñ?казаннÑ?й вид вÑ?полнÑ?еÑ? Ñ?Ñ?ение
+    Ñ?айла по кÑ?Ñ?кам, Ñ?Ñ?о пÑ?едоÑ?вÑ?аÑ?аеÑ? иÑ?полÑ?зование болÑ?Ñ?ого колиÑ?еÑ?Ñ?ва памÑ?Ñ?и.</p>
+
+    <p>Тем не менее, замеÑ?Ñ?Ñ?е, Ñ?Ñ?о Ñ?Ñ?оÑ? вид Ñ?одеÑ?жиÑ? пÑ?едÑ?пÑ?еждение о Ñ?ом, Ñ?Ñ?о он
+    недоÑ?Ñ?аÑ?оÑ?но безопаÑ?ен длÑ? иÑ?полÑ?зованиÑ? в Ñ?еÑ?Ñ?Ñ?знÑ?Ñ? пÑ?оекÑ?аÑ? и должен иÑ?полÑ?зоваÑ?Ñ?Ñ?Ñ? Ñ?олÑ?ко Ñ?
+    Ñ?елÑ?Ñ? Ñ?азÑ?абоÑ?ки. СледÑ?еÑ? пÑ?овеÑ?Ñ?и аÑ?диÑ? ваÑ?иÑ? пÑ?оекÑ?ов и
+    пеÑ?едаваÑ?Ñ? ваÑ?и Ñ?айлÑ? Ñ?еÑ?ез полноÑ?еннÑ?й внеÑ?ний
+    веб-Ñ?еÑ?веÑ?.</p></li>
 
 </ul>
 
- -<p>Note that the version of Django in use in Debian 6 Squeeze was not
- -affected by <a href="https://security-tracker.debian.org/tracker/CVE-2015-0222";>CVE-2015-0222</a> (Database denial-of-service with
- -ModelMultipleChoiceField) since that feature does not exist
- -in this version.</p>
+<p>Ð?амеÑ?Ñ?Ñ?е, Ñ?Ñ?о веÑ?Ñ?иÑ? Django, иÑ?полÑ?зÑ?емаÑ? в Debian 6 Squeeze, не
+подвеÑ?жена <a href="https://security-tracker.debian.org/tracker/CVE-2015-0222";>CVE-2015-0222</a> (Ð?Ñ?каз в обÑ?лÑ?живании в базе даннÑ?Ñ? Ñ?
+ModelMultipleChoiceField), поÑ?колÑ?кÑ? Ñ?Ñ?а возможноÑ?Ñ?Ñ? оÑ?Ñ?Ñ?Ñ?Ñ?Ñ?вÑ?еÑ?
+в данной веÑ?Ñ?ии.</p>
 
- -<p>For Debian 6 <q>Squeeze</q>, these issues have been fixed in python-django version 1.2.3-3+squeeze12</p>
+<p>Ð? Debian 6 <q>Squeeze</q> Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ? в пакеÑ?е python-django веÑ?Ñ?ии 1.2.3-3+squeeze12</p>
 </define-tag>
 
 # do not modify the following line
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXVpSlAAoJEF7nbuICFtKll4EQAKHQ9B20DFWPfiAIsAwOuSUG
XoK9y7yseG3pOlX4XW+XMiYLmS1p1oJNZcRnQqfX7HjC3pwKy8Gxv5WOvCQl8Lku
diIge0azBDgtTIM+6LRWIbkHkSa+yY7KIR3Ou1Ps58pmDN3yLMHiZQb03WaUG9nI
3DryBDXRRLSIKamS4knn8I6P8QaOxxpySQjCXkU70oFqcmvFm7mxsI2BicoNvu54
45zPQZTlbQcDWEh0p6r9xi8FE+5VEr6SMFiUKhvRUL5bMa/tRzCjdvZkdK7M/0E6
YzBV/ytn8VY0OwzkCNXF6dPB5sL0TzUHaHrjAeSn/OYSGaZ3WQFRipcdHXre7tdP
IakXbODM/A+cx60p09M/RqcwUb2BKZJcL/0OZGrj/Yn7q2vVxyDfZr+JTtzjnKRA
bsH4Xn4iVHmFHQmXM4HF5yNHyJiGHwbgxWWhusGizFzfworkCCyw08H5jREYqvNi
to5732NQBsv5W3He0JcrCZwwj2u1UYYnNjLSQ9zoBJWDGPv9acCdzHQnTqr9lYYx
UfSUr5mWSgpWYuSF95zo/pCPxUGCHereRBGSBpw6aDSREO8VDMbufkbEttz/8ofG
M7BtV2veYVrs167+7v2B/9iLE4cDvywhDnhKtKhRCu6O4OgwJiUfsWwMk5glHnqr
TvSPMxYXChcI9mubCay8
=52Dh
-----END PGP SIGNATURE-----
Reply to: