chap19.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[
<!ENTITY BASEID "djangobook.chap19">
]>

<chapter lang="ru" id="&BASEID;">

  <title id="&BASEID;.title">
    Безопасность
  </title>

  <para>
    Данная глава временно взята из первой версии книги и подлежит
    корректировке. Вы можете помочь с этим!
  </para>

  <para>
    Перевод &copy; Попов Руслан &lt;radz &bull; yandex &bull; ru&gt;
  </para>

  <para>
    Интернет может быть страшным местом.
  </para>

  <para>
    В наши дни, high-profile security gaffes seem to crop up on a
    daily basis. Мы видели вирусы, распространяющиеся с огромной
    скоростью, рои взломанных компьютеров становились оружием,
    бесконечная гонка вооружений в войне со спаммерами, и множество
    сообщений о взломанных веб сайтах.
  </para>

  <para>
    Будучи веб разработчиками, мы имеем обязанность делать всё
    необходимое для противодействия этим силам тьмы. Каждый веб
    разработчик должен рассматривать безопасность в качестве
    фундаментального аспекта своей работы. К сожалению, реализовать
    безопасную среду <emphasis>сложно</emphasis> &mdash; хакерам
    достаточно найти единственную уязвимость, а защитникам надо
    закрыть каждую из них.
  </para>

  <para>
    Django пытается смягчить эту проблему. Оно спроектировано для
    автоматической защиты вашего проекта от большинства стандартных
    ошибок программирования, влияющих на безопасность, которые часто
    делают новые (и даже опытные) разработчики. Важно понимать в чём
    заключаются эти ошибки, как Django может защитить вам и, самое
    главное, что вы можете сделать для улучшения безопасности вашего
    кода.
  </para>

  <para>
    Несмотря на всё это, сначала сделаем важное заявление: Мы не
    пытаемся предоставить полное руководство для каждого известного
    эксплоита FIXME и, соответственно, мы не будем пытаться объяснить
    каждую уязвимость подробно. Вместо этого, мы будет предоставлять
    краткое описание проблем на примере Django.
  </para>

  <section id="&BASEID;.the-theme">

    <title id="&BASEID;.the-theme.title">
      Тема безопасности в вебе
    </title>

    <para>
      Если вы вынесите только одну вещь из этой главы, то пусть это
      будет &mdash; <quote>Никогда, ни при каких условиях, не
      доверяйте никаким данным полученным от пользователей</quote>.
    </para>

    <para>
      Вы <emphasis>никогда</emphasis> не будете знать, кто находится
      на другой стороне HTTP соединения. Это может быть один из ваших
      пользователей, но так же легко это может быть гнусный хакер,
      ищущий дыру в вашем сайте.
    </para>

    <para>
      Любые данных из любого формата, которые приходит от
      пользовательских браузеров, должны рассматриваться с достаточным
      объёмом паранойи. Под этими данными понимаются как
      <quote>внутренние</quote> (т.е., переданные через формы), так и
      <quote>внешние</quote> (т.е., HTTP заголовки, cookie и другая
      информация HTTP запроса). Нет никаких сложностей в подмене
      метаинформации запроса, которую браузеры автоматически добавляют
      к нему.
    </para>

    <para>
      Каждая из описываемых в данной главе уязвимостей происходит
      напрямую из-за доверия к данным, которые пришли по проводам и
      которые не были проверены перед их использованием. Вы должны
      постоянно спрашивать себя: <quote>Откуда пришли эти
      данные?</quote>
    </para>

  </section>

  <section id="&BASEID;.sql-injection">

    <title id="&BASEID;.sql-injection.title">
      Внедрение SQL
    </title>

    <para>
      <emphasis>SQL инъекция</emphasis> &mdash; это стандартная
      уязвимость, в которой атакующая сторона изменяет параметры веб
      страницы (такие как GET/POST данный или URL) для внедрения
      определённых кусков SQL запроса, которые наивное веб приложение
      выполняет напрямую над своей базой данных. Вероятно, это
      наиболее опасная и, к сожалению, наиболее часто встречающаяся
      уязвимость.
    </para>

    <para>
      Данная уязвимость чаще всего проявляется, когда SQL
      <emphasis>собирается</emphasis> вручную на основе
      пользовательского ввода. Например, представим создание функции
      для получения списка с контактной информацией с помощью страницы
      поиска. Для защиты данных об адресах электронной почты от
      спаммеров, мы будем требовать от пользователя ввода чьего-нибудь
      имени и будет предоставлять адрес для введённого имени:
      <screen>
	<![CDATA[
def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username
    # execute the SQL here...
	]]>
      </screen>

      <note>
	<para>
	  В данном примере, и в других подобных <quote><emphasis>не
	  делай так</emphasis></quote> примерах, мы намеренно опустим
	  большую часть кода, необходимого для работоспособности
	  описываемых функций. Мы не желаем, чтобы кто-нибудь
	  использовал такой код вне контекста данной главы.
	</para>
      </note>
    </para>

    <para>
      И хотя такой код не выглядит опасным, он таковым является.
    </para>

    <para>
      Во-первых, наша попытка защитить весь наш список адресов
      электронной почты провалится из-за хитро составленного
      запроса. Подумайте о том, что может случиться, если атакующий
      введёт <token>' OR 'a'='a</token> в поле запроса. В этом случае,
      будет сконструирован следующий запрос:
      <screen>
	<![CDATA[
SELECT * FROM user_contacts WHERE username = '' OR 'a' = 'a';
	]]>
      </screen>
    </para>

    <para>
      Так как мы не проверяем введённую строку на наличие SQL команд,
      атакующий добавил выражение <token>OR</token> и это приведёт к
      выдаче всех записей из соответствующей таблицы.
    </para>

    <para>
      Однако, существует <emphasis>как минимум ещё одна</emphasis>
      опасность. Представьте, что может случиться, если атакующий
      введёт <token>'; DELETE FROM user_contacts WHERE
      'a'='a'</token>. Вот так будет выглядеть сконструированный
      запрос:
      <screen>
	<![CDATA[
SELECT * FROM user_contacts WHERE username = '';
DELETE FROM user_contacts WHERE 'a' = 'a';
	]]>
      </screen>
    </para>

    <para>
      Ой! А куда делся наш список контактов?
    </para>

    <section id="&BASEID;.sql-injection.solution">

      <title id="&BASEID;.sql-injection.solution.title">
	Решение
      </title>

      <para>
	Несмотря на то, что данная проблема является неочевидной,
	решение для неё будет простым: <emphasis>никогда</emphasis> не
	доверяйте пользовательским данным и
	<emphasis>всегда</emphasis> экранируйте всё, что вы
	используете при конструировании SQL запроса.
      </para>

      <para>
	Всё это Django делает на уровне API для работы с базой
	данных. Он автоматически экранирует все специальные SQL
	параметры, учитывая соглашение об использовании кавычек для
	используемого вами сервера баз данных (т.е., PostgreSQL или
	MySQL).
      </para>

      <para>
	Например, в данном вызове API:
	<screen>
	  <![CDATA[
foo.get_list(bar__exact="' OR 1=1")
	  ]]>
	</screen>
	Django выполнит соответствующее экранирование и результирующий
	оператор будет выглядеть так:
	<screen>
	  <![CDATA[
SELECT * FROM foos WHERE bar = '\' OR 1=1'
	  ]]>
	</screen>
	т.е., очень безобидно.
      </para>

      <para>
	Это поведение характерно для всего API с некоторыми
	исключениями:
	<itemizedlist>
	  <listitem>
	    <para>
	      Аргумент <token>where</token> у метода
	      <function>extra()</function> (см. приложение
	      <quote><xref linkend="djangobook.appendix_c"
	      endterm="djangobook.appendix_c.title"/></quote>). Этот
	      параметр принимает <emphasis>сырой</emphasis> SQL, так
	      было заложено при его разработке).
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Вручную созданные запросы с помощью API низкого уровня.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	В каждом из этих случаев, несложно защитить себя от
	ошибок. Надо просто использовать <emphasis>привязку
	переменных</emphasis> вместо конструирования запросов. Таким
	образом, предыдущий пример должен быть переписан так:
	<screen>
	  <![CDATA[
from django.db import connection

def user_contacts(request):
    user = request.GET['username']
    sql = "SELECT * FROM user_contacts WHERE username = %s;"
    cursor = connection.cursor()
    cursor.execute(sql, [user])
    # ... do something with the results
	  ]]>
	</screen>
      </para>

      <para>
	Низкоуровневый метод <function>execute()</function> принимает
	с SQL строку с символами подстановки (<token>%s</token>) и
	автоматически экранирует и подставляет параметры из списка,
	переданного вторым аргументом. Вы должны
	<emphasis>всегда</emphasis> конструировать свои SQL запросы
	таким способом.
      </para>

      <para>
	К сожалению, вы не можете свободно использовать привязку
	переменных. Например, нельзя таким способом определять
	идентификаторы (т.е., имя таблицы или полей
	таблиц). Следовательно, если вам потребуется динамически
	создать список таблиц по, скажем, содержимому переменной
	<varname>POST</varname>, вам придётся экранировать их имена в
	своём коде. Django предоставляет функцию,
	<token>django.db.backend.</token><function>quote_name()</function>,
	которая осуществляет экранирование идентификатора в
	соответствии с принятой схемой квотирования для текущей базы
	данных.
      </para>

    </section>

  </section>

  <section id="&BASEID;.xss">

    <title id="&BASEID;.xss.title">
      Межсайтовый скриптинг (XSS)
    </title>

    <para>
      Данный тип уязвимости проявляется в веб приложениях, которые не
      производят экранирование информации, введённой пользователем,
      перед её помещением в HTML страницы. Это позволяет атакующему
      вставить определённый HTML код на вашу страницу, обычно это теги
      <![CDATA[<script>]]>.
    </para>

    <para>
      Злобные хакеры часто используют XSS для кражи cookie и
      информации о сессии или вводят пользователей в заблуждение,
      вынуждая их вводить важную информацию (так называемый
      <emphasis>фишинг</emphasis> &mdash; рыбалка).
    </para>

    <para>
      Данный тип атак может принимать различные формы и бесконечно
      изменяться, так что мы рассмотрим типичный случай. Рассмотрим
      чрезвычайно простое представление:
      <screen>
	<![CDATA[
def say_hello(request):
    name = request.GET.get('name', 'world')
    return render_to_response("hello.html", {"name" : name})
	]]>
      </screen>
    </para>

    <para>
      Это представление просто получает имя из параметра
      <token>GET</token> и передаёт его в шаблон
      <filename>hello.html</filename>, который может выглядеть так:
      <screen>
	<![CDATA[
<h1>Hello, {{ name }}!</h1>
	]]>
      </screen>
    </para>

    <para>
      Таким образом, если мы перейдём по URL
      <token>http://example.com/hello/name=Jacob</token>, то
      результатом будет страница, которая будет содержать:
      <screen>
	<![CDATA[
<h1>Hello, Jacob!</h1>
	]]>
      </screen>
    </para>

    <para>
      Подождите, а что произойдёт, если перейти на
      <token><![CDATA[http://example.com/hello/name=<i>Jacob</i>]]></token>?
      Тогда мы получим это:
      <screen>
	<![CDATA[
<h1>Hello, <i>Jacob</i>!</h1>
	]]>
      </screen>
    </para>

    <para>
      Конечно, хакеры не будут играть с тегами
      <token><![CDATA[<i>]]></token>, они могут включить набор HTML
      кодов, которые наполнят вашу страницу определённым
      содержимым. Этот тип атак используется для принуждения
      пользователей выдать, например, информацию о своём банковском
      счёте, которая затем отправляется атакующему.
    </para>

    <para>
      Проблема может стать ещё серьёзнее в случае, если вы сохраняете
      эти данные в базе данных и затем отображаете их на своём
      сайте. Например, на MySpace однажды нашли уязвимость, которая
      позволила провести атаку такого типа. Один пользователь вставил
      в свой профиль JavaScript, который автоматически добавлял этого
      пользователя в качестве друга, если кто-то посещал его страницу
      с профилем. За несколько дней у него появились миллионы друзей.
    </para>

    <para>
      Это может казаться несерьёзным, но следует помнить, что
      атакующий запустил <emphasis>свой</emphasis> код, не код
      MySpace, на <emphasis>вашем</emphasis> компьютере. Это нарушает
      предположение о том, что весь код на сайте MySpace действительно
      написан этой компанией.
    </para>

    <para>
      Компании MySpace очень повезло, что этот код не принялся
      автоматически удалять пользовательские аккаунты, изменять их
      пароли, заваливать сайт спамом или выполнять какой-нибудь ещё
      кошмарный сценарий, который позволяет данная уязвимость.
    </para>

    <section id="&BASEID;.xss.solution">

      <title id="&BASEID;.xss.solution.title">
	Решение
      </title>

      <para>
	Решение простое &mdash; <emphasis>всегда</emphasis>
	экранируйте <emphasis>любую</emphasis> информацию с помощью
	тега <token>escape</token> (или его эквивалента) при
	отображение на вашем сайте информации, введённой
	пользователем.

	<note>
	  <title>
	    Почему Django не делает это автоматически?
	  </title>

	  <para>
	    <quote>Пусть Django автоматически экранирует все
	    переменные, отображаемые в шаблонах</quote> &mdash; эта
	    тема достаточно часто возникает в листе рассылки
	    разработчиков.
	  </para>

	  <para>
	    Пока шаблонная система Django избегает такого поведения,
	    потому что при этом бы незаметно изменилось бы то, что
	    должно работать прямолинейно &mdash; отображать
	    переменные. Это очень хитрая задача, чтобы оценить её
	    реализацию. К тому же, добавление скрытого неявного
	    поведения идёт против основных идеалов Django (да и Python
	    тоже), но обеспечение безопасности также является важной
	    задачей.
	  </para>

	  <para>
	    Всё, что мы хотим этим сказать, &mdash; возможно
	    когда-нибудь Django дорастёт до некоторой формы
	    автоматического (или почти автоматического) экранирования
	    в будущем. Рекомендуем периодически проверять официальную
	    документацию на предмет нововведений. Она всегда будет
	    содержать более актуальную информацию, чем эта книга.
	  </para>

	  <para>
	    Даже если эта функциональность будет добавлена в Django,
	    вы <emphasis>всё ещё</emphasis> будете должны иметь
	    привычку спрашивать себя каждый раз &mdash; <quote>Откуда
	    пришли эти данные?</quote>. Никакое автоматическое решение
	    не защитит ваш сайт от XSS атак на 100%.
	  </para>
	</note>
      </para>

    </section>

  </section>

  <section id="&BASEID;.csrf">

    <title id="&BASEID;.csrf.title">
      Подделка HTTP запросов
    </title>

    <para>
      Атаки типа <quote>подделка HTTP запросов</quote> (CSRF)
      случаются когда вредоносный веб сайт принуждает пользователей
      неявно загружать URL с сайта, на котором они были
      аутентифицированы, а следовательно, пользуется их правами.
    </para>

    <para>
      Djagno обладает встроенными инструментами для защиты от этого
      типа атак. Сама атака и эти инструменты описаны в главе
      <quote><xref linkend="djangobook.chap14"
      endterm="djangobook.chap14.title"/></quote>.
    </para>

  </section>

  <section id="&BASEID;.session">

    <title id="&BASEID;.session.title">
      Подделка сессий
    </title>

    <para>
      Подделка сессий не является каким-то видом атаки, это целый
      класс атак, нацеленных на данные пользовательской сессии. Они
      могут принимать ряд различных форм:
      <itemizedlist>
	<listitem>
	  <para>
	    <emphasis>Человек посередине</emphasis> &mdash; атакующий
	    читает данные сессии в момент когда они проходят мимо него
	    по сети.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Подделка сессии</emphasis> &mdash; атакующий
	    использует идентификатор сессии (возможно полученный с
	    помощью атаки <quote>человек посередине</quote>) для того,
	    чтобы притвориться другим пользователем.
	  </para>

	  <para>
	    Примером этих двух форм будет ситуация когда атакующий,
	    сидя в кофейне, используя локальную WiFi сеть будет ловить
	    идентификаторы сессий. Затем эти идентификаторы будут
	    использоваться, чтобы представиться оригинальным
	    пользователем.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Подделка cookie</emphasis> &mdash; атакующий
	    переопределяет данные (они могут быть в режиме
	    <quote>только для чтения</quote>) в cookie. Глава
	    <quote><xref linkend="djangobook.chap12"
	    endterm="djangobook.chap12.title"/></quote> детально
	    описывает работу cookie, одной из ярких особенностей
	    которых является простота незаметного изменения
	    содержимого браузером или злонамеренными пользователями.
	  </para>

	  <para>
	    Существует длинная история о сайтах, которые хранили
	    cookie подобные <token>IsLoggedIn=1</token> или даже
	    <token>LoggedInAsUser=jacob</token>. Чрезвычайно просто
	    воспользоваться таким подарком.
	  </para>

	  <para>
	    Проще говоря, не стоит доверять данным, сохранённым в
	    cookie.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Фиксация сессии</emphasis> &mdash; атакующий
	    принуждает пользователя обновить идентификатор
	    пользовательской сессии.
	  </para>

	  <para>
	    Например, PHP позволяет передавать идентификаторы сессий
	    через URL (т.е.,
	    <token>http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32</token>). Атакующий
	    просто подставляет такой идентификатор в URL ссылки, на
	    которую нажмёт пользователь, заставляя последнего
	    подключиться к указанной сессии.
	  </para>

	  <para>
	    Фиксация сессии используется при <quote>рыбалке</quote>,
	    принуждая пользователя вводить свою персональную
	    информацию в аккаунт, которым владеет атакующий. Последний
	    может просмотреть свой аккаунт и получить введённые
	    данные.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Отравление сессии FIXME</emphasis> &mdash;
	    атакующий внедряет в пользовательскую сессию потенциально
	    опасные данные. Обычно это происходит при отправке форм,
	    которые использует пользователь для установки данных
	    сессии.
	  </para>

	  <para>
	    Каноническим примером будет сайт, который сохраняет
	    простые пользовательские настройки (подобные цвету фона
	    страницы) в cookie. Атакующий может подвести пользователя
	    к нажатию ссылки для отправки <quote>цвета</quote>,
	    который на самом деле содержит данные для XSS атаки. Если
	    переданные данные не экранируются на стороне сервера,
	    пользователь может снова внедрить вредоносный код в свою
	    среду.
	  </para>
	</listitem>
      </itemizedlist>
    </para>

    <section id="&BASEID;.session.solution">

      <title id="&BASEID;.session.solution.title">
	Решение
      </title>

      <para>
	Существует целый ряд основных принципов, следование которым
	может защитить вас от этих атак:
	<itemizedlist>
	  <listitem>
	    <para>
	      Никогда не позволяйте информации о сессии быть в URL.
	    </para>

	    <para>
	      Среда Django для работы с сессиями, описанная в главе
	      <quote><xref linkend="djangobook.chap12.session"
	      endterm="djangobook.chap12.session.title"/></quote>,
	      просто не позволяет так делать.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Не используйте данные в cookie напрямую. Вместо этого,
	      храните идентификатор сессии, которая в свою очередь
	      хранится в базе данных (например).
	    </para>

	    <para>
	      Если вы используете встроенную среду для работы с
	      сессиями (т.е., <token>request.session</token>), это
	      будет выполняться автоматически. Среда использует
	      единственный cookie, в котором хранится единственный
	      идентификатор сессии, а данные самой сессии хранятся в
	      базе данных.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Не забывайте экранировать данные сессии, если вы
	      отображаете их в шаблоне. Обратитесь к секции
	      <quote><xref linkend="&BASEID;.xss"
	      endterm="&BASEID;.xss.title"/></quote> и запомните, что
	      он применяется к любой информации, которую создал
	      пользователь, а также к любой информации, полученной от
	      браузера. Вы должны рассматривать информацию из сессии,
	      как информацию полученную от пользователя.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Не позволяйте атакующим перехватывать идентификаторы
	      сессий.
	    </para>

	    <para>
	      Несмотря на то, что практически невозможно определить
	      ситуацию, когда кто-то похитил идентификатор сессии,
	      Django обладает встроенным механизмом защиты от атак
	      прямого перебора идентификаторов сессии. Идентификатор
	      сессии хранится в виде хэша (а не в виде
	      последовательного числа), это затрудняет прямой перебор,
	      а пользователь всегда получает новый идентификатор
	      сессии, как только пытается использовать несуществующий
	      идентификатор, что помогает избежать фиксации сессии.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	Следует отметить, что ни один из этих принципов не защитит вас
	от атаки <quote>человек посередине</quote>. Этот тип атак
	практически невозможно распознать. Если ваш сайт позволяет
	авторизованным пользователям просматривать важные данные, вы
	должны <emphasis>всегда</emphasis> передавать их с помощью
	протокола HTTPS. Также, если ваш сайт использует SSL, вы
	должны назначить <token>True</token> значению
	<varname>SESSION_COOKIE_SECURE</varname> &mdash; это заставит
	Django отправлять cookie с идентификатор сессии по протоколу
	HTTPS.
      </para>

    </section>

  </section>

  <section id="&BASEID;.email">

    <title id="&BASEID;.email.title">
      Внедрение E-mail заголовка
    </title>

    <para>
      Внедрение SQL является менее известным аналогом
      <emphasis>внедрения Email заголовка</emphasis>, которое крадёт
      данные форм при их отправке на электронную почту. Атакующий
      может использовать эту методику для рассылки спама через ваш
      почтовый сервер. Любая форма, которая создаёт почтовые
      заголовки, используя введённые в форму данные, уязвима для
      данного типа атак.
    </para>

    <para>
      Давайте рассмотрим стандартную контактную форму, которую можно
      встретить на многих сайтах. Обычно, такая форма отсылает
      сообщение на жёстко определённый адрес и, следовательно, не
      подвержена уязвимости, через которую можно рассылать спам. Но
      это только на первый взгляд.
    </para>

    <para>
      Тем не менее, большинство таких форм также позволяют
      пользователю указать собственную тему для почтового сообщения (а
      также свой адрес, текст сообщения, иногда и что-нибудь
      ещё). Поле темы используется для генерации заголовка Subject для
      почтового сообщения.
    </para>

    <para>
      Если этот заголовок не экранируется во время генерации почтового
      сообщения, атакующий может отправить что-нибудь вида
      <token>hello\ncc:spamvictim@example.com</token> (где
      <token>\n</token> является символом перевода строки). Это может
      привести к созданию следующих заголовков:
      <screen>
	<![CDATA[
To: hardcoded@example.com
Subject: hello
cc: spamvictim@example.com
	]]>
      </screen>
    </para>

    <para>
      Аналогично внедрению SQL, если мы доверяем пользователю вводить
      строку для темы письма, мы позволяем ему создавать вредоносный
      набор заголовков и использовать нашу контактную форму для
      рассылки спама.
    </para>

    <section id="&BASEID;.email.solution">

      <title id="&BASEID;.email.solution.title">
	Решение
      </title>

      <para>
	Мы можем предотвратить такую атаку также как мы предотвращаем
	внедрение SQL &mdash; всегда экранируйте или проверяйте
	данные, которые вводит пользователь.
      </para>

      <para>
	Встроенные в Django функции отправки электронной почты
	(<token>django.core.mail</token>) просто не позволяют
	использовать символы перевода строки в любом из полей,
	используемых для создания заголовков (<token>from</token>,
	<token>to</token> и <token>subject</token>). Если вы
	попытаетесь использовать
	<token>django.core.mail.</token><function>send_mail()</function>
	совместно с полем <token>subject</token>, которое содержит
	символ перевода строки, то Django вызовет исключение
	<token>BadHeaderError</token>.
      </para>

      <para>
	Если вы не используете встроенные в Django функции для
	отправки электронной почты, вам потребуется проверять
	заголовки на наличие там символа перевода строки. При их
	наличии надо будет выдавать ошибку или тихо удалять их
	оттуда. Рекомендуем посмотреть на класс
	<classname>SafeMIMEText</classname> в
	<token>django.core.mail</token>.
      </para>

    </section>

  </section>

  <section id="&BASEID;.traversal">

    <title id="&BASEID;.traversal.title">
      Directory Traversal
    </title>

    <para>
      <emphasis>Directory Traversal FIXME</emphasis> является другим
      типом атак на внедрение своей информации. В этом случае
      злонамеренный пользователь принуждает систему прочитать и/или
      записать файлы, доступа к которым веб сервер иметь не должен.
    </para>

    <para>
      Примером может быть представление, которое читает файлы с диска
      без аккуратной проверки их имени:
      <screen>
	<![CDATA[
def dump_file(request):
    filename = request.GET["filename"]
    filename = os.path.join(BASE_PATH, filename)
    content = open(filename).read()

    # ...
	]]>
      </screen>
    </para>

    <para>
      Несмотря на то, что данное представление выглядит надёжным, так
      как доступ к файлу ограничен <varname>BASE_PATH</varname> и
      использованием
      <token>os.path.</token><function>join()</function>, если
      атакующий использует в имени файла символы <token>..</token>
      (переход в родительский каталог), он может получить доступ к
      файлам вне <varname>BASE_PATH</varname>. Имеет значение только
      время, которое придётся затратить на поиск правильного числа
      таких команд, скажем так:
      <filename>../../../../../etc/passwd</filename>.
    </para>

    <para>
      Любое представление, которое читает файлы без соответствующего
      экранирования их имён уязвимы для этого типа
      атак. Представления, которые <emphasis>пишут</emphasis> в файлы
      также уязвимы, но вот только последствия страшнее.
    </para>

    <para>
      Другой вариант FIXME??? этой проблемы находится в коде, который
      динамически подгружает модули, основываясь на URL или другой
      информации из запроса. Широко освещённый пример пришёл из мира
      Ruby on Rails. До середины 2006 года Rails напрямую использовал
      URL, подобные <token>http://example.com/person/poke/1</token>,
      для загрузки модулей и вызова методов. В результате получалось
      так, что специально созданный URL мог автоматически загружать
      определённый код, включая скрипт для очистки базы данных!
    </para>

    <section id="&BASEID;.traversal.solution">

      <title id="&BASEID;.traversal.solution.title">
	Решение
      </title>

      <para>
	Если ваш код действительно должен читать или записывать файлы,
	основываясь на вводе пользователя, вам потребуется проверять
	запрашиваемый путь очень аккуратно, чтобы удостовериться, что
	атакующий не имеет возможности выйти из базового каталога, к
	которому вы разрешили доступ.

	<note>
	  <para>
	    Даже не стоит говорить о том, что
	    <emphasis>нельзя</emphasis> создавать код, который может
	    читать файлы из любого места на диске.
	  </para>
	</note>
      </para>

      <para>
	Хорошим примером экранирования можно считать представления из
	<token>django.views.static</token>. Вот его примерный код:
	<screen>
	  <![CDATA[
import os
import posixpath

# ...

path = posixpath.normpath(urllib.unquote(path))
newpath = ''
for part in path.split('/'):
    if not part:
        # strip empty path components
        continue

    drive, part = os.path.splitdrive(part)
    head, part = os.path.split(part)
    if part in (os.curdir, os.pardir):
        # strip '.' and '..' in path
        continue

    newpath = os.path.join(newpath, part).replace('\\', '/')
	  ]]>
	</screen>
      </para>

      <para>
	Django не читает файлы (пока вы не начнёте использовать
	функцию <token>static.</token><function>serve()</function>),
	таким образом данная уязвимость не влияет на код Django.
      </para>

      <para>
	В дополнение скажем, что использование схемы URL означает, что
	Django <emphasis>никогда</emphasis> не загружает код, пока вы
	это явно не укажете. Не существует метода создать URL, который
	заставит Django загрузить что-то не указанное в схеме URL.
      </para>

    </section>

  </section>

  <section id="&BASEID;.error-messages">

    <title id="&BASEID;.error-messages.title">
      Открытые сообщения об ошибках
    </title>

    <para>
      Во время разработки наличие возможности просматривать
      трассировочную информацию и ошибки в браузере является
      чрезвычайно полезной. Django предоставляет
      <quote>красивые</quote> и информативные отладочные сообщения.
    </para>

    <para>
      Однако, если такие сообщения будут отображаться после
      развёртывания сайта, они могут раскрыть аспекты работы вашего
      кода или конфигурации сайта, которые могут помочь хакерам в их
      нелёгкой работе.
    </para>

    <para>
      Кроме того, сообщения об ошибках и трассировочная информация
      бесполезна для конечных пользователей. Философия Django состоит
      в том, что пользователи сайта никогда не должны видеть сообщения
      об ошибках, относящиеся к приложению. Если ваш код вызывает
      необработанное исключение, посетители сайта не должны увидеть
      трассировочную информацию, вообще ничего. Вместо этого
      посетители должны получить дружественное сообщение
      <quote>Страница недоступна</quote>.
    </para>

    <para>
      В действительности, разработчикам необходимо видеть отладочную
      информацию для отладки ошибок в их коде. Таким образом, среда
      разработки должна прятать все сообщения об ошибках от
      пользователей, но должна отображать их доверяемым разработчикам
      сайта.
    </para>

    <section id="&BASEID;.error-messages.solution">

      <title id="&BASEID;.error-messages.solution.title">
	Решение
      </title>

      <para>
	Django использует простой флаг, который управляет отображением
	сообщений об ошибках. Если параметр <varname>DEBUG</varname>
	установлен в <token>True</token>, то сообщения об ошибках
	будут отображаться в браузере. В противном случае, Django
	отобразит сообщение с ошибкой 500 (<quote>Internal server
	error</quote>), используя предоставленный вами для этого
	случая шаблон. Этот шаблон должен находиться в файле
	<filename>500.html</filename> и располагаться в корне одного
	из ваших шаблонных каталогов.
      </para>

      <para>
	Однако разработчикам потребуется получать сообщения об ошибках
	от развёрнутого на боевом сервере сайта. Для этого каждая
	ошибка будет отправляться с приложением полной трассировочной
	информации на почтовые адреса, указанные в параметре
	<varname>ADMINS</varname>.
      </para>

      <para>
	При использовании Apache в качестве веб сервера и
	<token>mod_python</token> необходимо проверить наличие
	следующей строки в файле конфигурации Apache:
	<screen>
	  <![CDATA[
PythonDebug Off
	  ]]>
	</screen>
	эта строка подавляет сообщения обо всех ошибках, которые
	возникают до передачи управления Django.
      </para>

    </section>

  </section>

  <section id="&BASEID;.final-word">

    <title id="&BASEID;.final-word.title">
      Заключительное слово о безопасности
    </title>

    <para>
      Мы надеемся, что всё рассказанное здесь не слишком испугало
      вас. Интернет может быть диким и опасным миром, но немного
      предусмотрительности может вам помочь.
    </para>

    <para>
      Просто запомните, что безопасность в Интернет является постоянно
      изменяющейся темой. Если вы читаете старую версию этой книги,
      вам следует обратить внимание на ресурсы в сети,
      специализирующиеся на защите информации, на предмет наличия
      любых новых уязвимостей. Будет хорошей идеей тратить некоторое
      время каждую неделю или месяц на изучение новостей в области
      безопасности. Эта небольшая инвестиция времени может бесценно
      помочь вашему сайту и вашим пользователям.
    </para>

  </section>

</chapter>