Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
□ Информационный центр компании VeriSign по вопросам SSL: www.signiocom/products–services/security–services/ssl/ssl–information–center/
□ Информация по SslStream: http://msdn2.microsoft.com/library/d50tfalc (en–us,vs.80). aspx
Резюме
Рекомендуется
□ Пользуйтесь последней версией SSL/TLS. В порядке предпочтительности: TLS 1.1, TLS 1.0hSSL3.
□ Если это имеет смысл, применяйте списки допустимых сертификатов.
□ Прежде чем посылать данные, убедитесь, что сертификат партнера можно проследить до доверенного УЦ и что его срок действия не истек.
□ Проверяйте, что в соответствующем поле сертификата партнера записано ожидаемое имя хоста.
Не рекомендуется
□ Не пользуйтесь протоколом SSL2. В нем имеются серьезные криптографические дефекты.
□ Не полагайтесь на то, что используемая вами библиотека для работы с SSL/TLS надлежащим образом выполнит все проверки, если только речь не идет о протоколе HTTPS.
□ Не ограничивайтесь проверкой одного лишь имени (например, в поле DN), записанного в сертификате. Кто угодно может создать сертификат и вписать туда произвольное имя.
Стоит подумать
□ О применении протокола OCSP для проверки сертификатов в цепочке доверия, чтобы убедиться, что ни один из них не был отозван.
□ О загрузке свежей версии CRL–списка после окончания срока действия текущего и об использовании этих списков для проверки сертификатов в цепочке доверия.
Грех 11. Использование слабых систем на основе паролей
В чем состоит грех
Люди терпеть не могут паролей, особенно если их заставляют выбирать хорошие пароли, причем разные для каждой из множества систем: почты, электронного банкинга, интернет–пейджеров, доступа к корпоративной учетной записи и к базе данных. Специалисты по информационной безопасности тоже не любят паролей, потому что люди часто используют в таком качестве имена детей. Если же потребовать от пользователя выбрать хороший пароль, то он запишет его на бумажку и приклеит к нижней части клавиатуры.
Нет сомнения, что любая система аутентификации, основанная на паролях, -это разновидность «Уловки–22», поскольку практически невозможно построить такую систему без риска. Однако похоже, что от паролей никуда не деться, и не только потому, что они востребованы пользователями, но и потому, что других решений оказывается недостаточно.
В некотором смысле любая программная система, в которой применяются пароли, небезопасна. Однако разработчиков от ответственности никто не освобождает. Есть масса способов внести в систему дополнительные риски, но есть также способы снизить существующий риск.
Подверженные греху языки
Любой язык подвержен этому греху.
Как происходит грехопадение
Парольные системы уязвимы для самых разных атак. Во–первых, противник может войти в систему под учетной записью, которая ему не принадлежит и пользоваться которой он не имеет права. При этом совершенно необязательно, что пароль был скомпрометирован. Например, перехватив и затем воспроизведя трафик, можно обойти протокол проверки пароля и войти в систему, вообще не зная пароля, а просто послав копию чьих–то зашифрованных данных.
Во–вторых, надо иметь в виду, что противник может узнать чужой пароль. Это опасно не только потому, что он сможет войти от имени чьей–то учетной записи, но и потому, что этот пароль может использоваться для доступа в разные системы. По крайней мере, узнав один пароль пользователя, будет проще догадаться о других его паролях.
Существует множество простых способов обойти парольную защиту. Самый легкий из них вообще не связан с техникой, это социальная инженерия, когда противник обманом убеждает пойти навстречу своим неблаговидным намерениям. (Зачастую для этого необходимо иметь навыки общения, одной лжи может оказаться недостаточно.)
Одна из распространенных атак методом социальной инженерии заключается в том, чтобы позвонить в отдел поддержки клиентов, притвориться пользователем X и сказать, что забыл собственный пароль. Успеху весьма способствует знание персональной информации о жертве, тогда шансы получить новый пароль заметно возрастают.
Часто из человека можно вытянуть пароль под каким–нибудь простым предлогом, например представившись репортером, который пишет статью о паролях. В случае атаки «заманиванием» (phishing) противник рассылает электронные письма, убеждая людей зайти от своего имени на указанный сайт, который выглядит вполне прилично, но его единственной целью служит собирание имен и паролей. Это пример социальной инженерии, не основанной наличном контакте.
Другая распространенная проблема, тоже не связанная с техническими деталями парольной защиты, – это оставление стандартных учетных записей с паролями по умолчанию. Часто пользователи не изменяют их, даже если в инструкции явно сказано, что это следует сделать.
Серьезная проблема состоит в том, что если человеку позволено самостоятельно выбирать пароль, то он, скорее всего, возьмет такой, который легко угадать. Если же это запретить или настоять на том, чтобы пароль был достаточно сложным, то возрастают шансы на то, что человек запишет пароль на бумажке и оставит ее на своем рабочем столе.
Есть и другие физические опасности, угрожающие паролям. Противник может установить программу, протоколирующую нажатия клавиш, или иным способом перехватить ввод пароля, например с помощью видеокамеры. Это особенно просто, если набираемый пароль отображается на экране.
Пароль можно перехватить и в других местах. В зависимости от используемого протокола противник может подключиться к проводной линии. Или перехватить пароль на стороне сервера: либо в момент копирования из сети в память, либо уже после сохранения на сервере. Иногда пароли записываются в файлы–протоколы, особенно если пользователь неправильно вводит имя.
Чтобы избежать перехвата паролей на сервере, рекомендуется не хранить их в открытом виде ни в файлах, ни в базе данных. Это имеет смысл, потому что у типичного пользователя нет никаких причин доверять людям, имеющим физический доступ к серверу, в частности системным администраторам. К сожалению, что–то, связанное с паролем, хранить так или иначе приходится. Например, это может быть односторонняя свертка пароля, с помощью которой проверяется, что пользователь действительно знает пароль. Любые данные, хранящиеся на сервере с целью удостовериться в том, что пользователь знает пароль, мы будем называть валидатором. Противник, заполучивший такой валидатор, может воспользоваться компьютером, чтобы подобрать пароль. Он просто перебирает различные пароли и смотрит, соответствует ли им данный валидатор (такую атаку обычно называют офлайновым полным перебором или атакой грубой силой). Иногда задача упрощается, особенно в случае, когда одинаковые пароли всегда дают одинаковые валидаторы. Существует общий прием, называемый «затравливанием» (salting), смысл которого в том, что сопоставить одному паролю разные валидаторы.
Существует также опасность перехвата пароля на стороне клиента, особенно если система дает возможность хранить пароли в браузере или другом локальном хранилище. Такая методика «однократной регистрации», конечно, удобна для пользователя, но создает дополнительные риски. Впрочем, большинство людей считают, что это приемлемый компромисс.
Опасности офлайновой атаки с полным перебором подвержены даже сети. Большинство протоколов аутентификации защищают данные криптографическими методами, но противник обычно может перехватить зашифрованный пароль и позже подвергнуть его атаке грубой силой. Иногда для этого достаточно простого подключения к проводу, а иногда приходится притворяться клиентом или сервером. Если протокол проверки пароля плохо спроектирован, то противник может перехватить данные клиента, воспроизвести их с другого компьютера и войти от имени другого пользователя, даже не зная настоящего пароля.
Разумеется, противник может попробовать и онлайновую атаку с перебором, когда он просто многократно пытается войти в систему, предлагая каждый раз новый пароль. Если пользователям разрешено выбирать слабые пароли, то такая стратегия может принести успех. Вы можете попробовать ограничить число попыток входа или применить другие средства обнаружения вторжений, но если в результате учетная запись блокируется, то возрастает риск отказа от обслуживания. Предположим, к примеру, что противнику понравилась какая–то вещь, выставленная на онлайновом аукционе, а торги заканчиваются утром. Если противник наблюдает за тем, кто еще повышает ставки, то где–то в середине ночи он может начать входить от имени каждого из своих конкурентов до тех пор, пока их записи не окажутся заблокированными. Тогда к утру ему уже не о чем волноваться, потому что основные конкуренты будут заняты попытками разблокировать свои учетные записи, а не торговлей, тем более что многие подобные сайты требуют высылать персональные данные по факсу.
