WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |
-- [ Страница 1 ] --

Michael Howard David LeBlank WRITING SECURE CODE Second Edition Press Майкл Ховард Дэвид Лебланк ЗАЩИЩЕННЫЙ код 2-е издание, исправленное Москва 2004 УДК 004.45 ББК 32.973.26-018.2 Х68

Ховард М., Лебланк Д.

Х68 Защищенный код: Пер. с англ, — 2-е изд., испр.

говый дом Редакция», 2004. — 704 стр.: ил.

ISBN 5-7502-0238-0 В этой книге разработчики найдут практические советы и рекомендации по защите создаваемых приложений на всех этапах процесса создания ПО — от про ектирования безопасных приложений и до тестирования для выявления брешей в готовой программе и создания безопасной документации и сообщений об ошибках. Здесь рассказывается о моделировании опасностей, планировании про цесса разработки защищенных проблемах локализации и связан ных с ней опасностях, недостатках файловых систем, поддержке конфиденциаль ности в приложениях и безопасной установке приложений. Авторы иллюстриру ют свой рассказ примерами программ на самых разных языках — от до Perl.

Издание обогащено знанием, полученным авторами в процессе реализации Win dows Security Push — инициативы по укреплению защиты продуктов Microsoft.

Книга будет полезной менеджерам проектов, архитекторам приложений, про и техническим то есть абсолютно всем специалистам, вовлеченным в процесс разработки ПО, — как новичкам, так и профессионалам.

Книга состоит из 24 глав, 5 приложений, библиографического списка с анно тациями и предметного указателя.

УДК 004. ББК 32.973.26-018. к по договору с Microsoft Corporation, Вашинг тон, США.

Directory, ActiveX, Microsoft, Microsoft Press, MSDN, MS-DOS, Visual Basic. Visual C++, Visual Win32. Windows, и Windows NT товарными знака или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие являются собственностью соответствующих фирм.

Все названия компаний, организаций, продуктов, Web-сайтов, доменов, адресов электронной событий, а также имена в издании, вымышлены и не имеют никакого отношения к реальным компаниям, продуктам, Web-сайтам, доменам, адресам электронной почты, событиям и именам лиц.

© Оригинальное издание на английском Microsoft Corporation, © Перевод на русский язык, Microsoft Corporation, 2003- [SBN (англ.) © Оформление и подготовка к изданию, TSBN 5-7502-0238-0 торговый дом 2003- Оглавление Введение XX Кому адресована эта книга XXI Структура книги Загрузка и установка примеров приложений XX [I Системные требования Техническая поддержка [I Благодарности XXIII I БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ СЕГОДНЯ Глава 1 Необходимость защиты систем Приложения в «дикой» Web-среде доверительных вычислений «Танцуют б Тактичные методы пропаганды идей безопасности Запрещенные приемы Некоторые методы насаждения идей безопасности Убедите начальника к сотрудникам с заявлением на тему безопасности Возьмите в штат поборника безопасности Правила боя Правило защищающемуся приходится охранять все слабые места, а нападающему достаточно выбрать одно из них Правило №2: защищающийся готовится отразить известные атаки.

а нападающий может разработать новые методы взлома Правило № 3: оборону следует держать постоянно, удар же возможен когда угодно Правило №4: защищающему приходится соблюдать правила, а нападающему не возбраняется вести «грязную Резюме VI Глава 2 Активный подход к безопасности при разработке приложений Совершенствование процессов Необходимость обучения Отношение сотрудников к обязательному обучению Непрерывность обучения Развитие науки о безопасности Образование позволяет избавиться от что пара глаз — всегда лучше» А теперь доказательства! 2б Проектирование Беседуйте с потенциальными сотрудниками Определите цели защиты продукта Рассматривайте защиту как функцию программы Отведите на обеспечение безопасности достаточно времени Моделируйте опасности, грозящие системе С самого начала запланируйте процедуру удаления оказавшихся небезопасными Определите допустимое число ошибок Предусмотрите проверку группой по безопасности Разработка Очень осторожно предоставляйте права на внесение исправлений Перепроверяйте внесенные исправления Зб Создайте руководство по созданию безопасного кода Учитесь на предыдущих ошибках Поручите анализ безопасности приглашенным специалистам Разверните кампанию по Не утоните в потоке обнаруженных ошибок защиты Следите за уровнем ошибок Никаких неожиданностей и яиц»! Тестирование Поставка и сопровождение Как узнать, что продукт готов Обратная связь Ответственность Резюме Глава 3 Принципы безопасности, которые следует взять на вооружение Принцип согласно проекту, по умолчанию при развертывании Безопасно согласно проекту Безопасно по умолчанию Безопасно при развертывании Принципы безопасности Учитесь на ошибках Оглавление VII Уменьшайте приложения, уязвимую для нападений Назначайте безопасные параметры в по умолчанию Защищайте все уровни Используйте наименьшие привилегии Будьте готовы к проблемам с обратной совместимостью Принимайте как аксиому, что внешние системы не защищены по определению Разработайте план действий на случай сбоев и отказов Предусмотрите безопасный сбой что возможности подсистемы безопасности — это не то же самое, что безопасные возможности системы Не стройте систему защиты на ограничении информации о приложении Разделяйте код и данные Корректно исправляйте ошибки в защите Резюме Глава 4 Моделирование опасностей Моделирование опасностей как средство проектирования защищенных приложений Создание группы моделирования опасностей Разложение программы на составляющие Определение опасностей, грозящих системе Распределение опасностей по мере убывания их серьезности Реакция на опасность Отбор методов для предотвращения опасности Методы защиты Аутентификация Авторизация Технологии защиты от несанкционированного доступа и обеспечение конфиденциальности Защищайте секретные данные, а лучше вообще не храните их Шифрование, хеши, и цифровые подписи Аудит Фильтрация, управление входящими запросами и качество обслуживания Минимальные привилегии Устранение опасностей, грозящих приложению расчета зарплаты Основные опасности и методы борьбы с ними Резюме МЕТОДЫ БЕЗОПАСНОГО КОДИРОВАНИЯ Глава 5 Враг переполнение буфера В Переполнение стека Переполнение кучи VIII Оглавление Ошибки индексации массива Ошибки в строках форматирования Несовпадение размеров буфера при использовании Unicode и ANSI Пример ошибки, связанной с Unicode Предотвращение переполнения буфера Безопасная обработка строк Пара слов об осторожности при работе со строковыми функциями Параметр /GS компилятора Visual C++ Резюме Глава б Выбор управления доступом Почему списки так важны Раздел не «по теме»: исправление кода доступа к реестру Из чего состоит ACL Как выбрать оптимальный ACL Эффективные запрещающие АСЕ-записи Создание ACL в Windows NT Создание ACL в Windows Создание ACL средствами Active Template Library Как правильно упорядочить АСЕ-записи Безопасность при использовании SID сервера терминалов и удаленного рабочего стола Нулевая и другие опасные типы АСЕ Нулевая DACL и аудит 1б Опасные типы АСЕ Что делать, если нельзя изменить нулевую DACL Другие механизмы управления доступом Роли в Framework Роли в СОМ+ IP-ограничения Триггеры и разрешения сервера SQL Server Пример приложения для поликлиники Важное замечание по поводу механизмов управления доступом Резюме Глава 7 Принцип минимальных привилегий Ущерб от вредоносного ПО Вирусы и троянцы Изменение страниц Web-сайтов Краткий в управление доступом Коротко о привилегиях Привилегия Привилегия SeRestorePrivilege Оглавление IX Привилегия Привилегия SeTcbPrivilege Привилегии и Privilege Привилегия Привилегия Привилегия Несколько слов о маркерах Как взаимодействуют маркеры, привилегии, SID, ACL и процессы Идентификаторы SID и доступом, а также привилегии и их проверка аргумента в пользу назначения приложению высоких привилегий Проблемы с ACL Проблемы с привилегиями Использование секретов Решение проблем, возникающих из-за предоставления высоких привилегий Решение проблемы ACL Решение проблем с привилегиями Решение проблем с Определение оптимального набора привилегий Этап 1: выясните, какие ресурсы нужны приложению Этап 2: выясните, какими системными API-функциями пользуется приложение Этап 3: определите, какая требуется учетная запись Этап 4: исследуйте содержимое маркера.... Этап 6: внесите изменения в маркер Учетные записи непривилегированных служб в Windows XP/.NET Server Привилегия олицетворения в Windows Server Отладка возникающих из-за ограничения привилегий Резюме Глава 8 Подводные камни криптографии «Слабые» случайные числа Проблема с функцией rand Случайные числа криптографического качества в Случайные числа криптографического качества в управляемом коде 2 Случайные криптографического качества на Web-страницах Создание криптографических ключей на основе пароля Оценка эффективной длины пароля Управление ключами 2 Долгосрочные и краткосрочные ключи Выбор длины ключа для защиты данных Выбор места хранения ключей Оглавление Проблемы обмена ключами Создание собственных криптографических функций Использование одного ключа потокового шифрования Зачем нужно шифрование Подводные камни потокового шифрования "Что когда необходимо использовать лишь один ключ Атаки на поточные шифры путем переворота бит Защита от атак переворота бит Что выбрать: хеш, хеш с ключом или цифровую подпись Повторное использование буфера для открытого и зашифрованного текста Криптография как средство защиты от атак Документируйте все случаи использования криптографии Резюме Глава 9 Защита секретных данных Атака на секретные данные Когда секрет хранить не обязательно Хеш с модификатором данных 5 для усложнения задачи Получение секретных данных от пользователя Защита секретов в Windows 2000 и следующих ОС семейства Частный случай: реквизиты пользователя в Windows XP Защита секретов в Windows 4 Защита секретов в Windows и Windows СЕ Получение информации об устройстве средствами РпР Слабость единого универсального Управление секретами в памяти Оптимизирующий компилятор... с подвохом Шифрование секретных данных в памяти Блокировка памяти для предотвращения выгрузки секретной информации на диск Защита секретных данных в управляемом коде Управление секретами в памяти в управляемом коде Поднимаем планку безопасности Хранение данных в файле на FAT-томе Применение встроенного ключа и операции XOR Применение встроенного ключа и алгоритма 3DES Использование для шифрования данных и хранение пароля в реестре Использование 3DES для шифрования данных и хранение пароля в защищенном разделе реестра Использование 3DES для шифрования данных, хранение пароля в надежном разделе реестра, а также защита самого файла и раздела реестра списками ACL Оглавление XI Шифрование данных по алгоритму 3DES, хранение пароля в надежном разделе реестра, требование ввести пароль, а также защита списками ACL файла и раздела реестра Компромиссы при защите секретных данных Резюме Глава Все входные данные — от лукавого! Суть проблемы Излишнее доверие Методы защиты от основанных на изменении входных данных Как проверять корректность данных 2 ) «Осторожные» переменные в Perl УЖ Регулярные выражения как средство проверки входящих данных Будьте внимательны с поиском (или проверкой) данных Регулярные выражения и Unicode камень регулярных выражений Регулярные выражения в Perl Регулярные выражения в управляемом коде Регулярные выражения в сценариях Регулярные выражения в C++ Хороший подход, но без использования регулярных выражений Резюме Глава Недостатки канонического представления Что означает и как это понятие создает проблемы Проблемы канонического представления имен файлов Обход фильтров имен файлов в сервисе Napster Брешь в Mac OS X и Apache Брешь в именах устройств DOS Брешь в символической ссылке на каталог /tmp в пакете компании Sun Стандартные ошибки в канонических именах Windows Проблемы приведения в канонический вид в Web Обход родительского контроля AOL Обход механизмов обеспечения безопасности еЕуе Зоны в Explorer 4. Ошибка без точек* связанная с потоком ::$DATA Internet Information Server 4. Две строки вместо одной 3 Еще одна напасть в Web — управляющие символы Атаки на основании визуального совпадения и атаки Предотвращение ошибок приведения в канонический вид Никогда не принимайте решений на основании имен Используйте регулярные выражения как метод контроля имени 3 Отключайте генерацию имен файлов в формате XII Оглавление Не полагайтесь на переменную PATH — указывайте полные имена файлов Самостоятельно приводим имена в канонический вид Безопасно вызывайте CreateFile Лекарства от приведения в канонический вид в Web Контроль правильности входных данных Исключительная осторожность с — между молотом и наковальней На закуску: проблемы приведения в канонический вид, не связанные с файлами Имена серверов Имена пользователей Резюме Глава 12 Ввод в базу данных проблемы Псевдосредство заключение вводимых данных в кавычки Псевдосредство №2: хранимые процедуры Средство никаких подключений к СУБД под учетной записью администратора Средство №2: построение безопасных SQL-выражений Создание безопасных хранимых Глубокая оборона Резюме Глава 13 Проблемы ввода в Web-среде сценарии: когда выходные данные превращаются в монстров Иногда взломщик обходится без тэга

Брюс Лебан (Bruce Yung-Шин Лин (Yung-Shin Lin) по прозвищу Стив XXIV Введение (Steve Эрик Липперт (Eric Lippert), Лайонс (Matt Эрик Олсон (Erik Olson), Дейв (Dave Quick), Шелест (Art Дэниел Сай (Daniel Sie), Франк Свидерски (Frank Мэтт Томлисон (Matt Крис Уокер (Chris Walker), Лэнди Ванг Wang), Джонатан Вилкинс (Jonathan Wilkins) и Марк (Mark Мы также говорим «спасибо» всему отделению Windows за комментарии, пе дантичные замечания и уточнения — к сожалению, упомянуть каждого не пред ставляется возможным!

Некоторых хочется поблагодарить особо за то, что предоставили много мате риала для этой книги, причем основная его масса появилась в процессе кампа ний по безопасности соответствующих продуктов. Брэндон Брей (Brandon Bray) и Фокс (Raymond значительно помогли при сборе сведений о переполнении буферов. Дейв Росс (Dave Ross), Том (Tom и Ричи Лай (Richie — три ведущих эксперта по безопасности в Web, особенно по кросс сценариям. Благодаря Джону (John McConnell), Эль-Гаммалю (Mohammed и Беннетт (Julie Bennett) написана глава о проблемах при поддержке других языков, а работать с ними было огром ным удовольствием. Глава о безопасности кода в осталась бы схематичной, если бы не помощь Эрика Олсона и Ивана Медведева;

особое спасибо Ивану за его идею «безопасности доступа к коду в картинках». Адриан Они (Adrian и Питер Вискарола (Peter из компании Open Systems Resources Inc. опе ративно создавали для нас примеры обращения с устройствами и режимом ядра.

Джей Си Кэннон Cannon) взял на себя написание главы о конфиденциально сти. Наконец, Джонс (Ken Jones), Тодд (Todd Дейвид Райт (David Wright), Ричард Кэри (Richard Carey) и МакКей (Everett McKay) предоста вили массу материала, который лег в основу главы о документации. Глава о вы полнении анализа безопасности кода значительно улучшилась благодаря исклю чительно полезным консультациям и рекомендациям Рамси (Ramsey Dow) и презентации PowerPoint Нейла Вадиму Эйдельману принад лежит детальный анализ потенциальных проблем, возникающих при использо вании и решений, которые вошли как в эту книгу, так и в ста тью базы знаний Microsoft Knowledge Base. Ваша готовность предоставлять такой богатый и обширный материал заслуживает самой высокой похвалы и благодар ностей.

А эти люди помогли нам при работе над первым изданием, и за это мы гово рим им огромное Эли (Eli Allen), Джон (John Томас Демл (Thomas Моника Эне-Пиетросану (Monica Ene-Pietrosanu), Шин Фин неган (Sean Finnegan), Тим Флихарт (Tim Fleehart), Дамиан Хаасе (Damian Haase), Дейвид Хаббард (David Hubbard), Луи Лафреньер (Louis Lafreniere), Брайан ЛаМакчья (Brian LaMacchia), Джон Ламберт Lambert), Лоренс Ландауер (Lawrence Lan dauer), Пол Лич (Paul Leach), Липер (Terry Leeper), Максимо (Rui Maximo).

Дэрил Песел Pecelj), Джон Пискас (Jon Pincus), человек по прозвищу Forest Фриц Сэндс (Fritz Sands), Эрик (Eric Schultze), Алекс Сто ктон (Alex Stockton), Хэнк Войт (Hank Ричард Уард (Richard Ward), Ричард Веймир (Richard и Марк (Mark Zhou).

Введение XXV Много тех, кто не работает в Microsoft, пожертвовали своим временем, помо гая нам в работе над этой книгой. Мы благодарны Питеру (Peter Стиву Хейру (Steve Hayr) из компании Accenture, Кристоферу Клаусу (Christopher Klaus) из Internet Security Systems, Джону (John Pescatore) из Герберту Эйч Томпсону (Herbert H. Thompson) и Джеймсу Эй (James A. из Florida Tech и, наконец, Крису (Chris по про звищу «Weld из компании @Stake.

И самое важное мы хотим всех и каждого в корпорации за то воодушевление и рвение, с которым они отнеслись к инициативе тельные Огромное СПАСИБО вам всем!

БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ СЕГОДНЯ Необходимость защиты систем Защищенное ПО программа, которая обеспечивает кон и доступность информации кли ента, а также и вычислительных ре сурсов, управляемых владельцем системы или системным адми нистратором.

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

Источник: Microsoft.com развитием Интернета связи между приложениями, даже удаленными, стано вятся все теснее. В старые добрые времена компьютеры работали практически не зависимо друг от друга, причем связь между ними либо вообще отсутствовала, либо была очень слабой, а защита приложения считалась не столь важной: самое пло хое, что могло случиться, — разрушение системы на одной отдельно взятой ма шине. И пока приложение успешно справлялось со своими задачами, мало кого волновала его незащищенность. Подобный подход хорошо заметен во ставших классическими книгах начала 90-х. Так, на 850-ти страницах блестящей монографии Стива Макконела (Steve (Microsoft Press, практически не нашлось места проблемам безопасности. Не поймите нас превратно это дей ствительно замечательная книга, одна из тех, что в обязательном порядке долж ГЛАВА 1 Необходимость защиты систем быть в личной библиотеке каждого разработчика. Просто за информацией о безопасности вам придется обратиться к иным изданиям.

Теперь же другие времена. В эру Интернета практически все компьютеры — серверы, ПК, карманные компьютеры и прочие специализированные такие как AutoPC и встраиваемые системы, а в последнее время даже сотовые лефоны — объединены линиями связи. Это, конечно же, расширяет сти разработчиков и открывает потрясающие перспективы для бизнеса, такие устройства легче атаковать. В частности, не для работы в развитой сетевой (и поэтому потенциально недружественной) сре часто снижают общую защищенность компьютерных систем, делая их воспри имчивыми к атакам. А все потому, что разработчики просто не что приложению придется работать в сети и оно может стать легкой добычей ленников. Задумывались ли вы когда-нибудь, почему World Wide Web часто назы вают Wild Wild Web* ? Прочитав эту главу, вы поймете причину. Интернет — враж дебная среда, и любой код должен атак Мы не В пятницу, 13 июля 2001 года, хакеры изуродовали страницы Web-сайта института системного администрирования, сетевых технологий (System Administration, Networking and Security Institute, SANS) — ;

Ha следующей неделе SANS по почте всем подписчикам своего сетевого издания го Это хорошее напоминание о мо жет атака. Следует образом абсолютно все программы и их параметры и так, чтобы они не только атакам сегодняшним, но что года два.

рые наши сервисы дней, Действительно, Интернет — это враждебная среда. Подробнее о злона меренной модификации страниц сайтов (defacement) — на Web-странице Внимание! Никогда не следует рассчитывать, что ваше приложение будет ра ботать в заранее известных условиях. Наверняка «умники», использующие в конфигурации, которую вы ну никак не могли предвидеть. Рассчитывайте на худшее: на работу в исключитель но агрессивной среде, поэтому проектируйте, пиши те и тестируйте код с учетом именно таких условий.

Нелишне также помнить, что защищенная система — это качественная систе ма. Приложения, при создании которых с самого начала во главу угла дикий Web, по аналогии с Wild Wild West (Дикий, дикий Запад). — Прим.

Часть I Безопасность приложений сегодня более надежны, чем те, защита которых достраивалась ку». Защищенные продукты меньше критикуются средствами массовой информа ции, они более привлекательны для пользователей, а их сопровождение обходится дешевле. Высококачественный продукт немыслим без должного уровня безопас ности, поэтому придется при помощи пряника, а в особо тяжелых случаях и кну та, заставлять всех членов команды разработчиков помнить о безопасности кода.

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

Приложения в «дикой» Web-среде Мы часто размещаем компьютер в Интернете только для того, чтобы посмотреть, что с ним случится. Обычно не проходит и нескольких дней, как его обнаружи вают, исследуют и атакуют. Такие компьютеры обычно называют приманкой (honey их используют для наблюдения за действиями хакеров.

Примечание Чтобы больше узнать о приманках и о том, как хакеры проника ют в компьютерные системы, рекомендуем познакомиться с проектом (project.honeynet.org).

Мы наблюдали процесс обнаружения и атаки компьютера, когда в середине 90-х работали над Web-сайтом на котором защиту Windows 2000 тестировали в условиях Сейчас этот не кционирует. В пятницу мы тихо разместили Web-сайт в Интернете, а к понедель нику его уже массированно атаковали. И это несмотря на то, что мы о нем му ничего не говорили.

Смысл сказанного ясен, как белый день, — атаки неизбежны. Хуже того, сейчас перевес явно на стороне хакеров, и в разделе «Правила мы объясним почему, Некоторые взломщики действительно относятся к разряду и талантливых. Они вооружены глубокими знаниями о компьютерах, и у них масса энергии и времени на исследование приложений на предмет уязви мости. Не скрою, я с уважением отношусь к некоторым из этих ребят, особенно к так называемым шляпам» (white-hats), или «хорошим» хакерам, которые исследуют защиту систем в «мирных целях»;

со многими из них я знаком лично.

Лучшие представители племени «белых хакеров» тесно сотрудничают с произво дителями ПО, в том числе с Microsoft. Обнаружив серьезную брешь в системе безопасности, они сообщают об этом производителю. Тот принимает соответству ющие меры: выпускает «заплату» или предлагает пользователям изменить конфи гурацию приложения. Такой подход помогает Интернет-сообществу не оказаться безоружным перед вандалами, которые, обнаружив уязвимое место, проводят широкомасштабную атаку.

Большинство взломщиков — просто глупые вандалы, их еще называют люби телями (script kiddies), Они мало разбираются в защите и способны атаковать незащищенные системы, лишь пользуясь сценариями (scripts), созданными более Дословно с медом*. — ГЛАВА 1 Необходимость защиты систем грамотными взломщиками — теми, кто находит бреши, документирует их и пи шет код, их (в английском такой код называется exploit или просто exploit, есть и более короткий вариант — О том, как обнаружили тестовый Web-сайт Вы, что никто не найдет компьютер, «втихую» размещен ный в Интернете? А зря. сайт Windows 2000 обнаружили чески сразу, и вот как это произошло. (Не переживайте, если вам мы некоторые понятия в этом рассказе — мы их объясним далее по ходу изложения.) Кто-то (взломщик), сканируя внешние IP-адреса, щие Microsoft, обнаружил новый действующий IP-адрес — он принадлежал нашему серверу. Затем взломщик проверил порты сервера, выясняя, какие из них открыты. Эта процедура называется сканированием портов (port scanning). Открытым оказался только 80-й — порт протокола передачи ги пертекста (Hypertext transfer HTTP). наш «друг* направил на сервер с командой HEAD, пытаясь выяснить, какое сервер ное ПО на Web-сервере. Это был Internet Services 5), который на тот момент еще официально не Затем взлом щик запустил Web-браузер, ввел IP-адрес сервера и узнал, что это тестовый Web-сайт, Windows 2000, и его до менное имя — он отправил сообщение о своей находке на сайт и уже через несколько часов,•• под массированной атакой.

Подумать а ведь что мы сделали, — разместили сайт в Ин тернете! И только.

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

скажем — приятного мало. Пытаясь решить проблему, люди начинают метаться и суетиться. Хаос наяву! Лучше заблаговременно принять все возможные исключить подобную ситуацию, и здесь единственный способ — защищенные приложения, способные противостоять атакам.

Конечно, этот аргумент эгоцентричен — я рассмотрел проблему с точки ния разработчика. В долгосрочной перспективе система обойдется вам дорого и испортит вашу что, в свою очередь, повлечет падение даж, отток переключение их внимания на продукты конкурентов, ко торые, как им кажется, лучше защищены. А теперь предлагаю взглянуть на блему с точки зрения, которая действительно важна, — с конечн' > го пользователя!

Покупатели хотят, чтобы приложения работали, как сказано в ламе и как им самим того хочется. «Взломанные» программы не обеспечивают того, ни другого. Ваши приложения обрабатывают, хранят возможно, Часть I Безопасность приложений сегодня ют конфиденциальную клиентскую и корпоративную информацию. Пользовате лям не хочется, чтобы информация об их кредитных картах оказалась в Интер нете, чтобы кто-то получил доступ к их медицинским данным или чтобы их сис темы оказались инфицированы вирусами. В первых двух ситуациях имеет место проблема сохранения тайны пользователя, а в последнем — возможный отказ системы и потеря данных. Именно ваша обязанность создавать приложения, ко торые позволяют клиентам использовать по максимуму их компьютерные систе не опасаясь потери данных или вторжения в частную жизнь. Если вы нам не верите, спросите их сами.

Необходимость доверительных вычислений Надежные, или вычисления (trustworthy computing), — это не просто очередная маркетинговая кампания, а серьезный в сторону защищенности продуктов Microsoft и, хотелось бы надеяться, всей отрасли. Вот, к примеру, теле фон: в начале прошлого века казалось чудом, что он вообще работает. Поначалу абоненты не придавали особого значения тому, что телефоны работают не все гда или что нельзя позвонить в отдаленные места. Люди спокойно относились даже к таким неудобствам, как спаренные линии. Чудом казалось уже то, что можно разговаривать с тем, кто не находится в одной комнате с вами. По мере совер шенствования телефонные системы все чаще использовались в повседневной жизни. И как только они распространились повсеместно, люди стали восприни мать их как должное и полагаться на них в критических ситуациях. (Аналогично менялось и отношение к электричеству.) Это та степень надежности, к которой следует стремиться и в ИТ-отрасли. Компьютеры должны работать бесперебой но, выполняя задачи, для которых не «падать» из-за получения пакета с вредоносными данными и тех, кого не Безусловно, многое предстоит сделать, чтобы компьютеры по-настоящему за воевали наше доверие. Предстоит решить множество сложных напри мер, как сделать системы самовосстанавливающимися Зашита боль ших компьютерных сетей — также очень интересная и нетривиальная Эта книга как раз и посвящена созданию систем, на которые можно положиться пол ностью, «Танцуют Фраза превыше должна стать корпоративным девизом, ведь, как известно, необходимость поставлять защищенное ПО сейчас важна, как ни когда ранее. Пользователи требуют защищенных приложений и считают это сво им правом, а не привилегией. К тому же менеджеры отдела продаж конкурирую щих фирм не поленятся лишний раз напомнить вашим потенциальным клиентам, что ваш код небезопасен и ненадежен. Итак, ясно, что необходимо создавать в компании идеологию безопасности. Но с чего же начать? Лучше всего сверху, но это потребует немалых усилий. Вам придется доказать начальству, что укрепле ние защиты улучшит показатели прибыльности компании. Безопасность часто воспринимается как досадная помеха, к тому же очень затратная и совсем (или практически) не дающая положительного финансового результата. Кроме того, от ГЛАВА 1 Необходимость защиты систем вас потребуется масса такта, хотя иногда и откровенно партизанские действия нелишни. Итак, что имеется в виду под методами Тактичные методы пропаганды идей безопасности Для демонстрации что защищенные приложения — благо для вашего неса, требуются аргументы — и весомые. Лучшими можно считать те. что непо средственно касаются прибыли компании. Вам следует достаточно прозрачно объяснить руководству, что ими, скорее на бизнесе.

Защищенный — качественный Эту легко «продать» вашему руководству. Достаточно спросить, заинтересо вано ли оно в создании качественного продукта. Здесь единственный правильный ответ — да! В противном случае мы бы вам поискать другом месте — там, где качество.

Ну ладно, ладно, мы немного упростили, ведь мы не говорим об идеальном программном обеспечении. (Как шутят специалисты по безопасности, защищена та компьютерная что выключена и захоронена в кере;

но и ее безопасность обеспечена не «на все Мы говорим о рое достаточно и качество которого соответствует условиям его ты. Так, на защиту игры потребуется существенно меньше времени и чем на создание подсистемы безопасности приложения, работающего с ми военной разведки или медицинскими записями.

Необходимость и уровень защиты определяются конкретной ситуацией — так же, как для разных целей требуются разные решения. — однако заведомо вестно одно: защита является Не защищенный должным образом продукт проигрывает. Некоторые подумали, что безопасность также яв ляется подмножеством но все зависит от того, что понимать безопасностью. Так, защищающее секретные данные, не обязательно быть надежным. Систему, которая регулярно но не секретность по-прежнему можно считать Как показано на рис. 1-1. забота о или надежности означает борьбу за безопасность.

Зачем нужна безопасность в сетевой игре Это может показаться странным, но игры тоже подвергаются кам. Представьте, что вы сетевую стра тегическую игру типа Age of Empires 2, но что игрок может другого, ему вредо носный пакет Чувствуя, что проигрывает, нечестный игрок просто отправляет «пакет оппоненту. Такое поведение вряд ли можно на звать но оно возможно, и ваша задача — оградить пользова телей от подобного Часть I Безопасность приложений сегодня Качественное ПО Рис. 1-1. Защищенные программы — подмножество качественного и надежного ПО Пресса (и конкуренты) косточки» вашей программе Нравится вам это или нет, но СМИ хлебом не только дай пошуметь о про блемах с безопасностью. Журналисты не всегда понимают, о чем пишут, и часто в погоне за сенсацией делают из мухи слона. Почему бы не проигнорировать одни факты и не сгустить краски, описывая другие? Люди склонны верить прочитан ному или услышанному, поэтому, если о недостатке — серьезном или не очень — в защите вашей программы говорилось на первой полосе, будьте уверены — со трудникам вашего отдела продаж и маркетинга после придется долго расхлебы кашу, рьяными Поговорка о том, что «любой скан дал — прекрасная в случае проблем с безопасностью просто не работа ет. Такая «реклама» подтолкнет клиентов в объятия конкурентов с их вро де бы более надежными продуктами.

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

Не становитесь жертвой Существует распространенное заблуждение, что люди, способные взломать сис тему, ее и защитить. Есть особая каста которые счита ют, что чем больше «скальпов» в их послужном списке, тем серьезнее их воспри потенциальные клиенты. Вы ведь не чтобы ваша программа ста ла очередным скальпом в их коллекции!

ГЛАВА 1 Необходимость защиты систем Устранение недостатков — дорогое удовольствие Как и любые конструкции устранение недостатков защиты на поздних этапах разработки обходится значительно дороже. Сложно определить точную сумму из-за большого числа нематериальных к которым ОТНОСЯТСЯ:

• на координирование процедуры исправления;

• оплата работы разработчиков, отыскивающих кода;

• оплата работы программистов, исправляющих код;

• проверяющих код после внесения корректировок:

• на тестирование программы установки исправлений;

• затраты на создание и версий для разных языков;

• затраты на цифровое подписание пакета если я технология подписи кода, например • стоимость публикации пакета исправлений на Web-сайте;

• оплата создающих документацию для пакета • расходы на PR-кампанию, направленную на устранение плохого впечатления от наличия дыр в защите ПО;

• аренда линии у Интернет-провайдера (ISP);

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

• затраты клиентов на установку пакета Им придется сначала тановить исправления на тестовом сервере и проверить, как исправленное приложение станет работать в их Опять-таки — люди, занятые те и пакета могли, по идее, потратить это на более полезную работу;

• и, наконец, потерянная прибыль из-за что потенциальные клиенты ре шили отложить или вообще отказались от использования вашего продукта.

Как видите, стоимость внесения одного исправления в систему безопасное] и тянет на десятки, если не на сотни тысяч долларов. А что стоило поставить ( во главу угла при проектировании и разработке продукта!

Примечание Несмотря на сложность определения точной суммы затрат при выпуске пакета исправлений системы безопасности, Центр по Microsoft (Microsoft Security Center) полагает, что брешь в защите, требующая выпуска бюллетеня, обходится приблизительно в 000 долларов.

Рекомендуем один откуда можно почерпнуть массу веских о : нований для назначения безопасности высокого приоритета — раздел интеллек туальной собственности и преступлений (Computer Crime and Intellectual Property Section, на Web-сайте Министерства юстиции США www.cvbercrime.gov). Здесь собрано огромное количество рассказов об уголовных Часть I Безопасность приложений сегодня делах, связанных с компьютерными преступлениями, а также описание ущерба, выраженное в конкретных суммах. эти данные генеральному директо ру — возможно, он не представляет, во что обходится нарушение системы безо пасности.

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

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

• удаленная остановка — серьезный недостаток;

• атаку удавалось выполнить анонимно;

• возможно написать сценарий (script) для автоматизации атаки, которым с ра достью воспользуются любители;

• на исправление ошибки команде достаточно одного работы (так почему бы это не сделать сейчас, пока не • если ошибку исправить то в долгосрочной перспективе вырисовыва ется значительная экономия • мы помочь команде простой, эффективный план устранения бреши, сводящий к минимуму вероятность возникновения регрессионных ошибок.

Что такое ошибка (regression bug)? Когда очередное исправле ние нарушает работу приложения, говорят, что произошла Это неред ко возникает при исправлении связанных с защитой. По опыту могу ска зать, что регрессия — номер один того, почему после исправления ошибки в защите тестировать нужно еще чем до этого. Ведь вам не хочется, чтобы после ошибки в защите перестала работать какая-нибудь другая очень важная функция приложения.

Но веские аргументы остались без внимания. Нас это очень волновало, так как была действительно серьезной. К тому времени мы уже написали простой сценарий па удаленно останавливающий приложение. И нам пришлось выступить в роли дяди»: мы остановили приложение, работающее на сервере команды, где выполнялось тестирование. Каждый раз, когда они пере запускали мы его Это было несложно. При запуске программа открывала порт протокола TCP (Transmission Control Protocol), поэтому мы модернизировали свой Perl-сценарий: теперь он отслежи вал порт, и как только тот подавал признаки жизни, сценарий приложе ние специальным пакетом данных. Разработчики исправили ошибку, поскольку на шкуре какая незавидная судьба ожидает пользователей, ГЛАВА 1 Необходимость защиты систем При ближайшем рассмотрении ошибка — заурядное переполнение буфера — и исправление оказались тривиальными.

Примечание Подробнее о переполнении буфера рассказано в главе 5, Есть еще трюк, йо его использовать только в крайнем слу чае — атака нуждающегося в исправлениях приложения, которое установлено на компьютере одного из топ-менеджеров. Подумайте сами: компьютером какого из вице-президентов нужно завладеть (own), чтобы было принято решение об уст ранении ошибки?

Примечание Что в данном случае означает слово (own)? На хакер ском сленге это означает получить полный несанкционированный до ступ к компьютеру. Часто говорят, что система (owned — принадлежит). Да-да, написано правильно! Хакеры любят смешивать числа и буквы при написании слов. Например, цифра «3» обозначает букву (видимо, из-за сходства с перевернутой большой английской буквой цифра «О» обозначает букву «О» и так далее. Может, вы также слы шали, как говорили о (rooted) системе или как кто-то стал (root). Эти термины происходят от названия учетной записи которая в Unix называется Учетные записи Administrator (Администратор) или SYSTEM в ОС Microsoft Win dows имеют такой же уровень доступа.

Конечно, это радикальная мера. Мы никогда не выкидывали подобных фоку сов;

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

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

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

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

Убедите начальника обратиться к сотрудникам с заявлением на тему безопасности Если вам удалось привлечь внимание босса к животрепещущей проблеме, теперь следует убедить его довести мнение по данному вопросу до сведения всех сотруд ников. Простейший способ — разослать сообщение электронной почты или слу записку, в которой почему ставится главу угла. Один из лучших образцов, который мне удалось увидеть лично, — послание Джима (Jim Allchin), вице-президента группы Windows в Microsoft. Вот отрывок из письма, адресованного разработчикам Windows:

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

за защищенность Windows XP лежит на каж дом. Я говорю не о возможностях подсистемы защиты, а о качестве реализации каждой возможности.

Если станет о дырах в защите той части продук та, за которую вы отвечаете, сообщите об ошибке и поза об оперативном ее прежде чем продукт попадет к нас лучшая вмире команда разработчиков, прекрасно зна ем, что должны создавать код без проблем с — и точка. Я не хочу, чтобы после выпуска в XP бреши в подвергающие риску наших клиентов, Джим Джим выразился предельно ясно и недвусмысленно. Суть его послания проста: безопасности присваивается наивысший приоритет. Когда такие письма приходят «сверху», чудеса становятся возможными наяву. Конечно, это не озна чает, что в продукте не останется ни одной ошибки. Если уж говорить откровен но, то после выхода Windows XP несколько ошибок подсистемы безопасности все ГЛАВА 1 Необходимость защиты систем таки было найдено, и вряд ли они последние. Но направление ясно: под планку от версии к версии с тем, чтобы дыр обнаруживалось и меньше.

Самый громкий призыв к из в январе когда Билл Гейтс разослал всем сотрудникам компании памятную записку Дове вычисления» (Trustworthy Computing), в которой более защищенных и приложений по причине возрастания угрозы компьютерным Интернет три года назад разительно отличае ся от Сети — она куда враждебнее, и необходимо проек с учетом этого. меморандума Билла Гейтса вы на Web-стра - Возьмите в штат поборника безопасности Полезно иметь в штате одного или нескольких сотрудников — активных пропч идеи безопасности, людей, в полное мере насколько важ] компьютерная безопасность для компании и ее клиентов. Они станут своего рода который потянет за собой остальных сотрудников. Па такого пр безопасной работы систем можно возложить следующие • быть в курсе всех новинок в безопасности;

• собеседования с кандидатами в команду поддержки процедур бе зопасности в компании;

• учить сотрудников, как обеспечивать безопасность;

• назначать вознаграждения за самый безопасный код или за самое исправление ошибки защиты. В качестве вознаграждения годится все: денеж ные премии, отгулы, выделение персонального почетного места парковки месяц — да мало ли что еще;

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

Держите руку «на пульсе» На сегодня имеются два лучших ресурса с постоянно обновляющейся цией: сайты NTBugTraq и целиком посвящен NT, а на втором рассматриваются более общие вопросы. Поддержку NTBugTraq ляет Купер (Russ Cooper), а подписка на рассылку доступна на сайте www.ntbugtraq.com. BugTraq, объединяющий самые известные списки посвященные брешам в защите и их обнаружению, поддерживается компанией принадлежащей в настоящее время Symantec Corporation. Подписав шись на рассылку на сайте вы ежедневно станете по лучать около 20 писем. Знакомство с о новостях в сфере безопас ности из публикаций NTBugTraq и BugTraq должно стать частью ежедневной по безопасности, Рекомендуем обратить внимание и на другие предложения такие как Pen-Test и Sec-Prog.

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

Интервьюируя в Microsoft на позиции, связанные с мы обращаем внимание на качества претендентов, в том числе на:

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

• горячее желание создавать защищенное ПО, удовлетворяющее реальным тре бованиям пользователей и бизнеса:

• способность находить (но приемлемые в конкретной ситуации) способы применения теоретических знаний о безопасности;

• способность предлагать конкретные решения, а не просто ставить вопросы, Жаловаться на проблемы — штука нехитрая;

• способность понимать ход взломщика;

• способность изменить заданную роль. Часто требуется способность действо вать, как атакующий. Да-да, чтобы дать отпор хакерам, вы должны уметь делать то же, что и они.

Несколько слов о Как уже говорилось, обязан разбираться в практических проблемах безопасности, которые Это крайне важно. Есть люди, способные обнаружить и перечислить защиты системы, но ими способы решения часто совершенно Этим, как правило, компьютерные фанаты и ватели. Они знают самые заковыристые возможности системы и значение сообщений об ошибках, и им кажется, что обычные владеют таким же знанием. Им трудно залезть в шкуру поэтому они просто не понимают их проблем. А ваше ПО приобрета ют организации, вы должны понимать не но и ИТ~ менеджеров: знать, управляют компьютерами и серверами.

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

что повторяемся, но все-таки: человек должен делать то, что ему нравится, в случае следует просто сменить дело.) Другая важная составляющая — это опыт, особенно набитые при латании защиты в условиях «реального Такой опыт дорогого и им необходимо делиться с коллегами, В 2000 году началось затяжное снижение американского рынка, что очень многим игрокам стоило кучу денег. Как нам кажется, это произошло того, что их финансовые консультанты не имели опыта «медвежьего» рынка. В их памяти только хорошие времена, когда рынок уверенно рос, и они давали своим клиентам единственный совет — вкладывать деньги в сильно переоцененные К счастью, финансовый консультант Майка (одного из авторов этой ги) много повидал на своем веку и поэтому принял за него ряд мудрых решений, Благодаря ему Майк пострадал не так как большинство. Если вы ге с подобным опытом, держитесь за него обеими руками.

Организуйте процесс непрерывного обучения Ожидая первого ребенка, один из авторов с женой посещали курсы по первой помощи новорожденным. Когда в конце занятия инструктор, врач >й помощи, нет ли у нас вопросов, наш автор руку и зал, что уже завтра присутствующие забудут большую часть сказанного, поэтому спрашивается: что инструктор посоветует, чтобы не утратить навы ки. Ответ был прост: еженедельно перечитывать конспект курса и практиковать ся. То же самое справедливо и отношении безопасности: вы добиться, чтобы ваши не очень сведущие в безопасности коллеги получили возможность но освежать знания. команда «Безопасная Windows» Win dows Initiative) в Microsoft выбрала следующую тактику:

• создала сайт в интрасети, посвященный безопасности. На него обращаются при возникновении любых проблем с безопасностью:

• опубликовала «белую книгу» (white в которой описаны практикой методы обеспечения безопасности. По мере обнаружения и устра нения брешей в создаваемом ПО процесс латания дыр тщательно документи ровался и эта информация публиковалась для открытого доступа всем сотруд никам;

• организовала борьбы с ошибками»: сначала учебные занятия, а затем пе ресмотр созданного кода, проектной документации, планов тестирования и документации на предмет проблем с Ведение реестра ошибок вызвано не только желанием ошибки. за подобна домашнему заданию — она позволяет закрепить знания, полученные в ходе занятий. Отлов — это «холодный десерт» дня с ошибками:

• еженедельно рассылала по электронной почте командам разработчиков сооб щения с описанием брешей в системе безопасности и просьбой определить проблему. В сообщении они размещали ссылку на Web-сайт с робную о том, как устранить ошибку, и инструменты или риалы, которые можно использовать для поиска подобных ошибок в 16 Часть I Безопасность приложений сегодня Мы считаем такой подход очень полезным, поскольку он каждую неделю на поминает людям о соблюдать безопасность;

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

просто проинформировать об ошибках в коде — нужно стремиться к полному их искоренению.

Классифицируйте ошибки системы безопасности Иногда приходится принимать решение: устранять или нет ту или иную брешь.

Если вы столкнулись с ошибками, которые проявляются редко, не приносят боль шого вреда и тяжело поддаются исправлению, не торопитесь исправлять ошибку а отразите ее в документации как ограничение. Однако серьезные ошибки в под системе безопасности следует обязательно исправить. и приня тие о методах устранения и определение исправления ошибок лежат целиком на вас.

Правила боя Мы объяснили, зачем создавать системы, и предложили несколько простых способов воспитания в компании культуры безопасности. Однако не следует забывать, что мы, всегда «идем вторым Проще говоря, мы, как защищающиеся, должны более надежные системы, так как преимущество у нападающего.

Любое ПО, которое на компьютер, особенно подключенный к необходимо защищать. Имеется в виду то, что код приложения ста новится постоянно — 24 часа в 7 дней в неделю — доступным для атаки из любой точки земного тара. Поэтому он должен противостоять атакам, чтобы не стать причиной компрометации, повреждения, удаления или перлюстрации зло защищаемых системой ресурсов. В подобной, исключительно слож ной ситуации оказываются пользователи всех компьютерных систем. Это также создает проблемы производителям ПО, так как их продукты становятся потенци для атак.

А теперь об особенностях обороны и защиты.

ГЛАВА 1 Необходимость защиты систем Правило защищающемуся приходится охранять все слабые места, а нападающему достаточно выбрать одно из них Допустим, вы держите оборону в неплохо замке: каменные толщиной в 5 футов* с глубокий ров с водой, подъемный мост. Часо вые постоянно патрулируют стены замка, мост большую часть времени а когда его специальный отряд зорко следит за воротами. Вам позаботиться о хорошей экипировке стрелков, о средствах огня — на слу если вас обстреляют горящими а также о провизии на случай осады, Нападающему же достаточно отыскать всего одно слабое, плохо защищенное место, То же самое справедливо в отношении ПО: нападающему хватит единственной в защите вашего а вы обязаны «закрыть» все слабые места, Конечно, если какая-то возможность отсутствует — то есть не была или отсутствует в программе, — то и воспользоваться ею для атаки не удастся Правило №2: защищающийся готовится отразить известные атаки, а нападающий может разработать новые методы взлома Допустим, в вашем замке есть колодец, питаемый подземной рекой. Задумывались ли вы, что нападающий может проникнуть в замок именно через него, пройдя по руслу подземной реки? Помните историю падения Трои? Троянцы не опасности в подарке греков и поплатились за это жизнью.

Система безопасности ПО разрабатывается для теоретически вычислен ных или предугаданных атак. Так, разработчики 5 знали, как защитить от атак с символов (escape character) в но оказались не готовы к атакам с применением нестандартных ностей символов в формате UTF-8 — они просто не знали о существовании этой возможности. А хакер, изрядно отыскал-таки ошибку в обработке некорректных последовательностей символов. Подробный «отчет о проделанной опубликован на Web-странице Единственный способ защититься от атак заранее неизвестного типа — отклю чить все возможности программы, которые явно не востребованы пользователем.

Возвращаясь к аналогии с Троей, можно утверждать, что ничего бы не если бы защитники города не польстились на «подарок».

Правило №3: оборону следует держать постоянно, удар же возможен когда угодно Стража обороняющегося должна быть все время Нападающему в этом пл куда проще. Он может долго не проявлять себя и атаковать, когда ему будет удоб но. Иногда атакующий выжидает долгое время, тому же, кто держит оборону, при ходится быть готовым всегда. Это настоящая головная боль системных метра. — Прим.

Часть I Безопасность приложений сегодня которым приходится постоянно контролировать работу системы, про верять журналы, обнаруживать и отражать атаки. Таким образом, разработчики должны предусмотреть в ПО средства противостояния атакам и инструменты для мониторинга системы, пользователям выявить атаку.

Правило №4: защищающему приходится соблюдать правила, а нападающему не возбраняется вести игру» Хоть в мире ПО это и не всегда так, но по большей части это утверждение верно, В распоряжении защищающегося масса хорошо изученных разработан ных «белыми хакерами* (например, брандмауэры, системы обнаружения вторже ний, журналы аудита и «приманки») для защиты системы и обнаружения атак.

падающему же ничто не мешает прибегнуть к любому доступному ему средству проникновения в систему и обнаружения слабых мест в защите. И в этом случае преимущество на его стороне, Резюме Итак, что положение защищающегося не из приятных. Разработчикам ПО приходится создавать «постоянно бдящие* однако преимущество на стороне нападающих, и слабо защищенную программу они быстро взломают.

чтобы нейтрализовать нужно действовать весьма и весь ма умно. Говоря это, я все равно сомневаюсь, удастся ли нам когда-нибудь наго лову разгромить Интернет-вандалов — их много, так же как и доступ ных для атак серверов. Кроме многие атакуют компьютеры в Ин тернете просто потому, что им это удается! Вспоминается интервью с Джорджем (George который на «Почему вы хотите покорить Эверест?» ответил: «Просто потому, что он есть на свете». Но же мы в состоянии поднять планку защиты до такого уровня, что хакерам придется при знать, что атаковать наши программы слишком хлопотно, и поискать лучшее менение своим силам.

И, наконец, знайте, что безопасность занимает особое положение в мире ком пьютеров. За исключением разработчиков очень немногие люди (если таковые вообще имеются) активно интересуются вопросами масштабируемости и локали зации ПО. Однако многие склонны тратить время и деньги, чтобы в поте лица искать дыры в защите. Интернет — крайне сложная и агрессивная среда, и ваши приложения должны уметь выживать в ней.

Активный подход к безопасности при разработке приложений изданий, посвященных созданию безопасных программ, ограни только одной составляющей — кодом. Мы решили нарушить эту цию и рассказать обо что нам кажется важным: о проектировании, мировании, и документировании ПО. Каждый из этих процессов исключительно важен для создания безопасных систем, и. их, важно соблюдать жесткую дисциплину. Одного лишь добавления пары-тройки идей», горстки «лучших или поэтапных инструкций в не очень хорошо организованный процесс разработки недостаточно для существенного повышения безопасности конечного продукта. Мы познакомим вас с некоторы ми общими методами переориентации процессов разработки ПО на безопасности и уделим достаточно внимания проблемам образования и но безопасности, так как это критически важно для создания защищенных продук тов, кроме того, это наш любимый конек, а также детально обсудим методы паганды безопасности и внедрения жесткого контроля защиты на каждом этапе разработки.

А сейчас давайте почему большинство далеко не обделенных инт< л людей делает ошибки и оставляет ПО Вот основные по которым игнорируются требования по безопасности:

• безопасность смертную скуку;

• защита часто ограничивает функциональность продукта, она «путается под и мешает полноценной работе;

• безопасность сложно измерить:

20 Часть I Безопасность приложений сегодня • безопасность обычно представляет собой главную или пред мет заинтересованности и разработчиков;

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

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

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

Вторая причина — весьма распространенное отношение, отчасти на заблуждении. Согласно требованиям безопасности рекомендуется запретить пользователю доступ к функциям, которые ему не нужны. Представьте себе, что получится, если из соображений удобства использования (usability) приложение создано так, что персональную информацию и номера кредитных карточек кли ентов можно узнать без процедур аутентификации и ции. Ясно, что этими сведениями смогут воспользоваться том числе не моральными принципами субъекты! А теперь поставьте себя па место клиента;

можно ли считать безопасность препятствием», если из-за к ней ваши личные станут легкой добычей злоумышлен ника? Можно ли считать защиту «дурацким усложнением», если кто-то себя за вас? Знайте: облегчив доступ пользователей к конфиденциальным данным, вы упрощаете задачу С третьим аргументом придется но это не причина для создания «дырявых» программ. В отличие от производительности, которая поддается изме — цифры что из программ другой, — безопас не поддается оценке. Нельзя утверждать, что одна программа безопаснее другой, пока не выявлены все недостатки защиты в обоих приложе ниях (а это практически Понятно, что вы можете с пеной у рта спорить, что лучше защищено — А или приложение В, но вам никог да не удастся доказать, к примеру, что А на безопаснее В.

Тем не менее поддаются измерению и оценке улучшения в процессе разработки, например, количество прошедших обучение по безопасности, чис залатанных брешей в защите и т. п. Кроме того, можно быть уверенным, что в продукте заботящейся о безопасности организации скорее всего меньше «дыр», чем в приложении той компании, которая не обеспокоена безопасностью своих изделий. Есть и кое-что еще: вы всегда можете оценить эффективную «площадь своей программы. Подробнее об этом — в главах 3 и 19.

И последнее: чем больше в программе, тем выше вероятность обна ружения дыр, ведь взломщик каждую функцию. Новые возможнос ти сути своей опаснее, проверенные и активно используемые, но большин ство как люди предпочитают решать новые задачи, со здавать новые функции или выдумывать новые способы реализации старых. Билл Гейтс подчеркнул это в своем «Доверительные вычисления»:

ГЛАВА 2 Активный подход к безопасности при разработке приложений :

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

На рис. показаны некоторые новшества, позволяющие повысить ответствен ность сотрудников и улучшить структуру процессов разработки ПО с точки зре безопасности. В спиральной модели достаточно предусмотреть процедуры, а если вы используете водопадную модель (waterfall approach), про сто позаботьтесь о дополнительных этапах ниже течению», в режиме. А сейчас детально об особенностях подобных операций.

О О О О Обсуждение Моделирование Определение Кампания Обратная вопросов опасностей предельного экспертиза по обеспечению связь числа ошибок безопасности процессе в ора требований и в конце и у клиента 1 / Разработка • \ Концепция Готовые планы Готовь и Поставка проект тестирования код Легенда \ I 1 непрерывно Анализ Тесты старых ошибок командой. на отсутствие • кода Обучение отвечающей мутации данных • по ) безопасного кода О за безопасность и исполнение при минимальных О Рис. 2-1. Укрепление защиты в процессе разработки ПО на каждом этапе Вы увидите, что многие этапы выполняются итеративно и непрерывно. Так.

сотрудников в группу набирают не только в начале проекта — это составляющая часть процесса.

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

22 Часть I Безопасность приложений сегодня Необходимость обучения Я уже говорил, что обучение безопасности — мой конек;

точнее, недостаточность такого обучения — мой любимый «мальчик для А особо потешить эту свою слабость мне пришлось в первой четверти 2002 г., когда в Microsoft объявили кам панию по укреплению безопасности Windows (Windows Security Push). В рамках этого мероприятия мы за десять дней обучили примерно 8500 человек. Да. да, я не оговорился! Мы чтобы все члены всех команд, участвующих в создании кода, попавшего на установочный диск Windows (а число команд за шкаливает за 70), посетили семинары, в том числе и вице-президенты! Мы разра ботали три курса, и каждый пришлось 5-6 раз. Первый курс адресовал ся разработчикам, второй — а последний — менеджерам проек тов. (В Microsoft менеджеры проектов отвечают полностью за весь набор функ ций приложения.) Специалистам по документации предлагались курсы в соответ ствии с областью, в которой они работают. Вы не поверите, но нашлись мазохи прослушавшие все три курса!

К чему мы клоним? Мы считаем эту акцию необходимой. Успех по безопасности невозможен без повышения понимания и сознательности каждого сотрудника. Дэвид, второй из авторов этой любит повторять: «Люди хотят делать но подчас не как это — В этом им нужно помочь». Многие программисты как внедрять в ПО функции безопасности, но большинству из них никто не как создавать безопасные системы. Я убежден, что в институте учат неправильно или, по мере, не всегда преподают «правильные» вещи. Не поймите меня превратно: в обучение играет роль, но все начинается в учебном Лучше всего объяснять, что мы имеем в виду, на примере. В феврале 2002 г. я временно прервал участие в Windows Security Push для участия в круглом столе на «Симпозиуме по безопасности сетей и распределенных систем» (Network and Distributed System Security Symposium, в Сап-Диего, на котором обсуждались вопросы В я упомянул о собеседова нии, которое провел за несколько месяцев до этого. Мне требовалось отобрать человека в команду Secure Windows Initiative, который бы оказывал другим груп пам разработчиков помощь в проектировании и программировании безопасных приложений. На интервью я спросил кандидата, как укрепить алгоритма шифрования с открытым ключом. Претен дент начал подробно рассказывать, о том что взять два очень больших простых числа Р и — в он стал пересказывать, как работает алгоритм но не как применять. Я повторил вопрос: меня интересует, не как рабо тает RSA (это черный ящик, созданный и профессионалами и, надо полагать, работающий именно так, как обещают его создатели), а как применить эту технологию для защиты. Кандидат признался, что не знает, и этого было до он работу в другом отделе, Кстати, вопрос, который я задал претенденту, звучал так: как применить RSA для того, чтобы клиент, продавший свои акции, не позднее отказаться от сделки, увидев, что цена акции выросла. Одно из решений — обеспечить поддер жку цифровой подписи по алгоритму RSA и задействовать стороннюю организа цию-депозитарий для подписания и отметки и даты на распоряжении ГЛАВА 2 Активный подход к при разработке приложений клиента. Продавая акцию, клиент сначала направляет распоряжение организации, которая подтверждает его подпись, проставляет метку и подписывает распоряжение. подписанное и клиентом, и сторон ним депозитарием, защищает права брокера: теперь продавцу не так-то отказаться от своего слова.

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

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

Внимание! Пусть вашим девизом станет: безопасности = Безопасные По завершении круглого стола ко мне подошли пять профессоров, они бы;

и возмущены некорректностью моих вопросов на собеседовании и пытались убе дить меня, что понимание работы RSA исключительно важно. Я же стоял на сво ем: рассказать на экзамене о деталях механизма RSA проще а интерес но это лишь очень небольшому людей. Кроме того, ответ экзаменуемого легко оценить по шкале «верно — а вот умение справляться с опасностями и атаками — штука существенно более сложная, и его вряд ли испытанием. После оживленных сошлись на том, что обучение безопасных систем должно включать как основы изучения и атакам, так и особенности работы RSA и других механизмов защиты. Я остался исключительно доволен достигнутым компромиссом!

Но вернемся к Windows Security Push. Мы поняли, что необходимо обуча сотрудников построению безопасных систем, потому что в школе этого не пре подают. Мы осознали, что многие знают, как работает Kerberos, DES (Data Encryption Standard) и RSA, но этому знанию грош цена в базарный день, если человек ни когда не видел, как выглядит переполнение буфера в C++! Я часто повторяю:

знать того, чего не то есть если разработчик не знает, как делается пасный продукт, клиент никогда не получит защищенное Вот му нашей команде пришлось провести обучение 8500 сотрудников.

Сухой остаток таков: обучение методам необходимо, тем что ситуация в области защиты быстро так как обнаруживаются новые источники опасности. Поговорка: «То, что не известно, не может — в области защиты попросту не работает. Неизвестное может обезоружить (и очень вероятно, что так и выйдет) ваших клиентов перед серьезной опасностью. Курсы по защите следует сделать обязательными для всех работников (как в 24 Часть I Безопасность сегодня Это особенно важно для новых Не следует полагаться на то, что но вички что-то знают о безопасности систем!

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

Внимание! Обучение исключительно важно для того, чтобы создавать безо пасные системы. Не ждите, что люди знают, как програм мировать, документировать и развертывать безопасные системы;

они могут иметь представление о как работают механиз мы защиты, но от этого немного проку. В безопасности принцип «То, что не известно, не может повредить» не работает — пренебрежение неиз вестным чревато катастрофическими последствиями.

Отношение сотрудников к обязательному обучению Мы ожидали, что принудительные не понравятся сотрудникам и прием окажется прохладным, но мы ошиблись! В чем причина? Большинство компаний разработчиков ПО кишмя кишат энтузиастами информационных технологий, ко торых хлебом не корми — дай узнать что-то новое. А если занятие посвящено та кой «горячей» теме, как безопасность, то из аудитории их не выгнать. Так что дайте своим ИТ-фанатам информацию, которой они жаждут.

Примечание Раз уж мы заговорили об энтузиастах, не стоит недооценивать их стремление к первенству среди себе подобных. Большинство фанатов страстно увлечены своим делом и не прочь померяться силами, выяс няя, кто напишет самый быстрый, самый функциональный или самый маленький по объему код. Такие соревнования следует поощрять. Вот мой любимый пример «из жизни»: программист из команды по разработке сервера IIS 6 поклялся отдать свой талисман — гипсовую копию своего мизинца — тому, кто найдет дыру в его коде. Многие пытались, но, увы, никто не преуспел — приз никому не достался. Вы думаете, этот програм мист развлекался, объявляя награду? Конечно же нет;

он привлек армию профессионалов, чтобы те хорошенько код на предмет слабых мест. Программист не хотел оказаться крайним, автором дыры в защите, о котором трубить на всех углах. Вот так!

ГЛАВА 2 Активный подход к безопасности при разработке приложений Непрерывность обучения Это но истина в том, что каждую неделю появляются новые методы пли старых способов которые делают ранее про граммы уязвимыми для атак. По этой причине обучение разработчиков проводить В в нашей команде мы это делаем но: знакомим сотрудников с самыми свежими проблемами в области причинами проблем и способами смягчения последствий или полного устранения опасности. Мы гостей, которые расска о опыте защиты систем.

Развитие науки о безопасности Оказывается, обучение безопасности побочный эффект.

чив специалисты в конкретных предметных областях (а работая Windows, мы имели дело с создателями файловых систем, специалистами в сти локализации, HTTP, XML и др.) начинают задумываться о том, как злоумыш воспользоваться уязвимостью той или иной подсистемы (рис. 2 2), До основам безопасности обучения основам Рис. 2-2, Изменение сотрудников к проблемам безопасности после обучения защиты Акценты смещаются, становится придуманная на ходу поговорка:

«Кому функция, а кому и брешь в — специалисты с удивлением обнару живают угрозу безопасности в функциях, которые этого считали вполне бидными.

Совет Если у вас нет собственных специалистов по безопасности, те компанию, которая обеспечит осно ванное на реальном опыте обучение ваших 26 Часть I Безопасность приложений Внимание! Обучение безопасности преследует две цели. познако мившись с основами защиты, люди получают возможность контролиро вать создание а также находить и устранять недостатки за щиты, Но вторая и самая главная цель — научить сотрудников не созда вать дыры в защите продукта с самого начала!

Образование позволяет избавиться от заблуждения, что «лишняя пара глаз — всегда лучше» Я много раз слышал утверждение, что чем больше глаз изучают код. тем больше брешей удается найти и тем безопаснее код. Это вопиющее заблуждение! Люди, анализирующие код, должны знать и понимать, как выглядят уязвимые места.

Приведу аналогию. Написание книги совпало с периодом громких разоблачений компаний, занимавшихся фальсификацией финансовой отчетности.

себе, что исполнительный директор одной из таких компаний отвечает в Конг рессе США на вопросы, касающиеся учетной политики:

Представитель конгресса: У нас есть информация, что ваша компания представ ляла «липовые» отчеты.

Директор компании: Это неправда.

Представитель конгресса: Как вы можете это доказать?

Директор компании: Более 10 000 человек изучали наши отчеты, и ни один не нашел даже малейшего недостатка.

Представитель конгресса: Но каков уровень знаний этих в облас ти финансов? Где они получили бухгалтерское образование и ли им особенности учета в вашей отрасли?

Директор компании: Какая разница? Ведь 10 000 человек — это 10 000 пар глаз!

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

В 2001 г. я поставил простой эксперимент, желая подтвердить мою теорию о роли основам безопасности. Я обратился к двум моим знакомым: оба были технически подкованы и прекрасно разбирались в программировании. Я попро сил каждого проанализировать 1000 строк реального, взятого из от крытого кода на С и попытаться обнаружить в нем бреши. Первый "подопытный» нашел 10 второй — 16. Затем я прочитал им часовую лекцию с де монстрацией массы реальных примеров программистских ошибок, которые вы лились в дыры в защите, и как следует относиться к поступающим в программу. Закончив, я попросил их проанализировать код сно ГЛАВА 2 Активный подход к безопасности при разработке приложений ва. Вы мне но первый испытуемый нашел еще 45, а второй — Кстати, я сам обнаружил в программе только 54 недостатка. Таким образом, в общем зачете первый нашел 55 ошибок, т. е. на одну больше, чем я, а второй — 57, то еще две в придачу к нашим!

Если так очевидно, что позволяет разработчикам быстрее и нее распознавать недостатки защиты, то почему же люди продолжают верить, что нетренированные глаза и мозг способны повысить безопасность ПО?

Внимание! Горстка специалистов принесет больше чем армия неучей.

Интересный побочный образования персонала в заключается в том. что разработчики узнают, куда обращаться затруднениях, и не мучаются, повторяя одни и те же ошибки. Об этом свидетель ствует вал вопросов, поступающих в корпоративные новостные группы и спис си почтовой рассылки в Люди задают осмысленные вопросы, потому начинают понимать что к чему. Кроме того, образуется критическая масса сотруд ников, которые точно знают, что для разработки, те стирования и и эти люди положительно на остальных. Так удается снизить риск появления новых брешей в Сотрудников необходимо обучать безопасности! Эти знания не должны а ваться уделом элиты;

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

Проектирование В процессе создания любого ПО мероприятия по обеспечению безопасности следует проводить уже на стадии проекта. Я уверен, что вы знакомы с а ми исследования, показывающего, что на устранение бреши в защите на разработки придется потратить в 10 раз больше времени, денег и усилий, чем на ее искоренение на стадии и еще в 10 раз возрастает сложное гь исправления недостатка безопасности при тестировании и т.д. В этом мне при шлось не раз на собственном опыте. Я не могу привести точной в денежном выражении, но одно скажу с полной приходится исправлять то, что с самого начала разработано правильно и в корректировке не нуждается. Суть проста: начинайте мероприятия по обеспечению безопасности как можно раньше. А сейчас вы узнаете, как это делается на стадии проектирования.

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

уровень знаний будущего сотрудника следует с самого начала;

для этого в про цессе собеседования ему задают ряд вопросов по безопасности. Выяснив, что ка дидат имеет хорошие навыки в области защиты, берите его к себе ком панию.

Помните, что не стоит выяснять знание мельчайших деталей тех или иных технологий. Я уже говорил, что владение основами безопасности — это не 28 Часть I Безопасность приложений сегодня знание механизмов обеспечения безопасности, сколько умение грамотно нять их для защиты реальных систем, На собеседовании я нередко пишу на доске отрезок кода и предлагаю канди дату найти в котором возможно переполнение буфера. Да. это узкоспеци альная но программист должен безошибочно распознавать такую опасность.

Примечание Намного подробнее о буфера рассказывается в 5.

А вот еще одна любимая мной задачка:

«Правительство снизило цены на бензин, но при этом предписало всем вла дельцам оснащать свои автомобили устройствами контроля местоположения. Таким образом удалось точно определять пройденное расстояние и на этом основании начислять налог на пользование автотранспортными средствами. Предполагает ся, что устройство использует глобальную систему позиционирования GPS. Кан дидату предлагается ответить на ряд вопросов:

• как введение устройства скажется на неприкосновенности частной жизни:

• как устройство;

• как предотвратить жульничество со стороны недобросовестных автовладельцев;

• какой опасности подвергается устройство, если считать, что для предотвращения злоупотреблений в каждом будет храниться особый секретный код;

• кто должен программировать (записывать секретный код) устройство? Мож но ли доверять этим людям? Как решить эти Думаю, это очень полезный пример, потому что он помогает мне выяснить, как кандидат подходит к решению проблем безопасности. Причем задачка не глубоких знаний конкретных технологий. Рискуя не пере стану убеждать вас, что самое для создания безопасных приложений — правильный подход к решению проблем защиты. Можно объяснить человеку по дробности работы тех или иных технологий, но очень трудно изменить образ мышления, переориентировать его на безопасность. Принимайте на работу со трудников с наклонностями.

С другой стороны, вам пригодятся и люди с мышлением — те, кто способен выявлять неудачные проекты и указывать, как их следовало де лать с самого начала. «Хакеры* зачастую не способны предложить способ реше ния, удовлетворяющий всех на с огромным числом клиентских ком пьютеров и серверов. Не нужно много ума, чтобы забраться в автомобиль и уг нать его, а вот чтобы спроектировать устойчивую к взлому машину и эффектив ную сигнализацию, потребуется квалифицированный механик или инженер. По этому нужны как так и Определите цели защиты продукта Сразу определяйте потенциальных клиентов и их требования к безопаснос ти. У и у сетевого администратора большой корпорации с отделени ями в десятках стран требования к безопасности сильно различаются. Я достаточно хорошо представляю, что необходимо но пожелания крупного корпоратив ного клиента останутся большой загадкой, если вы их тщательно не соберете и ГЛАВА 2 Активный подход к безопасности при приложений не проанализируете. Итак, кто же ваши клиенты и что они хотят? Если вы знако мы с расспросите их, что опи в понятие безопасности мы. Каждый сотрудник, работающий над созданием продукта, должен в обязатель ном порядке знать пользователей У нас в Microsoft мы об что создание образа будущего клиента позволяет лучше представить возможные действия. Создайте красочные и живые психологические своих будущих пользователей (рис. 2-3) и развесьте их на стенах офиса. Ана цели клиентов в области безопасности, учитывайте демографические ха рактеристики, роли тех или иных пользователей в процессе работы или игры, их отношение к защите и допустимый уровень риска.

ты ему Рис. Плакат с портретом будущего пользователя 30 Часть Безопасность приложений сегодня Определение круга потенциальных клиентов и целей по защите приложения позволяет предотвратить его «распухание», то есть бессмысленное перенасыще ние продукта ненужными функциями. Постоянно спрашивайте себя: «Действитель но ли эта функция защиты избавляет от опасности, которой боится будущий пользователь?» Если нет, советую хорошенько подумать — может, от нее вообще стоит Ответьте на несколько вопросов и запишите ответы в специаль ный документ.

• Какова целевая аудитория приложения?

• Что означает «безопасность» для этой аудитории? Различается ли отношение к этому понятию в разных группах будущих клиентов? Разнятся ли требова ния по безопасности у различных пользователей?

• В какой среде будет работать продукт: в Интернете? в среде, защищенной бран дмауэром? на мобильном телефоне?

• Что вы хотите защитить?

• Каковы компрометации защищаемых вашим приложением объектов?

• Кто будет управлять продуктом — пользователь или компа нии?

• Какие уже имеющиеся безопасности операционной системы и ИТ можно использовать в приложении?

• Как защитить пользователя от его собственных ошибок?

Вот что говорится о важности понимания бизнес-требований в документе ISO «Information Technology — Code of practice for information security mana технология — Свод правил по управлению инфор мационной безопасностью») — международном стандарте, определяющем орга низационные, физические, коммуникационные и системные политики безопас ности при разработке ПО, — во введении и подразделе 10.1.1 раздела 10. requirements of systems» («Требования к безопасности по безопасности и процедуры по защите должны со бизнес-ценности информационных активов и возможному ущербу для возникающему по причине шения или отсутствия защиты.

Примечание ISO — очень общий документ, который в лучшем случае дает лишь основные правила разработки, но и он весьма помогает сообще ству разработчиков. Текст стандарта можно приобрести на сайте Примечание Для работающих компаниях, где руководствуют ся стандартом ISO 17799, замечу, что большая часть этой книги относится к разделам §9-6 «Application access control» в приложениях»), §10.2 «Security in application systems» в прикладных и в меньшей степени — к разделу §10.3 «Crypto graphic controls» ГЛАВА 2 Активный подход к безопасности при разработке приложений Рассматривайте защиту как неотделимую функцию программы Защита — это такая же функция системы, как и остальные. Не относитесь к ней, как какому-то туманному и загадочному разработки приложения. И ни когда не относитесь к безопасности, как к фоновой задаче, которую можно отло жить на потом или выполнить в более удобное время. Безопасность следует рас пространить на все приложение. Позаботьтесь, чтобы описание каждой функции в спецификации программы содержало раздел с описанием влияния, которое оказывает данная функция на защиту приложения. С примерами учета для безопасности вы можете познакомиться на сайте в каждой части любого из ментов, созданных группой IETF в последние годы, есть раз делы, посвященные безопасности, Помните: даже не предназначенные для защиты программы должны «уме противостоять атакам. Вот несколько примеров:

• переполнение буфера в Microsoft Clip Art позволяющее злоумышлен нику исполнить свой код • изъян в утилите для восстановления файлов для Solaris, который позволял рядовому локальному пользователю получать доступ уровня root • команда сортировки son во многих UNIX-системах, в том числе Apple OS X, создает условия для проведения успешной DOS-атаки Что у них общего? Программы не предназначены для обеспечения безопасное ти, но у всех нашлись слабые места, которые оставили пользователей беззащитными перед атаками.

Примечание Мне очень нравится которую рассказал один мой Когда-то он работал в компании, в которой всплески повышенного мания к безопасности приходились на утро понедельника. Причин;

оказалась весьма простой: по вечерам воскресенья вице-президент рел очередную про — «Сеть» (The Net), (Sneakers) или «Хакеры» (Hackers)!

Как-то пришлось анализировать программу, план разработки которой выглядел так:

• этап 0: создание проекта системы;

• этап 1: базовых функций;

• этап 2: программирование дополнительных функций;

• этап 3: обеспечение защиты;

• этап 4: устранение ошибок;

• этап 5: поставка продукта.

Как вы думаете, действительно ли разработчики серьезно относятся к ности? Я познакомился с этой командой только по который оказался рьяным энтузиастом безопасности и добился, чтобы меня 32 Часть I Безопасность приложений сегодня гласили в качестве эксперта. Но в команде полагали, что сначала реализо вать функции приложения и лишь решать вопросы безопасности. Огром ный такого подхода в том, что защита, реализуемая па этапе 3, впол не может свести на нет часть или работу, выполненную на этапах 1 и 2. Кро ме того, сложно удалить хотя бы часть на этапе 3, в зультате чего программа останется уязвимой.

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

Помните, не реализуя безопасность с самого вы столкнетесь с проблемами;

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

• добавление любых новых функций, в том числе защиты, на поздних этапах обходится дороже:

• при реализации безопасности часто приходится изменять уже реализованные функции. Это также весьма накладно;

• при добавлении защиты иногда меняется интерфейс приложения и наруша ется структура кода, созданного в на существующий интерфейс.

Внимание! Не защиту вдогонку!

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

Недавно меня попросили график разработки, и, я был очень приятно удивлен, увидев такое, ГЛАВА 2 Активный подход к безопасности при разработке приложений и и Дата Этап Мероприятия по обеспечению безопасности Начало проекта Обучение команды основам 08.09.2002 Этап 1: Начало 22.10.2002 День, посвященный или День 30.10.2002 Этап 1: Готовый код Завершение моделей грозящих 1-й сеанс исследования защиты, проводимый совместно с группой Secure Windows 18.11.2002 День 27.11.2002 Этап 2: Начало День безопасности Этап 2: Готовый код 10.01. День безопасности 02.02. 2-й сеанс исследования проводимый 24.02. совместно с группой Secure Windows Первая бета-версия Устранение ошибок и второго 28.02. приоритетов Первая бета-версия:

07.03. окончательный вариант (Release) День безопасности 03.04. Этап Готовый код Начало 4-недельной «работы нал 01.06. 3-й сеанс исследования защиты, проводимый совместно с группой Secure Windows Вторая бета-версия:

14.08. окончательный вариант (Release) День безопасности 30.08. Первый кандидат 21.09. па выпуск (Release Candidate) Заключительный, 4-й сеанс исследования а.

проводимый совместно с группой Secure Поставка приложения!

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

34 Часть I Безопасность сегодня Защита тесно вплетена в процесс, и члены заботятся о безопасности с самого начала его разработки. Выделять достаточно времени для работы над безопасностью очень важно.

Отведите на обеспечение безопасности достаточно времени Я что сейчас сообщу вам очевидную вещь, но если вы потратите боль ше времени на безопасность, то меньше останется на другие функции, при усло вии, конечно, что вы не нарушаете график и не превышаете смету, У разработчи ков есть старая что «из вещей — набора стоимости и графика — гарантировать можно только две». Защита — это одна из функций про дукта, поэтому ее приходится реализовать в ущерб стоимости и/или графика. Вам предстоит предусмотреть больше времени на проект или скорректировать гра фик так, чтобы справиться с дополнительной работой. Таким образом вы избави те себя от неприятных и всегда неожиданных «открытий», что на реализацию новых функций больше времени, чем ожидалось, так как они должны рабо тать не только корректно, но и Как и с любой другой чем позже начнется реализация безопаснос ти в проекте, тем дороже она обойдется, а риск срыва графика повысится. Учет безопасности на ранних этапах разработки составить более точный график, а попытка отложить ее «на потом» — прямая дорога к опозданию в по ПО, которое к тому же окажется «дырявым». Это особенно в отно шении защиты от DOS-атак: часто выясняется, что для ее реализации требуется коренным образом перестроить приложение.

Примечание Не забудьте предусмотреть в графике время на обучение, Моделируйте опасности, грозящие системе Моделированию опасностей вся глава 4, но пока мы лишь скажем, что возможных опасностей следует закладывать в основу про екта. Без них вы просто не создадите качественный продукт, так как для постро ения защиты надо понимать, что грозит приложению. Знайте: на со здание придется потратить немало времени. Но они стоят того, С самого начала запланируйте процедуру удаления функций, оказавшихся небезопасными «ПО не умирает — оно переходит в разряд опасных Повесьте это изречение на видном месте и никогда не потому что оно верно, ПО изнашивается, как это происходит с материальными вещами, но оно мо ментально становится крайне опасным, когда выясняется его неспособность про тивостоять атакам нового типа. Именно поэтому следует планировать процесс удаления устаревших функций. Например, постепенно выводить из об ращения старую функцию, заменяя ее более безопасной версией. Это даст для плавного перевода клиентов на обновленное и безопасное при ложение. Обычно клиенты очень любят но. спланировав и предупредив их об обновлении вы подготовите их к переменам.

ГЛАВА 2 Активный подход к при разработке приложений Определите допустимое число ошибок Решая, какие следует искоренить до начала поставок продукта, тесь реалистом и прагматиком. В идеале все проблемы ПО, в том числе следует устранять до поставки продукта клиенту. Но в реальности все не так просто. Защита — всего лишь одна, хотя и очень важная, часть прило жения, и при ее создании приходится жертвовать чем-то или идти на компромиссы.

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

Некоторым это может показаться кощунством, по следует смириться с тем, что никому не дано создать идеальное ПО (если, конечно, не рассматривать тот риант, когда заказчик готов вложить в него несколько миллионов долларов).

лее того, даже если вы попытаетесь приложение, на создание придется затратить столько что оно безнадежно устареет долго до выхода в свет. Программа должна делать именно то, для чего ее создали, не больше и не меньше. Это значит, что она в принципе не — это означает, что при сбое она никоим образом не открывает систему для атаки, Примечание До прихода в Microsoft мой начальник работал в одной малень кой секретной группе, которая разрабатывала систему, удовлетворяющую требованиям безопасности класса Orange Book. («Оранжевая книга* применяется Министерством обороны США для оценки надежности за щиты а класс А1 — это очень высокий уровень безопасности.

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

Исправлять следует те ошибки, искоренение которых оправдано. Как вы дум а ете, стоит ли устранять дефект, который повлияет на работу лишь пользовате лей из клиентской базы общей численностью 50 000 создаст очень небольшую потребует серьезной перестройки архитектуры, что в >ю очередь породит хвост регрессионных ошибок и нарушит работу по ловины пользователей? Наверняка лучше исправить недостаток не в в следующей версии;

кроме прочего это вам даст время, чтобы предупредить о грядущем изменении заранее.

Вспоминается одно совещание (дело было много лет где мы решали обходимость устранения ошибки, которая не позволяла масштабировать систе му. Загвоздка заключалась в том, что после исправления приложение стало бы недоступным для японских пользователей! После двух часов жарких дискуссий постановили ошибку не исправлять и пока предоставить обходное а полностью устранить дефект в следующем выпуске. Мы что 36 Часть I Безопасность приложений сегодня ма небезупречна, но зато работала, как и на тот момент этого было кроме того, ограничения мы четко описали в уровень ошибок нужно определить как можно зави сит от среды, где будет работать программа, и от того, что пользователи ожидают от нее. Установите планку функциональности ПО а количества ошибок — низко. Но будьте реалистом: никто не знает, что будет угрожать вашей программе в будущем, поэтому, следуя изложенным в главе 3, попытайтесь все-таки сократить «площадь Таким образом вы сузите круг дефек тов защиты, в результате возможна компрометация системы.

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

Внимание! Иногда кажется, что проще всего устранить ошибку, повысив пол номочия учетной записи, под которой работает приложение. Однако имейте в виду: это очень и очень плохое решение, почему — объясняет ся в главе 4.

Предусмотрите проверку группой по безопасности Когда вы что достаточно потрудились над продуктом и он уже весьма хорош и безопасен, пригласите специалистов по безопасности со стороны, что бы они проанализировали вашу работу. Незаинтересованный взгляд очень полезен — удается недостатки на самой стадии проекта, а не в его конце. В большинство проектов на предмет безопас ности анализирует наша Разработка Разработка — это написание и отладка кода. На этом этапе основной упор дела ется на написание максимально кода. Качество можно считать подмножеством безопасности: качественный код — безопасный код. Так каковы же методы достижения этих целей?

Очень осторожно предоставляйте права на внесение исправлений Буду краток: отзовите у большинства право на создание нового кода и внесение исправлений (check-in) в существующий код. Возможность модифицировать код — это привилегия, а не право. Разработчикам предоставлять ее только по сле прохождения курса Перепроверяйте внесенные исправления Взаимная проверка кода программистами — мой любимый метод, потому что он позволяет обнаружить уже допущенные ошибки и их развитие в программе. Вообще-то, я немного нарушаю общепринятые правила, но все равно стою на обучение и перекрестный контроль кода значительно повышают его безопасность. Не столько из-за обнаружения ошибок, ГЛАВА 2 Активный подход к безопасности при разработке приложений сколько из-за того, что программисты, что кто-то сунет свой нос в их стараются изо всех сил. Этот эффект называется эффектом effect) — по названию фабрики в южном пригороде штат Иллинойс*. Ис измерили время, требующееся рабочим на ных операций, и оказалось, что в присутствии исследователей рабочие выполня ли свою задачу быстрее и эффективнее.

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

В таком методе за раз изучается одна крошечная часть исходного текста, п > этому задача эксперта по безопасности сильно упрощается. Заметьте: я сказал сперт по безопасности». Перекрестная проверка кода программистами — прекрасно, но до того, как передать код в систему управления версиями, необх' чтобы его исследовали специалисты по безопасности — они выясняют личие ошибок защиты, а не общую корректность кода.

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

Учитесь на предыдущих ошибках О том, как не наступать на одни и те же грабли, рассказывается в главе 3- Здесь же достаточно сказать, что главное — учиться на ошибках прошлого с тем, чтобы не повторять их. Назначьте ответственного за выявление дефектов и меры по их Эффект Хоторна описан психологом Элтоном (George Elton Mayo, на основании исследований, проведенных на Западном заводе электрических изделий г. Хоторна с целью поиска оптимальных условий и труда и отдыха. Майо установил, что рост производительности труда рабочих не столько с условиями труда, сколько с их участием в исследовании. — утилита обнаружения и сравнения отличий между и каталогами. — Прим, перев.

38 Часть I Безопасность приложений сегодня Поручите анализ безопасности приглашенным специалистам Стоит привлечь специалистов, например из консалтинговой компании, для изучения и анализа кода и планов проекта. Работая в Microsoft, мы обнаружи ли, что внешние исследования исключительно эффективными глав ным образом потому, что компании-консультанты смотрят на продукт со сторо Не забудьте удостовериться, что специалисты из приглашенной компании имеют опыт работы с технологиями, используемыми в вашем и что они смогут передать знания вашей команде. Это должна быть независимая ком пания, причем не из тех, которые занимаются формальной сертификацией. Сер тификаты хороши для но смертельно опасны для разработки защи щенного кода, потому что создают ощущение Разверните кампанию по безопасности Начиная с конца 2001 г. в Microsoft регулярно проводятся кампании по безопас ности — security push. Цели этих мероприятий:

• повысить и понимание проблем безопасности членами команды;

• найти и устранить ошибки в а в некоторых случаях — и в проекте при • избавиться от в процессах разработки ПО;

• создать в команде крепкое ядро из разбирающихся в безопасности сотрудников.

две задачи исключительно важны. Затратив достаточно времени на security push (а в случае Windows они занимали до 8 недель), вы выполните «до машнюю и укрепите навыки, полученные в процессе обучения. Подобная кампания дает всем членам команды редкую возможность сконцентрировать вни мание на защите и избавиться от многих застарелых и опасных привычек. Более того, по завершении кампании возрастает число людей, пони мающих, зачем создавать безопасные системы, и заражающих окружающих сво ей уверенностью. Я множество раз, что после проведения security push более половины времени совещаний, посвященных изучению и анализу готового кода, тратилось на обсуждение последствий для приложения, обуслов ленных изменениями в коде или проекте. (Легко догадаться, что ко торые после security push я посещал лично, практически полностью посвяща лись защите, но, как вы наверняка догадались, это прямое следствие эффекта Если вы планируете проводить кампанию по безопасности, воспользуйтесь ре которые мы сформулировали и проверили на • до начала проекта смоделируйте опасности, грозящие еще не созданной про грамме. Как оказалось, в командах, которые занимаются этим в самом начале проекта, возникает меньше затруднений, а процесс разработки более глад ко, чем у тех, что делают все параллельно — моделирование, со здание тест-планов и проектирование. Причина в том, что моделирование опас ностей позволяет разработчикам и менеджерам сразу выявить части програм ГЛАВА 2 Активный подход к безопасности при разработке приложений мы, подвергающиеся особому риску и поэтому подлежащие более анализу. О моделировании опасностей рассказывается в главе 4;

• держите в курсе всех членов команды. Информируйте их о в безопасности и новых типах атак;

воспользуйтесь для этого электронной • создайте основную группу безопасности, будет каждый и искать и анализировать ошибки и недостатки защиты в создаваемом ПО.

группа должна стать силой кампании по безопасности;

• позаботьтесь, чтобы группа безопасности организовала список рассылки электронный форум, где любой команды разработчиков мог бы вопросы по защите и получать на них ответы. Помните: команда осваив область, поэтому следует быть открытым для новых идей и Ни в коем случае не говорите разработчикам, что их идеи или вопросы дурацкие (даже если это так)! Ведь ваша развить, а не убить вкус к безопасности;

• учредите призы за обнаружение «лучших» дыр в защите, за нахождение наи большего количества ошибок и т. п. Фанаты любят поощрение!

Не утоните в потоке обнаруженных ошибок защиты Задавшись целью «нарыть» побольше ошибок в защите, вы их найдете, но не утоните в них. Известна пара правил: разработчик должен работать не больше, чем с 5-ю ошибками одновременно, а общее количество обнаруженных в программе дефектов не должно более, чем в 3 раза, превышать число разработ чиков. При нарушении любого из них программисты «захлебываются» в работе по латанию уже найденных дыр в защите, и им хватает времени на поиск вых Но, справившись с фронтом работ, можно к других недостатков. Умеренный поток выявленных дефектов по.

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

Однако в каждой записи предусмотрите дополнительное поле, где надо указать, к какому типу опасности относится дефект. Вы вправе применить для ции ошибок описанную в главе 4 методику STRIDE, а в конце разработки лизировать, почему, скажем, у вас так много мест, уязвимых для DoS-атак.

Никаких неожиданностей и «пасхальных яиц»!

В программе не должно быть никакого дурацкого скрытого кода, скажем, для ото бражения списка всех сотрудников, участвовавших в создании приложения. Пр тически всегда проект с трудом укладывается в график, но откуда же берется вре мя на написание глупых Должен сознаться, что предыдущей сам занимался этим, но только не в готовом приложении. Это была программа прототип. Теперь я бы не стал писать «пасхальное яйцо», потому как что пользователям оно не да и, откровенно говоря, у нет времени на э го!

3- 40 Часть I Безопасность приложений сегодня Тестирование Тестирование защиты настолько важно, что мы посвятили ему отдельную главу.

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

как я ранее, в безопасном продукте не должно быть каких «дополнительных» функций, которые могли бы сделать систему уязвимой.

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

Поставка и сопровождение Самая трудная часть работы сделана, или, по крайней мере, так кажется, и код готов для отправки заказчику. Но безопасен ли продукт? Нет ли в нем известных бре шей, которыми может воспользоваться злоумышленник? В конце все сво дится к одному вопросу: как узнать, что продукт готов?

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

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

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

Внимание! Не поставляйте приложение, если в нем есть известные, чреватые серьезными нарушениями безопасности ошибки!

ГЛАВА 2 Активный подход к безопасности при разработке приложений Обратная связь После начала эксплуатации продукта в нем неизбежно обнаружатся бреши — выявите вы, другие — ваши пользователи. Поэтому следует заранее позаботиться о политике и процедурах проблем по мере их возникновения. Обнару женный недостаток должен пройти процедуру при этом определя ется его серьезность, принимается решение, как лучше его устранить и в каком виде предоставить исправление клиентам. Если дефект в последний следует тщательно исследовать на предмет аналогичных недостатков.

Если этого не сделать, повторы не заставят себя долго ждать, кроме того, подоб ное отношение — проявление элементарного неуважения к клиентам. Делайте правильно и, обнаружив ошибку определенного типа, искореняйте не только ее, но и всех ее «сестриц-близняшек».

Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.