Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Заметим еще, что популярные механизмы обеспечения конфиденциальности часто применяются неправильно, поскольку разработчик не понимает, при каких условиях они безопасны. Так, сплошь и рядом некорректно используют блочные шифры в режиме СВС (сцепление блоков шифртекста) и алгоритм RC4.
Для режима СВС входными данными служит не только открытый текст, но и случайно выбранный вектор инициализации (IV). Если он недостаточно случаен, возможна атака. Это верно даже тогда, когда в качестве IV для следующего сообщения выбирается последний блок предыдущего сообщения. Это одна из многих причин, по которым вместо СВС изобретены другие режимы работы блочных шифров, обеспечивающие и конфиденциальность, и аутентификацию. Жертвой этой уязвимости пал, как вы увидите, даже протокол SSL/TLS.
У алгоритма RC4 тоже есть серьезные слабости. Не стоит шифровать с его помощью слишком большие объемы данных (не больше 220 байтов). Все настолько плохо, что мы настоятельно рекомендуем вообще не пользоваться RC4, если вы хотите, чтобы ваша система сейчас и в перспективе оставалась безопасной. Но если вы все–таки настаиваете на шифровании с его помощью небольших объемов данных, то необходимо выполнить инициализацию, придерживаясь следующих апробированных рекомендаций:
□ начните генерацию ключей как обычно, а затем отбросьте первые 256 байтов гаммы (то есть зашифруйте первые 256 нулей и отбросьте результаты, не раскрывая их). Проблема в том, что этого количества может оказаться мало;
□ подайте ключ на вход односторонней функции хэширования, например SHА1, а результат используйте в качестве ключа для RC4. Это рекомендованный подход. Недавние атаки на SHA1 не оказывают на него практического влияния.
Еще один тонкий аспект конфиденциальности – в том, что есть такие параноики, которым подавай безопасность в режиме «точка–точка». Например, сторонники неприкосновенности частной жизни обычно не пользуются интернет–пейджерами, даже если они передают сообщения на сервер в зашифрованном виде, поскольку сервер – это излишняя слабая точка, не только уязвимая для хакеров, но и могущая стать основанием для вызова в суд. Ну и так далее. Большая часть людей хотели бы защитить свою частную жизнь, хотя при определенных обстоятельствах готовы пожертвовать безопасностью. А коли так, то желательно обеспечить конфиденциальность данных, поскольку в противном случае возможна «кража личности». На наших глазах слабозащищенные системы, раскрывающие данные о пользователях, становятся подотчетными. Например, всякая фирма, работающая в Калифорнии, обязана известить своих клиентов в случае, когда знает о возможной компрометации данных, которые пользователи считают приватными. Через некоторое время такие требования могут быть дополнены денежными штрафами и другими юридическими последствиями.
Иногда все–таки возникает потребность сделать что–то простенькое на базе криптографии с симметричным ключом, поскольку это быстро и куда менее накладно, чем использование SSL. Но мы не рекомендуем так поступать, ибо уж слишком много капканов на этой дороге. Само шифрование не вызывает никаких сложностей, если пользоваться правильными криптографическими примитивами, но вот управление ключами может стать кошмаром. К примеру, как безопасно хранить ключи и при этом сохранить возможность быстро переместить учетную запись на другую машину? Если вы склоняетесь к паролю, то тут вас подстерегают серьезные опасности, так как при использовании одной лишь криптографии с симметричным ключом пароль можно вскрыть с помощью полного перебора.
Если вы решили выбрать «симметричный путь», несмотря на все наши увещевания о том, что лучше бы обратиться к готовому решению, то прочтите хотя бы следующие советы:
□ пользуйтесь проверенным блочным шифром. Мы настоятельно рекомендуем AES и ключ длиной не менее 128 битов, какой бы алгоритм вы ни выбрали;
□ применяйте блочный шифр в режиме работы, обеспечивающем аутентификацию и целостность сообщений, например GCM или ССМ. Если вы пользуетесь библиотекой криптографических функций, в которой эти режимы не поддерживаются, нетрудно достать подходящую (см. раздел «Другие ресурсы»). Можно вместо этого воспользоваться сочетанием двух других конструкций: режима CTR с СМАС–или НМАС–кодом;
□ применяйте аутентификацию по всему сообщению, даже если данные не нуждаются в шифровании. В режимах GCM и ССМ сообщения можно аутентифицировать, не шифруя;
□ на принимающей стороне всегда проверяйте аутентичность сообщения и только потом делайте что–то с содержащимися в нем данными;
□ кроме того, на принимающей стороне проверяйте, что сообщение не было воспроизведено (а если это так, отбрасывайте его). Если сообщение аутентично, то для этого достаточно сравнить его номер с номером последнего пришедшего сообщения; номера должны монотонно возрастать.Кстати говоря, чтобы доказать третьей стороне, что сообщение было отправлено конкретным лицом, можно воспользоваться цифровой подписью, но делайте это только в случае необходимости и в дополнение, а не вместо механизма аутентификации сообщений. В системах Windows надлежащую проверку целостности данных на уровне пакетов и конфиденциальность обеспечат вызовы RPC/DCOM, если при создании сеанса вы измените один параметр. Еще раз подчеркнем, что лучше пользоваться готовыми решениями. Добавим, что SSPI API позволяет сравнительно легко организовать передачу данных по протоколам HTTPS или Kerberos, которые гарантируют аутентификацию как клиента, так и сервера, а заодно целостность и конфиденциальность пакетов.
Дополнительные защитные меры
Применяйте надежную схему управления ключами. В качестве варианта можем предложить Data Protection API (защита данных) в Windows или CDSA API.
Другие ресурсы
□ Утилита ssldump для анализа SSL–трафика: www.rtfm.com/ssldump
□ SSL–прокси Stunnel: www.stunnel.org/
□ Бесплатная реализация режимов GCM и ССМ от Брайана Гладмана: fp.gladman.plus.com/AES/index.htm
Резюме
Рекомендуется
□ Пользуйтесь стойкими механизмами аутентификации.
□ Аутентифицируйте все сообщения, отправляемые в сеть вашим приложением.
□ Шифруйте все данные, которые должны быть конфиденциальны. Лучше перестраховаться.
□ Если возможно, передавайте весь трафик по каналу, защищенному SSL/TLS. Это работает!
Не рекомендуется
□ Не отказывайтесь от шифрования данных из соображений производительности. Шифрование на лету обходится совсем недорого.
□ Не «зашивайте» ключи в код и ни в коем случае не думайте, что XOR с фиксированной строкой можно считать механизмом шифрования.
□ Не игнорируйте вопросы защиты данных в сети.
Стоит подумать
□ Об использовании технологий уровня сети, способных еще уменьшить риск. Речь идет о межсетевых экранах, виртуальных частных сетях (VPN) и балансировании нагрузки.
Грех 9. Применение загадочных URL и скрытых полей форм
В чем состоит грех
Представьте себе сайт, где вы можете купить машину по той цене, которую сами предложите! Такое возможно, если цена машины будет храниться в скрытом поле формы. Напомним, что ничто не может помешать пользователю просмотреть содержимое документа, а затем отправить серверу измененную форму, в которой цена будет «несколько» снижена (легко написать такой сценарий, например, на Perl). Скрытые поля в действительности скрытыми не являются.
Еще одна распространенная ошибка связана с «загадочными URL»: многие Web–приложения хранят в URL информацию об аутентификации и другие важные данные. В некоторых случаях эти данные нельзя выставлять на всеобщее обозрение, поскольку противник может их перехватить и начать манипуляции с сеансом. В иных случаях загадочный URL применяется как особая форма контроля доступа взамен общепринятых систем на базе проверки верительных грамот (credentials). Другими словами, пользователь предъявляет системе свой идентификатор и пароль, и в случае успешной аутентификации та создает строку, представляющую данного пользователя.
Подверженные греху языки
Уязвим любой язык или технология, применяемые для создания Web–сайтов, например: PHP, Active Server Pages (ASP), C#, VB.NET, J2EE (JSP, сервлеты), Perl и CGI (Common Gateway Interface – общий шлюзовой интерфейс).
Как происходит грехопадение
С этим грехом связаны две разные ошибки, которые мы и рассмотрим поочередно.
Загадочные URL
Первая ошибка – это использование загадочных URL (Magic URL), содержащих либо секретную информацию, либо нечто, что может дать противнику доступ к секретной информации. Взгляните на следующий URL:
Интересно, что за строка следует после id. Вероятно, она представлена в кодировке base64; на это указывает небольшой набор ASCII–символов и завершающие знаки равенства. Если подать эту строку на вход декодера base64, то он тут же вернет расшифровку: «My$ecre+pA$$wOrD». Нет сомнений, что это «зашифрованный» пароль, а в качестве алгоритма этого с позволения сказать шифрования выступает base64! Не поступайте так, если ваши данные представляют хоть какую–то ценность.
