Книги, научные публикации
Pages: | 1 | ... | 8 | 9 | 10 | Michael Howard David LeBlank WRITING SECURE CODE Second Edition Press Майкл Ховард Дэвид Лебланк ЗАЩИЩЕННЫЙ код 2-е издание, исправленное Москва 2004 УДК 004.45 ББК 32.973.26-018.2 Х68 ...
-- [ Страница 10 ] --необходимо про верять, что установлен в NULL, чтобы сначала получить размер буфер Ч не существует способа ограничить размер буфера;
ется, что размер источника не превышает 80 символов. Соблюдайте особую ос торожность с этим сообщением.
SB SB SB - в общем случае следует прежде все го отправлять сообщение чтобы узнать размер входной Однако это не всегда избавляет от неприятностей: размер данных может изме ниться в промежутке между определением размера и приемом в те чего возникнет переполнение. Будьте очень осторожны с этими сообщениями.
Пока не существует способа запросить длину текста всплывающей строки состояния при посредстве сообщения Ч в окне этого стиля в поле ввода все вводимые символы отобра жаются в виде звездочек Не забывайте очищать буфер, который передаете или чтобы пароль не оставался в памяти текстом. Подробнее об этом рассказывается в главе 9.
API-функции олицетворения Если вызов функции олицетворения по каким-либо причинам терпит сбой, оли цетворения не происходит и запрос выполняется в контексте безопасности вы зывающего процесса. Таким образом становится возможным превышение полно мочий, если процесс работает в контексте высоко привилегированной записи, например SYSTEM или члена группы администраторов. Вот почему очень важно всегда возвращенное значение. Если вызов завершился но, немедленно прервите выполнение клиентского запроса. К функциям олицет ворения относятся:
и 632 Часть V Приложения Кроме в Microsoft Windows 2003 олицетворение является при вилегией и предоставляется далеко не всем. Это увеличивает вероятность сбоя при попытке олицетворения. Оно возможно в Windows Server 2003, только если выполняется по крайней мере одно из условий:
Х запрошенный уровень ниже Impersonate (то есть разрешен анонимный уровень или Identify, которые никогда не вызывают ошибок);
Х маркер процесса обладает привилегией Х процесс (или другой процесс в этом сеансе входа в систему) создал маркер вызовом явно указав параметры доступа;
Х маркер принадлежит текущему пользователю приложения;
Х приложение является сервером СОМ или СОМ+, запущенным через сервисы активации СОМ, потому что СОМ добавляет к главному маркеру приложения идентификатор сервиса. Это не относится к запущенным как Activate as Activator.
Ч крайне не рекомендуется создавать дескрипторы защиты, имеющие нулевые (NULL) DACL, то есть при создании ко торых третий параметр равен NULL. Такая DACL никак не защищает объект.
Более того ничто не мешает взломщику определить АСЕ запись Control: Deny для группы Everyone, что запретит доступ к объекту всем, в том числе и админи страторам.
API-функции, уязвимые для DoS-атак Такие API-функции могут привести к возникновению условий для отказа в живании, особенно при недостатке памяти.
InitializeCriticalSection и в условиях недостатка памяти исключения, и если исключение не перехватывается, приложение завершается аварийно. Взамен рекомендуется функция Заметьте: EnterCriticalSection не инициирует исключения в Windows XP, Windows Server и последующих ОС. Также следите, чтобы не выполнять бло кирующих сетевых вызовов из критической секции или других блокируемых уча стков программы, И наконец, код критической секции следует проверять с особой тщательностью. Любые исключения должны перехватываться в самой критической секции, в противном случае программа вывалится в обработчик исключения до вызова В критической секции выполняйте лишь необходимый минимум операций. При программировании на C++ рекомендует ся создавать объект, вызывающий LeaveCriticalSection при раскрутке стека исклю чений.
и связанные с ней функции и макросы выделяют память в стеке, ко торая освобождается при выходе из функции, при этом предполагается, что па мяти достаточно! Во многих случаях эта функция инициирует исключение, ко торое, будучи необработанным, вызывает аварийное завершение процесса. Будь осторожны с макросами-оболочками для такими, Приложение А Опасные API-функции Наиболее общие рекомендации по поводу обрамляйте вызов обработ чиком исключений и не память на основе размера, указанного пользо вателем.
Наконец, вы должны в обработчике исключений;
эта фун кция служит для урегулирования переполнения стека и позволяет программе про должить выполнение, а не вылететь* с ошибкой. Вот пример.
ffinclude void { *p = } == { int result = TermmateTbread обе эти функции следует вызывать только в крайнем случае. Особенно TermmateTbread. Память, дескрипторы и системные ресурсы, которыми владел поток, не и не освобождаются. Вот выдер жка из документации к Platform SDK:
TermmateTbread Ч опасная функция, и к следует в случаях. TermmateTbread, только если точно знаете, что делает поток и контро лируете код, который исполнял в момент принудительного завершения, Есть только один случай уместного вызова TermmateTbread Ч когда при шении приложения один или несколько потоков не отвечают. TerminateProcess не очищает глобальные данные, которыми владеют DLL, и большинство должно вызывать ExitProcess, только если речь не идет о завершении внешнего процесса. Для тех, кто работал с TerminateProcess не освобожда ет ресурсы, занятые дочерними процессами. В принцип связи между родительскими и дочерними процессами реализованы не полностью.
Проблемы в сетевых API-функциях Сеть Ч это крайне агрессивная среда, и неверные предположения о правильно подключения способны стать причиной многих проблем. Если это возмож никогда не выполняйте сетевых вызовов из критической секции. Возможны любые, даже самые плохие сценарии, начиная от разрыва соединения до отправ ления данных и заканчивая злонамеренным клиентом, установившим слишком маленький размер окна TCP.
bind Ч будьте создавая привязку к (все интерфейсы) Ч есть риск нарваться на захват сокета. Подробности Ч в главе 634 Часть V Приложения Ч у этой функции три возвращаемых значения, и не всегда все они обрабатываются. На ошибку указывает при корректном разрыве соеди нения (или достижении конца буфера) возвращается 0, положительное число сигнализирует об удачном завершении. В общем случае идея вызвать recv в бло кирующем сокете плоха. При определенных обстоятельствах блокирующий recv может навсегда подвесить* поток. Для улучшения производительности применяйте Может решение и потеряет в но потери с лихвой окупятся повышением быстродействия.
send отправляет данные в сокет, с которым установлено подключение. Не следу ет рассчитывать на то, что все данные успешно переданы, если send не возвраща ет ошибки. Соединения иногда разрываются между вызовами send. Кро ме если злоумышленник намеренно задал размер окна TCP очень малень ким, существует лишь один путь заметить это Ч если при вызове send возникнет тайм-аут. Если вы сделали сокет блокирующим или не проверяете значение, воз вращаемое функцией, вы нарветесь на отказ в обслуживании.
Пользу вызовов функций интерфейса сложно переоценить Ч они предоставляют самую разнообразную информацию о Windows-системах. Примеры:
и др. К сожалению, все они блокирующие. Если пла нируете их вызывать, подумайте, как обойти тот факт, что все они обычно бло кируют выполнение секунд на 45, а иногда и дольше. Второе предостережение:
если придется иметь дело с реализациями (Server Message Block) отличными от тех, что созданы Microsoft, поведение функций может оказаться необычным.
Например, случае удачного выполнения системы Microsoft практически всегда возвращают корректный указатель, а другие могут вернуть NULL. Точно так же, как сервер не должен полагаться на клиента, клиентское приложение не должно достойного поведения от сервера.
Прочие API-функции Здесь собраны API-функции, которые не попали в другие категории.
и Ч основная причина избегать функций вида такова: они неряшливость и использование непроверенных указателей.
Они Ч наследие Windows, и их настоятельно не рекомендуется при менять в новых программах. В большинстве случаев достаточно проверить ука затель на NULL. В других ситуациях следует заключать код с указателями в блок структурной обработки исключений. Имейте в что это тоже опасно. Обра ботчик исключения может оказаться поврежденным из-за переполнения буфера, возникшего при копировании ненадежных данных. Не перехватывайте в обработ чике абсолютно все исключения Ч обрабатывайте лишь те, которые знаете, Понятно, что, если вы перехватываете это говорит об ошибке в коде, которую необходимо исправить!
Эти функции не гарантируют, что память, на которую ссылается указатель, и безопасна. Взять хотя бы вызов IsBadWritePtr для размещенного в стеке Приложение А Опасные API-функции буфера. Функция что память вполне безопасна, но мы-то знаем, что это не так. Из-за многозадачной природы Windows, ничто не мешает другому потоку изменить защиту памяти в промежутке между проверкой страницы ти и началом ее использования.
Внимание! Никогда не работайте с указателями, над которыми у вас нет мого контроля.
И наконец, не безопасна в многопоточной среде!
и возможные проблемы с этими функциям связаны с как они работают с ACL. Файлы, копируемые вызовом наследуют по умолчанию каталога, в который копируются, а файлы, переносимые сохраняют свои ACL. Дважды используется ли объект только локально;
не устанавливайте флаг ПРИЛОЖЕНИЕ Б Смехотворные оправдания, которые приходилось слышать мы критически на некоторые из оправданий, которые мно гие годы приходилось слышать от массы разработчиков, и про ектировщиков, пытающихся лоткрутиться от внесения изменений в структуру защиты или устранения дефектов в коде.
Х не будет заниматься подобными Х Кому придет в голову ломать наше Х никогда никто не Х Мы в безопасности, так как применяем Х Мы в безопасности, так как списки Х Мы в безопасности, так как установили брандмауэр.
Х Мы тщательно изучили код и не обнаружили ни единого дефекта защиты.
Х Да, это по умолчанию, но администратор вправе отключить опасную Х перестает нормально работать, если у пользователя нет админи страторских Х Но мы выбьемся из Х Приложение совершенно не пригодно для создания exploit-программ.
Х Мы же всегда так Х Эх, были бы у нас инструментальные средства Итак, приступим.
Приложение Б Смехотворные оправдания, которые приходилось слышать Никто не будет заниматься подобными глупостями!
Как бы не так! Еще как Как-то анализируя приложение, я спросил у разра выполнялись ли тесты на предмет переполнения буфера данных, полу чаемых с открытого И получил ответ, что такого тестирования не дилось, потому что, дескать, никто не станет атаковать сервер через но, где же сыскать желающих атаковать зловредными данными их драгоценную Я напомнил программистам о том огромном числе сценариев (scripts) всех мас тей для выполнения разрушительных атак на именованные каналы и интерфейсы самых разнообразных платформ, которое доступно для вандалов любителей (script kiddies), обожающих атаковать серверы в Интернете. Я предложил свою помощь в создании тест-планов. Но все напрас но, горе-программисты остались при своем: Никто не станет атаковать наше приложение через открываемый им сокет.
Не буду мучить вас подробностями и сразу скажу, что написал маленький сце нарий на который создавал подложный пакет и отправлял на сокет злопо лучного приложения, после чего сервер успешно падал! Стоит ли говорить, что разработчики быстро устранили ошибку и оперативно внесли в тест-планы про цедуры по тестированию на предмет обнаружения переполнения буфера!
Они не были разгильдяями Ч просто стали жертвой своей наивности. Плохие парни атакуют компьютеры и серверы круглые и если вы полагаете, что уж к вам-то они точно не то не обольщайтесь и позаботьтесь о соб ственной безопасности заранее, чтобы потом не пришлось кусать локти!
Кому придет в голову ломать наше приложение?
Это одна из разновидностей предыдущего оправдания. А ответ прост: всегда есть люди, пытающиеся нащупать вашу ахиллесову пяту и напакостить, да побольнее!
Кроме некоторые любят разрушать и наблюдать, как другие страдают. До статочно посмотреть ежедневные выпуски новостей, чтобы сколько в реальном мире зла и насилия. Вандалы разрисовывают стены зданий и заборы, хулиганы затевают драки и избивают совершенно невинных людей. И терный мир в этом смысле не исключение. Проблема здесь в что многие тысячи потенциальных взломщиков в состоянии атаковать, оставаясь а безнаказанными.
Мораль: люди атакуют компьютерные системы просто потому, что могут делать!
Нас никогда никто не атаковал!
К подобной фразе я всегда добавляю: Пока что! Или, как замечает мой Потому что ваш продукт никому не В мире финансов говорят: На осно вании доходности ценной бумаги в прошлом нельзя ее курс в будущем. То же верно в отношении безопасности и ПО. Достаточ но одному хакеру обнаружить уязвимость вашего приложения и сообщить дру гим, и ваш продукт моментально окажется под массированной атакой, кроме того, его станут щупать, пытаясь обнаружить аналогичные проблемы. Не успеете гла зом и в Интернете появится дюжина-другая exploit-программ, ствия которых (да и сами ошибки) вам придется устранять в пожарном порядке, 638 Часть V Приложения Мне приходилось тесно сотрудничать с разработчиками, приложение которых никогда не подвергались атакам, поэтому они не волновались о защите. Но не успевали они оглянуться, как за полгода в приложении обнаружилось семь серь езных брешей. Теперь у них есть небольшая группа специалистов по безопаснос ти, отвечающих за анализ и проектов и кода.
Рядом с одной из средних школ в Новой Зеландии, которые мне в детстве при шлось посещать, располагалась довольно оживленная и поэтому опасная трасса.
Школа уведомила местные власти о необходимости организации перехода, чтобы обеспечить безопасный переход ученикам. Чиновники отказа ли, мотивируя тем, что травматизм на этом участке дороги равен нулю. Из-за по пустительства властей все-таки несчастный случай: один из детей был сильно Переход построили, но слишком ведь ребенок уже пострадал, Подобное оправдание напоминает мне о нежелании многих выполнять резер вное копирование. Большинство начинает серьезно относиться к сохранности данных, только потеряв их. А до этого люди считают себя в безопасности. Но когда беда пришла, суетиться бесполезно, ибо ничего поделать нельзя, а заботиться стоило заранее!
Мораль очень проста: неприятности все-таки иногда случаются, поэтому об их предупреждении следует заботиться как можно раньше. Как говорила моя бабуш ка: предохранения стоит фунта Мы в безопасности, так как применяем криптографию С точки зрения программиста обеспечить поддержку криптографии в приложе нии достаточно просто: вся грязная работа уже сделана. Это хорошо изученный предмет, и большинство ОС содержит качественные реализации основных крип тографических операций. Однако очень часто программисты делают при чем чаще всего две следующие:
Х лизобретают собственные алгоритмы шифрования;
Х небезопасно хранят криптографические ключи.
Не надейтесь, что, создав собственный алгоритм вы откроете новое направление в криптографии. К настоящей криптографии подобное твор чество имеет очень далекое отношение, не говоря уже о том, что практически наверняка ваше решение взломают, Также шифрование обесценивается, если ключи хранятся небезопасным об разом. Даже самый лучший алгоритм шифрования с самыми большими ключами бесполезен, если ключ легко доступен.
Не изобретайте собственные алгоритмы шифрования Ч пользуйтесь опуб ликованными протоколами, которые прошли многолетние испытания.
Мы в безопасности, так как используем списки ACL Многие ресурсы в Windows можно защищать списками управления доступом Качественный, хорошо выверенный способен защитить ре Американские меры веса унция и фунт равны примерно 28 и 373 граммам соответ Ч перев.
Приложение Б Смехотворные оправдания, которые приходилось слышать от атаки. А неудачный ACL создает ложное ощущение безопасности и не предотвращает взлома.
В ряде случаев при анализе приложения я сталкивался с уверениями разработ чиков об использовании ACL. При ближайшем изучении обнаруживалось, что списки ACL есть, но какие Ч с полным доступом для группы Everyone (Все). Ина че говоря, любой (а именно это означает название группы) может делать с объектом все, что угодно (именно это означает полный Даже если поддерживает ACL полное разрешение для Everyone не в счет, так как не обес печивает никакой защиты.
Мы в безопасности, так как установили брандмауэр Еще одно популярное оправдание. Я слышал это от многих клиентов Microsoft, Изучив архитектуру Web-клиента в одной из компаний, я понял, что его оставляет желать лучшего. Однако в компании что потратили массу денег на свою инфраструктуру с брандмауэром и поэтому защищены от нападе ния. Как бы не так! Брандмауэры Ч замечательный инструмент, но они всего лишь одна из переменных общей формулы безопасности.
Дальнейшая экспертиза архитектуры показала, что она практически вся сете вая и на Web. И именно это меня сильно беспокоило. Брандмауэр на месте и исправно работает, но многие атаки осуществляются через стандартный для протокола HTTP порт 80, а именно он полностью открыт на брандмауэре.
Поэтому наличие брандмауэра не играет никакой роли, большинство атак его на замечает и проходит прямо на Web-сервер!
Но администратор компании возразил, что они могут анализировать прохо дящие через брандмауэр пакеты и отбрасывать опасный Web-трафик. Но я ска зал, что даже если забыть о возникающих при этом проблемах с быстродействи ем, ничто не запретит взломщику открыть подключение по протоколу и шифровать HTTP-трафик. Брандмауэр в этом случае окажется бессильным, Брандмауэры Ч замечательный но применять их надо с умом и только как часть общего решения обеспечения безопасности. Они не решают всех проблем.
Мы тщательно изучили код и не обнаружили ни единого дефекта защиты Ну уж это одно из моих любимых! Если вы понятия не имеете, как должна глядеть ошибка безопасности, то и не узнаете ее. даже столкнувшись нос к Как насчет проверки самолета Boeing 747-400 не предмет пригодности к Ну, это каждый Бивис-Баттхэд умеет! Типа, у него куча колес, два крыла, немного свисают книзу (там баки, поэтому топлива навалом), четыре двигателя, хвост ли все такое*. Достаточно ли этого для взлета? Ясно, что нет. Есть еще других вещей, которые обязательно чтобы убедиться в безопасности предстоящего полета, и заниматься этим должны специалисты. То же верно в от ношении анализа кода на предмет проблем с безопасностью. Анализировать должен один или более специалистов, которые понимают, как выполняются ата ки, как выглядит безопасный код и какие ошибки программирования возможны и чреваты прорехами в защите.
Мне вспоминается один когда я анализировал еще не увидевшую свет программу. Спецификации выглядели прекрасно, маленькая группа состояла из 640 Часть V Приложения высококлассных программистов, а тестирование выполнялось на высоком уров не. Пришло время поближе познакомиться с исходным кодом. Перед началом совещания ведущий разработчик сообщил, что это пустая трата времени, так как они уже проанализировали код на предмет безопасности и не нашли ни единой ошибки. Я предложил все-таки провести совещание и по прошествии 45 минут решить, стоит ли его продолжать. Стоит ли говорить что в течении 20 минут я обнаружил около десятка прорех в защите, встреча растянулась на три часа, а многие члены команды в тот день открыли для себя массу нового!
Есть другая модификация этого оправдания: код с открытыми (open Я не стану вести идеологических дебатов относительно открытого кода, а лишь что факт большей безопасности такого ПО совершенно не очевиден Ч многие из работающих над ним программистов не знает, что искать.
Активный анализ исходных текстов имеет смысл, когда вы знаете, что искать и как устранять недостатки. Это часть работы, которую мы с Дэвидом выполняем в Microsoft: мы анализируем огромное количество кода и знаем, что ищем. Иногда мы действуем, как бульдоги обнаруживаем брешь и не отпускаем программис тов, пока те ее не устранят! Это страшно интересно!
Да, это конфигурация по умолчанию, но администратор вправе отключить опасную функцию Раз уж на то пошло, буду рубить с плеча: администраторы не отключат опасные функции по пяти причинам. Они;
Х часто не знают, что следует отключить;
Х не знают, отключить ненужное;
Х не знают, что пойдет не так при отключении той или иной опасной функции;
Х довольны имеющейся устойчивостью всех систем и не желают искать непри ятностей;
Х не имеют времени.
Есть только один разумный выход: проектировать, программировать, тестиро вать и развертывать системы с практичными, но безопасными значения по умол чанию. Включение функции, способной сделать систему уязвимой к атакам, дол жно являться сознательным решением администратора.
Этот горький урок мы получили в IIS 5, но у большинство функций от ключено по умолчанию;
их активизирует администратор по мере необходимос ти. Это оправданно в системах, подвергающимся атакам, то есть в любой систе ме, которая открывает сокет!
Приложение перестает нормально работать, если у пользователя нет прав администратора За эти годы мне неоднократно приходилось вести такой диалог.
Я: Что ломается в приложении?
Клиент: Защита!
Я: В чем это выражается?
Приложение Б Смехотворные оправдания, которые приходилось слышать Клиент: Если не работать под учетной записью получаешь все время сообщения об отказе доступе.
Я: А вы задумывались над тем, что, может, так оно и должно быть?
Это классический пример непонимания принципа наименьших Если возникают ошибки доступа, достаточно запускать программу под админи стративной учетной записью или в контексте локальной системы, и неполадка исчезает! Практически всегда это очень плохая идея. Для выполнения подавляю щего большинства рутинных ежедневных операций не требуется ных полномочий. Задачи следует выполнять лишь с достаточным, но никак не избыточным набором привилегий.
Однако возможен один побочный эффект. Часто программы написаны и задачу просто не выполнить без полномочий администратора. Как ки программного обеспечения, мы должны избавляться от подобного и для выполнения непривилегированных задач требовать лишь минимально не обходимые привилегии. Это не так трудно, как кажется, но цель стоит того!
Я уже третий год не являюсь членом группы на своем ноутбуке. Только при настройке новой машины я предоставляю себе такие но по завершении конфигурирования немедленно в рядового пользователя. И все работает прекрасно. Когда нужен ив инструмент, я просто запускаю его с соответствующими реквизитами.
Но мы выбьемся из графика!
К счастью, подобное оправдание приходится слышать все реже, так как все начи нают осознавать, как важно создавать безопасные приложения. Однако в недобрые времена частенько приходилось выслушивать, как менеджер проекта нудит о срыве сроков. Во многих командах после оценки усилий и времени, не обходимых для обеспечения безопасности приложения, оказывается, что на ре конструкцию придется добавить к графику не менее полугода. Сделать эту ту все равно придется Ч рано или поздно, причем стоит значительно дороже. И дороже не только для вас, но для и ваших клиентов. Предоставляя вателям приложение, кишащее лазейками в защите, будьте готовы к практически нескончаемой череде жалоб и необходимости заниматься не совершенствовани ем продукта, а латанием дыр, обнаруживающихся в самых разных местах. Так что с самого начала выделите время на необходимые для обеспечения бе зопасности проекта, исходного кода и документации. Относитесь к ти как одной из функций приложения, и перестаньте ныть!
Приложение совершенно не пригодно для создания exploit-программ Мы неоднократно слышали подобное оправдание по отношению к тому или дефекту а также аргументацию, что данный дефект невозможно ровать. Ситуация и аргументация стандартны: на устранение дефекта 30 а для анализа и создания которая докажет ошибки уйдет дней. Никто не станет тратить такую прорву мени, поэтому приложения доказать не удается, его считают не поддающимся эксплуатации, а ошибку Ч не подлежащую устра нению. Это в корне неверный подход. Не спорю, все ошибки нельзя мести одной 642 Часть V Приложения метлой Ч к ним необходим дифференцированный подход зависимости от их серьезности. Разумно отложить устранение ошибки до следующей редакции, когда она сказывается на работе лишь одного пользователя на да то в те дни, когда Луна проходит через Сатурн, а ошибки нарушит работу осталь ных 999 999 Однако у свои особенности: когда обнаружен недостаток в защите и шансы регрессии невелики, просто устраните его, и точка. Не ждите, когда кто-то посторонний докажет, что ошибка действи тельно пригодна для эксплуатации, Мы всегда так делали Совершенно как вы делали раньше. За последние несколько лет Интер нет стал намного опаснее, а новые угрозы плодятся как мыши, практически еже недельно. Откровенно говоря, подобное оправдание в 99 случаев из 100 указыва ет на то, что приложение безнадежно дырявое и нуждается в серьезном анализе и пересмотре всего кода и методик программирования. Что бы вы сказали, если, обратившись к врачу с жалобой на приступы головной боли, получили бы рецепт на курс пиявок и аргументацию, дескать мы всегда прописываем именно это?
Внимание! Угрозы меняются, и вы должны меняться вместе с ними.
Эх, были бы у нас инструментальные средства получше!
Ну да! И это я слышал много раз. А суть в том, что нельзя снимать с себя ответ ственности за безопасность приложения, ссылаясь на отсутствие инструментов.
Функции большинства инструментальных средств ограничены, да и выполняют они их слепо! Как-то я спросил одного из лучших специалистов по анализу кода, какие инструменты он использует, и получил ответ: и свою Инструменты действительно часто позволяют ускорить процесс, но даже воо руженные наилучшими средствам неаккуратные программисты пишут такой же неряшливый код. Ничто не заменит качественных навыков программирования.
Лучшие программисты знают, что инструментальные средства Ч это всего лишь полезное подспорье, но сами по себе они проблем не решают.
В Контрольный список по безопасности для архитектора контрольный список (он также есть в папке Security Templates) Ч минималь ный набор проверок, которые должен выполнять проектировщик, архитектор или менеджер проекта в процессе проектирования приложения. Этот документ сле дует считать перечнем обязательных критериев, которым должен отвечать го го вый проект приложения по завершении этапа проектирования.
Отметка Процедура Глава I! Организовано обучение команды Назначен сотрудник, следящий за новостями на и NTBugtraq Выполнен анализ брешей в аналогичных приложениях и выяснено наличие аналогичных слабостей в нашем продукте Выяснены первопричины прорех в предыдущих версиях поражения* сведена до минимума П Вновь создаваемым пользовательским учетным записям назначаются минимальные привилегии и надежный пароль П Тщательно проанализированы считающиеся безопасными для использования в сценариях П Временный код проанализирован на предмет безопасности.
К безопасности временного кода следует относиться так же, как и к защите кода П по умолчанию безопасна см. след, стр.
644 Часть V Приложения Отметка Процедура Глава Завершено создание моделей опасностей на этапе проектирования Обеспечена многоуровневая защита приложений : Ошибки безопасности в журнале для дальнейшего анализа Требования по конфиденциальности определены и задокументированы Предусмотрены планы по переводу отдельных частей программы на управляемый код D Предусмотрены планы удаления функций, которые предполагается ;
изъять из приложения Предусмотрены планы реагирования на обнаруженные бреши :
В отражены проверенные методы обеспечения И безопасности ПРИЛОЖЕНИЕ Г Контрольный список по безопасности для программиста от вашей роли в процессе разработки ПО неплохо составить про верочный список, который позволит убедиться в том, что проект и исходные тексты создаваемого приложения соответствуют минимальным требованиям по ности. Буду откровенен: контрольные списки Ч вещь безусловно полезная, но, по следуя им, нельзя гарантировать абсолютную безопасность кода. Они скорее не обходимы, чтобы убедиться в отсутствии явных промахов, а также как обучения новичков. Как-то я как один программист наставлял не будешь выполнять требования контрольных списков, тебе придется не Имейте в виду, что этот контрольный список (он также есть в папке Security представляет собой набор проверочных в ко торый советую вам добавить элементы, характерные для вашей компании, а т же постоянно обновлять его по мере обнаружения новых угроз безопасности Общие условия Отметка Процедура Глава Код скомпилирован с параметром -GS среде Visual C++ Отладочные сборки скомпилированы с параметром -RTC (в среде Visual C++ Все ненадежные входные данные проходят проверку перед 1 ) использованием или хранением см. след. стр.
646 Часть V Приложения (продолжение) Отметка Процедура Глава Все функции управления буферами защищены от переполнения буфера П Рассмотрена возможность применения в программе заголовочного файла Strsafe.h П Изучены последние материалы по небезопасным и не рекомендуемым к применению функциям жение А П Структура всех таблиц корректна и удовлетворяет минимальным требованиям по безопасности, то есть не (NULL) и не содержит разрешения на полный доступ для группы Everyone (Все) П Нет никаких в коде полей паролей Сдлина пароля должна быть как минимум + где единица означает завершающий символ, определено в и равно 256) П Нет никаких ссылок на какие бы то ни было внутренние ресурсы (имена серверов или пользователей), жестко прописанных в коде Никаких жестко прописанных в коде (рекомендуется вариант Negotiate) D Имена и местоположение временных файлов отличаются достаточным уровнем случайности D В вызовах для олицетворения пользователя первый аргумент равен NULL, если полный путь к исполняемому файлу известен П Ресурсы, выделяемые подключениям, жестко ограничены П об ошибках не предоставляют лишней информации для потенциальных взломщиков Высокопривилегированные процессы пристально изучены несколькими специалистами на предмет оправданности повышенных привилегий П Важный в отношении безопасности код содержит уместные и подробные комментарии П Никаких решений не принимается на основании имен файлов П Всегда выполняется проверка, не является ли вызов файла обращением к устройству (например, PRN, и др.) D Нет никаких общих или перезаписываемых сегментов Никакие пользовательские данные не записываются в раздел реестра Никакие пользовательские данные не записываются в каталог Files Никакие ресурсы не открываются с флагом если более низкого уровня доступа достаточно Приложение поддерживает привязку к конкретному IP-адресу, не к 0 или ANY Приложение Г Контрольный список по безопасности программиста (окончание] Отметка Процедура Подробно размерность данных (байты или принимаемых или возвращаемых экспортируемыми API-функциями Всегда проверяется значение, возвращаемое функцией олицетворения D Для каждого случая олицетворения предусмотрены процедуры на случай сбоя П Сервисный код не создает окон и не отмечен как интерактивный Web и базы данных Отметка Процедура G Закрыты все лазейки для взлома через Web-страницу с применением сценариев О Нет никакой конкатенации операторов SQL I.
Нет никаких подключений к SQL Server под учетной записью I, Никакие не в процессе IIS 5 I.
На всех Web-страницах предусмотрен принудительный переход I.
на одну кодовую страницу D Отсутствие на серверных страницах вызовов функции I с передачей непроверенных данных Никаких решений не принимается на основании заголовка Все выполняемые на клиенте проверки наличия доступа и корректности данных обязательно дублируются на сервере Отметка Процедура Глава с параметром /robust При необходимости применяется атрибут [range] D проходят аутентификацию Применяются механизмы обеспечения Id и целостности пакетов i Используются строгие описатели контекста 11 Описатели контекста никогда не применяются для проверки прав на доступ П Всюду предусмотрена корректная обработка (NULL) описателей контекста П Доступ обеспечивается посредством безопасных функций обратного вызова П Учтены особенности работы нескольких одном процессе 22- 648 Часть V Приложения ActiveX, COM и Отметка Процедура Глава Все отмеченные как безопасные для использования в действительно таковыми являются Изучена возможность и где необходимо применен шаблон Криптография и управление секретами Отметка Глава Нет никаких в код (в исполняемых файлах, DLL-библиотеках, реестре, обычных файлах и др.) секретных данных Обеспечена надежная защита секретных данных Вызовы функций очистки буферов или не удаляются при компиляторной оптимизации. В тех местах, где это все-таки происходит, они заменены на Никаких доморощенных криптографических алгоритмов Ч только вызовы системного или пространства имен П Проверено и обеспечено высокое качество случайных чисел Генерируются только высококачественные случайные пароли В RC4 ключи шифрования никогда не используются повторно П Предусмотрена проверка целостности данных, шифруемых по алгоритму RC П Нет никаких слабых ключей (используются 128-битные ключи, а не 40-битные) Управляемый код Отметка Процедура Глава Успешно пройдена проверка утилитой FXCop XML-файлы и конфигурационные файлы не содержат никаких секретных данных 3 Все классы, для которых это оправданно, объявлены как герметичные Ко всем классам, для которых это необходимо, применены требования к наследованию П Все сборки снабжены строгими именами В сборках предусмотрены требования для определения минимального необходимого набора разрешений В сборках предусмотрены для отказа в конкретных разрешениях В сборках предусмотрены для определения необязательных разрешений, которые могут понадобиться П поддерживающее частичное тщательно проанализированы и схемы их использования достаточно безопасны Приложение Г Контрольный список по безопасности для программиста Отметка Процедура Всегда требуются необходимые разрешения Метод Assert обязательно закрывается для отзыва разрешения и сокращения времени его действия Код, отказывающий в доступе на основании имени файла, тщательно П При передаче вызовов вверх по стеку метод Assert заменяется на и Deny. Проверен весь код, который ведет себя иначе D Метод тщательно проверен на предмет корректности.
Рассмотрена возможность обойтись без этого метода Не пользующимся доверием пользователям не предоставляется никакой информации о проходе стека П Атрибут применяется с исключительной осторожностью Тщательно проверен управляемый код. служащий оберткой для неуправляемого ПРИЛОЖЕНИЕ д Контрольный список по безопасности для тестировщика контрольный список (он также есть в папке Security Templates) ет собой минимальный набор проверочных процедур, которые необходимо вы полнить в процессе тестирования приложения. Этот документ сле дует считать перечнем обязательных критериев, которым должен отвечать гото вый проект приложения по завершении этапа тестирования.
Процедура Глава список мест возможной атаки на основании декомпозиции приложения и модели опасностей Предусмотрен полный цикл тестирования на предмет мутации данных Предусмотрен полный цикл тестирования атак на SQL-механизмы, 12, а также атак с сценариев Приложение протестировано при значении параметра реестра в Windows ХР или в конфигурации по умолчанию в Microsoft Windows Server Выполнен анализ брешей в аналогичных приложениях компаний-конкурентов и выяснено, не подвержен ли аналогичным слабостям наш продукт Выяснены первопричины выявленных брешей в предыдущих версиях П Если приложение не является административным инструментом, всесторонне протестирована его работа в контексте пользователя, не обладающего административными правами Приложение Д список по безопасности для тестировщика Отметка Процедура Если приложение представляет административный протестирована своевременность и корректность завершения его работы в случае, когда у пользователя не оказывается административных привилегий П Поверхность поражения* программы сведена до минимума Конфигурация по умолчанию максимально безопасна Тщательно протестированы абсолютно все методы, свойства и события всех считающихся безопасными для использования в сценариях, и подтверждено, что они действительно таковы П Временный код проанализирован на предмет безопасности. К безопасности временного кода следует относиться так же, как и к защите промышленного кода Заключительное замечание Есть одна очень важная вещь, которая должна остаться у вас в голове после про чтения этой книги:
Ничто не заменит приложение с безопасными параметрами по умолчанию.
А это означает, что следует строить качественное программное обеспечение, которое работает с наименьшими привилегиями, обладает много уровневой защитой и минимальной площадью поражения. Так и только так.
потому что человек не в состоянии предвидеть все будущие угрозы и опасности.
Не полагайтесь на то, что администраторы будут исправно применять все зап латы или отключать все неиспользуемые опасные функции. Они не делать этого или не будут знать, как это делать, а чаще всего они так перегружены рабо той, что на подобные операции у них просто не хватает времени. Что касается домашних пользователей, то подавляющее их большинство профаны, которые понятия не имеют, как устанавливать заплаты или отключать функции.
Можете проигнорировать этот но тогда уж будьте готовы к адовым му кам беспрерывного устранения постоянно лазеек и дыр в вашем ПО.
Наконец, вам не удастся спихнуть обеспечение безопасности продукта на кого нибудь еще. Давно прошли те дни, когда защита была искусством избранных Ч это удел каждого, кто на месте отвечает за создание безопасного ПО, Больше невозможно прятать голову песок и жить по принципу моя хата с краю.
ничего не знаю.
Вы вправе пренебречь этим советом, но исключительно на свой страх и риск, Библиографический список с аннотациями 1. Carlisle, and Steve Lloyd. Understanding the Public-Key Infrastruc ture. Indianapolis, IN: Macmillan Technical Publishing, 1999. Новая и полная книга, посвященная сертификатам Х.509 и инфраструктуре ключа в стандарте Х.509 (PKIX). Авторы рекомендуют эту книгу как стандар ты IETF, изложенные человеческим языком. Охват материала в ней намного шире, чем в книге Feghhi, но и читать ее намного сложнее. если вам нужно глубоко разбираться в сертификатах, подумайте о покупке этой книги.
2. Amoroso, Edward G. Fundamentals of Computer Security Technology. e wood Cliffs, NJ: Prentice Hall PTR, 1994. Это одна из наших любимых книг.
У удивительный талант излагать сложную теорию в простой и т ной форме, Именно здесь вы найдете самое лучшее и полное описание дере вьев опасностей. Автор также рассказывает о некоторых моде лях безопасности, таких, как раскрытие информации в модели а также целостность в моделях Биба (Biba) и (Clark-Wilson). Единственный недостаток этой книги в том, что она опублико вана давно и устарела.
3. Anderson, J. Security Engineering. New York: Wiley, 2001. Хорошая позволяющая получить массу базовых сведений о безопасности. Ее заголовок и не совсем соответствует содержанию Ч здесь не очень много материала о настоящем Ч но ее стоит почитать хотя бы для того, чтобы получить массу интересных сведений и практических советов по безопасности.
4. Brown, Keith. Programming Windows Security. Reading, MA: Addison-Wes 2000. Лучшее объяснение того, как работает безопасности в Windows, в понятной и непринужденной форме.
5. Christiansen, Tom, et Perl Cookbook. Sebastopol, CA: O'Reilly & 1998. Если бы я оказался на необитаемом острове и имел возможность взять с собой лишь одну книгу по Perl, то я выбрал бы именно эту. Она охватывает все аспекты Perl, а также рассказывает, как с помощью этого языка создавать серь езные решения.
6. Feghhi, Jalal, and Peter Williams. Digital Certificates: Applied Internet Security. Reading, MA: 1999. Сложилось так, что работы цифровых сертификатов загадочны и весьма но эта книга поможет приподнять завесу тайны. Короче говоря, это самая лучшая книга из посвященных сертификатам Х.509 и открытого ключа 7. Ford, Warwick. Computer Security: Principles, Standard Protocols, and Techniques. Englewood NJ: Prentice Hall PTR, 654 Библиографический список с аннотациями Здесь описаны многие стороны защиты связи, в том числе криптография, аутен тификация, авторизация, целостность и конфиденциальность, не говоря уже о том, что это самое лучшее описание принципов невозможности отрицания авторства в доступной литературной форме. Здесь также подробно описыва ется архитектура защиты (Open Systems Interconnection).
8. Friedl, Jeffrey E. F. Mastering Regular Expressions. 2d ed. Sebastopol, CA:
O'Reilly & Associates, 2002. Просто самая замечательная из известных мне книг о регулярных выражениях. Во втором издании приводятся примеры на мно гих языках, в том числе на Perl и языках Framework. Я рекомендую ее что у регулярных выражений масса тонкостей, особенно когда они применяются для проверки корректности входных данных.
Simson, and Gene Spafford. Practical UNIX & Internet Security.
2d ed. Sebastopol, CA: O'Reilly & Associates, 1996. Эта толстенная книга ста ла уже классикой, хотя время властно и над ней! Несмотря на то, что она по священа в основном брешам в защите и проблемам администрирования в UNIX, изложенные в ней принципы практически к любой операцион ной системе. Здесь вы найдете обширнейший контрольный список по безо пасности UNIX, а также прекрасные интерпретации различных моделей пасности Министерства обороны США (Department of Defense), описанных в официальных стандартах серии документов Rainbow Series.
10. Garfinkel, Simson, and Gene Spafford. Web Security & Commerce. Sebas topol, CA: O'Reilly and Associates, 1997. Основательный и исключительно читабельный труд о Web-безопасности с интересными рассказами о сертифи катах и применении криптографических технологий.
Dieter. Computer Security. New York: Wiley, По нашему мнению, это более современная и прагматичная версия книги Аморосо Funda mentals of Computer Security Technology. Помимо моделей защиты, о которых рассказывает Аморосо, автор подробно о Microsoft Windows NT, UNIX и Web-безопасности.
Grimes, Richard. Professional Programming. Birmingham, U.K.: Wrox Press, 1997. Интересно и содержательно рассказывая о программировании DCOM, автор, в отличие от большинства других, не забыл подробно осветить вопросы безопасности применительно к этой технологии.
13.Howard, Michael, et Designing Secure Web-Based Applications for Micro soft Windows 2000. Redmond, WA: Microsoft Press, 2000. Исключительно широкий охват проблем безопасности в Web, а также исчерпывающие требо вания по безопасности. Это единственная книга, объясняющая, как работает делегирование в Windows 2000 и как создавать безопасные приложения.
Brian et al. Framework Security. Reading, MA: Addison 2000. Толстенный том, который в действительности представляет со бой собрание статей. Он для кто хочет подробно узнать обо всех внутрен ностях и тонкостях организации защиты доступа к коду в Eric. Visual Basic Code Security Handbook. Birmingham, UK:
Wrox Press, 2002. Удивительно доступная книга о безопасности в Легко читается, практична, лаконична Ч ее можно проглотить за один день и полу чить массу полезных сведений, Библиографический список с аннотациями Steve. Writing Solid Code. Redmond, Microsoft Press, книгу должен прочесть каждый программист. Я знаю многих с многолетним опытом и прекрасным стилем программирования, которые уз нали из нее о новых замечательных методах создания надежного кода. Код, созданный программистами, владеющими навыками написания надежных про грамм, обычно содержит мало ошибок безопасности, так как очень многие защиты являются следствием неряшливого стиля программирования.
Если еще не читали эту книгу, советую сделать это сейчас, а если читали, то возьмитесь за нее заново Ч наверняка вы обнаружите полезные вещи, торые пропустили ранее.
Stuart, and Joel Scambray. Hacking Exposed: Windows 2000.
keley, CA: 2001. Посвящена исключительно dows 2000 и этим отличается от следующей книги в списке, посвященной гим операционным системам. Если вы отвечаете за управление сетью Win dows 2000 или хотите узнать, что следует предпринять для обеспечения безо пасности своей сети на базе Windows, эта книга вам необходима. Она также полезна тем, кто разрабатывает приложения для Windows 2000, здесь описан горький опыт других, на котором следует учиться.
Stuart, Joel Scambray, and George Hacking Exposed: Net work Security Secrets and Solutions. 2nd ed. Berkeley, CA: w 2000. Этот труд позволит вам осознать, насколько вы уязвимы, когда ходите в причем независимо от операционной системы! Здесь расска зывается о брешах в защите в Netware, UNIX, Windows 95/98 и Windows NT. Б описании каждой бреши содержатся ссылки на инструментальные применяемые для ее эксплуатации. Очевидная цель книги Ч принудить нистраторов пристальнее следить за безопасностью.
Alfred J. et al. Handbook for Applied Cryptography. Boca Raton, FL: CRC Press, 1997. Моя любимая книга по криптографии, потому что вме щает массу полезной информации и практически не содержит бесполезных сведений. Однако приходится делать поправку на ее довольно почтенный воз раст.
20. National Research Council. Trust in Cyberspace. Edited by Fred B. Schneider.
Washington, D.C.: National Academy Press, Это результат работы п аналитического центра по безопасности, созданного для ана лиза инфраструктуры передачи данных и безопасности в США. а также предоставления рекомендаций, как сделать ее более устойчивой к нападениям, 21. Online Law. Edited by Thomas J. Smedinghoff. Reading, Developers Press, 1996. Это емкий обзор юридических особенностей нения текущего состояния законодательства, ре их обращение, конфиденциальности, патентов, де ответственности и многого другого. Она рекомендуется всем, кто зани мается электронной коммерцией или планирует использовать сертификаты в качестве составной части электронных контрактов.
22. Ryan, Peter, and Steve Schneider. Modelling and Analysis of Security Proto cols. London, England: Pearson Education Ltd, 2001. Я обожаю эту книг/ за то, что в ней первоклассно и по форме описаны протоколы защиты. Я 656 Библиографический список с аннотациями считаю, что формальное описание проблем безопасности позволяет но повысить надежность приложения Ч только за счет лаконичного и каче ственного изложения сути. Эта книга доступна обычному пользователю, а не только матерому математику.
Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2d ed. New York: Wiley, Замечательная но возраст дает о себе знать. Брюс, как насчет третьего 24.Security Protocols. Edited by Bruce et Berlin: Springer, 1998.
Это замечательное собрание статей, посвященных различ ным вопросам безопасной связи. Чтение для сильных духом: материал предельно сложен и требует хорошего знания криптографических технологий, но это того стоит.
Tsutomu, and John Markoff. Takedown: The Pursuit and Cap ture of Kevin Mitnick, America's Most Wanted Computer the Man Who Did It. New York: Hyperion, 1996. История о печально известном хакере Кевине и о том, как он компьютерные системы ком паний Sun Microsystems и других. Читается намного тяжелее, чем книга Столла The но, тем не менее, ее стоит прочесть.
26. Solomon, David and Mark Russinovich. Inside Microsoft Windows 2000.
Redmond, WA: Microsoft Press, 2000. Предыдущие редакции этой книги на Inside Windows NT*. Фундаментальное понимание операционной системы, для которой вы разрабатываете поможет вам создавать программное обеспечение, в котором максимально задействованы все преиму щества ОС. После выхода системы Windows NT в 1993 г. эта книга и документация к SDK помогли мне (Дэвиду) разобраться в этой новой на то время и захватывающей операционной системе. Если вы хотите стать настоя щим хакером (это почетное звание, и таких людей не стоит путать с крети нам, бездумно пользующимися сценариями атак, не понимая сути происходя щего), старательно изучайте все, что относится к ОС, для которой пишете 27.Stallings, William. Practical Cryptography for Data Internetworks. Los CA: IEEE Computer Society Press, 1996. Это подлинная жемчужи на нашего библиографического списка. Окажись я на необитаемом из всех книг по криптографии я выбрал бы именно ее. Составленная из серии легких для чтения статей из академических изданий и журнальных публика ций, эта книга охватывает несметное количество тем, в числе которых DES, IDEA, Skipjack, RC5, управление ключами, цифровые подписи, принципы аутентифи кации, SNMP, стандарты безопасности в Интернете и многие другие.
28.Stallings, William. Cryptography and Network Security: Principles and Practice. Englewood Cliffs, NJ: Prentice Hall, 1999. Автору прекрасно уда лось изложить теорию и но подлинная ценность этой книги в рассказе о протоколах защиты, таких, как SET, SSL/TLS, Русский перевод: Соломон Д. и Внутреннее устройство Microsoft Windows 2000. Мастер класс. Ч Питер;
дом Редакция, 2001.
Библиографический список с аннотациями PGP и Возможно, ей не хватает основательности Брюса Шнайдера с его Applied Cryptography: Algorithms, and Source Code in С, но годаря превосходному описанию протоколов материал наверняка окажется весьма интересным для практиков, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison- Wesley, 1994. Позволяет глубоко как на самом работают IP-сети. Одна из очень немногих которые прочно заняли мое заметное место на моем столе. К ней приходится часто обращаться, по этому она не перекочевала в книжный шкаф.
The Cuckoo's Egg. London: Pan 1991. Это не спра вочное издание, не техническая книга, а рассказ о том, как Столл лав стал безопасности, просто выслеживая хакеров со всего мира, атакующих его системы. Совершенно искренне рекомендую тать это легкое и захватывающее сочинение.
31. Summers, Rita С. Secure Computing: Threats and Safeguards. New York:
McGraw-Hill, 1997. Тяжелое, но исключительно исчерпывающее чтение, бенно разделы о проектировании и построении безопасных систем и зе защиты. Среди прочих тем этой книги защита базы данных, и управление.
Unicode Consortium. The Unicode Standard, Version Reading, 2000. (Поправки и обновления доступны на сайте в code.org.) Если вам хочется почитать толстую, скучную книгу, то это то, что вам нужно! В чем ее действительно никто не превзойдет, так это в об ширности... нет, не так Ч во всеохватной полноте описания стандарта Unicode и семантики различных языков и наборов символов.
33. Viega, John and Gary. Building Secure Software. Reading, Addi 2001. Можете считать это UNIX-версией первого издания книги, которую держите в руках. Если вы работаете в компании, занимающейся работкой ПО для UNIX, приобретите эту книгу и выучите ее назубок.
ный ее недостаток Ч много ошибочных сведений о безопасности в Windows.
Но в целом замечательно!
Whittaker, James A. How to Break Software: A Practical Guide to Testing.
Reading, MA: Addison-Wesley, 2002. Очень читабельная и основательная книга по тестированию. Автор интересно рассказывает о навыках, тренировке и методах тестирования, поэтому от книги трудно оторваться.
чтение для всех тестировщиков без исключения Ч как так и мате рых волков.
Elizabeth, et Building Internet Firewalls. 2d ed. Sebastopol, O'Reilly & Associates, 2000. Это настольная книга и справочник для тех, действительно хочет разобраться в том, как строятся безопасные сети и как работают брандмауэры. Создавая сетевое приложение, необходимо как функционируют брандмауэры. Хотя сети Windows и не основная тема этого труда, это не должно помешать вам обзавестись этой полезной книгой.
Предметный указатель 3DES 243, 247, С Run-time см. CRT canonicalization см. приведение access control entry см. АСЕ в канонический вид Access Control List CM. ACL CAPICOM 242, ACE (access control entry) 98,147, Cartesian join см. декартово 151, 153, 154, 155, 159, 160, 164, соединение 166, 169, CAS (Code Access Security) 464, ACK check-in см. код, внесение ACL (Access Control List) 49, 97, 98, исправлений 147, 149, 150, 152, 153, 154, chokepoint см. КПП 166, 170, 187, 188, 190, 262, Cipher cloaking см, маскировка Ч добавление ACE CLR (Common Language Runtime) Ч порядок следования АСЕ 171, 254, Ч создание Code Access Security CM. CAS Active Server Pages см. ASP code diffs см. код, различия Active Template Library CM. ATL code point см. кодовая позиция ActiveX COM (Component Model) activity diagram см.
411, операций COM Internet Services Advanced см. Интернета CM. AES COM+ AES (Advanced Encryption combining character см, составные Standard) символы Affected users см. риск, круг command shell см. командная пользователей, попадающих под оболочка удар Common Language Runtime CM. CLR ANSI 130, 132, Component Object Model CM. COM API 100, 189, 192, СОМ-службы Интернета Ч защиты данных см. DPAPI connectable см. объект, (application ID) стыкуемый ASP (Active Server Pages) connection point см. точка ATL (Active Template Library) соединения control flow graph см. диаграмма потоков управления cookie-файл 357, 359, 365, 374, credential см. реквизит Back Orifice cross-site scripting (XSS) см. атака, Basic authentication сценарий см. аутентификация, базовая (С Run-time) bind см. привязка bit flip см. атака, переворота бит Crucial ADS (Cryptographic API) 100, blanket см. оболочка, защитная bug см. жучок 237, 241, 243, 244, 247, 254, Предметный указатель CSP (Cryptographic Service Provider) DNS cache poisoning см. опас 228 модификация записей кэша DNS DNS spoofing см. опасность, подлог DACL (Discretionary Access Control DoS (Denial of Service) см. атака, List) 147, 151, 158, 160, 169, 180, отказ в обслуживании dotless IP address см. IP-адрес, Ч нулевая 167, не содержащий точек Damage potential см. риск.
address см. IP-адрес, потенциальный ущерб с точками Data Encryption Standard CM. DES (Data Protection API) 191, data flow diagrams CM. DFD 263, 268, data fork см. ветвь, данных HTML см. DHTML Data Protection API CM. DPAP DCE (Distributed Computing Environment) DCOM (Distributed COM) 103. EFS (Encrypting File System) Elevation of privilege см. опасность, DDoS (distributed denial of service) повышение привилегий см. атака, отказ обслуживании. Encrypting File System CM. EFS ephemeral см. ключ, эфемерный dead code см. код, неработающий exception handler clobbering dead store elimination см. удаление см, атака, захламление тупиковых записей обработчиков исключений declarative permission см. риск, см. разрешение, декларативное подверженность взлому defacement см. атака, уродование страниц Web-сайтов Denial of Service (DoS) см.
factoring см. ключ, разложение отказ в обслуживании на множители DES (Data Encryption Standard) 23, FAT 231, 243, 244, fault tree см. дерево неисправ DFD (data flow diagrams) 64, 75, 82, FileMon DHTML (Dynamic HTML) filtering см. фильтрация dictionary attack см. атака, взломом fork см. ветвь по словарю FTP Digest authentication см. аутенти FxCop на основе хеша digest function см. функция.
дайджеста GAC (global assembly cache) Discoverability см. риск, GNU С вероятность Access Control List H см. DACL ' hard link см. ссылка, жесткая Distributed COM CM. DCOM hash function см. функция, хеш Distributed Computing Hash-Based Message Authentication Environment CM. DCE Code НМАС DLL heap overflow см. атака, DNS 173, переполнение кучи 660 Предметный указатель Internet Protocol version 6 CM. IPv HFS HFS+ (Hierarchical File System Internet Server Application Programming Interface CM.
Plus) HMAC (Hash-Based Message IP restriction CM. IP-ограничение Authentication Code) 250 IPP (Internet Printing Protocol) 132, см. приманка IPSec (Internet Protocol HTML 58, 359, 363, HTTP (Hypertext transfer Security) 54, 93, 94, 99, 102, 240, protocol) 5, 77, 154, 355, 371 257, 96 IPv4 (Internet Protocol version 4) Hypertext transfer protocol (Internet Protocol version 6) 390, HTTP 409, IP-адрес Ч не содержащий точек Ч с точками I18N 378, IP-ограничение 97, 98, IAS (Internet Authentication ISAPI (Internet Server Application Service) Programming Interface) 48, (Internet Control Message 179, 337, Protocol) Ч короткое целое JavaScript Ч целое со знаком IDEA 243 JScript 242, IETF (Internet Engineering Task К Force) IIS (Internet Information Services) 5, 23, 95, 419, 132, 154, 173. 179, 317, keyed hash см. хеш с ключом (Internet Message Access Protocol) LAN Manager imperative permission LDAP 94, см. разрешение, императивное linear congruential function impersonation см. олицетворение функция, линейно index out of range см. атака, выход согласующаяся индекса за границы диапазона Local Security Authority CM. LSA Information disclosure logging см.
см. опасность, разглашение LSA (Local Security Authority) 184.
информации 187, 264, 268, Internet Authentication Service luring см. атака, см. IAS Internet Control Message Protocol CM. ICMP MAC (message authentication code) Internet Engineering Task Force CM. IETF 99, 100, 249, 253, см. ящик почтовый Internet Information Services CM. IIS см. вредоносное ПО Internet Message Access Protocol см.
CM. IMAP посредника Internet Printing Protocol CM.
см. маршалинг Internet Protocol Security CM.
maximum segment lifetime см. MSL Internet Protocol version 4 CM. IPv Предметный message authentication code Password-Based Key Derivation см, MAC Function CM. PBKDF MFC (Microsoft Foundation patch см. заплатка>
Napster (Portable Operating System National Language Support CM. NLS Interface for UNIX) Negotiate Post Office Protocol 3 см. РОРЗ NetBIOS Pretty Good Privacy CM. PGP NLS (National Language principal см. участник Support) безопасности NT LAN Manager CM. NTLM promiscuous mode см. режим, NTFS сквозной NTLM (NT LAN Manager) 93, 95, 96, protocol sequences см. последовательность NULL CM. DACL, протоколов Public-Key Cryptography Standard OBJREF (object reference) см. ссылка объектная off-by-one error см. ошибка.
QoS (quality of service) занижения размера буфера см. качество обслуживания на единицу ONC (Open Network Computing) Open Software Foundation RADIUS (Remote Administration Dial CM. OSF In User Service) OpenSSH 53 RC4 register attack см. атака, на регистр OSF (Open Software Foundation 412 Regmon regression bug см.
owner см. владелец объекта регрессионная Remote Administration Dial-In User Service CM. RADIUS command см. команда параметризованная 662 указатель Remote Desktop см. удаленный Secure/Multipurpose Internet Mail рабочий стол Extensions CM. S/MIME Remote Procedure см. см, риск, Security Account Manager CM. SAM воспроизводимость Security Configuration Editor Repudiation см. опасность, отказ см. редактор конфигурации от авторства безопасности resource fork см. ветвь, security descriptor см. дескриптор restricted token см. безопасности Security Descriptor Definition restricting SID см. SID, Language CM. SDDL ограничивающий Security Expressions reverse engineering см. обратный security ID CM. SID анализ Security Support Provider CM. SSP Rivest-Shamir-Adleman см. RSA Security Support Provider (Remote Procedure Call) 99, Interface CM.
415, 416, seed value см. значение 424, 428, 429 инициирования счетчика Ч конечная точка 48 serializing см. сериализация Ч служба определителя точек server hijacking см. атака, подмена вызова сервера Ч среда исполнения Server Block см. SMB endpoint mapping service Service Control Manager CM. SCM CM. служба определителя service principal name CM. SPN точек вызова SFI (safe for initialization) см. код.
runtime см. среда безопасный, в плане исполнения инициализации RSA 22, 23, SFS (safe for scripting) см. код, 235, 243 безопасный, в плане исполнения сценариев SID (security ID) 158, 166, 180, 186, (Secure/Multipurpose 193, 197, Internet Mail Extensions) Ч deny-only см, идентификатор, SACL (System Access Control List) запрещающий 151, 158, 160, Ч ограниченный safe for initialization см.
Ч ограничивающий безопасный, в плане signed integer см. ID, целое со и знаком safe for scripting см. код, Simple Mail Transfer Protocol безопасный, в плане исполнения см. SMTP сценариев point of failure см. точка salt см. модификатор критического сбоя SAM (Security Account Manager) SMB (Server Message Block) 54, 318, SMS (Systems Management Server) SCM (Service Control SMTP (Simple Mail Transfer script см. сценарий Protocol) 94, SDDL (Security Descriptor Definition sniffer см. сетевой анализатор Language) 159- social engineering см.
Secure Sockets Laver CM. SSL социальная инженерия Предметный указатель socket см. threat target см. объект, под SPN principal name) 96.
418 threat tree см. опасность, дерево Spoofing см. опасность. throttling см. ограничение числа подмена объектов запросов SQL injection см. SQL- TLS (Transport Layer Security) 57, 94- 96, 99, 102, 257, SSL (Secure Socket Layer) 57. 94. 95, token см. маркер 96, 99, 102, 225, 257, 355, 375, 390 SSP (Security Support Provider) 95 Transmission Control Protocol (Security Support Provider CM. TCP Interface) 95, 265, 390 Transport Layer Security CM. TLS stack smashing см. атака. truncation error см. ошибка, разрушение стека отбрасывания старшего stack walk см. проход стека Trusted Computing Base см.
stack-based cookie см. стековый trustworthy computing л см.
StackGuard STL (Standard Template Library) 139, stream cipher см.
bomb см. атака, потоковое (User ID) (Unified Modeling strict handle см. описатель 64, строгий INC Naming Convention.) Strings strong named assembly см. сборка, Unicode 130, 132, 304, 327, со строгим именем 377, 378, 380, 386, Unified Modeling Language CM. UML superuser см. суперпользователь Universal Naming Convention surrogate pair см. суррогатная пара symbolic link см.
unsigned short CM.
короткое целое SYN flood см. переполнение (user principal name) usability см. приложение, System Access Control List см.
использования entropy см. энтропия USB User ID CM. UID Systems Management Server CM. SMS user principal name CM. UPN 325, 326, Tampering with data см. опасность, данных V TCB (Trusted Computing Base) TCP (Transmission Control VBScript (Microsoft Visual Basic Protocol) 10, 390, Scripting Edition) 152, 231. 309.
TCP/IP 54, 99, Terminal Server см. сервер hijacking см. атака, захват терминалов threat model см. опасность, 664 Предметный указатель Ч на основании визуального совпадения waterfall approach см. модель Ч на регистр разработки водопадная Ч на секретные данные Web Ч нулевого дня Web-based Distributed Authoring and Ч отказ в обслуживании 45, 72. 92, Versioning CM. WebDAV (Web-based Distributed Ч распределенный Authoring and Versioning) Ч переворота бит window station см. оконная Ч перенаправление указателя станция Ч переполнение кучи Windows Host CM. WSH Ч поддержка окон приема Windows Sockets CM. Winsock Ч подмена Winsock (Windows Sockets) 339, Ч источника wrappers см. функция, оболочка Ч сервера WSH (Windows Scripting Host) Ч сетевых объектов 239, 357.
WTLS Ч посредника 54, Ч разрушение стека XML Ч распространение вирусов XOR 242, 243, 244, Ч социальная инженерия XSLT (XSL Transformation) Ч уговора XSS (cross-site scripting) см. атака, Ч уродование страниц Web сценарий сайтов атрибут Ч защиты 3 Ч разрешения attack см. атака, нулевого аудит 100, дня аутентификация 92, 93, - 93, авторизация 92, 97 Ч - Kerberos v5 93, асимметричного шифрования см. RSA Ч Microsoft Passport 93, 94, атака 74 NTLM 93, 94, 417 - RADIUS 93, 94, Ч DoS (Denial of Service) 71, -JScript 369 Ч па основе форм 93- Ч ping смерти 448 Ч на основе хеша 71, 93, - 447 Х.509 93, Ч взломом по словарю 259 Ч стандартная Windows 93: Ч SQL-кода Ч выход индекса за границы диапазона безопасный сбой Ч библиотека времени выполнения Ч захват Microsoft Visual C++ 7 см. CRT Ч захламление обработчиков блок пользовательского исключений окружения Ч кросс-сайтовый сценарий брандмауэр 298, 355, 359, 360, брешь 74, 80, 179, 314, 321, 323.
362, Предметный указатель i В И ветвь идентификатор см. ID Ч данных 323 Ч см. SID Ч запрещающий безопасности Ч ресурсов вирус 178 179 Ч см.
179 Ч приложения см.
179 избирательная таблица управления владелец объекта 186 доступом см. DACL вредоносное ПО 178 интерфейс Ч Ч генерация случайных чисел глобальный кэш сборок см. GAC Ч д Ч IPersist декартово соединение Ч делегат Ч Ч Ч атаки - Ч неисправностей Ч сервера дссериализация исключение дескриптор безопасности Ч 158, диаграмма Ч Ч Ч Ч потоков данных см. DFD Ч потоков управления К диспетчер канал именованный 48, 151, Ч локальной безопасности см. LSA качество обслуживания Ч служебных программ см.
класс доверительные вычисления Ч ж Ч журнал безопасности - жучок 5 Ч Ч Ч запись управления доступом Ч АСЕ Ч заплатка 58 Ч защита доступа к коду см. CAS Ч Password модификация Ч страниц сайтов 3 Ч значение инициирования Ч счетчика 227 Ч зона 361 Ч string Ч 666 Предметный указатель - КПП (контрольно-пропускной Ч 479 пункт) ключ 222, 250 криптографический провайдер -3DES 235 см. CSP - DSA 236 криптография - RSA 235 проверочное значение Ч временный 235 111, Ч длина Л Ч долгосрочный закрытый 100, 235, локальный диспетчер учетных - импорт записей см. SAM Ч краткосрочный Ч место Ч обмен максимальный период жизни Ч открытый 100, пакета в см. MSL Ч разложение на множители маркер 187, 188, 197, Ч сертификата Ч изменение Ч 235, Ч ограниченный 187, 199, 201.
Ч создание 203, Ч управление Ч случайный Ч шифрования 223, маршалинг Ч экспорт маска доступа 154, Ч эфемерный маскировка код метод Ч аутентификации сообщения см. MAC Ч Ч безопасный Ч Ч в плане инициализации -Clear Ч в плане исполнения Demand 469, 473, Ч Deny Ч внесение исправлений Ч Dispose Ч вырождение Ч Ч минимизация пользователей - 438, Ч Ч неработающий Ч Ч неуправляемый Ч Ч право на создание Ч Ч различия - управляемый 288, Ч Ч управляющий HTML Ч Invoke Ч 476, управляющий Ч кодовая позиция Ч команда параметризованная командная оболочка Ч Release компонент поддержки национальных языков см.
Ч конкатенация строк контекст пользователя - Validate контрольный след механизм удаленного вызова конфиденциальность процедур см.
Предметный указатель модель ПО Ч реакция Ч - тип Ч спиральная Ч уровень устранения модификатор 247, 259, 261 оператор 170 Ч Ч sizcof описатель контекста Ч нулевой оболочка Ч строгий Ч описатель пароля обратный анализ основное имя пользователя общеязыковая среда исполнения см. UPN ом.
основное службы см. SPN объект отравление Ч ошибка - Ч Unicode Ч Ч в строке форматирования Ч Ч буфера Ч на единицу - Ч индексации массива Ч Ч номер Ч отбрасывания Ч под угрозой 74, 78, 84- разряда Ч стыкуемый Ч регрессионная ограничение числа входящих Ч системы безопасности запросов станция олицетворение опасность 74 переполнение - DoS 72 Ч SYN-запросами 79, 81, 90 -буфера 108, 112, 125, 71, 81, 101 - дерево 73, 74, 77, 79, 87. 88. Ч кучи 89 Ч стека Ч категория 84, 86 подключаемый модуль Ч метод устранения 79, 92, 102 подпись автономная (detached) Ч моделирование 61, 78, Ч модель 60 протоколов Ч модификация Ч данных 72, 92, 258 поток Ч записей DNS 72 Ч данных Ч название 78 Ч Ч отказ от авторства 72. 92 приведение в канонический вид Ч повышение уровня привилегий 131, 313, 321, привилегия 97. 98, 101, 180. 73, Ч подлог DNS-сервера 72 Ч подмена сетевых объектов Ч Bypass Checking 92, 258 Ч Ч информации 72, 185, 187, 193, 210, Ч Ч раскрытие секретных данных Ч 181, 258 668 Предметный указатель 186, приманка 211, 214 пространство имен Ч Ч Ч Ч 287, Ч Ч 2 \ 3 Ч SeDebugPrivilege 184, 193, 210, 213, 258 Ч Ч Ч 243.
Ч Ч Ч 210, 213 2 Ч 185, Ч 308, Ч SelncreaseQuotaPrivilege Ч Ч 185, 210. протокол Ч передачи гипертекста см HTTP 193, Ч печати см. IPP проход стека Ч 193, Ч Ч Ч 473, Ч Ч Ч 470, 473.
192, Ч 184, Ч Ч 192, 193, 210, Ч Ч Ч 192, 210, Ч Ч Ч Ч Ч 210, Ч Ч Ч декларативное Ч 193, 210, Ч императивное Ч серверное 97, Ч регулярные 304, 210, 330, 331, - 192, 212, редактор конфигурации Ч безопасности Ч атрибут режим сквозной (приема всех Ч область пакетов) 75, 177, реквизит Ч оптимальный набор риск 78, 84, 85, Ч Ч вероятность обнаружения Ч удаление Ч воспроизводимость привязка Ч крут пользователей, попадающих приложение под удар Ч анализ Ч оценка Ч декомпозиция Ч подверженность Ч использования указатель Ч потенциальный ущерб триггер 170, Ч суммарный 89 троянец (троянский конь) роль 170, 172, сборка удаление тупиковых записей Ч разрешение на доступ 469 удаленный вызов процедур Ч строгое имя 287, 467 см. RPC Ч частичное доверие удаленный рабочий стол свойство универсальное соглашение об Ч 364 именовании общих ресурсов - 364 см. UNC Ч 362, 363 управление доступом 180, Ч 360 управляемый код Ч усечение Ч участник безопасности 93, 171.
сервер терминалов 155, ф 483, сетевой анализатор фильтрация 92. символ подстановки функция система - системная таблица управления Ч доступом см. SACL Ч сканирование портов Ч смарт-карта 9б Ч событие 193, Ч Ч Ч bind Ч onclick Ч Ч onload - close Ч - сокст 189, Ч составные символы Ч 435, 437, список управления доступом Ч 381, см.
Ч ссылка - Ч жесткая 181, 192. 318, 320.
Ч объектная Ч символическая Ч стековый cookie-файл Ч суперпользователь Ч 187, 193, суррогатная пара Ч сценарий 4, Ч Ч Ч \ точка Ч Ч критического сбоя Ч Ч соединения 440 Ч 670 Предметный указатель Ч 225, 228, 230, Ч Ч 260 95, Ч Ч Ч 263 Ч 189, 264, - 262, 263 Ч 280 189, 264, Ч 228 Ч Ч 262 Ч Ч 280 133, Ч 277 -main 117, 121, Ч Ч - 206 Ч 420 - 336, Ч 459 381, Ч 371 Ч 2 - 140 Ч - 387 Ч Ч - 197 - Ч 239 Ч Ч - 332 Ч - GetKey 236 Ч Ч 236 Ч Ч 332 Ч Ч 164 Ч rattrf Ч 197 - 140 Ч Ч 164 Ч Ч 132, 372 Ч 148, - Ч 197 419, Ч 340 Ч Ч Ч Ч Ч Ч Ч 276 - Ч Ч - 276 ~ Ч - Ч Ч Ч 367 Ч Ч Ч Ч 138, Ч Ч Ч Ч Ч Ч - 380, 381 Ч Предметный указатель хеш Ч с ключом 249, Ч с модификатором данных хеширование хранимая процедура Ч Ч Time - Ч shutdown - sizeof цифровая подпись 100, Ч создание шифрование 92, Ч асимметричное Ч блочное StrCpyN Ч потоковое Ч симметричное шифрующая файловая система 455, EFS энтропия системная эффект Хоторна 193, 378, 381, язык Ч объектного моделирования дайджеста 99, см.
криптографическая Ч определения дескрипторов согласующаяся безопасности см. SDDL оболочка ящик почтовый строковая хеш Майкл Ховард Майкл Ховард занимает пост старшего ме неджера программы по а также является одним из создателей и ак тивным участником Secure Windows Initia tive Ч команды, которая сотрудничает с проектировщиками, программистами и те помогая им системы. Он приложил нема ло усилий для большинства кампаний по безопасности в Microsoft.
Майкл живет в г. штат Вашингтон, недалеко от университетского городка Mic с женой, сыном и двумя собаками.
Дэвид Лебланк Дэвид Лебланк, доктор философии, в насто ящее время работает в команде Security Stra tegies в Microsoft, которая следит за безопас ностью продуктов Microsoft. Прежде он в качестве разработчика инструментальных средств и хакера занимался защи той внутренней сети Microsoft. До прихода в Microsoft возглавлял команду, создавшую версию для Windows NT сетевого анализато ра Scanner компании Security В получил звание доктора философии по охране окружающей среды в Техническом университете штата Джорджия. История о том, как он занялся защитой компьютеров, хотя ранее долгое время изучал вред, наносимый отработавшими автомобильными интересна, но слишком длинна и здесь не поместится. Дэвид живет около городка Монро, штат Вашингтон, с женой, пятью собаками, пятью лошадьми, котами, число которых постоянно варьируется, и рыбами. Если вы дается погожий денек, Дэвид выбирается на конную прогулку горы Каскады.
Ховард Майкл, Дэвид Защищенный код 2-е издание, исправленное Перевод с английского под общей редакцией А. Р.
Редактор П. Леонова Технические редакторы О. В. Г.
Корректор Л. А, Компьютерная верстка В. Б.
Дизайнер обложки Е. В. Козлова Оригинал-макет выполнен с использованием издательской системы Adobe PageMaker 6. Главный редактор А. И. Козлов Подготовлено к печати издательством Русская г. Москва, ул.
(095) 256-5120, тел./факс (095) 256- ru, www.rusedic.ru и.
Подписано в печать Тираж экз.
Формат л. Отпечатано в ОАО Типография 105005, Москва, ул. Фр. Энгельса, Press компьютерной литературы тел/факс sedit.ru;
серии я (095) 256-5120;
(095) ин компании?
обучение. быстро меняются. же быстро устаревают Мы и способ обучения. Мы ! разработать специально вашей компании, для в области IT, которые повысить свой Большое уделяется вопросам построения компании - вопросам безопасности, защиты резервному гети и др.
учебным центром Microsoft. и яр, Высокое качество Обучение по офи Высокое качество крупнейших в ТОП обучения. ориентируется на с корпоративными Мы разработку- программы обуче я Д митра к о по Наши Вы приобрести Х в Мясницкая. 6, (095) 928- дом ул. S.
Дом технической пр-т, (D95) 137- гвардия ул. Большая 28, Дом книги на Соколе пр-т, 78, (095} 152- Дом книги на 13, (095) 150- Торговый книги ул. Тверская, S, 229- и деловая книга Пенинский проспект, строение 38.
(095) Х в Санкт-Петербурге:
Дои СПб Дом военной 314- Магазин Подписные издания Литейный пр-т. 57, (812) 273- Магазин книга, ул. 2.
(812) Магазин Невский 13, ЗАО Торговый Дом (812) магазин и техника, (812) 567- Х в Екатеринбурге:
Книготорговая книги, 12, (3432) 59-4200, 59- Х в и ул. Большая 44.
Дворец Молодежи, 2-й этаж Х в Новосибирске:
Pages: | 1 | ... | 8 | 9 | 10 | Книги, научные публикации