Компьютерные сети. 6-е изд.

8.12. Веб-безопасность

Мы только что изучили две важные области, в которых требуется защита информации, — соединения и электронная почта. Можно сказать, что это были аперитив и первое блюдо. Теперь самое время перейти к основному вопросу: безопасности данных во Всемирной паутине. Именно здесь большинство злоумышленников проворачивает свои темные дела. В следующих разделах мы рассмотрим некоторые проблемы, касающиеся веб-безопасности.

Эту тему можно условно разделить на три части. Первая связана с безопасным именованием объектов и ресурсов, вторая — с установлением аутентифицированных соединений, третья — с тем, что происходит, когда сайт отправляет клиенту исполняемый код. Мы обсудим все эти вопросы после ознакомления с рядом возможных угроз.

8.12.1. Угрозы

Практически каждую неделю газеты публикуют статьи о проблемах безопасности во Всемирной паутине. Ситуация действительно довольно неприятная. Давайте рассмотрим несколько реальных случаев взлома. Прежде всего, домашние страницы многочисленных организаций самых разных масштабов подвергались атакам взломщиков и заменялись подложными страницами. (В прессе людей, которые атакуют чужие компьютеры, называют хакерами, однако в профессиональном сообществе это слово скорее используется по отношению к великим программистам. Мы предпочитаем термин «взломщик» (cracker).) К числу сайтов, которые однажды подверглись успешной атаке, относятся веб-страницы таких серьезных организаций, как Yahoo!, Вооруженные силы США, Американское бюро кредитной истории Equifax, ЦРУ, НАСА, а также газета New York Times. В большинстве случаев взломщики просто заменяли оригиналы на страницы с каким-нибудь забавным текстом, и уже через несколько часов сайты удавалось восстановить.

Конечно, происходили и гораздо более серьезные атаки. Многие сайты были выведены из строя за счет искусственно созданной чрезмерной нагрузки (DoS-атака), с которой сервер заведомо не может справиться. Зачастую такие нападения совершались сразу с большого количества компьютеров, которые злоумышленник уже взломал (DDoS-атака). Такие атаки настолько распространены, что уже перестали быть новостью. Тем не менее ущерб от них исчисляется миллионами долларов.

В 1999 году шведский взломщик проник на сайт Hotmail (корпорации Microsoft) и создал зеркало, на котором все желающие могли ввести имя любого пользователя этого сайта и прочесть всю его почту, включая архивы.

Русский 19-летний взломщик по имени Максим украл с сайта интернет-магазина номера 300 000 кредитных карт. Затем он обратился к их владельцам и заявил, что если они не заплатят ему $100 000, он опубликует номера кредиток в интернете. Они не поддались на шантаж, и тогда Максим исполнил свою угрозу, что нанесло серьезный ущерб многим невинным жертвам.

Двадцатитрехлетний студент из Калифорнии отправил по электронной почте в агентство новостей фальшивый пресс-релиз, в котором сообщалось об огромных убытках корпорации Emulex и об уходе в отставку ее генерального директора. Спустя несколько часов акции компании упали на 60 %, в результате чего их держатели лишились более $2 млрд. Преступник заработал около четверти миллиона долларов, продав акции без покрытия46 незадолго до своего ложного заявления. Хотя этот случай не является взломом веб-сайта, размещение такого объявления на сайте компании привело бы к аналогичному эффекту.

К сожалению, такие примеры можно перечислять долго. Теперь пора перей­ти к технической стороне дела. Более подробную информацию о проблемах веб-безопасности всех видов можно найти в работах Ду (Du, 2019), Шнайера (Schneier, 2004), Статтарда и Пинто (Stuttard and Pinto, 2007). Также множество описаний конкретных случаев вы найдете в интернете.

8.12.2. Безопасное именование ресурсов и DNSSEC

Давайте еще раз затронем проблему спуфинга DNS и начнем с самого простого случая. Допустим, Алиса хочет посетить веб-сайт Боба. Она набирает в браузере нужный URL и через несколько секунд видит страницу. Но настоящая ли она? Может, да, а может, нет. Не исключено, что Труди снова взялась за старое. Предположим, она перехватила исходящие пакеты Алисы и изучила их. Отыскав HTTP-запрос GET к сайту Боба, взломщица сама зашла на эту страницу, изменила ее и отправила ни о чем не подозревающей Алисе. Хуже того, Труди может сильно снизить цены в интернет-магазине Боба, тем самым сделав его товары очень привлекательными. Это резко повышает вероятность того, что Алиса вышлет номер своей кредитной карты «Бобу» (с целью приобрести что-нибудь по выгодной цене).

Одним из недостатков традиционной атаки посредника является то, что Труди должна иметь возможность перехватывать исходящий трафик Алисы и подделывать входящий. На практике она должна прослушивать телефонную линию Алисы или Боба (поскольку прослушивать оптоволоконный магистральный кабель — задача непростая). Конечно, перехват телефонных разговоров возможен, но это требует больших усилий, а Труди не только умна, но и ленива.

Кроме того, Алису можно обмануть проще: например, спуфинг DNS, о котором мы говорили в разделе 8.2.3. В двух словах это выглядит так. Злоумышленник сохраняет некорректные данные сопоставления сервиса на промежуточном сервере имен, чтобы сервер направлял пользователей на поддельный IP-адрес. Если пользователь захочет подключиться к сервису, он извлечет этот адрес и в итоге свяжется не с реальным сервером, а со злоумышленником.

Настоящая проблема в том, что служба DNS разрабатывалась в те времена, когда интернет был чисто исследовательской сетью, работавшей в нескольких сотнях университетов, и ни Алиса, ни Боб, ни Труди не были приглашены на этот праздник жизни. Вопрос защиты информации тогда еще не стоял; задача была в том, чтобы интернет вообще функционировал. Но с годами все кардинально изменилось, поэтому в 1994 году IETF создал рабочую группу, которая должна была обеспечить безопасность DNS. Этот проект под названием DNSSEC (DNS Security — защита DNS) действует до сих пор; первая версия представлена в спецификации RFC 2535, а обновление — в RFC 4033–4035. К сожалению, DNSSEC не развернут в полном масштабе, поэтому многие DNS-серверы все еще уязвимы для атак подмены.

Концептуально система DNSSEC очень проста. Она основана на шифровании с открытыми ключами. В каждой зоне DNS (см. главу 7) имеется два ключа — открытый и закрытый. Вся информация, отправляемая DNS-сервером, подписывается с помощью закрытого ключа зоны источника, и принимающая сторона может легко проверить подлинность данных.

DNSSEC предоставляет три основные службы:

1. Подтверждение источника данных.

2. Распространение открытых ключей.

3. Аутентификацию транзакций и запросов.

Первая служба является основной: она проверяет, что пришедшие данные были одобрены владельцем зоны. Вторая служба используется для безопасного хранения и извлечения открытых ключей. Третья позволяет защититься от атак повторного воспроизведения и подмены сервера. Заметим, что конфиденциальность здесь не обеспечивается: такая задача не стоит, поскольку вся информация DNS считается открытой. Изначально предполагалось, что процесс внедрения системы займет несколько лет. Поэтому нужно было организовать взаимодействие между серверами с поддержкой DNSSEC и остальными серверами. Это подразумевает невозможность внесения в протокол каких-либо изменений. Теперь рассмотрим эту систему более детально.

Записи DNS группируются в наборы записей ресурсов (Resource Record Set, RRSET). В таком наборе объединены все записи с одинаковым именем, классом и типом. Например, RRSET может состоять из нескольких записей A, если DNS-имя преобразуется в первичный и вторичный IP-адрес. Наборы расширяются за счет некоторых новых типов записей (они рассмотрены ниже). Каждый RRSET хешируется (например, с помощью SHA-2). Хеш подписывается закрытым ключом зоны (например, с применением RSA). Единицей передаваемой клиентам информации является подписанный RRSET. Получив его, клиент может проверить, действительно ли набор был подписан закрытым ключом зоны отправителя. Если подпись корректна, данные принимаются. Поскольку каждый RRSET содержит собственную подпись, эти наборы можно кэшировать где угодно, даже на не слишком надежных серверах, не опасаясь за их безопасность.

Система DNSSEC вводит несколько новых типов записей. Первая из них — DNSKEY. В ней указывается открытый ключ зоны, пользователя, хоста или другого принципала, криптографический алгоритм генерации подписи, наименование протокола передачи и некоторые другие данные. Открытый ключ хранится в незащищенном виде. Сертификаты X.509 не используются из-за их громоздкости. В поле алгоритма содержится значение 1 для MD5/RSA и другие значения для остальных комбинаций. Поле протокола может указывать на применение IPsec или другого протокола защиты соединений (если он вообще используется).

Второй новый тип записи — RRSIG. В ней содержится подписанный хеш, сформированный согласно алгоритму, который указан в DNSKEY. Подпись охватывает все записи RRSET (в том числе все DNSKEY), за исключением ее самой. Здесь также указано время начала и конца действия подписи, имя ее владельца и некоторая дополнительная информация.

Система DNSSEC устроена так, что для большей надежности закрытый ключ зоны можно хранить вне сети. Один или два раза в день содержимое базы данных зоны вручную переносится (например, на таком безопасном носителе, как старый добрый компакт-диск) на автономный компьютер, где расположен закрытый ключ. Здесь генерируются подписи для всех RRSET, и полученные таким образом записи RRSIG вновь записываются на защищенное устройство и возвращаются на главный сервер зоны. Таким образом, закрытый ключ хранится на безопасном носителе в сейфе и извлекается лишь для того, чтобы подписать ежедневное обновление RRSET на автономном компьютере. По окончании генерации подпи­сей все копии ключа удаляются из памяти, а носитель отправляется в сейф. Эта процедура сводит электронную защиту информации к физической, что гораздо понятнее для пользователей.

Метод предварительного подписания RRSET существенно ускоряет процесс обработки запросов, ведь благодаря ему отпадает необходимость в шифровании на лету. Правда, для хранения всех ключей и подписей в базах данных DNS требуется большой объем дискового пространства. Из-за подписи некоторые записи увеличиваются в размере десятикратно.

Получив подписанный RRSET, клиент применяет открытый ключ зоны отправителя для расшифровки хеша, затем вычисляет хеш самостоятельно и сравнивает два значения. Если они совпадают, данные считаются корректными. Но эта процедура не решает вопрос получения клиентом открытого ключа зоны. Один из возможных подходов сводится к тому, что надежный сервер передает клиенту ключ по защищенному соединению (например, при помощи IPsec).

Однако на практике предполагается, что у клиентов уже есть открытые ключи всех доменов верхнего уровня. Если Алиса пожелает посетить сайт Боба, она запросит у службы DNS набор RRSET для сайта bob.com. Этот набор будет включать IP-адрес и запись DNSKEY с открытым ключом Боба и будет подписан доменом верхнего уровня (com), поэтому Алиса сможет легко проверить его подлинность. На илл. 8.47 показан пример содержимого RRSET.

Теперь, вооружившись заверенной копией открытого ключа Боба, Алиса запрашивает у DNS-сервера Боба IP-адрес сайта www.bob.com. Этот RRSET подписан закрытым ключом Боба, поэтому Алиса может проверить подлинность подписи возвращенного Бобом набора. Если Труди каким-то образом внедрит фальшивый RRSET в один из кэшей, Алиса заметит это, так как запись RRSIG будет неправильной.

Имя домена

Время жизни

Класс

Тип

Значение

bob.com.

86400

IN

A

36.1.2.3

bob.com.

86400

IN

DNSKEY

3682793A7B73F731029CE2737D...

bob.com.

86400

IN

RRSIG

86947503A8B848F5272E53930C...

Илл. 8.47. Пример RRSET для bob.com. Запись DNSKEY содержит открытый ключ Боба. Запись RRSIG содержит хеш записей A и DNSKEY, подписанный сервером домена верхнего уровня com для подтверждения их подлинности

Впрочем, система DNSSEC также предоставляет криптографический механизм для связывания ответов с соответствующими запросами, что исключает возможность проведения атаки подмены данных, о которой мы говорили в начале главы. Эта мера (необязательная) заключается в том, что к ответу добавляется хеш запроса, подписанный закрытым ключом респондента. Поскольку у Труди нет закрытого ключа сервера домена верхнего уровня (com), она не сможет подделать ответ этого сервера на запрос интернет-провайдера Алисы. Конечно, Труди может опередить настоящий ответ, но фальшивка будет отслежена по неправильной подписи хешированного запроса.

DNSSEC поддерживает и некоторые другие типы записей. Так, для хранения сертификатов (например, стандарта X.509) можно использовать запись CERT. Зачем она нужна? Дело в том, что некоторые хотят превратить DNS в PKI. Случится это на самом деле или нет, пока неизвестно. На этом мы заканчиваем обсуждение DNSSEC. Более подробную информацию вы можете найти в специ­фикациях RFC.

8.12.3. Протокол TLS

Защита имен ресурсов — неплохое начало, но веб-безопасность этим не исчерпывается. Теперь мы поговорим об установлении защищенных соединений. Это довольно сложная тема (как и все связанное с безопасностью).

Когда веб-технологии стали достоянием общественности, их применяли для распространения статических страниц. Но вскоре некоторые компании задумались об использовании Всемирной паутины для выполнения финансовых транзакций, таких как покупка товаров по кредитным картам, онлайновые банковские операции, электронная торговля ценными бумагами. Для этого требовались защищенные соединения, поэтому в 1995 году компания Netscape Communications, на тот момент доминирующий на рынке разработчик браузера, представила пакет безопасности SSL (Secure Sockets Layer — уровень защищенных сокетов). Теперь он называется TLS (Transport Layer Security — защита транспортного уровня). Сегодня это программное обеспечение вместе с соответствующим протоколом получило широкое распространение (в частности, оно используется в браузерах Firefox, Brave, Safari и Chrome), и потому его стоит рассмотреть более подробно.

Итак, SSL создает защищенное соединение между двумя сокетами, при этом обеспечивается:

1. Согласование параметров между клиентом и сервером.

2. Аутентификация сервера клиентом.

3. Конфиденциальная передача данных.

4. Защита целостности данных.

Поскольку все перечисленные пункты нам уже знакомы, мы не будем на них подробно останавливаться.

Расположение SSL в структуре типичного стека протоколов показано на илл. 8.48. Фактически между прикладным и транспортным уровнями появляется новый уровень, который принимает запросы от браузера и отсылает их TCP для передачи серверу. После установления защищенного соединения основная задача SSL заключается в обеспечении сжатия и шифрования. При использовании протокола HTTP поверх SSL он называется HTTPS (Secure HTTP — защищенный HTTP), хотя по сути это тот же HTTP. Правда, часто доступ осуществляется через новый порт (443) вместо стандартного (80). К слову, SSL используется не только в веб-браузерах, хотя это самое распространенное применение. Также он обеспечивает взаимную аутентификацию.

Прикладной (HTTP)

Защиты (SSL)

Транспортный (TCP)

Сетевой (IP)

Канальный (PPP)

Физический (модемное соединение, ADSL, кабельное ТВ)

Илл. 8.48. Уровни (и протоколы), используемые обычным домашним браузером с SSL

Существует несколько версий протокола SSL. Ниже мы обсудим только версию 3, так как она является самой популярной. SSL предусматривает множество различных вариантов: с наличием или отсутствием сжатия, тем или иным алгоритмом шифрования, а также инструментами ограничения экспорта в криптографии. Последнее в основном предназначено для того, чтобы убедиться в корректном применении серьезного шифрования. Его можно использовать, только если данные передаются в пределах США. В иных случаях длину ключа ограничивают 40 битами, что криптографы воспринимают как насмешку. Но Netscape была вынуждена ввести это ограничение, чтобы получить лицензию на экспорт от правительства США.

SSL состоит из двух подпротоколов, один из которых предназначен для установления защищенного соединения, а второй — для его использования. Рассмотрим первый подпротокол (илл. 8.49). Все начинается с сообщения 1, в котором Алиса отправляет Бобу запрос на установление соединения. В запросе указывается версия SSL, а также предпочтения Алисы относительно сжатия и алгоритмов шифрования. Также в нем содержится нонс RA, который будет применен впоследствии.

Илл. 8.49. Упрощенный вариант подпротокола SSL установления соединения

Теперь очередь Боба. Он выбирает один из алгоритмов, поддерживаемых Алисой, и отсылает собственный нонс RB (сообщение 2). Затем он отправляет сертификат со своим открытым ключом (сообщение 3). Если сертификат не подписан какой-нибудь уважаемой организацией, Боб отсылает цепочку сертификатов, по которым Алиса может убедиться, что его сертификату действительно можно доверять. Все браузеры, включая тот, что установлен у Алисы, изначально снабжаются примерно сотней открытых ключей. Если среди присланных Бобом сертификатов встретится один из этих ключей, Алиса сможет восстановить по нему ключ Боба и проверить его. В этот момент Боб может прислать и другие сообщения (например, запрос на получение сертификата Алисы с ее открытым ключом). После выполнения своей части протокола Боб отправляет сообщение 4, в котором говорит, что настала очередь Алисы.

Алиса отвечает Бобу случайно выбранным 384-разрядным подготовительным ключом (premaster key), который она зашифровала открытым ключом Боба (сообщение 5). Действующий ключ сеанса вычисляется при помощи подготовительного ключа и нонсов обеих сторон. Это достаточно сложная процедура. После получения сообщения 5 оба собеседника могут вычислить ключ сеанса. Для этого Алиса просит Боба переключиться на новый шифр (сообщение 6), а также сообщает, что она считает подпротокол установления соединения оконченным (сообщение 7). Боб соглашается с ней (сообщения 8 и 9).

Несмотря на то что Алиса знает, кто такой Боб, сам Боб Алису не знает (если только у нее нет открытого ключа и сертификата к нему, что довольно необычно для физического лица). Поэтому первым сообщением Боба вполне может быть просьба войти в систему, используя полученные ранее имя пользователя и пароль. Впрочем, протокол входа находится за рамками SSL. Так или иначе, по окончании этой серии запросов-подтверждений можно переходить к передаче данных.

Как уже говорилось, SSL поддерживает многочисленные криптографические алгоритмы. Один из них использует для шифрования тройной DES с тремя отдельными ключами и SHA для обеспечения целостности сообщений. Эта комбинация алгоритмов работает довольно медленно, поэтому ее использовали в основном при выполнении банковских операций и в других случаях, требующих высокого уровня защиты. Для шифрования данных в обычных приложениях электронной коммерции применялся алгоритм RC4 с 128-разрядным ключом, а для аутентификации сообщений — алгоритм MD5. В качестве исходных данных RC4 использует 128-разрядный ключ, который значительно увеличивается в процессе работы алгоритма. С помощью этого внутреннего числа генерируется ключевой поток, который затем суммируется по модулю 2 с открытым текстом. В результате получается обычный потоковый шифр (см. илл. 8.18). В экспортных версиях также используется алгоритм RC4 со 128-разрядными ключами, но при этом 88 разрядов являются открытыми, что позволяет достаточно легко взломать шифр.

Для передачи данных используется второй подпротокол (илл. 8.50). Поступающие от браузера сообщения разбиваются на единицы данных размером

Илл. 8.50. Передача данных с использованием SSL

до 16 Кбайт. Если включено сжатие, то каждая единица сжимается отдельно. Далее по двум нонсам и подготовительному ключу вычисляется закрытый ключ, который объединяется со сжатым текстом. Результат хешируется алгоритмом, о котором договорились стороны (чаще всего это 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-документы или флеш-анимацию). Расширения и аддоны предоставляют новые функции (например, улучшенное управление паролями) или способы взаимодействия со страницами (маркировка страниц, просмотр сопутствующих товаров и т.д.).

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

Существуют еще две очевидные проблемы. Первая: программа может осуществлять вредоносные действия, например собирать личную информацию и отсылать ее на удаленный сервер. При этом браузер будет считать, что пользователь установил расширение именно с этой целью. Вторая проблема в том, что плагины дают браузеру возможность считывать новые типы контента. Часто это сам по себе полноценный язык программирования; хорошие примеры — PDF и Flash. Когда пользователи просматривают страницы с PDF и Flash, плагины выполняют соответствующий код. Он должен быть безопасным, ведь в браузере могут быть уязвимости, которыми код может воспользоваться. В силу этих причин аддоны и плагины лучше ставить по мере необходимости и скачивать только из надежных источников.

Трояны и другое вредоносное ПО

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

46 Вид спекуляции на бирже, когда торговец берет акции в кредит и продает их по текущей цене. После падения акций он выкупает их по новой, низкой стоимости и возвращает их брокеру. — Примеч. ред.