19 смертных грехов, угрожающих безопасности программ

Виега Джон

Но с непредсказуемыми случайными числами связана одна потенциальная проблема: если противник может увидеть данные, то ему достаточно сохранить случайное число и воспроизвести его! Чтобы предотвратить такую возможность, можете зашифровать канал по протоколу SSL/TLS. Но опять же это зависит от конкретной угрозы.

Противник изменяет данные

И наконец, предположим, что вам наплевать на то, что противник может увидеть данные, но изменять их он не должен. Это как раз проблема «цены в скрытом поле». Вообще–то вы должны избегать подобных решений, но если по какой–то странной причине другого выхода нет, то можете поместить в форму код аутентификации сообщения (message authentication code – MAC). Если МАС–код, возвращенный браузером, отличается

от того, что вы послали, или вообще отсутствует, то данные были изменены. Можете рассматривать МАС–код как свертку секретного ключа и данных. Чаще всего для вычисления свертки применяется алгоритм хэширования НМАС. Вам нужно лишь конкатенировать значения всех скрытых полей формы (или любых полей, которые вы хотите защитить) и свернуть результат с ключом, хранящимся на сервере. На С# код выглядит так:

...

HMACSHA1 hmac = new HMACSHA1(key);

byte[] data = UTF8Encoding.UTF8.GetBytes(formdata);

string result = Convert.ToBase64String(hmac.ComputeHash(data));

А на Perl – так:

...

use strict;

use Digest::HMAC_SHA1;

my $hmac = Digest::HMAC_SHA1->new($key);

$hmac->add($formdata);

my $result = $hmac->b64digest;

В PHP функции HMAC нет, но в архиве PHP Extension and Application Repository (PEAR) она имеется. (См. ссылку в разделе «Другие ресурсы».) Результат вычисления МАС–кода можно включить в скрытое поле формы:

...

<INPUT TYPE = HIDDEN NAME = «HMAC» VALUE = «X8lbKBNG9cVVeF9+9rtB7ewRMbs»>

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

Не используйте для этой цели функции хэширования. Применяйте МАС–коды, поскольку противник может повторить вычисление хэша. Заново же вычислить НМАС, не зная секретного ключа, невозможно.

Дополнительные защитные меры

Никаких дополнительных защитных мер не требуется.

Другие ресурсы

□ Раздел о скрытых полях в спецификации W3C HTML: www.w3.org/TR/ REC–html32#fields

□ « Practical Cryptography» by Niels Ferguson and Bruce Schneier (Wiley, 2003), §6.3 «Weaknesses of Hash Functions»

□ PEAR HMAC: http://pear.php.net/package/Crypt_HMAC

□ «Hold Your Sessions: An Attack on Java Session–Id Generation» by Zvi Gutter–man and Dahlia Malkhi: http://research.microsoft.com/~dalia/pubs/GM05.pdf

Резюме

Рекомендуется

□ Проверяйте все данные, поступающие из Web, в том числе и посредством форм, на признаки злоумышленности.

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

Не рекомендуется

□ Не встраивайте конфиденциальные данные в HTTP–заголовки и в HTML–страницы, в том числе в URL, куки и поля форм, если канал не шифруется с помощью таких технологий, как SSL, TLS или IPSec, или данные не защищены криптографическими средствами.

□ Не доверяйте никаким данным в Web–форме, поскольку злоумышленник может легко подставить любые значения вне зависимости от того, используется SSL или нет.

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

их.

Грех 10. Неправильное применение SSL и TLS

В чем состоит грех

Протокол Secure Sockets Layer (SSL – протокол защищенных сокетов), а равно пришедший ему на смену Transport Layer Security (TLS – протокол защиты транспортного уровня) – это два наиболее популярных в мире протокола защиты сетевых соединений. SSL широко используется в браузерах для обеспечения безопасности электронной торговли. Он применяется для защиты сети и во многих приложениях, не предназначенных для работы в Web. На самом деле, говоря о безопасности, программисты часто имеют в виду именно протокол SSL.

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

Программные API, поддерживающие SSL, обычно заменяют традиционную абстракцию ТСР–сокета, соединяющего две точки, понятием «защищенного соке–та» (отсюда и название протокола). Это означает, что SSL шифрует трафик, проверяет целостность сообщений и предоставляет каждой стороне возможность аутентифицировать партнера.

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

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

Подверженные греху языки

Проблемы SSL связаны с самим API, а не с языком, на котором он реализован. Следовательно, уязвимы программы на любом языке. Протокол HTTPS (HTTP поверх SSL) в этом отношении надежнее, чем сам SSL, поскольку в нем аутентификация производится обязательно, а не оставлена на усмотрение разработчика. Таким образом, HTTPS возлагает ответственность за принятие решения на пользователя.

Как происходит грехопадение

SSL – это протокол с установлением соединения (хотя рабочая группа по развитию Интернет (IETF) обещает скоро выпустить версию, не требующую соединения). Основное назначение SSL – обеспечить передачу сообщений по сети между двумя сторонами, каждая из которых настолько, насколько это возможно, уверена в том, с кем общается (разумеется, полную гарантию дать затруднительно), и при этом гарантировать, что сообщения не сможет ни прочитать, ни модифицировать противник, имеющий доступ к сети.

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