хешируется алгоритмом, о котором договорились стороны (чаще всего это MD5). Полученный хеш добавляется к каждому фрагменту в виде кода аутентификации сообщения (Message Authetication Code, MAC). Сжатый фрагмент вместе с MAC кодируется согласованным алгоритмом с симметричным ключом (обычно это суммирование по модулю 2 с ключевым потоком RC4). Наконец, присоединяется заголовок фрагмента, и тот передается по TCP-соединению как обычно.

Здесь стоит отметить следующее. Как уже упоминалось, в RC4 используется ряд слабых ключей, которые легко взламываются, поэтому сочетание SSL и RC4 уже давно считается не слишком надежным (Флюрер и др.; Fluhrer et al., 2001). Браузеры, позволяющие пользователю выбирать набор шифров, нужно настраивать на постоянное использование тройного DES со 168-разрядными ключами и SHA-2, невзирая на то что такая комбинация работает медленнее, чем RC4 c MD5. Еще лучше — перейти на браузеры, поддерживающие TLS (преемник SSL, описанный ниже).

С SSL связана еще одна проблема: у Алисы и Боба может не быть сертификатов. К тому же они не всегда проверяют ключи на соответствие сертификатам, даже располагая последними.

В 1996 году корпорация Netscape Communications направила SSL на стандартизацию в IETF. Результатом стал стандарт TLS. Он описан в RFC 5246.

TLS основан на 3-й версии протокола SSL. Хотя разница между ними сравнительно небольшая, все же отличий достаточно для того, чтобы SSL версии 3 и TLS были несовместимы. Например, в целях усиления ключа сеанса (усложнения его дешифровки) был изменен способ его вычисления по подготовительному ключу и нонсам. Из-за этой несовместимости большинство браузеров применяют оба протокола, и TLS превращается обратно в SSL, если нужно. Этот подход называется SSL/TLS. Первая реализация протокола TLS увидела свет в 1999 году, после чего в августе 2008 года появилась версия 1.2, а в марте 2018 года — версия 1.3. TLS поддерживает более сильные наборы шифров (в частности, AES), а также шифрование полей указания имени сервера (Server Name Indication, SNI), которые можно использовать для идентификации веб-сайта, посещаемого пользователем (в случае их передачи в виде открытого текста).

8.12.4. Выполнение недоверенного кода

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

Использование скриптов в браузере

Поначалу веб-страницы представляли собой статичные HTML-файлы без исполняемого кода. Теперь же они, как правило, содержат небольшие программы, обычно написанные на языке JavaScript (и иногда скомпилированные в более эффективный формат Web Assembly). Поскольку скачивание и выполнение такого переносимого кода (mobile code) очевидным образом угрожает безопасности, были разработаны различные методы минимизации рисков.

У JavaScript нет формальной модели политики безопасности, зато есть длинная история реализаций с проблемами конфиденциальности. При этом каждая компания-разработчик пытается решить этот вопрос по-своему. Основная мера защиты нацелена на то, чтобы при отсутствии программных ошибок нельзя было нанести ущерб путем чтения и записи произвольных файлов, получения доступа к конфиденциальным данным других веб-страниц и т.д. В таких случаях говорят, что код выполняется в песочнице, то есть в изолированной среде (sandboxed environment). Однако ошибки все же случаются.

Корнем всех проблем является уже сам факт запуска стороннего кода на вашем компьютере — вы сами напрашиваетесь на неприятности. С точки зрения безо­пасности это то же самое, что пригласить в гости вора и пытаться внимательно следить за тем, чтобы он не проник из кухни в гостиную. Если вы на секунду отвлечетесь, может произойти все что угодно. Загвоздка в том, что переносимый код позволяет использовать эффектную графику и обеспечивает быстрое взаимодействие с пользователем. Многие веб-дизайнеры считают, что это гораздо важнее безопасности, тем более что риску подвергается чей-то чужой компьютер, а не их собственный.

Предположим, что веб-сайт, содержащий ваши личные данные, предлагает вам дать обратную связь в виде произвольного текста, который видят все остальные пользователи. Идея в том, чтобы клиенты могли сообщить компании, понравились ли им предоставленные услуги. Но если сайт недостаточно тщательно проводит очистку данных в форме обратной связи, то злоумышленник может, помимо текста, разместить в поле небольшой фрагмент JavaScript-кода. Теперь представьте, что вы зашли на этот сайт и решили прочитать отзывы других пользователей. При этом JavaScript-код будет отправлен в ваш браузер. Однако браузер не знает, что это часть текста обратной связи. Он воспринимает его как обычный JavaScript-код, который можно встретить на любой другой веб-странице, и начинает его выполнять. Это позволяет вредоносному коду выкрасть все конфиденциальные данные, которые ваш браузер использует для этого сайта (например, файлы cookie), и отправить их злоумышленнику. Такие атаки называют межсайтовым скриптингом (Cross-Site Scripting, CSS). Родственная разновидность атак, подделка межсайтовых запросов (Cross-Site Request Forgery, CSRF), позволяет злоумышленнику выдавать себя за пользователя.

Еще одной потенциальной проблемой является недостаточная безопасность самого движка JavaScript. Например, используя уязвимость браузера, вредоносный JavaScript-код может взять под контроль браузер или даже операционную систему. Эта атака называется теневой загрузкой (drive-by download): пользователь заходит на веб-сайт и, не зная об этом, подвергается заражению. Причем сам сайт может и не быть вредоносным — JavaScript-код может находиться в рекламе или, как мы видели ранее, в поле обратной связи. Особую известность получила атака на Google и ряд других IT-компаний, так называемая операция «Аврора». В ходе этой атаки злоумышленники применили теневую загрузку, чтобы охватить как можно больше компьютеров компании и получить доступ к репозиториям исходного кода.

Расширения браузера

Наряду с увеличением возможностей веб-страниц с помощью кода сегодня также активно развивается рынок браузерных расширений (browser extensions), аддонов, или дополнений (add-ons), а также плагинов, или подключаемых модулей (plug-in). Это компьютерные программы, расширяющие функциональность браузеров. Плагины позволяют интерпретировать или отображать определенный тип контента (PDF-документы или флеш-анимацию). Расширения и аддоны предоставляют новые функции (например, улучшенное управление паролями) или способы взаимодействия со страницами (маркировка страниц, просмотр сопутствующих товаров и т.д.).

Установить аддон, расширение или плагин очень просто: достаточно найти нужную программу в Сети и пройти по ссылке. Таким образом код загружается и встраивается в браузер. Все эти программы написаны в разных средах, в зависимости от того, в какой браузер они встраиваются. В любом случае в первом приближении они становятся частью доверенной вычислительной базы браузера. То есть если установленный код содержит ошибки, это может нарушить работу всего браузера.

Существуют еще две очевидные проблемы. Первая: программа может осуществлять вредоносные действия, например собирать личную информацию и