Действительно ли защищены
Ваши web-приложения?
не т е"мс сте
ASP.NET Web Application Securit
■ Все тайны системы ASP.Net
■ Приемы защиты баз данных
■ Конкретные примеры шифрования на С# и VB Net
Данное издание уникально. В нем описаны
разнообразные виды атак, угрожающих web-
приложениям. Эти угрозы связаны с ошибками при
предоставлении полномочий пользователей и их
авторизации; при шифровании конфиденциальных
данных; при установке индивидуальных уровней
доступа; при обеспечении безопасности с помощью
XML. Для каждого вида атаки даны несколько
вариантов решений и настроек системы.
Авторы привели примеры конкретных записей для ^5^
программистов, а также подробности настройки NEW
системы для каждой из описанных угроз. house
Hacking syngress*
the Code
The Definition of a
PNETWb Apple lOnSecUl Serious Security Library™
www.nph.ru www.syngress.com

fr •/•%М|1^" ••***""*
.}>%;/■'■$.. •■""'' ^#^'Й
■^M^^j
i -'- '':"- - , >; к -.fife*-''%?£ У'0ЩЪг'&&^&%'*'^ '<~/'^"'-.~ i'
ASP.NET Web Aftftlkation Security
•'■*,•< *Ф#1:«'У%?«2
Mark M. Burnett
James C. Foster Technical Editor
SYNGRESS
®

J
ASP.NET Web Application Security
Марк М. Барнетт
Джеймс К. Фостер Технический редактор
[SJEW
PUBLISHING
HOUSE

УДК 004.382.7
ББК 32.81
Б24
Книга издана при участии технического редактора
Джеймса К. Фостера
Барнетт М., Фостер Д.
Б24 Хакинг кода: ASP.NET Web Application Security / Марк Барнетт, Джеймс
Фостер. — М.: ЗАО «Новый издательский дом», 2005. — 464 с.
ISBN 5-9643-0069-3
Тема атак на различные базы данных, особенно тех, где содержится финансовая
информация, сегодня очень актуальна. Умелый хакер может добыть информацию о
вашей кредитной карте, подобрав пароль или обойдя систему безопасности сервера
вашего банка. Задача программистов и системных администраторов этого банка — уберечь
конфиденциальную информацию от хакинга. Хакинг — это искусство взлома
всевозможных систем, уничтожение информации на удаленных компьютерах, воровство
информации, действия по нанесению вреда компьютерным сетям.
В данном издании описаны основные виды атак, с помощью которых хакеры
могут получить доступ к важной информации. Эти угрозы связаны с ошибками при
предоставлении полномочий пользователей и авторизации их; при шифровании
конфиденциальных данных; при установке индивидуальных уровней доступа; при
обеспечении безопасности с помощью XML. Авторы привели примеры конкретных записей для
программистов, а также подробности настройки системы для защиты от каждой из
описанных атак. Детально освещены все аспекты, связанные с предоставлением паролей к
аккаунтам, постановкой секретных вопросов, аутентификацией и авторизацией
пользователей.
«Хакинг кода» поможет программистам и системным администраторам
предотвратить атаки на пользовательские ячейки и web-сайты.
УДК 004.382.7
ББК 32.81
Original English language edition published by Syngress Publishing, Inc.
© 2004 by Syngress Publishing, Inc. All rights reserved.
ISBN 1-932266-65-8 (англ.) © Syngress Publishing, Inc., 2004
ISBN 5-9643-0069-3 (рус.) © ЗАО «Новый издательский дом», 2005

Благодарности
Мы хотели бы поблагодарить всех людей, чьи помощь и доброе отношение
сделали возможным публикацию этой книги:
В настоящее время книги распространяются в США под руководством
O'Reilly&Associates. Мы хотим поблагодарить всех сотрудников ORA,
потративших свое время и силы для того, чтобы эта книга вышла на рынок. Вот
их список: Тим О'Рэйли, Лаура Болдвин, Марк Брокеринг, Майк Леонард, Донна
Селенко, Бонни Шихан, Синди Дэвис, Грант Киккерт, Опол Матсутаро, Линн
Шварц, Стив Найзелвуд, Марк Уилсон, Рик Браун, Лесли Беккер, Джил Лотроп,
Тим Хинтон, Кайли Харт, Сара Уиндж, С. Дж. Рэйхилл, Питер Пардо, Лесли
Крэнделл, Валери Доу, Реджина Аджио, Паскаль Хоншер, Претон Паулль,
Сьюзан Томпсон, Брюс Стюарт, Лаура Шимье, Сью Уиллинг и Марк Якобсен,
Бетси Валишевски, Даун Манн, Катрин Барретт и Роб Баллингтон. Отдельная
благодарность Джогу Чодаки за помощь с Сафари.
Мы хотим отметить невероятную трудоспособность команды из Elsevier Science.
Эти люди помогли распространить наши идеи по всему миру: Джонатан Банкелл,
Иен Сигер, Данкан Энрайт, Дэвид Бертон, Розанна Рамадзотти, Роберт
Фэйрброзер, Мигель Санчес, Клаус Беран, Эмма Уайт, Рози Мосс, Крис Хоссак и
Криста Леппико.
Давид Бакленд, Венди Вонг, Даниэл Ло, Мэри Чинг, Люси Чонг, Лесли Лим,
Андрю Ген, Панг Аи Нуа и Джозеф Чен из STP Distributors — спасибо за
энтузиазм, с которым они принимали наши книги.
Благодарим Квон Санг Джуна из Acorn Publishing за общую поддержку.
Дэвид Скотт, Трисия Уилден, Марилла Берджесс, Аннет Скотт, Джефф Еббс,
Недли Партис, Век Лоу, и Марк Ланджели — их мы благодарим за продвижение
книг в Австралии, Новой Зеландии, Папуа Новой Гвинеи, Фиджи и Тонга, на
Соломоновых островах и островах Кука.
Мы признательны Уинстону Лиму из Global Publishing за помощь и поддержку в
Распространении книг на Филиппинах.

Автор
Марк Барнетт (Microsoft MVP) — независимый консультант по
безопасности, писатель-фрилансер и специалист по IIS Web-серверам,
основанным на Windows. Марк является соавтором Maximum Windows
Security и автором статей в Stealing the Network: How to Own the Box
(Syngress Publishing, 1-9311836-87-6) и Dr.Tom Shinder's ISA Server and
Beyond: Real World Security Solutions for Microsoft Enterprise Networks
(Syngress Publishing, ISBN: 1-931836-66-3). Он является автором и
техническим редактором Syngress Publishing Special Ops: Host and Network
Security for Microsoft, UNIX, and Oracle (ISBN: 1-931836-69-8). Бурнетт
выступает на различных конференциях по защите и опубликовал ряд
статей в Windows &.NET., Information Security, Windows Web Solutions,
Security Administrator, является постоянным участником SecurityFocus.com
Марк также публикует статьи на собственном web-сайте USSecurity.info.
Ассистент
Джошуа Скиллингс руководит Software Engineer for Trade West System,
LLC, консалтинговой компанией по созданию приложений для
финансовой промышленности. Джошуа окончил университет Brigham
Young со степенью BS по информатике. Являлся президентом клуба
Ассоциации по вычислительной технике. Он использует .NET. со времен
Beta 2 и занимался написанием самых разных видов игр, приложений для
карманных компьютеров, web-сайтов и средств безопасности, используя
NET Framework. Скиллинг живет с женой и двумя детьми в Сэнди, штат
Юта.

Содержание
Глава 1. Управление пользователями 1
Введение 2
Понимание опасностей 2
Правильный выбор идентификационных данных 3
Установка паролей 4
Надежность паролей 6
Способы защиты 10
Выбор надежных логинов 10
Способы защиты 12
Предотвращение сбора логинов 13
Сценарий: Проверка аккаунта пользователя 13
Сценарий: Король Спама *,. .14
Сценарий: Хакер > * *. v.*. *. v>* Д4"'
Контро^нзд информацией, удостоверяющей личй^да ,:^УД5
Способы ЩЩЙТЫ ♦..*...* *.Л4 *ч* «.» «^**&* -* *;.*
Ограничение неиспользуемых аккаувягаь,,,;^,^,^»^,,,.,.... «016
L^nOCOObl ^ЩрЗЙТЫ +шттшщ$!г«г* *^%^^щ^:;^^г *. ♦ »• • * «^
Правление паЦ^Ци <*Шшь ря»->г • ******* - * *- *-* * 19
Хранение ^^^^WM^mw^mw^ ♦ • ■ - -■ - — - - -~ ^ _ ,. Д9
Способы заирТ* а:,^,.. *..,> .»♦ к ♦... v *.*,.♦♦• ,21
Сроки действ^рГ ис1горн#1^]р|ля ♦, „ , * Л . * 22
Способы защиты ,£«..>„. 1>Й. *U* * - 25
Замена пароМА ;>. t.. * ..*..,* * 25
Способы защиты * ., 27
Переустановка потерянных или забытых паролей 28
Переустановка паролей 28
Способы защиты 33
Отправка информации по электронной почте 34
Способы защиты 36
Присвоение временных паролей 36
Построение кода 37
Взлом кода ..„..,** 37

Способы защиты 37
Использование секретных вопросов 38
Построение кода 41
Способы защиты 42
Предоставление прав пользователям 42
Обучение пользователей 42
Способы защиты 44
Вовлечение пользователей 44
Способы защиты 45
Краткая справка по стандартам кодирования 46
Установка логинов пользователя 46
Навязывание надежных паролей 46
Уход от легко угадываемых логинов 46
Предотвращение сбора логинов 46
Управление паролями 46
Хранение паролей 46
Срок действия и история пароля 46
Изменение паролей 47
Переустановка потерянных или забытых паролей 47
Переустановка паролей 47
Отправка информации по электронной почте 47
Присвоение временных паролей 47
Использование секретных вопросов 47
Предоставление прав пользователям 48
Обучение пользователей 48
Краткая справка по проверке кода 48
Установление логина пользователя 48
Обеспечение безопасного входа 48
Проблема использования легко угадываемых логинов 48
Предотвращение сбора логинов 48
Ограничение на неиспользуемые аккаунты 48
Управление паролями 49
Хранение паролей 49
Срок действия и история пароля 49
Изменение паролей 49
Переустановка потерянных или забытых паролей 49
Переустановка паролей 19
Отправка сообщений по электронной почте 49
Присвоение временных паролей 50
Использование секретных вопросов 50
Предоставление прав пользователям 50

Обучение пользователей 50
Вовлечение пользователей 50
FAQ 51
Глава 2. Проверка подлинности пользователей 53
Введение 54
Понимание опасностей 54
Опознавание пользователей 55
Построение форм регистрации 55
Способы защиты 57
Использование форм опознавания 58
Конфигурация форм опознавания 64
Способы защиты 65
Использование системы определения подлинности
пользователя\\^пс1о\У8 65
Базовая аутентификация 66
Справочная аутентификация 67
Интегрированная аутентификация Windows 68
Отображение логина клиента 69
Опознавание пользователей 70
Способы защиты 75
Использование паспортного опознавания 75
Способы защиты 77
Блокирование лобовых атак 78
Блокирование аккаунтов 79
Поиск других контрмер 80
Способы защиты 85
Авторизация пользователей 86
Принятие решения о способе авторизации 86
Личные параметры, основы и роли 87
Роли и ресурсы 90
Способы защиты 90
Авторизация используемых файлов 90
Способы защиты 92
Применение авторизации URL 92
Пользователи и роли 92
Операции HTTP 94
Файлы и пути 96
Конфигурация иерархии 98
Способы защиты 99
Авторизация пользователей через коды 99

Декларативная авторизация 99
Императивная авторизация 100
Эксплицитная авторизация 101
Способы защиты 101
Краткая справка по стандартам кодирования 102
Аутентификация пользователей 102
Построение форм регистрации 102
Использование форм опознавания 102
Использование аутентификации Windows 102
Использование аутентификации Passport 102
Блокирование лобовых атак 102
Авторизация пользователей 103
Принятие решения о способе авторизации 103
Авторизация файлов 103
Применение URL-авторизации 103
Авторизация пользователей через код 104
Краткая справка по проверке кода 104
Аутентификация пользователей 104
Построение форм регистрации 104
Использование форм аутентификации 104
Использование аутентификации Windows 106
Использование аутентификации Passport 104
Блокирование лобовых атак 105
Авторизация пользователей 105
Принятие решения о способе авторизации 105
Авторизация файлов 105
Запрос авторизации URL 105
Авторизация пользователей через систему кодирования ... .105
FAQ 106
Глава 3. Управление сессиями 109
Введение ПО
Маркеры сессии ПО
Маркеры опознавания 111
Понимание опасностей 111
Поддерживающая структура 113
Разработка безопасного маркера 113
Как тесно связан маркер с сессией пользователя? ИЗ
Безопасен ли способ передачи маркеров от сервера
к клиенту? 114
Достаточно ли велико используемое приложением ключевое

пространство? 114
Достаточна ли мощность генератора случайных чисел,
используемого приложением? 114
Создает ли приложение новый маркер для каждого
соединения? 114
Примет ли система любой маркер клиента? 114
Может ли пользователь управлять маркером для перехода
на другой аккаунт? 115
Может ли приложение распознавать измененный
или недействительный маркер? 115
Идентифицирует ли маркер клиента? 115
Ограничивает ли маркер свои рамки? 115
Обладает ли маркер одновременно относительным
и абсолютным сроком действия? 115
Сохраняет ли клиент маркер после завершения сеанса? ... .116
Есть ли у пользователя опция завершения сеанса? 116
Можете ли вы удалить маркер с сервера? 116
Способы защиты 116
Выбор механизма маркера 117
Маркеры, основанные на URL 117
Маркеры, основанные на файлах cookies 118
Маркеры, основанные на форме 118
Способы защиты 119
Использование индикаторов состояния 119
Структура «в процессе» 120
Защита ASP.NET Service Status 120
Метод SQL-сервера 122
Основные установки 123
Способы защиты 123
Использование маркеров ASP.NET 124
Использование cookies 124
Домен cookies 125
Путь cookies 127
Окончание срока действия cookies 128
Безопасные cookies 130
Значение cookies 131
Способы защиты 131
Работа в режиме просмотра 131
Активирование режима просмотра 132
Защита режима просмотра 132
Способы защиты 135

Расширение структуры управления ASP.NET 135
Создание маркеров 136
Связь с клиентом 139
Способы защиты 141
Завершение сеансов 142
Способы защиты 144
Краткая справка по стандартам кодирования 145
Настройка состояния 145
Разработка безопасного маркера 145
Выбор механизма маркера 145
Использование индикатора состояния 145
Использование маркеров ASP.NET 146
Использование cookies 146
Работа с ViewState 146
Расширение структуры управления ASP.NET 146
Создание маркеров 146
Прекращение сеансов 147
Краткая справка по проверке кода 147
Настройка структуры 147
Разработка безопасного маркера 147
Выбор механизма маркера 148
Использование индикатора состояния 148
Использование маркеров ASP.NET 148
Использование cookies 148
Работа с ViewState 148
Расширение ASP.NET State Management 149
Создание маркеров 149
Прекращение сеансов 149
FAQ 150
Глава 4. Шифрование личных данных 153
Введение 154
Использование криптографии в ASP.NET 156
Использование симметричной криптографии 157
DES и 3DES 159
Алгоритм Rijndae 163
RC2 164
Выбор алгоритма 166
Установка ключа и векторов инициализации 169
Способы защиты 175
Использование ассиметричной криптографии 176

Работа с алгоритмами хэширования 177
Подтверждение целостности 180
Хэширование паролей 182
Способы защиты 185
Работа со свойствами шифрования .NET 185
Создание случайных чисел 185
Способы защиты 186
Очистка памяти 187
Способы защиты 189
Защита секретной информации 189
Хранение секретной информации в файле 191
Хранение секретной информации в системном реестре ... .193
Хранение секретной информации в базе данных 193
Хранение секретной информации с использованием DPAPI . .193
Способы защиты 194
Защита коммуникаций с SSL 195
Способы защиты 197
Краткая справка по стандартам кодирования 198
Использование шифрования в ASP.NET 198
Симметричное шифрование 198
Работа с алгоритмами хеширования 198
Работа со свойствами шифрования .NET 199
Создание случайных чисел 199
Очистка памяти 199
Защита секретной информации 199
Защита коммуникаций с SSL (протокол безопасности
соединений) 199
Краткая справка по проверке кода 200
Использование шифрования в ASP.NET 200
Использование симметричного шифрования 200
Работа с алгоритмами хэширования 200
Работа со свойствами шифрования .NET 200
Создание случайных чисел 200
Очистка памяти 200
Защита секретной информации 201
Защита коммуникаций с помощью SSL 201
FAQ 202
Глава 5. Фильтры на входе в систему 205
Введение 206
Запрет на злонамеренный доступ 207

Идентификационные ресурсы системы 208
Другие способы контроля 209
Способы защиты 211
Защитное программирование 211
Контрольные переменные 211
Централизация кода 213
Тестирование и аудит 214
Использование эксплицитных ссылок 214
Способы защиты 218
Ограничение на вход 218
Проверка границ 219
Контроль валидатора 220
Способы защиты 222
Сравнение с образцом 222
Удаление данных 225
Способы защиты 226
Отражение данных 226
Неавторизованный доступ к файлам 226
Отражение данных 227
Способы защиты 229
Шифрование данных 229
Способы защиты 234
Инкапсуляция 234
Способы защиты 235
Параметризация 235
Способы защиты 236
Двойное декодирование 237
Способы защиты 238
Проверка синтаксиса 239
Способы защиты 239
Управление исключениями 240
Способы защиты 241
Маленькие хитрости 241
Способы защиты 243
Ограничение незащищенности от преднамеренного входа 243
Сокращение поверхности атаки 244
Неиспользованный код 244
Ограничение доступа к системе 245
Способы защиты 247
Ограничение области действия атаки 247
Минимальные привилегии 247

Содержание
Система Server-side 248
Способы защиты 248
Укрепление серверных приложений 249
Длина запроса 249
Разрешенные символы 250
Способы защиты 250
Краткая справка по стандартам кодирования 251
Управление злонамеренным входом 251
Идентификация источников входа 251
Защитное программирование 251
Ограничение на вход 251
Проверка границ 251
Соответствие образцам 251
Отражение данных 252
Шифрование данных 252
Инкапсуляция 252
Параметризация 252
Двойное шифрование 252
Проверка синтаксиса 252
Обработка исключений 253
Маленькие хитрости 253
Ограничение незащищенности от преднамеренного входа ... .253
Сокращение поверхности, подверженной атакам 253
Ограничение области действия атаки 253
Укрепление серверных приложений 254
Краткая справка по проверке кода 254
Обработка информации, введенной при злонамеренном входе . .254
Идентификационные ресурсы системы 254
Защитное программирование 254
Ограничение входа 255
Проверка границ 255
Соответствие образцам 255
Отражение данных 255
Шифрование данных 255
Инкапсуляция 255
Параметризация 256
Двойное шифрование 256
Проверка синтаксиса 256
Обработка исключений 256
Маленькие хитрости 256
Ограничение незащищенности от преднамеренного входа ... .257

Сокращение поверхности атаки 257
Ограничение области действия атаки 257
Укрепление приложений сервера 257
FAQ 258
Глава 6. Доступ к данным 261
Введение 262
Защита баз данных 263
Защита структуры баз данных 263
Способы защиты 265
Ограничение поверхности, подверженной атаке 265
Защита специфических драйверов 267
SQL-сервер 267
IIS и ODBC 269
Jet и ISAM 269
Способы защиты 270
Обеспечение наименьшей защищенности 271
Способы защиты 272
Защита баз данных 272
Способы защиты 274
Написание безопасной программы доступа к базе данных 274
Связь с источником данных 274
Опознавание 275
Защита строк соединений 277
Авторизация 279
Способы защиты 279
Защита от SQL-запросов 280
Пример SQL-запроса 280
Избегайте использования «опасных» символов 285
Использование SqlParameters 287
Прописывания типа и длины данных 289
Использование минимальных привилегий 289
Запрет на употребление опасных команд 289
Работа сервера с ошибками 290
Способы защиты 291
Написание безопасного SQL-кода 291
Способы защиты 296
Чтение и написание массивов данных 296
Способы защиты 302
Краткая справка по стандартам кодирования 303
Защита драйверов базы данных 303

Ограничение поверхности, подверженной атаке 303
Защита драйверов базы данных 303
Защита баз данных 303
Защита размещения базы данных 303
Обеспечение наименьших привилегий 303
Защита базы данных 303
Написание безопасной программы доступа к базе данных 304
Соединение с источником данных 304
Защита от SQL-запросов 304
Написание защиты SQL 304
Чтение и написание массивов данных 304
Краткая справка по проверке кода 305
Защита драйверов базы данных 305
Ограничение поверхности, подверженной атаке 305
Защита драйверов базы данных 305
Защита баз данных 305
Защита структуры базы данных 305
Обеспечение наименьших привилегий 305
Защита баз данных 306
Написание безопасной программе доступа к базе данных 306
Соединение с источником данных 306
Защита от SQL-запросов 306
Написание безопасного SQL-кода 306
Чтение и написание массивов данных 307
FAQ 307
Глава 7. Разработка безопасных приложений ASP.NET .. .309
Введение 310
Понимание опасностей 310
Написание безопасного HTML-кода 310
Построение защиты HTML 311
Предотвращение CSS-атак 311
Способы защиты 314
Предотвращение утечки информации 315
Способы защиты 316
Обработка исключений 316
Использование структурной обработки ошибок 318
Неструктурная обработка ошибок 318
Структурная обработка ошибок 319
Способы защиты 321
Составление отчетов и регистрация ошибок 322

Общие ошибки 322
Регистрация ошибок 323
Способы защиты 325
Краткая справка по стандартам кодирования 326
Написание безопасного HTML-кода 326
Обеспечение защиты HTML 326
Защита от утечки информации 326
Обработка исключений 326
Использование структурной обработки ошибок 326
Составление отчетов и регистрация ошибок 327
Краткая справка по проверке кода 327
Написание безопасного HTML-кода 327
Обеспечение защиты HTML 327
Защита от утечки информации 328
Обработка исключений 328
Использование структурной обработки ошибок 328
Составление отчетов и регистрация ошибок 328
FAQ 329
Глава 8. Безопасноть в XML 331
Введение 332
Применение XML 332
Шифрование данных в XML 333
Спецификация XML- шифрования 333
Процесс шифрования XML 338
Пример шифрования XML 339
Способы защиты 345
Применение цифровых подписей XML 347
Подпись данных XML 347
Спецификация цифровых подписей XML 348
Пример цифровой подписи XML 350
Способы защиты 356
Краткая справка по стандартам кодирования357
Применение шифрования XML 357
Шифрование данных XML 357
Применение цифровых подписей XML 357
Обозначение данных XML 357
Краткая справка по проверке кода 357
Применение шифрования XML 357
Шифрование данных XML 357
Применение цифровых подписей XML 358

Обозначение данных XML 358
FAQ 358
Приложение А. Основные понятия .NET-Security 361
Введение 362
Полномочия 362
Механизм Principal 363
Опознавание 364
Авторизация 364
Способы защиты 364
Безопасный тип 365
Защита кода доступа (Code Access Security — CAS) 365
.NET Code Access Security Mode 365
Нестрогая очередность (Stack Walking) 365
Идентичность кода 368
Группы кода 369
Декларативная и императивная безопасность 372
Запрашивание полномочий 374
Требование полномочий 377
Отмена проверок безопасности 380
Собственные полномочия 385
Ролевая безопасность 387
Principal 387
Windows Principal 389
GenericPrincipal 390
Манипулирование идентичностью 391
Ролевая проверка безопасности 394
Способы защиты 398
Создание нового набора полномочий 401
Модификация структуры кода группы 406
Удаленная безопасность 414
Криптография 414
Инструменты безопасности 418
Итог 421
Система безопасности Fast Track 422
Инструменты безопасности 425
FAQ 426
Приложение В. Глоссарий 429
Предметный указатель 433

Глава 1
Решения в этой главе:
а Логин пользователя
а Управление паролями
О Переустановка потерянн|Ш*р«1
паролей Фж0ййа "
Краткая справка по стандартам
кодирования
Краткая справка по проверке кода
FAQ

Глава 1 * Управление пользователями
Введение
Пользователь и его личная информация - основной объект систем
обеспечения безопасности web-приложений.
У каждого web-приложения свой уровень риска и чувствительности. Для
расстановки приоритетов в защите пользователей вам необходимо определить
степень риска в вашей организации. То, как вы построите web-приложение, в
значительной степени будет влиять на степень вовлеченности пользователей в
обеспечение безопасности. Они не всегда относятся к защите информации с должным
уровнем ответственности, но вы, будучи профессионалом по обеспечению
безопасности, должны быть уверены, что данные надежно защищены.
Обратите внимание на доступные для зарегистрированных пользователей
архивы статей он-лайн-журналов. Владельцы хотят защитить свои авторские права,
поэтому для получения доступа к статьям пользователю необходимо пройти
аутентификацию. В этом случае пользователи не хранят личную информацию на web-
сайте и не должны беспокоиться о конфиденциальности данных, возможно, они
даже делятся своей регистрационной информацией со своими друзьями, позволяя
им, таким образом, тоже получать доступ к защищенным статьям.
Пользователей волнует защищенность информации, возможно, даже больше,
чем web-мастеров. Многие компании не уделяют должного внимания защите
информации до тех пор, пока не станет поздно. В марте 2001 года Национальный
центр защиты инфраструктуры США (НЦЗИ) Федерального Бюро Расследований
(ФБР) сделал заявление, что хакеры похитили информацию о кредитных
карточках и пытались вымогать деньги у владельцев web-сайта, взломав web-сайты
электронной коммерции и банковского оборота. Хакеры воспользовались знанием
слабых мест Windows, которые не были бы настолько уязвимы, если бы web-масте-
ры использовали обновленные защитные «заплаты». НЦЗИ заявил, что хакерами
были похищены номера более чем миллиона кредитных карточек из 40 компаний.
Становится очевидным, что эти компании безответственно подходили к
вопросу защиты информации пользователей. Подобное беспечное отношение
ставит под удар личную информацию пользователей.
Независимо от того, кто является слабым звеном - разработчики web-сайтов
или пользователи, - защита web-сайта начинается с работы с пользователями.
Понимание опасностей
Основные типы опасностей, рассмотренные в этой главе:
■ Подбор пароля методом лобовой атаки. Этот вид взлома представляет собой
процесс вычисления пароля пользователя набором различных комбинаций символов.
Подбор пароля методом лобовой атаки может быть оптимизирован использованием
словарных слов, общих паролей или легко предсказуемых комбинаций символов.

Управление пользователями • Глава 1
■ Перехват аккаунта. Данный способ представляет собой перехват аккаунта
законного пользователя, иногда с блокированием доступа этого
пользователя к его аккаунту.
■ «Социальная инженерия». Это процесс использования навыков
программирования (вместо программного и технического оборудования) для
выяснения ценной информации (например, паролей), которая может быть
использована для компрометирования системы.
■ Спаминг. Общеизвестный вид деятельности, включающий в себя процесс
рассылки больших объемов нежелательных электронных сообщений
пользователю или web-сайту, приводящих к засорению Интернет-линий и
иногда к фатальному сбою сервера.
Правильный выбор
идентификационных данных
Защита пользователя начинается с выбора имени пользователя и пароля.
Выбирая логин и пароль или позволяя пользователю самому выбирать их, вы тем
самым демонстрируете необходимость защиты. В этом разделе вы узнаете о:
■ Обеспечении надежных паролей
■ Избежании легко угадываемых логинов
■ Предотвращении несанкционированного доступа
■ Возврате сохраненных сообщений об ошибке
■ Ограничении неиспользуемых аккаунтов
Подсказка
Вы всегда должны требовать и имя пользователя, и пароль. Иногда встречаются
web-приложения, требующие только пароль для входа в систему. Но необходимо
учесть сценарий, в котором пользователь меняет свой пароль и выясняет, что
данный код уже используется; в такой ситуации этот пользователь должен получить
новый логин. Всегда требуйте общий логин (имя пользователя) для идентификации
пользователя и личный логин (пароль) для аутентификации пользователя.

Глава 1 * Управление пользователями
Установка паролей
Исходное положение: Используйте технические средства и методы
для обеспечения безопасного входа
пользователей в систему.
Угроза: Подбор пароля методом лобовой атаки,
перехват аккаунта.
Если пароли являются центральным механизмом безопасности вашего
приложения, вы должны быть уверены в их надежности. Убедитесь, что они достаточно
сложные, чтобы предотвратить нежелательный доступ. Надежная методика
создания пароля такова:
■ Установить пароль длиной не менее 8 символов
■ Не ограничивать максимальную длину пароля
■ Установить пароль, состоящий из букв, цифр и знаков препинания
■ Позволить пользователям использовать в своих паролях любые символы
клавиатуры, включая пробелы
■ Не разрешать устанавливать в качестве пароля словарные слова
■ Не разрешать использовать в качестве части пароля личное имя пользователя
Подсказка
Пользователям иногда трудно придумать сложный пароль. Чтобы избежать этой
проблемы, вам необходимо совмещать как длину, так и использование
различных символов в качестве фактора усложнения пароля. Длинные пароли, в
которых используются только буквы, по эффективности соотносимы с более
короткими паролями с использованием различных символов. Проще говоря, добавление
от двух до четырех символов к паролю так же эффективно, как и добавление
цифры или знака препинания. Шестизначный пароль, состоящий из строчных и
заглавных букв и знаков пунктуации, приблизительно равноценен по сложности
восьмизначному паролю из строчных букв.
Многие популярные web-сайты не устанавливают минимальную длину пароля
или устанавливают минимальную длину, слишком маленькую для обеспечения
безопасности. Рис. 1.1 показывает web-сайт, который принимает только
трёхзначные пароли, а ограничение на максимум составляет 25 символов.

Управление пользователями • Глава 1
Минимальная длина недостаточна, и хотя 25 символов - это длинный пароль,
зачем вообще устанавливать какие-либо ограничения?
Рис.1-1 Пример слабого пароля
шсо
asswords ust ave at least 3 char cters and no more t an 25 characters
First Name
Last Name:
Подсказка
Ещё одним преимуществом длинного пароля является сокращение количества
словарных слов, которые пользователь может использовать в качестве пароля.
Пароли, взятые из словаря, легко вычислимы и должны избегаться. Установка
минимальной длины пароля в восемь символов исключает все слова от трех
до семи символов, которых в английском словаре насчитывается около 50,000.
Эти 50,000 слов входят в состав легко угадываемых паролей.
Если вы не установите требования по усложнению, многие пользователи
выберут предсказуемые, легко угадываемые пароли. Слабые пароли легко уязвимы для
подбора пароля методом лобовой атаки. Если пароли недостаточно длинные
и не содержат набора различных символов, количество возможных вариантов
Для подбора пароля методом лобовой атаки резко снижается. Если противнику
удается вычислить пароль пользователя, он использует его для доступа к
конфиденциальной информации, сбора персональных данных пользователя, а также может
вьщать себя за данного пользователя для достижения различных целей, стереть
или изменить данные или даже уничтожить аккаунт пользователя.

Глава 1 * Управление пользователями
Внимание
Зачастую взломщики пытаются угадать пароли пользователей eBay,
просматривая пользовательскую страничку About me (Обо мне) и собирая информацию
об именах детей, домашних животных, друзей, автомобилях или других интересах.
Если взломщику удается вычислить пароль, он залезает на аккаунт, изменяет
пароль и контактную информацию, а затем совершает мнимые покупки под аккаун-
том этого пользователя. Таким образом, он пользуется репутацией и
информацией жертвы для мошенничества по отношению к другим пользователям.
Надежность паролей
Чтобы проверить сложность пароля, воспользуйтесь функцией Оценка
стандартных фраз или функцией Подтверждение подлинности пользователя, как показано на
примере 1.2. Этот код преобразует Подтверждение подлинности пользователя в
текстовый пароль. При подтверждении формы входа применяется функция Проверки
контроля. Это показано на примере использования С# на рис. 1.2. и VB.NET в примере 1.3.
Пример 1.2. Подтверждение пароля использованием функции
Подтверждение подлинности пользователя: С#
<HTML>
<HEAD>
<TITLE>Password Checker</TITLE>
<SCRIPT language="C#" Runat="Server">
public void Button_Click(object sender, EventArgs e)
{
if (Page.IsValid)
{
Response.Write("Password passes complexity requirements.");
}
else
{
Response.Write("Password does not pass complexity requirements.");
}
}
public void PasswordCheck(object sender,
System.Web.UI.WebControls.ServerValidateEventArgs eventArgs)
{
if (eventArgs.Value.Length < 8)
{

Управление пользователями • Глава 1
eventArgs.IsValid=false;
}
else
I
// Require any two of the following
// Change the -2 to adjust complexity requirements
// The lower the value, the stricter the requirements
if (0 -
Convert.ToInt32(Regex.IsMatch(eventArgs.Value,"[a-z]")) -
Convert.ToInt32(Regex.IsMatch(eventArgs.Value,"[A-Z]")) -
Convert.ToInt32(Regex.IsMatch(eventArgs.Value,"\\d")) -
Convert.ToInt32(Regex.IsMatch(eventArgs.Value,".{10,}")) <= -2)
{
eventArgs.IsValid = true;
}
else
{
eventArgs.IsValid - false;
}
}
}
</SCRIPT>
</HEAD>
<BODY>
<form id="Password" Runat="Server">
Password:
<br>
<asp:TextBox
id="txtPassword"
TextMode="Password"
Columns="30"
Runat="Server" />
<asp:CustomValidator
runat="server"
ControlToValidate="txtPassword"
OnServerValidate=,,PasswordCheck"
ErrorMessage="Invalid password."
id="CustomValidatorl" />
<P>
<asp:Button Text="Check Password"

Глава 1 * Управление пользователями
OnClick="Button_Click"
Runat="server"
id="Buttonl" />
</p>
</form>
</BODY>
</HTML>
Пример 1.3 Подтверждение пароля с использованием функции
Подтверждение подлинности пользователя: VB.NET
<HTML>
<HEAD>
<TITLE>Password Checker</TITLE>
<SCRIPT language="C#" Runat="Server">
Sub Button_Click(s As Object, e As EventArgs )
If Page.IsValid Then
Response.Write("Password passes complexity requirements.")
Else
Response.Write("Password does not pass complexity requirements.")
End If
End Sub
Sub PasswordCheck(oSource as Object, oArgs as
ServerValidateEventArgs)
If oArgs.Value.Length < 8 Then
oArgs.IsValid=False
Else
'Require any two of the following
'Change the -2 to adjust complexity requirements
'The lower the value, the stricter the requirements
If Regex.IsMatch(oArgs.Value,"[a-z]") + _
Regex.IsMatch(oArgs.Value,"[A-Z]")+ _
Regex.IsMatch(oArgs.Value,"\d") + _
Regex.IsMatch(oArgs.Value, ".{108, }") <= -2 Then
oArgs.IsValid = True
Else
oArgs.IsValid = False
End If
End If

Управление пользователями • Глава 1
End Sub
</SCRlPT>
</HEAD>
<BODY>
<form id="Password" Runat="Server">
Password:
<br>
<asp:TextBox
id="txtPassword"
TextMode="Password"
Columns=,,30"
Runat="Server" />
<asp:CustomValidator
runat="server"
ControlToValidate="txtPassword"
OnServerValidate="PasswordCheck"
ErrorMessage="Invalid password.'
id="CustomValidatorl" />
<P>
<asp:Button Text="Check Password"
OnClick="Button_Click"
Runat="server"
id="Buttonl" />
</p>
</form>
</BODY>
</HTML>
Наиболее очевидный способ взломать слабые пароли - это использовать
подбор пароля методом лобовой атаки против web-приложения. Инструменты
на http://neworder.box.sk/codebox.iinks.php?kev=wwwcrks полезны для взлома
пароля. Если web-приложение использует форму HTML для ввода пароля,
возможно, целесообразно будет применять инструменты типа Elza (www.security-
fecus.com /tools/1127). Разумеется, вам понадобится несколько списков слов,
которые можно найти на www.gattinger.org/wordiisits/downioad.htmi
или http://neworder.box.sk/codebox.iinks.php?key=passdict.

Глава 1 * Управление пользователями
Способы защиты
■ Убедитесь, что длина пароля составляет минимум восемь символов.
Пароль может быть такой длины, которую позволит операционная
система или приложение.
■ Пароль должен состоять минимум из двух наборов символов. Разрешите
пользователям использовать при составлении пароля любые символы
клавиатуры.
■ Пароль не должен быть словарным словом и не должен включать в себя
имя пользователя.
Выбор надежных логинов
Исходное положение: Имена пользователей или пароли, которые
легко вычислить, подвергают аккаунты взлому.
Угроза: Подбор пароля методом лобовой атаки,
вычисление пароля, перехват аккаунта.
Один из самых распространенных пробелов в защите в течение всей
истории компьютеров - это выбор легко угадываемого пароля. Несмотря на то,
что в последние годы появилось множество рекомендаций по установке
пароля, многие пользователи, а иногда и администраторы, продолжают
пользоваться паролями типа password, letmein или просто оставляют бланк для
ввода пароля пустым. Одна компания по предоставлению web-услуг обязала
персонал присваивать пароли новым покупателям. Персонал не приложил
никаких усилий для установки защиты паролей, а покупатели не стали
изменять присвоенные им пароли по умолчанию. Через два года работы
компания насчитывала 200 покупателей, пользующихся одним и тем же паролем:
dragon.
Несколько лет назад я создал аккаунт для теперь уже не существующего
web-сайта он-лайн-аукциона. Для регистрации пароля не требовалось,
но вместо этого владельцы web-сайта прислали мне по электронной почте
автоматически образованный пароль, который состоял из моего имени
пользователя с цифрой 22 на конце. Разумеется, они рекомендовали мне
изменить пароль сразу же после первой регистрации для входа в аккаунт, но
они не объяснили, как именно это сделать. Мне стало интересно, сколько
же пользователей на самом деле изменили свои пароли, и я стал пробовать
войти в систему под чужими логинами, добавляя цифру 22 к каждому из них.

Управление пользователями • Глава 1 ц
ступе мне было отказано, и тогда я стал добавлять цифры 11, 33, 44
далее, и вскоре получил пароли практически всех аккаунтов системы.
Кывод: если вы автоматически создаете пароли для своих пользователей, вам
ясно учитывать, что некоторые из них никогда не поменяют пароль, установлен-
й по умолчанию, если, конечно, этого не требует последовательность первой
гистрации. Таким образом, создавая пароль для пользователей, убедитесь, что
лгооитм случайного выбора пароля не создает легко вычисляемые пароли. Один
примеров образования надежного пароля - это инструмент Pafwert, доступный
на 3Qgw.xato.com/pafwert.
Подсказка
То, как вы объясняете, в значительной степени влияет на то, как пользователь
выбирает пароль. Например, избегайте запрашивания PIN-кода, который многие
пользователи ассоциируют с кодом банковского автомата, с чем, возможно,
связан их выбор четырехзначного цифрового пароля. Вместо этого запросите
пароль в виде фразы, или, как назвал его один web-сайт, «очень длинный пароль».
Общая проблема многих бесплатных или условно-бесплатных скриптов
интерфейса CGI (общий шлюзовой интерфейс), например web-форумов, - это то,
что у них при использовании функции администрирования пароли
устанавливаются по умолчанию. Если вы являетесь администратором подобного ресурса,
просто не устанавливайте логин по умолчанию, а позвольте пользователям создать
начальный пароль через процесс установки.
Легко угадываемые имена пользователей также могут стать серьезной
проблемой. Имена пользователей не являются такой конфиденциальной информацией,
как пароли, но, тем не менее, следует ограничить возможности других людей
пользоваться чьим-то именем, так как они все следуют последовательному или
предсказуемому шаблону (подробнее см. раздел «Предотвращение сбора логинов»).
1акже очень важно избегать общих административных имен аккаунта, таких
а* administrator, admin, system или operator. Методика блокирования пароля
всегда применяется к административным аккаунтам, и, таким образом, пароли
Р Дставляют собой привлекательную цель для подбора методом лобовой атаки
и Других видов взлома.

Глава 1 * Управление пользователями
Внимание
Если вы разрешаете пользователям самим выбирать логины, убедитесь, что они
не используют таких имен, как administrator, support, root, postmaster, abuse,
Webmaster, security и так далее. Хакер, создающий аккаунт с одним из этих имен,
вероятно, сможет «сыграть роль» других пользователей, обманным путем
заставляя их раскрывать свои пароли.
Легко угадываемые, предсказуемые пароли или пароли по умолчанию уязвимы
для вычисления или подбора методом лобовой атаки, так же как и легко
угадываемые имена пользователей. Подобные пробелы могут привести к компрометации
большого числа аккаунтов. Некоторые общие скрипты интерфейсов CGI (общие
шлюзовой интерфейс) используют пароли по умолчанию, и взломщик может
использовать поисковый механизм для обнаружения уязвимых web-сайтов.
Разработайте вашу систему таким образом, чтобы пользователи устанавливали
свои пароли при первом использовании аккаунта или приложения. Используйте
случайно выбранные пароли только в случае необходимости и только для
начальной регистрации пользователя в аккаунте, при условии, что после этого
приложение обяжет их изменить пароль. Избегайте построения системы, которая требует
прохождения каких-либо специфических моделей создания имени пользователя
или пароля.
Также избегайте любых кодов автоматического образования имен
пользователей или паролей, пока не предпримете дополнительных шагов для избежания
предсказуемых шаблонов. Позвольте пользователям самим выбирать себе логин и
пароль каждый раз, когда это возможно.
Способы защиты
■ Не позволяйте обслуживающему персоналу выбирать пароли для
покупателей.
■ Если пароль выбран случайно, избегайте предсказуемых, шаблонных
моделей или построения пароля на основе имени пользователя.
■ Никогда и ни для каких систем не используйте пароль по умолчанию.
■ Не вводите предсказуемые или последовательные имена аккаунтов
пользователей.
■ Не употребляйте очевидные имена для административных аккаунтов

Управление пользователями • Глава 1 13
Предотвращение сбора логинов
Исходное положение: Сбор логинов подвергает пользователей
многочисленным попыткам взлома.
Угроза: Подбор пароля методом лобовой атаки,
«социальная инженерия», спамминг.
Несколько лет назад мне позвонили. Мужчина на другом конце провода назвал
меня по имени и сказал, что он из моего банка и ему необходимо сверить
информацию о моем счете со своими записями. Это сразу же показалось мне
подозрительным, но я даже не успел ничего ответить, как он зачитал мне моё полное имя
и почтовый адрес. Адрес, который он назвал, был ошибочным, но именно в таком
виде он был записан в телефонной книге, что натолкнуло меня на мысль, что он
использует общедоступную информацию для того, чтобы выудить из меня другие
личные данные. Этот человек просто собирал имена из телефонной книги в целях
мошенничества. Следующий пример продемонстрирует риск подобного сбора
личной информации.
Сценарий: Проверка аккаунта пользователем
1. Эллис подписалась на аккаунт на банковском счете, прошла регистрацию
и обнаружила следующий URL:
http://bank.example.com/userid = 2184&account = checking
2. Сомневаясь, насколько в действительности это приложение банка
безопасно, Эллис изменила параметр userid:
http://bank.example.com/userid = 2000&account = checking
3. Теперь она обнаружила, что видит еще чей-то бухгалтерский реестр
аккаунта. Сделав ещё один шаг вперед, она попробовала следующее:
http://bank.example.com/userid = l&account = checking
"*• Она поняла, что это тестовый аккаунт, поэтому попробовала userid = 2,
который оказался аккаунтом члена совета директоров банка.
т>
Данном примере Эллис обнаружила дефект в приложении и воспользовалась
Дсказуемой последовательностью идентификатора пользователя для перехода
** Другие аккаунты.

Глава 1 • Управление пользователями
Сценарий: Король СПАМа
Боб, хорошо известный спаммер, написал программу для ежедневного
просмотра тысяч web-страниц всех популярных web-сайтов. На каждой странице его
скрипт выделяет имя каждого обнаруженного пользователя аукциона. После сбора
нескольких миллионов имен аккаунтов он составляет список и сравнивает каждое
имя пользователя с каждым из наиболее распространенных
Интернет-провайдеров: hotmail.com, msn.com, juno.com, aol.com, earthlink.net, yahoo.com и так далее.
Затем Боб рассылает электронную почту по всем выбранным адресам и
отслеживает, какие из аккаунтов действительны. По завершении он получает более
миллиона действительных аккаунтов электронных адресов. Конечно, первое
электронное спамерское сообщение, которое он отсылает, - это сообщение с
предложением о продаже миллиона реальных электронных адресов всего за $99.
Сценарий: Хакер
Чак - хакер. Он похищает идентификационную и финансовую информацию
у ничего не подозревающих людей, пользующихся услугами электронной
коммерции. Ему известно, что один web-сайт розничной торговли предоставляет
возможность покупателям хранить информацию об их кредитных карточках для
упрощения дальнейших покупок. Чак рассчитывает взломать аккаунт одного из клиентов
данного сервиса и похитить хранящуюся там информацию о кредитной карточке.
Для этого Чак составляет небольшой список распространенных имен
пользователей и паролей и подбирает пароль методом лобовой атаки. Очень скоро
выясняется, что web-сайт блокирует доступ к аккаунту, если пользователь допускает
ошибку при наборе пароля пять раз подряд. Но существует другой способ выяснения
пароля: Вместо подбора множества паролей к одному аккаунту он может попробовать
один или два распространенных пароля к многим различным аккаунтам
пользователя. Из статистики Чак знает, что, если попробовать подобрать несколько
распространенных паролей к достаточному количеству аккаунтов, он получит совпадение.
Теперь единственной проблемой остается сбор имен пользователей. Для этого
он пишет скрипт для подписки на аккаунты, используя случайные, но
распространенные имена пользователей. Скрипт заполняется, и подается форма подписки,
появляется надпись «Извините, этот логин уже используется». Если он получает
такое сообщение, скрипт сохраняет данное имя пользователя. Если нет, он
заканчивает сеанс связи и пробует зайти под новым именем пользователя.
Через несколько часов скрипт собирает несколько тысяч имен пользователей с этого
web-сайта. Данные из составленного списка вводятся в скрипт подбора пароля методов
лобовой атаки, который обнаруживает три аккаунта с паролем: asdf. Разумеется, три акка'
унта - это не самый большой успех, но теперь у него есть скрипты, он может пользовать'
ся ими каждый день, внося небольшие изменения для достижения лучшего результата.

Управление пользователями • Глава 1 15
Контроль над информацией,
удостоверяющей личность
Собрав имена пользователей, взломщик сможет собирать электронные адреса
амминга, пытаться выяснить обманным путем пароли у других пользовате-
й используя методы «социальной инженерии», метод прямого подбора пароля
гочисленных aKKayHTOBj или обнаружить другие слабые места приложения.
Лля остановки сбора информации, удостоверяющей личность нужно не
показывать имена пользователей и не использовать предсказуемых логинов. Однако
работа некоторых web-сайтов полностью основана на личных данных, поэтому вам
необходимо использовать многочисленные и разнообразные методы для решения
проблемы незащищенности идентификационной информации.
Разрабатывайте систему таким образом, чтобы имя пользователя не являлось
первичным ключом к базе данных. Это даст пользователям возможность изменять
свои имена без потери важной информации об аккаунте или истории. Одним из
методов защиты имен пользователей является создание одного и более
вымышленных имен, не использующихся при получении доступа к электронной ячейке.
Избегайте последовательных (нумерационных) или шаблонных имен
пользователей. При соединении клиентов с внешними (например, проверяющими) аккаунта-
ми не используйте текущие номера аккаунтов в качестве ID пользователя, потому
что они часто составляют последовательность, следовательно, взломщик легко
может получить доступ к информации.
Взимание
;} Изменение или использование вымышленных имен пользователей в некоторых
случаях может привести к злоупотреблениям. Прежде чем сделать подобную
Функцию доступной, нужно убедиться, что это подходит для вашего приложения.
Ч Например, один web-сайт позволяет изменять имя пользователя, но только один
раз в месяц. Это делается, чтобы предотвратить неправильное использование
электронной ячейки. Однако ничто не помешает злоумышленникам просто
создать новые аккаунты.
Лучший способ предотвратить сбор имен пользователей - просто не показы-
ь их на web-сайте. В случае если это нецелесообразно в вашем конкретном слу-
» можно попробовать обмануть некоторые скрипты автоматического сбора, из-
ив шифрование, используемое для написания имен пользователей.
*-Щё один важный принцип - это избежание передачи имени пользователя как
Раметра запроса строки для того, чтобы избежать его появления в истории обо-
ателя Интернет, в журнале регистрации и заголовках других web-сайтов, ссы-
Тть ^Ихся на протокол передачи гипертекста (HTTP). Рассмотрите следующие
^*-> которые могут появляться в web-регистрациях других web-сайтов.

16 Глава 1 • Управление пользователями
Вот первый пример:
www.example.com/inbox.sapx?userid=mburnett&folder=inbox
Второй пример:
www.example.com/inbox.aspx?session=3FAC-FF2E-8BlC-722F-391D
Второй пример лучше, поскольку URL не содержит идентификационной
информации.
Способы защиты
■ Никогда не используйте электронный адрес в качестве имени
пользователя и избегайте любого иного упоминания E-mail.
■ Не работайте с директориями общего доступа и «белыми страницами».
■ Разрешите пользователям менять имя пользователя, когда необходимо.
■ Позвольте клиентам присваивать одно и более вымышленных «ников» для
своих аккаунтов.
Ограничение неиспользуемых аккаунтов
Исходное положение: Неиспользуемые аккаунты представляют собой
легкую мишень для хакеров.
Угроза: Взлом аккаунта.
Если бы вы были хакером и захотели взломать аккаунт чьего-то web-сайта,
какую мишень вы бы выбрали? Разумеется, вы не стали бы взламывать аккаунт,
которым кто-то пользуется ежедневно, но вы также не стали бы обращать внимание
и на аккаунт, к которому никогда не обращались.
Устанавливая контроль над аккаунтом, взломщик может изменять пароль
и полностью блокировать законному пользователю доступ. Для хакера существует
множество причин взломать чужую учетную запись.
Неиспользуемые аккаунты подвержены риску, так как:
■ Владельцы его могут не знать о последних действиях или изменениях в
информации аккаунта.
■ Пароли могут быть устаревшими.
■ Пользователи могут даже не знать о том, что у них есть он-лайновый счет.

Управление пользователями * Глава 1
П V лет назад хакеры взломали web-сайт банка и получили доступ к его базе
х компьютерные воры воспользовались своими знаниями в области элек-
нного перевода денег и перевели все средства на другие электронные счета.
оторые владельцы счетов обнаружили пропажу денег и сообщили об этом бан-
Работники банка немедленно проверили все электронные переводы, сделан-
за последнее время, и связались с клиентами для выяснения законности про-
ления транзакций. Многие клиенты были удивлены, обнаружив изменения в со-
тоянии счета, а для многих сюрпризом явился сам факт наличия у них
электронного счета в данном банке, который банк автоматически создал за них.
Пользователи зачастую первыми замечают мошенничество, но только не в
случаях с неиспользуемыми аккаунтами. Один агент по туризму обнаружила, что она
может переводить накопленные воздушные мили для бонуса от одного клиента
другому. Она обнаружила несколько редко используемых счетов с высоким
балансом воздушных миль и частично перевела их на счет родственника, считая, что
клиент не заметит разницы. Однако она не учла того, что авиалинии отсылают
клиенту сообщения по электронной почте с просьбой подтвердить перевод.
Поступили жалобы от нескольких клиентов, и предприимчивый агент был быстро
вычислен. Данная компания нашла выход в контролировании неиспользуемых ак-
каунтов путем запроса у их владельцев подтверждения на проведение каких-либо
действий.
Он-лайновые счета потенциально опасны, особенно те из них, которые
связаны с переводом финансовых средств. Хакер, в принципе, может взломать счет.
Если пользователь не обнаруживает вмешательства, хакер неоднократно может
беспрепятственно пользоваться счетом.
Разработайте систему отслеживания состояния счета и метод сохранения
неиспользуемых счетов без их полного закрытия, как показано в примере 1.4.
1очно определите, как и когда пользователи будут получать уведомление об
изменении состояния счета или проведенных транзакциях, и обеспечьте клиентов
конкретным и понятным способом отчета о подозрительных или мошеннических
периодах денег.
Централизуйте код для изменений счета и транзакций таким образом, чтобы
вас было общее место для записи, анализа и уведомления пользователей об этих
иствиях. Разработайте процесс приостановки и удаления неиспользуемых
а*каунтов.

Глава 1 • Управление пользователями
Пример 1.4. Окончание срока действия неиспользуемых аккаунтов
„ Mail Yabgfli-My Y^hpgi-tUlfi ** Sarch
Your Yahoo! Mail account is no longer active.
Why is my account inactive?
Yahoo' Mail deactivated your matl account because either
1 You have not logged into your account in at least 4 months, or
2. You have asked that your mail account be deactivated
What does this mean?
• All emails, folders, attachments and preferences have been deleted
• All messages sent to @yahoo.com are being bounced back to the sender
• You can still use your Yahoo' ID to access other registered services on Yahoo'
• Deiet&d information cannot be recovered
Подсказка
Многие web-приложения имеют индикаторы деятельности web-пользователей.
Например, некоторые web-форумы сообщают дату последнего посещения или
показывают историю продаж и покупок пользователя.
Способы защиты
Если ваш аккаунт не будет использоваться в течение длительного времени,
поставьте его на сохранение, требующее простой процедуры деактивации,
схожей с процессом восстановления пароля.
Избегайте обнародования любой информации, указывающей на то, что
электронная ячейка не используется.
Уведомляйте пользователей с помощью электронного сообщения, письма
или любым другим способом в случаях изменения состояния счета или
после выполнения значимых операций, если пользователь не являлся
инициатором этих действий.
Используйте средства защиты от мошенничества, например мониторинг
операций с аккаунтом на выявление отклонений от нормы.
Не активируйте в автоматическом режиме доступ к он-лайновым счетам
для всех пользователей с офф-лайновым счетом.

Управление пользователями • Глава 1
Управление паролями
п гле того, как пользователь установит имя пользователя и пароль, вам необ-
предпринять несколько шагов для обеспечения защиты этого пароля.
В этом разделе вы узнаете о:
■ Хранении паролей
■ Сроках действия и историях паролей
■ Изменении пароля
Хранение паролей
Исходное положение: Пароли, хранящиеся в базах данных,
представляют собой такую же опасность для вашего
приложения, как и остальные.
Угроза: Взлом аккаунта, возможные последствия.
В феврале 2001 года RealNames, компания, заменившая сложные web-адреса
простыми ключевыми словами, сообщила, что хакеры получили доступ к базе данных,
заполучив информацию по кредитным карточкам и пароли всех их клиентов. Месяц
спустя ADDR.com, компания по размещению на сервере web-узлов клиентов,
сделала заявление о том, что хакеры похитили личную информацию и пароли 46,000
пользователей. Спустя ещё месяц после этого общественность узнала о еще
нескольких подобных историях, когда сервер взламывался, а пароли похищались.
Риск подобного взлома можно существенно сократить, применяя один очень
простой способ: не хранить пароли в базе данных.
Существует три способа хранения паролей, используемых в дальнейшем для
аутентификации пользователей:
■ Текстовый формат.
«зашифрованный формат, хранение как гипертекст.
Создание одностороннего символа пароля и хранение этого символа в
базе данных.
овершенно очевидно, что первое решение неэффективно, да и второе нена-
лучше: хотя пароль и зашифрован, кодировка основана на секретном слове.
пРеДполагается, что web-приложение выполняет шифрование и дешифрова-

Глава 1 • Управление пользователями
ние, следовательно, оно должно каким-то образом хранить и ключевое слово.
Если хакер контролирует приложение, которое может расшифровать пароль, то
он получает доступ к паролю.
Внимание
Хэш называется односторонней функцией, потому что можно получить символ
из пароля, но нельзя получить исходный пароль из хэш-символа. Тем не менее
хэши не обладают абсолютной устойчивостью к взлому и должны быть тщательно
защищены. Если хакер сможет получить символ, он сможет получить список слов,
прогнать каждое из них через один и тот же хэшируемый алгоритм и сравнивать
два символа до тех пор, пока не обнаружит совпадение. Этот метод взлома
паролей стал также популярен, как John the Ripper.
Важная причина для того, чтобы не сохранять действительные пароли, - это
то, что в этом случае никто из вашей организации не сможет получить доступ
к именам пользователей. Это действительно важно, поскольку нередко люди
используют одни и те же пароли для разных систем. Если кто-то из вашей
организации обладает правом доступа к паролям вашего приложения, это может означать,
что у них также есть доступ к пользовательским аккаунтам других web-систем.
Если пароли хранятся в базе данных, взломщик может получить доступ ко всем
аккаунтам пользователя, даже если пароли зашифрованы. Это ставит под угрозу
всех тех, кто пользуется одним и тем же паролем для разных систем. Некоторые
хакеры составляют списки комбинаций логина и соответствующего ему пароля
для использования при вмешательстве в другие системы.
Установите наиболее подходящий для вашей организации алгоритм
аутентификации и проверки целостности информации. Поскольку хэши всё ещё очень
уязвимы против подбора пароля методом лобовой атаки, лучшее решение - не
самый быстродействующий алгоритм. Использование более медленного алгоритма
означает, что и процесс подбора пароля будет проходить дольше. Система должна
быть разработана так, чтобы вам никогда не приходилось восстанавливать пароль.
Пароли должны быть только установлены или переустановлены.
Однако иногда программа должна сохранять пароль для дальнейшего
использования. Например, однажды я проверял приложение, которое должно было
проводить аутентификацию провайдера данных третьей, независимой стороны-
Поскольку этот провайдер требовал проведения опознавания, приложение
вынуждено было сохранять пароль, используя обратимое шифрование. Так как
приложение требовало восстанавливаемый пароль, компании приходилось пр#"
нимать дополнительные меры по защите ключа шифрования, что они и делали-
поместив код шифровки и расшифровки в компонент СОМ.
Недостатком использования обратимого шифрования является то, что клю4
шифрования очень редко меняется. Замена ключа шифрования очень проблем^'

Управление пользователями • Глава 1 21
поскольку в этом случае вам придется расшифровать и заново зашифровать
гипертекст базы данных, используя новый ключ.
Если вы планируете использовать обратимое шифрование, в ваши планы
ясна входить и разработка механизма, который регулярно измененяет ключ
кования и обновления всех зашифрованных данных.
Внимание
а При обратимом шифровании всегда используйте надежный алгоритм, например
DES, BlowFish. Никогда не используйте XOR (исключающее ИЛИ), R0T-13 или
п любительские коды шифрования; они не обеспечивают должного уровня защиты
, и подвержены взлому в гораздо большей степени, чем вы думаете. Грубо говоря,
слабые алгоритмы шифрования можно сравнить с крошечным замком на
большой сумке.
Используйте одностороннюю функцию и храните хэш в базе данных. После
того как пользователь войдет в систему, запустите хэш-функцию на пароль,
введенный пользователем, и сравните этот хэш с тем, который хранится в вашей базе
данных. Преимуществом хэш-функции является то, что ключ состоит только из
букв, что позволяет пользователю вводить любые символы клавиатуры в своем
пароле, и вам не придется принимать дополнительных мер по управлению
специальными символами.
Подсказка
* Если ваша система хранит пароли в формате обычного текста, процесс перехода
к хэшам пройдет относительно безболезненно. Для этого создайте новое поле
хэша сразу же за уже существующим полем пароля. Затем захэшируйте все
существующие пароли и сохраните их в новом поле. После этого добавьте хэш-функ-
цию к вашему опознавательному коду и коду установки пароля. В заключение,
вместо сохранения и проверки поля пароля, обновите ваш код на первый хэш па-
Роля, затем сохраните и проверьте, используя поле хэш.
м. главу 4 «Шифрование личных данных» для более подробной информации
использованию характеристик шифрования .NET Framework.
Способы защиты
Никогда не храните пароль в формате обычного текста или используйте
обратимое шифрование.
используйте надёжные алгоритмы - MD5, SHA-1 (алгоритм
аутентификации и проверки целостности информации), SHA256 или SHA512.

Глава 1 • Управление пользователями
Сроки действия и история пароля
Исходное положение: Устаревшие или повторно используемые пароли
предоставляют больше возможностей для взлома.
Угроза: Подбор пароля методом лобовой атаки,
похищение аккаунта.
Так же как и приложения, пароли устаревают, потому что пользователи
обычно не меняют свои пароли регулярно, используя их на протяжении нескольких
лет. Это утверждение особенно справедливо в отношении аккаунтов электронной
почты провайдеров Интернет-услуг (ISP), процедура замены паролей которых
очень сложна. Вам необходимо требовать от пользователей регулярной замены
пароля, как это делают некоторые web-сайты.
Однако установить корректный интервал времени, через который
необходимо менять пароль, нелегко. Если максимальный срок действия пароля
составляет б месяцев, возрастает риск несанкционированного раскрытия
пароля. Но если запрашивать изменение пароля каждые 30 дней, вы скоро
обнаружите, что люди начнут пользоваться шаблонами, то есть использовать
последовательные пароли или пароли, основанные на датах. Таким образом, слишком
частое изменениепаролей на деле может привести к снижению защиты
системы. Более того, если пользователь заходит на web-сайт не чаще одного раза в
несколько месяцев и обнаруживает, что ему необходимо каждый раз менять
свой пароль, он будет недоволен подобной системой.
Чтобы рассчитать оптимальный срок действия пароля, задайте себе несколько
вопросов:
■ Насколько важны защищаемые данные?
■ Как часто пользователь заходит в приложение?
■ Сколько времени займет вычисление пароля, основанного на ваших
требованиях по его усложнению?
Если ваше web-приложение - это система он-лайн-банка, оптимальным сроком
действия пароля будет период от трёх до шести месяцев. С другой стороны, если
вы занимаетесь интерактивной продажей цветов, можно разрешить
пользователям не менять пароли в течение года и более.

Управление пользователями • Глава 1 23
Додсказка__
Если вы хотите, чтобы пользователи меняли пароли, но не хотите навязывать
им сроки действия, можно через определенные интервалы времени отправлять
м СОобщения по электронной почте о том, что их пароль устарел, в качестве
приложения давая ссылку на быструю замену пароля. Ещё один способ, чтобы
заставить пользователей менять пароль, - это предоставить им право самим
устанавливать срок действия пароля.
Срок действия непосредственно связан с историей пароля, которая
представляет собой список предыдущих паролей, употребляемых данным пользователем.
История пароля предостерегает от выбора в качестве нового пароля тот, которым
он уже пользовался ранее. Система будет отвергать пароль каждый раз, когда
он будет совпадать с паролем из списка. Многие системы запоминают от трех
до пяти ранее используемых паролей, однако есть и такие, которые хранят до 20
и более. История паролей не занимает существенного объема памяти, поэтому
есть смысл ее хранить.
жмание
Если вы храните историю паролей, сохраняйте только хэши паролей, но не сами
пароли, как было объяснено ранее в разделе «Сохранение паролей».
Несмотря на установку сроков действия и историю, некоторые пользователи
всё же используют один и тот же пароль повторно. Они обходят эти меры
безопасности, переустанавливая свои пароли столько раз, сколько потребуется для
заполнения списка истории, а затем устанавливают этот же пароль как вновь
введенный. Противодействием этому может послужить установка длинного списка
истории и минимальные требования по срокам действия пароля. Минимальный срок
действия пароля - это наименьшее количество времени, которое должно пройти
До того, как пользователь сможет снова поменять пароль.
Подсказка
Минимальный срок действия пароля иногда может причинять неудобства,
однако дня или даже часа может быть достаточно для того, чтобы пользователь
не смог многократно переустанавливать пароль, пытаясь заполнить список
истории. Если вы устанавливаете минимальный срок действия пароля, убедитесь,
^° администраторы могут отменить эту меру.

Глава 1 • Управление пользователями
Пароли - это не что иное, как засекреченное слово или фраза. При
достаточном количестве времени взломщик, в конце концов, вычислит пароль методом
прямого подбора или взломает уязвимые места операционной системы или
приложения. При устаревании пароля увеличивается риск подбора этого пароля
хакером. Более того, если злоумышленник завладеет паролем и законный владелец это
не обнаружит, злонамеренный доступ будет продолжаться до тех пор, пока пароль
будет оставаться действительным. Без установки срока действия пароля
злоумышленник будет залезать на аккаунт до тех пор, пока пользователь вручную не
поменяет свой пароль.
Установка срока действия пароля и история требуют дополнительных полей
базы данных, чтобы проследить, когда пароль был установлен, и иметь
возможность хранить список недавних паролей. Также существует дополнительное
процессорное требование хэширования пароля и сравнения его с каждым входом
списка истории. Можно устанавливать различные сроки действия пароля, как для
индивидуальных пользователей, так и для групп, или выбрать единый подход для
всей системы. Преимуществом единого метода для всей системы является то, что
вы можете «угасить», сделать недействительными все пароли одновременно в
случае крайней необходимости, например, если осуществлено вторжение на сервер.
Дату истечения срока действия пароля нужно проверять сразу же после того,
как пользователь успешно пройдет аутентификацию в системе, но до того, как ему
будет разрешен вход в систему. Если вы организовали аутентификацию с
использованием одной библиотеки, вам будет легче выполнять проверку срока действия
пароля. Если срок действия пароля ещё не истек, но уже близок к этой дате, можно
предупредить пользователя о скором окончании срока действия пароля.
Посмотрите пример 1.5.
Перед тем как присваивать пользователю новый пароль, проверьте историю
пароля и минимальный срок действия пароля.
Пример 1.5. Окончание срока действия пароля
Your password is 257 days оИ and has expired
Please change your password.
Ch пае Password
Previous password I
New password. I I
Retype new pas sword- I
at rd

Управление пользователями • Глава 1
Способы защиты
■ Установите максимальный срок действия пароля, подходящий вашему
приложению и пользователям.
■ Сохраняйте список недавних паролей для предупреждения их повторного
использования.
■ Если возможно, определите минимальный временной интервал между
переустановкой паролей.
Замена паролей
Исходное положение: Сделайте процедуру замены пароля легкой
и убедите пользователей менять пароли.
Угроза: Прямой подбор пароля, похищение аккаунта.
Многие специалисты по безопасности выступают против использования
«защиты через неизвестность» (практика сохранения чего-либо в скрытом
виде) в качестве механизма обеспечения закрытости системы. Но пароли и
опознавательные сертификаты - центральное звено многих защитных систем -
и есть не что иное, как защита через неизвестность. Эффективность пароля
полностью зависит от наших ожиданий, что никто не сможет вычислить или
угадать пароль.
При достаточном количестве времени злоумышленник может раскрыть
пароль, либо взломав уязвимые места системы, либо применив метод прямого
подбора пароля. Наша единственная защита - регулярная смена пароля. Именно
поэтому неотъемлемой характеристикой любого web-приложения должна быть
возможность менять пароли.
Можно привести пример деятельности одной компании, которая пользуется
финансовой торговой программой. Это приложение запрашивало регистрацию
ользователей каждый раз при осуществлении продажи. Так как большинство бро-
Ров выполняли операцию по продажи много раз за день, они просто сворачива-
1 обозреватель Интернет на своих экранах и оставались зарегистрированными.
рокеры были недовольны тем, что им постоянно приходится проходить аутенти-
т ацию из-за лимита времени сеанса, поэтому разработчики сняли все ограниче-
времени сеанса с сервера. В конце концов, брокеры просто оставляли свои
пьютеры включенными, а большинство из них даже не выходило из приложе-
ооозревателя Интернет. Иногда случалось так, что некоторые пользователи
Неделю пользовались одним-единственным обозревателем Интернет сеанса
с*язи.

Глава 1 * Управление пользователями
Сохранение сеанса связи открытым представляет собой большой риск, но еще
большим риском было то, как приложение управляло изменением паролей. Для
установки нового пароля люди просматривают страницу предпочтений, нажимают
на ссылку замены пароля и затем вводят новый пароль. Но представьте себе
следующий сценарий: другой брокер ждет, пока «жертва» уходит на обед, и затем
устанавливает новый пароль, используя открытый сеанс и не зная предыдущего
пароля. Сеанс не прерывается на протяжении следующей недели, но другой брокер
имеет полный доступ к аккаунту с новым паролем. И пока «жертву» не принудили
заново войти в сеть, она не в курсе, что пароль изменился.
Если пользователи не меняют свои пароли регулярно, они сталкиваются с
возрастающей вероятностью того, что их пароли будут раскрыты и, следовательно,
кто-то получит доступ к их аккаунтам. Чем труднее пользователям менять пароли,
тем меньше они хотят это делать, особенно если никто не требует от них
регулярного изменения пароля. Используя такие приемы, как ввод предыдущего пароля,
окончание срока действия сеанса связи и оповещение пользователя об
изменениях, злоумышленник может пользоваться аккаунтом на протяжении довольно
длительного времени, не выдав себя.
Разработайте систему таким образом, чтобы замена пароля представляла
собой интуитивно простой процесс. Избегайте крайних мер, отбивающих желание
проводить замену пароля - установка чрезмерно жестких, сложных требований.
До и после замены пароля всегда запрашивайте аутентификацию пользователя.
После того, как пользователь войдет в систему, предоставьте ему быструю
ссылку на наиболее общие задания по управлению аккаунтами, включая и
изменение пароля. Если ваши методы безопасности не предусматривают
самостоятельную замену пользователем устаревшего пароля, отправьте ему простое
предупреждение с прикрепленной ссылкой, как показано в примере 1.6.
Пример 1.6. Предупреждение об устаревшем пароле
МВОХ - 0 Messaged), 0 New | Please seled a folder xi
Warning your password is over 6 months ©Id. cbck here to change your password now
[View All Messages 3
1 OQP From Subject Date» See
§3 Г Prince Shalek URGENT ASSISTANCE 22 Sep Ik

Управление пользователями • Глава 1
Гтоаница изменения пароля должна состоять из трех бланков для текста: один
вода предыдущего пароля, второй для ввода нового пароля и ещё один - для
рЖдения нового пароля. Пример 1.3. демонстрирует образец экрана
переустановки пароля.
Чтобы предотвратить атаки прямого подбора пароля, сделайте страницу заме-
пароля доступной только для активных сеансов связи аутентифицированных
пользователей.
Способы защиты
■ Всегда разрешайте пользователям самим менять пароли.
■ Сделайте процедуру замены паролей простой и понятной для
пользователей.
■ Напоминайте пользователям о необходимости регулярно менять пароли.
■ Требуйте старый пароль при замене его на новый.
■ Запрашивайте новый пароль дважды для подтверждения правильности
написания.
■ Уточняйте легальность изменения состояния счета через электронную
почту или другие средства связи.
■ Заканчивайте все активные сеансы связи и требуйте опознавания после
изменения пароля.

Глава 1 * Управление пользователями
Переустановка потерянных
или забытых паролей
Рано или поздно кто-то из ваших пользователей потеряет или забудет
пароль. Поскольку это представляет собой потенциальную угрозу безопасности,
вам необходимо научиться работать с проблемными паролями. В этом разделе
вы узнаете о:
■ Переустановке паролей
■ Отправке информации по электронной почте
■ Присвоении временных паролей
■ Использовании секретных вопросов
Переустановка паролей
Исходное положение: Следуйте хорошо запланированной
процедуре переустановки потерянных или забытых
паролей.
Угроза: Подбор пароля методом лобовой атаки,
похищение аккаунта.
Чтобы избежать перегрузки раздела поддержки клиентов вопросами о
переустановке потерянных или забытых паролей, многие web-сайты разрешают
пользователям самим восстанавливать или переустанавливать пароли. Однако в случае
неправильной настройки данная опция может представлять собой уязвимое место
в вашем web-приложении.
Вы всегда должны рассматривать потерю пароля как событие, угрожающее
безопасности, принимая дополнительные меры по защите аккаунта пользователя
от несанкционированного вторжения. Подавляющее большинство web-сайтов
очень легкомысленно относится к восстановлению потерянных паролей:
Пользователю достаточно ввести свое имя или адрес электронной почты (как показано
на примере 1.7. и 1.8.), и через несколько минут он получит сообщение по
электронной почте, содержащее пароль. На практике пользователи, редко
посещающие web-сайт, зачастую пользуются именно этим способом восстановления
пароля, вместо того, чтобы записать или запомнить собственный пароль.

Управление пользователями • Глава 1
имер 1-7 Восстановление пароля с использованием только
р электронной почты
r ordc to ctncvc yaur pass rd fbr ycu Jab cr.com account, p с>:зс cirtc
■ urlafcbcruscmomc EJobbc ID) irtbo thctorm clow, c3 dk an Get
Pas^wsrd1, -зпе! * ur ass word ■ il b sen* to the crnati address iho* \s
reg ste* cd an your account.
Г"
. 10 ber oom
Пример 1-8. Ещё один способ восстановление пароля с
использованием только электронной почты
v-% - . -*
Passwtnrd Finder
Please enter the e-mail address you registered with. If our account information mQ be e-euuled to you shortly
& E-xna&Arfdress {
f №шщ_
Но восстановление пароля означает, что ваше web-приложение либо сохраняет
пароли в текстовом формате, либо использует обратимое шифрование. Оба этих
способа не очень хороши, как уже было описано выше в разделе «Сохранение паролей»,
ели произошла потеря пароля, обязательно уничтожьте старый пароль и запросите
У пользователя новый пароль. Никогда не позволяйте пользователям восстанавли-
ть потерянные пароли. Подсказки пароля, помогающие пользователю вспомнить
пъвд пароль, ненамного лучше, особенно если эта подсказка и есть сам пароль.
Подсказка
Еи*в одним преимуществом установки нового пароля вместо отправки старого
является то, что это не позволяет злоумышленнику восстановить пароль пользователя без
ег° ВеД0ма. Хотя опытный хакер в состоянии собрать достаточно информации и полу-
кгь Доступ к переустановке пароля пользователя, конечно же, пользователь
насторожи11»!, когда в следующий раз попытается войти в аккаунт и обнаружит, что старый па-
Р°ль больше не работает. Атака станет явной, и легальный клиент поднимет тревогу.

Глава 1 * Управление пользователями
Сложность переустановки паролей заключается в том, чтобы обеспечить
пользователей как можно более удобной процедурой замены, не ослабив при этом
защиту паролей. Прежде чем ваше приложение поменяет пароль, вы должны быть
полностью уверены, что имеете дело именно с конкретным пользователем,
а не с кем-то, кто выдает себя за него. Так как пользователь не сможет
авторизоваться по паролю, вам необходимо предпринять несколько обходных шагов. Вот
некоторые из них:
■ Отправьте пользователю письмо на электронный адрес, указанный
в аккаунте.
■ Попросите клиента ответить на один или более вопросов.
■ Попросите пользователя предоставить один или более бит информации,
имеющей отношение к аккаунту (например, ZIP-код или дату рождения).
Для сред повышенной защиты или при работе с особенно ценной информацией
можно принять дополнительные меры по установке идентификации пользователя:
■ Позвоните забывшему пароль по номеру, указанному в аккаунте.
■ Отправьте пользователю факс по заранее выбранному номеру.
■ Отправьте клиенту письмо обычной почтой.
■ Попросите пользователя о личном присутствии и предоставлении
информации, удостоверяющей личность, в главном офисе или филиале.
Целью запрашивания у пользователя ответа на секретный вопрос или
предоставления другой информации является подтверждение, что он обладает
знаниями об аккаунте, как показано в примере 1.9. Это помогает предотвратить
анонимные атаки против пользователей, однако не защищает от атаки субъекта,
обладающего личной информацией о конкретном пользователе. Отправка сообщения по
электронной почте подтверждает, что тот, кто запросил переустановку пароля,
имеет доступ к аккаунту. Злоумышленник может заполучить доступ к личной
ячейке пользователя, но если он ещё может и ответить на секретный вопрос и
обладает доступом к электронной почте этого же пользователя, возникают очень
большие проблемы, в разрешении которых вы вряд ли сможете поучаствовать.
Тем не менее, никогда не обновляйте пароль, только лишь прислав ссылку
на переустановку пароля по электронной почте.

Управление пользователями • Глава 1 31
имер 1-9- Обновление пароля пользователя с использованием
пр личной информации
IRECT
I h.ft* 5 с
т !|
Retrieve your password hint
First Name:
Last Name:
Auto Policy Number:
Zip Code (5 di^:
Разработайте систему с четким алгоритмом смены пароля. Используйте
только безопасные маркеры сессий с коротким сроком действия. Никогда не
заносите имя пользователя, адреса электронной почты или другую идентифицирующую
информацию в URL.
Процесс переустановки пароля должен протекать следующим образом:
1. Попросите пользователя предоставить имя аккаунта и ответить на один и
более вопросов, подтверждающих его отношение к данному аккаунту, как
это показано в примере 1.10. Войдите в IP-адрес клиента,
инициировавшего запрос, и присвойте безопасный маркер сессии переустановки пароля.
Установите короткий срок действия - 24 часа и менее.
2. Отправьте электронное сообщение на адрес, присвоенный данному
аккаунту, с уведомлением о том, что был получен запрос на переустановку
пароля; включите в сообщение IP-адрес клиента, с которого был получен
запрос. Обеспечьте безопасную ссылку на ваш web-сайт, используя
временный маркер, привязанный к процессу переустановки.
• После того как пользователь нажмет на ссылку, попросите его ввести
новый пароль и по возможности новый секретный вопрос и ответ на
него. Всегда проверяйте маркер сессии на предмет истечения срока его
Действия.

Глава 1 * Управление пользователями
Подсказка
Иногда случается так, что пользователь теряет и пароль, и имя пользователя
или больше не имеет доступа к электронному адресу, с которого был установлен
аккаунт. В этом случае нужно предоставить ему возможность провести
аутентификацию вручную, отправив электронное сообщение или позвонив в
представительство обслуживания пользователей для подтверждения идентификации.
Пример 1-10- Процесс переустановки пароля
Reset Your Password (Step 1)
To reset your Microsoft© .NET Passport password, please enter trie following
information and then click Continue
Help
I <a[ hotmail.com *j
E-mail Address I
Country/Region | United States j*J
State | Alabama ]~]
ZIP Code J
Contrnie
Member Services Terms of Use P ivacy Statement
Some elements Ф 1999 ■ 2003 Microsoft® Corporation All rights reserved.
На Рис. 1.11. показан пример процесса переустановки пароля. Окно
отображает, что web-сайт требует установки нового пароля вместо возобновления
старого. Хотя приложение и запрашивает электронный адрес и некоторую личную
информацию, номер кредитной карточки не обладает достаточным уровнем
безопасности для подтверждения личности пользователя. Любой человек,
принявший он-лайн-заказ от клиента, вероятно, будет обладать всей необходимой
информацией для заполнения этой формы. На первый взгляд, может показаться,
что этот процесс более безопасен, потому что он отправляет клиенту
электронное сообщение, но не забывайте, что если пароль от электронной почты забыт
или утерян, получить отправленное сообщение пользователь не сможет. В этом
случае аутентификация должна быть достаточной для разрешения полного Д°"
ступа к аккаунту. Помимо запрашивания информации о кредитной карточке пр°"
цесс должен запрашивать дополнительную личную информацию, а также ответ
на секретный вопрос.

Управление пользователями • Глава 1
1.11- Пример процесса переустановки пароля
Before you can create your mw passport w» must verify you id«m*y Emar vour m
one foftn of ritcabon *■. th torn b«ow you donl haw thit nfonmation on hati
for ha from an Earthbr* Cuatamar Support repta ant
1 En«KY«ur£ariM.tMkEmaSAtM«a»
2. Verify Yow
ft Cn Card4jmtor| Exp*rat«> 01 /}20G-J|
^ Sacral Wwq7P*L J
.&<; j
Самым распространенным недостатком процесса переустановки пароля
является использование в web-приложениях скрытых форм полей или строк запроса для
переноса информации с одной страницы на другую. Например, перед тем как задать
пользователю секретный вопрос, нужно выяснить, кто он такой. Именно поэтому
многие процессы переустановки паролей начинаются с ввода пользователем его
электронного адреса в web-форму. На следующей странице web-приложение открывает
секретный вопрос и запрашивает ответ на него. После этого ответ подтверждается,
и принимаются меры по восстановлению или переустановке пароля. Но иногда web-
сайты передают электронный адрес или имя пользователя как скрытую форму поля,
которую хакер может модифицировать. Иногда это может привести к тому, что
пароль будет отправлен на электронный адрес по вашему выбору. Ещё одним
недостатком является то, что вы можете начать процесс с одним аккаунтом и, модифицировав
параметры лишь наполовину, перейти на другой аккаунт и закончить процесс в нем.
Проверяя процесс переустановки пароля, убедитесь, что приложение верно
определило подлинность пользователя, перед тем как отправлять электронное сообщение.
Никогда не отправляйте сообщение ни по какому адресу, кроме указанного в аккаунте.
Прострите ещё раз весь процесс переустановки пароля, проверяя каждый шаг, и убеди-
ь, что он правильно и безопасно связан с предыдущим шагом. Убедитесь, что
переключиться на другой аккаунт во время выполнения процесса переустановки невозможно.
Способы защиты
Относитесь к переустановке пароля как к мере безопасности, регистрируя
АР-адрес пользователя и принимая другие меры безопасности.
Никогда не восстанавливайте пароль; разрешайте пользователям только
Устанавливать новый пароль.

Глава 1 * Управление пользователями
■ Никогда не используйте подсказки пароля для напоминания
пользователям их действующего пароля.
■ Запросите у пользователя дополнительные сведения об аккаунте, к
которому он хочет получить доступ: ответ на секретный вопрос или
информацию, имеющую отношение к данному аккаунту; никогда не проводите
переустановку пароля, запрошенную анонимным пользователем.
■ Отправьте пользователю электронное сообщение, подтверждающее
переустановку пароля вместе со ссылкой для завершения процесса.
■ После установки пароля, если пожелаете нужным, удалите из аккаунта всю
ценную информацию, например, номера кредитных карточек.
Отправка информации по электронной почте
Исходное положение: Электронная почта небезопасна, и вам не
следует пользоваться ей для передачи значимой
информации.
Угроза: Утечка значимой информации, похищение
аккаунта, нарушение конфиденциальности пользователя.
Взгляните на это электронное сообщение, которое я недавно получил,
подписавшись на информационные услуги:
Кому: mburnett@xato.net
От: sales@example.net
Копия: orders@example.net
Тема: Подтверждение заказа
Уважаемый М.,
Спасибо, что оформили подписку. Ниже вы найдете информацию по вашему
аккаунту. Пожалуйста, сохраните это письмо.
Имя пользователя: 300Watt-Orange
С вашей кредитной карточки №1234-5679-1111-1111 по окончании 30-тИ
дневного срока будет снята сумма в размере $19.95.
Проблема этого сообщения в том, что:
■ Мое имя пользователя и пароль пересылается через Интернет в текстовое
формате.

Управление пользователями • Глава 1 35
Информация о моей кредитной карточке также не зашифрована при
передаче через Интернет.
Любой, кто имеет доступ к почтовому ящику orders@example.net, может
получить копию этого послания.
■ Мне рекомендовано сохранить это электронное сообщение,
потенциально подвергая опасности значимую информацию в случае
несанкционированного доступа к моей электронной почте.
■ Возможно, мой пароль, а может быть, и информация по кредитной
карточке хранятся в текстовом формате или с использованием обратимого
шифрования, а не одностороннего хэша.
Электронная почта, по своей сути, является незащищенной средой,: в ней не
существует гарантированной аутентификации ни для отправителя, ни для
получателя, ее трафик не зашифрован, так как она проходит несколько сетей, многие
серверы и клиенты электронной почты не шифруют хранящиеся сообщения. E-mail
также представляет собой мишень для многих видов атак использования уязвимости
клиентов» атаки сценария, опасных вложений и «социальной инженерии».
Ещё одной потенциальной опасностью электронной почты является то, что
пользователь не застрахован от смены электронного адреса или домена. Некоторые
компании автоматически пересылают электронную почту, адресованную
уволенным работникам, новым людям, занимающим их должности. Также существует и
вопрос истечения срока действия доменов, зарегистрированных новыми
владельцами, обеспечивая новым владельцам домена доступ ко всей электронной почте,
отправленной на домен (см. www.auctioiibytes.com /cab /abn /уОЗ/m05/i 15 /sO 1).
Разработайте систему таким образом, чтобы она полагалась на электронную поч-
У олько как на вторичную форму идентификации и извещения. Если возможно, вос-
ьзуитесь преимуществом 8/МШЕ(Безопасный протокол передачи электронной
ы) или PGP для увеличения надежности общения через электронную почту.
и вы хотите, чтобы пользователь получал некое подтверждение заказа или ре-
Р ции аккаунта, предоставьте ему безопасную, временную ссылку, через которую
чток Ватель сможет просмотреть эту информацию на вашем web-сайте. Вместо того
х Ысылать пользователям их имена и пароли, во время регистрации дайте им
апомнить эту информацию. Если вам нужно подтвердить заказ, оплаченный
Но Нои карточке, укажите только несколько последних цифр номера карточки,
ем случае не давайте никакой другой идентификационной информации.
буд аписании электронного письма всегда учитывайте, какие последствия
цн еть пользователь в том случае, если информация, изложенная в данном
УДет раскрыта или просмотрена другими пользователями.

Глава 1 • Управление пользователями
Подсказка
Одна возможность, которую многие web-сайты всё ещё используют, - это
технологии открытого шифровального кода, такие как PGP, для написания или шифро.
вания электронных сообщений. Было бы просто позволить пользователям
постоянно хранить открытый шифровальный код для всех сообщений электронной
почты. Вам следует предоставить открытый шифровальный код вашей организации
и подписывать всю исходящую почту. Для получения перечня свободных
инструментов PGP зайдите на www.pgpi.org
Способы защиты
■ Никогда не отправляйте значимую информацию (логины пользователя
или информацию о кредитной карточке) по электронной почте.
■ Никогда не полагайтесь только на электронное сообщение для
удостоверения идентификации пользователя.
■ Не используйте электронную почту для хранения результатов передачи
web-формы, которая содержит значимую информацию.
■ Если возможно, зашифруйте сообщение по электронной почте.
Присвоение временных паролей
Исходное положение: Пользователи никогда не станут менять
временные пароли, пока вы их не заставите.
Угроза: Похищение аккаунтов, вычисление паролей.
Однажды я зарегистрировался на книжном web-сайте, которым с тех пор
не пользовался около двух месяцев. К тому времени, когда я снова захотел зайти
на web-сайт, я забыл свой пароль, и после нескольких неудачных попыток угадать
его, пришлось нажать на ссылку «Забыл Пароль».
К моему удивлению, вместо web-формы мой клиент электронной почты
предоставил мне бланк электронного сообщения, адресованный представителю
пользовательских услуг web-сайта. Я был удивлен, что такой крупный web-сайт может
полагаться на подобную процедуру, однако я составит сообщение и отправил его.
Через несколько часов я получил ответ, в котором сообщалось, что мой пароль
был переустановлен, однако не было сказано ни слова о том, как я могу получить
доступ к своему аккаунту. Я написал ещё одно письмо, в котором просил сообщить
мой новый пароль. Почти сразу же я получил ответ со своим новым паролем, ко-

Управление пользователями • Глава 1 37
„ поКазался мне очень странным - у меня возникло подозрение, что им часто
торь11*
пользовались.
а зашел на свои аккаунт и не обнаружил инструментов для замены пароля.
концов, переустановка пароля проводилась вручную; мог ли я ожидать
предоставления каких-либо признаков замены пароля? Поскольку у меня совсем не
времени, я сдался и просто использовал присвоенный пароль. Прошло больше меся-
гтг^жле Чем я выяснил, как поменять мой пароль. Вполне возможно, что существуют
ца, прелуд
птни покупателей, которые никогда не удосужатся менять свои пароли на этом web-сайте.
Временные пароли - не самое лучшее решение. Временные пароли, созданные
юльми, очень легко вычислить. Автоматически созданные пароли также создают-
по шаблону или трудны для запоминания. Пользователи не станут менять
временные пароли, пока вы не заставите их сделать это.
Построение кода
Организуйте систему таким образом, чтобы она не зависела от временных
паролей. Если у вас нет выбора, предоставьте средства создания надежных паролей
и поставьте такие ограничения на каждый пароль, при которых пользователь
должен будет немедленно сменить его. Система, в которой пароли имеют срок
действия, предполагает большую гибкость с временными паролями.
Никогда не рассчитывайте, что случайно образованные или временные
пароли будут изменены до тех пор, пока вы не заставите их изменить. Один из методов
образования паролей для пользователей - это создание пароля с определённым
периодом действия, причем дата должна быть просроченной, что обяжет
пользователей изменить пароль после первого же его использования. Убедитесь, что
этот пароль добавлен в архив истории пароля.
Взлом кода
ели вы заметили, что приложение использует временные пароли, попытайтесь
Н° рить, следуют ли они определенному шаблону, создав несколько аккаунтов. Так-
Штаитесь посмотреть, создает ли оно временные пароли, переустановив их.
роверяя систему, определите, навязывает ли она пользователям замену пароля.
Способы защиты
збегайте установки представителями пользовательских услуг временных
паролей.
ели вам приходится использовать временные пароли, воспользуйтесь
надежным генератором случайных паролей.

Глава 1 * Управление пользователями
■ Если вам приходится использовать временные пароли, установите
короткий срок действия пароля либо пароль с уже истекшим сроком действия.
Использование секретных вопросов
Исходное положение: Секретные вопросы не заменяют пароля.
Угроза: Утечка значимой информации, похищение акка-
унтов, конфиденциальность пользователя.
Для оказания помощи в идентификации пользователя в случае утери пароля,
многие web-приложения используют секретные вопросы. Отвечая на заранее выбранный
вопрос, пользователь тем самым как бы доказывает, что он является владельцем
данного аккаунта. Классический пример вопроса - «Девичья фамилия матери».
Ответы на секретные вопросы требуют некоторых знаний в отношении
аккаунта, однако они имеют несколько значительных недостатков:
■ Злоумышленник может выяснить необходимую информацию, проведя
расследование.
■ Ответ на вопрос обычно представляет собой факт, который не меняется с
течением времени.
■ Пользователи используют одни и те же секретные вопросы,
следовательно, и ответы на них, на разных, и, возможно, многочисленных web-сайтах.
■ Люди, близкие пользователю, могут знать ответы на большинство таких
вопросов.
■ Клиенты редко меняют свой секретный вопрос.
■ Ответы часто не зависят от регистра и состоят из ограниченного набора
символов.
■ На некоторые вопросы существует ограниченное количество ответов.
■ Многие люди ответили бы совершенно одинаково на многие из секретны*
вопросов.
Секретные вопросы обычно рассчитаны на то, что ответ на них знает только вЛЗ"
делец аккаунта и что он никогда не забудет ответ. Многие администраторы web-сай"
тов предполагают, что ответ на секретный вопрос достаточен для идентификации-

Управление пользователями • Глава 1 39
кивался с бесчисленным количеством web-сайтов, которые предоставля-
ные подсказки, как избежать легко угадываемых паролей, а затем в
качели серьезн
петного вопроса просили, например, назвать кличку домашнего питомца.
С тт если злоумышленник ничего не знает о пользователе, сущность секрет-
сов ОГраничивает количество возможных ответов. Прочитайте вопро-
зможные ответы на них, приведенные в таблице 1.1. Как становится
понятой таблицы, многие вопросы предполагают настолько ограниченное коли-
ответов, что вполне можно использовать способ прямого подбора ответа
вопросы. На протяжении нескольких лет специалисты предупреждают, что
СТОит использовать в качестве паролей клички домашних животных, фамилии
или даты, но в выборе секретных вопросов люди чаще поступают с точностью до
наоборот.
Таблица 1-1- Секретные вопросы и спектр возможных ответов на них
Вопрос
Спектр ответов
В каком городе вы родились?
Кличка вашего домашнего животного? 20 наиболее распространенных кличек
собак: Макс, Бади, Молли, Маги, Люси,
Джей, Роки, Сэди, Лаки, Дэйзи, Джек,
Сэм, Шэдоу, Биар, Бастер, Леди, Джинд-
жер, Эбби и Тоби.
10 самых крупных городов США: Нью-
Йорк, Лос-Анджелес, Чикаго, Хьюстон,
Филадельфия, Феникс, Сан-Диего,
Даллас, Сан-Антонио и Детройт; каждый
третий гражданин США живет в одном из
250 городов; 10 наиболее
распространенных названий городов США: Фэйер-
вью, Мидуэй, Оак Гроу, Франклин,
Риверсайд, Центервиль, Маунт Плезант,
Джорджтаун, Салем и Гринвуд.
1 высшую школу вы посещали? В Соединенных Штатах приблизительно
от 25.000 до 30.000 высших школ;
перечень высших школ конкретного штата и
города есть на web-сайт Classmates.com
Для получения списка самых
популярных 250 фильмов
см. www.imdb.com/top 250 films.
Какую i
Ваш
любимый фильм?

Глава 1 * Управление пользователями
Таблица 1-1- Секретные вопросы и спектр возможных ответов на них
Вопрос
Спектр ответов
Девичья фамилия вашей матери?
На какой улице вы выросли?
Производитель вашей первой машины.
Назовите дату годовщины свадьбы?
Ваш любимый цвет.
Существует приблизительно 25,000
наиболее распространенных фамилий.
Каждый 10-й житель США носит фамилию
Смит, Джонсон, Уильяме, Джонс, Браун,
Дэвис, Миллер, Уилсон, Мур, Тэйлор,
Андерсон, Томас, Джексон, Уайт, Гаррис,
Мартин, Томпсон, Гарсиа, Мартинез,
Робинсон, Кларк, Родригез, Льюис, Ли,
Уолкер, Холл, Ален или Янг.
15 наиболее распространенных
названий улиц: Первая, Вторая, Третья,
Четвертая, Пятая, Шестая, Седьмая,
Восьмая, Элм Парковая, Главная, Оак, Пайн,
Мапл, Кедр.
Наиболее известные производители
автомобилей: Акура, Ауди, БМВ, Бьюик,
Кадиллак, Шевроле, Крайслер, Дэу, Форд,
Хонда, Хаммер, Хенде, Инфинити, Исузу,
Линкольн, Ягуар, Джип, Киа, ЛендРовер,
Лексус, Мазда, Мерседес Бенц, Мерку-
ри, Мицубиси, Ниссан, Олдсмобиль,
Понтиак, Судзуки, Тойота, Фольцваген,
Вольво.
Средняя продолжительность брака
составляет 7,2 года, что дает вам 2,628
возможных дат.
Существует около 100 наиболее
распространенных цветов.
Ключ к правильному использованию секретных вопросов заключается
в понимании того, что они никогда не должны совпадать с паролем. Они
используются только для переустановки пароля и предотвращения
несанкционированного доступа к процессу переустановки пароля злоумышленником-
Ответа на секретный вопрос никогда не будет достаточно для определения
пользователя, но в сочетании с другими факторами (электронный адрес
пользователя, секретный вопрос) может существенно помочь в идентификации
пользователя.

Управление пользователями • Глава 1 41
^ большой опасностью секретных вопросов является то, что ответы
Фиксированы и, проведя небольшое исследование, злоумышленник мо-
°ОЫ яснить. Так как обычно на вопросы существует ограниченное количест-
■жет их выя
« пни также уязвимы и для атак методом прямого подбора. Секретные
во ответов, / г с
ппычно неэффективны против атак людей, близких пользователю. Ъыв-
в0иросы oud т т
непослушные дети подросткового возраста могут обладать исчерпыва-
щие жены,
" информацией и достаточной мотивацией для взлома счета пользователя.
Построение кода
Ключ к успешному и безопасному использованию секретных вопросов
заключается в ясном и точном определении их роли как части процесса восстановления пароля.
Они предотвращают переустановку пароля, если вы не обладаете знаниями личной
информации пользователя. Разработайте гибкую систему секретных вопросов и ответов
на них, которая будет позволять пользователям блокировать секретные вопросы или
требовать телефонный звонок для окончательного подтверждения. Ещё один
эффективный метод для защиты значимых web-приложений - позволить пользователям или
даже потребовать от них отвечать на более чем один секретный вопрос. Учитывайте
воздействие, которое окажет на базу данных наличие нескольких секретных вопросов.
Не позволяйте пользователям самим придумывать секретные вопросы,
поскольку многие пользователи не смогут сделать выбор, который обеспечит закрытость
информации, хранящейся на аккаунте. Если администратор разрешает пользователям
самим придумывать секретные вопросы, появляются ненадежные вопросы вроде:
■ В каком году вы родились?
■ Какой у вас пароль?
Выберите сложные вопросы, тщательно продумав спектр возможных ответов,
равно и вероятность общих ответов. Используйте уникальные вопросы и постарай-
ь избегать тем, предполагающих короткие, односложные ответы. Также постарай-
изоегать широко распространенных вопросов, таких как девичья фамилия матери,
ка собаки или название высшей школы. Но принимайте во внимание, что нужно
,тиать такие вопросы, на которые пользователь всегда буцет отвечать одинаково,
ставьте длинный перечень вопросов, но для выбора предоставьте пользова-
короткий список. Для пользователей, в большей степени заботящихся о бе-
ости, можно предоставить расширенный список из вопросов.
^^ пользователь дает определенное количество неправильных ответов на секретный
»возможно, вам не стоит давать ему еще попытки на угадывание, а вместо этого от-
электронное письмо с объяснением, что дан неправильный ответ. Это
предотврати*1» направленные на выяснение секретного вопроса методом прямого подбора.

Глава 1 * Управление пользователями
Ниже приведено несколько примеров хороших секретных вопросов:
■ Имя или фамилия вашей первой (-го) девушки (молодого человека)
■ Какой номер телефона вам больше всего запомнился из детства?
■ Где вы больше всего любили бывать в детстве?
■ Ваш любимый актер, музыкант или художник.
Способы защиты
■ Сами по себе секретные вопросы не защищены и поэтому никогда не
должны использоваться как эквивалент пароля.
■ Позвольте пользователям менять секретные вопросы и ответы на них
в случаях необходимости.
■ Раскрывайте атаки против секретных вопросов, проводимые методом
прямого подбора.
Предоставление прав пользователям
Система защиты никогда не будет совершенной без участия пользователя.
Пользователи способны заметить пробелы в защите, которые администраторы
и разработчики могут упустить из вида. Но для участия в обеспечении
безопасности непрофессионалам необходимо обладать знаниями и инструментами. То, как
они будут обеспечены этим, зависит от вас. В этом разделе вы узнаете о:
■ Образовании пользователей
■ Вовлечении пользователей
Обучение пользователей
Исходное положение: Пользователи должны знать, как защищать сво
аккаунты.
Угроза: Похищение аккаунта, «социальная инженерия*'
похищение личной информации.
С возрастанием зависимости финансовых и деловых транзакций от Интер**е
та возрастает и угроза интерактивных преступлений. Похищение личной инф°Р
мации, мошенничество, а также жульничество в Интернете заставляют админ**с

Управление пользователями * Глава 1 43
остоянно совершенствовать системы безопасности web-сайтов. Пользо-
ратор ^ дОЛжны брать ответственность за защиту на себя.
0ате' ря на серьёзное продвижение в области разработки технологий и мето-
иты пользователи попадают в те же ловушки, что и на заре эры Интерне-
дОВ пИМер, люди часто идут по ссылке на HTML-страницу или электронную
та. Напри р»
иплят всю информацию по своему аккаунту в появившееся окно, а многие
почту и ввил т
товы сообщить свои пароль любому, кто объявит себя администратором.
Многие пользователи интерактивных финансовых институтов и других web-сайтов
жертвами мошеннических электронных сообщений, направленных на похищение
Аоомации по аккаунтам. Эта атака известна под названием phishing. Пользователи
получают сообщение по электронной почте, как показано на рис. 1.12., о том, что в аккаунте
возникла проблема, поэтому администратор якобы просит ввести идентификационную
информацию в предложенную форму. Личная информация попадает на сервер,
контролируемый мошенником, а затем направляет информацию на реальный web-сайт.
Пользователь не подозревает о похищении своей информации, пока не становится слишком
поздно. К счастью, эти электронные послания известны своими грамматическими и
синтаксическими ошибками, такими как слово unnormally в приведенном примере 1.12.
Рис. 1-12. Пример мошеннического электронного сообщения.
SmwJi jj НЫр | Саши
rfer to update vour ** сигтЫктап
neec! complete
Venfyyom identity
'<« pmoral HfocuafeHi vrH b*'
«r 90? W>THHWW«
AS (be <tea в preceded bj 6* «SuAy «tandirci ffl£ евоДОоп. A
at* you **#*«*• tee г
Ещё
пи ОДИн способ мошенничества - это отправка пользователю электронного
' ВЬ1Глядящего как обычный текст, но на самом деле основанного на HTML.
Дает ДЯ П° Ссылкам на один (реальный) URL, пользователь, на самом деле,
попаду ДРУГОЙ с подложной формой регистрации, которая по внешнему виду абсо-
°бОа Дентична оригинальной. Ещё один вариант - это зашифровать URL таким
Те й ' Чтобы пользователь был уверен, что он находится на нужном ему web-сай-
РеМя как он попадает на совершенно другой web-сайт.

Глава 1 * Управление пользователями
Если человек не осведомлен о методах работы мошенников и воров, он постп
янно будет становиться жертвой подобных методов «социальной инженерии
Пользователи, не беспокоящиеся о безопасности аккаунтов, ставят под уда
не только самих себя, но и окружающих.
Способы защиты
■ С помощью различных средств объясните пользователям типы угроз
безопасности при работе с web-приложениями.
■ Если возможно, предоставьте людям форум для обсуждения тем
безопасности.
■ Никогда не давайте ссылок или форм в электронных сообщениях,
отправленных пользователям; просто попросите их зайти на свои аккаунты.
Вовлечение пользователей
Исходное положение: Вовлечение пользователей в обеспечение
безопасности повысит бдительность и поможет
ограничить количество атак.
Угроза: Похищение аккаунта, «социальная инженерия».
Однажды я разговорился с другом о мошеннических электронных посланиях,
отправленных клиентам крупного банка с просьбой зайти на их аккаунты через
прилагаемую к письму форму. Я упомянул, что подавляющее большинство клиентов
последовало этому указанию, даже несмотря замеченные ими многочисленные
грамматические ошибки в письме. На что мой друг ответил, что тоже получил подобное
сообщение, однако гордится тем, что сразу же догадался о мошенничестве и уничтожил это
сообщение. Но сколько пользователей он мог уберечь от этой ошибки, если бы
поставил компанию в известность, вместо того чтобы просто удалить это сообщение?
На самом деле, многие пользователи распознают мошенничество или другие
подозрительные вещи и никогда никого не предупреждают. Мой друг не оповес
тил окружающих, так как, во-первых, решил, что, возможно, кто-то еще замети
это и сообщит, а во-вторых, он просто не знал, как именно писать подобные пре
дупреждающие письма.
Если правильно и доступно предоставить пользователям необходимые свеД
ния, они смогут играть очень важную роль в обеспечении безопасности. НаибоД
продвинутым в области защиты и технически подкованным пользователям мояс
предоставить более широкие возможности и инструменты для обеспечения без
пасности. Например, они могут захотеть установить опцию, обеспечивают.)10 ^
ступ к их аккаунтам только с определенного круга IP-адресов, или получить рРс-
к расширенным возможностям обеспечения безопасности своих аккаунтов.

Управление пользователями • Глава 1 45
пользователь не знает, как распознавать нарушения безопасности и рас-
них, последствия атак будут гораздо существеннее. Ваша система должны
СКа чоаботана таким образом, чтобы все действия аккаунта можно было легко
и проверить. Создайте бросающиеся в глаза ссылки для обнаружения и до-
* нарушениях безопасности. Внедрите модульную разработку, позволяющую
ователям устанавливать их собственные опции защиты.
Способы защиты
■ Обеспечьте пользователям доступ к истории транзакций и событий,
связанных с их аккаунтами.
■ Расскажите непрофессионалам о легких способах нарушения
безопасности, а также об опасности всех подозрительных обстоятельств.
■ По возможности создайте форум для обсуждения проблем нарушений
безопасности.
■ Разрешите всем желающим установить дополнительные опции защиты.
■ Объясните пользователям, как удалять аккаунты, которые им больше не
нужны.

Глава 1 * Управление пользователями
Краткая справка по стандартам
кодирования
Установка логинов пользователей
Навязывание надежных паролей
• Заходите в поле формы пароля только один раз для его подтверждения
и присвоения переменной. После этого используйте только
подтвержденную переменную.
• Для проверки требований к усложнению пароля используйте стандартную
функцию.
Уход от легко угадываемых логинов
• Все временные пароли должны иметь короткий срок действия или быть отме
чены как уже просроченные, что вынудит пользователей поменять пароль.
Предотвращение сбора логинов
• Никогда не вводите имя пользователя в строку запроса URL.
• Избегайте директорий пользователя или других методов, которые можно
использовать для имен пользователей.
• Не устанавливайте имена пользователей и ID аккаунтов автоматически.
Управление паролями
Хранение паролей
• Используйте правильно установленные хэшируемые алгоритмы,
например, перечисленные в классе System.Security.Cryptography.
• Сведите все коды шифрования в централизованную систему, чтобы мояс
было легко менять алгоритмы и/или ключи.
Срок действия и история паролей
• Всегда проверяйте срок действия пароля сразу же после аутентификай **
пользователя.

Управление пользователями • Глава 1
Изменение паролей
енение пароля должно проводиться на отдельной странице и вклю-
в себя как старый, так и новый пароль.
Немедленно завершите все сессии пользователя после изменения пароля,
бующего ПОВТорной аутентификации пользователя.
Переустановка потерянных или забытых паролей
Переустановка паролей
• Воспринимайте потерю пароля как угрозу безопасности, принимая все
необходимые меры. Выясните все подробности события, включая IP-адрес клиента.
• Управляйте состоянием сессии во время процесса переустановки
осторожно; не отслеживайте идентификаторы аккаунта сессии на скрытых полях
формы или строк запросов.
Отправка информации по электронной почте
• Никогда не отправляйте значимую информацию по электронной почте.
• По возможности используйте PGP или S/MIME для цифрового написания
и/или шифрования электронных сообщений.
Присвоение временных паролей
• При
создании временных паролей используйте надежный алгоритм
случайного выбора с хорошей энтропией.
Пользование секретных вопросов
ираите вопросы с достаточным количеством возможных вариантов
ета для предотвращения вычисления или лобовых атак.
аите вопросов, на которые многие люди дали бы одинаковый ответ

Глава 1 * Управление пользователями
Предоставление прав пользователям
Обучение пользователей
• Избегайте длинных или чрезвычайно сложных URL, особенно во
входящих пунктах приложений, таких как окно регистрации.
Краткая справка по проверке кода
Установка логинов пользователя
Обеспечение безопасного входа
• Обеспечивает ли приложение надежные пароли?
• Требует ли приложение имя пользователя и пароль?
Проблема использования легко угадываемых логинов
• Избегает ли приложение использования последовательных номеров
аккаунтов пользователей?
• Составлены ли логины по определенному шаблону?
• Обслуживающий персонал сам выбирает пароли пользователям, вместо
того, чтобы предоставить им самим делать этот выбор?
• Система создает пароли по умолчанию?
Предотвращение сбора логинов
• Соответствуют ли номера аккаунтов и имена пользователей
установленному шаблону?
• Передаются ли опознаваемые номера аккаунтов или имена паролей
на URL как строка запроса?
• Появляются ли номера паролей или имена пользователей
на HTML-страницах?
Ограничение на неиспользуемые аккаунты
• Много ли в системе неиспользуемых аккаунтов? :
• Возможно ли определить, функционирует ли ячейка другого пользовать

Управление пользователями • Глава 1
49
чают ли пользователи уведомление по электронной почте после
сушенного изменения состояния аккаунта?
управление паролями
Хранение паролей
# Сохраняются хэши паролей или сами пароли?
Хэши паролей сохраняются с использованием корректных алгоритмов?
# Может ли ключ шифрования быть легко изменен?
# Используют ли хэши паролей метод случайного выбора?
Срок действия и история паролей
• Рассчитано ли приложение на установку времени срока действия пароля
и истекает ли их срок действия через какой-то период?
• Отслеживает ли программа историю паролей для предотвращения
повторного выбора пользователями паролей?
Изменение паролей
■ Удобна ли процедура замены пароля для пользователей?
■ Напоминаете ли вы клиентам о необходимости регулярно менять пароли?
■ Требует ли процесс замены пароля введения старого пароля?
■ Подтверждает ли система изменение пароля электронным сообщением?
■ Завершает ли система все активные сессии после изменения пароля?
Переустановка потерянных или забытых паролей
:тановка паролей
Переуа
Дощ-скает ли система восстановление утерянного пароля?
- -a*i приложение ответа на секретные вопросы при переустановке
пароля?
равляет ли программа электронное сообщение, подтверждающее смену
Равка сообщений по электронной почте
ет ли система отправки значимой информации по электронной почте?

50 Глава 1 • Управление пользователями
Присвоение временных паролей
• Использует ли система надежный алгоритм случайного выбора, если
преходится иметь дело с временными паролями?
• Если используются временные пароли, установлен ли у них ограниченный
срок действия?
Использование секретных вопросов
• Воспринимаются ли секретные вопросы как эквивалент пароля?
• Достаточное ли количество возможных ответов существует
на секретный вопрос?
• Избегает ли система секретных вопросов с общими ответами?
• Предотвращает ли приложение самостоятельную установку
пользователями секретных вопросов?
Предоставление прав пользователям
Обучение пользователей
• Доступна ли пользователям страничка помощи по вопросам безопасности?
• Предлагает ли web-сайт какие-либо другие методы образования клиентов?
Вовлечение пользователей
• Могут ли клиенты просматривать историю транзакций и событий своих
аккаунтов?
• Могут ли пользователи просматривать историю регистрации входа
в аккаунт, включая даты, время и IP-адреса?
• Есть ли у людей легкий и интуитивный способ сообщения о проблемах
защиты?
• Могут ли продвинутые пользователи устанавливать свои опции защиты.
• Могут ли клиенты удалять неиспользуемые аккаунты?

Управление пользователями • Глава 1
FAQ
второе данной книги на следующие вопросы рассчитаны как на ваше по-
^ве концепций, представленных в этой главе, так и на помощь в претворении
НИ концепций в реальную жизнь. Для того чтобы получить ответы на ваши соб-
ДЭ ^* нопоосы по этой главе, зайдите на www.syngress.com/solutions
ственные к
жмите на форму «Спросить у Автора». Вы также получите доступ к тысячам
других FAQ на lIFAQnetrom.
Вопросы (В) и ответы (О)
В" Какие алгоритмы аутентификации и проверки информации комплектуются
с .NET-Framework?
О". MD5,SHA1,SHA256,SHA384hSHA512.
В: Должен ли я автоматически создавать пароли с совершенно случайными
символами, чтобы убедиться, что пароли защищены?
О: Многие люди уверены, что создание совершенно случайных паролей лучше
всего защитит пользователей. Но не забывайте, что людям очень сложно
запоминать случайнш* пароли типа jD4nWpa8v, поэтому они предпочитают
их записывать. Возможно, лучшим решением было бы создание
запоминающихся паролей, соСТЖл^Нных из многочисленных случайных слов и знаков
препинания. Пользователям бр&ат легче запоминать их, и вам не придется
даже придумывать ошшком длинней! пароли.
»■ Какой должна быть максимальная длина пароля?
**■ Если вы используете хэшируемый алгоритм, кэш сам по себе имеет фиксированную
Длину, независимо от размера пароля. Другимщсловами, пароль, состоящий из семи
символов, производит хэш той же длины, что и пароль из 200 символов. Если вы
используете такой алгоритм, нет никакой необходимости в увеличении длины пароля.
Моя страничка web-форума отображает имена пользователей целиком. Как
я могу защититься от хакеров?
Некоторые web-приложения основаны на взаимодействии пользователя и не
Могут в полной мере предотвратить сбор имен пользователей. Противодейст-
вием этой потенциальной угрозы может послужить разрешение
пользователям менять свои имена и устанавливать вымышленные имена на аккаунты.
В:
** работаю с web-приложением, которое содержит очень важную финансовую
информацию. Должен ли я заставлять пользователей менять свой пароль
каждые 30 дней для достижения максимальной защищенности паролей?

Глава 1 • Управление пользователями
О: Этот метод обеспечения безопасности наиболее надежен, но он не очень ул
бен для пользователей. Можно заставить их записывать свои пароли или ел
довать шаблонам в выборе пароля. Лучшим решением является присвоен*
пользователям более надежных паролей и разрешение менять их реже.
Bl Зачем после переустановки пароля отправлять в электронном сообщении
ссылку, а не сам пароль? Если хакеру удастся получить доступ к электронной
почте пользователя, разве он не может получить и доступ к ссылке,
хранящейся в этом электронном сообщении? Почему бы просто не отправить
пользователю временный пароль по электронной почте?
О: Ссылка, находящаяся в электронном сообщении, так же доступна, как и сам
пароль, однако существуют и другие причины, по которым не следует
пересылать пароль. Во-первых, когда пользователь нажимает на ссылку,
устанавливается безопасный коммуникационный канал. Во-вторых, это позволяет web-
серверу записать IP-адрес клиента и время посещения. В-третьих, это не дает
пользователю сохранить электронного сообщения, содержащего пароль.
И, наконец, если пользователь больше не является владельцем аккаунта
данной электронной почты или если маршрут указан неверно, это
предотвращает использование пароля другими людьми.
Bl Надежны ли временные пароли?
О'. Временные пароли надежны, пока вы оставляете их временными. Лучший
способ сделать их таковыми - это установить у них просроченную дату срока
действия, так что пользователь будет вынужден изменить его после первого
же посещения аккаунта.
Bl Какой способ привлечения внимания пользователей к вопросам
безопасности считается лучшим?
О Г Наиболее удобный путь - это позволить людям обсуждать эту тему на
публичном форуме. Однако необходимо следить за подобными форумами, посколь
ку они иногда используются как один из методов «социальной инженерии
для выяснения паролей. Однажды мошенник отправил на форум интеракти
ной оплаты мобильников номера телефонов, позвонив по которым, польз
ватели могли сообщить о нарушениях безопасности. Когда кто-нибудь звон
по этим «телефонам доверия», мошенник на другом конце провода пр°с
сначала «аутентифицировать» себя, раскрыв свой пароль.
Bl Где я могу получить перечни слов для проверки паролей пользователей.
О: Зайдите на www.gattingcr.org/wordlists/download.html
или http://neworder.box.sk/codcboxJinks.php?key=passdict.

Глава 2
■ iflnf*:.,^,
,-£--:* е
p^u- "' ~i
•hi
Решения в этой главе:
U Аутентификация пользователей
□ Авторизация пользователей
.->ф: '"■'■■'
У к
Si^-it^i^^'*' Ш
-./•£
% Краткая справка по стандартам
кодирования
• Краткая справка по проверке кода
• FAQ
53

Глава 2 * Проверка подлинности пользователей
ш
Введение
Настоящая проверка безопасности web-приложения начинается тогда, когл
приходит время регистрации пользователя и получения доступа на ваш web-сайт
На первый взгляд процесс кажется очень простым: пользователю предоставляет
ся окно регистрации и обеспечивается доступ при вводе правильного логина и па
роля. Однако безопасность может быть нарушена многими способами. В этой
главе мы рассмотрим подобные нарушения и методы их предотвращения.
При опознавании устанавливается идентичность пользователя. Затем
пользователь авторизуется (или не авторизуется) на получение доступа к web-приложе-
нию. По сравнению с классическим ASP, ASP.NET обладает рядом преимуществ
так как предоставляет намного более надежный механизм опознавания и
инструменты для внедрения продвинутых сценариев опознавания и авторизации.
Несмотря на новые возможности опознавания и авторизации ASP.NET,
программисты все ещё склонны допускать те же ошибки, которые они делали
с прошлой версией ASP. В этой главе мы остановимся на рассмотрении именно
той части web-приложения, которая касается опознавания и авторизации.
Понимание опасностей
Основные виды угроз при опознавании пользователей:
■ Перехват аккаунта. Данный способ представляет собой перехват акаунта
законного пользователя, иногда с блокированием доступа этого
пользователя к его аккаунту.
■ «Человек-в-середине». Перехватывание web-трафика таким образом, что
злоумышленник в состоянии читать и изменять данные при передаче
между двумя системами.
■ Phishing. Разновидность атаки «Человек-в-середине», при которой
злоумышленник провоцирует законного пользователя на ввод пароля в
подложное электронное сообщение или web-форму, разработанную так, что
внешне она неотличима от реального web-сайта.
■ Неавторизованный доступ. Получение доступа к закрытым данным
без согласия её владельца.
■ Утечка информации. Недостаточная защита информации, которую зло
умышленник может использовать в целях компрометации системы.

Проверка подлинности пользователей • Глава 2
тирение привилегий. Получение злоумышленником доступа к конфи-
иальной информации аккаунтов высокого уровня.
сивное прослушивание сети. Использование утилитов контролирова-
сети для перехвата паролей или другой значимой информации,
передающейся по сети.
Опознавание пользователей
Окно web-регистрации - это фильтрующий момент приложения, заставляю-
w пользователя подтвердить действительность логина и пароля. Очень важно
шательно проработать это окно экрана, чтобы быть уверенным в правильности
идентификации пользователя. В данном разделе мы рассмотрим:
■ Формы регистрации
■ Формы опознавания
■ Применение Windows
■ Паспортное опознавание
■ Блокирование лобовых атак
Построение форм регистрации
Исходное положение: Форма регистрации должна защищать
сертификаты пользователя и противостоять атаке
гроза: Похищение аккаунта, утечка информации, SQL-
запросы, CSS-атаки.
колько лет назад, на одной из конференций по безопасности, я обратил
спи Ие На но^тбУк ещё одного участника конференции. На экране был выведен
с по еН пользователеи и паролей, который медленно прокручивался вниз
Сет ю °ткрь1той команды подсказки окна. Я сразу понял, что он прослушивал
KOHfh гЯ ЛОгины пользователей. Чего-то подобного стоило ожидать на такой
об эт ЦИИ ЧТО Удивило меня больше всего, это то, что когда я сказал ему
^Hafu' Пояснил, что это всего лишь пароли электронной почты, находящей-
Иьщ с атнЬ1х серверах, а именно Hotmail и Yahoo! За 10 минут он собрал длин-
*lePea K СеРТиФикатов людей, вошедших в свои аккаунты электронной почты
^защищенное соединение.

Глава 2 * Проверка подлинности пользователей
В самом деле, собрать эти сертификаты не представляет никакого трул
Оба сервиса (Hotmail и Yahoo!) предоставляют версии SSL-экранов регистрацИи
но фактически ими пользуются немногие. К счастью, с тех пор Hotmail стал пп
водить паспортное опознавание, a Yahoo! создает MD5-hash вашего пароля, пере
тем как отправить его по сети. Но многие web-сайты всё ещё остаются беззащцт
ными перед обеспечением безопасности вашего сертификата при регистрации
Поскольку форма логина играет очень важную роль при опознавании
пользователя, важно также защитить саму форму. Плохо составленная форма для входа
уязвима для пассивного прослушивания сети, утечки информации и phishing.
Более того, сама форма может быть уязвима против дефектов, таких как
запросы SQL и CSS-атаки.
После того как вы разработаете и построите форму для ввода логина,
избегайте использования единичных форм для множественных задач. Всегда передавайте
сертификаты по безопасным соединениям, используя SSL.
Подсказка
Постарайтесь установить безопасное соединение для формы регистрации
изначально, а не после того, как пользователь нажмет кнопку «Войти для получения
логина». Вам нужно убедить пользователей, что форма регистрации не просто
безопасна, а достоверна. Подробнее см. Главу 4 «Шифрование личных данных».
Поскольку URL регистрируются сервером-посредником и напечатанной
историей URL, лучше использовать метод HTTP POST с web-формой, чем метод
HTTP GET. (подробнее см. Главу б «Разработка безопасных приложений
ASP.NET»). Очень важно всегда подтверждать ввод формы для предотвращения
SQL-запросов и CSS-атак. (подробнее см. Главу 5 «Фильтрация входных данных
пользователя»).
Работая с неудачной регистрацией, будьте осторожны при отправке
сообщений об ошибке. Например, неопытные программисты иногда присылают
разные сообщения об ошибке с точным указанием того, где произошла оши
ка - при вводе логина или пароля. Сообщения об ошибке должны быть обш
ми, чтобы на их основе нельзя было собрать информацию, удостоверяюшу
личность пользователя. На рис. 2.1. приведен пример того, как должно выг
деть сообщение об ошибке. Если же в сообщении будет указано, где имен
произошла ошибка - в логине или пароле, - хакер будет вводить имя пользо
теля из списка до тех пор, пока сообщение об ошибке в логине не смени
на сообщение о неверном пароле. Имея верный логин, злоумышленник мо
вычислить и пароль.

Проверка подлинности пользователей • Глава 2
рис
1 Общее сообщение об ошибке регистрации
Username Password
Submit
F^fgotyoMfp ЙЕ
Первое, на что нужно обратить внимание при проверке регистрации, - это
источник кода для формы. В частности, обратите внимание на наличие в форме
скоытых тегов, которые могут быть изменены или могут раскрыть значимую
информацию. Затем введите неверную информацию в поле формы для того, чтобы
определить, что именно видят злоумышленники, получая сообщение об ошибке.
И, наконец, попробуйте воспользоваться методами запросов SQL и CSS-атаками,
описанными в Главе 5 «Фильтрация входных данных пользователя».
Разрабатывая форму регистрации, не используйте скрытые поля формы
для передачи значимой информации. Хакеру, возможно, удастся изменить эти
скрытые поля для получения неавторизованного доступа и просматривать
их для сбора информации, использующейся для атаки. Ниже приведен пример
скрытой формы поля, которая может быть уязвима для атаки:
<form method="POST">
<input type="text" name="txtUsername"></p>
<P><input type="text" name="txtPassword"x/p>
<mput type="hidden" name="AdminArea" value="False">
<P><input type="submit" value="Submit" name="Bl"x/p>
</form>
Способы защиты
сегда передавайте параметры регистрации только через SSL-соединения.
Используйте метод HTTP POST для отправки формы данных.
■
Сегда подтверждайте ввод формы.
°лагайтесь на скрытые поля формы для передачи данных, так как они
У1, оыть изменены клиентом, и значимая информация станет открытой
ДЛя 3лоУмышленника.

Глава 2 • Проверка подлинности пользователей
■ Никогда не раскрывайте излишнюю информацию в сообщениях об ошибк
Использование форм опознавания
Исходное положение: Установка незащищенных форм опознавай»
может ослабить безопасность web-приложения
Угроза: Похищение аккаунта, утечка информации.
Тысячи плохо написанных ASP-схем опознавания регистрации web-сайта
установлены по всему миру. Программисты допускают одни и те же ошибки в
обеспечении безопасности, особенно если у них нет достаточного опыта в
использовании кодирования для защиты. ASP.NET представляет новую концепцию, которая
называется опознавание форм. Несмотря на то, что она ещё далека от
совершенства, эта система, по крайней мере, предоставляет надежную инфраструктуру,
на базе которой программисты могут строить безопасные механизмы регистрации.
Опознавание форм - концепция, которую несложно понять и установить, при
этом она обеспечивает устойчивую защиту. Создается страница регистрации, и
изменяются некоторые установки в файле web.config. Однако такая легкость в
использовании может привести к плохому осуществлению защиты на практике.
Самая большая проблема в том, что остается возможность добавлять имена
пользователей и пароли прямо в файле web.config и даже использовать простые,
незашифрованные пароли, как показано на рис. 2.2. Можно хранить MD5 или SHA-
1 хэши в файле web.config, как показано на рис. 2.3., но ASP.NET не предлагает
никаких легких способов создания хэшей для паролей. В результате многие
разработчики выбирают пароли в формате обычного текста просто потому, что так проще-
Программисты могут оставить зашифровку на потом, однако это никогда не станет
для них первостепенной задачей. Если вы установили пароли в файле web.config'
зайдите туда прямо сейчас и используйте MD5 или SHA-1 с самого начала.
Рис.2.2. Читаемый (незашифрованный) текст паролей в web.config
Credentials passwordFormat="Clear">
<user name="Alice" password="testl23"/>
<user name="Bob" password="dragon"/>
<user name="Charlie" password="superman"/>
<user name="David" password="letmein"/>
</credentials>

Проверка подлинности пользователей • Глава 2
2 3 Пароли, зашифрованные SHA - 1
name="Alice" password="7288EDD0FC3FFCBE93A0CF06E3568E28521687BC"/>
. *-i*ls passwordFormat="SHAl">
<credentid ^ ^ ..„_„
<user
^rr^="Bob" password="AF8978B1797B72ACFFF9595A5A2A373EC3D9106D"/>
<user пенис г
<user name="Charlie"
j .л cr28604DD31094A8D69DAE60FlBCD347FlAFC5A"/>
password- l^zo
<user name="David"
^=»R7A875FClEA228B9061041B7CEC4BD3C52AB3CE3"/>
password d
</credentials>
Используйте код С# (рис. 2.4) или код VB.NET (рис. 2.5) для компиляции
утилита командной строки с целью хэширования пароля. Ещё один вариант -
это использование интерактивного генератора хэш, такого как на www.secure-
rnde.net/HasCalc + main.html.
Рис.2.4. Утилита передачи хэша: С#
using System;
using System.Web.security;
namespace Chapter02
{
// Add Sestem.Web to your references
class PassHash
{
[STAThread]
static void Main (string[] args)
{
string sMethod, sPass, sOut;
if (Environment.GetCommandLineArgs ().Length <3)
{
ShowHelp() ;
}
else
{
sMethod =
Environment.GetCommandLineArgs () [ 1].ToUpper().Substring(1,
Environment.GetCommandLineArgs() [1]. Length -1),
SPass = Environment.GetCommandLineArgs () [2];
if ((sMethod == "SHAl" || sMethod == "MD5") &&

Глава 2 • Проверка подлинности пользователей
sPass.Length > 0)
{
sOut =
FormsAuthentication.HashPasswordForStoringlnConfigFile
(sPass, sMethod);
Console.WriteLine(sOut);
}
else
{
ShowHelpO ;
}
}
}
public static void ShowHelpO
{
Console.WriteLine("Usage: PassHash [-MD5|-SHA1] <password>") ;
Console.WriteLine("Example: PassHash -SHA1 letmein");
}
}
}
Рис.2.5. Утилита передачи хэша: VB.NET
Imports System.Web.Security
Module PassHash
Sub Main()
Dim sMethod As String, sPass As String
Dim sOut As String
If Environment.GetCommandLineArgs.Length < 3 Then
ShowHelpO
Else
sMethod = UCase(Right(Environment.GetCommandLineArgs(1), _
Environment.GetCommandLineArgs(1).Length - 1))
sPass = Environment.GetCommandLineArgs(2)
If (sMethod = "SHA1" Or sMethod = "MD5") And sPass.Length The;
sOut=FormsAuthentication.HashPasswordForStoringlnConfigFile(sPass,
sMethod)
Console.WriteLine(sOut)
Else

Проверка подлинности пользователей • Глава 2
ShowHelpO
End If
End If
End Sub
Function ShowHelpO
* i MriteLine("Usage: PassHash [-MD5I-SHA1] <password>")
Console, w j. j-
le writeLine("Example: PassHash -SHA1 letmein")
End Function
End Module
Можно возразить, что хранить пароли в обычном текстовом формате
абсолютно безопасно, поскольку ASP.NET препятствует просматриванию этого файла
посторонними пользователями. В некоторой степени это так, однако, как
показывает опыт, эти файлы не всегда защищены. Возможно, в скором будущем кто-нибудь
обнаружит в ASP.NET дефект, позволяющий просматривать файлы web.config,
или сможет получить доступ каким-нибудь другим способом, таким как
разделенные файлы или FTP-сервер.
Даже MD5 или SHA-1, они тоже могут быть взломаны через словарь или
лобовой атакой. Такие инструменты, как Cain & Abel с www.oxid.it/cain.html.
способны взломать хэши MD5 и SHA-1. Хотя этот метод работает с надежными паролями
очень медленно, Cain обычно взламывает общие пароли, такие как показаны
на рис.2.6. Взвесьте все за и против, доверяя хранение секретных сертификатов
пользователей web.config, перед тем как установить любое web-приложение в вашу
систему.
Внимание
Так как файлы web.config - простые хэши, без особых «примочек», они более
уязвимы для взлома. Подробнее см. главу 4 «Шифрование личных данных».

Глава 2 * Проверка подлинности пользователей
Рис. 2.6. Выполнение с помощью Cain & Abel словарной атаки на
хэшах SHA-1
X
1 Fte Ш Configure Took Нф
© а * з в е ■ в Is
Рк*аеЫяога$о ISA Secret* Network ^/ Oadtor frasewsite ^ CCDU
5Hft4H*h P Ш&# Br
O7288EDD0FC3FFCBE93A0CF06E3568E28521687BC 165456 Pass/Sec 2471912(72%)
^АР8978В1797В72АСРРР9595А5А2А373ЕСЗО9106О dragon 872408(25%)
©18C28604DO31094A8D69DAE60F1BCD347F1AFC5A 185549 Pass/Sec 2037800(59%)
B7A875FC1EA228B9061041B7CEC4BD3C52AB3CE3 letman 1554325(45%)
SNA-iHashes
yZS t ■' ■ mao
Используя опознавание с помощью форм, помните, что оно относится только
к источникам, управляемым ASP.NET, включающим любые файлы с расширением:
■ .asax
■ .aspx
■ .ascx
■ .ashx
■ .asmx
■ .axd
■ .vsdisco
■ .rem
■ .soap
■ .config
■ .cs
■ .csproj
■ .vb
■ .vbproj
■ .webinfo
■ .licx
■ .resx
■ .resources
Сэскег
M&NTLM Hashes
JTLMV2 Hashes
^ PWl Files
Ш Cisco IOS-MD5 Hashes
Ей Cisco PIX-MDS Hashes
* APOP-MD5 Hashes
CRAM-MD5 Hashes
♦$» 05PF-MD5 Hashes
4» RHV2-MD5 Hashes
4» VRRP-HMAC Hashes
fVNC3DE5
г MD2 Hashes
■^ MD4 Hashes
SHU
1
P RIPEMD-160 Hash s
Kerbs PreAuth Hashes:
MSN Hashes
Radius Key Hashes
Sp ГКЕ-Р5К Hashes

Проверка подлинности пользователей • Глава 2 63
0 jsl
т .vjsprqj
используете формы опознавания и запрашиваете файл из защищен-
тории с любым из этих расширений, вас направят на страницу регистра-
Н° гт ояппосе файла с каким-либо другим расширением вы получите файл
нации. При запр ч-
без процедуры опознавания. Для получения инструкции по обеспечению
ности всех файлов смотрите «Mapping Non-ASP.NET Resources» ниже,
в этом же разделе.
Хотя формы опознавания и являются несомненным усовершенствованием
Ллгнкций, доступных в ASP.NET, всё же будьте очень осторожны, используя их.
Формы опознавания больше защищены при использовании их для
идентификации пользователей по базе данных SQL, файлам защиты данных, LDAP или акка-
унту операционной системы. Хранение паролей или хэшей в самом файле web.con-
fig может быть сопряжено с большим риском. Ещё один вариант - это
использование пользовательских файлов XML в защищенной директории для управления
опознаванием. Пример внедрения этого решения можно посмотреть
на http: //msdn.microsoft. com /library /en-us /cpquide/hlml /cpconcookieau-
thenticationusinganxmluserfile.asp
|sj ^^Р^кение He-ASP.NET ресурсов
^ынвнегео характеристик системы ASP.NET подходит только для
ресурсов ASP.NET, поэтому вам необходимо принять дополнительные ме-
Р"#»за»циты не-ASP.NET файлов. Для этого вам нужно расположить
зш ресурсы на фильтре ASP.NET, используя 1IS 5 и IIS6.
Использование IIS 5:
1. В сервисе управления «Интернет» выберите свойства конфи-
гурации приложения.
' 2. Находясь в «Домашней Директории», нажмите кнопку
>*> «Квдфигурация».

Глава 2 * Проверка подлинности пользователей
3- В меню Арр Mappings выберите «Добавить».
I 4. Нажмите кнопку «Browse» и разместите фильтр .NET ISAPl
(обычно расположен на C:\Wmnt\MicrosofLNet\Framework\
<version.\aspnetjsapi.dlI).
5. Введите расширение, которое вы хотите расположить на
ASP.NET (mv\ введите .* для расположения всех
расширений).
Использование IIS 6:1.
1. В сервисе управления Интернет выберите свойства
конфигурации приложения.
2. Находясь в «Домашней Директории», нажмите кнопку
«Конфигурация».
3. В меню Арр Mappings выберите «Добавить».
4. Нажмите кнопку «Browse» и разместите фильтр .NET ISAPl
(обычно расположен на C:\Winnt\Microsoft.Net\Framework\
<versionAaspnetjsapi.dlt).
5. Введите желаемое расширение для установки на ASP.NET
6. Для того чтобы добавить подстановку универсального символа,
нажмите «Вставить» из меню Mapping и введите путь
к .NET ISAPl фильтру.3аметьте» что добавление приложения
wildcard заставляет ASP.NETуправлять всеми расширениями файлов.
Такой метод подойдет для большей части неизменного
содержимого, но вы не сможете применить его для файлов с
расширениями mapped (Perl mw Cold Fusion). Wildcard mapping должно
оказывать некоторое шмтые на работу сервера, в зависимости от типа
содержания в ваших web-директориях. ASP.NET не
предусматривает специальных методов управления для статического содержа-
Конфигурация форм опознавания
Некоторые свойства элементов форм файла web.config оказывают влиян*
на безопасность. К ним относятся:
■ имя = «[имя файла cookie]» Выберите уникальное имя, которое не буде
противоречить именам других форм.
■ защита = «[Всё | Ничего | Шифрование | Подтверждение]» Хотя неь
торые установки могут предложить лучший вариант, вы всегда должны
выбирать значение «Всё» для обеспечения лучшей защиты.

Проверка подлинности пользователей • Глава 2
-f* = «[минуты]» Это протокол времени действия д/ш файла cookie,
измеряемо времени последнего запроса. Значение по умолчанию равняется 30 ми-
Можно установить и более короткое время, например 10 или 15 минут.
ъ поос SSL = «[да I нет]» Когда значение параметра «Да», cookie будет
обоажаться как защищенный, передачу cookie до тех пор, пока установ-
ена безопасность сессии SSL. Установка значения этого параметра на Ис-
ину и использование SSL представляет собой единственный надежный
заслон от похищения файла cookie.
Способы защиты
■ Никогда не используйте Формат пароля = «Очистить» на
производственных системах.
■ Осознавайте риск хранения любых сертификатов в незашифрованном
тексте в файле web.config.
■ При использовании форм опознавания принимайте дополнительные
меры защиты файлов, не управляемых ASP.NET
■ Тщательно планируйте установки для опознавания файлов cookie, чтобы
ограничить возможности для атак.
Использование системы определения
подлинности пользователя Windows
сходное положение: Windows может обеспечивать безопасную
проверку подлинности личности, но только если
она правильно настроена.
Похищение аккаунта, «Человек-в-середине»,
утечка информации
наль П°ЛНении к опознаванию форм ASP.NET предлагает поддержку для ориги-
с°бой етодов опознавания IIS. В совокупности эти программы представляют
л*> лп ентиФикацию Windows. Обозреватель Интернет напоминает пользовате-
н и пароль, как показано на рис. 2.7.
Угроза:

66 Глава 2 • Проверка подлинности пользователей
Рис. 2.7. Напоминание аутентификации Windows
Connect to www
my password
]
Для внедрения системы аутентификации Windows модифицируйте файл
web.config следующим образом:
Authentication modes = "Windows" />
<authorization>
<deny users = "?" />
<authorization>
Затем вам нужно открыть «Менеджер Интернет-Услуг» и выбрать свойства
для директории с защищенным содержимым. Отключите анонимный доступ
и выберите метод опознавания.
IIS предоставляет четыре стандартных метода опознавания:
■ Базовая аутентификация
■ Справочная аутентификация
■ Интегрированная аутентификация Windows
■ Отображение логинов клиентов.
Базовая аутентификация
Базовая аутентификация заключается в подсказывании посетителю web-саи
гина и пароля. Этот метод получил широкое применение из-за того, что его подДеР
вают многие обозреватели Интернет и wetxepeepbi. Преимущества метода таков
■ Работа через прокси-серверы.
Я Совместимость практически со всеми обозревателями Интернет.

Проверка подлинности пользователей • Глава 2
ение ПОЛьзователям доступа к ресурсам, расположенным не на Ш-сервере.
аутентификация имеет также и ряд недостатков:
Аоомация пересылается по сети в обычном текстовом формате.
Она кодируется методом base64 (подробнее см. RFC 1521), но отправляет-
в незашифрованном формате. Любой отправленный пароль, использу-
ший основное опознавание, может быть легко расшифрован.
■ По умолчанию пользователи должны иметь право Местной Регистрации
для использования базовой аутентификации.
■ Базовая система определения подлинности пользователя уязвима для
replay-атак.
Так как базовое опознавание не зашифровывает сертификаты пользователей,
очень важно, чтобы с зашифрованными сессиями SSL был отправлен трафик.
Пользователь, проходящий аутентификацию методом базового опознавания,
должен ввести правильные логин и пароль. Аккаунт пользователя может быть
местным или аккаунтом домена. По умолчанию IIS-сервер будет искать аккаунт
пользователя на месте или в Активной Директории. Если аккаунт пользователя
находится не в местном домене, он должен указать имя домена при входе. Синтаксически
этот процесс выглядит так: имя домена\логин, где имя домена - это имя домена
пользователя. Базовое опознавание также может быть настроено на применение
основного имени пользователя (ОИП) при использовании аккаунтов, хранящихся
на Активной Директории.
Для предотвращения похищения логинов пользователей в сети очень важно все-
использовать SSL при базовом опознавании. Имейте в виду, что основное опозна-
е провоцирует обозреватель Интернет отправлять сертификаты пользователей
кажДУ]ю страницу одного и того же web-сайта, а не только на страницу регистра-
• вдт вы не используете SSL на каждой странице, логины пользователей будут
сети. Один из способов предотвращения отправки логинов на незащищен-
раницы - это использование уникальной области для защищенного и незащи-
° содержания. Подробнее см. Главу 4 «Шифрование персональных >
: данных».
равочная аутентификация
ц0|^ " очная аутентификация во многом схожа с базовой аутентификацией, но
аова J ^ЯД пР°блем- Справочная аутентификация не пересылает имена поль-
Чец* и Пароли по сети. Она обеспечивает более высокий уровень защиты,
^ аутентификация, но требует более тщательного планирования.

68 Глава 2 • Проверка подлинности пользователей
Некоторые общие черты с базовой аутентификацией:
9 Пользователи должны иметь право местной регистрации.
■ Оба метода работают через firewalls.
Как и все методы опознавания, справочное опознавание имеет свои недостатк
■ Пользователи могут получить доступ только к ресурсам на IIS-сервере.
Их логины не могут быть переданы на другой компьютер.
■ IIS-сервер должен быть членом домена.
■ Все аккаунты пользователя должны хранить пароли, используя обратимое
шифрование.
■ Метод работает только с Internet Explorer 5.0. и выше.
■ Справочное опознавание в некоторой степени подвержено replay-атакам.
Справочная аутентификация безопасна благодаря способу передачи
опознавательной информации по сети. Имена пользователей и пароли никогда не
пересылаются. Вместо этого IIS используется справочное сообщение или хэш для
подтверждения логина пользователя. Для обеспечения работы данной системы все
аккаунты пользователей должны быть сохранены с помощью обратимого
шифрования в Активной Директории, что может представлять потенциальную опасность.
Когда эта установка будет доступна для аккаунта пользователя, пароль
пользователя должен быть изменен, чтобы создать копию в обычном текстовом формате.
Справочное опознавание дает большую защиту, но для большинства web-сайтов
недостатки этого метода существенней преимуществ. Интересной особенностью IIS явля
ется то, что когда вы отправляете заголовки опознавания клиенту, он сначала отправ
заголовок основного опознавания. Многие обозреватели Интернет используют первь
попавшийся заголовок и таким образом выбирают более слабое основное опознавая
Интегрированная аутентификация Windows
Интегрированная аутентификация Windows также представляет собой безо
ный метод, так как имена пользователей и пароли не передаются по сети. Эта си
ма очень удобна, поскольку, если пользователь уже зарегистрирован на домене и
ет доступ к web-сайту, логин и пароль у него не запрашиваются. Вместо этого ДЛЯ
знавания пользователя IIS использует скрытые логины пользователя, которые *э

Проверка подлинности пользователей • Глава 2
ются на US-сервер для опознавания. Если процесс идентификации
руются и пользователю предлагается ввести другой логин и пароль.
прошел , ^ ^т конфигурации клиента и сервера, интегрированное опозна-
Бз*"*. doWS использует либо Windows NT LAN Manager (NTLAN), либо
вание авТОматически выбирает метод, основываясь на конфигурации серве-
kerbe ^ Kerberos, и NTLM имеют свои преимущества и недостатки.
Ра И о^птает быстрее и более безопасен, чем NTLM. Kerberos опознает как
Kerberos paouia r
ак и сервер, что помогает предотвратить мошенничество. Kerberos так-
** оляет пользователям получать доступ к ресурсам удаленной сети, не распо-
ой на IIS-сервере. NTLM опознает только клиента, ограничивая доступ
ьзователей к информации по принципу расположения только на IIS-сервере.
Kerberos более предпочтителен для Интранет web-серверов. Однако при исполь-
овании Kerbeios вместо NTLM должны быть выполнены следующие требования:
■ Как клиент, так и сервер должны работать на Windows 2000 или выше.
■ Клиент должен пользоваться Internet Explorer 5 или выше.
■ Клиент и сервер должны быть либо на том же домене, что и IIS-сервер, либо
на домене, который для системы обозначен как проверенный,
«родственный».
Интегрированная система проверки подлинности пользователя Windows
имеет несколько ограничений:
■ Совместимость только с Internet Explorer 3.01. или выше.
Невозможность работы через firewall. Клиент будет использовать firewall
IP-адрес в хэше Интегрированного Windows, что вызовет провал запроса опознания.
Отображение логина клиента
От F.
ражение логина клиента - это процесс передачи логина на аккаунт. Логи-
то ОЬ1ть отражены Активной Директорией или IIS. Оба метода требуют Про-
ащищенных сокетов (SSL). Существует три типа отображения логинов:
Отображение один к одному
т°бражение много к одному
^"Отображение

Глава 2 * Проверка подлинности пользователей
Отображение логина - это процесс соединения логина с аккаунтом
определенного пользователя. Обычно, если мы хотим предоставить пользователю доступ
к интранет, нам нужно либо создать аккаунт пользователя, либо позволить
пользователю зарегистрироваться, используя аккаунт его домена. Создание дубликатов акка-
унта занимает много времени; даже если пользователь использует аккаунт своего
домена, есть вероятность того, что пароли его домена могут быть скомпрометированы.
Для обеспечения лучшей защиты и сокращения объема административной
работы можно присвоить каждому пользователю логин. Логины могут быть
использованы для подтверждения «чистоты» пользователя. На самом деле
использование логина более эффективно, чем аккаунта пользователя, так как логины можно
проверить, не связываясь с базой данных. Распределение логинов более
безопасно, чем аккаунтов пользователей. Более того, гораздо легче вычислить или
взломать чей-то пароль, чем подделать сертификат.
Опознавание пользователей
Если вы обеспечиваете защиту интранет-приложения, через которое
контролируете конфигурацию клиента и сервера и соответствующих клиентов и
серверов в том же домене, интегрированное опознавание Windows, возможно, является
для вас лучшим решением. Для web-сайтов общего доступа самый
распространенный метод - это основное опознавание через SSL-соединения. Поскольку
основное соединение безопасно только при использовании SSL, возможно,
понадобится усилить этот метод на вашем сервере. Можно сделать это через HTTP-модуль,
как показано на рис. 2.8. (С#) и 2.9. (VB.NET). Этот код проверяет, использует
ли каждый отправленный на сервер запрос основное опознавание и отправлен
ли он через SSL-соединение. Если эти два критерия не соблюдены, клиент
получает сообщение «403.4 Ошибка запроса SSL».
Рис. 2.8. Блокирование базового опознавания без SSL: С#
using System;
using System.Web;
using System.Security.Principal;
namespace HttpAuthModules
{
public class AuthenticationModule : IHttpModule
{
public AuthenticationModule()
{
}
public void Init(HttpApplication httpApp)

Проверка подлинности пользователей • Глава 2
SSL
// Register the event handler with Application object.
httpApp.AuthenticateRequest +=
new EventHandler(this.AuthenticateRequest) ;
}
private void AuthenticateRequest(object obj, EventArgs ea)
{
HttpApplication objApp = (HttpApplication) obj;
HttpContext objContext = (HttpContext) objApp.Context;
// Deny access if user is using basic authentication without
if (objApp.User.Identity.AuthenticationType == "Basic" &&
objContext.Request.IsSecureConnection == false)
{
objContext.Response.StatusCode = 4 03;
objApp.Response.End() ;
}
public void Dispose()
{
}
}
}
Рис. 2.9. Блокирование базового опознавания без SSL: VB.NET
Sports System.Web
Public Class AuthenticationModule
implements IHttpModule
Public Sub Init(ByVal app As HttpApplication) Implements
lHttPModule.Init
AddHandler app.AuthenticateRequest, AddressOf
e-AuthenticateRequest
End Sub
-Lie Sub Dispose () Implements IHttpModule. Dispose
Enc* Sub
Private Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As
System.EventArgs)
Di* objApp As HttpApplication

Глава 2 * Проверка подлинности пользователей
Dim objContext As HttpContext
objApp = obj
objContext = objApp.Context
* Deny access if user is using basic authentication without SSL
If objApp.User.Identity.AuthenticationType = "Basic" And _
objContext.Request.IsSecureConnection = False Then
objContext.Response.StatusCode = 403
objApp.Response.End()
End If
End Sub
End Class
Подсказка
Имейте в виду, что HTTP-модуль работает только с файлами, управляемыми
ASP.NET. Если вы хотите, чтобы ASP.NET управлял всеми файлами, следуйте
инструкциям «Отображение не-SAP.NET ресурсов»
Ещё одна проблема опознавания на операционной системе или домене - это
отсутствие прямого контроля над тем, какой аккаунт используется при
регистрации. Если вы предоставляете окно регистрации, любой имеющий аккаунт в этой
системе может попытаться зарегистрироваться. Они могут и не получить доступ
к ресурсу, но сервер позволит им аутентифицироваться. Это дает
злоумышленникам возможность провести лобовую атаку против привилегированных аккаунтов,
например, администраторского.
В зависимости от сети и конфигурации сервера, опознавание Windows может
также сделать возможной передачу атак с web-сервера на другие домены или
серверы внутренней сети. Пользователи могут ввести ник в формат домен/логин для
опознавания на других доменах. Если злоумышленнику известно имя других
доверяемых доменов, которые доступны web-серверу, потенциально он может
осуществить атаку попыткой опознавания на внутреннем домене.
Базовое опознавание также может быть сконфигурировано для UPN при
использовании аккаунтов, хранящихся в активной Директории, вновь обеспечивая
большую возможность для атак передачи данных.
При использовании опознавания Windows вы можете указать, какие именно
пользователи могут заходить на сервер. Для предотвращения доступа можно ис
пользовать файловую или URL-аутентификацию, однако это не предотвратит но
пытки хакеров аутентифицироваться - они всего лишь не получат доступа к соДеР'
жимому. Оба эти метода обеспечивают доступ на основании логина, поэтому поЛЬ'

Проверка подлинности пользователей • Глава 2
тель должен быть сначала аутентифицирован. Если вы не хотите подвергать
унт привилегированного пользователя лобовой атаке через механизм опозна-
иЯ можно оградить этого пользователя от опознавания через web-приложе-
Один из способов достижения этого модуль HTTP, как показано на рис. 2.10.
/Г#) и рис 2.11. (VB.NET). Этот код проверяет логин при каждом запросе
опознания на соответствие пользователю Администратор и отправляет сообщение об
пибке «ошибка 401 HTTP» в случае соответствия. Это предотвращает даже
попытки аутентификации в качестве Администратора.
Рис- 2-10- Блокирование регистрации Администратора: С#
using System;
using System.Web;
using System.Security.Principal;
namespace HttpAuthModules
{
public class AuthenticationModule : IHttpModule
{
public AuthenticationModule()
{
}
public void Init(HttpApplication httpApp)
{
// Register the event handler with Application object.
httpApp.AuthenticateRequest +=
new EventHandler(this.AuthenticateRequest);
}
public void AuthenticateRequest(object obj, EventArgs ea)
{
HttpApplication objApp = (HttpApplication) ob j ;
HttpContext objContext = (HttpContext) objApp.Context;
// If user identity is not administrator, return 403
code
if ( ob;jApp.User. Identity.Name. IndexOf ("administrator") >= 0)
objContext.Response.StatusCode = 403;
objApp.Response.End();
}
}
Public void Dispose()
{

Глава 2 * Проверка подлинности пользователей
Рис. 2.11. Блокирование регистрации Администратора: VB.NET
Imports System.Web
Public Class AuthenticationModule
Implements IHttpModule
Public Sub Init(ByVal app As HttpApplication) Implements
IHttpModule.Init
AddHandler app.AuthenticateRequest, AddressOf
Me.AuthenticateRequest
End Sub
Public Sub Dispose() Implements IHttpModule.Dispose
End Sub
Public Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As
System.EventArgs)
Dim objApp As HttpApplication
Dim objContext As HttpContext
obj App = obj
objContext = objApp.Context
' If user identity is not administrator, return 403 code
If objApp.User.Identity.Name.IndexOf("administrator") >= 0 Then
objContext.Response.StatusCode = 403
objApp.Response.End ()
End If
End Sub
End Class
Способы защиты
Всегда применяйте SSL для каждой страницы, использующей базовое ofl°'
знавание.

Проверка подлинности пользователей • Глава 2
т Используйте уникальные области для защищенного и незащищенного
содержания.
т По возможности задействуйте Интегрированное Опознавание Windows
для интранет-среды.
0 Оградите привилегированных пользователей от лобовых атак, отменив
для них опознавание.
Использование паспортного опознавания
Исходное положение: Паспортное опознавание дает много
преимуществ, однако не следует забывать о риске.
Угроза: Похищение аккаунта.
В середине 1999 года Microsoft выпустил услугу Passport service, единое
решение о подписке и электронной коммерции для web-сайтов. Несмотря на опасения
по поводу секретности и безопасности, Passport service пользуется поддержкой
таких крупных компаний, как eBay, McAfee и Citibank.
Но многие потребители все еще не доверяют системе, при которой столь
крупная база данных контролируется частной компанией, опасаясь, что возрастает
риск злоупотребления. Ещё один вопрос - это безопасность. Паспортная служба
Microsoft ещё не доказала свою надежность.
Тем не менее, у этого способа есть и свои преимущества. Для потребителей -
это небольшое количество паролей для запоминания; для web-сайтов - отсутствие
надоедливых установок базы данных пользователя. Кто-то может возразить, что
лучше иметь один опознавательный сервис с несколькими дефектами, чем тысячи
плохо защищенных web-сайтов. Однако риск очень велик, ведь если кто-то
похитит ваш паспорт аккаунта, он получит доступ ко всем сервисам.
Проблема заключается в том, что Microsoft не доказал безопасность этой сис-
емы, можно только поверить компании на слово. Кроме того, будучи частной
сигмой, Passport service еще не получил общественного одобрения. Microsoft не
РеДпринял никаких усилий ни для оглашения результатов проверки независимых
пертов, ни для подтверждения безопасности публикацией каких-либо техниче-
Деталей. Следовательно, только время покажет, насколько этот метод безопа-
^ на практике. Ещё одной проблемой становится тот факт, что чем больше web-
в начнут использовать Passport service, тем более привлекательной целью для
акеров он станет.
ормы регистрации Passport service у разных web-сайтов различаются по внеш-
и \л НД^' ^ногДа они появляются внутри web-сайта, как, например в Hotmail.com
^сощ; на собственных страницах того же web-сайта, как в eBay.com (см.
РИс-2Д2 9iq\ d - *
*» *-1«э). В зависимости от операционной системы, вы также должны быть
ны за .NET Passport из диалогового окна Windows или мастера подключе-

Глава 2 * Проверка подлинности пользователей
ния. Проблема такого рода непоследовательности заключается в том, что польза
вателю очень сложно отличить легальное окно регистрации от подложного. На
самом деле, кто-то может поместить окно регистрации .NET Passport на web-сайт и
просто собирать имена пользователей и пароли тех, кто им воспользуется.
Рис. 2-12- Регистрационное окно eBay
£*
Sign In With Your Microsoft Passport
Please enter your Passport information below
.M I P« port ign и
Do not ratnimbtr my •-
mell address for future
sign-in. (Select this whan
using • publ с computer.)
*ч
Sornt tltmtntf • 1Ю0 i
Рис. 2.13. Регистрационная форма Citibank
Member Ser -s
Especially for Citi* Cirdmsmbers
NET Passport Sign-in
Е-пмЯ Addre** j<Type your e-mail address>
l Sign me in automatically
-tin
I Do ne* r*fn«nb«r my «-mall addr#*s forfutur*
s4gn<-rn (Select this *h»n uimg • pt>btic computer )
0on*ha*aa t*ETP««p«rt;?
Some elements* 1090 - 2003 Microsoft» Corporation All
Cltl
New to Microsoft* JET Passport?
Ob Cards has teamed wthMcrosoft NET Passport to provide an
optional, secure sign-on process Best of al **s Free) You enter 1
password* to access 100s of participating merchant webstes. no
more wasted tone trying to remember dozens of dWferert passwords
Signing up for ЛЕТ Passport is fast and easy
Register your C» cardfs) for onlne services YouH be able to sign up
for JNET Passport at that time as wel
If you're «ready registered for crane services at cUcards com, i
select the Register button below to get MET Passport today
•Note: When accessing your Cti card account after sign-on
through WET Passport youl be asked to enter your Cardmember
Password This secerxiery level crtprctecttonte design
safeguard your pnvate account ^formation
J

Проверка подлинности пользователей • Глава 2
Хотя Passport service позволяет устанавливать разные параметры для защиты,
никаких гарантий того, что другие web-сайты, купившие данную систему, не бу-
йСПользовать тот же уровень защиты. Другими словами, хотя вы и можете ус-
вить более высокий уровень защиты, пароль пользователя будет закрыт
в большей степени, чем на web-сайте с минимальным уровнем безопасности.
Несмотря на эти недостатки, Passport service обладает и многими достоинства-
Для web-сайтов, использующих Passport service для клиентской настройки, или
cvpCOB, где не хранится личная информация, наиболее подходит Passport
service Таким web-сайтам более выгодно использовать паспортную аутентификацию
вместо того, чтобы давать пользователю другой логин и пароль для запоминания.
Многие web-разработчики недостаточно квалифицированы для создания
защитных свойств управления аккаунтами, и в этих случаях Passport service также
выглядит наиболее безопасным вариантом.
Но для web-сайтов со значимой финансовой и личной информацией
необходимо риск использования Passport service или любого другого механизма одиночной
регистрации возрастает. Пример с Citibank на рис. 2.13. указывает на то, что после
опознавания .NET Passport требуется ввести другой пароль. Хотя это и является
хорошей мерой безопасности и ликвидирует многие недостатки Passport service,
всё равно непонятно, зачем внедрять способ единичной регистрации, если вы все
равно заставляете пользователя запоминать ещё один пароль.
Подсказка
7 Даже если вы не внедрили Passport service на своем web-сайте, есть смысл
помочь клиентам подтвердить их идентичность в случае потери логинов аккаунта
для вашего web-сайта. При совместном использовании с методами, описанными
} в Главе 1, Паспорт дает надежное подтверждение идентичности пользователя.
Например, если пользователь забыл свой пароль, можно аутентифицировать его
с помощью Passport service, а затем отправить сообщение по электронной почте
с дальнейшими указаниями, как переустановить пароль. В этом случае вы
сохраняете опознавательную информацию пользователя неразглашенной, но
выигрываете от использования свойств паспортного централизованного опознавания.
Способы защиты
Не внедряйте паспорт на web-сайтах, где хранится важная финансовая
и личная информация.
*
При использовании Passport service на солидных web-сайтах не забывайте
принимать дополнительные меры безопасности, более подробной
аутентификации пользователей.

Глава 2 ■ Проверка подлинности пользователей
Блокирование лобовых атак
Исходное по л о лее ни е: Лобовые атаки очень сложно заблокироъ
ПОЛНОСТЬЮ, НО еСТЬ ВОЗМОЖНОСТЬ СНИЗИТЬ Hv _,
*** Эф.
фективность.
Угроза: Похищение аккаунтов, отказ от предоставлен
услуг, истощение ресурсов.
Как уже было рассказано в Главе 1, метод лобовой атаки - это попытка вычи
лить пароль систематическим набором всех возможных комбинаций букв, цифп
и символов до тех пор, пока не будет обнаружено верное сочетание.
Злоумышленник всегда сможет вычислить пароль таким способом, вопрос только в том, что это
может занять годы. В зависимости от длины и сложности пароля могут
существовать триллионы возможных комбинаций. Для ускорения процесса подбора хакер
может начать со словарных или слегка измененных словарных слов, так как многие
пользователи в качестве пароля выбирают именно их. Эти атаки относятся к
атакам подбора по словарю, или гибридам лобовой атаки. Лобовые атаки ставят под
удар аккаунты пользователей и загружают ваш web-сайт ненужным трафиком.
При лобовых атаках хакеры используют широкий выбор доступных
инструментов, которые пользуются списками слов и устанавливают правила
автоматического и ручного вычисления паролей пользователей. Хотя такие атаки легко
обнаружить, предотвратить их очень сложно. Например, многие инструменты
лобовых атак HTTP могут пересылать запросы через список открытых
прокси-серверов. Поскольку каждый раз запрос приходит с разных IP-адресов, простой
блокировкой определенного IP-адреса атаку остановить не удастся. Тысячи
прокси-серверов компании Akamai были использованы для атаки подобного рода против
известного web-сайта электронной коммерции, сразу же после перехода в новый век.
Более того, некоторые инструменты при каждой новой попытке пробуют новый
логин и пароль.
Внимание
Web-сайты для взрослых подвергаются сотням или тысячам лобовых атак ежзДне
но. Многие инструменты специально разработаны для атак против таких web-ca*10 •
Один из методов, используемых хакерами, - это сбор больших списков комбинаи
имен пользователей и паролей. Смысл в том, что если у человека есть аккаунт на w
сайте для взрослых, есть вероятность того, что у него есть логин и на другомyNe ^
те, для которого он использует тот же пароль. Такие инструменты, как Комбома
(см. www,securitvtoo)(.net/phpPP^ прочесывают ИнтвРн
поисках имен пользователей и паролей для быстрого составления списка комо
ций. Данная концепция используется в отношении всех типов web-сайтов. ^

Проверка подлинности пользователей • Глава 2
БлоКйрование аккаунтов
очевидным способом пресечения лобовой атаки является простое бло-
аккаунта после определенного количества вводов неверного пароля.
КЙ^ овать аккаунт можно на определенный промежуток времени, например
или же он может оставаться недоступным до тех пор, пока не будет про-
°Д а ручная разблокировка администратором. Однако подобный вариант - не
лачное решение проблемы, поскольку есть вероятность того, что из-за
неильного использования могут быть заблокированы тысячи аккаунтов. На
сале нек0торые web-сайты настолько подвержены атакам, что они просто не
остоянии применять политику блокирования аккаунтов, поскольку им
придется постоянно заниматься их разблокировкой.
Проблемы, возникающие при блокировке аккаунтов:
■ Злоумышленник может спровоцировать отказ в обслуживании (DoS),
заблокировав большое количество аккаунтов.
■ Поскольку нет возможности сделать недоступным несуществующий
аккаунт, заблокируются только действительные имена аккаунтов.
Хакер может использовать эту особенность для сбора имен
пользователей с web-сайта, в зависимости от полученного сообщения
об ошибке.
■ Преступник может нарушить всю деятельность web-сайта, заблокировав
большое количество аккаунтов и заполнив службу помощи сообщениями
о поддержке.
•соумышленник может постоянно блокировать один и то же аккаунт, даже
о истечении нескольких секунд после его разблокировки
администратором.
окирование аккаунтов неэффективно против медленных атак, которые
гут пробовать только несколько паролей в час.
щ з
Р ггие доступа неэффективно против атак, которые пробуют один па-
Для большого списка имен пользователей.
• Б
рование аккаунтов не даст результатов, если злоумышленник ис-
ует список комбинаций логин/пароль и угадывает уже после первой
ааРЫ попыток.

Глава 2 * Проверка подлинности пользователей
■ Мощные аккаунты, например аккаунты администратора, часто обходя
литику блокирования, хотя они представляют собой наиболее привле °"
тельные аккаунты для взлома. Некоторые системы закрывают доступ к
каунтам администратора только при сетевой регистрации.
■ Даже если конфиденциальность была нарушена один раз, атака может
продолжаться, при этом атакующий может получать доступ к ценной ли
ной и финансовой информации.
Блокирование аккаунта эффективно только в контролируемой среде или в случ
ях, когда риск настолько велик, что даже продолжительные отказы в обслуживании
из-за атак более предпочтительны, чем компрометация системы. Однако
в большинстве случаев блокирование аккаунта - не лучший способ борьбы с
лобовыми атаками. В качестве примера можно привести аукционные web-сайты, на которых
несколько скупщиков борются за один лот. Если такой web-сайт поддерживает
политику блокирования аккаунтов, один скупщик может просто заблокировать аккаунты
других скупщиков за минуту до начала торгов, таким образом лишив их возможности
предложить лучшую цену. Тот же способ может быть использован и для
блокирования важных финансовых транзакций или средств электронной коммуникации.
Внимание
Когда я разговариваю с администраторами и разработчиками о проблемах,
связанных с блокированием аккаунтов, их первая реакция - это предложение
увеличить количество попыток ввода пароля перед блокированием. Несомненно,
это защитит пользователей от случайной блокировки аккаунтов, но даже если вы
увеличите количество попыток ввода пароля до 20, злоумышленнику все равно
не составит труда заблокировать его. Ещё одно предложение - сократить время
блокирования аккаунта до нескольких минут. Microsoft Passport Service
использует именно этот метод. Хотя это решение и сокращает количество лобовых атак,
оно все же не предотвращает атаки полномасштабного отказа web-сайта, п
скольку злоумышленник может просто заблокировать ваш аккаунт ещё Р8*
^. что
по истечении этих нескольких минут. В конечном счете, именно вам решать,
лучше всего подходит для вашего web-сайта.
Поиск других контрмер
с0бо*
Как уже было сказано, блокирование аккаунтов не всегда представляет
лучшее решение, но так как атаки обычно носят автоматизированный хар ^
в вашем распоряжении есть еще несколько способов. Во-первых, поскольку , *,
атаки зависит от времени, самым простым выходом было бы установить

Проверка подлинности пользователей • Глава 2 81
и проверке пароля. Добавив даже незначительную паузу в несколько
н&е паУ гшественно замедлите лобовую атаку, не причинив никаких неудобств
секуНД» - и регИстрации входа в аккаунт. Код на рис. 2.14. (С#) и рис.2.15.
лользо иводит пример установки паузы при помощи HTTP-модуля.
о 14. Приостановка опознавания пароля: С#
,.olfj AuthenticateRequest (object obj , EventArgs ea)
private VUiU
HttpApplication objApp = (HttpAppliation) obj;
HttpContext ob^Context = (HttpContext) objApp.Context;
// If user identity is not blank, pause for a random amount of time
if ( objApp.User.Identity.Name ! = " ")
{
Random rand = new Random () ;
Thread.Sleep (rand.Next (minSeconds, maxSeconds) * 1000);
}
}
Рис. 2.15. Приостановка опознавания пароля: VB.NET
Public Sub AuthenticateRequest (ByVal obj As Object, ByVal ea As
System. EventArgs)
Dim objApp As HttpApplication
Dim objContext As HttpContext
Di** ran As Random
obJApp = obD
°bjContext = objApp. Context
1 If
T er ldentity is not blank, pause for a random amount of time
°bjApp.user. Identity.Name <> "" Then
ran - New Random
End eaCUSleep(ran-Next(ran.Next(minSeconds, maxSeconds) * 1000))
£n<* Sub
^'tyftbTa Ие ИаУзы не так эффективно, потому что приостановка атаки не даст
^еоп1» ' если злоумышленник отправляет множество запросов на опознава-
^^Ременно.

Глава 2 * Проверка подлинности пользователей
Ещё один способ - это блокирование IP-адреса, с которого были осуществ
неоднократные неудачные попытки регистрации. Недостатком этого способа '
ется то, что вы можете непреднамеренно заблокировать большую группу Поль
телей, перекрывая прокси-сервер, используемый крупной компанией. Еще
проблема заключается в том, что многие инструменты утилизируют прокси-crm
и отправляют только несколько запросов с каждого IP-адреса, далее переходя
следующий. Используя находящиеся в широком доступе открытые прокси-спи
на web-сайтах, например http://tooIs.rosinstrument.com/proxy/, хакер легко гм
жет обойти любой блокирующий IP-механизм. Поскольку большинство web-сайт
не блокируется после первой же неудачной попытки ввода пароля, злоумышлении
может предпринять две или три таких попытки для каждого прокси. При наличии
у него списка из 1000 прокси он может попробовать ввести 2000 или 3000 паролей
и блокирующий механизм не сработает. Но, несмотря на все недостатки, многие
web-сайты - а особенно web-сайты для взрослых - все-таки предпочитают
блокировать прокси IP-адреса, поскольку они слишком часто подвергаются атакам.
Некоторые компании, например Pennywize (www.pennywize.com), предлагают
методы, помогающие блокировать лобовые атаки. Один из таких простых, но
удивительно эффективных методов - использовать нестандартную реакцию на
ошибочные пароли. Например, большинство web-сайтов при вводе неправильного
пароля выдают сообщение «HTTP ошибка 401», а некоторые ресурсы - «HTTP 200
Успешно», но при этом направляют пользователя на страницу, указывающую
на ошибку при вводе пароля. Это ставит в заблуждение некоторые автоматические
системы, но это препятствие также легко обойти. Оптимальный выход - это
постоянно вносить изменения для создания препятствий. Это остановит хотя бы часть
хакеров. Можно, например, каждый раз отправлять новое сообщение об ошибке
или иногда, позволив пользователю войти на страницу, снова запросить у него
пароль.
Подсказка ^^^^
Некоторые автоматические инструменты лобовых атак позволяют хакерам У^8
навливать определенные строки запроса для просмотра того, как будет указа
неудачная попытка ввода пароля. Например, если сообщение об ошибке сод
жит фразу «Неверный логин или пароль», инструмент будет знать, что ошио
логине, и попробует ввести следующий по списку ник. Простой способ обма
эти инструменты - это включить эту же фразу как комментарий HTML-источ
страницы, при успешной аутентификации.
После одной или двух неудачных попыток регистрации попросите польз
ля не только напомнить логин и пароль, но и ответить на секретный в ^
Это не только предотвратит взлом в результате автоматизированных атак, ** ^
дет препятствовать получению доступа злоумышленником даже при налили

Проверка подлинности пользователей • Глава 2 83
логина и пароля. При обнаружении большого количества атак можно
то 3е™ ответ на секретный вопрос у всех пользователей,
прашивать
методы, которые могут вас заинтересовать:
Поедоставьте продвинутым пользователям опцию, разрешающую
регистрацию только с определенных IP-адресов.
■ Присвойте уникальный URL регистрации для группы пользователей
таким образом, чтобы не все пользователи могли получить доступ к
web-сайту с одного URL.
■ Используйте САРТСНА для предотвращения автоматических атак (см.
колонку «Использование САРТСНА»)
■ Вместо полной блокировки аккаунта поставьте его в режим полной
изоляции с ограниченными возможностями.
Применение большинства из перечисленных способов можно обнаружить,
но если совместить несколько методов, вы сможете защитить web-сайт от многих
лобовых атак. Очень непросто остановить опытного хакера, который намерен
получить пароль от вашего web-сайта, но, тем не менее, подобные ухищрения
помогут не допустить к важной информации многих злоумышленников, особенно
новичков. Эти методы затрудняют и замедляют действия хакеров, что дает вам
оольше возможностей вовремя обнаружить попытку атаки, и даже вычислить
злоумышленника. Системы обнаружения вторжений играют большую роль в
подобных ситуациях.
л
\
*^1Шяьзование CAPTCHAS
\ 41о^^НОСТЬЮ а8томатизиРованнь*й тест Тьюринга, отличающий че-
Щаа^ Ш номпьютеРа* или САРТСНА, - это программа,
позволяющие^*1* отличить компьютер от человека. Впервые получившая
-*Л!2^^рименение у Alta Vista для предотвращения автоматичес-

Глава 2 * Проверка подлинности пользователей
v
кого поиска подчинений, САРТСНА особенно эффективна в остан^
ке автоматического вторжения любого вида, включая лобовые ат
ки. Смысл работы заключается в предоставлении некоторых тесто»
которые человек легко пройдет, а компьютер - нет. Для того чтоб
САРТСНА работала эффективно, человек должен пройти тест ка
можно быстрее. Компьютеры, как правило, дают неверные огветы
Ez-gimpy (www.captcha>net/chi-bfn/ez-gimpy). возможно, самая
известная САРТСНА, предоставляет пользователю скрытое слово, которое он
должен ввести для прохождения теста. Но теперь появились
программы распознавания написанных образцов, которые решают ez-gimpy c
точностью до 92%. Исследователи из Школы Информатики Карнеги
Меллон постоянно работают над совершенствованием и
представлением новых САРТСНА (см. www,captcha.net/captehas),Если вы
разрабатываете собственный САРТСНА, имейте в виду, что вопрос не в том,
насколько сложны вопросы, а в том, насколько желательно, чтобы
компьютер получил правильный ответ. Однажды я видел САРТСНА с
картинкой, изображающей трех зебр. Пользователю предлагалось ответить
на вопрос, сколько зебр изображено на картинке, выбрав правильный
вариант ответа из нескольких предложенных. Для того чтобы ответить
на вопрос, нужно было нажать на одну из трех кнопок. Хотя
компьютеру очень сложно и понять вопрос, и интерпретировать картинку,
программа может дать случайно выбранный ответ и потратить 30%
времени. Такой уровень риска может показаться удовлетворительным,
но на самом деле подобную программу нельзя считать эффективной.
Если вы пользуетесь бесплатной услугой электронной почты и
используете похожую САРТСНА для предотвращения создания спаммерами
аккаунтов, все, что им нужно сделать, - это написать скрипт для
автоматического создания 1000 аккаунтов и рассчитывать, что в среднем
333 попытки будут успешными. Тем не менее, простые САРТСНА могут
быть эффективными против лобовых атак. Если вы совместите шанс
угадывания злоумышленником правильного логина и пароля с шансом
правильного разгадывания САРТСНА с другими методами,
описанными в этой главе, даже простая САРТСНА может быть достаточно
эффективной.
Хотя лобовые атаки сложно остановить полностью, их легко обнар^
•с к°-
потому что каждая неверная попытка регистрации записывает стати
HTTP 401 в журнале регистрации вашего web-сервера. Очень важно отс
вать ваши файлы журнала регистрации на лобовые атаки - в частности, iier
шанные 200 статусных кодов статуса, что означает, что злоумышленник о
жил правильный пароль.

Проверка подлинности пользователей • Глава 2 85
иведены признаки лобовой атаки или других злоупотреблений аккаунтом:
кратный ввод неверных регистрационных данных с одного и того
же IP-адреса
страции под разными именами пользователей с одного и того же IP-адреса
«ход в один аккаунт с большого количества различных IP-адресов.
■ Чрезмерное использование трафика или чрезмерный его расход при
единичном использовании.
■ Попытки проникнуть под разными логинами и паролями,
расположенными в алфавитном порядке
■ Регистрация с направляющего URL чьей-то почты или IRC (система
диалогового общения по Интернету) клиента.
■ Направляющий URL, содержащий логин и пароль в формате
http;//use:password(«Vw^.example.com/login.htm
■ При защите web-сайтов для взрослых с использованием URL известных
web-сайтов, практикующих распределение паролей.
■ Регистрация с подозрительными паролями, обычно использующимися
хакерами, такими как ownsyou (ownzyou), washere (wazhere), zealots, hacksyou
и тому подобное (см. www.securitybox.net/phpBB2/viewtopic.phpPt - 8563)
пособы защиты
спользуйте методы блокирования аккаунтов только в контролируемой
реде или там, где риск компрометации сервиса выше, чем риск
продолжительных атак отказа в обслуживании.
авьте случайно выбранные паузы в процесс опознавания для замедле-
ния лобовых атак.
• Об
-думайте блокирование IP-адресов, с которых были произведены многократ-
еУЦачные попытки регистрации, но принимайте во внимание последст-
•локирования прокси, используемого клиентами, которые входят в Интер-
10 выДеленной линии, а через модем, по карточке, с динамическим IP.

86 Глава 2 * Проверка подлинности пользователей
■ Периодически меняйте сообщения как для неудачной, так и для ycnei
аутентификации пароля. **
■ Попросите клиента ответить на секретный вопрос после ряда неудачи
попыток регистрации.
■ Предоставьте пользователям опцию ограничения входа на аккаунт толь
с определенных IP-адресов.
■ Используйте уникальную регистрацию URL для разных групп
пользователей.
■ Используйте САРТСНА для предотвращения автоматических атак.
■ Ограничьте возможности аккаунта при подозрении на атаку.
Авторизация пользователей
После подтверждения идентичности пользователя нужно определить, имеет
ли он доступ к запрашиваемому ресурсу. Для этого и нужна авторизация
пользователя. Возможно, это самая надежная часть ASP.NET в области авторизации
пользователя. В этом разделе мы рассмотрим:
■ Принятие решения о способе авторизации
■ Конфигурация файла авторизации
■ Создание URL авторизации
■ Авторизация через код
Принятие решения о способе авторизации
Исходное положение: Стратегия тщательной авторизации - это
вы надежной защиты приложения
Угроза: Несанкционированный доступ, расШйр
привилегий q.
В классической ASP нет встроенных способов авторизации - вы либо
стью устанавливаете её с кодом пользователя, либо разрешаете основной оп У
онной системе устанавливать её с небольшим взаимодействием с вашим Р&

Проверка подлинности пользователей • Глава 2 87
TFT предлагает наДежнУю инфраструктуру авторизации, обладающую
дом- № •* начинающих клиентов количеством новых свойств.
•«гяТОЧНЫМ Дг>
пост*1 надежность может казаться настолько сложной, что некото-
К сожалению,^! «*
т изучения и применения этих свойств. Однако нужно подчеркнуть,
рые й 00ения надежной системы безопасности вашего web-сайта очень важ-
чТОДЯЯ гъся во всех деталях авторизации ASP.NET.
н° Р ясения ASP.NET прекрасно работают и без авторизации, поэтому неко-
оаботчики не видят никакой необходимости в проведении авторизации,
Т ьзователь аутентифицирован. На самом деле многие ASP-приложения
подразумевают, что пользователь авторизован, если он прошел опознава-
Например, обычно существует административная область для поддержки
b-сайта и других привилегированных функций. Для получения доступа к этой
ресурса нужно войти в систему под именем и паролем администратора.
Недостаток этого метода в том, что он либо полностью разрешает, либо
полностью отклоняет доступ. Авторизация позволяет вам определить роли
пользователей и способы, которыми они могут взаимодействовать с операциями и ресурсами
вашего приложения. Опознавание касается получения права доступа, а
авторизация определяет, какой именно доступ разрешен.
Личные параметры, основы и роли
Опознавание - ключевая часть авторизации. Чтобы разрешить или запретить
доступ, вам сначала необходимо выяснить аутентичность данного пользователя.
•NET Framework (Инфраструктура) представляет 2 уровня данных о пользователе -
поле идентичности и основное поле. Основное поле соответствует пользователю
содержит поле идентичности, в котором содержится подробная информация
ловеке. Пользователи могут быть разделены на разные группы, или роли; ча-
сего они дифференцируются на администраторов и пользователей.
^ сновное поле осуществляет IPrincipal (Основное) интерфейс, позволяющий
Рятьроли и обеспечивает функционирование поля Ildenity (Идентичность):
,JbliC interface IPrincipal
TZl ISlnR°le(string role);
. Id**ity ^entity {get;,
^0де fa
^° fcHtbo Носгпь осуществляет интерфейс Идентичности и дает дополнитель-
РМацию о пользователе:

Глава 2 * Проверка подлинности пользователей
public interface Ildentity
{
string authenticationType {get;}
bool IsAuthenticated {get;}
string Name {get;}
}
.NET Framework включает в себя несколько объектов, которые осуществля
интерфейсы этих двух нолей. То, какие именно поля вы используете, завис
от выбранного вами метода опознавания пользователей. Таблица 2.1. иоказывае
какие объекты использовать для разных сценариев опознавания. Заметьте, чт
в дополнение к этим встроенным полям можно самим создавать ваши собственны
поля и управлять ими.
Роли и ресурсы
В ASP.NET существует два подхода к авторизации пользователей: ролевой и
ресурсный. Контроль доступа, основанный на ролях (Role-based access control -
RBAC), авторизует пользователей на основе их принадлежности к той или иной
логической группе, или роли. Принцип действия Ресурсной авторизации (Resource-
based authorization), схожей с дискреционным контролем доступа (Dictionary access
control - DAC), заключается в предоставлении или прекращении доступа к личным
ресурсам, основанного на отдельных пользователях или группах. Принципиальной
разницы между данными подходами нет. Главное различие состоит в том, что
ресурсная авторизация характерна для реальных ресурсов и для пользователей в
основной операционной системе или сети. Ролевая авторизация менее конкретна и
не зависит от операционной системы или ее ресурсов. Поэтому ресурсная
авторизация имеет что-то общее с применением списка дискреционного контроля дост>
па (Discretionary access control list - DACL), предоставляя через BUILTIN\Usei>
Read доступ к директории c:\inetpub\wwwroot\members\ и ее файлам. Ролевая а
торизация зависит от того, как Windows воспринимает BUILTIN\Users и физич
кого местонахождения директории Members. Ролевая авторизация зависит от то
как приложение определяет роль Members и приложение Members.
Поскольку ролевая авторизация более абстрактна и не зависит от осно
инфраструктуры, она обеспечивает большую гибкость и масштабность, че>
сурсная авторизация. Но ресурсная авторизация распространена более ш*Ф
Из-за абстрактного характера ролевая авторизация является также естестве
представлением организационной структуры, правил и процессов.
о

Таблица 2.1. Типы опознавания с ассоциированными основным и идентичным полями
Метод опознавания
Формы
Windows
Passport Service
Основной объект Идентичный объект
Обобщенный Основной Идентичность Форм
Обобщенный Основной Идентичность Windows
Обобщенный Основной Паспортная
Идентичность
Сертификаты
Хранятся в web.config
или опознавательном
коде пользователя
Обеспечивается
основной операционной
системой или доменом
.NET Passport
Роли
Установлена
одновременно с кодом
пользователя
Windows или группы
активной директории
Устанавливается на
базе групп паспортных
пользователей.
ш
ф
■о
э
s
X
X
8
§
е
о
ш
ф
S
Q)
Ю
Ш

90 Глава 2 * Проверка подлинности пользователей
Подсказка
При ролевой авторизации можно легко включать или отключать функции rm ^
жения, основываясь на ролевом членстве. Например, вам может понадоби Л°
ввести роль «Продвинутый пользователь» и предоставить членам этой rpv ^
расширенные возможности пользовательского интерфейса. Далее можно *
здать роль «Пониженные в правах» для аккаунтов пользователей, подозрев °
мых в нарушении безопасности, и блокировать определенные действия член
этой группы.
В ASP.NET существует несколько способов достижения ролевой авторизаци
которые будут описаны более детально далее в этой главе:
■ Авторизация URL
■ Декларативная безопасность, основанная на пользователе
■ Императивная защита, основанная на пользователе
■ Проверка явно заданных ролей
Способы защиты
■ Внедрение надежной основы авторизации при разработке приложения.
■ Разработка схемы ролевой авторизации.
■ Применение ресурсной авторизации для расширения ролевой авторизации.
■ Использование множественных уровней ролевой и ресурсной авторизаци
Авторизация используемых файлов
Исходное положение: Авторизация файлов предлагает уровн
и структурированный подходы к достилс
безопасности е
Угроза: Несанкционированный доступ, нелегал
расширение прав
Авторизация файлов - это процесс получения доступа к ресурсам фаИ ^
средством установки соответствующего контрольного списка доступа
(КСД;АС1С

Проверка подлинности пользователей • Глава 2 91
- ACL) на web-содержание файлов. Все приложения ASP.NET автомати-
cot№° льзуют авторизацию файлов; вы не можете это исправить или перена-
чеСК1! Авторизация файлов является функцией файловой системы NTFS.
сгр° ет вопрос, зачем ASP.NET предоставляет модуль файловой авториза-
он уже управляется операционной системой. Причины, по которым
ЦИЙ' тгТ включает в себя файловую авторизацию, заключаются в следующем:
Лля работы файловой авторизации не требуется проверки подлинности
пользователя. Поэтому операционная система видит только запрос файла,
приходящий из контекста процесса ASP.NET. ASP.NET управляет
проверкой соответствия доступа, запрашиваемого пользователем.
■ ASP.NET может не обеспечивать прямой доступ к файлу, вместо этого
он предоставляет общий доступ к ассамблее файла.
■ Так как ASP.NET проверяет разрешения NTFS, оно может управляться
и восстанавливаться при любых нарушениях безопасности, связанных
с неудачной попыткой доступа.
Вы настраиваете файловую авторизацию, получая доступ к свойствам защиты
файла в Windows Explorer, с использованием таких инструментов, как xcacls.exe,
через шаблоны защиты или через Group Policy. Поскольку ASP.NET осуществляет
файловую авторизацию на базе файлов ACL (список управления доступом), он
требует действительной идентичности Windows; поэтому система работает только
с концепцией опознавания Windows. Если Windowsldentity не связана с запросом,
икакой проверки доступа не будет проводиться вообще. То же самое относится
любому типу файлов, не преобразованных в ASP.NET.IIS, и основная операцион-
система все же будет выполнять проверку. Для установки соответствующих
v ений очень важно определить контекст защиты от опасностей, которые
гут представлять угрозу для файлов.
д но также всегда использовать некоторые формы файловой авторизации,
и вы не в полной мере понимаете, что такое ACL и контекст защиты. Но,
*им М^М' нУЖно предоставить пользователям доступ к web-содержанию в
реме^ ЬКо чтение». В NTFS есть большое количество структурированных пара-
Детза стР°йки- Чем больше таких установок вы используете, тем надежнее бу-
d Щиц*ено ваше приложение.
||е^ объект в Windows имеет три ACL: один для себя, один для передачи на до-
Один °*^екгы (Файлы) и ещё один для передачи на подкаталоги (директории).
методов достижения сверхнадежной защиты - это установка на дирек-

Глава 2 * Проверка подлинности пользователей
ториях переходящих разрешений, так чтобы новый объект обладал ограни
ным доступом либо не обладал им вообще. Это заставит вас установить разве ^
ния NTFS для всех новых файлов и директорий и в то же время ограничит дп^
хакеру, если ему каким-то образом удастся создать новый файл или директор
Хотя файловая авторизация - это ресурсный контроль доступа, вы также
жете воспользоваться преимуществом Windows или Active Directory groups для
дрения ролевой стратегии.
Способы защиты
■ Всегда устанавливайте ограниченные NTFS-разрешения на содержание
web-файлов, даже если не используете Windows для опознавания и
авторизации для доступа к файлам.
■ Используйте файловую авторизацию для внедрения как ресурсной,
так и ролевой безопасности.
■ Установите специфические и подробные NTFS разрешения для
повышения безопасности приложения.
■ Пользователи должны иметь право доступа только для чтения содержания
web-сайтов.
Применение авторизации URL
Авторизация URL - это механизм контроля доступа, основанный на пользователе,
роли, ресурсе или использованной операции HTTP. В своей основе авторизация и
связана с запросом, поэтому она работает с любой формой опознавания. Она такж
позволяет устанавливать ограничения для незарегистрированных пользователей.
Авторизация URL - эффективное средство усиления наименьших привиле
точным обозначением, кто и куда может получить доступ. Можно создать ко Ч>
гурацию авторизации URL редактированием web.config для защиты прилове
Каждый web.config приложения будет отменять установку любого каталога.
Пользователи и роли
Следующая часть web.config представляет собой пример авторизации и
<authorization>
<deny users="?"/>

Проверка подлинности пользователей • Глава 2 93
<allow u-.»—/>
внимание, что авторизация URL использует знак вопроса (?)
</autboriZation>
Обратите вниман . .
ния любого несанкционированного пользователя и звездочку (*),
дЛЯ ения всех пользователей. В приведенном примере код запрещает до-
ДЛЯ еопознанным пользователям и пропускает опознанных. В следующем
СТ^П ячяны все действительные форматы идентификации пользователей:
примере укалш
<allow users="?"/>
<allow users="*"/>
<allow users="Admin"/>
<allow users="Alice, Bob"/>
<allow users="BUILTIN\Administrator"/>
<allow users="Local.Domain\Joe"/>
Роли идентифицируются похожим способом:
<allow users="Managers"/>
<allow users="BUILTIN\Administrators"/>
<allow users="Local.Domain\Administrators"/>
Процесс авторизации URL-установок в ASP.NET происходит сверху к
середине, с остановкой на первом обнаруженном совпадении и игнорированием любого
заменяющего элемента. Поэтому очень важно соблюдать порядок элементов.
Существует два основных метода контроля доступа при настройке авторизации
Кь для защищенного содержимого web-сайта. Первый метод начинается с
блокирования неопознанных пользователей, затем прекращается доступ специфичес-
ользователей и ролей, и заканчивается разрешением доступа для всех осталь-
ользователей. Этот метод показан в следующем примере:
Authorization
<deny users="?"/>
<denV r°les="Expired"/>
<aHow users="*"/>
</^thorization>
Cei«UoT Римере пользователей вынуждают аутентифицироваться, при этом
отрется енты» чье право доступа закончилось какое-то время назад, и разре-
^|| Но всем остальным пользователям. В приведенном примере очень важ-
*е* Ь щч °М является отрицание неопознанных пользователей в первой стро-
н°м случае конфигурация будет выглядеть следующим образом:

94 Глава 2 * Проверка подлинности пользователей
<authorization>
<deny roles="Expired"/>
<allow users="*'7>
</authorization
Если пропустить первую строчку из предыдущего примера, то есть не от
неопознанных пользователей, система начнет с проверки того, не является
роль пользователя недействительной. Если пользователь ещё не аутентифипи
ван, он не может быть членом какой-либо роли, и, следовательно, этот элемент
совпадет. Следующий элемент допускает всех пользователей, данные которых ок
жутся верными, и они получат доступ к приложению.
Ещё один из наиболее популярных методов - блокирование неопознанных
пользователей, разрешение доступа всем специфическим пользователям и ролям
а затем отклонение всех остальных:
<authorization>
<deny users="?"/>
<allow roles="Managers"/>
<deny users="*"/>
</authorization> >
Эта конфигурация заставляет пользователей аутентифицироваться,
разрешает пользователям, принадлежащим к группе Manager, получить доступ к
приложению, но отклоняет всех остальных. В этом методе важно то, что вы включаете
последнюю строку, которая отрицает всех пользователей. Если пользователь не
соответствует ни одному элементу авторизации, он по умолчанию получает право
доступа до тех пор, пока web.config в родительской директории эксплицитно
отклонит право доступа.
Операции HTTP
Можно также использовать аутентификацию URL для блокировки опер
HTTP. Например, если у вас есть web-форма и вы хотите убедиться, что поль
тель использует метод POST, можно сделать следующее:
<authorization>
<allow users="*" verbs="POST"/>
<deny users="*"/>
</authorization

Проверка подлинности пользователей • Глава 2
Заметьте,
что в этом примере принимаются любые запросы от любого пользова-
jaM1'* щеГося операцией POST. В следующей строке мы отклоняем все запро-
теЛЯ'П пользователей. Это делается потому, что любые операции, кроме POST, не
сЫ оТ первой строкой, и, следовательно, не будут приняты. Другими словами, эле-
с0впаду шенИЯ эксплицитно определяет операции, которые не приняты. При опре-
мент у пераций с разрешенным элементом вы всегда должны ставить его за элемен-
^ пания. Следующий пример показывает выполнение того же, что и
предыдущий:
<authorization>
<allow users="*" verbs="POST"/>
<deny users="*" verbs="GET, HEAD, DEBUG"/>
</authorization>
Заметьте, что помещение в программу неопределенного атрибута операций
равносильно разрешению или отрицанию всех операций, поддерживаемых
ASP.NET (GET, HEAD, POST, DEBUG).
Внимание
I Можно применить URL-авторизацию для защиты сканеров CGI (общий шлюзовой
«интерфейс), которые используют операции HTTP HEAD. Хотя можно
заблокировать отправку запросов HEAD на существующие файлы, все равно появится сооб-
j щение об ошибке «404 Не найден», если файл не существует. Поэтому
необходимо обозначить для сканера, что статус кода «401 Не авторизован», в отличие
от обычно упоминаемых 200 0К, означает, что файл существует.
Существует несколько запретов использования авторизации URL для
ограничения операций HTTP:
Нельзя использовать обобщения в атрибутах операций.
ичень просто определить настройки для различных типов файлов (при
использовании положения элемента, описанного выше).
• Пр„
попытке выполнить заблокированную операцию выдается сообщение
°б ошибке «401 Не авторизован», а не «405 Метод Не Разрешен», что было
"Ы правильнее. Если запрос использует отклоненную операцию при от-
правке сообщения об ошибке 401, у пользователя будет запрошен ввод
сертификатов, но даже в случае правильного их указания он получит ещё од-
**о сообщение об ошибке 401.

96 Глава 2 * Проверка подлинности пользователей
HTTPMethodNotAllowedHandler (метод обработки неразрешенного д0
обеспечивает больший контроль над блокирующими операциями. Можно ^
вить этот разработчик в ваш файл web.config, как показано ниже: а'
~NtKEss <system.web>
SB <httpHandlers>
<add verb="*"
path="*.mdb"
type="System.Web.HttpMethodNotAllowedHandler"/>
</httpHandlers>
</system.web>
Этот пример блокирует все операции любого файла с расширением .mdb
Имейте в виду, что для того, чтобы этот пример работал, расширение файла
*/mdb должно быть эксплицитно преобразовано для aspnet_isapi.dll или иметь
обобщенное преобразование для aspnet_isapi.dll. Путь свойств может содержать
символы обобщения в любой части пути, как показано ниже:
n*«777 <system.web>
^В <httpHandlers>
<add verb="*"
path="/members/a??/def*.*"
type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>
</system.web>
Интересно отметить, что атрибут операции, в отличие от атрибутов опера
ций, которые использует аутентификация URL, может также манипулировать си
волами обобщения. Метод HttpMethodNotAllowedHandler не предлагает авториза
ций для конкретного пользователя; он просто присылает сообщение об оши
«405 Метод Не Разрешен» на любой запрос, совпадающий с данной операцией
путем. Это удобно для гибкого блокирования операций HTTP, но не позволяе
танавливать параметры для каждого отдельно взятого пользователя. Лучши ^
ходом из этого положения является использование сочетания URL-автори
атрибута операции и HttpMethodNotAllowedHandler.
Файлы и пути
Можно применять авторизацию URL для установки ограничений инд
альных файлов и путей, используя элемент местонахождения, как показано

Проверка подлинности пользователей • Глава 2
<confi^ation>
<С vocation path="">
<system.web>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="default.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
В приведенном примере первый элемент оставляет путь, который относится
к текущей директории, пустым, и запрещает всем неопознанным пользователям
доступ к файлам этой директории. Второй элемент определяет путь к файлу
defaultaspx и разрешает всем просмотреть содержимое этого файла. В результате
неопознанные клиенты получают доступ к домашней странице, но далее от них тре-
уют аутентификации для получения доступа к любому другому файлу. Интересно
метить, что порядок расположения элементов не влияет на очередность их вы-
лнения. Это происходит потому, что default.aspx является дочерним файлом теку-
приложения и, следовательно, воспринимает конфигурацию как иерархию.
\*>олее подробное описание иерархии конфигурации вы найдете ниже в этой главе).
но задействовать элементы положения для полного блокирования досту-
к 0пРеделенному файлу:
< Nation path="settings.mdb">
<system.web>
<authorization>
<deny users="*"/>
^authorization
</system.web>
/location>

98 Глава 2 * Проверка подлинности пользователей
Заметьте, что использовать обобщения в установочном пути нельзя, по
вы можете прописать путь положения либо на всей директории, либо индц ^
ально для каждого файла, на котором вы бы хотели видеть разные настройки V
ризации. Если вам нужно полностью заблокировать доступ пользователей к & -
с помощью обобщения, просто добавьте к файлу web.config следующее:
<system.web>
<httpHandlers>
<add verb="*" path="* .mdb" type="System. Web. HttpForbiddenHandler" л
</httpHandlers>
</system.web>
В данном примере для обеспечения работы расширение файла *.mdb должно
быть эксплицитно преобразовано для aspnet_isapi.dll или иметь обобщенное
преобразование в приложении для aspnet_isapi.dll. Атрибуты пути и операции
поддерживают такие обобщения, как уже упомянутый HttpMethodNotAllowedHandler.
См. раздел <httpHandler> в файле machine.config для рассмотрения примера того,
как ASP.NET использует метод HttpForbiddenHandler для блокировки
определенных расширений файла.
Подсказка
В дополнение к уже упомянутым, HttpForbiddenHandler и HttpMethodAllowedHandler,
ASP.NET предлагает два других: HttpNotFoundHandler и HttpNotlmplementedHandler.
Иерархия Конфигурации
С помощью ASP.NET можно создать файл web.config для приложения и уникальнь
web.config для каждого дочернего приложения. Кроме того, machine.config манилулир,
глобальными установками для приложений. При управлении авторизацией ASP.NE1 в
чает различные конфигурирующие файлы в совокупности, начиная с дочернего при-*
ния низшего уровня. Другими словами, она проверяет раздел авторизации web.conng ф^
текущего приложения. Если соответствия не обнаружены, программа проверяет разд
ризации файлов machine.config любого исходного приложения, как правило, закан1*
файлом machine.config, который по умолчанию дает право доступа всем операциям
зователям. ASP.NET воспринимает конфигурирующие файлы, как если бы вы с каЖД
бавляли секции авторизации, начиная с текущего уровня и повышая уровень в ходе р
Во избежание непреднамеренного разрешения доступа каждую авторизаШ* .
но завершать элементом, либо допускающим, либо отклоняющим всех пользов
Когда ASP.NET наталкивается на эту строку, всегда происходит совпадение,

Проверка подлинности пользователей * Глава 2 99
оизводит больше никаких авторизующих элементов. Единственное ис-
кД1°че " уСТаНовок авторизации приложения. В этом случае нужно тщательно спла-
граммам
этого правила - это если вы хотите, чтобы одно приложение имело под-
0чение1
исходную конфигурацию, чтобы не допустить непреднамеренного доступа.
нйровать
Подсказка
^г-дятвратить изменение исходной конфигурации дочернего приложения мож-
побавив элементу свойство разрешить Отмену = «нет».
Способы защиты
■ Используйте авторизацию URL для ограничения доступа к ресурсам web-
сайта.
■ Заблокируйте неиспользованные операции HTTP при помощи атрибута
операций или HttpMethodNotAllowedHandler.
■ Используйте HttpForbiddenHandler или HttpNotFoundHandler для
блокирования всеобщего доступа к определенным файлам.
Авторизация пользователей через код
Наиболее гибкий аспект авторизации ASP.NET - это способность программно
торизовать пользователей. Существует три способа выполнения этого задания:
Декларативная авторизация
Императивная авторизация
Эксплицитная авторизация
^тивная авторизация
Р^еви ИВная защита позволяет устанавливать требования к получению раз-
с°быти РОВНю класса, так же как и к индивидуальным методам, свойствам или
И Рис 9 i»7 Т° МОЖно сделать, установив свойство, как показано на рис. 2.16. (С#)
Т°*Ысои ^-NET, где изображены методы, предоставляющие право доступа
ам местной Администраторской группы.
Декларг

100 Глава 2 * Проверка подлинности пользователей
т Рис. 2.16- Декларативная защита: С#
[PrincipalPermissionAttribute(SecurityAction.Demand, Role
"BUILTIN\Administrators")]
public DoSomething
{
}
Рис. 2.17. Декларативная защита: VB.NET
<PrincipalPermissionAttribute(SecurityAction.Bemand, Role:
"BUILTIN\Administrators")>_
Public Sub DoSomething()
End Sub
Преимущество декларативной защиты - в удобной установке разрешений для
избранных членов или для класса как целого, с одним атрибутом. .NET Framework
проверяет декларативную защиту сразу же перед применением метода, до того как
будет запущен первый код.
Императивная авторизация
Декларативная защита позволяет устанавливать разрешения на класс или
отдельных его членов, в то время как императивная защита позволяет вам требовать
разрешения из вашего кода.
I Рис, 2.18. Императивная защита: С#
public DoSomething()
PrincipalPermission ppCheck = new PrincipalPermission (null,"Admin
ppCheck.Demand();
// Admin code
}
*"» Рис. 2.19. Императивная защита: VB.NET
Sub DoSomething()
Dim Perm As New PrincipalPermission(Nothing, "Admins", True

Проверка подлинности пользователей • Глава 2 1
perm. Demand О
// Admin code
End Sub
Эксплицитная авторизация
Т юке как при использовании императивной защиты можно эксплицитно про-
ь на членство роли, используя метод Iprincipal.IsInRole. Существенной разни-
„ меЖду императивной защитой и эксплицитной проверкой роли членства явля-
ТОэ что можно проверить роль членства внутри вашего кода как утверждение
Если-То, без демонстрации исключений при неудачном доступе. Этот метод
полезен например, когда вы блокируете или разблокируете свойства, основанные
на ролях текущих пользователей, как показано на рис. 2.20. (С#) и рис. 2.21. (VB.NET).
Рис.2.20. Эксплицитная авторизация: С#
I .
If (User.IsInRole ("Admins")
{
Response.Write ("<a href=/admin.aspx>Admin Menu </a>") ;
g^ Рис. 2.21, Эксплицитная авторизация: VB.NET
If User.IsInRole ("Admins") then
Response.Write("<a href=/admin.aspx >Admin Menu</a>")
End if
безо °РИзация* основанная на коде, позволяет вам усиливать гранулированную
ЧИю °СТЬ ЧеРез ваше приложение. Для лучшей защиты используйте
комбинатов Декларативной, императивной и эксплицитной авторизации.
Сп°собы защиты
ьзуите декларативную, императивную и эксплицитную проверку ро-
я °^еспечения множественных уровней авторизации.
ни Утилизации .NET Framework внедрите надежные методы декларатив-
Нои авторизации.

102 Глава 2 - Проверка подлинности пользователей
Краткая справка по стандартам кодировании
Аутентификация пользователей
Построение форм регистрации
• Всегда используйте SSL для передачи логинов пользователей.
• Всегда используйте метод HTTP POST для передачи логинов пользовател -
• Все формы ввода должны быть отфильтрованы от SQL-запросов и CSS-aT
• Не полагайтесь на скрытые формы полей при передаче значимых данны
• Используйте одинаковое сообщение об ошибке, как для неверного логина
так и неверного пароля; не обнародуйте никакой другой информации в
сообщениях об ошибке.
Использование форм опознавания
• Если возможно, держите аутентифицированных пользователей на
SSL-соединениях для предотвращения похищения строки с данными о пользователе
• Избегайте хранения сертификатов в файлах web.config или же
используйте хэши MD5 или SHA-1.
• Конфигурируйте web-сайт таким образом, чтобы все защищенные ресурсы
управлялись ASP.NET с использованием отображения обобщения приложения.
Использование аутентификации Windows
• Всегда используйте SSL с основным опознаванием.
• Разделите защищенное и незащищенное содержание и используйте
уникальные области для каждого.
• Защитите привилегированных пользователей от лобовых атак, освобод
их от опознавания.
Использования аутентификации Passport
• Используйте самые надежные из имеющихся в наличии установок за
при использовании паспортного опознавания.
Блокирование лобовых атак
• Внимательно взвесьте все за и против применения политики блокир
ния аккаунтов.

Проверка подлинности пользователей • Глава 2 103
случайные паузы в процесс аутентификации для замедления лобо-
Ф вставьте t у
„ыхатак.
йте форму ответа, как для успешного, так и для неудачного опозна-
• яполя, изменяя статус кода HTTP и текст сообщения об ошибке,
вания пар
швайте у клиентов ответ на секретный вопрос после нескольких не-
• удачных попыток входа в систему.
п оставьте продвинутым пользователям возможность установки ограни-
я ВХода в аккаунт строго с определенных IP-адресов,
ользуйте уникальный URL регистрации для разных групп пользователей.
И пользуйте САРТСНА после определенного количества неудачных
попыток входа.
• Предоставьте возможность выборочного ограничения свойств или
временной приостановки аккаунта без полного выключения пользователя.
Авторизация пользователей
Принятие решения о способе авторизации
• Постройте приложение на основе четко определенных ролей.
• Установите файлы ACL и настройте другие ограничения авторизации так,
чтобы вы смогли идентифицировать эти установки на ранней стадии
авторизации файла.
Авторизация файла
Установите ограничители NTFS-разрешения содержания web-файлов, даже
если вы не используете их, опознавание Windows и файловую авторизацию,
используйте файловую авторизацию для ресурсной и ролевой защиты,
опросите специфичные и детальные NTFS-разрешения для повышения
безопасности приложения.
Применение URL-;
авторизации
туп к конфиденциальным данным всегда начинайте секцию авториза-
% *Ии с <deny users = «?»/>.
щ анх*ивайте авторизацию <deny users = «*»> или <allow users = «*»>.
вы используете свойство операций с разрешенными элементами,
^ Да ставьте его перед элементом deny (отрицание).
^пользуйте HttpForbiddenHandler или HttpNotFoundHandler для блоки-
ия всеобщего доступа к определенным файлам.

Глава 2 * Проверка подлинности пользователей
• Тщательно планируйте иерархию web.config для избежания непредНа
ренного доступа к файлам.
Авторизация пользователей через код
• Используйте декларативные, императивные и эксплицитные проверки
роли для обеспечения множества уровней авторизации.
Краткая справка по проверке кода
Аутентификация пользователей
Построение форм регистрации
• Передает ли форма регистрации данные по безопасным соединениям?
• Используется ли метод HTTP POST или GET?
• Утверждает ли приложение форму регистрации входа?
• Обнаруживает ли форма значимую информацию через скрытые формы полей
• Не слишком ли много информации раскрывает сообщение об ошибке?
Использование форм аутентификации
• Содержит ли файл web.config логины пользователя при наличии более
безопасных вариантов?
• Есть ли в файл web.config логины пользователей в незашифрованном виде
• Использует ли файл web.config безопасные установки для файлов cookies.
Использование аутентификации Windows
• Если вы используете базовое опознавание, зашифрован ли трафик Ьэ
• Позволяет ли разработка web-сайта осуществлять пересылку логинов Р
движении с SSL-страницы на незашифрованную страницу?
• Может ли злоумышленник устроить лобовую атаку против привилегии
ванных аккаунтов?
• Может ли злоумышленник осуществлять лобовые атаки с web-сервер
другие системы?
Использование аутентификации Passport
• Достаточно ли паспортное опознавание подходит для вашего web-c

Проверка подлинности пользователей • Глава 2 105
^рование лобовых атак
живает ли web-сайт блокирование аккаунта?
меняете ли вы меры для замедления лобовых атак?
ашен ли web-сайт какими-нибудь свойствами одурачивания автоматиче-
инструментов лобовой атаки?
пользуете ли вы самые простые способы остановки автоматических
например секретный вопрос или САРТСНА?
Поедоставляет ли приложение установки ограничения доступа к аккаун-
там для продвинутых пользователей?
• Оснащено ли приложение какими-нибудь способами ограничения или
приостановки доступа для аккаунтов, подозреваемых в злоупотреблении?
Авторизация пользователей
Принятие решения о способе авторизации
• Оснащена ли система надежной инфраструктурой с ролевой защитой?
• Используются ли множественные уровни опознавания?
Авторизация файлов
• Каким образом система определяет минимум требований NTFS-разрешений?
• Есть ли на web-сайте файловая авторизация для внедрения как ресурсной,
так и ролевой безопасности?
Запрос авторизации URL
ачинается ли раздел авторизации web.config для защищенного содержа-
ния с отклонения неопознанных пользователей?
канчивается ли этот раздел правилом, что все пользователи получают
ф *ли не получают доступ по умолчанию?
пользуется HttpForbiddenHandler или HttpNotFoundHandler для блоки-
Р°вания всеобщего доступа к определенным файлам?
°ризация пользователей
Рез систему кодирования
• Ис
^^ ьзует ли приложение декларативную, императивную и эксплицит-
Роверку роли для обеспечения многоуровневой авторизации?

106 Глава 2 * Проверка подлинности пользователей
FAQ
цие вопросы пользователей и ответы на них авторов этой книги пп*и.
ике.
Щ
чены как для понимания теории, так и для воплощения концепций на
Если у вас есть вопрос к автору, зайдите на www.syngress.com/solutiong и ще
на форму «Спросить автора». Вы также получите доступ к тысячам других ^
на iTFAQnet.com.
Вопросы (В) и ответы (О)
В: Я сконфигурировал файл web.config для использования форм опознавай
и отклонения неопознанных пользователей, но он не перенаправляет меня в фо
му регистрации, когда я получаю доступ к защищенному содержанию.
О Г Проверьте свойства приложения в Inetrner Service Manager и убедитесь
что доступ анонимного пользователя заблокирован. В противном случае
IIS не будет предпринимать попыток аутентификации пользователя.
В: Могу ли я использовать событие Application_OnAuthenticateRequest вместо
HTTP-модулей, рассмотренных в этой главе?
О: Нет никакой нео6хсщщш£Ти в создании модуля HTTP для управления
событиями ASP.NET. Вы также можете добавить манипуляторы событий в global.asax.
Модули HTTP очень схожи с бинарными версиями global.asax.
В: Мой web-сайт настроен на Windows-аутентификацию, и когда я ввожу верный
пароль, он запрашивает меня о повторном вводе пароля.
О: На самом деле причин может быть несколько. Во-дарвых, убедитесь, что вы
включили форму с именем пользователя в виде домен\логин или локальная сист
ма\логин. Также проверьте, имеет ли аккаунт пользователя, который вы исполь
ете, NTFS-разрешения для доступа к web-содержанию.
В: Какая разница между различными манипуляторами HTTP-ошибок, та
как HttpMethodNotAllowedHandler и HttpForbiddenHandler?
0а. Разница заключается в том, какой HTTP-статус кода он прись- ^
HttpForbiddenHandler выдает сообщение 403, HttpNotFoundHandler возвра <
сообщение 404, HttpMethodNotAllowedHandler выводит сообщение
a HttpNotlmplementedHandler присылает сообщение 501.
В: Уязвим ли ASP.NET против атак переполнения буфера? ^д.
О: Управляемые коды обычно не уязвимы против атак переполнения ^
но это не означает, что вы в полной безопасности. Поскольку по ^
проверенный код обладает способностью вызова неуправляемого к0<д

Проверка подлинности пользователей * Глава 2
внешние компоненты или вызовы Windows API, риск переполне-
го *е? все же есть. Всегда соблюдайте меры предосторожности и прове-
ния yv стр0ки при вызове неуправляемых кодов. Также убедитесь, что
^ЯЙ е код с низко привилегированным аккаунтом, и используйте жест-
3 ничения NTFS для ограничения прав доступа к файловой системе.
К ео откажите web-пользователям в доступе к файлам вне содержания
web-директорий.

—-^ГТ"
Глава 3
г
Гщттщп
4>¥А- U
Решения в этой главе:
□ Состояние поддержки
U Использование маркеров ASPJIIST
ч/1
%щ
/$
' ^$"
*#*«
*-&
'•'Ч\ "~Ъ. 4?'
С*"-**' *" ' ' у
Краткая справка по стандартам
кодирования
Краткая справка по проверке кода
FAQ

Глава 3 • Управление сессиями
Введение
Зачастую обеспечение безопасности аккаунта пользователя
от продолжительности сеанса связи. Так как HTTP является беспроводны Иг
токолом, установка форм длительности сеанса обычно зависит от web-па-*
т-г * °*Рабоь
чика. Пользователи обычно просматривают множество страниц с разнь
держанием. Попадая изначально на одну страницу, они затем переходят н
гую страницу и так далее, пока не закончат просмотр всего web-сайта. После
го клиенты либо закрывают обозреватель Интернет, либо оставляют его отк
тым и продолжают просмотр других web-сайтов. Непрофессионал считает
это продолжительный сеанс связи с одним web-сайтом. На самом деле дело ofi
стоит совсем иначе.
Для каждого посещения страницы обозреватель Интернет отправляет
несколько запросов на сервер для получения элементов, необходимых для
отображения страницы в окне обозревателя. После отображения этих элементов
клиент прекращает связь с сервером. При загрузке следующей страницы
обозреватель повторяет процесс, но для сервера этот запрос никак не связан
с предыдущим.
Поэтому серверу необходимо создать уникальный маркер, представляемый
обозревателем с каждым посещением для указания сеанса, к которому он
относится. Маркер - определяющая строка, уникальная для каждого сеанса. Используя эти
маркеры сеансов, сервер будет воспринимать серию несвязанных запросов, как
если бы они были одним продолжительным соединением.
Сервер может присваивать два основных типа маркеров:
■ Маркеры сеансов
■ Маркеры опознавания
Маркеры сессий
Маркеры сессий создают непрерывность между запросами HTTP. Они
кают с отправкой первого запроса клиента на сервер и заканчивают свое де
либо с закрытием клиентом обозревателя Интернет, либо по истечении ^
ленного промежутка времени. Маркеры сеансов чаще всего устанавлива
рез файлы cookies, как сеансовые или устойчивые файлы cookies, и зачаст)
матически управляются сервером приложения. Цель маркера сессии - ^.
вать взаимодействие между клиентом и сервером для обеспечения видим
прерывного соединения. „ 0$>
Программисты применяют маркеры сессий для установки предпочте ^ И
зователей, прослеживания нестабильных сессий, соединения множества
фор»

Управление сессиями • Глава 3 111
а подобного списку покупок. Маркеры сессий обычно принимают
созД311 „ Cookies, так как это самый удобный метод хранения информации
0клие гргсий должны быть защищены, но безопасность обычно не являет-
Маркеры сс
енным моментом управления маркером.
Маркеры опознавания
п е того, как пользователь прошел проверку легальности на сервере, сервер
маркер аутентификации, который можно представлять с каждым запро-
подтверждения своей идентичности. Так выявляется аутентифицирован-
" пользователь. Важно отметить, что маркер аутентификации почти так же зна-
как и действительные логины пользователя, с тем лишь исключением, что
у маркера аутентификации короткий период существования.
Очень важно проводить различия между маркерами сеанса и аутентификации.
Разделяя их, вы сможете лучше оптимизировать установки для каждого
и ограничить подверженность некоторым типам атак. Например, можно
использовать встроенные свойства управления ASP.NET для маркеров сессий
и использовать более продвинутые методы аутентификации маркеров.
Для обеспечения безопасности маркер должен обладать определёнными
свойствами, а именно:
■ Идентифицировать клиента на сервере
Не пользоваться аккаунтом за пределами приложения
Находиться в индивидуальном доступе
этой главе мы рассмотрим способы защиты маркеров сеанса и
аутентификации в приложении ASP.NET.
°нимание опасностей
типы опасностей, угрожающие маркерам, рассмотренные в данной главе:
Щение маркера. Возможность получать доступ к маркеру другого
вателя и потенциально получать доступ к аккаунту пользователя.
* С
д УЩии аккаунт. Манипуляции существующим маркером для получения
к аккаунту другого пользователя.

Глава 3 • Управление сессиями
■ Фиксация сеанса. Обеспечение другого пользователя известным
фиксированным маркером для аутентификации и дальнейшего получения доступа
к сеансу пользователя.
■ Вычисление маркера. Угадывание или вычисление действующего маркера
сеанса, поскольку схема маркера использует последовательные и
предсказуемые шаблоны.
■ Лобовые атаки на маркеры. Вычисление действующего маркера сеанса
перебором всех возможных комбинаций в ключевой области маркера.
■ Поддержание существования маркера. Процесс периодической отправки
web-запросов для предотвращения истечения срока действия; часто
используется с атаками фиксации сессий.
■ Манипуляции маркерами. Изменение маркера в URL или файле cookies
для получения несанкционированного доступа к приложению.
■ CSS-атака. Атака, включающая ввод HTML или скриптинговых команд во
вверенное приложение с целью похищения пользовательского файла
cookies, маркера сеанса или логинов аккаунта.
■ Утечка информации. Форма атаки «Человек-в-середине», при которой
злоумышленник провоцирует реального пользователя ввести пароль в
подложный e-mail или web-форму, внешне не отличимую от настоящего web-
сайта.
Трудно разработать схему, при которой вы будете полностью уверены, что
маркер поступает от реального пользователя, а не от злоумышленника. Например, У
пользователя должен быть действительный маркер, но он может быть прислан
хакером, каким-то образом вычислившим маркер. Вам необходимо определить,
пришел ли маркер с того самого IP-адреса, к которому вы «привязали» маркер, но он
может прийти и не с пользовательского компьютера, поскольку этот IP-адрес мо
жет быть брандмауэром или общим сервером-посредником. Если вы все же считз
ете, что запрос пришел с пользовательского компьютера, совсем не обязательно-
что он пришел действительно от пользователя. Но даже если вы уверен
и в этом, его источником может являться Троян, вирусы или «червь». И еще ост
ется вариант, что пользователь вовсе не хотел отправлять его вам, но стал ясеР
вой CSS-атаки. В конечном счете, вы даже не можете знать наверняка, с реальны
ли пользователем вы имеете дело; это может быть кто-то, кто знает логин или **
пользует обозреватель Интернет пользователя, ушедшего на обед.

Управление сессиями • Глава 3
Используя современные технологии, вполне возможно создать механизм,
оактически полностью отвечающий этим пунктам, но тогда возникают вопросы
овместимости, принятия пользователя, развертывания, подготовки пользовате-
обучения разработчиков и поддержки инфраструктуры. Поэтому большинство
web-приложений использует уязвимые схемы маркеров. В этой главе будут рассмо-
тоены способы обеспечения безопасности строк с данными о пользователе.
Поддерживающая структура
ASP.NET очень упрощает процесс управления маркерами обоих типов.
Разработчик может использовать свойства управления сеансами ASP.NET по умолчанию
или расширить их для обеспечения более надежных и безопасных свойств
маркеров управления. В этом разделе мы рассмотрим:
■ Разработку безопасных маркеров
■ Выбор механизма маркера
■ Использование провайдеров состояния
Разработка безопасного маркера
Исходное положение: Чтобы быть безопасным, маркер должен
соответствовать определенным критериям
Угроза: Перехват сеансов, похищение аккаунтов,
фиксация сеанса, утечка информации.
Разработчики внедряют в свои web-приложения маркеры сеансов и
аутентификации, использующиеся длительное время. Однако недостаток понимания управле-
Ия сеансом приводит к компрометации многих web-сайтов. Очень важно обеспе-
Ть защиту маркеров сеансов, но еще важнее сохранить маркеры аутентификации.
^Ля п°Дтверждения безопасности маркер аутентификации должен пройти ряд про-
Р°к, которые будут рассмотрены в общих чертах в следующих разделах.
*\ак тесно связан маркер с сессией пользователя?
то наиболее распространенная ошибка программистов, часто позволяющая
УМышленникам похищать сессии других пользователей, манипулируя марке-
• большинство маркеров не привязано к конкретным пользователям посколь-
Редиолагается, что обладание маркером есть доказательство права собствен-
001,11 на него.

Глава 3 • Управление сессиями
Безопасен ли способ передачи маркеров
от сервера к клиенту?
Это означает использование SSL и протокола IPSec для шифрования при
отправке маркера. Если трафик не зашифрован, маркер будет видимым для других.
Когда вы используете файл cookies, важно пометить его как безопасный, так,
чтобы обозреватель Интернет клиента управлял им правильно.
Достаточно ли велико используемое приложением
ключевое пространство?
Для предотвращения лобовых атак на маркер сеанса он должен быть
достаточно большим, чтобы злоумышленник не смог легко воспользоваться
действительным маркером. Например, 128-битовое число 340 282 366 920 938 463 374 607 431
768 211 456 (или 2128) возможных уникальных маркеров сеансов.
Достаточна ли мощность генератора случайных
чисел, используемого приложением?
Надежный генератор случайных чисел гарантирует использование доступного
ключевого пространства непредсказуемым способом. Компьютеру очень сложно
генерировать действительно случайное число, но генераторы псевдослучайных
чисел не позволяют легко производить одно и тоже число дважды.
Создает ли приложение новый маркер
для каждого соединения?
Пользователь никогда не сможет восстановить сеанс со старым маркером.
При каждой аутентификации пользователя всегда удаляйте старые маркеры и
начинайте новый сеанс с новым.
Примет ли система любой маркер клиента?
Если система принимает предоставленный клиентом маркер, она будет уязв
мой для так называемой атаки фиксирования сеанса. При использовании этого
да атаки злоумышленник отправляет жертве URL, содержащий маркер сеан
Жертва щелкает кнопкой мыши на URL и вводит свои сертификаты входа, ак
вируя сеанс. После этого хакер заходит на web-сайт, используя тот же ID сеанс
получает доступ к аккаунту пользователя. Вы не только должны отклонять та
маркеры, но и регистрировать их как попытку взлома.

Управление сессиями * Глава 3
^[ожет ли пользователь управлять маркером
для перехода на другой аккаунт?
Многие web-приложения используют незащищенные маркеры сеансов, кото-
ie при изменении позволяют хакеру переходить на аккаунт другого аутентифи-
пированного пользователя. Маркер всегда должен быть привязан к
определённому аккаунту и сеансу, и необходимо избегать последовательных и предсказуемых
маркеров сеанса.
Может ли приложение распознать измененный
или недействительный маркер?
Для того чтобы предотвратить изменение маркера в целях использование
приложения, система должна быть способна распознавать любые отклонения от
первоначального состояния. Приложение должно идентифицировать маркер,
измененный пользователем с помощью цифровой подписи или хэша маркера.
Идентифицирует ли маркер клиента?
Маркер всегда должен быть случайным числом, которое ни в коем случае не
идентифицирует клиента. Случайное число должно быть образовано генератором
и хранится на сервере в соответствии с ID пользователя. Когда клиент
предоставляет маркер серверу, сервер проверяет сеанс и идентифицирует клиента.
Ограничивает ли маркер свои рамки?
Приложение должно ограничивать маркер определенными рамками
приложения для предотвращения выхода клиента за рамки безопасности или
непреднамеренной передачи маркеров пользователей через незащищенные соединения. Это
°бенно важно в отношении файлов cookies при их пересылке с защищенных
Раниц на незащищенные. Такой метод помогает избежать атаки похищения
Kles с серверов с таким же именем домена.
бладает ли маркер одновременно относитель-
ьщ и абсолютным сроком действия?
аркер может просуществовать еще очень короткий промежуток времени после
^ а п°льзователя. Поскольку клиенты могут оставлять маркер активным неограни-
^ количество времени, необходимо установить абсолютное время истечения сро-
^^ ствия маркера. В этом случае вся информация, относящаяся к маркеру, должна
Уничтожена и должен быть установлен новый маркер, если сеанс все ещё активен.

Глава 3 * Управление сессиями
Сохраняет ли клиент маркер после завершения
сеанса связи?
Это проблема, поскольку пользователь может заходить на аккаунт с общего
компьютера. Обозреватель Интернет клиента сохраняет постоянные файлы
cookies, историю URL и хэши посещаемых страниц, создавая тем самым проблему для
всех типов маркеров.
Есть ли у пользователя опция завершения сеанса?
Хотя сеанс, в конце концов, истечет сам собой, пользователи должны обладать
опцией завершения сеанса. Если клиент сам завершает сеанс, вся информация,
касающаяся этого сеанса, должна быть стерта. Также очень важно уничтожать
старые сеансы тех пользователей, которые могут остаться в базе данных.
Можете ли вы удалить маркер с сервера?
Иногда (в целях безопасности) возникает необходимость в аннулировании
одного или всех сеансов. В обоснованности этого действия маркер полагается на сервер.
Например, при задействовании встроенных маркеров ceaHcaASP.NET сервер может
только определить, был ли маркер установлен на основе его хэша, но, поскольку
сервер не поддерживает список сеансов, он не может аннулировать маркер.
К сожалению, только несколько схем маркеров отвечают всем этим
критериям, и даже протокол HTTP не может полностью соответствовать им Каждый
метод имеет свои слабые стороны, поэтому идеального варианта не существует.
Способы защиты
■ По возможности используйте дополнительные меры для привязывания
маркера к сеансу клиента.
■ Старайтесь передавать маркеры, используя SSL.
■ Всегда задействуйте достаточно большое ключевое пространство для мар*
керов сеансов.
■ Обязательно используйте надежный генератор случайных чисел для мар'
керов сеанса.
■ Никогда не принимайте новые маркеры, представленные клиентом.

Управление сессиями • Глава 3 117
щ Ни в коем случае не включайте в маркер идентификационную
информацию пользователя в формате обычного текста.
Ш Всегда ограничивайте рамки маркера текущим приложением.
Ш Используйте как относительные, так и абсолютные ограничители
времени для маркеров.
Ш Примите меры по предотвращению хранения клиентом маркера сеанса
после его завершения.
■ Предоставьте пользователям опцию самостоятельного завершения сеанса.
■ Устанавливайте новый маркер при каждой регистрации сеанса.
Выбор механизма маркера
Исходное положение: Проведите тщательный выбор механизма маркера
для обеспечения лучшей защиты пользователей.
Угроза: Похищение сеанса, похищение аккаунта,
фиксация сеанса, утечка информации.
Маркеры, основанные на URL
Маркеры, основанные на URL, существующие на URL как часть его пути или
как часть строки запроса, как показано на примере:
http: //www.example.com/inbox.aspx?sessionID=6861636B696E67746865636F6465
http: //www.example.org/user.aspx?sid={6861-636B-696E-6774-6865-636F-6465}
http://www.example.net/ (o51mpx45ylxps255o3bxzoib) /Default.aspx
Зтот метод, возможно, самый распространенный, так как обладает наиболее
уникальной совместимостью. Недостаток его заключается в том, что со стороны очень
*Х)сто вычислить ваш маркер сеанса. Маркер может появиться в истории или в хэше
3Ревателя Интернет или его может зарегистрировать любой промежуточный сер-
г посредник или фильтр. Его могут вычислить те, кто знает, что он не защищен SSL,
УД£т появляться как передатчик при нажатии на ссылки на другие web-сайты,
ели вы используете маркеры, основанные на URL, существует также риск то-
о клиенты совместно используют, копируют URL или ставят на них закладки
*Ц-, содержащие маркеры сеанса. Ещё одна проблема - это то, что они более
Риимчивы к атакам фиксации сеанса, потому что злоумышленнику проще от-

i Глава 3 * Управление сессиями
править вам URL, уже содержащий маркер сеанса. (Более подробное описание
атак фиксации маркера будет предложено далее в этой главе).
Маркеры, основанные на файлах cookies
Еще один известный метод - это использование HTTP механизма cookies.
Многие обозреватели Интернет поддерживают cookies, но некоторые пользователи
блокируют их в силу причин секретности или потому, что рассматривают их как
угрозу безопасности. Но подавляющее большинство web-сайтов требует
использования cookies для аутентификации. Аргумент по поводу секретности здесь
недостаточен, поскольку пользователи уже идентифицируют себя, вводя сертификаты.
Файлы cookies более безопасны, чем другие методы, по следующим причинам:
■ Они пересылаются как часть тела письма, которое редко хранится в
файлах регистрации.
■ Файлы cookies сеанса не сохраняются в обозревателе Интернет сеансов
(если только не отмечены как постоянные).
■ Они обладают встроенными механизмами истечения срока, рамок
действия и использования безопасных соединений.
Однако cookies не гарантируют иммунитет против атак похищения сеансов. При
пересылке cookies без использования SSL они очень уязвимы против атак
пассивного прослушивания сети и «Человек-в-середине», и злоумышленник вполне сможет
физически похитить cookies, если у него есть доступ к компьютеру пользователя. В
Сервисном Пакете 1 Internet Explorer 6 Microsoft предложил HttpOblyCookie для
остановки атаки похищения cookies определенного типа, но не решил эту проблему
полностью. Большинство проблем, связанных с cookies, возникают в силу слабых
методов защиты и недостаточности разработок. Ниже в этой главе мы рассмотрим
способы настройки и использования cookies для маркеров аутентификации.
Формы аутентификации ASP.NET включают в себя маркеры, основанные на
cookies, но при этом предлагают варианты кодировки и подтверждения маркеров сеанса.
Маркеры, основанные на форме
Некоторые web-сайты содержат маркеры в формы HTML как скрытые поля-
При переходе на следующую страницу обозреватель Интернет представляет мар
кер сеанса в теле запроса. Ниже приведен пример использования маркера в пол
скрытой формы
<INPUT TYPE = "hidden" NAME = "sessionID"
VALUE = "686163B696E6774686563F6465" >

Управление сессиями * Глава 3
Защита скрытых форм полей приблизительно такая же, как и у cookies, но она
представляет такого же многообразия свойств, как для cookies.
ASP.NET предлагает основанный на форме механизм ViewState, который рас-
йряет метод скрытых форм полей для включения в него шифрования и установ-
ения более структурированного хранения. ViewState ликвидирует некоторые
поблемы маркеров, основанных на форме, но все же не представляет собой иде-
льного решения. Позже в этой главе мы вернемся к рассмотрению ViewState и
некоторых других методов обеспечения безопасности.
Основным препятствием здесь выступает то, что ни один их этих методов
управления не был разработан конкретно для безопасности маркеров управления, и ни один
из них сам по себе не соответствует в полной мере этой цели. Ни один из
перечисленных приемов не дает надежной защиты и свойств обеспечения секретности, требуе-
мьк для конфиденциальных web-приложений. Ещё хуже, то, что, хотя SSL
компенсирует многие из этих ограничений, многие web-сайты до сих пор не применяют его, и
только в очень редких случаях можно видеть, что web-сайты удаляют логины клиентов.
Способы защиты
■ При использовании маркеров, основанных на URL, должны быть
приняты меры по привязке маркера к клиенту сеанса.
■ При работе с маркерами, основанными на cookies, убедитесь, что следуете
всем руководствам по безопасности.
• По возможности используйте SSL для помощи в защите аутентификации
маркеров.
Использование индикаторов состояния
Исходное положение: Обеспечьте надежную защиту выбранного
провайдера
Угроза: Перехват сеансов, похищение аккаунтов,
фиксация сеансов, утечка информации
^P.NET предлагает три способа хранения состояния сеанса на сервере: в про-
Ссе ASP.NET Service Status или сервер SQL. Какой из этих методов вам лучше все-
°ДХодит, определяется в зависимости от требований надежности и масштабно-
• Структура управления «в процессе» схожа с тем, что было доступно с IIS5 и
» Ссическим ASP. Эта структура управляется местно рабочими процессами
-JNET. Это самый быстрый из трех предложенных методов, но в случае переза-
*ь US или web-приложения вся информация сеанса будет потеряна. ASP.NET

20 Глава 3 * Управление сессиями
Service Status - это внешний сервис, который сохраняет состояние даже в случае
перезапуска IIS и может использоваться несколькими клиентами. Можно запус.
тить ASP.NET Service Status на локальном или удаленном компьютере. Структура
управления SQL-сервера - наиболее масштабируемое и надежное решение, но оно
работает медленнее других, и его сложнее всего настраивать.
Структура «в процессе»
Для отладки местной структуры управления требуется много усилий, но
существуют несколько обязательных шагов. Настройте файл web.config следующим образом:
<sessionState
mode="InProc"
cookieless="false"
timeout="15"
/>
Если вы используете структуру управления «в процессе», убедитесь, что вы
заблокировали ASP.NET Service Status с помощью Service Administrative tool. Если у
вас стоит Windows Server 2003, его также можете через эту команду:
C:\>sc config aspnet_state start= disabled
Структура ASP.NET Service Status
ASP.NET Service Status - это, в сущности, миниатюрный HTTP-сервер, который
управляет структурой сеанса PUT и GET. Рис. 3.1. демонстрирует пакет ввода типа
трафика, отправленного ASP.NET на сервис.
Рис 3.1. Пакет ввода ASRNET Service Status
***АР*** Seq. 0xE6F3358D Ack: 0X85F6237 Win: 0x4470 TcpLen: 20
0x0000
0x0010
0x0020
0x0030
0x0040
0x0050
0x0060
0x0070
0x0080
00 DO B7 8F 6A F0 00 A0 24 Еб 4C 8E 08 00 45 00 ... .j...$.L.--E
00 ED 0A 66 40 00 80 06 DA 97 0A 55 00 63 0A 55 ...f@ V-C'V
00 01 08 72 00 50 E6 F3 35 8D 08 5F 62 37 50 18 ...r.p. .5. .J>7f
44 70 CA El 00 00 50 55 54 20 2F 2F 4C 4D 2F 57 Dp...PUT /A^7
33 53 56 43 2F 31 2F 52 6F 6F 74 2F 73 74 61 74 3svc/l/root/s^z
65 2F 46 6F 72 6D 73 28 52 79 6A 6B 41 63 46 59 e/Forms (Ry]^ *
58 42 70 37 2B 4D 52 78 45 64 70 68 78 64 6E 41 XBp7+MRxEdpb*dn'
50 36 63 3D 29 2F 74 76 6C 64 77 74 79 33 79 34 P6c=)/tvldtfty3^
64 79 76 6E 6E 61 32 6E 73 33 76 32 35 35 20 48 dyvnna2ns3v255"

Управление сессиями • Глава 3 121
ОК0090
ОХООАО
охоово
охоосо
OxOODO
ОхООЕО
OxOOFO
54 54 50 2F 31 2Е 31 0D ОА 48 6F 73 74 ЗА 20 31 ТТР/1.1. .Host: 1
30 2Е 38 35 2Е 30 2Е 31 0D ОА 54 69 6D 65 6F 75 0.85.0.1..Timeout
74 ЗА 32 30 0D ОА 43 6F 6Е 74 65 6Е 74 2D 4С 65 t:20. .Content-Le
6Е 67 74 68 ЗА 33 34 0D ОА 4С 6F 63 6В 43 6F 6F ngth:34. .LockCoo
6В 69 65 ЗА 30 0D ОА 0D ОА 14 00 00 00 00 01 00 kie:0
01 00 00 00 FF FF FF FF 08 54 65 73 74 49 74 65 Testlte
6D 01 07 57 6F 6F 68 6F 6F 6F FF m..Woohooo.
Недостаток программы ASRNET Service Status состоит в том, что она использует
незашифрованные и неаутентифицированные соединения с web-сервером или с кем-
то ещё, кто может достичь открытого порта. К сожалению, сервис имеет
ограниченные способности блокирования IP-адресов. Фактически, все, что он может сделать -
это разрешить или запретить все внешние соединения через недокументированные
установки регистрации. Это вполне допустимо, если вы используете ASRNET Service
Status только на одном компьютере, но не более того. Если вы запускаете программу
для одного местного web-сервера, можно установить ключ следующим образом:
■ Ключ: HKEY_LOGAL_MACHINE\SYSTEM\CurrentControlSet\Services\
aspnet_state\Parameters\
■ Значение: Допускает Удаленное Соединение
■ Тип: DWORD
■ Установки: 0 для блокирования удаленных соединений, 1 для разрешения
удаленных соединений
Для эффективного контроля за доступом к этому сервису вам нужно сконфигурировать
фильтр внешнего пакета или использовать Шкгравила для ограничения (и шифрования)
трафика только к авторизованным серверам. Вы также можете установить скрытый порт для сер-
^^ чтобы затруднить его обнаружение. Можно сделать это при помощи следующих действий:
■ Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
^rvices\aspnet_state\Parameters\
* Значение: Порт
11 Тип: DWORD
Установки: Любой неиспользованный номер порта от 1 до 65535

Глава 3 * Управление сессиями
Подсказка
Если вы меняете порт прослушивания по умолчанию, необходимо убедиться, что
вы внесли те же изменения и в файл web.config.
Для настройки ASP.NET на использование сервиса состояния пропишете
в файле web.config следующие установки:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=10.185.0.31:3104"
cookieless="false"
timeout="15"
/>
Если вы хотите и дальше скрывать расположение и порт сервиса состояния,
можно зашифровать строку соединения и сохранить её в журнале
с aspnet_setreg.exe (см. http;//support.microsoft.com/detault.aspx?scid s 329290).
Для использования этого инструмента введите следующую команду:
С:\>aspnet_setreg -k:Software\YourApp\State
-d:stateConnectionString="tcpip=10.185.0.31:3104"
После этого поменяйте свойство stateConnectionString в файле web.config на
следующее:
stateConnectionString
="registry:HKEY_LOCAL_MACHINE\SOFTWARE\YourApp\State\ASPNET_SETREG,
stateConnectionString"
Метод SQL-сервера
Чтобы использовать SQL-сервера для управления состоянием сеанса внесите
следующие изменения в файл web.config:
<sessionState
mode="StateServer"
sqlConnectionString="data
source=10.185.10.4;Trusted_Connection=yes"
cookieless="false"
timeout="15"
/>

Управление сессиями • Глава 3
Сконфигурируйте также SQL-сервер с соответствующими таблицами для со-
оанения состояния сеанса. Для получения более подробной информации смотри-
kttp^/support.vicrosoft.com/Pscid = 317604.
После конфигурации таблиц SQL-сервера создайте на базе данных новый акка-
^х с низкими привилегиями, посвященный состоянию управления. Так же как
в случае с конфигурацией сервиса состояния, можно использовать aspnet_setreg.exe
лля шифрования строки соединения базы данных:
c.\>aspnet_setreg -k:Software\YourApp\State
-d: sqlConnectionString="datasource=10.185.10.4;Trusted_Connection=yes"
После этого измените свойство SqlConnectionString в файле web.conflg на
следующее:
sqlConnectionString="registry:HKEY_LOCAL_MACHINE\SOFTWARE\YourApp\State\
ASPNET_SETREG, SqlConnectionString"
Более подробная информация по безопасным соединениям базы данных
представлена в Главе 6 «Доступ к данным».
Основные установки
Опция «без использования cookie» указывает на добавление маркера сеанса
а не на использование cookie сеанса. Некоторые дефекты маркеров сеансов
ASP.NET делают их непригодными для использования на URL. ASP.NET примет любые
синтаксически правильные маркеры и, следовательно, уязвима для фиксации сеансов,
ина также не предполагает шифрования или хэширования для проверки
происхождения маркера и его возможной модификации. Маркеры, основанные на cookie, создают
такие же проблемы, но их легче контролировать. Для состояния ceaHcaASP.NET
использует cookie сеанса, поэтому обозревателю Интернет не приходится сохранять этот соок-
1е на диске.
Значение срока действия - это время в минутах, в течение которого маркер ос-
^ся активным. Установите минимальное значение, если это будет целесообраз-
Для уменьшения вероятности атак перехватывания сеансов в вашем случае.
Способ
ы защиты
Если вы не используете ASP.NET Service Status, удалите эту опцию из
инструментов администратора сервиса.

Глава 3 • Управление сессиями
■ Если вы используете сервис, установите ключ регистра Разрешить Удаленное
Соединение, если эта опция применяется только для управления местной системой.
■ Если вы используете сервис состояния с множеством серверов, задействуйте
IPSec или другой механизм фильтрации пакетов для ограничения доступа к порту.
■ Установите стандартный порт с сервисом состояния.
■ При использовании сервиса состояния или сервера SQL всегда
зашифровывайте строку соединения при помощи aspnet_setreg.exe.
■ Избегайте внедрения маркеров «без использования cookie».
■ Установите короткий тайм-аут, соответствующий вашему приложению.
Использование маркеров ASP.NET
После установки метода слежения и управления состоянием вы можете
сфокусировать внимание на специфике управления состоянием. Ни cookie, ни URL
не разработаны специально для безопасной передачи сеансов или аутентифици-
рованных маркеров, однако существует несколько методов защиты их от атаки,
которые можно применить.
Использование cookies
Исходное положение: Разработка cookies не предусматривает их
защиту, однако при помощи тщательной
конфигурации вы сможете защитить их.
Угроза: Перехват сеанса, похищение аккаунта,
фиксация сеанса, утечка информации.
HTTP cookies - это механизм хранения состояния пользователя для создания
эффекта беспрерывного соединения с web-сервером. Cookies были разработаны
с целью управления пользовательскими предпочтениями и отслеживания пере'
менных сеанса, и они хорошо с этим справляются. Но когда вопрос касается
безопасности, возникают проблемы. Многое в спецификациях зависит от серве
ров, обозревателей Интернет клиента, а также любых промежуточных nocpe#
ников в выполнении процедур. К сожалению, дело не всегда в этом. Более того-
нет никаких требований к пользовательскому агенту даже для принятия cookie •
Обычно для сохранения cookies с ASP.NET вы пользуетесь метод0*
RESPONCE.COOKIES. Однако ASP.NET автоматически пишет cookies без напйса'

Управление сессиями • Глава 3 125
ййЯ вами кода. Если вы блокируете состояние сеанса, ASP.NET создает cookies-
Лайл сеанса с уникальным маркером для каждого пользователя, подсоединенного
серверу. Если вы используете формы аутентификации с использованием
cookies, ASP.NET также добавляет опознавательный маркер к этому файлу cookies.
Для получения доступа к этим cookies можно использовать метод
rESPONCE.COOKIES для формальной аутентификации cookies, объект Forms-
AuthentificationTicket обеспечивает доступ к свойствам cookies, а также к другим
свойствам, связанным с формами аутентификации.
Cookies всегда будут в какой-то степени уязвимы, но некоторые установки
могут ограничить эту уязвимость. Свойства, оказывающие влияние на защиту:
■ Домен
■ Путь
■ Сроки действия
■ Защита
■ Значение
Домен cookie
Дополнительное свойство домена cookies определяет, какие серверы могут
получать доступ к информации в cookie. Если это свойство не установлено,
предполагается, что обозреватель Интернет разрешит доступ только к хосту, с которого
пришел cookie. Однако вы, возможно, захотите определить это значение.
Домен cookie разрешает доступ ко всем хостам, которые соответствуют
имени домена, включая все подобласти. Другими словами, соответствие
устанавливается справа налево, таким образом, домен cookie, установленного на
example.com, будет соответствовать *.example.com. Имя домена должно содер-
ать минимум две точки для предотвращения установки доменов вроде .com.
Подайтесь быть как можно точнее на домене. Например, если у вас хост с именем
•cker.org, вы настроили домен cookie на .cker.org, хосты cra.cker.org, atta.cker.org,
Just.about.any.script.kiddie.ha.cker.org могут получить доступ к cookie. Это очень
^но, поскольку хакер может обнаружить дефекты и взломать эти системы для
лучения доступа к cookies из намеченной системы. На рис. 3.2. и 3.3. показаны
°собы настройки домена на все cookies.
Кроме предоставления специфического имени хоста, вы, возможно, захотите
сверить домен cookie, который вы получили. Скажем, к примеру, что хост
"cker.org устанавливает свойство домена на ro.cker.org. Однако хост ha.cker.org ус-

126 Глава 3 • Управление сессиями
танавливает свойство домена на .cker.org. Теперь, предположим, пользователь
переходит на ha.cker.org, и сервер отправляет cookie сеанса с таким заголовком:
Set - Cookie: ASP.NET_SessionId=nkih5piv3zdeuc55xj2np555; domain=.cker.org.
Теперь пользователь переходит на ro.cker.org, и обозреватель Интернет
определяет, что хост ro.cker.org соотвествует домену .cker.org, поэтому он отправляет
назад cookie, полученный cha.cker.org:
Cookie: ASP.NET_SessionId=nkih5piv3zdeuc55xj2np555;
Ro.cker.org сервер не проверяет домен и просто разрешает доступ к cookie.
Этот пробел может спровоцировать сервер на ряд атак, включая такие, как
фиксация сеанса, перескакивание аккаунта и манипуляции маркерами. Для
предотвращения этого типа атаки всегда проверяйте домен cookie, как показано на рис. 3.2.
(С#) и рис. 3.3. (VB.NET). Обратите внимание, что перед тем, как установить
домен на все cookies, как показано на рис. 3.2. и 3.3., вам всегда нужно приводить
в действие подтверждение кода, рис. 3.4. (С#) и рис. 3.5. (VB.NET).
Рис. 3.2. Установка домена на все cookies:C#
private void settingTheDomainOnAHCookies ()
{
foreach (string key in Response.Cookies.Keys)
{
Request.Cookies[key].Domain = "te.st.ing";
Рис. 3.3. Установка домена на все cookies :VB.NET
Private Function settingTheDomainOnAllCookies()
Dim key As String
For Each key In Response.Cookies.Keys
Request.Cookies(key).Domain = "te.st.ing"
Next
End Function

Управление сессиями • Глава 3
-1 рис 3-4- Проверка домена cookies:C#
^.
ivate void verifyingTheCookieDomain()
{
foreach (string key in Response.Cookies.Keys )
{
HttpCookie cookie = Request.Cookies[key];
if (cookie.Domain != "te.st.ing")
Cookie.Expires = DateTime.Now.AddYears(-1);
}
}
}
Рис- З.5. Проверка домена cookies:VB.NET
Private Function verifyingTheCookieDomain()
Dim key As String
For Each key In Response.Cookies.Keys
Dim cookie As HttpCookie = Request.Cookies(key)
If cookie.Domain <> "te.st.ing" Then
cookie.Expires = DateTime.Now.AddYears(-1)
End If
Next
End Function
Путь cookies
Так же как и у домена, у cookies есть свойство пути для ограничения области
Действия. После прохождения проверки домена сервер проверяет путь cookie.
Уть согласовывается слева направо до совпадения с любым путем или путями ни-
е его. Таким образом, если вы устанавливаете путь как «/» (косая черта), cookies
прашивается на всех путях на сервере. Путь /shopping ограничивает cookies все-
пунктами в директории shopping и ее подкаталогах.
Устанавливайте путь как можно конкретнее, поскольку обозреватель Интер-
^ отправляет cookie на все URL, соответствующие пути. Сузив область дейст-
я» вы предотвратите нежелательную отправку cookie через обозреватель Ин-
РНет, например на страницы, не оснащенные SSL. Это также поможет оградить

128 Глава 3 • Управление сессиями
от CSS-атаки, если злоумышленник обнаружит дефект в одной из частей прилож
ния. Например, у вас есть приложение, доступное только для членов www.exani
ple.com/protccted/, но предлагающее демонстрационное приложение, котоп
может увидеть любой пользователь, зайдя на www.example.com/demo/. Тепеп
представьте, что кто-то, просматривая эту демонстрацию, обнаружит дефект CSS
позволяющий похитить аутентификационных cookies всех клиентов
В этом примере установка специальных путей cookies для защищенных и
демонстрационных директорий, скорее всего, оградит от подверженности атаке,
поскольку для использования дефекта против действительных членов понадобится
получить доступ к этой защищенной директории, в то время как доступ к
демонстрационному приложению есть у всех. Хотя это ни в коем случае нельзя считать
решением проблемы CSS, все же это ограничивает подверженность атаке.
Подсказка
Стратегии защиты обычно имеют несколько уровней эффективности. Некоторые
методы абсолютно эффективны; другие смягчают атаки ограничением области
распространения. Есть также методы, которые лишь скрывают некоторые
данные, замедляя тем самым атаку и вводя в заблуждение неискушенных хакеров.
Смягчающие и скрывающие методы не дают серьезной защиты, но в целом
оказывают положительное влияние в борьбе с атаками, особенно при
использовании комбинации этих методов.
Всегда указывайте специфику пути cookie и проверяйте путь к cookies, которые
клиент отправляет в ваше приложение. Для опознавания форм установите
атрибут элемента форм в файле web.config.
Окончание срока действия cookies
Окончание срока действия cookies в ASP.NET представляет собой механизм,
сбивающий с толка, но для ограничения подверженности cookies похищению
важно задавать срок его действия максимально коротким. Cookies оснащены
свойством Окончание срока действия, которое и устанавливает период, в течение котор0*
го обозреватель Интернет будет хранить файл cookies. Если это свойство не уста
новлено, клиент программы для просмотра web-сайтов сбросит cookie, как тольк
он закроется и не сохранит его на диске. Несмотря на то, что дата истечения срок
действия указывает обозревателю Интернет, когда он должен прекратить испо
зование cookie, нет никаких гарантий, что он удалит просроченный файл cook*
Таким образом, хотя это и не надежная мера защиты, ее стоит использовать.
Когда ASP.NET создает cookies ID сеанса, дата истечения срока действия
нем не установлена, поэтому обозреватель Интернет сбросит его сразу же по*-
закрытия. ASP.NET сама управляет истечением срока действия и повторным вЫ /

Управление сессиями • Глава 3 1
маркеров сеанса, основываясь на установке тайм-аута на элементе sessionState
"ла web.config, как показано ниже:
<sessionState
m0de="InProc"
sqlConnectionString="data source=127.0.0.l;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
ASP.NET также управляет истечением срока действия ярлыков форм
аутентификации. Файлы cookies для маркеров форм аутентификации не будут иметь даты
истечения срока, до тех пор, пока web-приложение не установит их как
постоянные. Метод FormsAuthentication.RedirectFromLoginPage обладает параметром,
указывающим на то, хотите ли вы использовать постоянный cookie или нет:
FormsAuthentication.RedirectFromLoginPage(UserName.Text, Persist.Checked)
Обратите внимание, что класс FormsAuthenticationTicket также обладает
свойством IsPersistent, которое можно установить. Некоторые web-приложения
предоставляют пользователям свойство «Remember Me», поэтому им не приходится
каждый раз вводить свои логины. Это небезопасный метод, поэтому никогда не
устанавливайте это свойство на web-сайты, хранящие личную информацию, дающие
пользователям возможность выполнять серьезные финансовые операции, а также
осуществлять операции с личной информацией или коммуникационные действия.
Класс FromsAuthenticationTicket имеет свойство истечения срока действия,
которое указывает, когда аутентифицированный маркер прекратит свое
существование, но не устанавливает дату окончания срока действия самого cookie. Файл cookies,
0тправленный на обозреватель Интернет, не будет иметь установленной даты исте-
ения срока действия до тех пор, пока вы не обозначите его как постоянный.
Обнаружив маркер старой аутентификации, ASP.NET аннулирует его и создаст новый.
Формы аутентификации предоставляют две установки, контролирующие управле-
е 0к°нчанием срока действия маркера: тайм-аут и скользящее окончание срока. Тайм-
0пределяет количество минут до истечения срока действия cookie. Скользящее
окончу при установке значения на «да», обновляет дату истечения срока действия cookie
^ЭДым новым запросом обозревателя Интернет, предполагая, что, по крайней мере,
вина обозначенного времени уже истекла. Другими словами, установив тайм-аут на
скользящее окончание на позицию «да», позволит пользователю находиться на стра-
^^ До 20 минут с момента последнего запроса, до того как ему снова придется пройти
«тификацию. Если вы установили скользящее окончание на значение нет, програм-
Рсбует аутентификации пользователя через 20 минут после первого запроса.

130 Глава 3 • Управление сессиями
Внимание
Установка «тайм-аут* не влияет на постоянные файлы cookies. Если вы установи!
те аутентификационный ярлык как постоянный, ASP.NET установит срок
истечения cookies на 50 лет с момента выпуска cookies сервером - даже более
значительная причина, по которой не следует использовать постоянные cookies с
формами аутентификации.
Хотя возможность выбора между относительным и абсолютным тайм-аутом
является преимуществом, несомненно, лучше было бы совместить оба. В этом случае
можно устанавливать тайм-аут на определенный период ожидания события, а
также после установленного количества минут. Если не используется абсолютный
тайм-аут и кто-то оставит обозреватель Интернет на автоматически обновляемой
странице, сеанс никогда не закончится. Злоумышленники также могут
воспользоваться этим преимуществом данного дефекта, оставляя маркер активным, для
атаки фиксации сеанса.
Безопасные cookies
Сервер может пометить cookie как безопасный для указания клиенту, что он
должен принять меры по его защите. Хотя RFC (запрос на комментарий) не
определяет, какие именно меры защиты должен предпринять обозреватель Интернет,
обычно это означает лишь отправку cookie через зашифрованный сеанс
протокола безопасных соединений. Тем не менее, отметка cookie как безопасного - это
только предположение сервера, и клиент программы не должен неукоснительно
его выполнять. Теоретически, обозреватель Интернет должен предоставлять тот
же уровень защиты, какой был предоставлен при выпуске cookies. Большинство
самых распространенных обозревателей пользуются этой установкой.
Если вы ставите защиту SSL web-сайта, нужно также отмечать cookies как
безопасные, чтобы клиент не отправлял их на незащищенные SSL-страницы
на web-сайте.
Можно настроить формы аутентификации на то, чтобы всегда использовать
безопасные cookies с установкой requireSSL в файле web.config:
<forms name=M.ASPXAUTH"
loginUrl="/protected/login.aspx"
protection="All"
path="/protected/
timeout="15"
slidingExpiration="false"
requireSSL="true"
>

Управление сессиями • Глава 3
Обратите внимание, что если вы присваиваете формам аутентификации значения
нужно предоставить SSL-соединения для всей защищенной области web-приложе-
В противном случае, если пользователь заходит на не-SSL страницу, обозреватель
интернет не отправит cookie и пользователю придется снова пройти аутентификацию
создания новой FoirnsAuthenticationTIcket и, следовательно, нового файла cookies.
£ и вЫ требуете защиту для форм аутентификации cookies, убедитесь, что вся
защищенная область допускает SSL. Более того, вы, возможно, не захотите отмечать cookies
сеанса как безопасные, пока ваше web-приложение полностью не разрешит SSL.
Значения cookies
Наиболее распространенное применение cookies - хранение переменных
значений пользователей, таких как пользовательские предпочтения. Однако
некоторые разработчики используют cookies и для хранения ценной информации, такой
как имена пользователей, пароли и даже информация по кредитным карточкам.
Никогда не храните ценную информацию в cookie и всегда шифруйте все данные,
пригодные для хранения в нем.
Способы защиты
■ Всегда устанавливайте специальный атрибут домена и проверяйте его при
чтении cookies.
■ Всегда устанавливайте специальный путь cookies.
■ Устанавливайте короткий тайм-аут сеанса cookies для ограничения
вероятности атаки перехвата сеансов.
и Если вы используете протокол безопасных соединений, отметьте cookies
как безопасные.
Никогда не храните ценную информацию, такую как логины
пользователей или номера кредитных карточек, и всегда зашифровывайте данные.
■
Работа
в режиме просмотра
исходное положение: Режим просмотра может быть безопасным, если
вы используете правильные установки.
гроза: Манипуляция параметрами, фиксация сеанса,
утечка информации.

Глава 3 * Управление сессиями
Бежим просмотра - это свойство ASRNET, позволяющее сохранять свойства
формы, когда страница пересылается назад на себя. ASRNET сохраняет текущее
состояние всех видов контроля в виде зашифрованной строки в скрытой фор^е
поля. Опасность режима просмотра заключается в том, что злоумышленник мо
жет просмотреть или изменить значения этих форм для проведения различных
атак. К счастью, ASRNET позволяет защищать данные режима просмотра,
зашифровывая их и обнаруживая изменения с помощью хэшей.
Активирование режима просмотра
Можно активировать режим просмотра на машине, приложении, странице
или уровне контроля. Было бы заманчиво активировать режим просмотра на всем
web-сайте, однако вам придется проявить большую избирательность, чтобы
сократить вероятность атак. В Таб. 3.1. показано, как настроить режим просмотра на
различные уровни. В принципе, если вы не используете режим просмотра для
контроля страницы, можно заблокировать его.
Таблица 3.1. Активирование режима просмотра
Область действия Настройка
Машина В файле machine.config установите
<pagesenableViewState = «true»/>
Приложение В файле web.config установите
<pagesenableViewState = «true»
Страница В ресурсе страницы используйте
<% @ Page enableViewState = True.
Контроль В ресурсе страницы установите свойство контроля
EnableViewState = «True»
Защита режима просмотра
Режим просмотра появляется в ресурсе HTML как скрытая форма поля, *аЬ
это показано на рис. 3.6. Несмотря на загадочный внешний вид, он использует
только 64 основных шифрования. Можно раскодировать эти данные с помощь*0
инструмента «Декодер режима просмотра», как показано на рис. 3.7., которы1
можно найти на http://staff.develop.com /onion/resources.htm.

Управление сессиями • Глава 3 13
рис-3-6- Образец поля Обзора Состояния
• put type="hidden" name=" VIEWSTATE"
<1^e="dDwxNTQyMjY4Nzg2O3Q8O2w8aTw3PjtpPDk+Oz47bDx0PDtsPGk8MT47PjtsPHQ
GODA8cDxwPGw8RGF0YUtleXM7XyFJdGVtQ291bnQ7PjtsPGw8PjtpPDEwPjs+Pjs+Ozs7O
70zs+02w8aTwwPjtpPDE+02k8Mj47aTwzPjtpPDQ+02k8NT47aTw2PjtpPDc+02k80D4
^STw5Pjs+O2w8dDw7bDxpPDA+Oz47bDx0PEA8MzEhU29ydGluZy9GaWx0ZXJpbmcgRml4Z
WQgRGF0YVNldCBSZXNlbHRzOz47Oz47Pj47dDw7bDxpPDA+Oz47bDx0PEA8MzA7VGhlIEJ
hc21jcyBvZiBVc21uZyBTUUw7Pjs7Pjs+Pjt0PDtsPGk8MD47PjtfPHQ8QDwyOTtVc21uZ
vBRdWVyeXN0cmluZyBSZXNlbHRzIGluIFNRTCBTdGF0ZWllbnRzOz47Oz47Pj47dDw7bDx
pPDA+Oz47bDx0PEA8Mjg7VXNpbmcgdGhlIElTIElFIFRhYlN0cmlwIENvbnRyb2w7Pjs7P
L+pjt0PDtsPGk8MD47PjtsPHQ8QDwyNztCZWdpbm51cnMgR3VpZGUgVkl2lENvbSBPYmp
lY3RzIGluIEFTUC5OZXQ7Pjs7Pjs+Pjt0PDtsPGk8MD47PjtsPHQ8QDwyNjtDcmVhdGluZ
yBhIExvZ21uL0VtYWlsL0FjdG12YXRpb24gUGFnZTs+Ozs+Oz4+O3Q8O2w8aTwwPjs+O2w
8dDxAPDl0OlRoZSBCZWdpbm51cidzIEdlaWRlIHRvIGFuIEFycmF5TGlzdDs+Ozs+Oz4+O
3Q8O2w8aTwwPjs+O2w8dDxAPDIzO0NvbmZpZ3VyaW5nIGEgVHJlc3RlZCBTUUwgU2V6dmV
yIENvbm51Y3Rpb247Pjs7Pjs+Pjt0PDtsPGk8MD47PjtsPHQ8QDwyMjtBZGRpbmcgRHluY
WlpYyBDb250ZW50lHRvIFlvdXIgUGFnZXM7Pjs7Pjs+Pjt0PDtsPGk8MD47PjtsPHQ8QDw
yMTtDcmVhdG133yBhIEllbnUgVXNlciBDb250cm9sIHdpdGggUm9sbG92ZXJzOz47Oz47P
j47Pj47Pj47dDw7bDxpPDA+Oz47bDx0PEA8MDY3MjMyNTAxM3SwNjcyMzIlMDEyO0FTUC5
0RVQgRGF0YSBXZWJcPGJyXD5Db250cm9scyBLaWNrIFN0YXJ0lA0KOlNjb3R0lElpdGNoZ
WxsOz470z47Pj 47Pj 47Po/QlmEhBOdXCZBvDCRMGZGfOTBW" />
Рис. 3-7. Декодер Обзора Состояния
\4 -'
Поскольку Режим просмотра представляет свойства контроля формы, злоумы-
еНник сможет модифицировать форму, изменяя свойства режима просмотра.
РИмер, злоумышленник сможет изменить цену продукта в он-лайн-магазинах
и модифицировать параметр для выполнения атаки SQL-запросов. Злоумыш-
н**ик может применить ряд других атак, таких как CSS-атаки, неавторизованный
СтУп или переполнение буфера.

134 Глава 3 * Управление сессиями
Для предотвращения манипуляций режимом просмотра злоумышленником
можно включить сообщение аутентификации кода (MAC). MAC по своей сущц0с_
ти - это хэш данных, поддерживающий их целостность. Можно активировать его
на машине, приложении или на странице. Словом, вы можете активировать
его везде, где у вас активирован режим просмотра с атрибутом:
enableViewStateMac="true"
Внимание
Хотя многие документы не рекомендуют использовать режим просмотра MAC, по
крайней мере, пока это не станет необходимостью для четкого исполнения
программы, я советую вам использовать его
MAC защитит вас от постороннего вмешательства в данные режима
просмотра, удаляющего содержание. Однако кто-то всё же может раскодировать и
просмотреть параметры режима просмотра, используя Декодер режима просмотра,
упомянутый выше. Чтобы решить эту проблему, можно также зашифровать поля
режима просмотра. Шифрование можно настроить с помощью элемента machineKey
в файле web.config:
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="3DES"
/>
Атрибут подтверждения правильности может быть MD5, SHA-1 или 3DES.
Первые два провоцируют ASP.NET на создание хэша MD5 или SHA-1 MAC, a 3DES
шифрует содержание режима просмотра и создает SHA-1 MAC. Установка режима
подтверждения на 3DES защищает данные от просмотра и предотвращает
манипуляцию параметрами, но все же не дает полной защиты режима просмотра.
Злоумышленник может предварительно заполнить форму, сохранить поле Режим Пр°"
смотра, а затем спровоцировать другого пользователя использовать эту форму
Чтобы не допустить этого вида атаки, ASP.NET позволяет вам установить
уникальный ключ для каждого пользователя, что делает данные действительными только
для данного пользователя. Можно сделать это в событии page_unit, установив
свойство ViewStateKeyUser на объекте страницы. В случае с аутентифицированнЫ
ми пользователями можно установить его на логин или ID сеанса, но в слу43-
с анонимными пользователями вам необходимо создать случайное число и сохра
нить его в cookies пользователя. Рис. 3.8. (С#) и рис.3.9. (VB.NET) показывают, ка
использовать вышеописанные методы.

Управление сессиями • Глава 3
^ рис.3-8. Защита режима просмотра:С#
Йй*-—: ■
rivate void Page_Init(object sender, System.EventArgs e)
{
EnableViewState = true;
EnableViewStateMac = true;
ViewStateUserKey = User.Identity.Name;
}
•^ Рис-3-9- Защита режима npocMOTpa:VB.NET
^
Private Sub Page_Init(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Init
EnableViewState = True
EnableViewStateMac = True
ViewStateUserKey = True
InitializeComponent()
End Sub
Для обеспечения надежной защиты режима просмотра используйте шифрова
ние, хэширование и уникальные ключи пользователей. Всегда блокируйте режим
просмотра, если вы не используете его.
Способы защиты
■ Заблокируйте режим просмотра, если вы не используете его.
■ При активации режима просмотра всегда активируйте режим просмотра MAC.
■ Установите атрибут подтверждения в machine.config на 3DES
■ Установите уникальный пользовательский ключ режима просмотра для
каждого пользователя.
Расширение структуры управления ASP.NET
Структура управления ASP.NET удобна, но не соответствует критериям,
рассмотренным в начале этой главы. Например, маркеры сеанса и опознавания
^е Привязаны к пользователю, и ASP.NET разрешит доступ любому предоставление-

Глава 3 • Управление сессиями
му клиентом маркеру. Этот раздел посвящен использованию встроенных свойств
структуры управления совместно с клиентскими файлами cookies для обеспечения
дополнительного уровня безопасности. В этом разделе будут рассмотрены:
■ Создание маркеров
■ Установка сеансов
■ Завершение сеансов
Важно отметить, что хотя это и не остановит всех атак, использование SSL
все же усилит методы, описанные в этом разделе.
Создание маркеров
Исходное положение: Используйте дополнительный код для
повышения безопасности маркера.
Угроза: Перехват сеанса, похищение аккаунта,
фиксация сеанса, утечка информации.
Маркер, используемый для управления сеансом, должен быть надежным
случайным числом и не должен напрямую идентифицировать пользователя, а
приложение должно быть в состоянии подтвердить его подлинность.
Случайные числа - важный аспект безопасности, но для того, чтобы считаться
действительно случайными, они должны обладать определёнными свойствами.
Например, число не должно быть предсказуемым или легко воспроизводимым, и оно
должно быть достаточно длинным, чтобы его сложно было вычислить. При
создании маркера сеанса ASP.NET использует надежный генератор случайных чисел для
создания 120-битового ключа, который наверняка подходит для многих целей. Этот
маркер сеанса хранится в файле cookies под названием ASP.NET_Se-ssionId или на
URL, если вы используете структуру «без cookies». Этот маркер сеанса также
доступен через свойство Sessionld объекта Session.
Единственный недостаток маркера сеанса ASP.NET - это то, что он являете
всего лишь случайным числом, и ASP.NET примет любой маркер нужной длинь
что делает её уязвимой для атаки фиксации сеанса. В качестве компенсации это
недостатка нам приходится создавать MAC для маркера сеанса, основанного
случайном числе, хранящемся с механизмом состояния сервера, как показано
рис. 3.10. (С#) и рис. 3.11. (VB.NET).

Управление сессиями • Глава 3 137
рис- 3-Ю- Расширение ID сеанса с MAC :C#
ivate void enhanceSessionldWithMac()
{
string SessionMacCookieValue;
// Check if there is a SessionMac cookie
if (Request.Cookies["SessionMac"] == null)
{
SessionMacCookieValue = null;
}
else
{
SessionMacCookieValue = Request.Cookies["SessionMac"].Value;
}
// Create and store hash
if (Session ["key"]==null && SessionMacCookieValue==null)
{
Session ["key"]=CreatKey();
string hash = createHMASCHAl(Encoding.Unicode.GetBytes(
Session.SessionID),
Encoding.Unicode.GetBytes(
(string) Session["key"]));
HttpCookie SessionMac = new HttpCookie ("SessionMac", hash);
Response.Cookie.Add (SessionMac);
}
// Check against stored hash
else
{
string createHash = createHMASCHAl(
Encoding.Unicode.GetBytes(
Session.SessionID),
Encoding.Unicode.GetBytes(
(string) Session["key"]));
if (createdHash != Request.Cookies [ "SessionMac"].Value)
{
Session.Abandon();
Response.Redirect ("default.aspx");
}

Глава 3 • Управление сессиями
Рис. 3-10- Расширение ID сеанса с MAC : VB.Net
Private Sub enhanceSessionldWithMac()
Dim SessionMacCookieValue As String
1 Check if there is a SessionMac cookie
If Request.Cookies("SessionMac") Is Nothing Then
SessionMacCookieValue = Nothing
Else
SessionMacCookieValue = Request.Cookies("SessionMac").Value
End If
' Create and store hash
If Session("key") Is Nothing And SessionMacCookieValue Is Nothing Then
Session ("key") = createKeyO
Dim hash As String
hash = createHMASCHAl (Encoding.Unicode.GetBytes (Session.SessionID),
Encoding.Unicode.GetBytes(Session("key")))
Dim SessionMac As HttpCookie
SessionMac = New HttpCookie("SessionMac", hash)
Response.Cookies.Add(SessionMac)
Else
' Check against stored hash
Dim createdHash As String
createdHash = createHMASCHAl(_
Encoding.Unicode.GetBytes(Session.SessionID), _
Encoding.Unicode.GetBytes(Session("key")))
If (createdHash <> Request.Cookies("SessionMac").Value) Then
Session.Abandon()
Response.Redirect("default.aspx")
End If
End If
End Sub
Этот код создает MAC, основанный на ID сеанса, используя случайное число, *Р
нящееся нВ сервере как ключ. Он сохраняет этот MAC как cookie на клиенте. При в
де запроса клиента, вы против компьютера представляете MAC и видите, соответс .
ет ли он MAC, хранящейся в cookie клиента. Если они соврали, можете быть увере
что это действительное ID сеанса: в противном случае, удалите текущий сеанс и заст^
те пользователя получить новый ID сеанса. После окончания времени сеа*1
на сервере, ключ больше не будет доступен и MAC, основанный на этом ключе та>^

Управление сессиями • Глава 3 139
станет быть действительным. Если клиент отправляет cookie для предшествующе-
еанса без обеспечения MAC, сервер удалит сеанс и начнет все с начала с новым ID
Нет никакой необходимости в добавлении вашего собственного MAC, для яр-
ков форм опознавания, если вы всегда используете шифрование или подтверж-
ние с помощью свойства защитить = «Все» элемента формы в файле web.config.
Яго гарантирует, что взламыватель не сможет просмотреть или изменить ярлык
/Ьорм опознавания. Ярлык кодируется и хэшируется, основываясь свойствах
Ключ кодирования и Ключ подтверждения элемента Ключ машины в файле
machine.config. При установке по умолчанию, они оба настроены на
^utoGenerate,IsolateApps», что означает, что ASP.NET будет образовывать
случайные значения для этих ключей. Установка IsolateApps очень важна, поскольку она
гарантирует уникальный ключ для каждого приложения ASP.NET на сервере. Это
особенно важно на общем хосте, поскольку без неё, один web-сайт будет
производить ярлык действительных форм опознавания для другого web-сайта на том же
сервере.
фдсказка
Если вы эксплицитно используете значения decryptionKey и validation Key для
разрешения форм опознавания в вэб-форме, вы все равно можете использовать
установку IsolateApps для предоставления уникального ключа каждому приложе-
^ нию на сервере.
Связь
с клиентом
После того как вы установили безопасный маркер и отправили его клиенту, вы,
возможно, захотите убедиться, что только этот клиент использует данный маркер.
Хотя полностью предотвратить похищение cookie очень сложно, все же существуют не-
колько методов ограничения области действия для блокирования многих типов атак.
Существует много способов получения маркеров сеанса взламывателем и пере-
та сеанса пользователей. Некоторые из методов, которые может использовать:
Атака «Человек-в-середине», включая ППА (протокол перераспределения
адресов) или ДСИ (доменная система именования) «спуфинг».
Получение маркера сеанса на URL, хранящегося в кэше или в журналах
регистрации сервера-посредника.
Получения доступа к системе клиента и похищение cookie обозревателя
Интернет; Троян также входит в этот тип атаки.

140 Глава 3 • Управление сессиями
■ Использование межсайтингового скриптинга для получения cookie
обозревателя Интернет или маркера в URL.
Причина того, что web-сайты редко используют привязку к сеансу пользоват
в том, что очень сложно провести привязку к единичному сеансу, и даже если r
это удалось, это не защищает вас от всех типов атак. Вам нужно не только полуют,
маркер, но еще и сделать так, что его было сложно использовать с другого клиент
Существует несколько способов создания надежной привязки между сеансо
и пользователем. Самым очевидным из них является использование IP-адреса кли
ента. Основная проблема этого выбора в том, что некоторые Интернет
провайдеры используют сбалансированное кэширование серверов-посредников. Это
означает, что, во-первых, более одного пользователя будут пользоваться одним и тем
же IP-адресом и, во-вторых, что пользователь может не использовать один и тот
же IP-адрес для каждого запроса. Чтобы решить эту проблему, вы должны быть
в состоянии использовать первые один или два октета IP адреса. Таким образом,
если клиент приходит с 192.168.10.58, можно привязать сеанс к первым двум
октетам, 192 и 168. Другой метод - это привязать к строке UserAgent, полученной
клиентом. Однако некоторые посредники случайным способом изменяют строку
UserAgent, для помощи в защите секретности пользователя, и взламыватель
может обнаружить и подменить эту строку. И, наконец, есть ещё один способ -
привязать к cookie текущего сеанса ASP. Ни один их этих методов не совершенен,
но, используя их комбинацию, вы, несомненно, обеспечите более надежную
защиту, чем, если откажетесь от них совсем.
Рис. 3.12. (С#) и рис. 3.13. (VB.NET) показывают, как получить информацию
о клиенте и сохранить её в структуре сеанса. С каждым новым запросом от этого
клиента, вы сравниваете информацию с сохраненной информацией и удаляете
сеанс в случае не соответствия. Проведите тестирование, чтобы убедиться, что
сможете использовать их с вашей клиентской базой.
Рис. 3.12. Привязка к клиенту: С# ш
private void bindingToTheClient()
{
// get the first two octets
string[] userlpArray = Request.UserHostAddress.Split('.');
string f irstTwoOctets = userlpArray [0] + "." + userlpArray [1] '*
if (Session["firstTwoOctets"] == null &&
Session["userAgent"] == null)
{
Session["firstTwoOctets"] = firstTwoOctets;
Session["userAgent"] = Request.UserAgent;

Управление сессиями • Глава 3 141
else
{
if ((string) Session["firstTwoOctets"] != firstTwoOctets II
(string) Session["userAgent"] != Request.UserAgent)
{
Session.Abandon();
Response.Redirect("default.aspx");
}
}
}
Рис- 3.13- Привязка к клиенту: VB.NET
I. ■
Private Function bindingToTheClient()
Dim userlpArray() = Split(Request.UserHostAddress, ".")
Dim firstTwoOctets As String = userlpArray(0) + "." +
userlpArray (1)
If Session("firstTwoOctets") Is Nothing And _
Session("userAgent") Is Nothing Then
Session("firstTwoOctets") = firstTwoOctets
Session("userAgent") = Request.UserAgent
Else
If Session("firstTwoOctets") <> firstTwoOctets Or _
Session("userAgent") <> Request.UserAgent Then
Session.Abandon()
Response.Redirect("default.aspx")
End If
End If
End Function
Способы защиты
* Всегда используйте надежный генератор случайных чисел для маркеров
сеанса.
* Используйте маркер, который не идентифицирует пользователя ни кому,
кроме сервера.

142 Глава 3 * Управление сессиями
■ Используйте дополнительный MAC для гарантирования аутентичности
маркера сеанса.
■ При использовании форм опознавания на общем сервере, всегда
используйте установку IsolateApps элемента machineKey в файле machine.config
■ Сохраняйте переменные клиента для помощи гарантированной привязки
к тому же самому клиенту.
Завершение сеансов
Исходное положение: Тщательно выбирайте механизм маркера,
который обеспечивает пользователям лучшую защиту.
Угроза: Перехват сеансов, похищение аккаунтов,
постоянно активированный маркер.
Нужно уничтожить маркер сеанса сразу же после окончания сеанса.
Существует несколько способов завершения web-сеанса:
■ Клиент закрывает обозреватель Интернет.
■ Пользователь пролистывает разные web-сайты.
■ Клиент обозревателя не используется достаточно долгое время для
истечения срока действия маркера.
■ Сервер удаляет маркер.
Когда клиент закрывает программу, обозреватель Интернет сбрасывает все
маркеры сеансов, не отмеченные как постоянные. Однако если пользователь
просто перелистывается на другой web-сайт, маркеры сеансов остаются в памяти
обозревателя Интернет. Это означает, что если пользователь вернется на свой we
сайт, его маркер сеанса будет активен. Это может представлять опасность на обше
публичном компьютере или если пользователь оставляет окно обозревателя И
тернет открытым на продолжительный период. Для ликвидации этой опасное
ASP.NET автоматически заканчивает сеанс через заранее определённое вр^м
обычно 20 минут.
Но если пользователь находится на web-сайте, который автоматически обн
ляется каждые несколько минут, сеанс никогда не останется неиспользованнь
достаточное для истечения время. Взламыватель может воспользоваться этой в
можностью с фиксацией сеанса для того, чтобы оставить маркер активным на /*
статочно долгое время для проведения атаки.

Управление сессиями • Глава 3 1
Наилучшим противодействием этому служит установка трех различных факто-
цстечения срока действия:
щ Через определённое время, если он не использовался.
щ Через абсолютное время с того момента как маркер был создан.
■ Через определенное количество использований.
Используя эти факторы, можно, например, «угасить» сеанс, если он не
использовался в течение 10 минут, через два часа после создания маркера, или через 50
hit на ваш web-сайт. При любом из этих условий, нужно создать новый маркер
сеанса или провести повторную аутентификацию пользователя. Этот метод
практикуется в основном на интерактивных банковских web-сайтах.
Так как ASP.NET автоматически устанавливает тайм-аут неиспользуемых
сеансов, мы можем использовать структуру сеанса для хранения двух других
переменных. Рис. 3.14. (С#) и рис. 3.15. (VB.NET) показывают как использовать, хранить
и проверять абсолютное истечение и счетчик hit.
Рис- 3-14. Истечение сеанса :С#
private void expiringSessions()
{
if (Session["absoluteExpiration"] == null &&
Session["maxHitCount"] == null)
{
Session["absoluteExpiration"] =
DateTime.Now.AddHours(2); // Two hours from now
Session["maxHitCount"] = 3; // Fifty hits to the website
Session["hitCount"] = 0;
}
else
{
Session["hitCount"] = (int) Session ["hitCount"] +1;
// Check if session has expired, or exceeded max hit count
if (DateTime.Now > (DateTime) Session["absoluteExpiration"] ||
(int) Session ["hitCount"] ..> (int) Session["maxHitCount"])
{
Session.Abandon();
Response.Redirect("default.aspx");
}

144 Глава 3 * Управление сессиями
Рис. 3.15. Истечение сеанса :VB.NET
Private Function expiringSessions()
If Session ("absoluteExpiration") Is Nothing And _
Session("maxHitCount") Is Nothing Then
1 Two hours from now
Session("absoluteExpiration") = DateTime.Now.AddHours(2)
' Fifty hits to the website
Session("maxHitCount") = 50
Session("hitCount") = 0
Else
Session("hitCount") = Session("hitCount") + 1
' Check if session has expired, or exceeded max hit count
If DateTime.Now > Session("absoluteExpiration") Or _
Session("hitCount") > Session("maxHitCount") Then
Session.Abandon()
Response.Redirect("default.aspx")
End If
End IF
End Function
Этот код проверяет текущий сеанс на наличие абсолютного истечения и
счетчика hit. В случае отсутствия, код создает его и сохраняет со структурой сеанса.
При поступлении следующего запроса, он снова проверяет эти значения, пока
клиент не перейдет за пределы. На этом этапе сеанс завершается и требуется
повторная аутентификация пользователя на сервере.
Способы защиты
■ Применяйте тайм-ауты для завершения неиспользуемых сеансов.
■ Используйте абсолютные тайм-ауты для установки ограничений активнь -
сеансов.
■ Задействуйте счетчик посещений для ограничения использования лк>6°
одиночного маркера.

Управление сессиями • Глава 3
Краткая справка по стандартам
кодирования
Настройка состояния
разработка безопасного маркера
• По возможности применяйте дополнительные меры для привязки маркера
к сеансу клиента.
• Предавайте опознавательные сертификаты через SSL или IPSec.
• Всегда используйте достаточно большую ключевую область (минимум 120
бит) для маркеров сеанса.
• Всегда ставьте надежный генератор случайных чисел
для маркеров сеанса.
• Никогда не принимайте новые маркеры, предложенные клиентом.
• Не включайте идентификацию пользователей в незашифрованном виде
в маркер.
• Всегда ограничивайте область действия маркера текущим приложением.
• Используйте и относительный и абсолютный тайм-ауты для маркеров.
• Примите меры по предотвращению сохранения клиентом маркера сеанса
после завершения сеанса.
• Разрешите пользователям самим прекращать сеанс.
• Всегда используйте новый маркер при каждой регистрации сеанса.
Выбор
механизма маркера
• Избегайте маркеров, основанных на URL.
• По возможности используйте маркеры на базе cookie.
• Используйте маркеры HttpOnly с клиентами Internet Explorer.
• Задействуйте SSL для защиты маркеров сеанса.
использование индикатора состояния
Заблокируйте ASP.NET State Service, если вы не пользуетесь ей.
Используйте asp.net_setreg.exe для шифрования строки состояния
соединения.
Избегайте использования маркеров без cookie.
Установите для вашего приложения тайм-аут с подходящим сроком.

146 Глава 3 * Управление сессиями
Использование маркеров ASP.NET
Использование файлов cookies
• Всегда устанавливайте специальный домен и путь на все cookie.
• Всегда проверяйте домен и путь на входящих cookie для блокирования
cookie с неверной областью действия.
• Не устанавливайте сроки истечения на cookie, чтобы они истекли
при закрытии обозревателя Интернет.
• При использовании постоянных cookie, используйте короткие сроки
истечения действия.
• При использовании SSL, отмечайте cookie как безопасные, для предотвра
щения их от передачи по не SSL соединениям.
• Никогда не храните чувствительную информацию в cookie, и всегда
шифруйте то, что храните.
Работа с ViewState
• Заблокируйте ViewState на всех страницах, где вы им
не пользуетесь.
• Везде, где вы активировали ViewState, активируйте
Обзор Состояния MAC.
• Установите свойство подтверждения элемента machineKey
в machine.config к 3 DES.
• Установите уникальный ключ ViewState для каждого пользователя.
Расширение структуры управления ASRNET
Создание маркеров
• Всегда используйте надежный генератор случайных чисел
для маркеров сеанса.
• Используйте MAC, основанное на случайной числе для подтверждения
подлинности маркера сеанса.
• Используйте установку IsolateApps для обеспечения уникальных ключей
между приложениями.
• Используйте переменные клиента для тесной привязки
к сеансу клиента.

Управление сессиями • Глава 3
Прекращение сеансов
• Используйте абсолютные тайм-ауты в дополнение к неиспользованным
тайм-аутам для продления максимального срока действия маркера.
• Используйте счетчик посещений для ограничения использования одного
любого маркера.
Краткая справка по проверке кода
Настройка структуры
Разработка безопасного маркера
• Тесно ли маркер привязан к сеансу пользователя?
• Безопасным ли способом сервер передает маркер клиенту?
• Достаточно ли велико ключевое пространство, используемое
приложением?
• Надежный ли генератор случайных чисел для маркеров использует
приложение?
• Примет ли система любой маркер предоставленный клиентом?
• Возможно ли пользователю манипулировать маркером для переходя
на другой аккаунт?
• Идентифицирует ли маркер клиента?
• Правильно ли маркер ограничивает свою область действия?
• Оснащен ли маркер одновременно относительным и абсолютным
тайм-аутами?
• Сохраняет ли клиент маркер по окончании сеанса?
• Обладает ли пользователь опцией прекращения сеанса?
• Создает ли приложение новый маркер для каждого входа?
Выбор механизма маркера
• Использует ли приложение безопасный механизм
передачи cookie?
• Применяет ли приложение маркеры HttpOnly с клиентами
Internet Explorer?
Использует ли приложение SSL, когда это целесообразно?

148 Глава 3 * Управление сессиями
Использование индикатора состояния
• Если вы не используете ASP.NET Session State Service,
заблокирован ли он?
• Если вы внедрили ASP.NET Session State Service, использует ли система
нестандартный порт?
• Если вы используете ASP.NET Session State Service,
контролирует ли система ограничение права доступа на порт сервиса?
• Файл web.config содержит зашифрованные строки соединения
структуры сеанса, созданные aspnet_setreg.exe?
• Избегает ли приложение маркеров не на основе cookie?
• Использует ли приложение короткие тайм-ауты cookie?
Использование маркеров ASP.NET
Использование cookies
• Устанавливает ли код специальный домен и путь на все cookie?
• Проверяет ли код домен и путь на входящих cookie для блокирования
cookie с неверной областью действия?
• Устанавливает ли приложение подходящие свойства истечения cookie?
• Отмечает ли приложение cookie как безопасные при их передаче по SSL
соединениям их?
• Избегает ли приложение хранения уязвимой информации
в файлах cookie?
• Кодирует ли приложение все данные, хранящиеся в файлах cookie?
Работа с ViewState
• Блокирует ли приложение ViewState на страницах,
где он не используется?
• Активирует ли приложение ViewState УСД при использовании
ViewState?
• Использует ли элемент machineKey в файле machine.config 3DES
в качестве метода подтверждения?
• Устанавливает ли приложение уникальный ключ ViewState
для каждого пользователя?

Управление сессиями • Глава 3
расширение ASRNET State Management
Создание маркеров
• Использует ли приложение надежный генератор случайных чисел
для маркеров сеанса?
• Гарантирует ли приложение подлинность маркера сеанса?
• Использует ли система установку IsolateApps для обеспечения уникальных
ключей для каждого приложениями?
• Использует ли приложение переменные клиента для привязки к сеансу
клиента?
Прекращение сеансов
• Использует ли приложение абсолютные тайм-ауты в дополнение к
неиспользуемым тайм-аутам для продления максимального срока действия
маркера?
• Есть ли в приложении счетчик посещений для ограничения
использования любого маркера?

Глава 3 • Управление сессиями
FAQ
Следующие вопросы, с ответами авторов этой книги, предназначены как для по*
мощи в понимании концепций, представленных в данной главе, так и для помощи
в практическом применении этих концепций. Если у вас есть вопрос к автору, зайди,
те на vww.SYn0ess.com/solutions и щелкните на форму «Спросить автора». Вы также
получите доступ к тысячам других ЧЗВ на ITFAOnetcom.
Вопросы (В) и ответы (О)
В: SSL обеспечивает достаточную безопасность, чтобы предотвратить доступ
хакеру?
Ol SSL не решает всех проблем, однако защищает от многих типов атак, поэтому
вам необходимо использовать его везде, где это возможно. На медленных
серверах, SSL иногда может удвоить загрузку процессора, но с более мощным
«железом» будет проще. Более того, можно разгрузить SSL с помощью
специального аппаратного обеспечения. Если ваш web-сайт связан с важными
финансовыми, личными или коммуникационными данными, использование SSL
обязательно.
В: Могу ли я создать разные установки machineKey в каждом файле web.config
вместо одиночной установки в machine.config?
Ol Да, на самом деле это самый предпочтительный метод защиты сервера с
множеством пользователи. Для настройки используйте следующую установку
IsolateApps:
<machineKey validationKey=*Au'toGenerate, IsolateApps"
decryptionKey="AutoGenerate,IsolateApps" validation="SHA2/'/>
В: Где безопаснее управлять структурой сеанса -« в аккаунте клиента или
на сервере?
Ol Лучше всего и там, и там. Если вы полагаетесь только на сервер, хакеру легче
влезть в сеанс клиента, не зная его. В противоположном случае очень сложно
предотвратить фиксацию сеанса, и нет никаких способов отменить сеанс
пользователя после инцидента с безопасностью.
В: Почему так важно использовать надежный генератор случайных чисел Д-71
маркера сеанса?
О: Основная причина использования надежного генератора случайных чисел "
это предотвращение угадывания или применения атаки грубого подбора №
маркера сеанса. Например, хакер может создать скрипт для рассмотрения тЫ

Управление сессиями * Глава 3
сЯч ID сеансов, пока не обнаружит действительный сеанс. Чем надежнее чис-
ло, тем сложнее ему будет обнаружить этот сеанс. Случайное число должно
быть большим, непредсказуемым, и даже проходить через все ключевое
пространство. Если у вас 120-битное случайное число и 10 000 активных сеансов,
нужно чувствовать себя в безопасности, зная, что для каждого активного
сеанса, 132, 922, 799, 578, 491, 000,000,000,000,000,000 ID сеансов
недействительны. Даже используя автоматический скрипт, будет очень сложно вычислить
действительное ID сеанса.
В- Я управляю службой электронной почты, по некоторым причинам должен
поместить маркер сеанса на URL. Как я могу предотвратить отправку с
обозревателя Интернет клиента маркера URL в поле Referer, когда пользователь
обращается на внешнюю гиперссылку?
0: Если вы поместили ID сеанса на URL и пользователь щелкает на ссылку, web-
сайт окончательного места назначения сможет увидеть оригинальный URL,
включая маркер сеанса, просмотрев поле Referer. Иногда хакер может
использовать этот пробел для входа в сеанс пользователя. Самый легкий способ
предотвращения взлома - возвращать все URL через ваш URL, установят ори
гинальный URL в качестве параметра. Таким образом, можно закончить чем-
то вроде этого:
http: //www. example . com/ext email ink. aspx?original = www. externalURL. com
Затем используйте externallink.aspx. для захвата параметра оригинального
URL и направьте клиента на тот web-сайт. Внешний web-сайт увидит только
ссылку, пришедшую с externallink.aspx.

Глава 4
и »• •:.. н i ьтштт
да н-1
,Щ
'\ '«I
Решения в этой главе:
О Использование криптографии в ASP.NET
";<■<-$
3 Работа со свойствами криптографии ASP.NET
Ш
3 Защита коммуникацийъ^к:/^Щ*%ф''
77-а ' '■^•XlJ'p:
4
1.V
0'-
' "V
**-»•,
• Краткая справка по стандартам
кодирования
• Краткая справка по проверке кода
• FAQ
~<Ц£'Р '
153

154 Глава 4 • Шифрование личных данных
Введение
С той огромной ответственностью, которая возложена на цифровую защи
в нашем современном мире, остается удивительным тот факт, что столь небол
шой процент web-сайтов использует шифрование. Возможна причина в сложно
ти и недостатке приложений, поддерживающих его, но безопасность это само
главное в защите данных, а защитить данные без криптографии невозможно. К
счастью, ASP.NET предлагает впечатляющий набор классов, связанных с
криптографией, для защиты даже самой чувствительной информации. И что самое
замечательное, ASP.NET позволяет легко внедрять криптографию в ваше приложение
Но криптография это больше, чем просто гарантирование
конфиденциальности. На самом деле, криптография играет много ролей в защите данных, такие как:
■ Обеспечение целостности данных
■ Гарантирование секретности
■ Опознавание отправителей и получателей
■ Предотвращение отрицания
Целостность данных включает в себя доказательство того, что данные не были
модифицированы с определенного момента времени. Секретность и
конфиденциальность предотвращают ваши данные от доступа к ним без вашего согласия.
Опознавание подтверждает, что данные были получены с установленного источника
и доступны только для установленного получателя. И, наконец, отрицание
отклоняет действие или право собственности на данные. Криптография заставляет
пользователя подтверждать действие или признавать право собственности на данные.
Читая эту главу, вы найдете концепции, которые в некоторых случаях,
уникальны для криптографии как науке. Хотя полное обсуждение использования
криптографии находится за пределами этой книги, очень важно понять несколько основ
ных концепций:
■ Обычный текст Оригинальные не модифицированные, не защищенны
данные, также известны как простой текст.
■ Гипертекст Обычный текст, преобразованный таким образом, что его
возможно прочесть без специального ключа.
■ Шифрование Процесс преобразования простого текста в гипертекст.

Шифрование личных данных • Глава 4
0 Расшифровывание Процесс преобразования гипертекста в простой текст.
0 Шифр Алгоритм или процесс, используемый для шифрования
чувствительных данных.
Щ Ключ Секрет, используемый для шифрования и расшифровывания
чувствительных данных.
■ Ключевое пространство Набор всех возможных ключей, доступных
на специальном шифре.
■ Генератор псевдослучайных чисел (ГПСЧ). Поскольку компьютеры
не могут быть действительно случайными, мы полагаемся на генератор
псевдослучайных чисел для наиболее близкого имитирования
случайности. Случайные числа играют важную роль в криптографии.
Не смотря на то, что криптография - важный элемент защиты данных,
она не невосприимчива к атакам. На самом деле, существует целый ряд способов
атаки системы криптографии, таких как:
■ Грубый подбор Вычисление ключа подбором всех возможных вариантов.
Успех атаки грубого подбора зависит от скорости текущей компьютерной
технологии и времени, установленного для таких атак.
■ Уязвимость пользователя Люди очень уязвимы против «социальной
инженерии», физическим угрозам, шантажу, и они всегда делают выбор
не в пользу безопасности.
и Криптоанализ Многие люди изучают алгоритмы криптографии, пытаясь
найти дефекты в таких кодах.
■ Утечка через канал Иногда возможно вычислить ключ криптографии или
обнаружить дефект в шифре, измеряя и анализируя время, потребление
и расход энергии, электромагнитное излучение, теплоотдачу и другие каналы.
Физическая атака Взламыватель может получить физический доступ к
вашему компьютеру и выяснить ваш персональный ключ или установить
регистратор ключа или другое отслеживающее устройство для раскрытия ва
щего пароля.

156 Глава 4 * Шифрование личных данных
■ Плохое внедрение Многие разработчики не понимают как правильно
применять криптографию в их приложениях и, следовательно, могут
непреднамеренно, стать причиной дефекта.
Использование криптографии в ASP.NET
Перед тем как устанавливать криптографию в свое приложение ASP.NET
вы сначала должны понять, когда использовать различные доступные шифры
В ASP.NET существует три основных категории шифра:
■ Симметричный алгоритм
■ Ассиметричный алгоритм
■ Алгоритм хэширования и подписи.
Каждый из них играет уникальную роль в обеспечении безопасности
приложения ASP.NET. Важно понимать, какой тип шифра нужно применять в той или иной
ситуации. В таблице 4.1. представлены некоторые типы использования для
различных категорий шифра:
Таб.4.1.Алгоритмы шифрования в .NET Framework
Категория Алгоритмы Предполагаемое использование
Симметричный DES, 3DES. Шифрование объемных данных
Rjindael (AES), RC2
Ассиметричный RSA Опознавание, целостность данных
Хэширование MD5, SHA-1, SHA256, Целостность данных
и подписи SGI HA384fSHA512fDSA
Внимание
С такой серьезной встроенной поддержкой для алгоритмов шифрования, нет
никаких причин «изобретать велосипед». На самом деле, поскольку редко кому УДа*
ется написать действительно надежный алгоритм шифрования, никогда не пола
гайтесь на тот, который вы придумали сами. Более того, такие алгоритмы obfu
cation данных как XOR, R0T-13 предоставляют очень низкий уровень защит
Не смотря на все наши усилия объяснить это, программисты постоянно использу
ют эти дефектные методы, для защиты секретных данных.

Шифрование личных данных • Глава 4
Использование симметричной криптографии
Исходное положение: Симметричная криптография эффективна для
шифрования объемных данных, но
масштабность и управление ключа ограничивают ее
использование.
Угроза: Утечка информации, искажение данных, атаки
«Человек-в-середине», атаки грубого подбора.
Симметричная криптография, известная также как криптография секретного
ключа, это использование одного общего секрета для разделения зашифрованных
данных между партиями. Шифр здесь называется симметричным, потому что вы
используете один и тот же ключ для шифрования и расшифровывания данных.
Проще говоря, отправитель шифрует данные при помощи пароля, который
должен знать и получатель для получения доступа к данным.
Симметричное шифрование - это двусторонний процесс. С блоком простого
текста и данного ключа, симметричный шифр всегда будет производить тот же
гипертекст. И наоборот, используя тот же ключ на том же блоке гипертекста, мы
всегда получим оригинальный простой текст. Симметричное шифрование
эффективно для защиты данных между сторонами с установленным общим ключом, а также
часто применяется для хранения конфиденциальных данных. Например, /iSP.NET
использует 3DES для шифрования данных cookie для ярлыка форм опознавания.
В таблице 4.2. представлены характеристики алгоритмов симметричного
шифрования, доступных в .NET Framework. Хотя эти алгоритмы работают
по-разному, .NET Framework предлагает стандартизированную модель через класс
Симметричный алгоритм.
Таб. 4.2. Алгоритмы симметричного шифрования .NET Framework
^ззвание Размер блока Режим шифра Длина ключа
j*^ 64 CBCECB.CFB 56 бит
Фойной DES 64 CBC,ECB,CFB Два или три
56-бит. ключа
R|Jndael (AES) 128,192,256 СВС и ЕСВ 128,192,
~ или 3556 бит
** 64 CBC,ECBfCFB 40,48,56,64,
72,80,88,96,104,
114,120,или128 бит

Глава 4 * Шифрование личных данных
Кроме предоставления доступа к различным алгоритмам шифрования, .Nj>
Framework также позволяет подгонять режим шифра, длину ключа, блокироват
размер, а также некоторые другие параметры. Режим шифра определяет режим
операции шифра. Хотя перечисление Режим Шифра включает в себя пять
различных режимов, только три из них поддерживаются существующими алгоритмами
как показано в таблице 4.2. Опции режима шифра следующие:
■ Режим электронного кодировочного листа (ЭКЛ) Самый простой и
быстрый режим, позволяет вскрывать гипертекст одним блоком и позволяет
компиляцию кодировочного листа. Зашифрованные блоки могут быть
перемещены без оказания влияния на все сообщение. Этот режим эффективен только
там, где выполнение является важнейшим приоритетом за счет безопасности.
■ Режим сцепления блоков шифра (СБШ) Этот режим использует вектор
инициализации (ВИ) для добавления обратной связи к блоку
трансформации. Это предотвращает проблемы, возникающие с режимом ЭКЛ.
Шифрование предполагает знание ВИ, но он не является секретной
информацией, и можно передавать его по незащищенным соединениям.
■ Режим обратной связи шифра (ОСШ) использование ВИ как СБШ не
работает с частичными блоками, делая его подходящим для шифрования
потока данных.
Подсказка
Хотя все симметричные алгоритмы, доступные в .NET Framework блочные шифры,
вы можете получить доступ к ним через потоко-ориентированное
проектирование. Однако они все же остаются блочными шифрами, и вам не стоит смешивать
их с потоковым шифром, которые не всегда так безопасны.
Полное применение всех симметричных алгоритмов и установок в действие с
файлом symmetric.aspx вы можете увидеть на директории загрузки
дополнительного кода \Ch04 в электронной версии этой книги (www.syngress.com /soluiio**§/•
Рис.4.1. показывает, как выглядит эта страница.

Шифрование личных данных • Глава 4
Рис. 4.1. Образец симметричной криптографии.
**
Чья, Л М «ttKpMw
Symmetric Cryptography Example
HadtfeethaCMb
»
»!***• *t {BjtM>
|скЭ
Zf>tt$t>fcV>*Mr«»ty»
|м™
. —.- 4
(Mb*wn»*l4tel*liA>- «CM ]§|
HtiiJee'iritloMtcicMMBMt» *j
11 PSD« »* 0» 17 1АД7 14«S«»«MU «0 ™
DES и 3DES
Стандарт Шифрования Данных (DES) был разработан в 1977 году
Правительством США как официальный стандарт криптографии; этот стандарт широко
применяется и по сей день. DES положен в основу опознавания кода персональной
идентификации (PIN) первых банковских автоматов и, до недавнего времени,
использовался как основной метод шифрования для UNIX машин. DES - это блочный шифр,
использующий 64-битовый блок с длиной ключа 56 бит. В начале 1990-х годов, была
доказана неэффективность защиты предоставленной возможностями текущего
оборудования и вероятность того, что все потенциальные комбинации ключей DES
возможно исчерпать менее чем за один день. Тройной DES (также известный как 3
UES) призван искоренять недостатки DES. 3DES использует стандарт шифрования
*Ь> прогоняя его через себя по циклу 3 раза, используя разный набор ключей
шифрования с одним циклом. Это был простой способ эффективно увеличить размер
К)ча с 56 до 168 бит, повышая, таким образом, безопасность, но очевиден так же
т°т факт, что шифрование данных занимает в три раза больше времени, чем DES.
возможно, DES подходит к завершающей стадии своего существования, a 3DES
Настолько эффективен, как другие алгоритмы, но, тем не менее, они оба оста-
Ся Доминирующими в выборе алгоритмов. Многие программисты делают свой
°р именно в их пользу из-за их совместимости и всеобщего признания.
-NET Framework обеспечивает доступ к этим алгоритмам через классы
^•ryptoServuceProvider и TripleDESCryptoServiceProvider. Заметьте, что оба
класса управляются автоматическим переходом на строку, что может вызвать
и в управлении функций Win32 CryptoAPI.

160 Глава 4 * Шифрование личных данных
Подсказка
Хотя DES и 3DES не используют управляемые коды, можно получить некоторь^
внедрения открытого источника этих классов, которые содержат полностью
управляемый код. Внедрения открытого источника .NET Framework включают моно
проект (www.go-mono.com) и DOtGNU Portable.NET (www.soyjjWj
storm.com.ou/portable nethtml). Заметьте, однако, что собственные классы .NET
Framework, которые вызвали criptoIPP были сертифицированы ФСОИ 140-1
(см. http://scr.nistgov/crvptval/140-l/140 vend.htm)/
iiHi Рис. 4-2- Шифрование 3DES с ASP.NET: С#
private void tripleDESO
{
string plainText = "This is a secret for 3DES";
Response.Write("plainText: " + plainText + "<br>");
byte[] buffer = ASCIIEncoding.ASCII.GetBytes(plainText);
TripleDESCryptoServiceProvider des =
new TripleDESCryptoServiceProvider();
des.GenerateKey();
des.GeneratelV();
string encryptedString = Convert.ToBase64String(
des.CreateEncryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Encrypted string: " + encryptedString + "<br>");
buffer = Convert.FromBase64String(encryptedString);
string decryptedString = ASCIIEncoding.ASCII.GetString(
des.CreateDecryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Decrypted string: " + decryptedString + "<br>")'
Рис- 4-3- Шифрование 3DES с ASP.NET: VB.NET
Private Function tripleDESO
Dim plainText As String = "This is a secret for 3DES"
Response.Write("plainText: " + plainText + "<br>")
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)

Шифрование личных данных • Глава 4
Dim des As New TripleDESCryptoServiceProvider
des.GenerateKey()
des.GenerateIV()
Dim encryptedString As String = _
Convert.ToBase64String( _
des.CreateEncryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
Response.Write("encryptedString: " + encryptedString + "<br>")
buffer = Convert.FromBase64String(encryptedString)
Dim decryptedString As String = _
ASCIIEncoding.ASCII.GetString( _
des.CreateDecryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
Response.Write("Decrypted string: " + decryptedString + "<br>")
End Function
DES обладает несколькими ключами, которых следует избегать, поскольку они
не достаточно надежны. На самом деле, существует 4 ключа, которые производят
те же подключи. Это означает, что если вы шифруете данные одним из этих ключей,
а затем расшифровываете данные, при помощи этого же ключа, вы, в конечном
итоге, получите оригинальное сообщение. Кроме этих слабых ключей, существуют также
12 полуслабых ключей. Полуслабые ключи применяются парами, в которых один
ключ расшифровывает данные зашифрованные другим. ASP.NET позволяет
проводить проверку методами IsWeakKey и IsSemiWeakKey. Увидеть действительный
исходный текст для метода IsWeakKey можно на рис.4.4., метода IsSemiWeakKey на рис.4.5.
^одсказка
\ Можно загрузить исходный текст для основных классов криптографии .NET
\ Framewoi^cwvw.gotdotnetcom/team/clr/samples/eula clr crvptoscr.aspx.
ч
fyg-4.4. Исходный текст метода IsWeakKey .NET Framework
Public static bool IsWeakKey(byte[] rgbKey) {
if (IIsLegalKeySize(rgbKey)) {
throw new CryptographicException(
Environment.GetResourceString(
'cryptography_InvalidKeySize") ) ;
}

Глава 4 * Шифрование личных данных
UInt64 key = QuadWordFromBigEndian(rgbKey);
if ((key == 0x0101010101010101) ||
(key == Oxfefefefefefefefe) ||
(key == OxlflflflfOeOeOeOe) I I
(key == OxeOeOeOeOflflflfl)) {
return(true);
}
return(false);
Рис-4,5- Исходный текст метода IsSemiWeakKey .NET Framework
public static bool IsSemiWeakKey(byte[] rgbKey) {
if (!IsLegalKeySize(rgbKey)) {
throw new CryptographicException(
Environment.GetResourceString(
"Cryptography_InvalidKeySize"));
}
UInt64 key = QuadWordFromBigEndian(rgbKey);
if ((key == OxOlfeOlfeOlfeOlfe) ||
(key == OxfeOlfeOlfeOlfeOl)
(key == OxlfeOlfeOOeflOefl)
(key == OxeOlfeOlfflOeflOe)
(key == OxOleOOleOOlflOlfl)
(key == OxeOOleOOlflOlflOl)
(key == OxlffelffeOefeOefe)
(key == OxfelffelffeOefeOe)
(key == OxOllfOllfOlOeOlOe)
(key == OxlfOllfOlOeOlOeOl)
(key == OxeOfeeOfeflfeflfe)
(key == OxfeeOfeeOfeflfefl)) {
return(true);
return(false);
Обратите внимание, что автоматически образованные ключи и ключи, образов
ные методом GenerateKey никогда не бывают слабыми, и шансы случайного выбора од
ного из них равняется 1 к 18,014,398, 509, 482, 000. Более того, классы DES и

Шифрование личных данных • Глава 4
пропущены через Исключения Криптографии, если вы попытаетесь использовать
слабый ключ.
длгоритм Rijndael
Принимая во внимание, что DES подходит к завершению своего
эффективного использования, a 3DES не более чем временная замена, многие специалисты
занимаются поисками других алгоритмов. Национальный институт стандартов
и технологий (НИСТ) недавно сделал выбор в пользу Rijndael в качестве
официальной замены DES. Эту спецификацию, относящуюся к Улучшенному стандарту
шифрования (УСШ) можно посмотреть на http/://csrc.nist.gov/publications/
fins/fips!97/fips-197.pdf. Rijndael предлагает ключи большего размера, чем DES,
но лучшего качества, чем 3DES. Спецификация Rijndael предлагает ключи
размером 128, 192 или 256 бит.
Поскольку стандартизацию этого алгоритма поддерживает правительство,
ожидается повсеместная замена DES на этот алгоритм, хотя ASP.NET все ещё
полагается на DES и 3DES. Однако Rijndael - это алгоритм по умолчанию,
используемый с классом СимметричныхАлгоритмов и представляет собой единственный
алгоритм, который полностью выполняется в управляющем коде. Рис. 4.6. и рис. 4.7.
приводят пример использования шифрования Rijndael в ASP.NET. Заметьте, что
шифрование Rijndael не имеет никаких известных слабых ключей, и
следовательно, не поддерживает метод IsWeakKey.
Шифр Rijndael самый быстрый и обеспечивает самые большие по размеру
ключи по сравнению со всеми остальными шифрами .NET Framework.
Рис. 4.6. Шифрование Rijndael: C#
Private void rijndael ()
{
string plainText = "This is a secret for Rijndael";
Response.Write("plainText: " + plainText + "<br>");
byte[] buffer = ASCIIEncoding.ASCII.GetBytes(plainText) ;
RijndaelManaged rijndael = new RijndaelManagedO;
riJndael.GenerateKey();
riJndael.GenerateIV();
string encryptedString = Convert.ToBase64String(
rijndael.CreateEncryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Encrypted string: " + encryptedString + "<br>");

(l64 Глава 4 * Шифрование личных данных
buffer = Convert.FromBase64String(encryptedString);
string decryptedString = ASCIIEncoding.ASCII.GetString(
rij ndael.CreateDecryptor() .TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Decrypted string:" + decryptedString + "<br>");
Рис. 4.7. Шифрование Rijndael: VB.NET
Private Function rijndaelEncryption()
Dim plainText As String = "This is a secret for Rijndael"
Response.Write("plainText: " + plainText + "<br>")
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)
Dim rijndael As RijndaelManaged = New RijndaelManaged
rijndael.GenerateKey()
rijndael.GeneratelV()
Dim encryptedString As String = _
Convert.ToBase64String( _
rijndael.CreateEncryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
Response.Write("encryptedString: " + encryptedString + "<br>")
buffer = Convert.FromBase64String(encryptedString)
Dim decryptedString As String = _
ASCIIEncoding.ASCII.GetString( _
rijndael.CreateDecryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
Response.Write("Decrypted string: " + decryptedString + "<br>')
End Function
RC2
RC2 - это симметричный блочный шифр, разработанный Рональдом Ривес
том из компании RSA. RC2 был задуман как прямой заменитель DES, улучша*0
щий исполнение и предлагающий изменяемые размеры ключа. RC2 обычно ис
пользуется в S/MIME безопасной электронной почте и предполагается, что о
работает в два-три раза быстрее, чем DES. Полная спецификация RC2 дотсуп**

Шифрование личных данных • Глава 4
^rjvjptf.org/rfc/rfc2268.txt. Рис. 4.8. и рис.4.9. представляют примеры ис-
льзования шифрования RC2. Также как Rijndael, RC2 не имеет известных сла-
ключей и, следовательно, не поддерживает метод IsWeakKey.
RC2 - широко применяемый алгоритм, допускающий разную длину ключа, но нуж-
иМеть в виду, что эксперты считают маленькие ключи RC2 небезопасными. Всегда
спользуйте 128-битный ключ, что составляет максимально допустимую длину.
рис. 4.8. Шифрование RC2: С#
private void rc2 ()
{
string plainText = "This is a secret for RC2";
Response.Write("plainText: " + plainText + "<br>");
byte[] buffer = ASCIIEncoding.ASCII.GetBytes(plainText);
RC2CryptoServiceProvider rc2 = new RC2CryptoServiceProvider();
rc2 .GenerateKey();
rc2.GenerateIV();
string encryptedString = Convert.ToBase64String(
rc2.CreateEncryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Encrypted string: " + encryptedString + "<br>");
buffer = Convert.FromBase64String(encryptedString);
string decryptedString = ASCIIEncoding.ASCII.GetString(
rc2.CreateDecryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Response.Write("Decrypted string: " + decryptedString + "<br>");
}
Private Function rc2Encryption()
Dim plainText As String = "This is a secret for RC2"
Response.Write("plainText: " + plainText + "<br>")
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)
Dim rc2 As New RC2CryptoServiceProvider
rc2.GenerateKey()
rc2.GenerateIV()
Dim encryptedString As String = _
Convert.ToBase64String( _
rc2.CreateEncryptor().TransformFinalBlock( _

Глава 4 • Шифрование личных данных
buffer, 0, buffer.Length))
Response.Write("encryptedString: " + encryptedString + "<br>")
buffer = Convert.FromBase64String(encryptedString)
Dim decryptedString As String = _
ASCIIEncoding.ASCII.GetString( _
rc2.CreateDecryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
Response.Write("Decrypted string: " + decryptedString + "<br>")
End Function
Выбор алгоритма
Выбор алгоритма симметричного шифрования зависит от длины ключа,
совместимости, выполнения и персональных предпочтений. Очень сложно доказать,
что той или иной алгоритм более надежен, хотя отсутствие уязвимости в течение
определенного периода, уже само по себе достаточное доказательство.
Надежность алгоритма основывается на длине ключа, однако это не является гарантией,
что тот или иной алгоритм не имеет дефекта.
Внимание
Во время написания настоящей книги ни о каких дефектах этих алгоритмов,
кроме ограничения длины ключа, неизвестно. Известно, однако, что некоторые
правительственные агентства тратят много средств и усилий для обнаружения
дефектов в этих алгоритмах. Если такое агентство когда-нибудь обнаружит (или уже
обнаружило), дефект, можете быть уверены, что это станет одним из наиболее
охраняемых секретов. Скорее всего, они пойдут на увеличение длины ключа, чтобы
создать впечатление, что у них нет никаких клише дефектов алгоритмов.
Когда безопасность стоит выше исполнения, нужно избегать незащищенности
данных, наслаиванием множества алгоритмов, как показано на рис. 4.10. и 4.11-
Поскольку Крипто Потоки позволяют сцепление, обеспечение множества
уровней шифрования.
Рис. 4.10. Наслаивание Симметричных Шифров: С#
private void layeringSymmetricCiphers()
{
string plainText = "This is a secret for Layering Ciphers";
Response.Write("plainText: " + plainText + "<br>");
byte[] buffer = ASCIIEncoding.ASCII.GetBytes(plainText);

Шифрование личных данных • Глава 4
moryStream encryptedMemoryStream = new MemoryStream();
D-HndaelManaged rijndael = new RijndaelManaged();
rijndael.GenerateKey ();
rijndael.GenerateIV();
RC2CryptoServiceProvider rc2 = new RC2CryptoServiceProvider();
rc2 .GenerateKey();
rc2.GenerateIV();
// Chain the streams together for encryption
CryptoStream CryptoStream = new CryptoStream(
new CryptoStream(encryptedMemoryStream, rc2.CreateEncryptor(),
CryptoStreamMode.Write), rijndael.CreateEncryptor(),
CryptoStreamMode.Write);
CryptoStream.Write (bugger,0, buffer.Length);
CryptoStream.FlushFinalBlock ();
string encryptedString = Convert.ToBase64String(
encryptedMemoryStream.ToArray ( ));
Response.Write ("Encrypted string:" + encryptedString + "<br>");
//Prepare for decryption
MemoryStream decryptedMemoryStream =
new MemoryStream (encryptedMemoryStream.ToArray ( ));
buffer = new byte [decryptedMemoryStream.ToArray( ).Length[;
//Unchain the streams for decryption
CryptoStream = new CryptoStream(
new CryptoStream (decryptedMemoryStream, rc2.Createdecryptor ( )
CryptoStreamMode.Read), rijndael.CreateDecryptor ( ).
CryptoStreamMode.Read);
CryptoStream.Read (buffer, 0, buffer.Length);
string decryptedString = ASCIIEncoding.ASCII.GetString (buffer);
Response.Write ("Decrypted string:" + decryptedString + "<br>");
J^4.11. Наслаивание Симметричных Шифров: VB.NET
ate Function layeringSymmetricCiphers()
°im plainText As String = "This is a secret for Layering Ciphers"

168 Глава 4 * Шифрование личных данных
Response.Write("plainText: " + plainText + "<br>")
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)
Dim encryptedMemoryStream As MemoryStream = New MemoryStream
Dim rc2 As RC2CryptoServiceProvider = New RC2CryptoServiceProvid<
rc2.GenerateKey()
rc2.GenerateIV()
Dim rijndael As RijndaelManaged = New RijndaelManaged
rij ndael.GenerateKey()
rij ndael.GeneratelV()
' Chain the streams together for encryption
Dim cryptoStream As CryptoStream = New CryptoStream( _
New CryptoStream(encryptedMemoryStream, rc2.CreateEncryptor, _
CryptoStreamMode.Write), rijndael.CreateEncryptor, _
CryptoStreamMode.Write)
cryptoStream.Write(buffer, 0, buffer.Length)
cryptoStream.FlushFinalBlock()
Dirr encryptedString As String = Convert.ToBase64String( _
encryptedMemoryStream.ToArray())
Response.Write("Encrypted string: " + encryptedString + "<br>")
' Prepare for decryption
Dim decryptedMemoryStream As MemoryStream = _
New MemoryStream(encryptedMemoryStream.ToArray())
' Unchain the streams for decryption
cryptoStream = New CryptoStream( _
New CryptoStream(decryptedMemoryStream, rc2.CreateDecryptor(), _
CryptoStreamMode.Read), rijndael.CreateDecryptor(), _
CryptoStreamMode.Read)
cryptoStream.Read(buffer, 0, buffer.Length)
Dim decryptedString As String = ASCIIEncoding.ASCII.GetString (buff er'
Response.Write("Decrypted string: " + decryptedString + "<br>")
End Function

Шифрование личных данных • Глава 4
Vrтановка ключа и векторов инициализации
Результат гипертекста определяет целый ряд параметров. Чтобы расшифро-
гипертекст, нужно использовать тот же алгоритм и те же параметры. Два
пара, которые нужно каждый раз менять, - это ключ и вектор инициализации
тИ) Ключ - это жизненно важный секрет для гарантированного сохранения це-
гтности данных, а вектор инициализации обеспечивает случайность и
уникальность блоков гипертекста.
Если вы шифруете данные каждый раз с одним и тем же ключом, вы всегда бу-
ете получать один и тот же гипертекст. Зная это, взламыватель может собрать
достаточно данных для расшифровки сообщения. Чтобы не допустить этого,
алгоритмы симметричного шифрования используют ВИ для инициализации процесса,
гарантирующего уникальность гипертекствового сообщения. Получатель
сообщения должен знать и ключ и ВИ для расшифровки сообщения, но только ключ
должен оставаться в секрете.
Внимание
| Чтобы создать новый ключ и ВИ, никогда не извлекайте одно из другого, так как,
f узнав ВИ, взламыватель сможет определить и ключ. Также избегайте
фиксированных ВИ для всего шифрования. Лучший выход это использовать случайный
/ ; ВИ, который алгоритм автоматически создает при инициализации.
При изменении ключа возникает несколько сложностей, особенно, когда это
касается общего ключа без каких-либо приоритетных секретов. Причина
шифрования заключается в том, что вы не доверяете передающей среде.
Следовательно, нужно каким-то образом передать ключ через незащищенные соедине-
ния, но если у вас уже есть безопасное соединение, зачем вам нужно дальнейшее
шифрование? Предположим, на пример, что вы хотите переслать кому-то
зашифрованное сообщение. Получатель не сможет прочитать ваше сообщение, пока
1 не предоставите ему соответствующий ключ. Нет никакого смысла в отправ-
ключа вместе с сообщением, поэтому, чтобы сообщить получателю ключ, вы
°ните ему по телефону. Но раз уж вы доверяете безопасности телефонной ли-
и настолько, что можете сообщать ключ, почему бы вам не зачитать и само со-
Щение по телефону? В этом заключается основной недостаток симметричной
" нтографии, но его можно преодолеть с помощью алгоритмов изменения
д Ча и использования ассиметричной криптографии. Для приложения
•JNET это не такая большая проблема, поскольку можно использовать SSL для
новки безопасного сеанса.
*аще всего вы будете использовать симметричное шифрование для сохране-
**Увствительных установок или данных пользователя. Проблема заключается в

Глава 4 * Шифрование личных данных
том, ваше ASP.NET приложение должно знать ключ и, следовательно, сохран
его для собственного использования.
Это представляет собой проблему, потому что, если взламыватель проника
приложение, он может получить доступ и к ключам приложения. Наприм
ASP.NET использует файл machine.comfit для хранения ключей многих операц -
шифрования, таких как шифрование ярлыка форм опознавания. Если взламьт
тель сможет получить доступ к чтению этого файла, он может фальсифицироват
ярлык. Для предотвращения этой ситуации можно использовать DPAPI, рассмот
ренный ниже в этой главе. Нужно также разработать ваше приложение таким
образом, чтобы вы могли регулярно менять ваши ключи.
Возможно, иногда, вы захотите, чтобы ваши пользователи могли шифровать
информацию так, чтобы даже у вас не было к ней доступа. Пользователь
применяет ключ и затем получает доступ к зашифрованным данным. Однако обычно очень
не практично ожидать от пользователя запоминания длинного ключа
шифрования. Если для них становится проблемой даже запомнить обычный пароль,
состоящий из шести или восьми символов, как они могут запомнить 128-разрядный
ключ? Выходом из этой ситуации может стать разрешение пользователю вводить
пароль, который вы используете для извлечения соответствующего ключа.
Метод PasswordDeriveBytes.CryptDeriveKey может воспроизвести подходящий
ключ, основываясь на пароле, алгоритме и ряде других взаимодействий. Этот
метод создает хэш пароля, используя salt, и использует этот хэш для создания
другого хэша, повторяя этот процесс столько раз, сколько обозначено взаимодействий.
Результат - длинная строка, подходящая для использования в качестве ключа.
Рис.4.12. и 4.13. представляет код для использования CryptDeriveKey, а рис. 4.14.
показывает пример ключа, извлеченного из пароля пользователя.
Внимание
Имейте ввиду, что хотя можно использовать CryptDeriveKey для превращения
короткого пароля в надежный ключ, не забывайте, что ключ будет настолько
надежным, насколько надежен сам пароль. Однако использование большого
количества взаимодействий, несомненно, замедлит атаку грубого подбора, поскольку
взламыватель вынужден будет выполнять всю последовательность этих
взаимодействий при каждой новой попытке подбора пароля. Для инструмента взлом
пароля, каждая миллисекунда играет большую роль.

Шифрование личных данных • Глава 4
4.12- Использование CryptDeriveKey: C#
rivate void cryptDeriveKeyExample()
{
// set initial values
string password = "ThisIsMyPassword";
string salt = "ThisIsMySalt";
string algname = "RC2";
string hashName = "MD5";
byte[] IV = new byte[8];
int keySize = 128;
// Create and PasswordDeriveBytes
PasswordDeriveBytes pdb =
new PasswordDeriveBytes(password,
ASCIIEncoding.ASCII.GetBytes(salt));
// Extract Key
byte[] key = pdb.CryptDeriveKey(algname, hashName, keySize, IV);
Response.Write("derived key: " + Convert.ToBase64String(key) +
"<br>") ;
дд Рис. 4.13. Использование CryptDeriveKey: VB.NET
Private Function cryptDeriveKeyExample()
set initial values
Dim password As String = "ThisIsMyPassword"
Dim salt As String = "ThisIsMySalt"
Dim algname As String = "RC2"
Dlm hashName As String = "MD5"
Dim iv() as Byte = New Byte(7) {}
Dim keySize As Integer = 128
Create and PasswordDeriveBytes
1ш Pdb As PasswordDeriveBytes = _
ew PasswordDeriveBytes(password, _
AScHEncoding. ASCII. GetBytes (salt) )

Глава 4 • Шифрование личных данных
' Extract Key
Dim key As Byte() = pdb.CryptDeriveKey(algname, hashName, keySize, jVv
Response.Write("derived key: M + Convert.ToBase64String(key) + "<br>"\
End Function
Рис. 4.14. Пример извлечения ключа из пароля
*»ynwti *rt Cryptography tHwxfAe rttcrosoft Internet t •
■ FftV*r
ttp/flocrfiost/dvpteriW/vb neyayptopeoe/webformj.epx
Symmetric Cryptography Example
Hacking the Code
[RfjndMl (AES)
Mode loc .yj
Padding PKCS7
Inrttebzation Vector (IV) tW№2fjMSbfkSoA9ATeeTo--
K*f |latmein
Plaintext
Sempl. Plaintext
Cyphertext (Raw)
С pKertext (Bytes)
lhMl-.A*rrH*L$ftoieiu\)-'.'tCbS)fl
Il9 40 12 «2 CI F7 EO 10 A4 CC 1С A4 A6 EF 92 40 ^
Э1 F3 DC 29 06 27 BA A7 24 43 «2 S3 A9 E6 6C в0
U
При использовании режимов СВС или CFB нужно установить вектор инициализа
ции. ВИ работает также как почва, для дальнейшего преобразования данных таким о
разом, чтобы два сообщения простого текста зашифрованных с помощью одного
образовывали уникальный гипертекст. Это затрудняет применение атаки подбора
словарю против гипертекста. Нужно использовать случайное число для ВИ, котор
Симметричный алгоритм создает автоматически при создании класса. Прочитав
это свойство и сохраните ИВ, чтобы позже вы смогли расшифровать гипертекст,
ли вы создаете ваш собственный ВИ, он должен быть той же длины, что и ключ,
мните, что ВИ не конфиденциален, и вам не нужно принимать никаких специалЫ*
мер по его защите. Рис. 4.15. и 4.16. показывают, как можно добавлять ВИ так, чТ°
хранить их вместе, а также способ извлечения ВИ и расшифровки гипертекста.

Шифрование личных данных • Глава 4
рис 4Д5- Сохранение ВИ с гипертекстом: С#
ivate void savinglVWithCipherText()
tring plainText = "This is a secret for savinglVWithCipherText";
Response.Write("plainText: " + plainText + "<br>");
hyte[] buffer = ASCIIEncoding.ASCII.GetBytes(plainText);
RijndaelManaged rijndael =
new RijndaelManagedO ;
rijndael.GenerateKey();
rijndael.GeneratelV();
// perform encryption
byte[] encryptedBytes =
rijndael.CreateEncryptor().TransformFinalBlock(
buffer, 0, buffer.Length);
// append IV to beginning of encrypted string
byte[] encryptedByteArrayWithlV =
new byte[encryptedBytes.Length + rijndael.IV.Length];
for (int x=0; x < rijndael.IV.Length; x++)
encryptedByteArrayWithlV[x] = rijndael.IV[x];
for (int x=0; x < encryptedBytes.Length; x++)
encryptedByteArrayWithlV[rijndael.IV.Length + x] =
encryptedBytes[x];
// Display ciphertext with IV appended
string encryptedStringWithlV =
Convert.ToBase64String(encryptedByteArrayWithlV);
Response.Write("Encrypted string with IV: " +
encryptedStringWithlV + "<br>");
'' remove the IV from the beginning of the encrypted string
byte[] decryptedBytesWithlV =
Convert.FromBase64String(encryptedStringWithlV);
¥te[] decryptedIV = new byte[rijndael.IV.Length];
yte[] decryptedBytes =
new byte[decryptedBytesWithlV.Length - rijndael.IV.Length];
for (int x=0; x < decryptedIV.Length; x++)
decryptedIV[x] = decryptedBytesWithlV[x];
for (int x=0; x < decryptedBytes.Length; x++)

Глава 4 * Шифрование личных данных
decryptedBytes[x] =
decryptedBytesWithIV[decryptedIV.Length + x];
// decrypted the ciphertext using the retrieved IV
rijndael.IV = decryptedIV;
string decryptedString = ASCIIEncoding.ASCII.GetString(
rijndael.CreateDecryptor().TransformFinalBlock(
decryptedBytes, 0, decryptedBytes.Length));
Response.Write("Decrypted string: " + decryptedString + "<br>") .
}
Рис. 4.16. Сохранение ВИ с гипертекстом: VB.NET
Private Function savinglVWithCipherText()
Dim plainText As String = "This is a secret for
savinglVWithCipherText"
Response.Write("plainText: " + plainText + "<br>")
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)
Dim rijndael As RijndaelManaged = New RijndaelManaged
rijndael.GenerateKey()
rijndael.GeneratelV()
' Perform encryption
Dim encryptedBytes As Byte() = _
rijndael.CreateEncryptor().TransformFinalBlock( _
buffer, 0, buffer.Length)
' append IV to beginning of encrypted string
Dim encryptedByteArrayWithIV() As Byte = _
New Byte ( (encryptedBytes.Length - 1) + (rijndael.IV.Length -
D) {}
Dim x As Integer
For x = 0 To rijndael.IV.Length - 1
encryptedByteArrayWithlV(x) = rijndael.IV(x)
Next
For x = 0 To encryptedBytes.Length - 1
encryptedByteArrayWithlV((rijndael.IV.Length - 1) + x) = ^
encryptedBytes(x)
Next

Шифрование личных данных • Глава 4
• Display ciphertext with IV appended
Dim encryptedStringWithlV As String = _
Convert.ToBase64String(encryptedByteArrayWithlV)
Response.Write("Encrypted string with IV: " + _
encryptedStringWithlV + "<br>")
» remove the IV from the beginning of the encrypted string
Dim decryptedBytesWithlV As Byte() = _
Convert.FromBase64String(encryptedStringWithlV)
Dim decryptedIV As Byte() = New Byte(rijndael.IV.Length - 1) {}
Dim decryptedBytes As Byte() = _
New Byte((decryptedBytesWithlV.Length - 1) - _
(rijndael.IV.Length -1)) {}
For x = 0 To decryptedIV.Length - 1
decryptedIV(x) = decryptedBytesWithlV(x)
Next
For x = 0 To decryptedBytes.Length - 1
decryptedBytes (x) = decryptedBytesWithlV((decryptedIV.Length - 1) +
x)
Next
' decrypted the ciphertext using the retrieved IV
rijndael.IV = decryptedIV
Dim decryptedString As String = ASCIIEncoding.ASCII.GetString(
rijndael.CreateDecryptor().TransformFinalBlock( _
decryptedBytes, 0, decryptedBytes.Length))
Response.Write("Decrypted string: " + decryptedString + "<br>")
End Function
Симметричная криптография имеет свои ограничения и слабые стороны, но
°на играет важную роль в защите данных. .NET Framework дает хорошую
поддержку Для хорошо установленных симметричных шифров, и вы всегда сможете
зашифровать данные. Установите надежную инфраструктуру для шифрования ещё
а ранней стадии проектирования вашего приложения.
Способы защиты
* Используйте надежные симметричные шифры для гарантирования
секретности данных.

Глава 4 * Шифрование личных данных
■ Никогда не полагайтесь на XOR, ROT-13, или какие бы то ни было
любительские алгоритмы шифрования.
■ Избегайте DES, используете его только в случаях крайней необходимости
для обратной совместимости; рассматривайте 3DES как совместимый вариант
■ Используйте шифрование Rijndael/УСШ для обеспечения лучшей защиты
и исполнения.
■ Когда используете шифрование RC2, применяйте 128-разрядные ключи,
каждый раз, когда это возможно.
■ При высоком приоритете безопасности и низком выполнении,
рассмотрите алгоритмы шифрования разделения слоев.
■ При создании ключа и ВИ не извлекайте одно из другого.
■ Используйте CryptDriveKey для создания ключа из пароля пользователя.
Использование ассиметричной криптографии
Исходное положение: Ассиметричная криптография эффективно
работает с публичными коммуникациями, но она
намного медленнее симметричной криптографии.
Угроза: Утечка информации, нарушение целостности
данных, атаки «Человек-в-середине», атаки
грубого подбора.
Ассиметричная криптография предназначена для обмена ключа
симметричной криптографии и результатами масштабности, использованием публичных
и частных моделей ключа. Симметричная криптография пользуется только одним
ключом для шифрования и расшифровывания всех данных, а ассиметричная
криптография использует два разных ключа - один для шифрования, другой для
расшифровывания. Идея метода заключается в том, что можно свободно распр
странять ваш публичный ключ, который может использоваться другими для шиф
рования данных, получить доступ к которым можете только вы, при помощи ваш
го частного ключа.
Два ключа извлекаются математическим способом из одного основного клю4
г О"
который затем уничтожается. С математической точки зрения, невозможно
здать один ключ из другого без этого основного ключа; следовательно, вы моЖе

Шифрование личных данных • Глава 4
пространять ваш публичный ключ без опасения скомпрометировать вашу сис-
ему. Поскольку можно свободно распространять ваш публичный ключ, этот ме-
оД решает проблему передачи ключа.
тсказка
* Несмотря на то, что ассиметричная криптография позволяет использовать общий
< ключ, очень важно защитить ваш частный ключ. Поэтому не следует хранить
частный ключ в вашем web-приложении.
Одной из проблем использования ассиметричной криптографии является то,
что для каждого пользователя, с которым вы общаетесь, вам понадобится
отдельный ключ, так же как и им для всех, с кем общаются они Если у вас два человека,
обменивающихся зашифрованной информацией, одного ключа будет достаточно.
Если три человека хотят общаться безопасно, вам понадобятся все три ключа; для
четырех человек понадобятся шесть ключей, а для пяти - десять. Как вы уже
заметили, количество требуемых ключей быстро возрастает, существенно
ограничивая масштабность симметричной криптографии. Ассиметричная криптография
при решении этой проблемы использует единый публичный ключ для всех
пользователей; поддерживая хороший уровень целостности, любой пользователь может
использовать этот ключ для общения с другими пользователями.
Ассиметричная криптография интенсивная и, следовательно, редко
используемая для шифрования всей коммуникации в целом, компилирующая программа.
Многие приложения используют ассиметричную криптографию для замены
ключа сеанса, а затем используют симметричный шифр для шифрования трафика в те-
чениее этого сеанса.
Поскольку ассиметричная криптография часто имеет дело с кодом, как
клиента, так и сервера, очень редко можно увидеть её использование для внедрения
пользователей на большинстве публичных вэб-приложений. Тем не менее, вы
обнаружите, что ассиметричная криптография используется в сочетании с другими
технологиями, такими как SSL. Протокол SSL использует ассиметричное шифро-
Вание для установки симметричного ключа сеанса для безопасной замены данных.
^-устанавливает безопасность и целостность web-коммуникаций и устанавливает
°Длинность сервера к клиенту (и возможно клиента к серверу).
Более подробно о SSL вы узнаете ниже в этой главе.
работа с алгоритмами хэширования
"сходное положение: Алгоритмы хэширования - это односторонняя
функция, используемая для подтверждения
целостности данных.

Глава 4 * Шифрование личных данных
Угроза: Утечка информации, нарушение целостное*
данных, атаке
бого подбора.
данных, атаки «Человек-в-середине», атаки гп
Даже несмотря на то, что шифрование является важной частью защиты дан
ных, иногда важно доказать, что данные не были модифицированы. Можно
сделать это при помощи алгоритмов хэширования (алгоритмы проверки
Целостности). Хэш - это односторонняя функция. Она преобразовывает данные таким
образом, выдавая результат хэша (который иногда называют дайджест), при котором
невозможно произвести вычисление для создания оригинального сообщения.
■ Принимая любую длину на входе, на выходе они производят
фиксированную длину.
■ Они должны быть значительными и быстро вычисляться.
■ Они должны быть защищены от инвертирования.
■ Они должны быть устойчивы к столкновениям.
Функция хэша принимает на входе строку любой длины и производит строку
с фиксированной длиной. Это означает, что хэши можно применять как по
отношению к чему-то очень маленькому, например, пароли, так и по отношению к
чему-то с большим объемом, например, весь документ. Хэшируемые алгоритмы,
предлагаемые .NET Framework очень эффективные и быстрые, что делает их
целесообразными для многих приложений. Самое важное свойство хэша это его
размер. Большой хэш с трудом инвертирует функцию, что гарантирует, что функция
свободна от столкновений.
Так как функции хэша имеют фиксированный выход, но неограниченный
вход, множество значений может произвести тот же хэш. Однако можно
использовать эти маленькие контрольные суммы файла, или хэши для дальнейшего
подтверждения целостности данных.
Ещё одно распространенное использование хэша - это демонстрация кому-т
части информации без действительного её обнаружения. Например, чтобы до*
зать, что вы знаете пароль, вы можете отправить действительный пароль или с
здать и отправить хэш этого пароля.
Это очень важно для опознавания web-сайтов, потому что сервер не должен
хранять пароли - ему нужны только их хэши.
.NET Framework поддерживает хэшируемые алгоритмы, перечисленные в т
лице 4.3.

Шифрование личных данных • Глава 4 1
Таблица 4.3. Хэшируемые алгоритмы, доступные в .NET Framework
""""название Класс Длины хэша
MD5
SHA1
SHA256
SHA384
SHA512
MDA5 CryptoServiceProvider
SHA lCryproServiceProvider
SHA Managed
DHA 256 Managed
SHA 384 Managed
SHA 512 Managed
128 бит
160 бит
256 бит
384 бит
512 бит
Алгоритм MD5, определенный RFC 1321, возможно самая хорошо известная
и широко используемая хэш функция. Это самый быстрый из всех хэшируемых
алгоритмов, но использует самое маленькое 128 разрядное значение хэша, что
делает его самым уязвимым к атакам. MD5 подвержен частичным столкновениям, и он
не сможет противостоять атакам при увеличении аппаратного обеспечения. Тем
не менее, на сегодняшний день это самый широко используемый алгоритм.
SHA это алгоритм, разработанный Национальным агентством безопасности
(NSA) и был опубликован NIST как FIPS PUB 180.Разработанный для
использования со Стандартом цифровой подписи (DSS), SHA производит 160-разрядные
значения хэша.
Оригинальная спецификация SHA, опубликованная в 1993 году, была вскоре
изъята NSA и superceded исправленным FIPS PUB 180-1, отнесенной к SHA1.
Причиной изъятия оригинальной спецификации NSA послужило исправление
дефекта оригинального алгоритма, сокращающего криптографическую защиту.
Однако NSA никогда не уточняло, какой именно дефект был исправлен, заставляя
тем самым исследователей проводить тщательную проверку обоих алгоритмов.
Именно из-за такой тщательной проверки защиты SHA считается безопасным.
С тех пор NIST опубликовала ещё три варианта SHA-1, которые производят бо-
Лее большие x3ihh:SHA-256, SHA-384 и SHA - 512. Не смотря на то, что с большим
Размером хэшей эти алгоритмы должны обладать большей защитой, они не
подергаются столь тщательному анализу как SHA-1. Тем не менее, длина хэша играет
^Кную роль в защите от атак грубого подбора и birthday атак.

180 Глава 4 • Шифрование личных данных
\i
Об атаке Birthday.
Атаки дня рождения основаны на уникальных проблемах с дотируемыми
алгоритмами, созданных на концепции под названием Парадокс Дня
Рождения. Эта загадка основывается на том, что в комнате, в которой
находятся 183 человека, существует 50% вероятности того, что у кого-то
из них дата рождения совпадет с вашей. Однако если вы хотите обнаружить
двух людей с такой же датой рождения с вероятностью в 50%, как это
не удивительно, но вам понадобятся только 23 человека в комнате. Для
функции хэширования это означает, что гораздо легче обнаружить два
совпадения, если вам все равно какие именно они будут. Возможно заранее
просчитать хэши заданной длины пароля для определения возникновения
столкновений.
Подтверждение целостности
Можно использовать хэши для подтверждения целостности, но многие
разработчики используют их не правильно, снижая их эффективность. Например,
многие вэб-сайты, позволяют загружать файл вместе с checksum MD5 этого файла.
Они делают это для того, чтобы вы могли подтвердить целостность файла, но вы
загружаете cheksum с того же местоположения и через те же соединения,
что и сам файл. Если вы не доверяете файлу настолько, что на самом деле хотите
проверить хэш, как можно доверять хэшу, полученному с того же
местоположения? Если кому-то удастся модифицировать файл, он также легко может
вычислить и сохранить новый хэш.
Подсказка
Чтобы подтвердить целостность загружаемого файла, многие web-сайты наряду0
суммой MD5 предоставляют подпись PGP этой суммы. Сумма MD5 подтверждает
целостность, а подпись PGP подтверждает подлинность суммы MD5. ^
Если вы храните хэши в секрете, они эффективны для подтверждения Д
ных, таких как cookie. Например, предположим, вы написали cookie обозрева
лю Интернет клиента и сохранили хэш этого cookie в вашей базе данных. КогД
позже, клиент возвращает этот cookie, можно просчитать этот хэш и сравни
его с тем, который хранится в вашей базе данных, чтобы убедиться, что он не о

Шифрование личных данных • Глава 4
меНен. Так как ASP.NET полностью сохраняет сеансы и маркеры опознавания
cookie, а не на сервере, он вычисляет хэш данных cookie и зашифровывает как
анные, так и хэш. Этот зашифрованный результат расшифровывается и
сохраняется в cookie на стороне клиента. При возврате cookie клиентом, сервер
расшифровывает строку и подтверждает хэш. Таким образом, ASP.NET защищает хэш и
секретность данных.
Еще один способ защиты хэша - это использование алгоритма хэша
снабженного ключами. Такие хэши похожи на обычные, с тем лишь исключением, что они
основаны на секретном ключе. Чтобы подтвердить хэш или создать подложный,
зам необходимо знать этот ключ.
.NET Framework предлагает два алгоритма хэшей, снабженных ключами:
■ HMACSHA 1 Эта функция производит опознавательный код сообщения
основанного на хэше, основываясь на алгоритме хэширования SHA 1.
HMACSHA 1 совмещает оригинальное сообщение и секретный ключ и
использует SHA 1 для создания хэша. Затем хэш снова комбинируется с
секретным ключом и создается второй хэш SHA1. Также как и SHA 1,
алгоритм HMACSHA 1 производит 160-разрядные хэши.
■ MACTripleDES Этот алгоритм использует тройной DES для шифрования
сообщения, сбрасывая все, кроме последних 64 разрядов гипертекста.
Используя алгоритмы ключевого хэширования, можно отправлять хэш с
данными, но нужно сохранять секретный ключ. Заметьте, что этот метод не имеет
ограничений схожих с обменом ключа в симметричной шифровании. Рис. 4.17. и
4.18. демонстрирует применение функции HMACSHA 1.
Рис. 4.17. Использование HMACSHA 1: С#
Private void HMACSHAlExample()
{
// Setup
string plainText = "This is a secret for HMACSHAlExample";
Response.Write("plainText: " + plainText + "<br>");
byte[] key = ASCIIEncoding.ASCII.GetBytes("SecretKey") ;
bYte[] data = ASCIIEncoding.ASCII.GetBytes(plainText) ;
fI Perform Hash
HMACSHA1 hmac = new HMACSHA1(key);
kyte[] result = hmac.ComputeHash(data);

fl82 Глава 4 • Шифрование личных данных
Response.Write("HMACSHAlExample results:" +
Convert.ToBase64String(result) + "<br>");
Рис. 4.18. Использование HMACSHA 1: VB.NET
Private Sub HMACSHAlExample()
' Setup
Dim plainText As String = "This is a secret for HMACSHAlExample"
Response.Write("plainText: " + plainText + "<br>")
Dim key() As Byte = ASCIIEncoding.ASCII.GetBytes("SecretKey")
Dim data() As Byte = ASCIIEncoding.ASCII.GetBytes(plainText)
' Perform Hash
Dim hmac As HMACSHA1 = New HMACSHA1(key)
Dim result () As Byte = hmac.ComputeHash(data)
Response.Write("HMACSHAlExample results: " + _
Convert.ToBase64String(result) + "<br>")
End Sub
Хэширование паролей
Ещё одной важной функцией использования хэшей является хранение
паролей. Как уже было описано в Главе 1, вы не должны хранить действительные
пароли в вашей базе данных. Используя алгоритмы хэширования, можно хранить хэш
и использовать его для опознавания пользователя. Так как образование двумя
паролями одного и того же хэша крайне не желательно, вы можете сравнить
сохраненный хэш с хэшем пароля, полученным от пользователя. Если они совпадут, вы
можете быть уверены, что пароль верный.
Защита паролей с помощью хэшей имеет несколько уникальных проблем. Во-
первых, не смотря на то, что хэши не обратимые, они подвержены взлому
методом грубого подбора. Вы не можете воспроизвести пароль из хэша, но можете
создать хэши миллионов паролей, пока не обнаружите совпадение. Поэтому наде#
ность хэша зависит не от длины ключа алгоритма хэширования, а от длины само
го пароля. И поскольку пароли, обладающие столь низкой энтропией, предсказу^
мы, и зачастую слишком короткие, это не самая сложная задача.
Ещё одной проблемой использования хэшей является то, что одни и те же да**
ные всегда будут производить один и тот же хэш. Это может быть проблемой, еС
ли кто-нибудь получит хэши, потому что он может воспользоваться словарем *э

Шифрование личных данных • Глава 4 1
Й для обнаружения паролей. Чтобы предотвратить это, мы можем добавить
рОЛь соль, чтобы гарантированно получать разные пароли каждый раз. Соль
олжны быть большим случайным числом, специально разработанным для этой
ели. Нет никакой необходимости в сохранении секретности соли, поэтому мож-
хранить её с самим хэшем.
При использовании соли, существует столько возможных хэшей для каждой
части данных, сколько разрядов в соли. Конечно, если злоумышленник получит
доступ к хэшам, он получит доступ и к соли, но суть этого метода заключается
том, чтобы заставить взламывателя просчитывать каждый хэш индивидуально
и не извлекать никакой выгоды из тех паролей, которые он уже взломал. Рис. 4.19.
и 4.20. демонстрируют алгоритмы хэширования, включающие соль.
Рис. 4.19. Хэширование: С#
private void hashExample ()
{
string plainText = "This is a secret for hashExample";
Response.Write("plainText: " + plainText + "<br>");
// Create strong random byte values
byte[] saltBytes = new byte[8];
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider() ;
rng.GetNonZeroBytes(saltBytes);
// Create an array to hold plain text and salt
byte[] plainTextBytes = ASCIIEncoding.ASCII.GetBytes(plainText);
byte[] plainTextAndSaltBytes =
new byte[plainTextBytes.Length + saltBytes.Length];
// Append salt value and create byte array for hash
for (int x=0; x < saltBytes.Length; x++)
PlainTextAndSaltBytes[x] = saltBytes[x];
f°r (mt x=0; x < plainTextBytes.Length; x++)
PlainTextAndSaltBytes[saltBytes.Length + x] =
plainTextBytes[x];
11 Perform hash using SHA1
HashAlgorithm hash = new SHAlManaged() ;
kyte[] hashBytes = hash.ComputeHash(plainTextAndSaltBytes);
^sponse.Write("Hashed string with salt: " +
Convert.ToBase64String(hashBytes) + "<br>");

184 Глава 4 * Шифрование личных данных
*"*""■ Рис. 4.20. Хэширование: VB.NET
Private Function hashExample()
Dim plainText As String = "This is a secret for hashExample"
Response.Write("plainText: " + plainText + "<br>")
' Create strong random byte values
Dim saltBytes() As Byte = New Byte(8) {}
Dim rng As RNGCryptoServiceProvider = New RNGCryptoServiceProvider
rng.GetNonZeroBytes(saltBytes)
1 Create an array to hold plain text and salt
Dim plainTextBytes As Byte() =
ASCIIEncoding.ASCII.GetBytes(plainText)
Dim plainTextAndSaltBytes As Byte() = _
New Byte(plainTextBytes.Length + saltBytes.Length) {}
1 Append salt value and create byte array for hash
Dim x As Integer
For x = 0 To saltBytes.Length - 1 Step x + 1
plainTextAndSaltBytes(x) = saltBytes(x)
Next
For x = 0 To plainTextBytes.Length - 1 Step x + 1
plainTextAndSaltBytes(saltBytes.Length + x) = plainTextBytes(x)
Next
1 Perform hash using SHA1
Dim hash As HashAlgorithm = New SHAlManaged
Dim hashBytes As Byte() = hash.ComputeHash(plainTextAndSaltBytes)
Response.Write("Hashed string with salt: " + _
Convert. ToBase64String (hashBytes) + "<br> ')
End Function
Может показаться, что основа похожа на ВИ. На самом деле, это тот же метод-
используемый для достижения тех же целей. Заметьте, что она также схожа с фу# ь
циями и алгоритмами хэшей, обладающих ключами, а их функции, такие ка
HMACSHA1 являются прекрасными заменителями для кода на рис. 4.20. Чтобы и
пользовать хэш, обладающий ключами, просто используйте соль на месте клю4 '
или же следуйте образцу кода на рис. 4.19.

Шифрование личных данных • Глава 4
Способы защиты
щ Используйте алгоритмы хэширования для подтверждения целостности
и хранения паролей.
■ Для проверки данных можно разрешить другим просматривать хэш,
но нужно защитить его от модификаций.
■ Используйте ключевые алгоритмы хэширования для защиты хэша от
модификаций.
■ Для опознавания пароля, храните хэши в секрете для предотвращения
атак грубого подбора.
■ Добавьте соль в хэш для гарантирования случайности.
Работа со свойствами шифрования .NET
Теперь, когда вы понимаете основы шифрования .NET, необходимо изучить
несколько тем, касающихся этих свойств. В данном разделе мы рассмотрим:
■ Создание случайных чисел
■ Сохранение памяти чистой
■ Защита секретов
■ Защита коммуникаций с помощью SSL
Создание случайных чисел
Исходное положение: Случайные числа - это ключевой момент
криптографии, но компьютеру практически
невозможно быть абсолютно случайным.
Угроза: Утечка информации, нарушение целостности
данных, атаки «Человек-в-с ере дине», атаки
грубого подбора.

86 Глава 4 * Шифрование личных данных
Случайные числа являются ключевым моментом большинства форм кри
графии. В какой- то степени, надежность системы основывается на способно
производить случайные, непредсказуемые числа. Без этой случайности, взламь
тель сможет предугадать криптографические расчеты. Например, SSL шифр0
ние Netscape был взломан в 1995 году, потому, что использовал слабый генерат
случайных чисел.
Поскольку у компьютеров возникают трудности с действительной случайно
тью, они используют так называемые генераторы псевдослучайных чисел
(ГПСЧ). Чтобы использовать в криптографии, ГПСЧ должен обладать энтропией
Энтропия - это мера случайности, которая ведет к непредсказуемости и
выполняет распределение случайных чисел. Надежным генератором случайных чисел
считается такой, который, выдав список образованных чисел, в следующий раз не
восстановит их последовательность.
.NET Framework для образования случайных чисел использует ГПСЧ
Провайдер КриптоУслуг, который является wrapper функции CryptGenRandom
в CryptoAPI. ГПСЧ считается достаточно эффективным, кроме случаев с
повышенными требованиями защиты. Если у вас возникла необходимость в установке
более надежного генератора случайных чисел, зайдите на
www.scheier.cum/yarrue.html и www.irisa.fr/caps/projects/hipsor/HAVEGE.htmL
Заметьте, что CryptoAPI получает энтропию и из достаточно большого набора
факторов системы, но если вы хотите добавить дополнительную энтропию,
можно передать строку или множество байтов при создании класса.
Внимание
При использовании случайных чисел в криптографических целях, всегда
используйте ГПСЧ Провайдер Крипта Услуг, а не класс System.Random.
SystemRandom основан на предсказуемой функции и не считается надежным
генератором случайных чисел.
Способы защиты
■ Используйте только ГПСЧ Провайдер Крипто Услуг для производства на
дежных случайных чисел; избегайте использование System.Random.
■ Используйте внешние источники энтропии для дальнейшего повышен
случайности ГПСЧ.

Шифрование личных данных • Глава 4 18
Очистка памяти
^ 0дцое положение: Тщательно планируйте ваш код для
предотвращения хранения секретов в памяти.
Угооза: Утечка информации.
Работая с чувствительными данными, убедитесь, что не оставили никакой
Формации после работы. Вы не должны допускать хранения незашифрован-
й информации в памяти. Для сокращения возможности забывания чувстви-
ьных данных в памяти, используйте как можно больше изменений, избегайте
кэширования обычного текста, подчищайте память после выполнения операции
шифрования.
Обычно в .NET Framework, «сборщик мусора» удаляет все неиспользуемые
объекты. Но предсказать, когда он это, сделает очень сложно, фактически система не
очищает память, а только помечает её, как доступную для повторного
использования. Именно потому, что важная информация может оставаться в памяти, вам
необходимо всегда очищать память от криптографических объектов и переменных.
Чтобы выполнить это, .NET Framework предлагает метод Clear () для всех
криптографических объектов.
По завершении работы с любыми переменными, имеющими отношение к
шифрованию, удаляйте их содержание. Это касается не только переменных
гипертекста и простого текста, но и крипто объектов, ключей, соли и переменных ВИ. Рис.
4.21. и 4.22. показывает способ выполнения этого.
Рис. 4.21. Очищение объектов, имеющих отношение
к шифрованию: С#
rijndael.GenerateKeyO ;
rijndael.GenerateIV();
'/ Perform encryption
string encryptedString = Convert.ToBase64String(
riJndael.CreateEncryptor().TransformFinalBlock(
buffer, 0, buffer.Length));
Perform decryption
Uffer = Convert.FromBase64String(encryptedString);
string decryptedString = ASCIIEncoding.ASCII.GetString(
rijndael.CreateDecryptor().TransformFinalBlock(
buffer, 0, buffer.Length));

|88 Глава 4 • Шифрование личных данных
// Clean up
rijndael.Clear();
encryptedString = decryptedString = String.Empty;
buffer = null;
„м„, Рис. 4.22. Очищение объектов, имеющих отношение
SB к шифрованию: VB.NET
Private Sub cleaningExample()
' Setup
Dim buffer() As Byte = ASCIIEncoding.ASCII.GetBytes( _
"This is a secret for cleaningExample")
Dim rijndael As RijndaelManaged = New RijndaelManaged
rijndael.GenerateKey()
rijndael.GeneratelV()
' Perform encryption
Dim encryptedString As String = Convert.ToBase64String( _
rijndael.CreateEncryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
'Perform decryption
buffer = Convert.FromBase64String(encryptedString)
Dim decryptedString As String = ASCIIEncoding.ASCII.GetString(
rijndael.CreateDecryptor().TransformFinalBlock( _
buffer, 0, buffer.Length))
' Clean up
rijndael.Clear()
encryptedString = decryptedString = String.Empty
buffer = Nothing
End Sub
Заметьте, что некоторые переменные не имеют методов Clear (), поэтом,
мы эксплицитно zero those out.

Шифрование личных данных • Глава 4
Способы защиты
щ Очистите все переменные, использующиеся с операциями шифрования,
включая простой текст, гипертекст, ключи, соль, АИ и случайные числа
■ Используйте метод С1еаг() для очистки всех чувствительных данных
■ Используйте Dispose () для немедленного освобождения ресурсов памяти.
■ Эксплицитно обнулите любые переменные, которые не поддерживают
метод Clear ().
Защита секретной информации
Исходное положение: Секреты представляют собой ключевой момент
системы защиты, но полностью защитить
данные очень сложно.
Угроза: Утечка информации, нарушение целостности
данных, атаки «Человек-в-середине», атаки
грубого подбора.
Один из самых сложных аспектов безопасного программирования - это
процесс сохранения секретов, даже если сам код скомпрометирован. Хранить секрет
в коде сервер просто, но вы не всегда можете быть уверены в его безопасности.
Многие разработчики ASP обожглись на хранении паролей базы данных в файле
Global .asa, который должен быть защищен.
Даже имеющиеся у нас решения защиты секретных данных не идеальны
и все ещё уязвимы, если кто-то получит доступ к web-серверу.
Используйте шифрование для защиты ваших данных, но ваше
приложение должно хранить ключ расшифровки данных. Ваше приложение должно
иметь доступ к этому ключу, но нужно предпринять меры по
предотвращению постороннего доступа к нему. В конечном итоге, данные важно защи-
Ить от несанкционированного использования, потому что взламыватель
°Жет использовать само приложение для получения доступа. Лучшее, что
ы можем сделать, это ограничить возможность получения доступа к секре-
м- Кроме ключей шифрования должны быть сохранены другие секреты, а
Именно:
и Пароли доступа к другим системам
Строки соединения базы данных

190 Глава 4 * Шифрование личных данных
■ IP-адреса частных серверов
■ Пути к файлам с чувствительными данными
Существует множество способов получения неавторизованного доступа
к web-серверу, некоторые их которых дают взламывателю полный или
частичный контроль над сервером. Ниже приведены примеры типов доступа,
которые взламыватель может получить, используя дефекты Windows, IIS и других
приложений:
■ Возможность просматривания директории содержания web-каталогов
■ Возможность просматривать содержание любых файлов web-директорий
■ Возможность просматривать любые файлы того же раздела, что и
содержание web-директорий
■ Возможность написания файлов на содержание вэб-директории
■ Возможность запуска команды в споре после появления анонимного
пользователя
■ Возможность запуска команды в споре после появления аккаунта
СИСТЕМЫ
■ Возможность to run commands и получать доступ к регистрации под
содержанием SQL сервера или другого аккаунта базы данных
■ Возможность просматривать незашифрованный трафик при его
прохождении по сети
Важным уроком здесь является то, что web-содержангие не всегда защищено.
С одной стороны, взламыватель не всегда может получить полный доступ к ваше
му серверу Ключевым моментом защиты секретной информации является
использование различных методов защиты, что позволит вашему приложению быть
более устойчивым к взламывателям, обладающим частичным доступом.
Некоторые из методов защиты секретной информации:
■ Хранение секретных данных в файле
■ Хранение секретных данных в системном реестре

Шифрование личных данных • Глава 4 1
щ Хранение секретных данных в базе данных
■ Использование API Защиты данных (DPAPI) для получения доступа к
защищенным данным операционной системы
Хранение секретной информации в файле
При использовании файловой системы для хранения секретной информации,
убедитесь, что вы используете файлы, расположенные вне web-корня и
желательно на отдельном разделе. Установите жесткие права доступа к файлу для
ограничения прочтения и написания доступа к этому файлу Вместо жесткого
программирования пути файла, используйте переменные среды. Хотя «защита через
неизвестность» не самый лучший способ защиты файла, избегайте присваивания файлу
слишком очевидного имени, такого как passwords.txt.
.NET Framework предлагает систему хранения, называемую isolated storage,
которая обеспечивает простой метод хранения секретной информации в файле.
Преимущество этого метода заключается в том, что можно ограничить доступ к
хранению доменом пользователя группы или приложения, а также в том, что .NET
Framework берет все подробности управления доступом к файлу на себя. Для
приложения изолированное хранение работает как файловая система. Хранение
возникает как корень контейнера для приложения, где оно может создавать файлы
и директории. Но система изолированного хранения предотвращает выход за
рамки этого контейнера хранения. Изолированное хранение работает особенно
эффективно при наличии множества полудоверительных приложений на том же
сервере. Несмотря на то, что изолированное хранение предоставляет некоторые
механизмы защиты данных, оно не было разработано специально для защиты
секретной информации, поэтому вам не стоит полностью полагаться только на него.
*«с 4.23. и 4.24. показывают примеры хранения и поиска данных из
изолированного хранения.
^ис 4.23. Хранение и поиск данных из изолированного
, хранения:С#
Private void isolatedStorageExample()
{
lf using System.10.IsolatedStorage;
string data = "dataForlsolatedStorage";
'I Prepare isolated storage for writing
Is°latedStorageFileStream isolatedStorage =
new IsolatedStorageFileStream("isolatedStorageExample.txt",

192 Глава 4 • Шифрование личных данных
FileMode.OpenOrCreate, FileAccess.Write);
// write to isolated storage
StreamWriter sw = new StreamWriter(isolatedStorage);
sw.WriteLine(data);
sw.Close();
isolatedStorage.Close ();
// prepare isolated storage for reading
isolatedStorage =
new IsolatedStorageFileStream("isolatedStorageExample.txt",
FileMode.Open, FileAccess.Read);
// read from isolated storage
StreamReader sr = new StreamReader(isolatedStorage) ;
Response.Write("Read form isolated storage:" +
Sr.ReadLineO + "<br>") ;
Sr.Close
}
"■*"»; Рис 4.24. Хранение и поиск данных из изолированного
шшт храненияЛ/B.NET
Private Sub isolatedStorageExample()
' using System.10.IsolatedStorage;
Dim data As String = "dataForlsolatedStorage"
' prepare isolated storage for writing
Dim isolatedStorage As IsolatedStorageFileStream = _
New IsolatedStorageFileStream("isolatedStorageExample.txt",
FileMode.OpenOrCreate, FileAccess.Write)
' write to isolated storage
Dim sw As StreamWriter = New StreamWriter(isolatedStorage)
sw.WriteLine(data)
sw.Close()
isolatedStorage.Close()
' prepare isolated storage for reading

Шифрование личных данных • Глава 4 1
isolatedStorage = New IsolatedStorageFileStream( _
"isolatedStorageExample.txt", FileMode.Open, FileAccess.Read)
1 read from isolated storage
Dim sr As StreamReader = New StreamReader(isolatedStorage)
Response.Write("Read from isolated storage: " + _
sr.ReadLineO + "<br>")
sr.CloseO
find Sub
Хранение секретной информации
в системном реестре
Системный реестр традиционно считался лучшим механизмом для хранения
секретной информации в web-приложении, потому что взламывателю обычно
необходимо обладать более высоким уровнем доступа для прочтения реестра,
чем он может получить из анонимного аккаунта. Например, взламывателю удастся
пояучить доступ через ПБС или общий файл, но для прочтения реестра обычно
требуется отправка кода на сервер. При хранении секретной информации в
реестре, убедитесь, что вы установили жесткие ACL на соответствующие ключи
реестра для ограничения доступа к этим ключам. Также как и с файлами, неизвестность
это не полная защита, но вам следует избегать использования слишком очевидных
имен ключей.
Хранение секретной информации в базе данных
Хранение секретной информации в базе данных может считаться хорошим
методом, особенно, если вы используете доверительные соединения с вашей базой
Данных. Конечно, строка соединения с базой данных сама по себе является секрет-
Ной информацией, поэтому существуют ограничения на этот тип стратегии.
Преимуществом использования базы данных в том, что вы легко можете разде-
■^ть секретную информацию через множественные серверы.
Хранение секретной информации
с использованием DPAPI
DPAPI, возможно, является самым безопасным методом хранения данных,
^Пользующихся операционной системой для управления ключами шифрова-

194 Глава 4 * Шифрование личных данных
ния, но у него существует несколько ограничений. Во-первых, встает выб0п
где хранить данные: машинное хранение или пользовательское хранение. ма
шинное хранение менее безопасно, поскольку доступно каждому на сервере, Но
пользовательское хранение требует загрузки профайла, которое ASP.NET це
поддерживает. Пользовательское хранение может также вызвать сложности
при имперсонализации множества пользователей в web-приложении. Самым
легким способом использования машинного хранения является использование
дополнительной энтропии, для помощи в защите данных от других. Разумеется
нужно хранить эту энтропию в таком месте, где она была бы доступна вашему
web-приложению.
Для использования DPAPI, вам необходимо перевести вызовы P/Invoke
нВ Crypt32.dll. Пример использования DPAPI можно посмотреть на
hup://msnd.microsofl.com/architecture/applivatio/default.aspxppull ^ /library/
eii-us/diinctsec/html/SecNetHToS.asp.
В конечном итоге, лучшим методом хранения секретной информации
является комбинация выше описанных методов. Например, можно использовать
регистрационный ключ для хранения энтропии для доступа к DPAPI и зашифрованные
данные DPAPI, используемые для изолированного хранения. В действительности
же, выбранный вами метод будет зависеть от того, как вы расставляете
приоритеты между безопасностью и выполнением, и то какими правами вы обладаете на
сервере хостинга.
В любом случае, вы не получите абсолютной защиты секретной информации,
и вашей действительно реальной защитой является следование всем методам для
обеспечения безопасности вашего сервера.
Способы защиты
■ Избегайте хранения секретной информации в коде, даже если он
компилирован
■ Никогда не храните секретную информацию в обычном тексте
■ Используйте комбинацию файла, реестра, базы данных или DPAPI для
хранения секретной информации.
■ Используйте неизвестность только в качестве дополнительного уровня
защиты к надежному шифрованию и контролю доступа.

Шифрование личных данных • Глава 4
Защита коммуникаций с SSL
Исходное положение: SSL обеспечивает легкое в применении
шифрование для HTTP соединений.
Угроза: Утечка информации, нарушение целостности
данных, атаки «Человек-в-середине», атаки
грубого подбора.
SSL - это протокол, который включает в себя многие из методов ыифрования,
описанные в этой главе. Не смотря на то, что он достаточно прост в применении,
многие пользователи не имеют никого представления о его основополагающих
технологиях и знают его только как маленькую блокирующую иконку на
обозревателе Интернет. SSL предоставляет основу шифрования и аутентификации для всех
трафиков HTTP.
Клиент и сервер устанавливают сеанс SSL запросом клиента сертификата
у сервера. Сервер отвечает отправкой сертификата и его предпочтениями шифра.
Затем клиент генерирует ключ, подходящий ко всем шифрам, который он
шифрует публичным ключом сервера и передает ключ на сервер. Сервер аутентифициру-
ет себя к клиенту, возвращая сообщение, не аутентифицированное с общим
ключом. Все данные теперь зашифрованы и аутентифицированы ключом,
извлеченным из общего ключа. Процесс может также включать в себя похожий метод
аутентификации клиента. SSL является жизненно важной частью процесса защиты
web-приложения. Он не защищает от всех видов атак, но представляет собой
основу для методов, описанных в данной книге.
Внимание
I Несмотря на многочисленные попытки некоторых компаний продать SSL как ре-
J шение проблем безопасности сервера, важно отметить, что SSL не предоставля-
1 ет защиту самому серверу .SSL аугентифицирует сервер клиенту и гарантирует
Q частность коммуникации между сервером и клиентом. Это цифровой эквивалент
оболочки защиты.
Так как процесс шифрования требует больше циклов ЦПУ, SSL не ставит
дополнительной загрузки на сервер, особенно на медленные процессоры. Поэтому,
Многие операторы web-сайтов делают выбор не в пользу использования SSL, одна-
°> вы, возможно, захотите рассмотреть несколько методов улучшения
выполнения:
• Обновляйте аппаратное обеспечение или загрузку, балансируя через
множество серверов

196 Глава 4 * Шифрование личных данных
■ Используйте SSL усилители аппаратного обеспечения
■ Оптимизируйте web-содержание для минимального трафика
Даже не дорогое обновление аппаратного обеспечения или усилители SSL
могут способствовать дополнительной загрузке, требуемой для SSL трафика.
Заметьте, что большинство дополнительных процессов происходят от первой.проверки
связи, которая включает в себя более медленное ассиметричное шифрование,
используемое для замены ключа сеанса. После того, как ключ установлен, остальной
трафик шифруется симметричным шифрованием, используя этот ключ.
Поскольку большинство симметричных алгоритмов достаточно эффективны,
протокольные данные намного меньше после установки сеанса.
Подсказка
Некоторые web-сайты, пытаясь избежать протокольных данных SSL, используют
его только при первоначальном процессе аутентификации, а затем снова
переходят к нормальному HTTP соединению. Однако многие протокольные данные
процесса используются для первоначальной проверки связи сеанса, что
включает в себя ассиметричную криптографию. Таким образом, если вы проходите
через процесс инициализации сеанса SSL, нужно сохранять соединение SSL для
остального трафика также.
SSL всегда важно, но в некоторых случаях его использование необходимо:
■ При передаче чувствительной информации
■ При использовании форм аутентификации
■ При использовании основной аутентификации
Ошибка, которую допускают программисты, - это не сохранение сеанса SbL,
после того как пользователь аутентифицировался при помощи основной аутенти
фикации. С основной аутентификацией обозреватель Интернет автоматическ
отправляет логин пользователя с каждым запросом. Вы не только должны сохра
нять SSL соединение, но также следить за тем, что все элементы страницы, таки
как изображения, таблицы стилей и скрипты, также проходили через SSL соеД^н
ния. Один из способов избежать этого - использовать уникальное имя вашего ->э
трафика, такое как secure.example.com.

Шифрование личных данных • Глава 4 1
5SL основан на хорошо поставленной инфраструктуре публичного сертифи-
а но технология не может восполнять человеческие недостатки. Обозрева-
лъ Интернет пользователя может показывать блокирующую иконку, но несколь-
пользователей откроют сертификат web-сайта, чтобы убедиться, что он
действительный.
Если они сделают это, возникнет возможность создания подложной
информации, которая будет выглядеть также как и подлинная. Даже если обозреватель
Интернет предупреждает пользователя о недействительном сертификате, многие
пользователи все равно продолжат просмотр web-сайта. Единственный способ
предотвратить этот тип атаки - это предоставить подробную информацию по
вашему сертификату и научить пользователей работать с SSL и сертификатами SSL.
Способы защиты
■ Всегда используйте SSL для защиты чувствительной информации HTTP
трафика.
■ Обновляйте аппаратное обеспечение или используйте SSL усилители для
управления процессом протокольных данных SSL.
■ Выполнив сеанс, сохраняйте SSL его как можно дольше.
■ Убедитесь, что вы используете SSL для всех элементов страницы.
■ Научите пользователей работать с SSL и сертификатами SSL.

198 Глава 4 * Шифрование личных данных
Краткая справка по стандартам кодирования
Использование шифрования в ASP.NET
Симметричное шифрование
• Никогда не полагайтесь на XOR, ROT-13 или любые любительские
алгоритмы шифрования.
• Избегайте использования DES, кроме случаев крайней необходимости,
для обратной совместимости. Рассматривайте 3DES как совместимую
альтернативу.
• Используйте шифрование Rijndael/УСШ для лучшей защиты и исполнения.
• По возможности применяйте 128-разрядные ключи.
• При определении защиты как первостепенного приоритета и исполнения
как второстепенного, учитывайте алгоритмы уровневого шифрования,
используя CryptoStreams.
• При создании ключа и ВИ, не извлекайте один их другого. Используйте
случайный ключ и ВИ образованные при инициализации класса.
• Используете CryptoDeriveKey для создания ключа шифрования из пароля
пользователя.
Работа с алгоритмами хэширования
• Используйте алгоритмы хэширования для подтверждения целостности
данных, а также хранения и подтверждения паролей.
• Для подтверждения данных, храните хэши в безопасном месте так, чтобы
их не возможно было модифицировать.
• Используйте ключевые алгоритмы хэширования, такие как НМАССНА1
для защиты хэшей.
• Для аутентификации пароля, сохраняйте секретную информацию хэшеи
для предотвращения атак грубого подбора.
• Добавьте соль в хэш или используйте алгоритм хэширования для
обеспечения случайности.

Шифрование личных данных • Глава 4
работа со свойствами шифрования .NET
Создание случайных чисел
в Используйте только rnC4CiyptoServiceProvider для создания надежных
случайных чисел; избегайте использования System.Random.
в Используйте внешние источники энтропии для дальнейшего повышения
случайности ГПСЧ.
Очистка памяти
• Используйте метод Clear () для очистки чувствительных данных на
криптографических объектах.
• Используйте метод Dispose () для немедленной очистки ресурсов памяти.
• Эксплицитно обнулите все переменные, которые не поддерживают
метод Clear ().
Защита секретной информации
9 Избегайте хранение секретной информации в коде, даже если он
компилирован бинарно.
• Никогда не храните никакой секретной информации в простом тексте.
• Используйте комбинацию файл, реестр, база данных или DPAPI для
хранения секретной информации.
• Используйте неизвестность только как дополнительный уровень защиты.
Защита коммуникаций с SSL
• Всегда используйте SSL для защиты чувствительного трафика HTTP.
• Обновляйте аппаратное обеспечение или используйте усилители SSL для
управления процессом протокольных данных SSL.
• После установки сеанса, сохраняйте SSL как можно дольше.
• Убедитесь, что вы используете SSL для всех элементов страницы.

200 Глава 4 • Шифрование личных данных
Краткая справка по проверке кода
Использование шифрования в ASP.NET
Использование симметричного шифрования
• Использует ли приложение хорошо установленные алгоритмы
шифрования, избегая слабых методов шифрования и методов кодирования?
• Использует ли приложение DES, когда 3DES работает как совместимая
замена?
• Извлекает ли приложение ключ из ВИ или ВИ из ключа, вместо того,
чтобы использовать надежный генератор случайных чисел?
• Избегает ли приложение использования жестко запрограммированных
значений для ВИ?
Работа с алгоритмами хэширования
• Использует ли приложение алгоритмы хэширования, где целесообразно
гарантировать целостность данных?
• Сохраняет ли приложение хэши вместо действительных паролей в базе
данных?
• Сохраняет ли приложение хэши в безопасном месте?
• Использует ли приложение ключевые алгоритмы хэширования везде,
где это возможно?
• Добавляет ли приложение соль во все хэши?
Работа со свойствами шифрования .NET
Создание случайных чисел
• Использует ли приложение только rnCHCryptoServiceProvider для образе
вания надежных случайных чисел, избегая System.Random?
• Требует ли система дальнейшей энтропии, кроме той, что обеспечивает
CryproAPI?
Очистка памяти
• Приложение удаляет все переменные, используемые в операциях шифр0
вания, включая и переменные для простого текста, гипертекста, ключей,
ВИ и случайных чисел?

Шифрование личных данных • Глава 4
# Вызывает ли приложение метод Clear () для всех криптографических
объектов?
# Вызывает ли приложение метод Dispose () для всех криптографических
объектов?
# Обнуляет ли приложение все переменные, которые не поддерживают
метод Clear ()?
Защита секретной информации
в Избегает ли приложение сохранения жестко-программируемой секретной
информации?
• Использует ли приложение комбинацию защитных методов, таких как
файловая система, реестр, база данных и использование DPAPI для
сохранения секретной информации?
• Использует ли приложение незаметность там, где это целесообразно в
качестве дополнительного уровня защиты?
Защита коммуникаций с помощью SSL
© Всегда ли приложение использует SSL для защиты восприимчивого HTTP
трафика?
• Использует ли приложение SSL для всех элементов страницы, включая
изображения, таблицы стилей и клиентские скрипты?

202 Глава 4 * Шифрование личных данных
FAQ
Вопросы (В) и ответы (О)
В: Должен ли я использовать алгоритмы шифрования, основанные на
CryptoAPI или управляемые версии этих алгоритмов?
О: Ответ на этот вопрос зависит от ваших частных требований. Можно
предпочесть всегда использовать управляемый код, но функции CryptoAPI намного
быстрее и сертифицированы FIPS 140-1.
В: Могу ли я воспользоваться методом GetHashCode, вместо создания MS5 или
SHA-1 хэшей?
О: Метод GetHasaCode производит ключ хэша, который эффективен при
работе со структурами, например таблицы хэша. Производимые им хэши не
обладают свойствами защиты, требуемыми для криптографического
использования.
Bl Как можно получит*» достиг к некоторым свойствам CryptoAPI, которыми
.NET Framework не обладает?
О: CryptoAPI предлагает много расширенных свойств, для которых .NET
Framework не предусматривает wrappers. Прочитайте статью «Расширение
.NET Шифрования с GAPICOM иУ/Invoke» на
hUp://msdn.imcrosufk^
Ъr'dry/en'uн/dnc'лpi/html/щtcт^^icйpi.гspщзlя более вродробной информации.
Bl Должен ли я всегда использовать самый бодьшой по размеру хэш, SHA-512,
при создании хэшей?
О: В некоторых сценариях самый большой по размер хэш может быть
эффективен, но это зависит от того, что вы хэшируете. Нет никакого смысла
использовать SHA 512 для хэширования 8-символьного пароля, так как взламы-
ватель просто применит атаку грубого подбора пароля, а не самого хэша.
В: Я использую CryptDeriveKey для создания ключа из пароля. Я знаю, что
пароль сократит эффективную длину ключа, но какой будет эквивалент длины
ключа 8-символьного пароля?
0я. Общепринято, что благодаря ограниченному ключевому пространству и
повторяющейся природе английского языка, существует 1,3 бит энтропии для
каждого 8-разрядного символа. Чтобы достичь эквивалента 128-разрядного
ключа, пользователю понадобится 98-символьный пароль, и 8-символьныи
пароль будет грубо равняться использованию 10-разрядного ключа шифр0"
вания. Однако если вы используете пароль со случайными буквами, числам**
и символами, можно достичь немногим более чем 6 бит энтропии на сим-

Шифрование личных данных • Глава 4
вол, так что 8-символьный случайный пароль будет грубым эквивалентом 50-
разрядного шифрования.
о- Чтобы сократить обработку протокольных данных SSL, должен ли я
использовать 40-разрядное шифрование вместо 128-разрядного?
О: Большинство протокольных данных приходят от первоначальной проверки
связи процесса. После того как сеанс установлен, вы заметите небольшое
выполнение, полученное использованием намного более слабого
40-разрядного шифрования.

Глава 5
м>**
ф\М .-v../ •"
#«>■
f -- 1ц
Решения в этой главе:
а Введение
U Управление злонамеренным входом
Вынужденный выход , ^
Ограничение подверженности
} справка по стандартам копирования
U Краткая справка по проверке кода
Итог
Решения Fast track
FAQ
205

206 Глава 5 • Фильтры на входе в систему
Введение
На протяжении всей этой книги мы рассматриваем все многообразие
опасностей и риска защиты системы безопасности. Но ни одна из этих опасностей не
может сравниться с тем, когда взламыватель поражает самое сердце и атакует код
вашего приложения. Многие разработчики столкнулись с somber реальностью того
что их коды не защищены; и хакеры взламывают их, не используя ничего, кроме
обнаружения дефекта в самом web-приложении. Манипулируя входом программы
взламыватели зачастую провоцируют сервер на раскрытие данных пользователей
или получение прав доступа к неавторизованным файлам или расширениям кода
программ на самом сервере. В самом деле, незащищенный код становится
источником бесчисленных вторжений.
Незащищенный код подвержен риску по нескольким причинам:
■ Существует огромное количество способов взлома незащищенного кода.
■ Нет никакой необходимости в получении пароля, поскольку код уже
работает в контексте аутентифицированного пользователя.
■ Взламыватель получает доступ ко всему, к чему имеет доступ
web-приложение, что обычно включает в себя и восприимчивые данные пользователей.
■ Многие web-приложения не разработаны, в достаточной мере, для защиты
и предотвращения этих типов атак.
Каждую неделю разработчики безопасности рассылают списки (mailing lists)
такие как BugTraq и Vuln Watch с раскрытием дефектов защиты коммерческих
или широко доступных web-приложений. Пока многие программисты изучают
способы избежания незащищенности кода, существует и нескончаемый поток
программистов, подвергающих риску пользователей, потому, что не фильтруют вход
на свое приложение.
Ниже перечислены несколько распространенных опасностей, вызванные
плохой фильтрацией входа:
■ Вторжение SQL Манипулирование входом пользователя для построения
утверждения SQL, которое выполняется в базе данных сервера.
■ Пересечение директории Получение доступа файлов за пределами
границ web-приложения манипуляцией входа с символами пересечения
директории. Этот вид атаки также известен как double dot attack.

Фильтры на входе в систему • Глава 5
Я Получение доступа к коду сервера Раскрытие содержания кода сервера
или файлов конфигурации манипулированием входом для маскировки
настоящего расширения файла.
■ Доступ к файловой системе Манипулирование входом для чтения,
написания или удаления защищенных файлов на диске.
■ Отказ в обслуживании Провоцирование приложения на чрезмерное
потребление ресурсов или остановку функционирования.
■ Утечка информации Постоянная отправка неверного входа для
получения сообщения об ошибке, которое может содержать информацию,
способствующую атаке.
■ Межсайтинговый скриптинг Внедрение HTML или скриптинговых
команд, заставляющих web-приложение атаковать других пользователей.
■ Command Injection Внедрение специальной оболочки метасимволов,
манипулирование входом каким-нибудь другим способом, провоцирующим
сервер использовать код по выбору взламывателя.
■ Переполнение буфера Переполнение буфера отправкой данных в
большем объеме, чем он может управлять, что ведет к сбою приложения или
выполнению кода по выбору взламывателя.
Не смотря на огромное многообразие атак, web-разработчики все же имеют
большое преимущество: эти атаки абсолютно предотвратимы использованием
фильтрации и хорошим применением кодирования.
Запрет на злонамеренный доступ
До того как взламыватель сможет взломать ваше приложение злонамеренным
Входом, ему необходимо получить ваш код. Именно в этом и есть преимущество
^«-разработчиков. Тщательно идентифицируя и контролируя вход, можно
предотвратить атаки еще до того, как взламыватель получит доступ к вашему коду.
Стратегии управления входом, которые мы рассмотрим, следующие:
* Идентификация источников входа
' Оборонительное программирование

208 Глава 5 - Фильтры на входе в систему
Идентификационные ресурсы системы
Исходное положение: Иногда скрытые источники входа пользователя
представляют наибольшую опасность.
Угроза: Злонамеренный вход.
Определение многочисленных способов входа в ваше приложение - это уже
решение половины проблемы злонамеренного входа. Все атаки самого приложения
основаны на некоторых формах манипуляции входа разрешенного пользователя. Если вы
управляете формой входа должным образом, можно избежать если не всех
то большинство этих уязвимостей. Форма входа и строка запроса - это не все, чем
нужно управлять, нужно контролировать любые другие данные, которые взламыватель
может модифицировать. Часто упускаемые из вида - это непрямые источники входа
и данные, к которым, как вы считаете, взламыватель не сможет получить доступ.
В приложении ASP.NET самым очевидным местом поиска входа является
любое место, где вы используете объект Request. ASP класс предоставляет объект
Request как свойство объекта Server. Для установки совместимости с
существующим кодом ASP, ASP.NET предлагает класс HttpRequest через свойство Request
класса Page. Класс HttpRequest exposes элементы запроса HTTP через его
многообразные свойства. Таблица 5.1. демонстрирует некоторые из этих свойств и их
взаимосвязь с другими элементами запроса HTTP
Таблица 5.1
Свойство Источник
Обозреватель Интернет Предположительно основан на заголовке
предоставленного клиентом UserAgent
Сертификат клиента Основан на заголовках сертификата клиента
Cookies Заголовок Set-Cookie от клиента
Форма Отправка данных с клиента
Заголовки Все заголовки Http
Путь Parsed с URL
ПутьИнфо Parsed с URL
Строка запроса Parsed с URL
Переменные сервера Сочетание данных сервера и клиента
Пересылка на URL Заголовок пересылки с клиента
UserAgent Заголовок UserAgent с клиента
UserHost Name Сервер DNS ^^^^*

Фильтры на входе в систему • Глава 5
Легкий способ обнаружения потенциальных дефектов вашего кода - это иссле-
ование всех ссылок на объект Request, чтобы убедиться, что вы управляете входом
пользователя в полной мере. Как будет рассмотрено дальше в этой главе, вы всегда
лясны фильтровать данные, полученные с объекта Request и никогда не должны
напрямую связывать объект Request со строкой. Например, рассмотрите этот код:
[С#]
Response.Write("Welcome " + Request.QueryString["Username"]);
[VB.NET]
Response.Write("Welcome " & Request("UserName"))
В данном примере, код напрямую выпускает содержание переменной
UserName без подтверждения или фильтрации его содержания. Это
распространенный, но совершенно точно, не безопасный метод. Лучшим решением является
фильтрация входа до работы с данными, как показано ниже:
[с#]
string userNameSafe=FilterInput(Request.QueryString["UserName"]);
Response.Write("Welcome " + userNameSafe);
[VB.NET]
userNameSafe=FilterInput(Request("UserName"))
Response.Write("Welcome " & userNameSafe)
В этом примере код вызывает пользовательскую функцию Filterlnput, которую
вы создаете для выполнения любой фильтрации, необходимой для типа данных.
Другие способы контроля
Объект Request самый распространенный источник входа, но пользователь
может осуществлять и непрямой вход или через менее очевидные источники.
пользователь может вводить данные напрямую в вашу базу данных или
манипулировать заголовками HTTP, отправленными на ваш сервер. На пример, рассмотри-
е код ASP показанный на рис. 5.1. Этот код из страницы управления ошибками
^р (найден по умолчанию на C:\WINNT\Help\iisHelp\common\500-l00/asp),
IIS5 использует для управления серверными ошибками. Подразумевает-
я» что в случае возникновения ошибки она покажет подробности, если только за-
Рос будет отправлен на «Local Host», основанный на проверке содержания
перечной сервера SERVER_NAME.

Глава 5 • Фильтры на входе в систему
Рис. 5.1. Источник ASP Из 500-100.ASP
• Only show the Source if it is available and the request is from the same
• machine as IIS
If objASPError.Source > "" Then
strServername = LCase(Request.ServerVariables("SERVER_NAME"))
strServerIP = Request.ServerVariables("LOCAL_ADDR")
strRemotelP = Request.ServerVariables("REMOTE_ADDR")
If (strServername = "localhost" Or strServerIP = strRemotelP)
And_ objASPError.File <> "?" Then
Response.Write Server.HTMLEncode(objASPError.File)
If objASPError.Line > 0 Then Response.Write ", line " &_
objASPError.Line
If objASPError.Column > 0 Then Response.Write ", column " &
objASPError.Column
Response.Write "<br>"
Response.Write "<font style=""COLOR:000000;_
FONT: 8pt/llpt courier newM,,><b>"
Response.Write Server.HTMLEncode(objASPError.Source) & "<br>"
If objASPError.Column > 0 Then Response.Write_
String ( (objASPError.Column - 1), "-") & ff/s<br>"
Response.Write "</bx/font>"
blnErrorWritten = True
End If
End If
Сервер извлекает переменную SERVER_NAME из заголовка хоста,
предоставленного клиентом. Этот заголовок хоста с клиента основывается на том, какой IP-адрес
принимает имя «Local Host». Обычно этот IP-адрес указывает на loopback, 127.0.0.1, но
кто-то может отредактировать свои HOSTS файлы так, чтобы они указывали на любой
IP-адрес. Если бы взламыватель ввел IP-адрес вашего web-сайта, как IP-адрес LocalHost
в свой HPSTS файл, он мог бы перейти на ваш Local Host и похитить ваш web-сайт.
Более того, заголовок хоста клиента вернет Local Host и сервер покажет все детали
ошибки. С IIS 6 Microsoft зафиксировал это, удалив проверку для LocalHost и
показывая детали ошибки, только если IP-адрес сервера совпадает с удаленным IP-адресом.
Примечание
Редактирование файлов HOSTS - это только один способ выполнения этого типа
атаки. Взламыватель может также использовать инструмент или скрипт для
построения пользовательского HTTP запроса с любым заголовком на его усмотрение.

Фильтры на входе в систему • Глава 5
Ещё один пример неожиданного входа пользователя - это имя DNS хоста для
клиента. Если взламыватель контролирует противоположные входы DNS для его
тр.ддресов, потенциально он может использовать это имя хоста для
злонамеренного входа или обмана ограничений контроля прав доступа.
Важно учитывать все источники входа, включая также и входы с вашей
внутренней системы или от внутренних пользователей. Вместо того чтобы атаковать
ваш сервер напрямую, взламыватель, возможно, посчитает, что было бы проще
обойти с обратной стороны и войти там, где вы меньше всего этого ожидаете -
с доверенного источника.
Способы защиты
■ Идентифицирует все случаи объекта Request, чтобы быть уверенным, что
вы тщательно отфильтровали все входы.
■ Отыщите и отфильтруйте другие формы непрямого входа, включая и вход
с самого приложения.
Защитное программирование
Исходное положение: Предотвращение уязвимости приложения
требует основательной практики кодирования.
Угроза: Злонамеренный взлом.
Ни один из типов атак приложения, попавших в поле зрения за последние
несколько лет, не требовал ничего большего, кроме применения разумного и
предсказуемого защитного кодирования. К сожалению, до недавнего времени, лишь некоторые
web-разработчики находили время, мотивацию или тренинги для построения этого
Дополнительного кода в своих приложениях. Но нескончаемый поток выявляемых
уязвимых мест приложения, все больше убеждает в необходимости применения
защитного кодирования. Несмотря на то, что защитное кодирование не всегда может
являться для вас важнейшим приоритетом, от вас не потребуется больших усилий,
если вы будете выполнять несколько простых методов для повышения защиты кода.
Контрольные переменные
Поскольку все пользователи так или иначе связаны с переменными, а вы кон-
Ролируете переменные, то вы контролируете и вход пользователя. В языке
программирования Perl есть свойство, называемое TaintMode, которое воспринимает
*** входы пользователей как сомнительные, и, следовательно, небезопасные. Бо-
*ее того, все переменные, полученные из сомнительных переменных, также ста-

Глава 5 • Фильтры на входе в систему
новятся сомнительными. Вы не можете выполнить какие-либо операции с сомни,
тельными переменными, пока не очистите или не отфильтруете их.
В ASP NET нет эквивалента такого свойства, но web-разработчики могут
написать код, используя тот же подход. Для этого необходимо убедиться, что вы всегда
присваиваете вход пользователя к переменной, сначала пропустите код через
функцию фильтрации, для того чтобы убедиться, что вход безопасен для
использования. Затем убедитесь, что вы работаете только с неочищенными
переменными, а не с необработанным входом пользователя.
Подсказка
Для того чтобы вам было легче отслеживать чистоту переменных, можно
добавлять суффикс к имени переменной после проверки данных на безопасность.
Например: userName_safe = FilterString Request.Form («UserName»).
Убедитесь, что вы никогда не работаете с переменной без суффикса safe.
Классическая ASP позволяет web-разработчикам пользоваться переменными
без их первоначального определения. Для расширения написания переменной
можно воспользоваться директивой Oprion Explicit, но она не активируется
по умолчанию. Использование указания переменной имеет несколько
преимуществ обеспечения безопасности. Указав переменные в вашей системе, вы
получаете список всех данных своей системы кодирования, что представляет собой
прекрасную возможность идентифицировать источники входа пользователя. Указав
переменные, вы контролируете их. К счастью, Vb.NET активирует эту опцию
по умолчанию. Важно также отметить, что С# требует указания переменных.
Классическая ASP имеет другой недостаток: определение типа переменных
в ней не предусмотрено; все переменные представляют собой варианты. К
счастью, CLR представляет надежную систему, но она не устанавливается по
умолчанию VB.NET. Очень важно подразделять переменные на типы, поскольку это
помогает повысить надежность данных и ограничить подверженность атакам.
Определяя тин переменной, вы тем самым ограничиваете тип данных, которые
может содержать переменная. Например, если вы вводите число в запрос SQL,
можно предотвратить вторжение SQL-запросов, потому что числовая
переменная не примет строковые данные, требуемые для команд SQL-запросов. В
классической ASP, тип варианта будет автоматически настраивать согласование
со строковыми данными.
Так как Vb.NET не обеспечивает строгое разделение данных на типы, нуж**
активировать эту опцию. В Visual Studio .NET 2003 можно активировать её, выбра
Tools | Options для получения диалогового окна, показанного на Рис. 5.2.
Выберите пайку Projects и щелкните на VB Fefaults. Затем установите OptlCl
Strict на On. Также, как в случае с указанием переменной, С# автоматически трев>
ет разделение переменных на типы.

Фильтры на входе в систему • Глава 5
рис. 5.2. Активация Option Strict для VB.NET
*j
.-.i Envtronroent
Q Source Control
La Text Edtor
LJ Database Tools
О Debugging
C3 Device Took
HTMLDesigner
Л Projects
VBDefaufcs
VC++8ufcJ
VC++Directories
WebSetbngs
Cj Windows Forms Designer
CJ XML Designer
ОеЫкРг S
Зрйвп
<^pttan§Jairt
©wspare
Централизация кода
Контролирование переменных в некоторой степени включает в себя
фильтрацию или обработку данных в этих переменных. Чтобы не писать код каждый раз,
когда вы принимаете вход пользователя, можно централизовать на код
фильтрации. При проектировании приложения ASP.NET используйте функции
централизованной фильтрации на каждом источнике входа пользователя.
Централизация кода обладает рядом преимуществ:
■ Она организовывает вашу систему и сокращает сложность.
■ Она сокращает появление атаки, сокращая количество кодов.
■ Она позволяет вам быстро фиксировать работу с атаками, которые могут
возникнуть в будущем.
Сложность - враг безопасности. Осуществляя хороший контроль и
организацию системы кодирования, вы сокращаете вероятность уязвимости приложения.
° Целом, сокращение объема кода сокращает сбои, в то время как упрощение
вашей системы и повторное использование уменьшает число атак векторов. Кроме
0го, централизованный код позволяет вам легко настраивать функции
фильтрации для адресации новых атак как знание безопасности и развитие исследований.
Ещё одно преимущество использования централизованного кода в том, что
ректифицировать вход пользователя, которой вы не отфильтровали, очень про-
^°» потому что он переносится на строку в функции фильтрации. Например, ес-
"^ У вас есть функция фильтрации под названием Filterlnput, вы никогда не долж-
^ переходить на объект Request без прохождения через функцию Filterlnput еле-

14
Глава 5 * Фильтры на входе в систему
дующим образом: safelnput = filterlnput (Request.QueryString («Username»))
Соблюдая этот метод, вы легко сможете осуществить поиск для всех ссылок на объ
ект Request снаружи функции Filteringlnput, используя такой инструмент, как Gren
Подсказка
Можно скачать оригинальный порт Win 32 Grep или другие утилиты Unix
с http://unxutils.sourceforge.net/
Тестирование и аудит
Из-за сложности и многообразия атак приложений разного уровня, очень
просто не заметить простых ошибок. Вы всегда должны проверять код защиты,
чтобы убедиться в том, что он на самом деле выполняет то, что вы от него
ожидаете. Например, одно коммерческое web-приложение использует постоянное
выражение для ограничения доступа к определенным административным
страницам, таким образом, что только пользователи локальной системы могли
просматривать их. Для этого приложение проверяло IP-адрес клиента на наличие
выражения «127*». Поскольку любой IP адрес, который начинался с 127 относился к
локальному хосту, программист посчитал, что эта мера ограничит доступ. Однако
он не использовал привязку Л для усиления соответствия с начала строки, потому
что .* означает ноль, заданное им выражение, на самом деле подходило к любому
IP-адресу, содержащему 127 в любом месте адреса, например 192.168.1.127. Взла-
мывателю не составило большого труда найти IP-адрес, содержащий 127 и
полностью обойти это ограничение.
При проектировании надежного плана проверки и тестирования при работе с
различными IP-адресами, программист должен учитывать эту брешь.
Использование эксплицитных ссылок
Многие языки программирования позволяют пользователям применять
«быстрые клавиши» для сокращения печати. Например, если вы не указали
весь путь при получении файла, система подразумевает, что файл находится
текущей рабочей директории.
Это важно при использовании фильтрации входа пользователя, потому чТ
ASP.NET позволяет вам делать ссылки элементов на объект Request без опредеЛ
ния названия специфической совокупности. Например, Request («Password») э
тоже самое, что и Request.Form («Password»). Когда вы ссылаетесь на
обобщенны**
объект Request, ASP.NET осуществляет поиск в совокупностях QueryString, For
Cookies, ClientCertiflcate и ServerVariables для обнаружения совпадений.
Следов

Фильтры на входе в систему • Глава 5
льно, не указав эксплицитно совокупность, вы можете непреднамеренно взять
д из неверного источника. Проблема заключается в том, что QueryString это
первая найденная совокупность.
Рассмотрите код на рис. 5.3. (С#) и 5.4. (VB.NET). Он представляет собой
страницу ASP.NET, которая устанавливает ограничение прав доступа к Локальному
Хосту проверяя IP-адрес клиента, с помощью переменной REMOTE_ADDR. Сервер
сам поддерживает это значение, поэтому метод проверки IP-адреса, показанный
на рис. 5.5., можно считать надежным.
Рис. 5-3- Использование обобщенных ссылок запроса [С#]
<html>
<body>
<%
if (Request.QueryString["REMOTE_ADDR"]== "127.0.0.1")
Response.Write("Access is <b>allowed</b>");
else
Response.Write("Access is <b>not allowed</b> from " +
Request.QueryString["REMOTE_ADDR"]);
%>
</body>
</html>
Рис. 5.4. Использование обобщенных ссылок запроса [VB.NET]
<html>
<body>
<%
If Request("REMOTE_ADDR")="127.0.0.1" Then
Response.Write("Access is <b>allowed</b>")
Else
Response.Write("Access is <b>not allowed</b> from " & _
Request("REMOTE_ADDR"))
End If
Ь
</body>
</ntmi>

Глава 5 • Фильтры на входе в систему
Рис. 5.5. Блокированный IP-адрес
1 99/
fdlt Fawr**s t tteip
http://10.85.0.23/protectedform.aspx
Access is not allowed from 10 85 0 99
46
Проблема этого кода заключается в том, что программисту не удалось
определить специфическую совокупность для использования, поэтому ASP.NET будет
искать в совокупностях QueryString, Form, Cookies и ClientCertificate перед тем как
попробовать совокупность ServerVariables. Зная это, взламыватель может войти
в любую из этих совокупностей с элементом, подходящим к имени переменной
сервера и пройти это препятствие. Например, добавив переменную строки
запроса с именем REMOTE_ADDR и используя адрес 127.0.0.1, можно удалить все IP
ограничения приложения, как показано на рис. 5.6.
Рис 5,6- Доступ IP-адресу с REMOTE_ADDR в строке
запроса разрешен.
http- 10Л5 0.99 protectedform рнГС > С »» "177 ЙЛЛ х_
№ Ptfw**«s «fe goto
fcwfr * .. *» f# Search, ■ f
http://10.85 0 23/prrtectedform.aspx'REMOTE_ADOR-127.0.0.1 jfr ..t***
Access is
from 127 0 0 1

Фильтры на входе в систему • Глава 5
Точно также взламыватель может обмануть и пользователя, передав
переменные на URL, который заменяет форму, cookie или значение логина. Выход из этой
туацИИ очень прост: всегда эксплицитно называйте совокупность, из которой
ы хотите извлечь переменную. Это проиллюстрировано на рис. 5.7. (С#) и 5.8.
(VB.NET), как эксплицитная ссылка на объект Request.ServerVariables. Избегая
уразумеваемых ссылок, можно предотвратить взламывателя от привнесения
двусмысленности в ваш код.
рис. 5.7. Использование обобщенных ссылок запроса [С#]
<html>
<body>
<%
if (Request.ServerVariables["REMOTE_ADDR"]== "127.0.0.1")
Response.Write("Access is <b>allowed</b>");
else
Response.Write("Access is <b>not allowed</b> from " +
Request.ServerVariables["REMOTE_ADDR"]);
%>
</body>
</html>
Рис. 5.8. Использование обобщенных ссылок запроса [VB.NET]
<html>
<body>
<%
If Request.ServerVariables("REMOTE_ADDR")="127.0.0.1" Then
Response.Write("Access is <b>allowed</b>")
Else
Response.Write("Access is <b>not allowed</b> from " & _
Request("REMOTE_ADDR"))
End if
%>
</body>
</html>

Глава 5 • фильтры на входе в систему
Способы защиты
■ Всегда делайте привязку фильтрованного пользователя к переменным для
отделения его от необработанных данных.
■ При обращении к VB.NET всегда используйте Option Explicit или Option Strict
■ Используйте централизованные функции фильтрации на всех входах
пользователя.
■ Никогда не используйте обобщенную совокупность Request.
Ограничение на вход
Ключом защиты вашего приложения от умышленных данных является
подтверждение входа всех пользователей. В вашем коде существует множество
действий, которые вход пользователя может имитировать, и, следовательно,
множество методов подтверждения этого входа. Примеры того, на что может повлиять
вход пользователя следующие:
■ Получение права доступа к базе данных
■ Прочтение файловой системы
■ Разрешение пользователям пересылать или сохранять файлы
■ Запуск команд программной оболочки
■ Рассылка электронной почты
■ Установка свойств объекта
■ Processing a shopping cart purchase
Каждое из этих действий подвержено одной и более опасностям, упомянутых
в начале данной главы Чтобы подсчитать эти опасности, я установил следуюЩ**6
методы, которые опишу более подробно в этом разделе:
■ Проверка границ Проверка входящих значений на соответствующий
данных, длину строки, формат, символы, диапазон.

Фильтры на входе в систему • Глава 5
■ Соответствие образцов Использование устойчивых выражений для
обнаружения соответствия и разрешения доступа или обнаружения
неправильного символа или строки и блокирования доступа.
■ Отражение данных Отправка данных в систему, прочтение интерпретации
данных этой системой и затем сравнивание с оригинальными данными.
■ Шифрование Преобразование символов строки в специальный формат
для безопасного обращения.
■ Инкапсуляция Извлечение дайджеста из входа пользователя, который
содержит известный набор символов, делая их безопасными для использования.
■ Параметризация Принятие входа пользователя в качестве параметра для
фиксации области его деятельности, например, добавляя расширение
файла или префиксируя путь директории.
■ Двойное кодирование Кодирование данных дважды для подтверждения
совпадения обоих образцов.
■ Escaping Заключение в кавычки или установка ESC специальных
символов таким образом, чтобы они воспринимались как буквенные символы.
■ Проверка синтаксиса Проверяя законченную строку, убедитесь в
соответствии синтаксиса для цели.
■ Обработка исключений Проверяя выполнение ошибок, убедитесь, что
результаты возвращены, как вы и ожидали.
■ «Маленькие хитрости» Небольшие части данных, помогающие
предотвратить вторжения.
На следующих примерах вы увидите, как использовать эти методы с
различными задачами программирования.
Проверка границ
Исходное положение: Проверяйте входные данные на их
соответствие целям.
Угроза: Злонамеренный вход.

20 Глава 5 • Фильтры на входе в систему
Проверка границ - это быстрый и легкий способ предотвращения многих атак при-
ложения. Проверьте входные значения, чтобы убедиться, что они соответствуют
ожидаемому типу данных, длине строки, формату строки, набору символов и диапазону
значений. ASP.NET предлагает несколько легких способов проверки входных данных:
■ Контроль валидатора
■ Преобразование типа
■ Параметры Sql
Контроль валидатора
ASP.NET предоставляет несколько методов контроля, используемых для
подтверждения всех форм данных, введенных пользователем. Прикрепив валидатор
контроля к форме и установив несколько свойств, вы получите автоматическую
проверку ASP.NET входных значений пользователей.
Таблица 5.2. Валидатор Контроля ASRNET
Контроль Описание
Валидатор сравнения Сравнивает значения контроля с фиксированным
значением или со значением другого контроля
Валидатор пользователя Выполняет функции определения пользователя
Валидатор области действия Проверяет обобщенные значения, чтобы они
не выходили за рамки максимально
и минимально допустимых значений
Валидатор устойчивых выражений Сравнивает соответствие значения
с устойчивой фразой
Валидатор требуемого поля Гарантирует, что поле контроля не останется пустым
Валидатор итога Суммирует все ошибки подтверждения на страницу
Для того чтобы использовать валидатор контроля, установите свойств
ControlToValidate и затем установите любые другие свойства для определения вь
полнения. Рис. 5.9. (С#) показывает на примере метод использования
валидатора
контроля для проверки обобщенного поля входа.

Фильтры на входе в систему • Глава 5
рис. 5-9- Подтверждение обобщенного входа (С#)
<htmi>
<body>
<form runat="server">
Enter you age:
<br />
<asp:TextBox id="tboxl" runat="server"/>
<br /><br />
<asp:Button Text="Submit" runat="server" />
<br /><br />
<asp:RangeValidator
ControlToValidate="tboxl"
MinimumValue="13"
MaximumValue="120"
Type= "Integer"
EnableClientScript = "false"
Text= "Invalid age."
Runat= "server"/>
</form>
</body>
</html>
Самый мощный из перечисленных валидаторов - это валидатор устойчивых
выражений, который позволяет сложным образцам совпадать для обеспечения
того, чтобы вход осуществлялся с очень специфическими параметрами.
Но важно отметить, что хотя валидаторы контроля достаточно мощные, все
Же у них есть и некоторые ограничения:
* Можно использовать их только для подтверждения форм контроля.
* Вы можете подтверждать форму контроля, только когда страница
пересылается сама на себя, а не на другую страницу.
* Они работают только с контролем со стороны сервера.
■ ASP.NET не выполняет никакого подтверждения с валидатором контроля,
пока он не запустит событие Page-Load.
Они склонны к децентрализации кода, перемещая их на индивидуальные
страницы, а не используют централизованный механизм для фильтрации входа.

222 Глава 5 • Фильтры на входе в систему
Поскольку валидатор контроля концентрируется исключительно на форме
входа, очень легко упустить из вида фильтрацию других форм входа пользователя
Для работы с этими ограничениями, вам необходимо будет развить функции
пользователя для подтверждения другого входа. Тем не менее, из-за их автоматических
сообщений об ошибках и дополнения клиентского кода, вам следует всегда
использовать валидатор контроля для формы входа.
Внимание
Свойства подтверждения контроля со стороны клиента ускоряют подтверждение
клиента и предотвращают дополнительную загрузку на ваш сервер с продолжительных
обратных отправок, но в качестве меры защиты они не надежны. Взламыватель
может легко заблокировать скриптинг клиента, или использовать пользовательский
инструмент для отправки форм, которые проходят подтверждение клиентской стороны.
Способы защиты
■ Используйте валидатор контроля для подтверждения формы входа,
если страница пересылается сама на себя.
Сравнение с образцом
Исходное положение: Сравнение с образцом - это эффективный метод
для фильтрации злонамеренного входа.
Угроза: Злонамеренный вход.
Самым распространенным и эффективным методом отслеживания
злонамеренного входа, является применение сравнения образцов через устойчивые
выражения. Используя сравнение с образцом, вы блокируете вход, который содержит
специальные символы злонамеренного входа или разрешаете доступ только входа,
содержащего набор известных безопасных символов. В силу некоторых
обстоятельств, последний метод более предпочтительный для проверки входа.
Поскольку очень сложно предугадать каким именно способом кто-то
попытается взломать ваше приложение, необходимо решить каким символам, вы
разрешите доступ, а затем заблокировать все остальные. Рис. 5.10. (С#) и 5.11. (VB.NET)
показывают метод использования устойчивых выражений для предоставления прав
доступа только специальным символам. Использование этого метода, однако,
требует некоторой предусмотрительности. Пользователи будут растеряны, если вь
не предоставите доступ определенным символам, таким как апостроф или дефи
в поле имени.

Фильтры на входе в систему • Глава 5
рис. 5.10. Разрешения доступа хорошо известным символам (С#)
// Pattern match for known good characters and check length
// Only allow 1-260 letters, numbers, spaces,
// periods, and/or back slashes
Regex knownGood = new Regex (@"Л [a-z0-9\s\ . \\] {1, 260}$",
RegexOptions.IgnoreCase);
if (!knownGood.IsMatch(decodedPathl))
TextBoxResults.Text += "Step 2: Pattern match for " +
"known good failed\n";
else
TextBoxResults.Text += "Step 2: Pattern match for " +
"known good passed\n";
Рис. 5.12. Разрешения доступа хорошо известным символам (VB.NET)
'Pattern match for known good characters and check length
'Only allow 1-260 letters, numbers, spaces, periods, and/or back
slashes
Dim knownGood As Regex = New Regex (,,Л [a-z0-9\s\ . \\] {1, 260 } $", _
RegexOptions.IgnoreCase)
If Not knownGood.IsMatch(decodedPathl) Then
TextBoxResults.Text += "Step 2: Pattern match for " & _
"known good failed" & vbCrLf
Else
TextBoxResults.Text += "Step 2: Pattern match for " & _
"know good passed" & vbCrLf
End If
Ho сравнивание с образцом это больше, чем блокирование и
предоставление доступа индивидуальным символам. Некоторые атаки используют
действительные символы, и все же могут быть злонамеренными. Например,
рассмотрите web-приложение, которое сохраняет данные в файле и выбирает имя фай-
Ла> основанного на входе пользователя. Для предотвращения прослеживания
Директории или атак файлового допуска, нужно позволить пользователям
вводить только буквенно-цифровые данные, которые можно расширить устойчи-
ь*м выражением. Но что происходит, если пользователь выбирает имя файла,
ИсПользуя зарезервированное имя устройства DOS, такое как СОМ1, PRN или
^UL? Несмотря на то, что эти названия не содержат ничего, кроме
алфавитах символов, получение доступа к ним может вызвать отказ от обслуживания

224 Глава 5 • Фильтры на входе в систему
или усилить некоторые виды других атак. Для некоторых типов входа нулсн
позволять только хорошо известные данные и затем выполнять последующую
проверку, чтобы убедиться, что вход не содержит плохо известных данных
Рис. 5.12. (С#) и 5.13. (VB.NET) показывает метод использования устойчивого
выражения для проверки этих образцов.
Рис. 5.12. Сравнивание плохо известного входа (С#)
// Pattern match for known bad characters and strings
Regex knownBad = new Regex(@"(?:AUX|CO(?:M\d|N\.\.) " +
@"|LPT\d|NUL|PRN|\n|\r|progra(?:W|m\sfiles)|system32" +
@"Iwinnt|[\?\*\<\>\l\""\:\%\&])", RegexOptions.IgnoreCase);
if (knownBad.IsMatch(decodedPathl))
TextBoxResults.Text += "Step 3: Pattern match for " +
"known bad failed\n";
else
TextBoxResults.Text += "Step 3: Pattern match for " +
"know bad passed\n";
Рис. 5.13. Сравнивание плохо известного входа (VB.NET)
'Pattern match for known bad characters and strings
Dim knownBad As Regex = New Regex("(?:AUX|CO(?:M\d|N\ . \ .) " &
" |LPT\d|NUL|PRN|\n|\r|progra(?:W|m\sfiles) |system32" &
"Iwinnt| [\?\*\<\>\|\""\:\%\&])", RegexOptions.IgnoreCase)
If knownBad.IsMatch(decodedPathl) Then
TextBoxResults.Text += "Step 3: Pattern match for " & _
"known bad failed" & vbCrLf
Else
TextBoxResults.Text += "Step 3: Pattern match for " & _
"know bad passed" & vbCrLf
End If
Таблица 5.3. представляет некоторые общие сценарии входа и примеры ус"
тойчивых выражений образцов, которые нужно использовать для
распознавания злонамеренного входа. Иногда вам придется давать допуск только хорош0
известным данным, а иногда вы будете отфильтровывать плохо известные №н~
ные, но, обычно, вам придется выполнять обе эти проверки. Заметьте, что
образцы в этой таблице не являются универсальными для всех возможных вариа**"

Фильтры на входе в систему • Глава 5
в йСпользования, поэтому нужно адаптировать их для вашего конкретного
приложения.
Таблица 5.3. Образцы устойчивых выражений для фильтрации входа
действие Regex для сравнивания известного плохого входа
доступ к файловой системе (?: AUXI СО (? :M\d IN.\.) I LPT\ d INUL IPRN
I \n I \r I progra (?:\~11 m\sfiles) I system
321 winnt I \[\?\*<\>\ I \A:\%\&])
доступ в базе данных (?:\V I d (?:elete I sform I rop\stable) I insert \sinto I s
(?:elect\s\* I pJI union\sselect I xp J
Отправка электронных сообщений (?:rcpt\sto l[\<\>\;])
форматирование HTML a) I javascript I omnoudeover i vbscript)
дсказка
'i Сравнивание с устойчивыми фразами может быть сложным процессом, и примеры,
^ приведенные в таблице 5.14. могут соответствовать, а могут и не соответствовать
ty: вашим потребностям. См. wvw.exparrotcom/-pdw/Mail"RFC822-Address.html при-
% мер сложности подтверждения чего-либо так же прост, как и электронный адрес.
Удаление данных
В некоторых случаях, вы захотите, чтобы ваши пользователи могли вводить
специальные символы без ограничений. Но разрешение применения этих
символов подвергает ваше приложение таким атакам, как, например запросы SQL. Вы
можете, например, позволить клиентам использовать апостроф при вводе фамилии,
например ОЪрайен, но в SQL у этого символа своё специальное значение.
Разрешение применения этого символа может сделать ваше приложение уязвимым
против запросов SQL. Но выход, на самом деле, очень простой: замените каждую
одинарную кавычку на две одинарные. Это позволит вам построить предложение SQL,
не беспокоясь о клиентах, использующих одинарные кавычки. Удалив (или
постаяв в кавычки), символ теряет всякое значение для интерпретатора SQL.
Ниже приведено несколько типов данных, требующих удаление:
• Команды программной оболочки
• Предложения SQL

Глава 5 • Фильтры на входе в систему
■ Образцы устойчивых выражений
■ HTML
Способы защиты
■ Используйте устойчивые выражения либо для блокирования известных
плохих данных, либо для предоставления доступа известным хорошим данным
■ Используйте устойчивые выражения для выявления злонамеренных
ключевых слов или других образцов.
■ Удаляйте все специальные символы из логина пользователя.
Отражение данных
Исходное положение: Отражение данных подтверждает путь или
другую информацию, используя функции
доверенных систем.
Угроза: Прослеживание директории.
Когда Микрософт впервые выпустил Windows 2000, безопасность была забытым
вопросом, который быстрыми темпами привлекал внимание. Разработчики
безопасности нашли многочисленные бреши в операционной системе, особенно в
Информационном Сервере Интернет (IIS). Самыми серьезными дефектами были
получение доступа к просматриванию защищенных файлов и прослеживание файловой
системы для получения доступа к файлам, находящимся за пределами директории
web-содержания. Разработчики безопасности нашли способ обмануть IIS, заставив
его думать, что он находит файл с другим расширением или файл в той же
директории, когда на самом деле он извлекал файл из исходной директории. В то время,
пока эти методы вводят в заблуждение IIS, операционная система с помощью
различных методов, получает доступ к файлам и, следовательно, устанавливает верное
право доступа. Установив едва различимую разницу между тем, как IIS и ОС, интерпре-
тируют пути файлов, разработчики выявили несколько серьёзно уязвимых мест.
Неавторизованный доступ к файлу
Одной из первых уязвимостей, обнаруженных в IIS 5 была возможность пр°
сматривать части ресурсов стороны сервера, просто добавив строку «+.htr» к лк>
бому URL. Вместо обычной обработки скрипта сервера, IIS возвращает исходны
текст самого файла, зачастую раскрывая восприимчивую информацию, такую *а

Фильтры на входе в систему • Глава 5
тпоки соединений база данных и пароли. Для взлома этого уязвимого места, взла-
ывателю нужно войти в URL следующим образом:
www. example. com/global. asa+. htr
Обычно IIS не допускает запросы для файлов с расширением .ASP или ASP.NET,
но добавление дополнительного символа заставляло IIS воспринимать его как файл
с расширением HTR. Однако фильтр ISAPI, который обрабатывал расширения
HTR, сбрасывал лишние данные и возвращал содержание самого файла.
Microsoft быстро выпустил заплаты для борьбы с этой уязвимостью, но другие
разработчики обнаружили, что даже с ней можно вводить систему в заблуждение,
просто добавив строку «%3F+.htr», таким образом:
www.example, com/global .asa%3F+.htr
И снова сервер вернул исходный текст для global.asa, а не заблокировал
запрос. Хотя Microsoft установил специфику распознавания уязвимости, в первый
раз им не удалось применить её против основополагающего недостатка, что
позволило провести IIS ещё раз.
IIS была также подвержена различным уязвимостям отслеживания директории.
В этих случаях взламыватель запрашивал файлы вне границ web-приложения.
Обычно IIS не допускает запросов из вне web-корня, но, замаскировав двоеточие («..»)
через шифрование и другие методы, разработчики нашли способ обмануть IIS, заставив
его воспринимать файл, как если бы он находился в web-корне, когда на самом деле,
он был взят из исходной директории. Всё это обернулось серьёзными недостатками,
потому что они позволяли взламывателям выполнять команды и быстро получать
доступ к серверу. Более того, многие из Интернет «червей», типа Code Red и Nimba,
использовали эти недостатки для своего распространения от сервера к серверу.
Отражение данных
Чтобы предотвратить прослеживание директорий и доступ к коду сервера,
Разработчики обычно проверяют расширения файлов и держат под контролем ну-
и» содержащие двоеточия. Однако это не всегда эффективно, поскольку существу-
507 такие методы как кодирование, которые взламыватели используют для
маскировки этих символов. Вместо того чтобы каждый раз пытаться угадать, как имен-
u взламыватель может заполучить ваш код, используйте более эффективный ме-
°Д- отражение данных. При использовании этого метода, вы берете вход иользо-
^теля и пропускаете его через доверенную систему. Затем вы читаете
интерпретацию системой этих данных и сравниваете с входом пользователя. Шаги, которые
е°бходимо предпринять для отражения пути файла, следующие:

228 Глава 5 • Фильтры на входе в систему
1. Расшифруйте путь и расширьте любые переменные среды.
2. Используйте метод System.IO.Path.GetFullPath () для обратного отражени
нормализованного пути.
3. Сравните директорию входа пользователя с директорией отраженного пути
4. Убедитесь, что путь проходит в соответствии с ограничениями приложения
5. Используйте только путь, отраженный из того, который указан в вашем коде
Код на рис. 5.14. (С#) и 5.15. (VB.NET) демонстрирует эти шаги.
Рис. 5-14. Отражение данных (С#)
// Parameterizing and Data Reflecting
string rootPath = @"e:\inetpub\wwwroot\files\";
string fileExt = ".txt";
string expandedPath =
System.Environment.ExpandEnvironmentVariables(decodedPathl) ;
string scopedPath =
string.Concat(rootPath, expandedPath, fileExt);
string absolutePath = "";
try
{
absolutePath = Path.GetFullPath(scopedPath);
// Double-check to see if still within parameters
if (!absolutePath.StartsWith(rootPath) ||
!absolutePath.EndsWith(fileExt))
TextBoxResults.Text += "Step 4: Data reflection failed\n";
else
TextBoxResults.Text += "Step 4: Data reflection passed\n";
}
catch (Exception ex)
{
TextBoxResults.Text += "Step 4: Reflection failed " +
"with an Exception: " + ex.ToString() + "\n";
Рис. 5.15. Отражение данных (VB.NET)
'Parameterizing and Data Reflecting
Dim rootPath As String = "e:\inetpub\wwwroot\files\"
Dim fileExt As String = ".txt"

Фильтры на входе в систему • Глава 5
pirn expandedPath = System.Environment. _
ExpandEnvironmentVariables(decodedPathl)
Dim scopedPath = String.Concat(rootPath, _
expandedPath, fileExt)
pim absolutePath
Try
absolutePath = Path.GetFullPath(scopedPath)
•Double-check to see if still within parameters
If Not absolutePath.StartsWith(rootPath) Or
Not absolutePath.EndsWith(fileExt) Then
TextBoxResults.Text += "Step 4: Data reflection failed" & vbCrLf
Else
TextBoxResults.Text += "Step 4: Data reflection passed" & vbCrLf
End If
Catch ex As Exception
TextBoxResults.Text += "Step 4: Parameterizing failed " & _
"with an Exception: " & ex.ToString() & vbCrLf
End Try
Преимущество этого метода в том, что поскольку операционная система, в
конце концов, решит к какому файлу разрешить доступ, у вас есть система, которая
укажет вам, к какому файлу она намеревается получить доступ, основываясь на
входе данного пользователя. Вы подтверждаете путь и используете его при
действительном получении доступа к файлу.
Способы защиты
* Отражайте данные, используя функции доверенных систем, для
предотвращения атак, таких как прослеживание директорий.
• Всегда применяйте отраженный путь в последовательных операциях.
Шифрование данных
Исходное положение: Шифрование данных нейтрализует
злонамеренное содержание HTML.
Угроза: Межсайтинговый скриптинг.

230 Глава 5 • Фильтры на входе в систему
Иногда хакеры не пытаются проникнуть в ваш web-сайт, но вместо этого хотят
использовать web-приложение для доступа к другим пользователям или сбора ддц_
ных о пользователе. Например, взламыватель может захотеть получить доступ к
он-лайновому банковскому аккаунту другого пользователя или личной
электронной почте. Используя метод под названием «межсайтинговыи скриптинг», хакер
вводит содержание HTML в web-страницу для использования других
пользователей. Это содержание может злонамеренный HTML markup, включающий:
■ Обманчивые ссылки
■ Форма HTML тэгов
■ Клиентский скрипт
■ Активные X компоненты
Основным моментом этой атаки является злоупотребление доверием, которое
возникает из запуска злонамеренного содержания на доверенном web-сайте.
Взламыватели могут использовать уязвимые места межсайтиногового скриптинга
для выполнений большого числа атак, таких как:
■ Похищение файла cookies клиента
■ Обхождение методов ограничения
■ Получение доступа к web-содержанию
■ Сбор IP-адресов web-пользователей
■ Изменение поведения ссылок или форм
■ Перенаправление пользователей на недоверенные web-сайты
В самом деле, многие разработчики недооценивают межсайтинговыи скриптинг.
Межсайтинговыи скриптинг уязвим, когда web-приложение динамичн
отображает выход HTML одного пользователя, основанного на входе от ДрУ
гого пользователя, такое как отображение не фильтрованных результате»
гостевой книги или обратной связи системы. Взламыватель может использ
вать это, вводя тэги HTML, которые модифицируют поведение web-стра**
цы. Например, взламыватель может внедрить код JavaScript, который переН
правляет пользователя на другой web-сайт или похищает файл cookie, к°т

Фильтры на входе в систему • Глава 5
ь1Й содержит аутентификационную информацию. Служба электронной
почты, основанная на web, такая как Hotmail долгое время представляла собой
мишень для атак межсайтингового скриптинга, так как они отображали
HTML в содержании электронного послания. Для выполнения атаки, взламы-
вателю просто нужно было отправить намеченному пользователю
специально разработанный e-mail.
Для работы межсайтингового скриптинга, взламыватель должен отправить
markup HTML через некоторые формы входа. Это должно включать в себя форму
HTML, файл cookie, параметр QueryString, или даже заголовок HTTP. Например,
существует множество страниц регистрации, которые отправляют сообщение
об ошибке обратно пользователю:
www.example.com/login.aspx7err = Invalid+username+or+password
Страница проверяет параметр ошибки, и если он существует, отображает
содержание обратно пользователю в качестве сообщения об ошибке. Если страница
не фильтрует этот вход, взламыватель должен быть в состоянии внедрить
злонамеренный код.
К счастью, ASP.NET автоматически блокирует вход любого пользователя,
который содержит HTML код. Рис. 5.16. демонстрирует метод блокирования ASP.NET
запроса для URL:
Http: //localhost/inpurt .aspx?text+<a href=»»x/a.
Рис, 5.16. Встроенное HTML блокирование ASRNET
Server Error in У Application
A potentially dangerous Request QueryStrng value was detected from the
client (user» <scnpt>afert(Vutne... ).
•ев «с ratad duetae the
latocaaclon ragaxdiag ebe oclgln and location of
an* tioa «tack craea bale*.
[MttataouaKVabacti cwtton (ОвлЮОМОМ) A potentially danatrou* ttwwst.QufrSt ч»а v«1u» на* aVtactad
ct«*.Wtb Kttj>»t4U»rt.V4lid*t««rin(CStrino », ftrino valmHwu String шП«<Люп»«яО +JK
■ .«Ttp*aeiMft.V«li4ataNtmV«!iMGoll«ct1onCttaMV*liMCo11»ction *<. StHn» coll action*—O +»*
HI!*»?.Date™«H*»t£el***tQ «47
. - П Иал«1 ttxttJt i onStcp. S/ftan.Wte. HttB*ft>1 i ctrtiWM-Ifcutirt lonStap. Be*cut« О *»«
*tt»Aoabc*tt4Xi fe*cwt«5*.t»CKx«ut1oft»*p (tap •sot*** coa»lata<nynthronM»l ) tV
Vanlaa МалкаНмгМств* jN(T Naamit Vmfcni IAQS) ASM*T VWoni 1 «302

232 Глава 5 * Фильтры на входе в систему
Этот способ ограничен, поэтому легко не заметить все различные наборы сим
волов и методов шифрования, которые поддерживает ASP.NET или обозревател
Интернет клиента.
Некоторые наборы символов разрешены к применению для мульти-байтоа
или других зашифрованных представителей специальных символов.
Последовательность символов, которая может казаться благотворной в одном наборе
символов, в другом - может представлять собой злонамеренный код. Не смотря на то
что вы часто можете отфильтровывать специальные символы, не следует
полностью полагаться на этот метод как на абсолютную защиту.
Шифрование - это метод, который нейтрализует специальные символы,
изменяя изображение этих символов. Шифрование HTML создает специальные
символы-эквиваленты реально существующего символа, который предотвращает
интерпретацию символов как активного HTML, Таб. 5.5. демонстрирует HTML
зашифрованных представителей некоторых общих символов. Если обозреватель
Интернет наталкивается на любой их этих HTML зашифрованных символов, он
отображает сам символ, а не воспринимает его как специальный символ.
Таб. 5.5. Пример Шифрования реально существующего символа HTML
Название
Кавычки
Знак & (=and)
Меньше чем
Больше чем
Символ
«
&
<
>
Десятичный код
&#34
&#38
&#60
&#62
Сущность (Enity)
&quot
&amp
&lt
&gt
Используя таб. 5.5., при наличии у нас HTML markup:
<а href="www.asp.net."> ASP.NET</a>
Мы можем расшифровать это следующим образом:
&lt;a href=&quot; www.asp.net&quot; &gt; ASP.NET&lt;/a&gt;
Первый пример появится как активная ссылка, в то время как второй пример
отобразит сам HTML markup.
.NET Framework предоставляет методы в объекте Server, класс HttpSeverUtn1
для шифрования строк, которые могут представлять собой потенциальную опз
ность, если их оставить не зашифрованными. Эти методы:

Фильтры на входе в систему • Глава 5
■ HtmlEncode Зашифровывает HTML строки для безопасного выхода на
обозреватель Интернет клиента
■ URLEncode Зашифровывает строку для безопасной передачи её как URL
■ URLEncode Пути Зашифровывает строку для безопасной передачи её как
часть пути URLa.
Рис 5.17. (С#) и 5.18. (VB.NET) демонстрируют способ использования метода
Html Encode.
Рис. 5-17. Использование Html Шифрования (С#)
private void Buttonl_Click(object sender, System.EventArgs e)
{
Label1.Text = Server.HtmlEncode(TextBoxl.Text);
Label2.Text =
Server.HtmlEncode(Orders.Customers[0].Name);
}
Рис. 5,18- Использование ШтШифрования (VB.NET)
Private Sub Buttonl_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Buttonl.Click
Labell.Text = Server.HtmlEncode(TextBoxl.Text)
Label2.Text = _
Server.HtmlEncode(Orders.Customers[0].Name)
End Sub
Ещё один тип шифрования - это URL Encode для URL и строк запроса,
вставленных в HTML. Нужно использовать URLEncode или URLPathEncode, везде, где
ВЬ1 используете ссылку URL или строку запроса в документе HTML. Это включает
всебя элементы APPLET, AREA, BASE, BGSOUND, BODY, EMBED, FORM, FRAME,
frRAME, ILAYER, IMG, ISINDEX, INPUT, LAYER, LINK, OBJECT, SCRIPT, SOUND,
TABLE, TD, TH, и TR HTML. Используйте URLEncode на всех URL
и URLPathEncode для кодировки только пути. Разница состоит в том,
^то URLPathEncode шифрует пространство как 20%, а не знак плюс («+_»),
который использует URLEncode. Более того, URLPathEncode отображает все знаки
препинания, в отличие от URLEncode.

234 Глава 5 • Фильтры на входе в систему
Способы защиты
■ Используйте HtmlEncode для шифрования строк для обозревателя
Интернет выхода.
■ Используйте URLEncode для шифрования строк URL для выхода.
■ Используйте URLPathEncode для шифрования части пути URL для выхода
Инкапсуляция
Исходное положение: Хэширование инкапсулирует данные для
безопасной обработки.
Угроза: Злонамеренный вход.
Иногда вам нужно воздействовать на вход пользователя, но действительное
значение входа может вас не касаться. Например, вы задумались об уникальном
идентификаторе, основанном на входе пользователя или о пароле для
последующего сравнения. Можно использовать хэш для инкапсуляции данных в
формате безопасной строки, в то время как все ещё поддерживаете ссылку на
оригинальные данные.
Эффективные функции хэширования обладают некоторыми свойствами,
которые делают их целесообразными для инкапсуляции данных:
■ Они производят длинные, случайные дайджесты, что позволяет извлекать
пользу из всего ключевого пространства.
■ Они производят мало столкновений; две строки входа крайне редко
образуют один и тот же хэш.
■ Они всегда производят строки дайджеста с одинаковой длиной.
■ Создав хеш, вы не сможете извлечь из него оригинальные данные.
При помощи хэша можно нейтрализовать любое злонамеренное содержани
потому что хэш искажает строку в безопасный формат. Вы можете затем отфор
тировать хэш в hex строку для безопасной обработки.
Если вы захэшировали пароль перед сохранением, можно не проверять е
на наличие неверных символов, потому что хэш не содержит злонамеренно
содержания. Это позволяет пользователям вводить в пароль любые символы

Фильтры на входе в систему • Глава 5
усмотрение, и вы можете не опасаться влияния специальных символов на
строку.
Ещё один пример - когда нужно создать файл, основанный на входе пользова-
лЯ Поскольку любая операция с файлами, основанная на входе пользователя,
может представлять опасность, можно захотеть сначала преобразовать вход в
безопасный хэш строки. Тот метод будет описан более подробно в Главе 6.
Хэши также эффективны для маскировки данных, что делает их менее
уязвимыми против атак угадывания. Одно приложение электронной коммерции
использовало временные файлы XML для shopping cart. Имена файлов были
основаны ни ГО пользователя и текущей дате. Однако бреши никогда не покидают
приложение, и они не были удалены после окончания сеанса, оставив на директории
временные файлы, содержащие личную информацию пользователей, включая
подробную информацию по кредитным карточкам покупателей. Взламывателю
понадобилось всего лишь использовать эффективную тактику угадывания для
получения доступа к этой информации. Напротив, использование имени файла,
основанного на хэше, сделает его непредсказуемым и будет использовать достаточно
большое ключевое пространство для предотвращения угадывания.
Способы защиты
■ Используйте хэши для инкапсуляции данных для безопасной обработки.
■ Преобразуйте хэши в hex значения для создания безопасных alphanumeric
строк.
Параметризация
Исходное положение: Параметризация позволяет фиксировать
контекст входа пользователя
Угроза: Отслеживание директорий, получение доступа
к системе файлов, запросы SQL, внедрение
команд
Параметризация - это метод, при котором вы помещаете вход пользователя в
фиксированный контекст так, что можно контролировать диапазон доступа. Рас-
°трите web-приложение, в котором вы получаете доступ к файлам, основанным
выбранной ссылке. Ссылка может отправить вас на URL, как показано ниже:
•sxample.org/articles . aspx?xml=/artides/a0318 . xml

Глава 5 - Фильтры на входе в систему
Важнейшей проблемой URL является то, что он становится взламывателям
и вы получаете доступ к системе файлов, возможно подталкивая их к попыткам
поиска способов взлома приложения: что произойдет, если вы отправите имя файла
с другим расширением?
Чтобы предотвратить злоупотребление вашим web-приложением, принимайте
минимальное количество требуемой информации и вставляйте её как параметп
полного пути. Если путь и имя файла зафиксированы, следующая версия URL
может быть лучшей:
www.example.org/articles.aspx7article = а0318
Теперь возьмите the/articles path и присоедините параметр article, следующий
за расширением .xml. Теперь вне зависимости от того, что вводит пользователь,
он всегда будет начинаться с the/articles path и иметь расширение .xml.
Внимание
Не полагайтесь только на параметризацию для гарантирования масштаба.
Microsoft допустил эту ошибку с образцом showcode.asp, включенным в ранние
версии IIS (см. www.securitvfocus.com/bld/167). Программист проверил,
не содержит ли последняя строка пути специфической директории, но не
проверил наличие двойных точек («..»), что позволило взламывателям запросить файлы
с исходной директорией. Лучший способ предотвращения таких ситуаций -
это комбинирование параметризации с отражением данных, сравниванием с
образцом и другими методами, описанными в данной главе.
Параметризация может использоваться не только для получения доступа к
файлу; это ещё и эффективный способ ограничения многих типов атак. В Главе о
будут рассмотрены методы использования параметров для предотвращения запр0"
сов SQL.
Способы защиты
■ Используйте параметризацию для фиксирования контекста и диапазон
данных пользователя.
■ Совмещайте параметризацию с другими методами для предотвращен**
прослеживания директорий.

Фильтры на входе в систему • Глава 5
двойное декодирование
Исходное положение: Двойное декодирование помогает выявлять
множественные уровни кодирования.
Угроза: Прослеживание директорий, получение доступа
к системам файлов, получение доступа к коду
сервера.
Двойное декодирование - это метод, специально разработанный для
противостояния атаки кодирования, называемой двойное кодирование. Уязвимость
против этого типа атаки возникает потому, что ваше приложение может
расшифровывать и зашифровывать строку более одного раза в различных
областях вашего приложения. Взламыватели могут извлечь из этого выгоду, создав
множественные уровни зашифрованных строк, обычно в пути или строке
запроса. Другими словами, вы шифруете строку, а затем шифруете её ещё раз.
Это должно позволить взламывателю обойти сравнивания с образцом в коде
ваше приложения.
IIS5 был уязвим против этого типа атаки. В мае 2001 года, Microsoft выпустил
заплату кумулятивной защиты для IIS (см. www.microsoft.com/technet/security/
bulelin/MS01-026.aspx). что включало в себя фиксацию для уязвимости против
двойного декодирования. IIS декодирует входящие запросы для изображения
пути в канонической форме. Затем он проводит необходимую проверку
безопасности на этом пути, чтобы убедиться, что пользователь запрашивает файл,
находящийся в пределах директории web-содержания. После проверки IIS выполняет
второе декодирование. Взламыватель может извлечь из этого выгоду,
зашифровав путь дважды. Первое декодирование удалит первый уровень шифрования,
но так как путь обладает ещё одним уровнем шифрования, он пройдет проверку
защиты IIS. При втором декодировании IIS расшифрует второй уровень
кодирования и произведет окончательный путь. Конечный результат заключается
втом, что взламыватель может обойти проверку защиты IIS для получения
доступа к файлам вне web-корня.
Поскольку очень сложно предугадать, что строка в вашем приложении будет
Декодирована дважды, наиболее эффективно было бы изначально проверять
ХоД пользователя на множественные уровни кодирования. Дважды декодиро-
в строку, вы сможете выявить наличие множественных уровней кодирования,
0 Что делать, если кто-то использует больше двух уровней декодирования?
кУДа вы знаете, сколько раз надо провести декодирование, чтобы достичь по-
еДнего уровня? Может ли кто-нибудь вызвать отказ от обслуживания, кодируя
Р°ку сотни раз? Решение в том, чтобы проводить декодирование дважды,
НаВнивая результаты первого декодирования с результатами второго. Если они
с°впадают, то вы поймете, что строка содержит ещё два или более уровней

238 Глава 5 • Фильтры на входе в систему
кодирования, и, скорее всего, это не действительный запрос. Если вы
столкнулись с этим, просто отклоните запрос и верните сообщение об ошибке клиенту
Рис. 5.19. (С#) и рис. 2.20. (VB.NET) демонстрируют использование метода
двойного декодирования.
Рис- 5.19. Двойное декодирование (С#)
// Double decode
string decodedPathl = Server.HtmlDecode(inputFilePath);
string decodedPath2 = Server.HtmlDecode(decodedPathl);
if (!decodedPathl.Equals(decodedPath2))
TextBoxResults.Text += "Step 1: Double decode failedW;
else
TextBoxResults.Text += "Step 1: Double decode passed\n";
Рис. 5.20. Двойное декодирование (VB.NET)
'Double decode
Dim decodedPathl As String = Server.HtmlDecode(inputFilePath)
Dim decodedPath2 As String = Server.HtmlDecode(decodedPathl)
If Not decodedPathl.Equals(decodedPath2) Then
TextBoxResults.Text += "Step 1: Double decode failed" & vbCrLf
Else
TextBoxResults.Text += "Step 1: Double decode passed" & vbCrLf
End If
Способы защиты
Используйте двойное декодирование для выявления множественных уроВ
ней кодирования.
Отклоняйте все запросы, которые содержат более чем один уровень
кодирования.

Фильтры на входе в систему • Глава 5
Проверка синтаксиса
Исходное положение: Проверка синтаксиса - это последняя линия
защиты против атак, которым удалось пройти
через все другие.фильтры
Угроза: Злонамеренный вход.
После разрешения доступа входа пользователя и применения одного или
более методов, описанных в этой главе, вам, в конечном итоге, нужно что-то
сделать с данными. Можно, например, построить предложение SQL для
поиска информации аккаунта, основанного на данном логина. Для проверки входа
пользователя можно использовать один или более методов, описанных в
данной главе, но перед выполнением предложения SQL на сервере, вы,
возможно, захотите провести последнюю проверку, чтобы удостовериться, что
синтаксис SQL соответствует формату, который вы ожидаете. Например,
вы не хотите отправлять предложение SQL с множеством глаголов, таких как
два предложения SELECT или SELECT и DELETE. Прохождение
заключительной строки через функцию сравнивания образцов может быть очень
эффективно в остановке атак.
Проверка синтаксиса применяется в качестве последней линии защиты
против тех атак, которые прошли через все другие фильтры. Примеры проверки
синтаксиса:
■ Убедиться, что команды программной оболочки не содержат piping,
перенаправляющих, командно-взаимосвязанных символов.
• Убедиться, что строка адреса электронной почты содержит только
один адрес
• Убедиться, что пути файла относятся к директории web-содержания и не
содержат drive designators, пути UNC, символы прослеживания
директории или зарезервированных названий устройств DOS.
Способы защиты
■ Когда это будет целесообразно, проверьте синтаксис любой строки,
основанной на входе пользователя

Глава 5 - Фильтры на входе в систему
Обработка исключений
Исходное положение: Обработка ошибок может перехватить ошибки
до того, как хакер использует их.
Угроза: Злонамеренный вход.
Хакеры не используют нормальные операции вашего web-приложения;
обычно они стараются отыскать исключения, которые вы не заметили. Правильная
обработка исключений - это мощная защита в предотвращении большого процента
уязвимостей web-приложений. Хотя ваш код может потерпеть неудачу в перехвате
злонамеренного входа пользователя, обработчик исключений может заметить
ошибку до того, как взламыватель успеет использовать её.
Обработка исключений - это лучший метод с многолетним стажем
использования, но ограниченные возможности обработки ошибок в ASP привело к тому, что
многие программисты так и не смогли толком разобраться в работе с
исключениями. ASP.NET представляет намного более надежную систему, преимуществом
которой вы и должны воспользоваться.
Обработка исключений - это нечто большее, чем обработка ошибок.
Некоторые компоненты не вызывают ошибку, но дают информацию об ошибке через
события или свойства. Более того, иногда ошибка так и не возникает, но результаты
выполнения совсем не те, какие вы ожидали. Например, если вы выполнили
запрос базы данных на просмотр записей определенного пользователя, вы будете
ожидать возврат только этой записи. Если же в ответ вы получаете больше одной
записи, у вас возникнут подозрения. Вам всегда следует проверять результаты,
чтобы убедиться, что это именно то, что вы ожидали.
Другие исключения:
■ Код возврата из команд программной оболочки DOS
■ Код возврата с почтовых серверов
■ Размер, длина или тип возвращенных данных
■ Ограничение времени выполнения операции

Фильтры на входе в систему • Глава 5
4
(Подсказка
Иногда природа ошибки не так важна, как её частота. Чтобы повысить
безопасность, вы, возможно, захотите рассмотреть возможность использования
добавления кода, для проверки множественных ошибок, полученных с одного и того же
сервера за определённый период. Поскольку многие атаки зависят от
использования ошибок, получение слишком большого количества ошибок от одного
пользователя, может послужить индикатором атаки.
Способы защиты
■ Воспользуйтесь преимуществом надежных свойств обработки ошибок в
ASP.NET.
■ Проверьте возвращенные результаты, чтобы убедиться, что они
соответствуют тому, что вы ожидали.
«Маленькие хитрости»
Исходное положение: «Маленькие хитрости» играют роль детекторов
мини-вторжений.
Угроза: Получение доступа к коду сервера, получение
доступа к системе файла, выполнение команд,
запросы SQL.
Многим уже знакома концепция горшочек меда, которая разработана
системой для заманивания хакеров в ловушку, давая администратору время для сбора
Данных и выслеживания взламываетеля. Иногда вы не можете предугадать все
возможные типы атак, но вы, по крайней мере, можете обнаружить и
зарегистрировать вторжение. Горшочки меда, при правильном управлении, могут доказать свою
эффективность в качестве систем обнаружения вторжений. Можно интегриро-
вать эту концепцию в ваше web-приложение, используя маленькие горшочки меда,
И-ли Маленькие хитрости. Ниже приведен пример применения этого метода:
1. Разместите уникальные строки через ваше приложение или данные, ко-
°рые вы можете использовать в качестве «маленьких хитростей». Например,
°3Дайте подложные записи базы данных, полей, таблиц или даже завершен-
ь*х баз данных, в зависимости от типа вторжения, которое вы хотите прокон-
Ролировать.

Глава 5 • фильтры на входе в систему
2. Настройте ваше приложение так, чтобы оно никогда не получало допус
к этим данным обычным способом. Например, если вы создали поле базы данных
никогда не используйте обобщение утверждения выбора (такое Ка
«SELECT*FROM»), а вместо этого перечислите требуемые специфические поля
3. Настройте ваше приложение или внешний разборщик пакеток
(или и то и другое) для прослеживания строк, выходящих из вашей базы данных
или web-сервера.
Предположим, что у вас есть web-сайт электронной коммерции, который
принимает транзакции кредитных карточек, и вы хотите использовать «Маленькие
хитрости» для обнаружения любого неавторизованного доступа к вашим данным.
Для этого в вашей базе данных, создайте единичную подложную запись, используя
уникальный номер кредитной карточки, который вы бы не использовали в других
случаях, возможно, состоящий из одних нулей. Убедитесь, что вы
структурировали запросы SQL таким образом, что эта запись не появится при нормальных
условиях, и, следовательно, если она когда-нибудь появится в запросе, это будет
означать большую вероятность вторжения, так же как хакер использует запросы SQL
для получения доступа к вашей базе данных.
Существует несколько способов отслеживания этой строки. Один из них -
написать код и проверять содержится ли он в записи результата каждого
запроса, хотя это предполагает добавление значительного количества обработки
протокольных данных. Другой способ - это использование системы
обнаружения вторжений (IDS), такой как Snort (www.snort.org). для прослушивания
сетевой ссылки между web-сервером и базой данных, а также между web-сервером
и Интернетом. И, наконец, настроить «сниффер» на отслеживание созданной
вами подложной записи и предупреждать вас каждый раз, когда это значение
переходит из базы данных к web-серверу или из web-сервера в Интернет.
Заметьте, что зашифрованные сетевые соединения предотвращают
подслушивание, поэтому вам необходимо устанавливать этот метод в соответствии с вашей
частной конфигурацией.
«Маленькие хитрости» используются не только для базы данных. Вы также
можете использовать их для выявления доступа к файлам, директориям или даже
командам. Ниже перечислены ещё несколько идей:
■ Поместите подозрительный пустой текстовый файл с уникальным имене
в содержание вашей web-директории. Затем настройте IDS для отслежива
ния строки с этим именем файла при выходе из сети.
■ Поместите комментарий сервера с уникальной строкой в ваш исходный
текст для обнаружения доступа к скриптам сервера.

Фильтры на входе в систему • Глава 5
0 Измените переменную в вашей команде подсказки на уникальную строку
для выявления доступа удаленных команд.
«Маленькие хитрости» целесообразны не для всех приложений, но они могут
обеспечить дополнительный уровень защиты, выявляя атаки приложения на
ранней стадии.
Способы защиты
■ Используйте «Маленькие хитрости» в вашей базе данных для выявления
атак запросов SQL.
■ Используйте «Маленькие хитрости» в вашей системе файлов для
обнаружения получения доступа к системе файлов.
■ Используйте «Маленькие хитрости» в вашем исходном тексте для
обнаружения получения доступа к коду сервера.
Ограничение незащищенности
от преднамеренного входа
Атаки приложения широко распространены и разнообразны, но нам ещё
только предстоит выяснить все возможные способы использования хакерами
вашего web-приложения. Также неправдоподобно и то, что все разработчики
100% своего времени будут посвящать написанию защиты кода. Недостатки
безопасности - это сбои, и никакое количество обучающих курсов для
разработчиков или денежных средств, не могут гарантировать код без дефектов.
Поскольку вам приходится использовать все возможности обеспечения защиты
вашего кода, нужно также и принять меры по ограничению подверженности
атакам и сделать ваше приложение более устойчивым к хакерам. В этом
разделе мы рассмотрим:
• Сокращение поверхности атак
* Ограничение диапазона атак
■ Упрочнение приложений сервера

Глава 5 * Фильтры на входе в систему
Сокращение поверхности атаки
Исходное положение: Сократите атаку поверхности вашего прилоясе.
ния для обеспечения ограниченных возможное-
тей для хакеров
Все коды имеют определенную вероятность содержания дефектов. Чем
больше у вас код, тем выше вероятность того, что ваше приложение будет иметь
дефекты. Чем больше дефектов в вашем приложении, тем больше поверхность для
атаки вашего приложения. Поверхность для атаки представляет собой
подверженность вашего приложения атакам, но необязательно уязвимость против атак.
Web-приложение также обладает поверхностью, подверженной атаке. Она
состоит из каждой динамичной web-страницы, каждого открытого TCP/IP порта,
аждой системы аккаунта и каждого запущенного приложения или сервиса, нахо-
ящихся во взаимосвязи с другими факторами. На сокращение поверхности, под-
ерженной атаки, направлено много усилий. Брандмауэр, например, ограничива-
т число TCP/IP портов, имеющих доступ. В самом приложении также существует
множество методов ограничения поверности, подверженной атаке.
Поверхность, подверженная атаке, состоит из любых компонентов вашего
приложения, которые отвечают следующим требованиям:
■ Компонент видим или может быть раскрыт взламывателем.
■ Компонент доступен для взламывателя.
Заметьте, что удаление любой из этих проблем, сократит поверхность
приложения, подверженную взлому. Существует множество креативных методов,
которые можно использовать для сокращения подверженности атаке.
Неиспользованный код
По мере возрастания и расширения свойств web-приложения нужно добавлять
все больше и больше функциональности к ключам модулей. Иногда центральный
модуль берет на себя обработку большей части функциональности приложения-
Рассмотрите, например, этот URL поиска Microsoft механизма приложения, с°
держащего девять параметров:
http://search.microsoft.com/search/results.aspx7na = 81&st = a&View
enus&qu = asp.net&qp =&qa=&qn=&c=2&s=0

Фильтры на входе в систему • Глава 5
Обратите внимание, что этот поиск не использует все параметры, и,
следовательно, их значения остаются пустыми. Хотя это и считается уязвимостью, все же
то увеличивает поверхность, подверженную атаке, поскольку предлагает взламы-
вателю многообразие потенциальных векторов атак. Если вы не используете
некоторые параметры, просто не показывайте их. Чем меньше хакер сможет увидеть,
тем меньше вероятность взлома. Хотя это не увеличивает действительную
поверхность, подверженную взлому, оно оказывает такое же влияние потому, что
ограничивает способность взламывателя раскрывать все доступные параметры.
Внимание
, < Скрытие параметров не означает, что вам не нужно защищать код, который их
обрабатывает. Сокрытие не заменяет защиту, но зато оно усиливает другие меры
безопасности, которые должны иметь место. Чем меньше людей увидят параме-
&щ тры, тем меньше будет проведено атак; следовательно, оно оказывает влияние
^ на сокращение поверхности, подверженной атаке.
Несмотря на то, что нужно скрывать неиспользуемые параметры, вы также
должны учитывать параметры, которые вообще не должны появляться на первом
месте. Можно, например, использовать код обработки параметров, которые не
должны существовать в производственном приложении. Внимательно
просмотрите каждый модуль для определения любых неисправностей или невыполняемого
участка программы. Никогда не полагайтесь на сокрытие этого типа параметра.
Под
сказка
Разработчики программного обеспечеия должны проводить тестирование и
устранение неисправностей кода, и вы неизбежно обнаружите код, который кто-то
забыл удалить. Чтобы предотвратить это, установите метод кодирования так,
чтобы всегда использовать ту же схему тестирования или других временных
переменных. Это облегчает быстрый поиск любого оставшегося кода, который не
должен попасть в производственную среду.
Ограничение доступа
Самым простым способом ограничения поверхности, подверженной атаке,
является ограничение права доступа к коду приложения. Одна
среднестатистически страница HTML защищена намного надежнее, чем полностью функциональ-
^°е приложение электронной коммерции. Чем меньше у вас код, тем меньше под-
^рженность атаки. Поскольку это не реалистичная стратегия, можно добиться то-
0 Же эффекта, ограничив права доступа к компонентам этого приложения.

Глава 5 * Фильтры на входе в систему
Внимательно изучите распределение прав доступа к следующим свойствам:
■ Он-лайн-демонстрация Вы можете захотеть продемонстрировать
свойства вашего приложения при помощи он-лайновой демонстрации, но это
разрешит всем желающим получить право доступа к вашему коду. Вместо
этого, предложите статистическую демонстрацию HTML, которая только
стимулирует свойства приложения. При этом вам не нужно фиксировать
никакие уязвимости, которые могут иметь место, но это позволит вам
сократить поверхность, подверженную атаке, предоставляя право доступа
только для покупателей или зарегистрированных пользователей.
■ Администрация или модули управления содержанием Ваши
административные страницы могут требовать аутентификации для получения
доступа, но сама страница аутентификации может быть уязвлена. Установите
ограничения прав доступа к административным модулям, усилив
IP-ограничения, используя сокрытые порты, сертификаты клиентов и перенеся
административные модули на отдельный web-сайт.
■ Интранет или экстрнет модули Установите ограничения доступа к
модулям интранет или экстранет при помощи тех же методов, которые
используются для административных модулей.
■ Образец кода и приложения Многие web-серверы или приложения
поступают с образцом кода или кодом по умолчанию, или программой, которая
всегда должна быть удалена при перемещении в производственную среду.
■ Приложения третьей стороны Многие организации предпочитают
покупать, а не создавать определенные свойства для своих web-приложений.
Существуют тысячи широко доступных поисковых служб, гостевых книг,
управлений пользователями и систем управления содержанием.
Использование одной из них не сделает вас уязвимым, но подумайте, что
практически любой человек может получить право доступа к исходному тексту.
Такая всеобщая доступность к коду может привести к увеличению
поверхности, подверженной атаке, особенно, если это популярный компонент,
используемый на многих web-сайтах. Некоторые хакеры обнаружат
уязвимые места этих компонентов, а затем при помощи поисковой службы
выяснят, какие именно web-сайты используют этот компонент. Если вы
используете компонент третьей стороны, попытайтесь скрыть их идентиф
кационную информацию и всегда внимательно просматривайте и тести-
ПУЙТР КОЯ

Фильтры на входе в систему • Глава 5
Способы защиты
■ Сократите поверхность приложения, подверженную атаке для
ограничения вторжения хакеров.
■ Не раскрывайте строку запросов параметров, если вы не используете их в
этом частном контексте.
■ Удаляйте тестирование, устранение неполадок и невыполняемый участок
программы из производственного приложения.
■ По возможности используйте статистическое содержание демонстрации
приложения.
■ Ограничьте доступ к административным или другим частным модулям.
■ Удаляйте образец кода или программ из производственного сервера.
■ Избегайте или тщательно проверяйте компоненты третьей стороны.
Ограничение области действия атаки
Исходное положение: Используйте защитные права доступа для
ограничения области действия атак.
Угроза: Злонамеренный вход.
Создание пуленепробиваемого приложения, которое противостояло бы всем
существующим и будущим атакам на уровне приложения, невозможно. Можно
фильтровать вход и сокращать поверхность вашего приложения, подверженную
атаке, но, нужно также учитывать, что кто-то все равно может найти способ
взломать ваш код. Проектируйте ваше приложение таким образом, чтобы
взламывать, даже взломав код, не смог извлечь большой объем информации.
Минимальные привилегии
Важной стратегией является следование принципу наименьшей привилегии.
Усмотрите контекст безопасности пользователя web-приложения и оцените до-
^Уп пользователя к следующему:

Глава 5 • Фильтры на входе в систему
■ Файловая система
■ Ключи системного реестра
■ Исполнители
■ Компоненты СОМ
■ Классы WMI
■ Порты TCP/IP
■ Базы данных
■ Другие web-сайты на том же сервере
Планируйте контекст безопасности вашего web-приложения для ограничения
прав доступа к этим пунктам. Пристальное внимание к безопасности пользователя
будет отделять web-приложения от остальных операционных систем.
Система Server-side
Самой распространенной ошибкой web-разработчиков является предположение
о том, что код server-side защищен от взламывателей. Хотя он и должен быть защищен,
практика показывает, что это не всегда так. Нужно воспринимать его как не
защищенный, и, следовательно, принимать все меры предосторожности в отношении того, что
вы включаете в эти файлы. Код Server-side не самое подходящее место для сохранения
секретной информации, такой как пароли, строки соединений базы данных или
другой восприимчивой информации. Взгляните на ваш код servereide с точки зрения взла-
мывателя, для определения какая информация может быть подвержена риску.
Способы защиты
■ Используйте принцип наименьшей защищенности для ограничения прав
доступа web-пользователей.
■ Избегайте сохранения паролей, частных комментариев или другой
восприимчивой информации в server-side коде.

Фильтры на входе в систему • Глава 5
укрепление серверных приложений
Исходное положение: Многие web-приложения оснащены установками
для защиты от различных типов атак.
Угроза: Злонамеренный вход.
При написании защищенного кода, очень важно защитить себя от атаки, Нои
ASP.NET и IIS, помогают в этом, предоставляя установки для предотвращения или
сокращения атак на уровне приложения. Некоторые из установок по укреплению
вашего web-сервера, которые можно использовать против атак:
Длина запроса
Некоторые атаки полагаются на способность отправлять данные за предполагаемые
ограничения. Переполнение буфера, например, требует отправку очень большой строки
как части web-запроса. HS 6.0 позволяет вам ограничивать размер тела запроса при
помощи таких установок как MaxRequestEntityAllowed и AspMaxRequestEntityAllowed. Обе эти
установки позволяют устанавливать максимальный размер в байтах для тела запроса, как
определено заголовком длины содержания HTTP. Другими словами, заголовок длины
содержания запроса не может превышать пределы, обозначенные этими установками.
MaxRequestEntityAllowed может быть установлена на любом уровне метабазы, таких как
доя сервера, определенных webcaHTOB, виртуальной директории или даже файла.
Установка AspMaxRequestEntityAllowed похожа, но применяется только в ASP файлах.
IIS6 предоставляет установки регистра для контроля длины различных частей
запроса. В таб. 5.6. вы найдете краткое изложение этих установок.
Таб.5.6. IIS6 Установки Реестра для ограничения длины запроса
Ключ реестра: HKLM/Установка текущего контроля/Сервисы/НИР/Параметры
Значение Диапазон Поумолч. Описание
Макс. Длина Поля 64 до 65,534 (байты) 16К Максимальная длина любого
индивидуального заголовка
^«с. Кол-во байтов в Запросе 256 до 16,777,216 (байты) 16К Максимальная длина запроса
URL и любого заголовка
^Кс. длина сегмента URL О до 32,766 (символы) 260 Максимальная длина
любого сегмента URL
(одинарная директория в полном пути)
^Нс- счет сегмента URL 0 до 16,383 (сегменты) 255 Максимальное число
сегментов URL в запросе

Глава 5 * Фильтры на входе в систему
Разрешенные символы
Для ограничения подверженности атакам прослеживания директорий и inady
рования, IIS6 предлагает несколько установок регистра, для ограничения
символов, которые пользователь может отправлять в запросе. Эти две установки
показаны в таб. 5.7.
Таб. 5.7. IIS6 Установки регистра для ограничения символов
Ключ реестра: HKLM/Установка текущего контроля/Сервисы/НТТР/Параметры
Значение Диапазон Значение Реком. Описание
по умолч. значение
AllowRestrictedChars 0или1 О О Если установить на О, принимает шестизначные
скрытые символы в запросах URL, который
декодирует в U+0000 в U+ 001F и U+007F
в U+009F диапазонах
EnableNonUTF8 0или1 1 О Если установить на 1, сервер даст право
доступа запросам, содержащим ANSI
или DBCS символы.
PercentUAIIowed 0или1 1 О Если установить на 1, право доступа получат
запросы, содержащие символы,
зашифрованные в формате %UNNNN
Первая из этих установок, EnableNonUTFS, позволяет вам ограничивать
запросы таким образом, что они содержат только символы, зашифрованные UTF-8.
Это помогает избежать двусмысленности с символами различного шифрования.
Вторая установка, PercentUAIIowed, позволяет пользователям отправлять
запрос URL, используя формат %UNNNN, где NNNN - это значение Unicoda
символа, который вы хотите преобразовать. Нужно ещё раз заметить, что это может
вызвать двусмысленность, поэтому лучше не прибегать к этому методу, по крайней
мере, пока в этом не будет крайней необходимости.
Способы защиты
■ Используйте установку метабазы MaxRequestEntityAllowed
и AspMaxRequestEntityAllowed для ограничения чрезмерной длины запроса-
■ Используйте MaxFieldLenght, MaxRequestBytes, URLSegmentMaxLength
и URLSegmentMaxCount для ограничения длины специфических частей запрос
■ Используйте ключи регистра EnableNonUTFS и PercentUAIIowed
для ограничения действительных символов в запросе.

Фильтры на входе в систему • Глава 5
Краткая справка по стандартам кодирования
управление злонамеренным входом
идентификация источника входа
• Всегда идентифицируйте все источники входа пользователя, включая
все ссылки на объект Request.
• Внимательно идентифицируйте другие непрямые или менее очевидные
источники входа.
Защитное программирование
• Всегда привязывайте пользователя, прошедшего фильтрацию к
переменным, для отделения их от необработанных данных.
• Когда используете VB.NET, применяйте Option Explicit и Option Strict.
• Используйте функции централизованной фильтрации на всех входах
пользователя.
• Никогда не используйте обобщенную совокупность Request при сборе
входа пользователя.
Ограничение на вход
Проверка границ
• Используйте валидатор контроля для подтверждения формы входа,
если страница пересылается сама на себя.
• Никогда не полагайтесь на client-side подтверждение безопасности.
Соответствие образцам
• Используйте устойчивые выражения для подтверждения известных
плохих данных или разрешения права доступа известных хороших данных.
• Используйте регулярные выражения для определения злонамеренных
ключевых слов или других образцов.

Глава 5 * Фильтры на входе в систему
Отражение данных
• Отражайте данные при помощи доверенных систем для предотвращения
таких атак, как прослеживание директорий.
• Всегда работайте с отраженным путем в последовательных операциях.
Шифрование данных
• Используйте HtmlEncode для шифрования строки для выхода браузера.
• Используйте URLEncode для шифрования строки URL для выхода.
• Используйте URLPathEncode для шифрования части пути URL для выход;
Инкапсуляция
• Используйте хэши для инкапсуляции данных для безопасной обработки.
• Преобразуйте хэши в шестизначные символы для создания безопасных
буквенно-цифровых строк.
Параметризация
• Используйте параметризацию для фиксирования контекста или обасти
действия данных пользователя.
• Комбинируйте параметризацию с другими методами для предотвращения
прослеживания директорий.
Двойное шифрование
• Используйте двойное шифрование для обнаружения многоуровненго
шифрования.
• Отклоняйте все запросы, содержащие более чем один уровень
шифрования.
Проверка синтаксиса
• Проверяйте синтаксис любой строки, основанной на входных данных
пользователя, чтобы убедиться, что она соответствует ожидаемому
формату;

Фильтры на входе в систему • Глава 5
Обработка исключений
• Воспользуйтесь преимуществами надежных свойств обработки
исключений в ASP.NET.
• Проверьте возвращенные результаты, чтобы убедиться, что они
согласуются с тем, что вы ожидали.
Маленькие хитрости
• Используйте маленькие хитрости в вашей базе данных для обнаружения
атак
SQL запросов.
• Используйте маленькие хитрости в вашей файловой системе для
выявления доступа к файловой системе.
• Используйте маленькие хитрости в исходном тексте для выявления
доступа к коду со стороны сервера.
Ограничение незащищенности
от преднамеренного входа
Сокращение поверхности, подверженной атакам
• Сократите поверхность приложения, подверженную атакам, для
ограничения незащищенности против хакеров.
• Не показывайте параметры строки запроса, если вы не используете их в
данном контексте.
• Удаляйте тестирование, отладку и невыполняемый участок программы из
производственных приложений.
• По возможности, используйте статистическое содержание в
демонстрациях приложения.
• Ограничьте доступ к администрированию или другим частным модулям.
• Удаляйте образец кода и программ из производственных серверов.
• Избегайте и тщательно проверяйте компоненты третьей стороны.
Ограничение области действия атаки
• Используйте принцип наименьшей защищенности для ограничения
доступа web-пользователей.

254 Глава 5 * Фильтры на входе в систему
• Избегайте хранения паролей, личных комментариев или другой
восприимчивой информации о коде стороны сервера.
Укрепление серверных приложений
• Используйте установки MaxRequestEntityAllowed и
AspMaxRequestEntityAllowed для установки ограничений запроса
чрезмерной длины.
• Используйте установки регистра MaxFieldLength, MaxRequestBytes,
URLSegmentMaxLength и URLSegmentMaxCount для ограничения длины
определённых частей запроса.
• Используйте ключи регистра EnableNonUTF8 и PercentUAllowed для
ограничения действительных символов в запросе.
Краткая справка по проверке кода
Обработка информации, введенной
при злонамеренном входе
Идентификационные ресурсы системы
• Правильно ли приложение определяет все возможные источники входа
пользователя, включая менее очевидные и второстепенные источники?
Защитное программирование
• Привязывает ли приложение отфильтрованных пользователей к
переменным для отделения их от необработанных данных?
• Используя VB.NET, применяет ли приложение Option Explicit
и Option Strict?
• Использует ли приложение функции централизованной фильтрации на
всех входных данных пользователя?
• Избегает ли приложение использования обобщенных совокупностей
Request при сборе входных данных пользователя?

Фильтры на входе в систему • Глава 5
Ограничение входа
Проверка границ
• Использует ли приложение валидаторы контроля для подтверждения
форм входных данных, если страница пересылается сама на себя?
• Избегает ли приложение усиления безопасности через подтверждение со
стороны клиента?
Соответствие образцам
• Использует ли приложение регулярные выражения для блокирования
известных плохих данных или разрешения доступа известных хороших
данных?
• Использует ли приложение регулярные выражения для определения
злонамеренных ключевых слов или других образцов?
Отражение данных
• Отражает ли приложение данные, используя функции доверенных систем
для предотвращения таких атак как прослеживание директорий?
• Всегда ли приложение работает с отраженным путем в последовательных
операциях?
Шифрование данных
• Использует ли приложение HtmlEncode для шифрования всех строк для
выходных данных обозревателя Интернет?
• Использует ли приложение URLEncode для шифрования всех строк URL
для выходных данных?
• Использует ли приложение URLPathEncode для шифрования части пути
всех URL для выходных данных?
Инкапсуляция
• Использует ли приложение хэши для инкапсуляции данных для
безопасной обработки?
• Преобразовывает ли приложение хэши в гексо значения для создания
безопасной буквенно-цифровой строки?

Глава 5 • фильтры на входе в систему
Параметризация
• Использует ли приложение параметризацию для фиксирования контекста
и области действия данных пользователя?
• Комбинирует ли приложение параметризацию с другими методами
фильтрации для предотвращения прослеживания директорий?
Двойное шифрование
• Использует ли приложение двойное шифрование для выявления много-
уровнего шифрования?
• Отклоняет ли приложение все запросы, содержащие более одного уровня
шифрования?
Проверка синтаксиса
• Проверяет ли приложение синтаксис любой строки, основанной на
входных данных пользователя?
Обработка исключений
• Пользуется ли приложение преимуществом надежных свойств обработки
ошибок в ASP.NET?
• Проверяет ли приложение возвращаемые результаты, чтобы подтвердить
их соответствия тому, что ожидалось?
Маленькие хитрости
• Использует ли приложение Маленькие хитрости в базе данных для атаки
SQL-запросов?
• Использует ли приложение Маленькие хитрости в системе файла для
выявления доступа к системе файлов?
• Использует ли приложение Маленькие хитрости в исходном тексте
программы для выявления доступа к коду со стороны сервера?

Фильтры на входе в систему • Глава 5
Ограничение незащищенности
от преднамеренного входа
Сокращение поверхности, подверженной атакам
• Сокращает ли приложение поверхность приложения, подверженную
атакам для ограничения взлома?
• Избегает ли приложение показа параметров неиспользуемой строки
запроса?
• Освобождается ли код от тестирования, удаления неисправностей или
других невыполняемых участков программы?
• Использует ли приложение статическое содержание в демонстрации
приложения?
• Ограничивает ли приложение доступ к администрирующим или другим
частным модулям?
• Освобождается ли производственный сервер от образца кода?
• Подвергались ли компоненты какой-либо третьей стороны проверке
безопасности?
Ограничение области действия атаки
• Использует ли приложение принцип наименьшей защищенности для
ограничения доступа web-пользователей?
• Избегает ли приложение хранения паролей, личных комментариев или
другой восприимчивой информации в коде со стороны сервера?
Укрепление приложений сервера
• Использует ли приложение установки метабазы MaxRequestEntityAllowed
и AspMaxRequestEntityAllowed для ограничения чрезмерной длины запроса?
• Использует ли приложение установки регистра MaxFieldLength,
MaxRequestBytes, URLSegmentMaxLength и URLSegmentMaxCount для
ограничения специфичных частей запроса?
• Использует ли приложение ключи регистра EnableNonUTF8 и
PercentUAllowed для ограничения действительных символов в запросе?

Глава 5 • Фильтры на входе в систему
FAQ
Ответы авторов данной книги на следующие вопросы, рассчитаны как на ваше
понимание концепций, представленных в этой главе, так и на помощь в
претворении данных концепций в реальную жизнь. Для того чтобы получить ответы на ваши
собственные вопросы по этой главе, зайдите на www.syngress.com/solutions
и нажмите на форму «Спросить Автора». Вы также получите доступ к тысячам других
ЧЗВ на lTFAQnet.com.
Вопросы (В) и ответы (О)
Bl Я хочу позволить пользователям вводить некоторые HTML теги, такие как
<Ь> и <i>, но встроенное свойство подтверждения не позволит мне сделать
это. Как настроить ASP.NET, чтобы позволить им сделать это, и как я могу
позволить использовать эти теги, не подвергая других пользователей атаки
межсайтиногового скриптинга?
О: Чтобы позволить пользователям отсылать HTML разметку из формы поля,
строки запроса или файла cookie, вы должны, прежде всего, заблокировать
встроенное свойство подтверждения. Эта установка является атрибутом
элемента <page> в machrne.D^nfig. Вы также можете заблокировать его на
постраничной основе с этим тегом на самой странице:
<%@ Page validateRequest =* *Тгиеи%>
После того как вы заблокируете это свойство, Й^шо вручную зашифровать
входные данные пользователя, чтобы убедиться, что они не содержат HTML
разметку. Затем найдите зашифрованные теги, которые вы хотите разрешить
применять и верните их в оригинальную форму. Например, чтобы позволить
применять жирную разметку, найдите строку &lt;b$rgt и замените её <Ь>. IА°"
вторите это для каждого разрешенного тега. ТакШ| же образом замените все
события &lt;/b&gt; на </Ь>.
Имейте в виду, что поскольку вы заблокировали встроенное подтверждение, ну^
но очень внимательно проверять входные данные пользователя на наличие Н А
разметки.
Bl Уязвим ли ASP.NET против атак переполнения буфера?
Ol Управляемые коды обычно не уязвимы против атак переполнения буф У
но это не означает, что вы в полной безопасности. Поскольку полное
проверенный код обладает способностью вызова неуправляемого кода

Фильтры на входе в систему • Глава 5
го же, как внешние компоненты или вызовы Windows API, риск
переполнения буфера все же есть. Всегда соблюдайте меры предосторожности и
проверяйте длину строки при вызове неуправляемых кодов. Также убедитесь, что
запускаете код с низко привилегированным аккаунтом, и используйте
жесткие ограничения NTFS для ограничения прав доступа к файловой системе.
Например, откажите web-пользователям в доступе к файлам вне содержания
web-директорий.
В; Микрософт утверждает, что вам не нужен URL_Scan с II 6. Существуют ли
какие-либо преимущества использования URLScan для остановки атак на
уровне приложения?
0е. US 6 обладает многими свойствами защиты, которые в большинстве случаев,
делает URLScan неприменимым. Однако есть также и несколько свойств,
которые сокращают атаку поверхности, подверженной этим атакам, и
помогают ограничить атаки на уровне приложения. Например, вы можете
использовать URLScan для блокирования запросов, содержащих определённые
строки, а также можете ограничить длину специфичных HTTP заголовков. См.
www.microsoft.com/technet/security/ tools/URLscan.mspx для более
подробной информации по использованию URLScan с IIS 6.

Глава 6
i •'cj ода,. • ц******•*"
Решения в этой главе:
□ Введение
-I Безопасность данных
"3 Написание безопасной программы
доступа к базе данных
)аткая справка по стандартам кодирования
)аткая справка по проверке кода
261

262 Глава 6 • Доступ к данным
Введение
В зависимости от цели хакера, данные приложения могут стать его первоначал
ной мишенью. В общем, сервер баз данных приложения - это место, где хранится в
личная, восприимчивая информация - от номеров кредитных карт до медицинск "
информации. Многие web-приложения используют нечто вроде хранилища данны
Эта глава посвящена тому, как легко скомпрометировать базу данных и описание ппо-
блем, которые беспокоят многие текущие web-приложения. Однако после прочтения
выводов этой главы, ваше web-приложение может и не стать одним из них.
Чтобы защитить вашу базу данных, мы будем придерживаться восходящего
подхода, рассмотрев с начала методы защиты драйверов, которые используют
приложения для связи с базой данных. Затем мы изучим методы защиты базы
данных как единого целого, используя установку по умолчанию и использование
методов, таких как наименьшая привилегированность. Мы также рассмотрим
межсетевой экран и другие средства защиты вашего приложения, а также попытки
вторжения через монитор. И, наконец, вы углубимся в рассуждения о том, как писать
безопасный код, который обеспечит защитное соединение с вашей базой данных.
Эти рассуждения затронут также специфические подробности способов,
которыми пользуются хакеры для взлома системы с помощью запросов SQL и
многоуровневой защиты, которую можно использовать для защиты вашего приложения.
Типы опасностей, описанные в данной главе:
■ Компрометация данных Взламыватель получает доступ к прочтению или
изменению частных данных.
■ Компрометация базы данных Взламыватель получает доступ в
модификации структуры самой базы данных.
■ Запросы SQL Манипулирование входными данными пользователя для
построения SQL утверждений, которые выполняются на сервере базы данных.
■ Переполнение буфера Переполнение буфера отправкой большего
объема данных, чем он может обработать, приводящее к сбою приложения и
выполнению кода по выбору взламывателя.
■ Расширение привилегий Получение доступа к ресурсам системы или вь
полнение кода в контексте безопасности аккаунта привилегированного
пользователя.
■ Утечка информации Раскрытие восприимчивой информации или ли1*
данных пользователя.

Доступ к данным • Глава б
Защита баз данных
Безопасность вашего кода доступа к данным в значительной степени зависит от
н(ъраструктуры всей базы данных. Уязвимость безопасности может возникнуть из-
сбоя в базе данных или её драйверов, незащищенное расположение базы данных
й ее плохой конфигурации. Перед тем как писать любой код доступа к данным в
-ятем web-приложении, нужно рассмотреть безопасность самой базы данных.
Защита структуры баз данных
Исходное положение: Тщательно разработайте расположение вашей
базы данных, учитывая технологии
межсетевого экрана.
Угроза: Компрометация базы данных, обход мер
безопасности.
Первым важным шагом в защите вашей базы данных является осуществление
основательного контроля доступа к самой базе данных. Нужно разработать
межсетевой экран для ограничения прав доступа таким образом, чтобы прямой доступ
к портам базы данных могло получать только само web-приложение. То, где
физически будет находиться сервер базы данных вашей сети, также влияет на
безопасность базы данных.
Например, допустим, у вас есть web-приложение .NET под именем
myApplication, которое использует базу данных под названием myApplication
Database. Рис. 6.1. демонстрирует общую схему размещения межсетевого
экрана для этого сценария.
Рис. 6.1. Схема размещения межсетевого экрана #2
Internet
Insecure Zone
Firewall
myApplication
Web Server
DMZ
Firewall
-
myApplication
Database
Secure Zone
Company
Database
Employee
Database

264 Глава 6 • Доступ к данным
Заметьте, что межсетевой экран отделяет web-сервер MyApplication от Инте
нета, а другой межсетевой экран отделяет web-сервер MyApplication от базы да
ных myApplication. Место, где установлен web-сервер, называется демилитариз
ванной зоной (ДМЗ). За вторым межсетевым экраном находится база даннь
и внутренняя сеть компании.
Это распространенный сценарий, поскольку многие администраторы
считают, что такая расстановка обеспечивает второй уровень защиты базы данных,
если взламыватель компрометирует web-сервер или другой сервер в ДМЗ. Однако
эта конфигурация может быть и не самой безопасной. Если взламыватель
получит доступ к самой базе данных, например, через запросы SQL или
переполнение буфера, он получит прямой доступ к внутренней сети, обойдя защиту
межсетевого экрана.
Рассмотрите альтернативную схему размещения сети, представленную на рис. 6.2.
Рис. 6.2. Схема размещения межсетевого экрана #2
в
Internet
Insecure Zone
myApplication
Web Server
myApplication
Database
Firewall
DMZ
В этом сценарии мы расположили базу данных в ДМЗ, наряду с web-сервером.
Сервер базы данных в этом сценарии воспринимается как сервер повышенного
риска и отделяет его от других баз данных и остальной внутренней сети.
Размещение сервера базы данных в ДМЗ определяют и ограничивают область действия
атаки базы данных.
Конфигурация вашего конкретного межсетевого экрана будет зависеть
от потребностей вашего приложения, а также от типа данных, хранящихся в оа
зе данных. Где бы вы не размещали вашу базу данных, нужно учитывать возмо
ный риск.

Доступ к данным • Глава 6
Способы защиты
щ Проверьте топологию вашей сети и потребности безопасности для
разработки схемы расположения межсетевого экрана, наилучшим образом
подходящей для вашей среды.
■ Учитывайте самый плохой вариант развития событий при разработке
схемы размещения межсетевого экрана.
Драйвер базы данных - это интерфейс программного обеспечения,
поддерживающий связь с базой данных. Поскольку драйверы существенны для связи базы
данных, они представляют собой известную цель для атаки. Единственное, что вы
можете сделать для защиты драйверов вашей базы данных - это обновлять их.
Также как и наиболее популярное корпоративное программное обеспечение,
драйверы часто обновляются, потому что их уязвимости могут оказать губительное
влияние на систему. Многие вирусы, «черви», и вторжения в Интернет за последнее
время, могли бы быть предотвращены, если бы атакованные системы обновляли
драйверы и программное обеспечение.
Помимо обновления драйверов, еще один приемлемый метод защиты,
которому нужно следовать - это включить ограничение областей вашей системы,
подверженные атаке взламывателем, а также понимание и предотвращение атак
переполнения буфера. Мы также проверим методы регистрации и прослеживания для
определения того, когда и как взламыватели могут осуществить вторжение, или
попытку вторжения, в вашу систему.
Ограничение поверхности, подверженной атаке
Исходное положение: Удаляйте неиспользованные драйверы из вашей
базы данных для сокращения числа векторов атак.
Угроза: Компрометизация базы данных.
Компании по разработке программного обеспечения строят базы данных для
Удовлетворения широкого круга потребностей web-сайтов. Однако ваше
приложение не пользуется всеми доступными свойствами, установленными в базе данных
По умолчанию. Каждое свойство базы данных - это потенциальный вектор атаки;
^едоиательно, неиспользуемые свойства не играют никакой роли, кроме того,
Что увеличивают поверхность атаки для хакера. Сократите эту поверхность, >да-
Ив все неиспользуемые драйверы базы данных.
По умолчанию, Windows 2000 устанавливается с различными драйверами
Отбытого Интерфейса Взаимодействия с Базами Данных (ОИВБД). Если вы не ис-

Глава 6 • Доступ к данным
пользуете ОИВБД, то можете удалить его. Вы должны вручную удалить драйверь
ОИВБД из регистра. При помощи regedit, удалите все неиспользуемые драйверу
из следующих ключей:
■ HKLM\SOFTWARE\ODBC\ODBCINST.INI
■ HKLM\SOFTWARE\ODBC\ODBC.INI
Рис. 6.3. Демонстрирует метод использования regedit для удаления этих ключей
Рис. 6.3- Удаление драйверов ОИВБД из Системного реестра.
Registry Editor
$ш F^orfces
Ш 83Mfcrosoft *
Ш- „jMrabis
Wi <_J Moor* Hey Technology
Ш u3 NewTech Infos/stems
Ш ^Nufcoft
^JNUnit
j& «Д NVIDIA Corporation
£ Z3 0D8C
♦ О ODBCINI
В
„J Conversor de раодпа de a
C3 Driver da Microsoft para a
О Driver do Microsoft Access
Q Driver do MKrosoft dBase
«Л Driver do Mferosoft ExceK*
О Driver do Microsoft Parade
О Driver para о Mfcrosoft Vis
<f,J Mcrosoft Access Driver (*
23 Microsoft Access-Trefcer (
£j Mfcrosoft dBase Driver (*.
„J Mcrosoft dBase VFP Dove
^3 Microsoft dBase-Trefcer (+ ^
►
Name
©(Default)
4
T
RC6J5Z
* a
Data
(value not set)
i
Cjoroputer^YJ^Oe^
Если вы не пользуетесь Jet-драйверами, можно также удалить их. Удалите
неиспользуемые jet механизмы форматы Индексно-последовательного Метода Доступа (ИПМД)>
который вы найдете ниже HK£Y_LOQ\L_MACHINE\SOFTWAIlE\Microsoft\Jet
регистрационного ключа.
И, наконец, некоторые приложения Windows устанавливают названия
источников данных (НИД) Пользователь, Система или Файл. Как правило,
приложения даже не уведомляют вас о том, что они установили эти НИД. Если вы
не используете их, нужно удалить их. Используйте Административные инстру
менты ОИВБД и щелкните на Remove для каждого неиспользуемого драйвера
как показано на рис. 6.4. Или можно удалить НИД, удалив входы пОД
HKEY_LOCAL_MACHINE\SOFTWERE\ODBC.INI регистрационного ключа.

Доступ к данным • Глава 6
рис- 6.4. Удаление НИД
ODBC DM 5. се Ad r to ? X
UserDSN |sy$teroDSN| FfeDSN| Drivers) Тгасж^| ConnectionPooing| About |
Ц$е* Data Sources-
Name Dover A*jd
dB E FI Microsoft dBase Driver ГОД
Excel F Microsoft Excel Driver (" xk) Semove
MS Access Database Microsoft Access Driver f.mdb)
Visual FoxPro Database Microsoft Visual FoxPro Driver £onf«gure~
Visual FoxPro T Microsoft Visual FoxPro Driver
An ODBC User data source stores ^formation about how to connect to
the indicated data provider A User data $смсв&оф visible to>»qu
mi cm cn& be used on the current machine.
OK
jj Cance* 1 ' Help
Подсказка
ft*'* _____
Некоторые обновления или заплаты могут заменять удаленные вами входные
данные. После установки обновлений проверьте ваш регистр и удалите все
восстановленные входные данные.
Защита специфических драйверов
После удаления неиспользуемых драйверов базы данных, вам необходимо
сократить поверхность, подверженную атаке, обеспечив безопасность оставшихся
драйверов. Большинство драйверов базы данных предлагает установки для ограничения
функциональности или ограничения использования драйвера. Мы остановимся на
рассмотрении некоторых примеров установок для различных распространенных драйверов.
SQL-Сервер
Сохранение записи о том, кто пытается войти в вашу базу данных - с многих
т°чек зрения представляет собой ценный метод. Если вы видите многократные
**еУдачные попытки входа под разными именами пользователя или с разными па-
Ролями, можно предположить, что это попытка взламывателя войти в вашу базу
данных методом грубого подбора. Точно так же, если вы заметили, что пользова-

268 Глава 6 • Доступ к данным
тель вошел в систему во внеурочное время, нужно связаться с ним, для подтвер^
дения причин использования базы данных.
SQL-Сервер не проверяет логины и попытки логина по умолчанию. Можно за
регистрировать попытку входа, установив соответствующее значение в ключе
регистра, расположенного на HKEY_LOCAL_MACHINE\SOFTWARE | Microsoft
MSSQLServer\AUDITLe vel. Возможны следующие значения:
■ 0 Входы не зарегистрированы (по умолчанию).
■ 1 Зарегистрированы только удачные входы.
■ 2 Зарегистрированы только неудачные входы.
■ 3 Зарегистрированы удачные и неудачные входы.
Также, по вашему выбору, можно установить уровень записи при помощи
инструмента SQL Server's Enterprise Mangement. Щелкните правой кнопкой мыши на
группу базы данных и выберите Properties. Всплывет новое окно. Выберите на
верху Security. Вы должны увидеть окно, подобное тому, что вы видите на рис. 6.5.
Область проверки уровня позволяет вам устанавливать уровень входа. При
использовании установок регистра или ГИП, установите проверку уровня для
записи всех попыток входа.
Рис. 6.5. Установка максимального уровня входа
SQli vtrPr p rttes (Cw figur ) (10ГА1)
Sattte* JD 5 | В ! Ac*r**D
SQLSe»v* ©vide «AenrtwewtbwwiortW'
aecou*? aroJ * named SQL Sew» togw Ю and wwwi
cwrft-fa**
t
& S «ccounf
Xheeocourt
J ** 1
Расположение SQL-Сервера по умолчанию для записи входов в C:\Progra
Files\Microsoft SQL Server\MSSQL\LOG.

Доступ к данным • Глава 6
I1S и ODBC
Можно настроить IIS на автоматическую регистрацию деталей на источник ОИВБД.
Можно ввести данные, такие как IP-адрес клиента, запрос, выполненный
клиентом, переданные параметры, запрошенная страница, и многие другие свойства
коммуникации связанный пользователей. С этими данными, сохраненными в базе
данных, можно отслеживать и противостоять атакам и аномальной деятельности.
Для установки IIS для ОИИБД, щелкните правой кнопкой мыши на ваш web-
сайт, показанный в Административном окне IIS. Выберите Properties, и вы
увидите окно, подобное тому, какое изображено на рис. 6.6.
Рис- 6-6- Установка IIS для ОИВБД
Dtectoij! Security | HTTPHeadets j Curiom Errors | S £*t j
Wefe$*e|opw 1 Perftxmwe | ISAPIF j HomeD ectexy | Docuroente j
D<t$enp&>r* [Odeu* Web Sil
IPjMAm |iAIUrw«9r»ed)
l£PP*fc 80
Cortnectwn*
<* ilnfewted
Г L To: |
CoenectionT f 900 seconds
P HTTPfceapASves Enabled
—P1- £гиЫв Loggtfjg
Ac%<s tog format
jODBCLoggnjj jj
NCSA ^ , . v.
t И t
WX Extended I. Fife Form*
( OK | Caned |
_J Advanced J |
1
-
gropwt -j
AM* J Нф |
Из этого окна можно выбрать ODBC Logging под названием «Active log
format». После того, как вы выберете ODBC Logging, вам нужно щелкнуть на кнопку
Properties справа, для настройки ODBC DSN, таблицы для ввода входных данных
и логинов ваших пользователей для соединения с ресурсом данных. Можно найти
Перечень структуры таблицы, приемлемой для регистрации, а также скрипт для
с°здания таблицы для вас, в Microsoft't Knowledge Base Article 245243,
Ha http; / /support.microsoft.com/default.aspx?acid = kb:en-us:Q245243.
Jet и ISAM
Если вы используете Jet или ISAM, нужно использовать определенные установ-
101 для повышения вашей безопасности. Jet-драйверы могут и должны работать в

Глава 6 • Доступ к данным
режиме Sandbox. Возможно, вы уже слышали термин sandbox, примененный
к anmieTaMjava.
В отношении jet драйверов его смысл такой же. Sandbox («песочница») - Это
защищенная область памяти, в которой приложение или драйверы смогут
работать без риска повреждения других запущенных приложений. Режим Sandbox
предотвращает внедрение восприимчивых команд, таких как Программная оболочка
в запросах SQL.
Нужно изменить входные данные регистра на HKEY_LOCAL_MACHlNE\
Software\Microsoft\Jet\4.0\engines\SandboxMode для запуска при 3-х значениях,
что наиболее безопасно в режиме Sandbox.
■ 0 Режим Sandbox заблокирован.
■ 1 Режим Sandbox применим только с Access Applications.
■ 2 Режим sandbox применим только с non-Access Applications.
■ 3 Режим sandbox применим ко всем приложениям.
Ещё одна установка, которую можно использовать для повышения безопасности,
связана с текстом ISAM. По умолчанию текст ISAM позволяет вам читать и писать
любые текстовые файлы. Ключ регистра, который контролирует это свойство,
расположен на HKEY_IX)CAL„MACHINE\Sofhvare\Microsoft\Jet\4/0\Engin^
Extensions и по умолчанию содержит значения txt, csv, tab, asc, tmp, htm, html.
Увеличьте ограничения тех файлов, которые могут быть прочитаны и написаны,
заменив вход txt на любое используемое вами текстовое расширение.
Способы защиты
■ Удалите или заблокируйте неиспользуемые драйверы вашей базы данных.
■ Периодически проверяйте и удаляйте новые неиспользуемые драйверы,
особенно после обновлений или установки заплат.
■ Установите драйверы вашей базы данных на максимальную безопасность.
■ Установите драйверы вашей базы данных на регистрацию получения Д°"
ступа на проведение деятельности.

Доступ к данным • Глава б
Обеспечение наименьшей защищенности
Исходное положение: Ограничьте и ужесточите право доступа к вашей
базе данных до минимального числа
пользователей, имеющих право доступа при сохранении ее
функциональности.
Угроза: Утечка информации, компрометизация базы
данных, повышенные права доступа.
Когда программисту нужно установить соединение с базой данных, он часто
пишет код, который применяет самый быстрый и легкий способ соединения и
получения необходимых данных. Это, как правило, включает в себя использование
SQL-Сервера, или Системы Администратора, аккаунт, который имеет право
доступа привилегированного пользователя и не будет создавать разработчику никаких
препятствий с правами доступа и авторизацией. Программист часто думает так:
«Я вернусь и заблокирую систему, когда у меня будет время».
Как показывает опыт, дотянув до последней минуты, программист забывает,
или у него просто нет времени на то, чтобы вернуться и укрепить безопасность
базы данных. Именно с этим может столкнуться приложение в производственной
среде с завышенными правами доступа. Это также объясняет, почему
программист, получив доступ к одной системе, работающей с завышенными правами
доступа, может получить доступ ко всем другим компьютерам этой компании.
Правило наименьшей незащищенности утверждает, что любой пользователь,
приложение или процесс, должен обладать минимальным правом доступа к тому, что
ему нужно сделать для завершения своей функции. Не давайте права доступа,
основываясь на том, что доступ может понадобиться пользователю позже, или, что это
проще, чем вычислять, каким именно должен быть этот минимальный доступ.
Устанавливайте только минимум требуемых привилегий пользователя. Если, в будущем,
пользователю понадобится ещё доступ, предоставьте их именно тогда, но не раньше.
SQL-Сервер обладает различными механизмами для оказания вам помощи в
установлении права наименьшей привилегированности, включая роли, группы
и список управления доступом. Мы уже упоминали первый и наиболее очевидный
(Но часто игнорируемый) способ, которому нужно следовать. Никогда не исиользуй-
Те sa аккаунта для доступа к данным. Sa аккаунта обладает правами делать все, что ва-
Ше приложение, вероятно, не должно делать, например, удаление всей базы данных.
место этого, создайте аккаунт пользователя на SQL-Сервере, который обладает
Равом делать только то, что требует ваш код, будь то чтение таблицы, выполнение
Храненных процедур и т. д. Можно установить права как специфичные, как инди-
**Дуальные колонки таблицы или индивидуально сохраненной процедуры. Как
^Лько вы обнаружите, что вам нужно больше доступа, добавьте эксплицитное пра-
^» которое вам необходимо. Блокируя доступ к базе данных таким образом, очевид-

Глава 6 * Доступ к данным
но, ограничивает действия пользователя. Это эффективно с точки зрения безопас
ности. Если взламыватель взломает вашу базу данных, он обнаружит, что ограничен
теми же правами, что и приложение. Это может потенциально свести к минимум
как данные, которые он может похитить, так и ущерб, который может причинить
Межсетевой экран - это ещё один способ установки наименьшей
привилегированности. Давая разрешение прохода через межсетевой экран только портам,
которые используют ваше приложение, вы ограничиваете нежелательную или неав-
торизованную коммуникацию. SQL Сервер устанавливает соединение через порт
1433 для доступа TCP/IP. Можно изменять эту установку, но имейте в виду, что
изменение порта может усложнить профайлинга трафика и других проверок,
которые полагаются на использование SQL Сервером порта 1433.
Протокол Интернет Безопасности (IPSec) и Протокол Безопасных Соединений
(SSL) представляют собой два дополнительных метода, которые вы используете для
ограничения пользователей, имеющих право доступа к вашей базе данных. IPSec
использует методы, которые состоят из фильтров, фильтров действий и правил. Используя IPSec,
вы эксплицитно определяете, по IP-адресу, какие компьютеры могут устанавливать
соединение с вашей базой данных. Компьютер клиента должен иметь известный и
доверенный сертификат для успешного соединения с базой данных. Преимуществом SSL перед
IPSec в том, что при изменении IP-адреса, не требуется изменение конфигурации.
Используйте правило наименьшей привилегии в течение разработки и
внедрения вашего приложения. Оно является частью надежного основания
безопасности. Мы продолжим рассмотрение этого метода и порекомендуем больше способов
его использования в других областях вашего приложения.
Способы защиты
■ Всегда устанавливайте минимум требуемого доступа и разрешений.
■ Используйте межсетевой экран для ограничения несанкционированного
доступа.
■ Используйте IPSec или SSL для ограничения пользователей, имеющих
право доступа к вашей базе данных.
Защита баз данных
Исходное положение: Удалите неиспользуемые свойства и огранять
установки по умолчанию на вашей базе лая*1
для предотвращения успешных атак.
Угроза: Компрометизация базы данных.

Доступ к данным • Глава 6
Как уже упоминалось ранее, база данных включает в себя множество свойств для
привлечения как можно большего числа пользователей. Вам, возможно, не
понадобится большинство из этих свойств, можно сократить поверхность, подверженную
атакам, заблокировав или удалив эти неиспользуемые свойства. Более того, базы
данных имеют слабые установки по умолчанию. Ниже приведен перечень свойств,
которые можно удалить, а также установок по умолчанию, которые необходимо укрепить:
■ Сохраняйте ваши пакеты обновления, драйверы, обновления, заплаты и
«заплаты» текущими. Пересмотрите вашу базу данных web-сайта
производителя для выяснения доступных сервисных заплат.
■ Используйте надежные пароли для всех аккаунтов. Это особенно важно в
отношении sa аккаунтов, которые представлены в SQL-сервере по умолчанию.
Надежные пароли сокращают способность взламывателя успешного угадывания,
подбора грубым методом, атаки словаря или обнаружения пароля аккаунта другим
методом. Всегда используйте длинные и сложные пароли для аккаунтов баз данных.
■ Удаляйте образец кода, базы данных и сохраненных процедур. По
умолчанию SQL-Сервер устанавливается с базами данных Nortwind и Pubs и
соответствующими сохраненными процедурами. Нет никаких причин
представления этих баз данных в производственной среде.
■ Удаляйте неиспользуемые сетевые библиотеки. SQL-Сервер может
устанавливать связь с приложениями разнообразными способами. Сетевые
библиотеки, или nettles, представляют собой модули, определяющие метод связи,
который может использовать SQL-Сервер. Самый распространенный метод
связи TCP/IP, но можно также использовать Shared Memory, Named Pipes,
Banyan Vines, AppleTalk или VIA GigaNet SAN, а также некоторые другие.
Пока вы решаете, какой метод связи использовать, заблокируйте все сетевые
библиотеки для предотвращения доступа к вашей базе данных. Когда вы
примите решение, какие (ую) библиотеку (и) использовать, заблокируйте все
неиспользуемые сетевые библиотеки для ограничения поверхности атаки.
■ Удалите расширенные сохраненные процедуры. По умолчанию
SQL-Сервер устанавливается с 60 сохраненными процедурами, которые вам могут,
не пригодится. Эти сохраненные процедуры используются, главным
образом, для удобства и обеспечивают функциональность инструментов
графического интерфейса пользователя, такого как SQL Server Enterprise
Manager. Удалив эти сохраненные процедуры, вы ограничите
инструменты и методы, которые взламыватель может использовать для получения
доступа и компрометизации вашей базы данных.

Глава 6 • Доступ к данным
Процесс защиты базы данных сложен и уникален для платформы и базы naj>
ных каждого приложения. Найдите время и изучите специфические меры безо,
пасности для вашей конкретной среды.
Способы защиты
■ Обновляйте программное обеспечение вашей базы данных.
■ Блокируйте или удаляйте неиспользуемые свойства вашей базы данных.
■ Укрепите слабые пароли и права доступа, установленные по умолчанию.
Написание безопасной программы
доступа к базе данных
Вы рассмотрели методы защиты драйверов и самих баз данных, а также различные
установки, которые можно использовать для блокирования функциональности и права
доступа. Однако это только половина решения безопасного доступа к данным. Если ваш код
не фильтрует, должным образом, входные данные пользователя, взламыватель сможет
проникнуть в ваше web-приложение для выполнения SQL-утверждений в базе данных.
В этом разделе вы изучите методы предотвращения получения доступа взламы-
вателем к вашей базе данных. Мы рассмотрим:
■ Связь с источником данных.
■ Защита от SQL-запросов.
■ Написание безопасной программы доступа к базе данных.
■ Прочтение и написание данных файлов.
Связь с источником данных
Исходное положение: Связь с источником данных может потенпиаЛЬ
подвергать опасности восприимчивую информани*"'
Угроза: Утечка информации, нарушение целостное
данных, уничтожение данных.

Доступ к данным • Глава 6 27
Опознавание и авторизация являются жизненно важными элементами при
использовании источника данных. Перед тем как ваше приложение сможет использовать
источник данных, он должен будет аутентифицировать ваше приложение для соединения и
авторизовать виды деятельности, которые пытается выполнить ваше приложение.
Отсутствие хотя бы одного из этих шагов ведет к слабой защите базы данных. Источник данных,
который не проводит аутентификацию, дает право доступа всем и каждому для
соединения, от самых проверенных пользователей до самого опасного хакера. Источник данных
без аутентификации воспринимает всех пользователей как привилегированного
администратора, с правом чтения всех сохраненных данных и выполнения любых изменений
источника данных. SQL Сервер обладает множественными опциями как для проведения
аутентификации, так и для авторизации, которые мы и рассмотрим в этой главе.
Опознавание
Опознавание - это процесс, с помощью которого ваше приложение
устанавливает связь с базой данных. Взламывателю придется потрудиться для получения
доступа к базе данных, с которой он не может установить связь.
Ваше приложение может аутентифицироваться к базе данных SQL-Сервера
двумя разными способами. Мы рекомендуем наиболее безопасный метод,
называемый Аутентификация Windows. При использовании этого метода, Windows
устанавливает логин за вас, так что нет никакой необходимости передавать его по
сети. Поэтому отпадает возможность сохранения имен пользователей и паролей в
строке соединения. У вас есть различные опции методов использования
Аутентификации Windows при соединении с SQL-Сервером из приложения ASP.NET. Эти
опции включают в себя использование процесса идентификации ASP.NET,
использование фиксированной идентификационной информации с ASP.NET,
использование обслуженных компонентов, использование LOGON User API для им-
персонализации определенной идентичности, использование идентичности
вызывающей программы и использование анонимного аккаунта пользователя
Интернет.
Мы рекомендуем использование процесса установки идентичности ASP.NET,
потому что это один из самых простых и наиболее безопасных методов соедине-
Ния. Для использования ASP.NET вам необходимо изменить локальный процесс
^r.NET идентификации значения пароля на web-сервере и создать аккаунт
зеркального отражения на сервере базы данных, создав локального пользователя с
^М же именем и паролем. Мы вкратце отметили необходимые шаги процесса:
1. Измените аккаунт ASP.NET на web-сервере на проверенное, надежное
значение пароля, содержащее заглавные и строчные буквы, цифры и
специальные символы, такие как !, @,# или #. Например, wh!t3Rabitt..hop..hop.

6 Глава 6 • Доступ к данным
2. Измените пароль в Machine.config (обычно находится на (\\
\Windows\Microsoft.NET\Framework\<Framework version>\CONFIG) Ha
элемент processModel.
Например,
<processModel userName = "machine"
password="wh!t3Rabitt..hop..hop">
3. Защитите файл machine.config от неавторизованного доступа, используя ACL.
4. Создайте тот же аккаунт (зеркальный аккаунт) на сервере базы данных.
5. На сервере базы данных создайте логин сервера для локального аккаунта ASP-
NET и отобразите логин в аккаунт пользователя в соответствующей базе
данных. Создайте роль пользователя базы данных, добавьте пользователя базы
данных в роль и настройте соответствующие разрешения базы данных для роли.
После выполнения этого можно соединиться с SQL-Сервером при помощи
Аутентификации Windows. Рис. 6.7. (С#) и рис. 6.8. (VB.NET) приводят пример
строки соединения при помощи Аутентификации Windows.
Рис.6.7 Аутентификация Windows [C#]
SqlConnection sqlConnection = new SqlConnection("server=apollo;" +
"database= EmployeePersonallnformation;" +
"Integrated Security=SSPI;");
Рис.6.8. Аутентификация Windows [VB.NET]
Dim sqlConnection = New SqlConnection( _
"server=apollo; database=EmployeePersonalInformation; " + __
"Integrated Security=SSPI;")
Аутентификация Windows, однако, не всегда возможна. Второй, и менее безопасный,
метод для соединения приложения с базой данных SQL-Сервера - это Аутентификация
SQL. Рассматривайте возможность применения SQL Аутентификации только, если:
■ Ваша база данных не поддерживает Windows Аутентификацию.
■ Ваше приложение не может использовать Windows Аутентификацию из-за
межсетевого экрана.

Доступ к данным • Глава 6 2
■ Ваше приложение должно соединяться с базой данных при помощи
множественных идентичностей, и вы не используете имперсанализацию в
вашей АБР.КЕТприложении.
SQL Аутентификация может быть опасной, потому что логины должны
сохраняться и передаваться базе данных. Нужно защищать логины на сервере приложения, так
ясе как и при передаче на SQL-Сервер. Один из способов - это установить сертификат
сервера в базу данных SQL-Сервера для автоматического шифрования логинов,
отправленных по сети. Можно также использовать канал шифрования IPSec для защиты
средств связи между приложением и SQL-Сервером. Также зашифруйте и строку
соединения с базой данных, которую использует ваше приложение, на случай, если взламы-
ватель обнаружит способ прочтения вашей системы файлов. В следующем разделе мы
рассмотрим методы шифрования строки соединения базы данных. Рис. 6.9. (С#) и рис.
6.10. (VB.NET) показывают пример строк соединения для SQL-Аутентификации.
Рис. 6.9. Строка соединения SQL Аутентификации [С#]
string SqlConnectionString = "Server=apollo;" +
"Database=EmployeePersonalInformation;" +
"uid=colsen;pwd=g01d3n.GREMlin;";
Рис. 6.10. Строка соединения SQL Аутентификации [VB.NET]
Dim SqlConnectionString = New String("Server=apollo;" +
"Database=EmployeePersonalInformation;" + _
"uid=colsen;pwd=g01d3n.GREMlin;")
Защита строк соединения
Защита ваших строк соединения особенно важна, если вы используете SQL
Аутентификацию, потому что строка соединения будет содержать логин и пароль. Вы никогда не
Должны хранить информацию по соединению в самом коде web-приложения. Даже если
ВЬ1 используете Windows аутентификацию, строка соединения все равно содержит
информацию сервера и базы данных, с которой они соединяются. Чем меньше информации
Раскрывает ваш сервер приложения в случае компрометизации, тем лучше. Следующие
Методы представляют собой лучшие альтернативы для защиты вашей строки соединения.
DPAPI
Программный интерфейс защиты данных приложения (DPAPI) - это один из
Наиболее безопасных методов хранения ваших строк соединения, хотя и сложен в

Глава б • Доступ к данным
использовании. DPAPI является частью Windows 2000 и последующих опера.
ционных систем Windows. Используйте DPAPI для шифрования и расшифр0_
вывания данных. Преимущество DPAPI в том, что операционная система
управляет ключом шифрования вместо приложения. DPAP1 также использует
логин аккаунта, вызывая код DPAPI для извлечения ключа шифрования
См. http://msdn.microsoftxom/librar
для более подробной информации по использованию DPAPI в ASP.NET
UDL-файлы
Если вы используете провайдера данных OLE DB .NET, использование UDL-
файлов - ваше право выбора. Проследите, чтобы UDL хранился вне виртуальной
директории web-приложения, и защитите файлы NTFS разрешениями.
Используйте подтвержденный путь для файлов UDL. Имейте в виду, что UDL файлы не
используют шифрование для сохранения информации.
СОМ + компонент
Если ваше приложение включает в себя сервисные компоненты, можно
использовать СОМ + для хранения строк соединения. Сохраняйте строки
соединения и управляйте ими с помощью инструмента Components Service. Для более
подробной информации по использованию строки соединения СОМ +,
см. http://siipporl.microsoft.com/default.aspx?scid = kb;en-us:0271284.
Системный Реестр
Строка соединения может быть сохранена в HKEY_LOCAL_NACHINE или
HKEY_CURRENT_USER registry hive. Используйте соответствующий ACL и
шифрование для защиты любой информации, хранящейся в системном реестре.
Текстовые файлы
Текстовые файлы - небезопасный метод хранения строк соединения. Если нужно
использовать текстовые файлы, убедитесь, что вы их зашифровали, храните их вне
виртуальной директории web-приложения и защитите их с NTFS разрешениями.
Внимание
Никогда не используйте sa или db_owner аккаунты для доступа к данным
приложения. Взламыватели всегда могут сначала предпринять попытку, используя эти
встроенные по умолчанию аккаунты. Убедитесь, что эти аккаунты оснащены на"
дежными паролями и что их можно использовать только для администрирования-

Доступ к данным • Глава 6 27
Двторизация
Авторизация - это процесс, с помощью которого база данных определяет,
имеет ли ваше подсоединенное приложение достаточно прав для выполнения
операций, которые она пытается выполнить.
Другими словами, имеет ли подсоединенное приложение право доступа к
чтению этой таблицы или изменению этой колонки? SQL Сервер обеспечивает
ролевой подход авторизации. Роли могут разрешать или ограничивать право доступа
прочтения или написания базы данных, таблиц, солонок, ролей и сохраненных
процедур. Он поддерживает три категории ролей:
■ Роли базы данных определяемые пользователем Эти роли используются
для группирования пользователей с такими же правами доступа к базе
данных. Например, администратор может образовать роль под названием
Human Recources и уточнить, что эту роль может просматривать только
EmployeePersonallnformation базы данных. Все другие базы данных на
сервере, такие как Cudtomerlnformation, откажут в доступе пользователю
в роли Human Resource. И, наконец, администратору нужно привязать
специфических пользователей в роли. В этом примере, администратор базы
данных, привяжет логин Mrtha из Human Resources роли Human Resource.
■ Роли приложения Это роли, используемые для присвоения особых прав
доступа приложений к базе данных. Приложение использует встроенные
сохраненные процедуры для активации прав.
■ Фиксированные роли базы данных Это фиксированные роли базы
данных SQL Сервера вне блока. Эти роли общего использования
применяются для распространенных видов деятельности, таких как роль dbjbackup,
которая имеет право доступа к резервному копированию базы данных.
Способы защиты
Используйте роли для запроса наименований привилегированных
аккаунтов.
Используйте Windows Аутентификацию всякий раз, когда это возможно.
Сохраняйте строки соединения в безопасности.
Установите надежные пароли для sa и db_aKKayHTOB. He используйте эти
аккаунты в вашем приложении!

80 Глава 6 • Доступ к данным
Защита от SQL-запросов
Исходное положение: Взламыватель может использовать злонамерен-
ный SQL код против вашей базы данных.
Угроза: Утечка информации, нарушение целостности
данных, уничтожение данных.
Атаки SQL запросов один из самых опасных и распространенных атак
web-сайтов в наше время. Атака SQL-запросов основывается на пользователе,
предумышленно провацирующем базу данных на выполнение разрушающих и компромети-
зирующих команд SQL. Мы приведем специфические примеры методов
использования хакерами запросов SQL, информации, собранной взламывателями,
и ущерб, который они могут нанести. Затем мы также рассмотрим несколько
методов предотвращения этих атак.
Пример SQL-запроса
Практически все web-сайты читают информацию, введенную пользователями
от логина до критериев поиска. Когда пользователь вставляет в SQL-данные,
которые будет обрабатывать база данных, происходит вторжение SQL. Например, web-
сайт может читать логин и пароль во время выполнения логина и проверять базу
данных, чтобы посмотреть, действительна ли информация логина. Обычная и
незащищенная строка запроса SQL может выглядеть как строки, показанные
на рис. 6.11. (С#) и рис. 6.12. (VB.Net).
Рис. 6.11. Обычная строка запроса [С#]
string queryString = "select * from Accounts where username = '" +
Request.QueryString["username"] + " ' and password='" +
Request.QueryString["password"] + " '";
Рис. 6.12. Обычная строка запроса [VB.NET]
Dim queryString = New String("select * from Accounts " + _
"where username = •" + Request.QueryString["username"] + _
"' and password='" + Request.QueryString["password"] + "'")

Доступ к данным • Глава 6 2
Внимание
| ;: Строки запроса SQL на рис. 6.9. и 6.10. имеют множественные, существенные
*f проблемы. Если в вашем коде содержатся строки подобные этой, вы подверже-
| ны атаке на многих уровнях. Пожалуйста, продолжайте изучение методов защиты
у - ваших запросов.
Целью является ввод пользователем своей информации, что приведет к
запуску строки, которая будет работать против базы данных:
select * from Accounts where username = 'chris',
password='Gob.stop.er.112'
Система использует результаты, полученные в результате запроса, чтобы
разрешить или запретить доступ. Как бы то ни было, для ввода имени пользователя
хакер должен будет ввести
hahaha
и в графе пароль:
'; drop table Accounts
Это означает, что данный запрос нарушает работу базы данных
select * from Accounts where username = 'hahaha1,
password=''; drop table Accounts
Можно сделать два вывода. Первый - о том, что подставлять в нужную графу
имя пользователя hahaha бесполезно; второй вывод нарушает ваши расчеты
0 the second statement destroys your accounts database table.
Это пробел в приложениях SQL: особый код, введенный злоумышленником,
нарушает работу системы, если его не удалить.
Некоторые методы могут помочь вам предотвратить эти атаки.
• ' - открывает и закрывает последовательности в базе данных;
• ; - обозначает окончание определенного абзаца;
■ ™ - создает комментарий: «все написанное после этого знака - игнорировать».
Ниже охарактеризованы некоторые из типов атак, которые хакер может со-
^ршить для компрометации и разрушения базы. В этих атаках использована наша
°ригинальная последовательность запросов, показанная на рисунке 6.9.

82 Глава 6 • Доступ к данным
Взлом информации о структуре базе данных. Хакер будет считать атаку
удачной, если ему удастся определить, структуру базы, информацию о том
какие колонки или таблицы имеются в наличии. Установленное по
умолчание поведение SQL-сервера должно быть таким - выдать информацию об
ошибке, если задан некорректный запрос. Например, если хакер вводит в
качестве имени пользователя:
1 having 1-1
система выдаст сообщение об ошибке, содержащее информацию о
неверном вводе запроса, как показано на рис. 6.13.
Рис. 6.13 Вывод сообщения об ошибочном запросе
Сoiumo'Accountsu*ernam "ismv * Hit feet Brit tec -' ■ 1Ы * f« -• .-.**: - D X
©fe Ш $ew Favorfces Josls Help
iBacfc |j; Se ch Favorite* Media * Г""* ...
$S [ Н«р://»оса1ю5У5011пЭй»«£хатр1е^еЬРогт1,в$рж " ]*] \ ^0
I I [Its ^bohdx CRA =. tiavse- bcefoost " producbori vbscrfct4 wefesfeagHg Commerce ■ **
Se ver Error in '/SQLIrf ction Exam pie* pplication
Column 'Accounts.username' is invalid in the select list because it
is not contained in an aggregate function and there is no GROUP
BY clause.
Description: An unhanded ехсе|а*юп occurred dunngthe execution of the current web request Ptease review the backtrace
for more frrformation about the error and where ft originated m the code
Exception Details: System Data.ScjOent SctfExceptfcwr Column 'Accounts username* is invalid in the select list because It №
not contained in an aggregate function and there ts no OROUP BY clause
/
, i©ca**rttranet
Как видно, сообщение об ошибке включает слова «Accounts'» и «username»-
Параметр group by идет дальше в этом запросе, как показано здесь:
1 group by Accourits.username having 1=1-
Система выдаст сообщение об ошибке при создании этого запроса, как п
казано на рис. 6.14.

Доступ к данным • Глава 6 2
рис- 6.14 Следующая колонка при выводе сообщения
об ошибочном запросе
Cokimn'Att. «.• word* I«y tnthe t * с >
£cfc $ew Fayorites loote ijelp
Back Search Favorites Media *
5 j W^:/flocalK«t/SQlIn>ection£xempte/WebForml aspx | So
Unfcs bondx GRA devserver Joarfhosfc product*** vbscr?)!; wehsfcac**g Commerce *
л
S rv r Error in ! SQLInj cticnExampIe1 Application.
Column 'Accounts password* is invalid in the select list because Л
is not contained in either an aggregate function or the GROUP BY
clause.
Description: An urihandled exception occurred during the execution of the current web request Please review the stack trace
for more information about the error and where ft originaied in the code
Exception Details: System .Data SqK3ent.Sq£xception: Column "Accounts .password* is «nvaJtd in the «elect tot because it te
not contained in either an egate function or the GROUP BY clause
A ~"
Done , local internet
^
Данное сообщение содержит информацию о следующем параметре
запроса - о пароле. Хакер может попытаться продолжить подбор элементов до
тех пор, пока вывод сообщений об ошибке прекратиться. В нашем примере
последовательности запросов взломщик остановит появление страниц,
выдающих информацию об ошибке, после ввода следующей записи:
1 group by Accounts.username,Accounts.password having a~a--
Вывод сообщений об ошибке прекращается, потому что колонка в таблице
«Accounts» представлены как группа по одному признаку. Теперь хакер
знает, какие колонки есть в этой таблице и может ввести нужную для получения
доступа запись.
Похищение информации о содержании базы данных. Взломщик может
выяснить характер данных, которые содержатся в базе, используя переделанное
сообщение об ошибке. В этом случае, когда появляется запрос о некорректном
изменении, сервер SQL выает сообщение о запрете подобных действий.
Например, если хакер вводит такое имя пользователя:
1 union select min (username) , 1 from Accounts where
username > 1 -

Глава 6 • Доступ к данным
система выдает первое имя пользователя из таблицы «Accounts», в данном
случае «admin,» как показано на рис. 6.15.
Рис. 6.15 Значение имени пользователя отражено
в сообщении об ошибке.
Syntax rorcow ■ thevarch v •« "k a • iflf ■ « « -Ox
F Ш &»* Pavonte* look Нф
Back * Search Favorites Med» **
ess|^tp://loce»K»st/5<^In)ectkxTEx<yr^/WdDPorTnl .a$px " _J Go
Unks i bondx CRA devserver locatiost production vbseript webstaojrio. Commerce
Server Error in ' SQLInjection Exam pie1 Application.
Syntax error converting the varchar value 'admin' to a column of
data type int
Description: An unhanded exception occurred dumgthe execution of the current web request Please review the stack trace
f or more inf ormatton about the error and where it ongtaated*» the code
Exception Details: System Data SqOent.SqExcepbDn. Syntax error converbngthe varchar value 'admtn'to a column of data
typemt.
Done toeaf intranet
Хакер мог применить тот же метод для приложений SQL, то есть ввести
«суррогатный» пароль для определенного логина и узнать пароль
администратора, и подобным образом добраться до каждой записи таблицы или
записи в базе данных.
Нарушение целостности базы данных Эта атака нарушает корректность
запросов, нарушая выполнение корректных запросов, часто с помощью
закрытия кавычки и/или точки с запятой, и затем добавляя элементы, которые
нарушают пунктуацию SQL-запросов. Вот примеры некорректных записей,
которые могут быть введены в качестве пароля:
1; delete from Accounts
или
'; insert into Accounts (username, password) values
('hahaha', '0wn3d')
Эти запросы являются результатом намеренного запуска пустого паролЯ
или случайного ввода «разрушительного» пароля.

Доступ к данным • Глава 6 28
■ Компрометация запроса Хакер может сократить или обойти процесс
аутентификации. В этом примере в качестве имени пользователя было введено следующее:
admin1—
Используя метод, показанный на рисунке 6,1, можно преждевременно
остановить SQL запрос, чтобы остановить его после ввода логина «admin».
Если (что является большой ошибкой) такое имя пользователя существует,
хакер обходит пароль админа, и система становится уязвимой для атаки,
позволяя войти в систему как «admin» с верным паролем.
Логическая последовательность тоже может нарушить ход выполнения
запроса. Если в качестве имени пользователя хакер вводит:
or a=a—
то хакер войдет в систему в качестве первого пользователя из таблицы
в базе данных. Этот способ сработает, так как сервер SQL будет считать
элемент а=а соответствующим первой записи из таблицы.
Есть и более другие методы для взлома SQL-приложений. Большинство
хакеров используют как минимум один из описанных способов, так что этот список не
является исчерпывающим. Хакеры постоянно придумывают новые пути
проникновения в системы, основанные на SQL. К счастью, существуют меры защиты
от этих атак.
Многие web-сайты содержат информацию, что для защиты SQL-приложений
достаточно фильтровать или избегать характерных для хакеров символов,
например ', -, и ;. Но этого недостаточно. Ниже описаны решения, с помощью которых
можно улучшить защиту. Рекомендуем использовать эти методы в комбинации
Друг с другом.
Избегайте использования «опасных» символов
Это простейший способ предотвращения атак на SQL. Идея в том, чтобы как
минимум отфильтровать «опасные» для системы знаки, которые может ввести
пользователь и которые могут нарушить работу базы данных.
У этого метода есть и недостатки. «Опасные» знаки могут быть значимой
частью информации, вводимой клиентом. Например, если вы запретите
использование символа ('), то при вводе названии компании или пароля пользователя могут
Появиться проблемы. Как минимум, может появиться сообщение об ошибке, о за-
^Домо ложных данных. Заведомо ложные данные - символ, который не должен
Употребляться вне SQL-элемента, например символы «-» или «;». Если
установлено, что эти символы не подходят для ввода в специальные поля, например, полю
*Имя пользователя» или «пароль», то получается, что запрещены знаки препина-

6 Глава 6 * Доступ к данным
ния, поэтому клиент не сможет ввести эти символы как часть логина или пароля
о чем система ему сообщит.
Фильтр на использование символов в общем затрагивает удваивание «опаг-
ных» символов, так что система воспринимает их как буквы, а не как символ,
закрывающий строку запроса. На рис. 6.16 (С#) и 6.17 (VB.NET) показано, как
избежать этой проблемы.
Рис. 6.16 Запрет на использование символа «'»[С#]
private string escapeQuoteCharacter(string stringToEscape) {
{
return stringToEscape.Replace("'", '"'");
}
Рис. 6.17 Escaping the ' Character [VB.NET]
Private Function escapeQuoteCharacter(ByVal stringToEscape As String)
As String
Return stringToEscape.Replace("'", "ll")
End Function
Этот способ сам по себе не является окончательным решением, ведь у хакера
остается возможность ввести данные в вашу базу данных, которые позже могут
нарушить ее работу. Например, хакер введет следующее имя пользователя:
Timebomb'; drop table account—
Метод «избегайте кавычек» прерывает последовательность. Новая
последовательность означает:
Timebomb''; drop table Accounts—
После дублирования символ «'» читается как буква, и система заносит их в базу данных.
Timebomb1; drop table Accounts—
В этом случае не наносится ущерб, так как символ «'» помечен как буквенный,
просто у пользователя странный логин. В этом примере предположим, что
таблица «Accounts» содержит и колонку «e-mail». Представим, что могло бы случиться,
если бы web-сайт попытался отправить всем пользователям послание по электро**"

Доступ к данным • Глава 6 28
ной почте. Система создавала бы типовые имена пользователей, которым нужно
было бы осуществить рассылку по электронной почте. В соответствии с этой
записью система продолжала бы работать, если бы нужно было отправить послание на
адрес, соответствующий имени пользователя, под которым вошел хакер:
select email fran emailAddress where username=' Timebomb'; drop table
Accounts—'
Символ «'» в имени пользователя закрывает текущую строку, элемент,
нарушающий целостность, добавлен, и закрывающая кавычка не учитывается. База
данных принимает имя пользователя и удаляет таблицу «Accounts». Чтобы
предотвратить подобную атаку, не оставляйте информацию о выполненных базой запросах.
Если в приложении используется метод «избегайте кавычек», каждый
пользователь, перед тем, как отправлять послание по электронной почте, будет проверен,
и атака провалится.
Другой недостаток заключается в том, что этот метод не спасает, если хакер
будет использовать шестнадцатиричные знаки ASCII или другие знаки, чтобы
обойти это препятствие. База данных и код воспримут такие знаки как корректные.
Использование SqlParameters
.NET Framework содержит набор типов параметров SQL, которая называется
SqlParameter. Эта система позволяет автоматически задавать тип и длину
информации, которую вводит пользователь. На рис. 6.18 (С#) и 6.19 (VB.NET) показано,
как использовать набор SqlParameter, чтобы обозначать переменные, когда вы
пишете программу в SQL.
Рис. 6.18 Использование SqlParameters
при составлении SQL-программы (С#)
SqlDataAdapter command =
new SqlDataAdapter("select password from Accounts " +
"where password=@password", conn);
SqlParameter SqlParameter =
command.SelectCommand.Parameters.Add("^password",
SqlDbType.VarChar, 8);
ScJlParameter. Value = Request. Form [ "username" ] ;

8 Глава 6 • Доступ к данным
Рис. 6.19 Использование SqIParameters при составлении
SQL-программы (VB.NET)
Dim command = New SqlDataAdapter("select password " + _
"from Accounts where password=@password", conn)
Dim sqlParameter = command.SelectCommand.Parameters.Add( _
"@password", SqlDbType.VarChar, 8)
sqlParameter.Value = Request.Form["username"]
Используйте этот метод и при запуске сохраненных процедур. На рис. 6.20
(С#) и 6.21 (VB.NET) приведен пример использования SqlParameteiTyra этой
процедуры.
Рис. 6.20 Использование SqIParameters при запуске
сохраненных процедур (С#)
SqlDataAdapter command = new SqlDataAdapter("Accountlnsert", conn);
command.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter sqlParameter =
command.SelectCommand.Parameters.Add("@username",
SqlDbType.DateTime, 8);
sqlParameter.Value = Request.Form["username"];
Рис. 6.21 Использование SqIParameters при запуске сохраненных
процедур (VB.NET) ^ __
Dim command = New SqlDataAdapter("Accountlnsert", conn)
command.SelectCommand.CommandType = CommandType.StoredProcedure
Dim sqlParameter = _
command.SelectCommand.Parameters.Add("@username", _
SqlDbType.DateTime, 8)
sqlParameter.Value = Request.Form["username"];
База данных принимает данные, обозначенные как parm. Value как буквен
поэтому не нужно ограничивать пользователя при вводе информации. Замет
что SqlParameter к тому же задает определенные типы и их величину. Если то,
пытается ввести пользователь, не соответствует заданным параметрам, сист
выдает сообщение о невозможности ввода. По возможности, обязательно пр
сывайте параметры для информации, которую вводит пользователь.

Доступ к данным • Глава 6 28
Прописывание типа и длины данных
Если вы собираете данные, полученные от пользователя, сохраняйте их
отдельно от базы данных. Номера ID лучше хранить как номер в базе данных.
Пароли, состоящие из 8 символов, лучше хранить в поле типа varchar максимум на 8
знаков. Если вы сочетаете использование SqlParameter и предустановленных
параметров данных, ваша система может забраковать несоответствующие установкам
данные. Например, если хакер пытается внедрить аккаунт для нового
пользователя, запись выглядит следующим образом:
•; insert into Accounts (username, password) values
('hahaha', '0wn3d')
наш SqlParameter код определит, что длина пароля превышает 8 знаков и запретит доступ. В
качестве альтернативы, если взломщик пытается предпринять подобную атаку на числовое
поле,, SqlParameter код предотвратит ее, потому что эта атака затронет и поля других типов.
Использование минимальных привилегий
Ограничьте пользователя базы данных в действиях. Если ваше приложение
предназначено только для чтения данных из базы, ни к чему разрешать
пользователю удалять таблицы, вставлять данные или делать что-то кроме чтения.
Уменьшение доступа сократит поле атаки и, соответственно, возможный ущерб.
Запрет на употребление опасных команд
В зависимости от того, для чего предназначено ваше приложение, возможно,
вам стоит запретить запросы, основанные на неверных данных, потому что они
могут нести угрозу. С другой стороны, можно применить принцип минимальных
привилегий. Представим, что мы ограничиваем ввод пользователем данных, опас-
Hbix для SQL команд, таких как drop или delete. На рис. 6.22 (С#) и 6.23 (VB.NET)
показан пример установки фильтра на потенциально опасные для SQL команды.
^С- 6.22 Отсеивание опасных для SQL команд (С#)
Private bool containsBadData(string stringToCheck)
{
string[] badData = new string[]
{ "drop", "delete", "insert", "update" };
for (int x=0; x < badData.Length; x++)

90 Глава 6 • Доступ к данным
Рис. 6.22 Filtering Dangerous SQL Commands (C#)
if (stringToCheck.IndexOf(badData[x]) > -1)
return true;
}
return false;
Рис. 6.23 Отсеивание опасных для SQL команд (VB.NET)
Private Function containsBadData(_
ByVal stringToCheck As String) As Boolean
Dim badData = _
New String() {"drop", "delete", "insert", "update"}
For x As Integer = 10 To badData.Length
If (stringToCheck.IndexOf(badData(x) ) > -1) Then
Return True
End If
Next
Return False
End Function
Если метод возвращает сообщение true, пользователь может ввести запись,
содержащую неверные данные. Можно посмотреть еще дальше, и прописать
устойчивые выражения, чтобы вычислить хакера, который пытается ввести строку SQL
в поле. Постарайтесь понять, кто именно вводит эти выражения. Если вы
обосновываете поля, которые содержат комментарии пользователя, могут быть
легальные причины, по которым пользователь вводит эти выражения.
Работа сервера с ошибками
Как уже объяснялось на примерах с SQL-приложениями, сообщения об
ошибках могут дать хакеру много детальной информации о вашей базе данных.
Скроите принципы работы базы с помощью Try и Catch утверждений, особенно тщатель
но проверьте работу сервера при подаче неправильных запросов. В настройке
Catch введите детали произошедшей ошибки. Это поможет вам узнать, что был
предпринята попытка атаки, удачная или неудачная. Прописывая ошибки на сер
вере, вы предотвратите вывод сообщений об ошибке и, соответственно, важны
деталей, клиенту. Помните, что успешная атака на SQL-приложение необязатель

Доступ к данным • Глава 6
Приведет к ошибке. В начале атаки на SQL-приложение хакер может просто
собрать информацию о вашей базе данных, чтобы лучше подготовить нападение.
Более подробно этот случай описан в Главе 7.
Если вы тщательно осуществите эти решения, вероятность атак на ваши SQL-
приложения резко сократится. Но не забывайте, что методы защиты необходимо
постоянно обновлять, потому что хакеры все время изобретают новые способы
взлома различных баз данных. На этих сайтах вы можете получить более новую
информацию о способах защиты SQL-приложений:
■ www.nextgenss.coin/papers.htnil
■ ww7w^governmentsecurity.org /articles/
SQLInjectionModesofAttackDetenceandWhyltMatters.php
■ www.owasp.org
Способы защиты
■ Используйте методы защиты SQL-приложений в сочетании друг с другом,
не ограничивайтесь использованием только одного метода.
■ Предотвратите вывод сообщений об ошибки для пользователя.
■ Используйте SqlParameters.
■ Пропишите все варианты ошибочного ввода на сервере.
■ Не предоставляйте пользователям излишних полномочий.
Написание безопасного SQL-кода
Исходное положение: Код, написанный с учетом требований
безопасности, защитит ваше приложение от возможных атак.
Угроза: Утечка информации, нарушение целостности
или уничтожение данных.
Окружающая среда, например Интернет, таит много угроз для вашего
приложения, но эти угрозы могут еще не существовать в тот момент, когда вы пишете
Программу. Но если вы хотя бы стараетесь предугадать возможные способы
взлома, вероятность удачной атаки резко падает. Вот примеры того, как снизить
уязвимость вашей системы и повысить безопасность данных.

Глава 6 * Доступ к данным
■ Избегайте записи «SELECT * FROM» Используйте оригинальные
называния колонок, чтобы ограничить возможности для атаки. Используйте
символ «*» как простейший способ, чтобы избежать нумерации колонок,
которые вам нужны из базы данных, но дает хакеру больше данных для «работы»
С помощью этого символа хакеру проще манипулировать запросом и
избегать сообщения об ошибке, если «*» будет означать «все, что угодно». С
помощью наименования специфически колонок в своем запросе, вы
ограничите его структуру и выход, затрудняя хакеру создание запроса для атаки.
Всегда устанавливаете минимальные настройки для данных.
■ Проверяйте результаты запросов query results Можно повысить
«иммунитет» вашей системы с помощью проверок результатов действия мер,
принятых вами для повышения уровня безопасности. Например, попробуйте
выяснить информацию о пользователе, занесенном в базу данных, если его
имя уникально. Убедитесь, что в результате настройки одному имени
пользователя соответствует один пароль, и снесите приложение, если это не так.
Стоит застраховаться. Может последовать атака, в результате которой данные
пользователей могут стать достоянием хакера, или ваша база может рухнуть.
Затраты на проверку базы данных окупятся, потому что в случае атаки ущерб будет
еще большим.
■ Используйте сохраненные процедуры. С их помощью можно не только
ускорить работу приложения, но и повысить уровень безопасности. Тот
факт, что эти процедуры невозможно изменить, является защитой от атаки
(правда, не стопроцентной), и минимизирует количество выдаваемой
информации. Каждой сохраненной процедуре стоит прописать свой уровень
безопасности. Пользователь, которому запрещено вносить изменения,
должен иметь доступ только к «read-only» сохраненным процедурам, то есть все
должно быть подчинено правилу минимального увеличения привилегии.
Также, в случае компрометации системы, хакер не сможет сделать выводы
о структуре вашей базы данных, если установлены сохраненные
процедуры. Взломщик узнает, через какой логин и пароль вы запустили
сохраненную процедуру CreateAccount, но он не узнает названия таблиц или
колонок, которые можно изменить через эту процедуру.
■ Структурируйте систему для повышения безопасности. Изменив
порядок, в котором работает ваша система, можно повысить уровень
безопасности. Например, попробуем снова использовать сценарий с входом в систе
му, с момента начала сеанса работы это самое уязвимое место для атаки-
Общий код для аутентификации пользователя на web-сате показа
на рис. 6.24 (С#) и 6.25 (VB.NET)

Доступ к данным • Глава 6
рис. 6.24 Общий код аутентификации (С#)
SqlDataAdapter adapter =
new SqlDataAdapter("select username from Accounts " +
"where username=@username and password=@password", en);
SqlParameter sqlParameter =
adapter.SelectCommand.Parameters.Add("@username",
SqlDbType.VarChar,15);
adapter.SelectCommand.Parameters["@username"].Value =
username.Text;
sqlParameter =
adapter.SelectCommand.Parameters.Add("^password",
SqlDbType.VarChar,8);
adapter.SelectCommand.Parameters["@password"].Value =
password.Text;
DataSet ds = new DataSetO;
adapter.Fill(ds, "authenticate");
if (ds.Tables["authenticate"].Rows.Count == 1)
{
authenticated();
}
else
{
rejected();
}
Рис. 6.25 Общий код аутентификации (VB.NET)
Dim adapter = New SqlDataAdapter("select username " +
"from Accounts where username=@username and " + _
"password=@password", en)
Din\ sqlParameter = _
adapter.SelectCommand.Parameters.Add("@username", _
SqlDbType.VarChar, 15)
a<iapter. SelectCommand. Parameters ("@username") .Value =
username.Text
SqlParameter = adapter.SelectCommand.Parameters.Add(

Глава 6 • Доступ к данным
"^password", SqlDbType.VarChar, 8)
adapter.SelectCommand.Parameters("@password").Value
password.Text
Dim ds = New DataSet
adapter.Fill(ds, "authenticate")
If ds.Tables("authenticate") .Rows.Count = 1 Then
authenticated()
Else
rejected()
End If
Система просто берет данные пользователя (имя и пароль) и осуществляет
запрос, чтобы увидеть, есть ли аккаунт в базе данных, которому
соответствуют эти данные. Этот код неплох, но его можно и улучшить. Представим,
что случится, если с помощью другого метода хакеру удастся ввести SQL
в имя пользователя, чтобы пароль не был проверен администратором. (See
the «Compromise a Query» bullet point in the «Preventing SQL Injection»
section for details on this attack.) The code will authenticate the user if there is an
account with a username admin without the attacker knowing the password.
Предотвратить подобную атаку можно с помощью незначительного
изменения структуры кода аутентификации. Избегайте использования пароля
пользователя, основанного на предоставленном имени пользователя. Если
запрос возвращает пароль, проверьте его If the query returns a password,
check the retrieved password against the user supplied password for a match.
Рисунок 6.26 (C#) и 6.27 (VB.NET) показывают, как это осуществить.
Рис. 6.26 Улучшенный код аутентификации (С#) ___
SqlDataAdapter adapter =
new SqlDataAdapter("select password from Accounts " +
"where username=@username", en);
SqlParameter sqlParameter =
adapter.SelectCommand.Parameters.Add("@username",
SqlDbType.VarChar,0);
adapter.SelectCommand.Parameters["@username"].Value =
username.Text;

Доступ к данным • Глава 6 3
nataSet ds = new DataSetO;
adapter.Fill(ds, "authenticate");
j^f (ds.Tables ["authenticate"] .Rows.Count == 1 &&
password.Text == ds.Tables["authenticate"].Rows[0]
["password"].ToString())
{
authenticated();
}
else
{
rejected() ;
}
Рис. 6.27. Улучшенный код аутентификации (VB.NET)
Dim adapter = New SqlDataAdapter("select password " +
"from Accounts where username=@username", en)
Dim sqlParameter = _
adapter.SelectCommand.Parameters.Add("@username", _
SqlDbType.VarChar, 15)
adapter.SelectCommand.Parameters("@username").Value =
username.Text
Dim ds = New DataSet
adapter.Fill(ds, "authenticate")
*f ds.Tables("authenticate").Rows.Count = 1 And _
password.Text = ds.Tables("authenticate").Rows(0) _
("password").ToString() Then
authenticated()
Else
rejected()
End if
Этот код больше не уязвим против вышеупомянутой атаки SQL-запросов.
В случае с этим логином введенный хакером пароль должен
соответствовать паролю, возвращенному из базы данных.

96 Глава 6 • Доступ к данным
Программирование с учетом проблем безопасности может предотвратить
текущие и будущие взломы. Важно оценить, насколько область кода уязвима для ата
ки и затем применить одно или более предложенных решений. Вы хотим под
черкнуть важность написания безопасного кода входа. Те же самые меры предо
сторожности могут и не применяться с внутренним модулем, который рассчиты
вает коэффициент серьезности (по крайней мере, если вы работаете с NASA)
Но, если применять принципы безопасного кодирования, можно на один шаг
опережать хакера.
Способы защиты
■ Восстанавливайте минимум требуемых данных из сервера.
■ Проверяйте результаты на наличие ожидаемых свойств.
■ Используйте кодирующие структуры, усиливающие безопасность.
Чтение и написание массивов данных
Исходное положение: Хакер может нанести ущерб или разрушить
ваше приложение или операционную систему,
атакуя массивы данных
Угроза: Компрометация и/или удаление данных,
приложения или операционной системы
Любое приложение, которое обрабатывает (читает и пишет) массивы данных,
подвержено ряду угроз. Массив данных может быть взят из файла программы Access
или получены от пользователя. В любом из этих случаев, поскольку эти файлы
данных, как правило, находятся на хостовой операционной системе, приложение
обладает правом доступа к системе файлов операционной системы. Хакер может
воспользоваться преимуществом этого, проведя атаки с целью прочитать или удалить
информацию, содержащую восприимчивые файлы. Он может также выполнять
атаку DoS, заполняя файловое пространство вашей операционной системы.
В этом разделе мы рассмотрим наиболее распространенные и разрушаюшн
атаки и методы защиты от них. Любое из упомянутых решений, может предотвр
тить развитие других атак. Наша цель не быть настолько защищенным, насколь
это требуется, а на столько, насколько это возможно. Всегда существует вер°
ность того, что новый дефект или вновь обнаруженная атака приведет оД
из предостережений в состояние бесполезности, подтверждая внедрение излИ
них предосторожностей.

Доступ к данным • Глава 6 2
Первое, что нужно сделать - это заблокировать файловую систему вашего
.NET Application. По возможности, поместите все файлы вашей базы данных вне
web-корня. Если, вследствие ограничивающих условий стратегии или
архитектуры, вам приходится хранить файлы данных в вашем приложении, убедитесь, что
поместили в директории, не обладающей IIS правами чтения или написания. Для
блокирования IIS запустите окно администрирования Internet Information Service.
Найдите web-приложение и расширьте его структуру директории. Затем щелкните
правой кнопкой мыши на директорию, содержащую ваши файлы данных, и
выберите Properties. Рис. 6.28. демонстрирует пример с web-приложением под
названием webapp и директорией файла под названием data file directory.
Рис. 6.28. Блокирование доступа
4 Internet Information Services
Action _ Ф Щ Ш Й* Q Щ^
Tree | и&т
В " Crys^ReportWebfo*
ffi PortalCSVS
Ш CertSrv
Ш CertControl
$ " CertEnro»
Ш csp
Й" £3 aspnetjcter*
i < _vtiJan
Щ bin
^Ddataftedrectory
S3 uJ -YtLcnf
Ш £J _vtt_pvt
33 uJ _vti_scrjpt
Щ ^3 jvttjtxt
Ш ^J „private
В О _vti_cnf -*
Ш £j -vfajog
ШС2 vtf script
П*
**
Le-VtLbh
Ubh
"• i' i -
pLvttjcnf
UJ„vti_pvt
LJ_vti_scnpt
C3_vtijxt
J\ Assembtylnfo.cs
LjGtobal.asex
J9 Globd.«5«x.c$
j|} Global.asax.resx
Web.config
JO WebAppfcabon! .csproj
Г] WebAppfcationl .csproj.webinfo
WebForml.aspx
hgweoformi.aspx.es
_J WebForml.aspx resx
LU 1
Explore
Open
Br
►
Tas& ►
; fcetete
Rerwj»
Refresh
tNp
2J
properfc sheetf thecurrent
В появившемся OKHeProperties, убедитесь, что опции Read nWrite не отмечены,
^к показано на рис. 6.29.

Глава 6 * Доступ к данным
Рис. 6-29- Ограничение права доступа Read и Write.
data file directory Properties * X
D ectocy J Documents | Directory Security j HTTP He rs j Custom £mx$ \
When connecting to this fesource the content should come from:
• The designated directory
A rejection to a JJRL
Le&al Path. |W*ebappSdata fie directory
Г R Logvtsfcs
fiead R Index this resource
V£nfe>
Г* О ect&yfeuwsjno,
Application Settings
Starting pomt <Defaut Web $ite>\webapp
E xecute Permissions' Scripts only
Qsate*".
OK
J Cancel ) Apply | Help
Подсказка
Именно файловая система операционной системы, а не IIS, нуждается в праве
доступа к файлам данных. По умолчанию ASP.NET получит право доступа к вашей
файловой системе с аккаунтом ASPNET.
Затем вам необходимо предоставить право доступа ASPNET к этим файлам
данным через NTFS. При помощи Windows Explore перейдите на директорию,
на которой вы поместили ваши файлы данных. Щелкните правой кнопкой мыши
на директории и выберите Properties. Выберите Security наверху окна для
просмотра доступа к директории безопасности, как показано на рис. 6.30.

Доступ к данным • Глава 6
рис- 6.30. Установка NTFS разрешений.
d ta Ше directory f» о t t * X
General | Shamg Secure | Web Shams J Customize |
group or user names
С Administrator (THORNAdministrator)
Administrators iTHORSAdrtMnistralor*}
j*p account (THOftASPNET)
Backup Operators |TH0R48ackup Operators)
fiemove
D
П
d.
n
n -
El
Advanced
ггэелтпп rwmfr
«
P rnibsiomrbraspnetjap
account
Fui Control
Modify
Read & Execute
List Folder Contents
Read
Write
Add.
Акт
a
a
D
□
□
D
For special регяшют or for advanced settings
cSck Advanced
OK
Cancel
£mfy
Из этого окна можно заблокировать доступ к директории, предотвратив
доступ к Read@Execute, List Folder Context Write, и Read. Заблокируйте директорию
файла данных, ослабив разрешения на файлах, которые использует ваше
web-приложение. Теперь, если предумышленный пользователь получит доступ к
директории, он не может создавать файлы.
Ещё одно предостережение - это использовние специальных .dll для
ограничения права доступа к определенным расширениям файлов в IIS 5. Например, если
ВЬ1 используете файлы базы данных Access, вы можете тар все запросы для файлов
с расширением .mbd на страницу «404-File not found» вместо того, чтобы
возвращать запрошенный файл базы данных. Можно использовать 404 .dll, доступный на
www.xato.net/filed/404.zip, для выполнения этой задачи. В IIS6 необходимости
в этом нет, потому что эта версия не позволит запросы для расширения файлов,
только если они уже имеют MIME mapping для этого типа файла.
Можно точно определять и удалять mappings расширений файлов, нажав на
Кнопку Configuration в окне свойств web-приложения, как уже было показано на
РНс. 6.29. Это вызовет появление окна Application Configuration с Mappings tab,
Убранного по умолчанию, как показано на рис. 6.31.

00 Глава 6 • Доступ к данным
Рис. 6.31. Добавление и удаление Extension Mappings
Application ConfiQurati * n X
Mappings J Options] Debupgiig|
-Application Mappings
Ext
" a
asax
ascx
a$hx
asmx
asp
aspK
axd
cdx
eer
config
ЮП
Ajjd
£ Path V ibs
С \** INDGV/$''C f h'uJm в* гч'ча GET HE .
C:VW!NDOWS\Micio$oftNETSFfame.. GET,HEA
CAW!NDOWS\Micfosoft.NET\Ffame.. GET HEA.
C:VWlNDOWS\Micfo$oftNET\Frame.. GET HEA
C:\WIND0WS4Micfo$ortNET\Ffame„ GET HEA
C:\WIND0WS\System324inetsfvSa$p.„. GET HEA.
0\WiNDOWS\Micro$oft NEUFrame. GET,HEA.
C:\WINDOWS\Moasofi.NET\Fram*. GET HEA.
C:\WIND0WS\System32\k>et$fv\asp... GET,HEA
C:\WINDOWS\Sy$tem32\ir>et$fv\a$p.. GET,H£A
CAWINDOWS\Microsoft.NET\Ffame.. GET HEA
r\wiwnn\A/<;vM;rrn*r»ftwrT\FiAn«» пр мрд
gm
fiemove
OK
Cancel
Help
Из этого окна вы можете добавить mappings между расширениями файла,
которое вы хотите ограничить и 404 .dll, которые будет возвращать сообщение «404-
Page Not Found». Используя 404.dll, вы не только ограничиваете доступ к файлу,
но также и отрицаете даже само подтверждение существования файла. Взламыва-
тель не сможет заметить разницы между файлом, который не существует, и
файлом, к которому он не может получить доступ.
Некоторые приложения, прямо или косвенно, позволяют пользователю о
зывать влияние на имя файла, созданного или получившему доступ в операци
ной системе web-сервера. Это должно происходить через web-сайт, который соз
ет файл пользователя для загрузки, основанной на логине. Это представляет со
риск для безопасности, потому что пользователь может выбрать имя, не безо
ное для системы файлов. Например, что, если пользователь выберет в каче
имени c:\ntdetect.com? Существует вероятность того, что web-приложение
write важный файл операционной системы, пытаясь создать файл,
основаннь»'
ргйл. н°
этом логине. Или, возможно, ваше приложение не пытается написать фаИ '
вместо этого читает файл, основанный на логине или некоторых других ]

Доступ к данным • Глава 6
данных, контролируемых пользователем. Хакер сможет определить любой файл в
операционной системе web-приложения и получить его содержание через вашу
web-страницу.
В силу этих причин, никогда не основывайте доступ к файлам на именах,
на которые пользователь может оказывать влияние. Вместо этого подумайте
об использовании хэша логина или некоторых псевдослучайных
идентификаторах, которые взламыватель может легко вычислить или которыми он может
манипулировать.
Если ваше web-приложение создает файлы в операционной системе,
предпримите предосторожности для защиты от атак DoS. Оцените условия, заставляющие
web-приложение создавать файл и возможные действия пользователя в
злоупотребление этой системой. Например, многие банковские приложения позволяют
вам загружать банковские данные для внесения в финансовые программы, такие
как MS Money. В этом сценарии возникают следующие вопросы:
■ Что могло бы произойти, если бы пользователь запрашивал тысячу
загрузок ежеминутно?
■ Создает ли приложение новый файл в системе файлов для каждого запроса?
■ Существуют ли какие-нибудь ограничения частности запрашивания
пользователем загрузок?
■ Удаляет ли код предыдущие записи автоматически, когда пользователь
создаёт новую запись?
• Существуют ли какие-либо ограничения дискового пространства для
каждого пользователя?
И Что произойдет с вашим приложением или платформой, если на диске не
осталось свободного места для написания файлов?
Без механизма предотвращения пользователей от заполнения вашей файловой
истемы временными файлами, взламыватель может не только вывести ваше при-
экение из строя, но и дискредитировать всю операционную систему, заняв все
исковое пространство операционной системы. Но если вы предупреждены
этом, решение этой проблемы относительно легкое. Во-первых, всегда внедряй-
^втоматическое уведомление о том, что свободное пространство на диске
закаивается. Во-вторых, ограничьте файлы, которые могут создавать пользователи че-
*^ определенный период. Если пользователь пытается создать больше файлов,
^ разрешено, удалите предыдущий файл пользователя или отклоните запрос.

Глава 6 * Доступ к данным
Как мы уже рассматривали, приложение, которое использует файлы данных
в их хостовых операционных системах, должны принимать дополнительные меры
предосторожности. Начните с блокирования использования файлов, к которым
разрешен доступ, использующих разрешения IIS и NTFS одновременно.
Продолжите фильтрацию запросов восприимчивых типов файлов на странице «404-File
Not Found» и не позволяйте пользователям оказывать влияние на имена файлов
созданных на сервере. И, наконец, защитите ваше приложение и операционную
систему против DoS атак файлов, основанных на системе, ограничив количество
файлов, создаваемых пользователем.
Способы защиты
■ Заблокируйте вашу систему файлов IIS и NTFS установками.
■ Не позволяйте пользователям оказывать влияние на имена файлов,
созданных на сервере.
■ Ограничьте количество и/или размер файлов, которые пользователи
могут создавать на сервере.

Доступ к данным • Глава 6
Краткая справка по стандартам кодирования
Защита драйверов базы данных
Ограничение поверхности, подверженной атаке
• Удалите или заблокируйте неиспользуемые драйверы в вашей базе данных.
• Проводите периодические проверки на наличие новых неиспользованных
драйверов и удаляйте их, особенно после проведения обновлений или
заплаток.
Защита драйверов базы данных
• Установите драйверы вашей базы данных на максимальную безопасность.
• Установите драйверы вашей базы данных на разумную деятельность по
доступу к входу.
Защита баз данных
Защита размещения базы данных
• Просмотрите топологию вашей сети и требований безопасности для
разработки схемы размещения межсетевого экрана наилучшим образом
подходящей для вашей среды.
• Ориентируйтесь на худшее развитие событий при разработке схемы
размещения вашего межсетевого экрана.
Обеспечение наименьшей привилегии
• Всегда предоставляйте и используйте минимум требуемого доступа
и разрешений.
• Используйте межсетевой экран для ограничения несанкционированного
доступа.
• Используйте IPSec или SSL для ограничений количества пользователей,
которые могут соединяться с вашей базой данных
Защита базы данных
• Обновляйте программное обеспечение вашей базы данных.
• Блокируйте или удаляйте неиспользуемые свойства вашей базы данных.
• Усиливайте слабые пароли и разрешения, установленные но умолчанию.

Глава 6 * Доступ к данным
Написание безопасной программы доступа
к базе данных
Соединение с источником данных
• Используйте роли для применения правила наименее привилегированных
аккаунтов.
• Используйте Windows Аутентификацию, где это возможно.
• Сохраняйте строку соединения базы данных безопасной.
• Устанавливайте надежные пароли для sa и с1Ь_аккаунтов.
Не используйте эти аккаунты в ваших приложениях.
Защита от SQL-запросов
• Используйте несколько методов защиты от SQL-запросов вместо одного
• Скрывайте входные данные пользователя при вставке в базу данных
и выборке из базы данных.
• Используйте sql параметры для проверки типа и длины входных данных
пользователя.
• Обрабатывайте и решайте все ошибки на стороне сервера.
• Усиливайте правило наименьшей привилегии в коде и аккаунте базы данных
Написание защиты SQL
• Проводите выборку минимума требуемых данных из базы данных.
• Проверяйте полученный результат на наличие ожидаемых атрибутов.
• Используйте структуры кодирования, усиливающие безопасность.
Чтение и написание массивов данных
• Заблокируйте вашу систему файлов IIS и NTFS установками.
• Не позволяйте пользователям оказывать влияние на имена файлов, созда
ных на сервере.
• Ограничьте количество и/или размер файлов, которые пользователи
гут создавать на сервере.

Доступ к данным • Глава 6
Краткая справка по проверке кода
Защита драйверов базы данных
Ограничение поверхности, подверженной атаке
• Удалила ли команда разработчиков программного обеспечения или ИТ
команда все посторонние драйверы до запуска базы данных в
производственную среду?
• Поддерживается ли стратегия периодической проверки обновлений
и заплаток безопасности программного обеспечения?
Защита драйверов базы данных
• Настроены ли используемые вами драйвера базы данных на запуск
в самом безопасном доступном контексте, таком как режим Sandbox
для Jet драйверов?
• Установлен ли IIS для регистрации деятельности web-сервера?
• Регистрируют ли драйверы базы данных попытки входа в систему?
Защита баз данных
Защита структуры базы данных
• Используете ли вы межсетевые экраны для ограничения доступа к вашему
приложению?
• Взвесили ли вы все «за» и «против» того, где разместить источник данных
- в той же среде, что и web-сервер или отдельно от web-сервера за
межсетевым экраном?
Обеспечение наименьших привилегий
• Обладают ли пользователи, приложения или процессы минимумом
требуемых прав для завершения своих функций?
• Доступны ли межсетевые экраны, ограничивающие порты, для связи с
наименьшим требуемым набором?
• Используете ли вы IPSec или SSL для ограничения компьютеров, которые
могут связываться с вашей базой данных?

Глава 6 • Доступ к данным
Защита базы данных
• Усилили ли вы пароль sa аккаунта?
• Удалили ли вы расширенные сохраненные процедуры и сетевые
библиотеки, которые вы не используете?
• Удалили ли вы все образцы баз данных, образцы сохраненных процедур
и образцы кода из базы данных перед её использованием в
производственной среде?
Написание безопасной программы доступа
к базе данных
Соединение с источником данных
• Приняли ли вы решение, какой метод аутентификации использовать
в пользу Windows аутентификации, если она возможна?
• Защищены ли ваши строки соединения ACLEncode?
• Создали ли вы роли, группы и разрешения для эффективного ограничения
доступа пользователей к вашей базе данных?
Защита от SQL-запросов
• Понимают ли команды разработки программного обеспечения и
программирования механизмы SQL атак?
• Существуют ли в программе дублирующие механизмы для защиты от SQL-
атак, такие как скрытие и фильтрация входных данных, использование Sql
параметров и обработка ошибок на стороне сервера?
• Предусмотрены ли методы периодического исследования последних SQL-
атак для подтверждения того, что ваша программа все еще защищена от
новых атак?
Написание безопасного SQL-кода
• Восстанавливает ли программа минимум требуемых данных
из базы данных?
• В зависимости от требований безопасности модуля, были ли применены
дополнительные проверки безопасности, такие как ожидаемые параметра
размера и содержания результата?
• Имеется ли у инженера программного обеспечения написанный код,
разработанный на максимизацию безопасности?

Доступ к данным • Глава 6
Чтение и написание массивов данных
• Должна ли файловая система приложения проводить блокирование,
используя как NTFS, так и IIS разрешения?
• Если ваше приложение создает или читает файлы на сервере,
предотвращен ли пользователь от изменения имени созданного или прочитанного
файла?
• Если ваше приложение создает файлы, основанные на действии
пользователя, предусмотрены ли предостережения для предотвращения
пользователя от использования чрезмерного количества дискового пространства?
FAQ
Ответы авторов данной книги на следующие вопросы рассчитаны как на ваше
понимание концепций, представленных в этой главе, так и на помощь в претворении
данных концепций в реальную жизнь. Для того чтобы получить ответы на ваши
собственные вопросы по этой главе, зайдите на www.syngress.com/solutions и нажмите
на форму «Спросить Автора». Вы также получите доступ к тысячам других ЧЗВ
на lTFAQnet.com.
Вопросы (В) и ответы (О)
В: SQL запросы поражают все базы данных или только находящиеся на
SQL-сервере? Защищены ли одни базы данных больше других?
О: Все серверы баз т&ттт той или иной степени подвержены SQL-запросам.
Риск зависит от множества факторов, включающих в себя свойства сервера,
установки по умолчш&т? сложности, документации и т.д. SQL запросы - это
скорее проблема кода, чем б&ш данных. Если вы проводите тщательную
фильтрацию, упомянутые в дштой главе, потенциальные возможности и
уязвимости базы данных будут шгеть незначитела^и^ш последовательности.
Б- Существуют ли какие-ниб^да black box test, которые я могу использовать для
выяснения подверженности моего приложения SQL-запросам?
^- Выяснить подверженность SQL-запросам vm вне гор&здо сложнее, их
выявление, обычно, требует тщательного пересмотра щэда. Однако существует
несколько проверок на быстрое выявление подверженности SQL запросам.
Найдите несколько форм входных данных пользователя, таких как
web-форма, параметр строки запроса или файла cookie, или попытайтесь внести
недействительные символы, такие как одинарная кавычка или точка с запятой.

Глава 6 • Доступ к данным
Если вы видите ошибку действительной базы данных, то есть вероятность т
го, что она подвержена SQL-запросам. Ещё один способ - это ввести строю/
' или 1=1-в web-форму логина. Плохо написанный логин может принят
её и зарегистрировать вас как первого, в списке базы данных, пользователя
В: При выборе стратегии аутентификации SQL-Сервера, когда я должен
использовать Windows аутентификацию и когда Windows и SQL-Сервер
аутентификацию (смешанную)?
О: Как правило, использование Windows аутентификации дает намного больше
преимуществ, включая более надежную инфраструктуру аутентификации
и авторизации, возможность сохранять логины вне строки соединения
и преимущества администрирования, заключающиеся в отсутствие
необходимости установки новой модели безопасности (оригинальные механизмы
аутентификации и авторизации SQL-Сервера). Можно просто предоставить
SQL-Серверу право доступа к любым группам Windows, и присвоить
соответствующие разрешения. Самый распространенный аргумент в пользу
использования смешанной модели безопасности в том, обобщение соединения
поражено, когда пользователи используют свой собственный контекст
безопасности. Обобщение соединения (connection pulling) - это способность
выполнять повторный цикл (recycle) установленный соединений базы данных,
таким образом увеличивая скорость соединения для обновленных соединений.
Однако, в web-основанных приложениях, вероятнее всего, при выполнении
доступа к данным, все пользователи будут пользоваться одним общим
контекстом. Для перспективы обобщения соединения нет никакой разницы,
является ли аккаунт, выполняющий доступ к данным одиночным Windows акка-
унтом или оригинальным аккаунтом SQL-Сервера.

Глава 7
?■• «а«от •
п»ил§ ей
1 v.r /Ш\. w
'' ': , '' ' h
■ ^' " -:r^ Щ
•e о s jHbi.t
m **■ L— ■' < ^x 3
Решения в этой главе:
а Введение
3 Краткая справка по стандартам кодирования
ti Проверке кода
" >;??.>
309

Глава 7 * Разработка безопасных приложений ASP.NET
Введение
Хотя большинство ваших усилий по обеспечению безопасности сфокусировано
на механизмах работы приложения и коде, запущенном на сервере, нужно также
учитывать HTML-содержание, которое вы отправляете обозревателю Интернет клиента
В данной книге мы рассмотрели такие темы, как управление и опознавание
пользователей, использование шифрования, получение доступа к данным и фильтрация
входных данных пользователей. Но даже после соблюдения всех рекомендаций
неэффективный метод HTML-кодирования может предоставить хакеру восприимчивую
информацию и даже подвергнуть ваших пользователей риску. Хотя это может и не
представлять большой проблемы для некоторых web-сайтов, это серьезная проблема ддя
больших web-сайтов со значительным числом участников, таких как Yahoo! или eBay.
Пока у вас не будет контроля над обозревателем Интернет пользователя, и вы не
будете иметь достаточного влияния на принимаемые им решения, производимое
вами содержание может подвергнуть пользователя этим опасностям.
Понимание опасностей
В этой главе рассмотрены следующие типы опасностей:
■ Межсайтинговый скриптинг (XXS) Внедрение HTML или скриптинговых
команд, провоцирующих web-приложение атаковать других пользователей.
■ Подделка межсайтингового запроса (CSRF) Использование доверие web-
сайта у пользователя для выполнения транзакций от имени пользователя.
■ Утечка информации Преднамеренная отправка недействительных
входных данных для создания сообщения об ошибке, содержащие
информацию, которая может способствовать атаке.
■ «Социальная инженерия» Использование социальных навыков хакера
для извлечения информации у других или каким-либо образом
манипулировать служащими или другими доверенными людьми намеченной организади
■ Отрицание Способность пользователя отрицать выполненное
им действие или транзакцию.
Написание безопасного HTML-кода
Многие атаки пользуются преимуществом слабых присущих мест или дефеК
безопасности в стандарте HTML, или методов его обработки сервера

Разработка безопасных приложений ASP.NET • Глава 7
лли обозревателями Интернет. Следуя методам защиты HTML, можно ограничить
подверженность пользователя этим атакам. В данном разделе мы рассмотрим:
■ Построение защиты HTML
■ Предотвращение утечки информации
Построение защиты HTML
Исходное положение: Осторожное использование разметки HTML
может помочь предотвратить межсайтиноговый
скриптинг и другие виды атак.
Угроза: Межсайтинговый скриптинг.
Предотвращение CSS-атак
В Главе 5 мы рассмотрели метод фильтрации входных данных пользователей как
защиту от атак межсайтингового скриптинга. Но межсайниговый скриптинг не возникает, пока
вы не напишите выходные данные для обозревателя Интернет. Поскольку очень просто не
заметить все различные наборы символов и методов шифрования, поддерживаемые
ASP.NET или обозревателем Интернет клиента, вы не можете полностью полагаться
на фильтрацию входных данных для защиты от атак межсайнтингового скриптинга.
Одним из решений, уже рассмотренным нами в Главе 5, является кодирование
с помощью HTML всех данных, отправляемых на обозреватель Интернет. Кроме
этого, нужно также определить набор символов шифрования для вашей
web-страницы. Установка набора специфических символов ограничивает, какие символы
Действительны для вашего web-сайта и устраняет двусмысленность, которую
хакеры могут использовать, применяя другие наборы символов.
Вы можете обозначить набор символов для всего вашего приложения в файле
web.config:
<configuration>
<system.web>
<globalization
requestEncoding="ISO-8859-l"
responseEncoding="ISO-8859-l"/>
</system.web>
</configuration>
Также можно обозначить и постраничный набор символов:
^eta http-equiv="Content Type" content^"text/html; charset=ISO-8859-l" />

Глава 7 * Разработка безопасных приложений ASP.NET
В случае использования DHTML, существует ещё один метод защиты от атак
межсайтингового скриптинга - не использовать свойства InnerHTML для
установки и чтения значений между элементами HTML. Вместо этого, всегда используйте
свойство InnerText. Если вы используете InnerHTML, следите за тем, чтобы всегда
фильтровать входные и шифровать выходные данные пользователей. Также
используйте те же предостережения с методами insertAdjacementElement
и insertAdjacementHTML, а также с элементами TEXTAREA и объектами TextArea
Ещё один метод защиты от атак межсайтингового скриптинга - установить
ограничения безопасности на элементы frame или iframe. Это можно сделать с
помощью свойства Security следующим образом:
<IFRAME SECURITY ="restricted" SRC-"message.htm">
Установка этого свойства обладает следующими результатами:
■ Source file, обозначенный свойством SRC перенимает установки
безопасности Internet Explorer для зоны Restricted Sites.
■ Все гиперссылки отображаются в новом окне обозревателя Интернет,
вне зависимости от свойства TARGET в элементе гиперссылки.
■ Использование JavaScript, VBScript и протокола About ограничено.
■ Все вложенные фреймы перенимают те же ограничения.
Родственной атакой межсайтиногового скриптинга считается атака так
называемой Подделки межсайтиногового запроса (CSRF). Идея атаки подделки
межсайтиногового запроса состоит в том, чтобы спровоцировать пользователя отправлять
запрос от имени пользователя на другие web-сайты. Атака выполняется
провоцированием пользователя на посещение URL, например, обозначая внешний URL в тэге
IMG. Затем, когда обозреватель Интернет клиента запрашивает изображение из
внешнего URLa, он делает это в контексте пользователя, включая любые маркеры
сеанса, файлы cookies или сохраненные логины аутентификации этого пользователя.
Пример: предположим, взламыватель хочет заставить пользователя выполнить
некую транзакцию, например, перевод средств с одного аккаунта на другой. Каким-
то образом, взламывателю удается заставить пользователя просмотреть HTML
страницу, возможно через HTML форматированную электронную почту. В HTML
взламыватель включает тэг IMG, который содержит URL и все параметры,
необходимые для перевода средств. Гипотетически URL должен выглядеть примерно вот так.
https:// www.example.org/banking/transfer.aspx?from=123467&to-987655&amt=l00°

Разработка безопасных приложений ASP.NET • Глава 7 j
Предположим теперь, что этот web-сайт не придерживается лучших
методов защиты и позволяет пользователям автоматически входить в систему,
основываясь на сохраненных файлах cookie. Когда пользователь просматривает
e-mail, он попытается запросить изображение (image). Возврат из сервера,
очевидно, будет не одиночным изображением, поэтому он появится как
неправильная ссылка в документе HTML.
Этот пример, возможно, слишком упрощен, но он, несомненно, выполним
во многих web-сайтах. Рассмотрим несколько моментов, которые взламыватель
может выполнять с помощью этого типа атаки:
■ Инициализировать stock trade.
■ Подделывать почту, отправляемую на web-форум.
■ Осуществлять покупку, используя сохраненную информацию
по кредитной карточке.
■ Отправлять электронную почту с аккаунта почты, основанной на web.
■ Аутентифицироваться на безопасный web-сайт.
■ Получать доступ на ресурсы частных интранет web-сайтов.
■ Изменять пароль пользователя для интерактивных аккаунтов.
■ Собирать информацию о пользователе или среде пользователя.
Как можно видеть, это может представлять серьёзную опасность как для
пользователей, так и для операторов web-сайтов. Вы не можете предотвратить
эти атаки фильтрацией входных данных пользователей, и они не требуют
блокирования скриптинга со стороны клиента. Основной момент здесь в том, что
атаки CSRF компрометизируют вашу способность усиливать отрицание. Если ваша
web-страница подвержена CSRF-атаке, пользователь может возразить, что он не
выполнял транзакцию, даже если она брала свое начало от его компьютера,
используя его логин.
Тем не менее, можно сократить вашу подверженность CSRF-атаке. Ниже
приведено несколько подсказок, с помощью которых вы можете это сделать:
■ Запрашивайте Post на формах Это не исключит полностью опасность,
но затруднит выполнение атаки.

Глава 7 • Разработка безопасных приложений ASP.NET
■ Запрашивайте мульти-шаговые транзакции Не позволяйте пользователям
завершать восприимчивую транзакцию одним шагом. Например,
запрашивайте вторую страницу для подтверждения транзакции, а может быть даже
САРТСНА (см. Главу 2) для подтверждения того, что имеете дело с человеком.
■ Подтверждайте referrer headers Проверяйте HTTP referrer headers для
того, чтобы убедиться, что форма POST входит в вашу собственную
форму. Хотя referrer headers не всегда надежны, подделать их из-за CSRF атаки
будет намного сложнее.
■ Не позволяйте пользователям автоматически входить в ваше приложение
с логинами, сохраненными в файле cookie.
■ Следуйте руководствам в Главе 3 для безопасного управления сеансами
пользователей.
■ Не позволяйте пользователям отправлять IMG тэги, такие как форум или
гостевая книга, в ваше приложение. Также используйте предостережения,
позволяющие пользователям отправлять гиперссылки или URL.
Способы защиты
■ Всегда шифруйте любые выходные данные HTML, основанные
на действующих входных данных.
■ Устанавливайте набор специфических символов в файле web.conflg или
на постраничной основе.
■ Установите ограничения безопасности на элементах frame и ifarme
со свойством Security.
■ Используйте POST на формах, где это возможно.
■ Запрашивайте мульти-шаговое выполнение транзакции с подтверждением
пользователя.
■ Подтверждайте referrer headers на форме POST
■ Не позволяйте пользователям сохранять логины в файлах cookie.

Разработка безопасных приложений ASP.NET • Глава 7
■ Используйте предостережения при разрешении пользователям вводить
HTML, такие как IMG-тэги или гиперссылки.
■ Используйте инструменты проверки синтаксиса HTML для
подтверждения того, что имеете действительное и должным образом
структурированное содержание HTML.
Предотвращение утечки информации
Исходное положение: Содержание вашего web-сайта представляет
собой изобилие информации для взламывателя.
Угроза: Утечка информации, «социальная инженерия».
Одно из первых дел, которое сделает взламыватель, это поиск информации на
вашем web-сайте, полезной для проведения атаки. Этот шаг, как правило, не
представляет риска для взламывателя, потому что в большинстве случаев, это вызывает
такой же трафик, как и типичного web-пользователя. Собранная таким образом
информация, помогает взламывателю направлять атаку на определенные ресурсы,
раскрывать другие ресурсы, или собирать информацию для сосредоточивания атаки.
Ниже перечислены несколько подсказок для ограничения просачивания
информации взламывателю:
■ Избегайте жестко закодированных адресов электронной почты и, по
возможности, используйте вымышленные имена электронной почты.
Например, вместо отправки запроса распродажи на электронный адрес вашего
торгового менеджера, создайте общую вымышленную распродажу,
которая направляется на аккаунт его действительного электронного адреса.
■ Используйте предостережения при составлении перечня имен,
электронных писем или телефонов. Такая информация может использоваться
при атаке социальной инженерии.
■ Удаляйте мета теги из источника HTML, которые раскрывают схему
расположения страницы, управление содержанием, контролирование
источника или другого используемого вами программного обеспечения.
■ Избегайте HTML-комментариев, раскрывающих информацию о вашем
приложении, среде сервера, инфраструктуре сети или организационной
структуре.

Глава 7 * Разработка безопасных приложений ASP.NET
Способы защиты
■ Используйте вымышленные имена для ссылок электронной почты.
■ Избегайте подробностей, таких как адреса электронной почты
или телефоны extension.
■ Удаляйте метатэги HTML, раскрывающие нежелательную информацию.
■ Избегайте комментариев HTML в производственной системе.
Обработка исключений
До появления ASP.NET обработка ошибок никогда не была сильной стороной ASP.
Не смотря на большие усилия, предпринятые по обработке возможных условий
возникновения ошибки, нередко можно видеть выведенное их строя классическое
приложение с появившемся загадочным сообщением об ошибке. Для приложений, играющих
критическую роль в успехе компании, это может быть большой помехой, и, возможно
даже риском безопасности. В классических ASP вы могли видеть нечто вроде этого:
Microsoft VBScript runtime error '800a0006'
Overflow
/asp/test.asp, line 25
Чтобы построить безопасное приложение, нужно обрабатывать ошибки. .NET
Framework предлагает намного более улучшенные механизмы, позволяющие
проводить надлежащую и последовательную обработку ошибок вашего приложения.
.NET Framework обладает свойствами по:
■ Выявлению и обработке ошибок
■ Составлению отчетов об ошибках для клиентов
■ Регистрации деталей ошибок для администраторов и разработчиков
■ Производство событий для внешнего мониторинга
Не смотря на то, что каждый программист надеется написать безошибочную программу, это
не всегда может быть реалистичной целью. Ошибки в программах могут быть невероятно тшет-
ными, обычно разрушающими программу, в которой они возникают. Такие ошибки можно кл^с"
сифицировать по четырем категориям, которые мы и рассмотрим в последующих разделах:

Разработка безопасных приложений ASP.NET • Глава 7
■ Синтаксические ошибки Ошибки, вызванные написанием программы,
не соответствующей правилам языка. Например, орфографическая
ошибка в написании ключевого слова.
■ Ошибки компиляции Ошибки, выявленные на стадии компиляции.
Например, присваивание большого числа целой переменной,
что вызывает переполнение.
■ Runtime-ошибки Ошибки, возникающие после компиляции и
выполнения программы. Например, ошибка деления на ноль.
■ Логические ошибки Ошибки, возникшие вследствие неверного
внедрения алгоритмов. Это тип ошибки, который программисты боятся больше
всего, так как его очень сложно удалять.
Синтаксические ошибки - это самые распространенные ошибки в программировании.
Это особенно верно, если вы новичок в работе с определенным языком. К счастью,
проблема синтаксических ошибок может быть легко решена. В Visual Studio .NET, слова,
содержащие ошибки подчеркиваются, также как в Microsoft Word. Для того чтобы узнать причину
ошибки, просто установите курсор мышки на подчеркнутое слово, и появится окно
подсказки. Синтаксические ошибки, как правило, допускаются при написании программы и
обычно оказывают незначительное влияние на безопасность приложения в конечном итоге.
Ошибки компиляции возникают при попытке компилятора составить программу
и обнаружении, что программа содержит код, который потенциально может вызвать
сбой программы. Поскольку такие ошибки предотвращают завершение процесса
компиляции, вы перехватываете их до того, как ваша программа перейдет в производство.
Ошибки этапа выполнения возникают во время того, как программы запускается
и случается что-то непредвиденное. Это регулярно происходит с проектами, сданными
в очень короткие сроки. Программисты пытаются уложиться в сроки и часто
остаются довольными тем, что их приложение работает. У них нет времени на проверку
работы приложения в разных сценариях, в которых оно, возможно, будет использоваться;
следовательно, результатом является дефектная, потенциально уязвимая программа.
Чтобы гарантировать, что приложение надежно и безошибочно насколько это,
возможно, важно уделить особое внимание предупреждению всех возможных ошибок
вашего приложения. Runtime ошибки представляют собой риск для безопасности,
поскольку они могут раскрыть восприимчивую информацию и усилить такие атаки, как
отказ обслуживания и запросы SQL.
И, наконец, логические ошибки, состоящие из сегмента кода того, что не отвечает
°Жиданиям работы. Сбой может быть результатом отсутствия определенных свойств
Или обеспечения дополнительных свойств. Логические ошибки могут быть результатом
Расширения привилегий, перескакивания аккаунтов или других атак приложения.

Глава 7 * Разработка безопасных приложений ASP.NET
Использование структурной обработки ошибок
Исходное положение: Структурная обработка ошибок способствует
умению внимательно рассчитывать заранее
обработку ошибок.
Угроза: Утечка информации.
Обработка ошибок в инфраструктуре получила большую поддержку. В классической
ASP обработка ошибок была неструктурной, проводимой с помощью использования
ограниченного утверждения On Error. В VB.NET, обработка ошибок может быть как
структурной, так и не структурной. Так вы сможете перехватывать недочеты и реагировать на них.
Неструктурная обработка ошибок
Неструктурная обработка ошибок в VB.NET схожа с обработкой ошибок в ASP.
Рассмотрите следующий код:
Dim shortNum As Intl6
Dim intNum As Int32
intNum = 999999
shortNum = intNum ' narrowing will fail!
Работая с этим кодом, вы увидите сообщение об ошибке, показанное на рис. 7.1.
Рис. 7.1. Runtime ошибки
Е«се ■ юл of lype S t m.Ov rf). £кс ptionwat Hi own Micro fi Int m«rt txplot «
Server Error in VWebApplicationl' Application.
Exception of type System.OverfhwBxceptton was thrown.
De*cri|rtiMr Anu*Mral«dexM|)tonocci*rrt<luftogineaxiK^^ ГЦ ■■■ review Iheitacfctrwi.wr
Exception Detail*- Sy*w> OverflmCxowtion: Exc«pHon erf type SyMtffl.Ovwftwfctcartiop wm thrown
Line 17:
Line 38: intNum - 999999
I-»* '5. « xu v i t a rwnc 1 f*
Line 40-
Uoe AXi
Сообщение об ошибке, подобное этому, раскрывает информацию о вашем приложи
нии, но оно также и предупредит хакера о том, что вы не обрабатываете ошибки. Д^
предотвращения появления ошибок, VB.NET поддерживает неструктурное утверждение

Разработка безопасных приложений ASP.NET • Глава 7
Dim shortNum As Intl6
Dim intNum As Int32
On Error Resume Next
intNum = 999999
shortNum = intNum ' narrowing will fail!
If Err.Number <> 0 Then
Response.Write(Err.Description)
End If
Утверждение On Error resume Next игнорирует все возникающие ошибки,
и продолжает работать так, как будто ошибок не возникало вовсе. Информация
об ошибке содержится в объекте Err. В случае возникновения ошибки свойство
Number объекта Err будет содержать значение nonzero.
В предыдущем примере мы рассмотрели три ошибки. Первая ошибка вызовет
резкий переход на блокирование ErrorHandling, и после того, как будет отпечатано
описание ошибки, он продолжит выполнение с того момента, с которого было прервано.
Вторая ошибка будет проигнорирована, в то время как третья приведет к сбою программы.
Как можно видеть, неструктурная обработка ошибок делает вашу программу
беспорядочной и сложной к восстановлению, а также на будущую эксплуатацию.
Следовательно, мы рекомендуем использовать структурную обработку ошибок.
Структурная обработка ошибок
Вместо установки формулировки On Error в начале блока для обработки
потенциальных ошибок, .NET предлагает структурную обработку ошибок с
использованием конструкции Try-Catch-Finally для обработки ошибок. Конструкция Try-Catch-
Finally позволяет размотчикам эффективно перехватывать различные формы
ошибок и соответствующим образом реагировать на них. Она имеет следующий
синтаксис:
Try
' Executable statements that may cause
' an exception.
Catch [optional filters]
' Catches the error and responds to it
Catch [optional filters]
' Catches the error and responds to it
[Additional Catch blocks]
Finally
' Always executed, with or without error
End Try

Глава 7 * Разработка безопасных приложений ASP.NET
Применяя структурную обработку ошибок, мы получаем:
Dim shortNum As Intl6
Dim intNum As Int32
mtNum = 999999
Try
shortNum = intNum ' narrowing will fail!
Catch anyException As Exception
Response.Write(anyException)
End Try
После выполнения обработки, появившееся сообщение
об ошибке выглядит так:
System.OverflowException: Exception of type System.OverflowException was
thrown, at WebApplication1.WebForml.Page_Load(Object sender, EventArgs
e) in C:\Documents and Settings\lwm\VSWebCache\LWM\WebApplication1\
WebForml.aspx.vb:line 31
После выполнения строки в блоке Try, она образовывает исключение, которое
затем перехватывается блоком Catch. Утверждение в блоке Catch распечатывает
причину возникновения данного исключения. Предыдущий пример не отражает
должным образом конструкцию структурной обработки ошибок в VB NET:
Dim shortNum As Intl6
Dim intNum As Int32
intNum = 999999
Try
shortNum = intNum ' narrowing will fail!
Catch outofMemoryException As System.OutOfMemoryException
Response.Write("Out of memory!")
Catch OverflowException As System.OverflowException
Response.Write("Overflow!")
Catch anyException As Exception
Response.Write("Some exception!")
End Try
Здесь мы имеем дело с множественными утверждениями Catch. Каждое из них
улавливает разные типы исключений. В случае обнаружения, выражение полностью
оценивается. После нахождения соответствия, выполняется блок Catch. Если соответствий не
найдено, появляется сообщение об ошибке. В предыдущем списке перечислены исключения:

Разработка безопасных приложений ASP.NET • Глава 7 3
■ Исключение OutOfMemory (Недостаточно памяти) Возникает при
недостаточном объеме памяти для продолжения выполнения программ.
■ Исключение Overflow (Переполнение) Возникает при условии
переполнения результатов операции.
■ Исключение Основа класса для исключений. Это означает, что все,
не совпавшие исключения, образуют совпадение здесь.
При образовании исключения блоком Try, по порядку оцениваются несколько
утверждений Catch. Во-первых, оно сравнивается с блоком Catch, и проверяет, походит
ли оно к обозначенным в блоке Catch исключениям. Если соответствий не найдено,
оно сравнивается со следующим и т.д. Процесс прекращается только после
обнаружения соответствия. В нашем случае, исключение относится к Исключениям Overflow
и, следовательно, соответствует второму блоку Catch. Если совпадений не найдено,
возникает сообщение об ошибке. И, наконец, блок finally позволяет вам проводить все, что
должны делать очищающие операции кода, независимо от типа возникшей ошибки.
Catch anyException As Exception
'Response.Write(anyException)
Response.Write("Some exception!")
Finally
' code here always executes
' regardless of the exception
End Try
Существует несколько ключевых моментов, которые надо помнить, при
написании программ структурной обработки ошибок. Во-первых, при создании
обработчика ошибок, нужно быть уверенным, что в случае сбоя кода, он будет в
безопасности. Также учитывайте эффект использования фильтров и блоков Finally
с многоуровневой обработкой ошибок. Иногда эти блоки выполняются в
неожиданном порядке, поэтому нужно принимать меры предосторожности при выборе
Метода обеспечения защиты с этими блоками кода.
Способы защиты
■ Используйте структурную обработку ошибок во избежание использования
обработчика ошибок, установленного ASP.NET по умолчанию.
■ Всегда программируйте обработчик ошибок на безопасный сбой.

Глава 7 * Разработка безопасных приложений ASP.NET
■ Учитывайте порядок выполнения фильтрации исключений и блоков
Finally.
Составление отчетов и регистрация ошибок
Исходное положение: Предоставьте пользователям общие детали во
время сбора более существенной информации
для администраторов и разработчиков.
Угроза: Утечка информации.
Если ваше приложение сталкивается с исключением, оно должно каким-то
образом его обработать. Чаще всего, это проявляется как 500 взвращенных ошибок
клиенту, наряду со страницей ошибок, установленной по умолчанию, как показано
на рис. 7.1. Как правило, нужно избегать обработчика по умолчанию, потому что
он предоставляет мало полезной информации законному пользователю, и, кроме
того, дает обилие информации взламывателю.
Если пользователь делает что-нибудь не так, нужно объяснить ему, как исправить
ошибку. Например, если он оставляет требуемую ддя заполнения форму пустой, нужно
дать ему знать, что заполнение этого поля обязательно. Тем не менее, вам никогда
не следует раскрывать слишком много информации в вашем сообщении об ошибке. Если
пользователь не может сделать ничего ддя поправки ситуации, например, если
внутренняя база данных ослаблена, просто отправьте общее сообщение об ошибке на сервере.
Общие ошибки
Общие ошибки - это ключи для сохранения отчета об ошибках. Как правило, вы
захотите скрыть подробную информацию об ошибке от конечного пользователя.
Ниже приведено несколько примеров сообщений об ошибке, которых следует избегать:
■ «Файл обеспечения доступа ошибки
c:\inetpub\wwwroot\orders\orders.mbd»
■ «ОШИБКА СОЕДИНЕНИЯ С СЕРВЕРОМ \\ WEBSDB»
Вместо этого, отправляйте такие сообщения об ошибке:
■ «Ошибка открытия базы данных; пожалуйста, свяжитесь с
администратором или попробуйте позже».
■ «Источник сервера в данное время не доступен; пожалуйста, попробуйте
ещё раз позже».

Разработка безопасных приложений ASP.NET • Глава 7
В ASP.NET можно обеспечить общие страницы HTML для обработки
различных классов ошибок. Следующий пример демонстрирует установку исключений
в файле web.config:
<customErrors defaultredirect="/error/error.aspx" mode="on">
<error statuscode="404" redirect="/error/404Error.htm"/>
<error statuscode="500" redirect="/error/500error.aspx"/>
</customErrors>
Эта конфигурация предусматривает общую страницу под названием error.aspx,
но также обеспечивает страницы переадресации для ошибок 404 и 500. Все
необработанные ошибки будут вызывать переадресацию на одну из этих страниц.
римечание
Установки обработчика ошибок по умолчанию в файле web.config применяются
только для файлов преобразованных в ASP.NET. Если вы хотите применять их для других
файлов, таких как файлы НТМ или GIF, нужно либо настроить документ преобразова-
- ний IIS на то, чтобы позволить ASP.NET обрабатывать другие расширения файлов.
См. Главу 2 для получения инструкций по преобразованию не-ASP.NET источников.
ASP.NET позволяет вам задавать обработчика ошибок на уровне страницы или
приложения. Для того чтобы задать глобального обработчика ошибок на
странице, используйте событие Page.Error. Для глобального обработчика приложения
используйте событие Application.Error в Global.asax.
Регистрация ошибок
Хотя вы и не хотите, чтобы конечный пользователь видел подробную
информацию об ошибке, она, конечно же, будет нужна вам для исправления ошибок или для
того, чтобы предупредить вас об атаке. Можно воспользоваться несколькими способами
регистрации ошибок в приложении ASP.NET, примеры которых приведены ниже:
■ IIS файл регистрации Добавляет текст пользователя в файл регистрации
стандарта IIS, при помощи метода Response.AppendToLog.
■ Регистрация событий Windows добавляет события в Регистрацию
событий Windows, используя класс EventLog.
■ Регистрация файла пользователя Записывает в текстовый файл
пользователя, используя классы FileStream и StreamWriter.

Глава 7 * Разработка безопасных приложений ASP.NET
■ Централизованная база данных Регистрирует ошибки как записи
в централизованной базе данных.
■ События интерфейса WMI Повышает WMI события для перехвата
другими корпоративными механизмами регистрации.
■ Отправка электронной почты Отправляет электронную почту через
SMTP администратору, при возникновении исключений.
Выбранный вами метод регистрации ошибок во многом зависит от
потребностей и размеров вашего конкретного приложения. Ниже приведены несколько
вопросов, которые вам нужно задать себе для оценки механизма регистрации:
■ Произойдет ли сбой регистрации, если система или сеть подвергнется
атаке отказа в обслуживании?
■ Позволяет ли механизм подробную и всестороннюю регистрацию
без нагрузки на приложение или сеть?
■ Возможно, ли ограничить доступ к данным регистрации?
■ Существует ли возможность изменения регистрационных данных,
инициализация подложных регистрационных данных взламывателем?
■ Повлечет ли за собой компрометизация приложения или сервера
компрометизацию данных регистрации?
В некоторых случаях целесообразно предусмотреть механизмы мульти-регист-
рации. Это помогает обеспечить точность и неотрицаемость данных
регистрации. Вы, можете, например, использовать регистрационные данные IIS для того,
чтобы отслеживать ошибки, но сохранять дополнительную, подробную
информацию об ошибке в отдельном файле регистрации. Кроме того, можно использовать
сниффер или систему обнаружения вторжений для регистрации подозрительных
сетевых трафиков между клиентом и сервером.
При регистрации деталей исключения, нужно предусматривать, какая инф°Р
мация представляет для вас наибольшую ценность. Нужно, например, регистрир0
вать следующие детали:
■ Информацию, позволяющую определить в каком месте приложения
возникла ошибка.

Разработка безопасных приложений ASP.NET • Глава 7
■ Информацию, устанавливающую точное время дату и расположение
сервера.
■ Информацию, позволяющую вам воспроизводить ошибку или,
если возможно, воспроизводить атаку.
■ Информацию, позволяющую вам идентифицировать взламывателя и
коррелировать эту информацию с регистрационными данными других
приложений.
Информация, которую можно не регистрировать, включает в себя:
■ Информация, которая раскрывает слишком много информации о коде
вашего приложения или инфраструктуре сети.
■ Личная информация, такая как пароли пользователей или номера
кредитных карт.
■ Прочая информация, которую взламыватель может использовать против вас.
Способы защиты
■ Всегда предоставляйте пользователям общую информацию, не
раскрывающую слишком много информации.
■ Установите, обработчик общих ошибок в файл web.config или создайте
разработчик глобальных ошибок на уровне приложения или страницы.
■ Не регистрируйте пароли пользователей, номера кредитных карт
или другую уязвимую информацию в файлах регистрации.
■ Выключите отладку, прослеживание и детализированные сообщения
об ошибке в производственном приложении.

Глава 7 * Разработка безопасных приложений ASP.NET
Краткая справка по стандартам кодирования
Написание безопасного HTML-кода
Обеспечение защиты HTML
• Всегда зашифровывайте все динамические выходные данные, основанные
на динамических входных данных.
• Установите набор специальных символов в файле web.config или на
постраничной основе?
• Используйте меры предосторожности, используя свойство DHTML
innerHTNL, метод insertAdjacentElement, метод insertAdjacementHTML
элемента TEXTAREA и объект TextArea. По возможности, используйте
innerText вместо innerHTML.
• Используйте ограничения защиты на элементах frame и iframe при
помощи атрибута защиты.
• По возможности, используйте процедуру самотестирования при загрузке
на формах.
• Запросите мульти-шаговые транзакции подтверждения пользователя.
• Проверьте заголовки отправителя на форму процедуры самотестирования
при загрузке.
• Не позволяйте пользователям сохранять логины в файлах cookie.
• Используйте меры предосторожности, позволяя пользователям вводить
HTML, такой как IMG теги или гиперссылки.
Защита от утечки информации
• Используйте псевдонимы для ссылок электронной почты.
• Избегайте распечатки детальной информации о службах, такой как адреса
электронной почты или номера телефонов.
• Удаляйте мета теги HTML, раскрывающие нежелательную информацию.
• Избегайте комментариев HTML в производственной системе.
Обработка исключений
Использование структурной обработки ошибок
• Используйте структурную обработку ошибок во избежание обработчика
ошибок, установленного ASP.NET по умолчанию.

Разработка безопасных приложений ASP.NET • Глава 7
• Всегда программируйте обработчик ошибок на безопасный сбой.
• Внимательно следите за порядком выполнения фильтров исключения
и блоков окончания.
Составление отчетов и регистрация ошибок
• Всегда предоставляйте пользователям общие сообщения, не
раскрывающие слишком много информации.
• Установите, обработчик общих ошибок в файл web.config или создайте
разработчик глобальных ошибок на уровне приложения или страницы.
• Не регистрируйте пароли пользователей, номера кредитных карт или
другую уязвимую информацию в файлах регистрации.
• Выключите отладку, прослеживание и детализированные сообщения об
ошибке в производственном приложении.
Краткая справка по проверке кода
Написание безопасного HTML-кода
Обеспечение защиты HTML
• Отправляет ли приложение динамические выходные данные без их
предварительного шифрования?
• Поддерживает ли приложение установку набора специальных символов в
файле web.config или постраничной основе?
• Фильтрует ли приложение входные и шифрует ли выходные данные с
помощью свойства innerHTML, метода insertAdjacentElement, метода
insertAdjacement HTML элемента TEXTAREA и объекта TextArea?
• Могут ли программисты использовать innerText вместо innerHTML?
• Обладают ли элементы frame и iframe атрибутом безопасности?
• Используют ли формы GET, когда POST был бы более подходящим?
• Требуют ли уязвимые транзакции множественных шагов выполнения,
включая подтверждение пользователя?
• Проверяют ли формы заголовки ссылающегося для подтверждения
источника входных данных?
• Могут ли пользователи вводить IMG или теги гиперссылки для
выполнения CSRF атак?

Глава 7 * Разработка безопасных приложений ASP.NET
Защита от утечки информации
• Включает ли в себя содержание HTML имена служащих, адреса
электронной почты, номера телефонов, которые могут быть использованы при
выполнении атак «социальной инженерии»?
• Раскрывают ли мегатэги HTML излишнюю информацию?
• Включает ли в себя содержание HTML излишние комментарии?
Обработка исключений
Использование структурной обработки ошибок
• Использует ли приложение структурную обработку ошибок во
избежание использования обработчика ошибок, установленного ASP.NET
по умолчанию?
• Всегда ли сбой обработчиков ошибок происходит безопасно?
Составление отчетов и регистрация ошибок
• Раскрывают ли ошибки слишком много информации?
• Использует ли приложение общий обработчик ошибок, вместо
встроенных обработчиков ошибок?
• Содержат ли файлы регистрации пароли пользователей, номера
кредитных карт или другую уязвимую информацию?

Разработка безопасных приложений ASP.NET • Глава 7
FAQ
Ответы авторов данной книги на следующие вопросы рассчитаны как на ваше
понимание концепций, представленных в этой главе, так и на помощь в претворении
данных концепций в реальную жизнь. Для того чтобы получить ответы на ваши
собственные вопросы по этой главе, зайдите на www.svngress.com/solutions и нажмите
на форму «Спросить Автора». Вы также получите доступ к тысячам других ЧЗВ
на iTFAOnet.com.
Вопросы (В) и ответы (О)
В'. Можно ли что-нибудь сделать на сервере для защиты от атак межфреймового
и межоконного скриптинга?
О: Атаки межфреймового и межоконного скриптинга, в основном, касаются
клиента, а точнее, клиента, заходящего на сервер с предумышленным
содержанием. Однако можно ограничить способность взламывателей
использовать ваш web-сайт для таких атак. Самое важное - отправить любые межсай-
тинговые выдачи в ваше приложение. Нужно также учитывать некоторые
свойства DHTML и их влияние на безопасность, указанную на этом
URL: http://msdnymf^ dhtml.asp.
В: Всегда ли можно прюхентъ GET вместо POST?
О: Запросы GET, как ггравило, соответствует запросам поиска, например ID или
поисковый мехаштмапроса* Запросы POST предпочтительны, если они
содержат предъявленную на рассмотрение иыфоршадию пользователя,
уязвимую информацию, или информацию* что-жбо изменяющую на сервере.
В- Должен ли я использовать шифратор HTML или obfuscator для защиты
от утечки информации?
О- Хотя эти типы инструментов и оказывают пользу как правило, они не
являются достаточной заменой для надежных методов кодирования HTML.
Шифрование и умышленное запутывание полагаются на клиента и не являются
ошибкоустойчивыми.

Глава 8
Решения в этой главе:
Ш Применение Securing XML
В Применение цифровых подписей XML
• Краткая справка по стандартам
кодирования
• Краткая справка по проверке кода
• FAQ
331

Глава 8 • Безопасность в XML
Введение
XML - это мощная технология структуризации данных в независимом от
платформы, доступном для чтения формате. Документы в XML легко создавать и
просто анализировать. Существует очень много приложений, использующих XML
как в сетевом, так и во внесетевом пространстве. Рамки данной главы не
предусматривают рассмотрение всех преимуществ XML, но при желании, на эту тему
можно найти перечень из более чем 2,500 книг на Amazon.com.
Несмотря на все преимущества, до недавнего времени XML не обладал
надежной защитой. Например, раньше XML не предусматривал спецификацию для
защиты секретности или сохранности данных. Данные, содержащиеся в XML, были
подвержены просмотру и изменениям внешними сторонами без обнаружения.
Чтобы решить эти проблемы безопасности, разработчики были вынуждены
использовать внешние, disparate технологии для защиты данных, содержащих XML.
Консорциум всемирной сети (W3C) направил эти вопросы, используя
средства инструментов шифрования и цифровых Логинов. XML теперь включает в себя
внутренние и стандартизированные спецификации для описания зашифрованных
и подписанных данных. Для защиты конфиденциальности и целостности ваших
данных, содержащихся в XML, вы можете использовать шифрование.
Используйте общий и частный ключи цифровых Логинов для подписи XML-данных.
Подписание XML данных защищает целостность, подлинность, а иногда и
невозможность отказа данных. Спецификации XML-шифрования и цифровой подписи
понятны и детализированы по вопросам раскрытия алгоритмов, форматов, методов,
используемых для расшифровывания действительных подписей. Используя эти
спецификации, вы можете быть уверены, что ваши данные будут, не только
защищены, но и полезны для других приложений, использующих ту же спецификацию.
Применение Securing XML
Целью XML шифрования является описание зашифрованных в цифровом
формате web-источников, при помощи XML XML-спецификации создают
документ, совмещающий преимущества как XML, так и шифрования для производства
стандартизированного, читаемого человеком документа, код которого может Де
лать грамматический разбор не зависимо от платформы, и в тоже время, содержа
щий секреты шифрования с симметричным или ассиметричным алгоритмам .
по вашему выбору.
Web-источники, используемые в XML-шифровании может быть ниче
из HTML документа на GIF файле или даже полного XML-документа. XMLEnco
С СУ"
обеспечивает шифрование элемента, включающий теги запуска и завершения,
держание между тегами запуска и завершения, и весь документ XML, Специф***а'

Безопасность в XML • Глава 8 33
ция описывает, что зашифрованные данные расположены в элементе
Зашифрованные Данные. Этот элемент также содержит подробную информацию,
имеющую отношение к шифрованию и /или расшифровыванию. Эта подробная
информация включает в себя алгоритм шифрования, ключ, используемый для
шифрования, ссылки на внешние объекты данных, и зашифрованные данные, или
ссылки на зашифрованные данные.
Шифрование данных в XML
Исходное положение: Securing XML целесообразно для шифрования
специальных элементов документа, для
передачи его по незащищенным сетям, а также в целях
архивации.
Угроза: Утечка информации, нарушение целостности
данных, атаки человек-в-середине.
SSL протокол шифрования Интернет должен быть достаточно эффективен
для защиты данных, передаваемых по Интернету. Однако Securing XML
обеспечивает решение, немного отличающееся от создания потока зашифрованных
данных. XML позволяет вам шифровать единичные, специальные элементы
XML-документа, вместо того, чтобы зашифровывать весь документ, как в случае с SSL.
Например, если вы пересылаете по Интернету медицинскую информацию,
информация о пациенте, неидентифицирующую его, а именно: рост, вес, результат
анализа крови, может быть и не зашифрованной, но вам придется зашифровывать
информацию, подтверждающую идентичность пользователя, а также более
чувствительную информацию, такую как имя и номер социальной страховки.
Преимущество шифрования только в том, что нужно шифровать небольшое количество
данных, а не весь документ.
Ещё одно преимущество спецификации XML-шифрования касается
сохранения данных. SSL обеспечивает зашифрованный канал или передаваемые данные
через Интернет. XML, наоборот, представляет собой спецификацию образования
Данных, которые можно использовать для архивации и хранения данных.
Например, ранее упомянутые медицинские записи могут быть заархивированы, не
раскрывая идентифицирующую пользователя информацию.
Спецификация XML-шифрования
Спецификация XML-шифрования находится в стадии разработки и готова
К адаптации. Для дальнейшей информации, можно просмотреть официальные
спецификации Синтаксиса и Обработки XML-шифрования W3C, на ww\v.w3.orh/TR/xmleiic4:ore.
Рис.8.1. показывает спецификацию синтаксиса Securing XML.

Глава 8 • Безопасность в XML
Рис. 8.1. Спецификация синтаксиса шифрования XML
<EncryptedData Id? Type? MimeType? Encoding?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
Полную схему шифрования XML можно найти на www.w3.org/TR/xmlenc-
core/xenc-schema.xsd, а также на рис. 8.2. Элементы, выделенные жирным
шрифтом объяснены, следуя схеме.
Рис. 8.2. Схема шифрования XML
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
"http://www.w3.org/2001/XMLSchema.dtd"
[
<!ATTLIST schema
xmlns:xenc CDATA #FIXED •http://www.w3.Org/2001/04/xmlenc#'
xmlns:ds CDATA #FIXED ■http://www.w3.org/2000/09/xmldsig#'>
<!ENTITY xenc 'http://www.w3.org/2001/04/xmlenc#'>
<!ENTITY % p ' '>
<!ENTITY % s ' '>
]>
<schema xmlns='http://www.w3.org/2001/XMLSchema» version='1.0'
xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
targetNamespace='http://www.w3.org/2001/04/xmlenc#'
elementFormDefault='qualified'>

Безопасность в XML • Глава 8
<import namespace='http://www.w3.org/2000/09/xmldsig#'
schemaLocation='http://www.w3.org/TR/2002/REC-xmldsig-core-
20020212/xmldsig-core-schema.xsd*/>
<complexType name=lEncryptedType' abstract=ltrue'>
<sequence>
<element name=lEncryptionMethod'
type='xenc:EncryptionMethodType'
minOccurs='0'/>
<element ref='ds:KeyInfo' minOccurs=l0'/>
<element ref=,xenc:CipherData'/>
<element ref='xenc:EncryptionProperties' minOccurs=l0'/>
</sequence>
<attribute name='Id' type='ID' use='optional'/>
<attribute name=,Type' type=*anyURI* use=* optional'/>
<attribute name=*MimeType' type=*string' use='optional'/>
<attribute name=lEncoding1 type=lanyURI' use='optional'/>
</complexType>
<complexType name=lEncryptionMethodType' mixed='true'>
<sequence>
<element name='KeySize' minOccurs=l0' type='xenc:KeySizeType'/>
<element name='OAEPparams' minOccurs='0' type='base64Binary'/>
<any namespace=l##other' minOccurs='0' maxOccurs='unbounded'/>
</sequence>
<attribute name='Algorithm' type='anyURI' use='required1/>
</complexType>
<simpleType name='KeySizeType'>
<restriction base="integer"/>
</simpleType>
<element name=*CipherData' type='xenc:CipherDataType'/>
<complexType name='CipherDataType'>
<choice>
<element name='CipherValue' type='base64Binary'/>
<element ref='xenc:CipherReference'/>
</choice>
</complexType>

Глава 8 * Безопасность в XML
<element name='CipherReference' type='xenc:CipherReferenceType'/>
<complexType name='CipherReferenceType'>
<choice>
<element name='Transforms1 type=,xenc:TransformsTypel
minOccurs=,0'/>
</choice>
<attribute name=,URIl type='anyURI' use='required1/>
</complexType>
<complexType name='TransformsType■>
<sequence>
<element ref='ds:Transform' maxOccurs='unbounded1/>
</sequence>
</complexType>
<element name=,EncryptedDatal type=,xenc:EncryptedDataType'/>
<complexType name='EncryptedDataType■>
<complexContent>
<extension base='xenc:EncryptedType'>
</extension>
</complexContent>
</complexType>
<!— Children of dsiKeylnfo —>
<element name=,EncryptedKeyl type=,xenc:EncryptedKeyTypel/>
<complexType name=•EncryptedKeyType•>
<complexContent>
<extension base="xenc:EncryptedType■>
<sequence>
<element ref=,xenc:ReferenceList' minOccurs=l0'/>
<element name=,CarriedKeyName' type=lstring1
minOccurs='0'/>
</sequence>
<attribute name='Recipient' type=lstring1
use='optional'/>
</extension>
</complexContent>
</complexType>
<element name="AgreementMethod" type="xenc:AgreementMethodType"/:>

Безопасность в XML • Глава 8
<complexType name="AgreementMethodType" mixed="true">
<sequence>
<element name="KA-Nonce" minOccurs="0" type="base64Binary"/>
<!— <element ref="ds:DigestMethod" minOccurs="0"/> —>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
<element name="OriginatorKeyInfo" minOccurs="0"
type="ds:KeyInfoType"/>
</sequence>
<attribute name = "Algorithm" type = "anyURI" use = "required"/>
</complexType>
<!-End Children of ds:KeyInfo— >
<element name = 'ReferenceList' >
<complexType>
<choice minOccurs = '1' maxOccurs = 'unbounded'>
<element name = 'DataReference' type = 'xenc:Referencetype'/>
<element name = 'KeyEwference' type='xenc:Referencetype1/>
</choice>
</complextype>
</element>
<complexType name = 'ReferenceType'>
<sequence>
<any namespase = ' ##other' minOccurs = '0' maxOccurs = •unbounded1/>
</sequence>
<attribute name= ' URI' type ='anyURI' use ='required'/>
</complexType>
<element name = 'EncryptionPropreties'
type='xenc:EncryptionPropertiesType'/>
<complexType name='EncryptionPropreties Type'>
<sequence>
<element ref=lxencrEncryptionProperty1 maxOccurs= 'unbounded'/>
</sequence>
<attribute name= 'Id1 type=,IDl use='optional'/>
</complexType>
<element name='EncryptionProperty'
type='xenc:EncryptionPropertyType'/>
<complexType name='EncryptionPropertyType' mixed='true'>

Глава 8 • Безопасность в XML
<choice maxOccurs='unbounded'>
<any namespace='##other' processContents='lax1/>
</choice>
<attribute name='Target' type='anyURI' use='optional'/>
<attribute name=,Id' type='ID' use=loptional'/>
<anyAttnbute namespace="http://www.w3.org/XML/1998/namespace"/>
</complexType>
</schema>
Схема шифрования XML довольно сложна в описании средств шифрования.
Наиболее примечательные элементы в этой спецификации:
■ Зашифрованные данные Основной момент спецификации. Этот элемент
заменяет зашифрованные данные, если данные были зашифрованы в
документе XML или сам документ XML. В последнем примере, элемент
EncryptedData на самом деле становится корневым элементом документа.
■ Зашифрованный ключ Необязательный элемент, содержащий
информацию о ключе, с помощью которого проводился процесс шифрования.
■ Метод шифрования Необязательный элемент, описывающий алгоритм,
применяемый в процессе шифрования.
■ Шифр данных Обязательный элемент, обеспечивающий зашифрованные
данные.
Подсказка
Заметьте, что элементы EncryptedKey и Encryption Method необязательны.
Они должны быть представлены, если получатель владеет этой информацией.
Процесс шифрования XML
Процесс зашифровывания и расшифровывания - прямой. Информационный
объект зашифровывается при помощи симметричного или асимметричного
алгоритма и соответствующего ключа. Каждая разработка спецификации должна ра3"
работать общий набор алгоритмов для возможности взаимодействия. Если инф°Р"

Безопасность в XML • Глава 8 3
мационный объект это элемент в документе XML, удалите этот элемент вместе
с содержанием и замените на соответствующий элемент Зашифрованные данные.
Если информационный объект для шифрования - внешний источник, создайте
новый документ с корневым узлом Зашифрованные данные, который будет
содержать ссылку на внешний источник.
Расшифровывание выполняет эти шаги в обратном порядке: проведите
синтаксический анализ XML для получения алгоритма, параметров и используемого
ключа; разместите данные для расшифровывания; и выполните операцию
расшифровывания. Результатом будет расшифрованная строка UTF-8, представляющая
фрагмент XML, который должен полностью заменить элемент Зашифрованные
данные. Ели информационный объект внешний источник, незашифрованная
строка доступна для использования приложением.
Существует несколько нюансов шифрования документов XML.
Зашифрованные экземпляры XML - это хорошо сформированные документы XML, но они не
могут считаться действительными при проверке достоверности с их
оригинальной схемой. Если схема проверки достоверности требовалась зашифрованным
документом XML, создайте новую схему для этих зашифрованных элементов.
дсказка
Если получатель документа или объект, которому получатель передает документ
XML, не должен узнать уязвимую информацию, полностью удалите её. Можно
удалить уязвимую информацию при помощи простой XSL трансформации. В
конечном итоге, удаление данных более безопасно, чем их зашифровывание.
Пример шифрования XML
Предположим, например, что мы работаем в медицинской лаборатории и
ответственны за возврат результатов анализов в больницу. Лаборатория хранит
результаты в документе XML, которую могут интерпретировать и оказывать влияние
различные компьютеры больницы, устройства для обработки анализов и системы
Данных. Однако определять конкретного человека, результаты которого
применяет лаборатория, могут только несколько достоверных систем. Следовательно, мы
зашифровываем элемент документа Личная Информация пациента ключом,
доступ к которому имеют только достоверные системы. Рис. 8.3. приводит пример
записи XML, которую лаборатория должна передать больнице.

Глава 8 • Безопасность в XML
Рис. 8.3. Шифрование документа
<?xml version="1.0"?>
<medicalRecord>
<patientPersonalInformation>
<name>Bryan Pitcher</name>
<SSN>555-55-5555</SSN>
</patientPersonalInformation>
<bloodTestResults>
<bloodType>A+</bloodType>
<redBloodCellCount>4200000/cmm</redBloodCellCount>
<whiteBloodCellCount>4500/mcl</whiteBloodCellCount>
</bloodTestResults>
</medicalRecord>
Рис. 8.4. и 8.5. приводят пример программы, которая может читать документ,
показанный в примере 8.3. и создавать XML-зашифрованный документ.
Программа будет шифровать элемент Личная Информация Пациента. Для удобства,
программа вырабатывает ключ и ВИ. Обычно программа должна читать эти значения
из безопасного местоположения. Предположим, что наш проверенный
получатель обладает этим ключом и ВИ, а также знает и метод шифрования.
Рис. 8.4. Шифрование документа XML: С#
public void encryptDocument(string xmlDocumentPlainTextFilename,
string xmlDocumentCipherTextFilename)
{
// Generate the keys
TripleDESCryptoServiceProvider tripleDES =
new TripleDESCryptoServiceProvider();
tripleDES.GenerateIV();
tripleDES.GenerateKey();
// Get the XML document from file
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.Load(xmlDocumentPlainTextFilename);
// specify the element to encrypt
XmlElement patientPersonallnformation =
(XmlElement)xmlDoc.SelectSingleNode(

Безопасность в XML • Глава 8
"medicalRecord/patientPersonallnformation");
byte[] patientPersonalInformationBytes =
Encoding.UTF8.GetBytes(patientPersonalInformation.OuterXml);
// Set up the CryptoStream for encryption with the key and IV
MemoryStream memoryStream = new MemoryStream();
CryptoStream CryptoStream = new CryptoStream(memoryStream,
tripleDES.CreateEncryptor(tripleDES.Key, tripleDES.IV),
CryptoStreamMode.Write);
// Write ciphertext to memory stream
CryptoStream.Write(patientPersonallnformationBytes, 0,
patientPersonalInformationBytes.Length);
CryptoStream.Close();
// Convert ciphertext to a Base64 string
byte[] patientPersonalInformationEncryptedBytes =
memoryStream.ToArray();
string patientPersonallnformationCipherText =
Convert.ToBase64String(patientPersonalInformationEncryptedBytes);
memoryStream.Close();
// Create and populate the necessary XML encryption elements
XmlElement xmlEncryptedData =
xmlDoc.CreateElement("EncryptedData");
XmlAttribute xmlType =
xmlDoc.CreateAttribute("Type");
xmlType.Value =
"http://www.w3.Org/2001/04/xmlenc#Element";
xmlEncryptedData.Attributes.Append(xmlType);
XmlElement xmlCipherData =
xmlDoc.CreateElement("CipherData");
xmlEncryptedData.AppendChild(xmlCipherData);
XmlElement xmlCipherValue =
xmlDoc.CreateElement("CipherValue");
xmlCipherValue.InnerText = patientPersonalInformationCipherText;
xmlCipherData.AppendChild(xmlCipherValue);
patientPersonalInformation.ParentNode.ReplaceChild(
xmlEncryptedData, patientPersonallnformation);

Глава 8 • Безопасность в XML
// Write XML encrypted document to file
xmlDoc.Save(xmlDocumentCipherTextFilename);
Рис. 8.5. Шифрование документа XML: VB.NET
Public Function encryptDocument _(ByVal xmlDocumentPlainTextFilename,
ByVal xmlDocumentCipherTextFilename)
' Generate the keys
tripleDES = New TripleDESCryptoServiceProvider
tripleDES.GeneratelV()
tripleDES.GenerateKey()
1 Get the XML document from file
Dim xmlDoc = New XmlDocument
xmlDoc.Load(xmlDocumentPlainTextFilename)
' specify the element to encrypt
Dim patientPersonallnformation = _
xmlDoc.SelectSingleNode( _
"medicalRecord/patientPersonalInformation")
Dim patientPersonalInformationBytes As Byte()
patientPersonallnformationBytes = _
Encoding.UTF8.GetBytes(patientPersonallnformation.OuterXml)
1 Set up the CryptoStream for encryption with the key and IV
Dim memoryStream As MemoryStream = New MemoryStream
Dim CryptoStream = New CryptoStream(memoryStream, _
tripleDES.CreateEncryptor(tripleDES.Key, tripleDES.IV), _
CryptoStreamMode.Write)
1 Write ciphertext to memory stream
CryptoStream.Write( _
patientPersonallnformationBytes, 0, _
patientPersonalInformationBytes.Length)
CryptoStream.Close()

Безопасность в XML • Глава 8
' Convert ciphertext to a Base64 string
Dim patientPersonallnformationEncryptedBytes As Byte()
patientPersonallnformationEncryptedBytes = _
memoryStream.ToArray()
Dim patientPersonallnformationCipherText = _
Convert.ToBase64String( _
patientPersonallnformationEncryptedBytes)
memoryStream.Close()
' Create and populate the necessary XML encryption elements
Dim xmlEncryptedData = xmlDoc.CreateElement("EncryptedData")
Dim xmlType = xmlDoc.CreateAttribute("Type")
xmlType.Value = "http://www.w3.Org/2001/04/xmlenc#Element"
xmlEncryptedData.Attributes.Append(xmlType)
Dim xmlCipherData = xmlDoc.CreateElement("CipherData")
xmlEncryptedData.AppendChild(xmlCipherData)
Dim xmlCipherValue = xmlDoc.CreateElement("CipherValue")
xmlCipherValue.InnerText = _
patientPersonallnformationCipherText
xmlCipherData.AppendChild(xmlCipherValue)
patientPersonallnformation.ParentNode.ReplaceChild( _
xmlEncryptedData, patientPersonalInformation)
' Write XML encrypted document to file
xmlDoc.Save(xmlDocumentCipherTextFilename)
End Function
Рис. 8.6. изображает XML документ после того, как элемент Личная
Информация Пациента был зашифрован.
Рис. 8.6. Документ ХМL после шифрования
<?xml version="1.0"?>
<medicalRecord>
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element">
<CipherData>

Глава 8 * Безопасность в XML
<CipherValue>fcEijNQTn3TLRBEtXwAGH003v4Jt0eZ0Uukuf9IE0ruxN6NHQKWufrVw03xKT
Zau8z7FMyEmxdZKbqLg2Fl/Ct8KphQvфDyTodtMmE^-uJrvtNniЗZFxu+41enVPBXUgrq8x0Bgo
0px7RyOsFVdpogYh+CVioHtQq</CipherValue>
</CipherData>
</EncryptedData>
<bloodTestResults>
<bloodType>A+</bloodType>
<redBloodCellCount>4200000/cmm</redBloodCellCount>
<whiteBloodCellCount>4500/mcl</whiteBloodCellCount>
</bloodTestResults>
</medicalRecord>
Нага образец кода заменил элемент документа Личная Информация Пациента
на элемент Зашифрованные Данные. Эта копия Зашифрованных Данных не
содержит описательной информации, имеющей отношение к ключу шифрования
или алгоритму, как было замечено ранее.
Рис. 8.7. и 8.8. приводят пример кода расшифрования XML-зашифрованного
документа. Для простоты, этот код расшифровывает элемент и пишет его в файл.
Рис. 8.7. Расшифрование ХМ1_документа:С#
public void decryptDocument(string xmlDocumentCipherTextFilename,
string xmlDocumentPlainTextFilename)
{
// Get the XML document from file
XmlDocument xmlDoc = new XmlDocument() ;
xmlDoc.Load(xmlDocumentCipherTextFilename) ;
// Retrieve the element to be decrypted
XmlElement patientPersonallnformationEncrypted =
(XmlElement)xmlDoc.SelectSingleNode(
"medicalRecord/EncryptedData");
XmlElement xmlCipherValue =
(XmlElement)patientPersonallnformationEncrypted.SelectSingleNode(
"CipherData/CipherValue");
byte[] patientPersonallnformationEncryptedBytes =
Convert.FromBase64String(

Безопасность в XML • Глава 8 3
xmlCipherValue.InnerText);
// Set up the CryptoStream for decryption
MemoryStream memoryStream = new
MemoryStream(patientPersonalInformationEncryptedBytes);
CryptoStream cipherStream = new CryptoStream(memoryStream,
tripleDES.CreateDecryptor(),CryptoStreamMode.Read);
// Perform decryption
byte[] patientPersonalInformationBytes =
new Byte[patientPersonalInformationEncryptedBytes.Length];
cipherStream.Read(patientPersonallnformationBytes, 0,
patientPersonalInformationBytes.Length);
cipherStream.Close();
memoryStream.Close();
// Write the decrypted information to disk
string patientPersonallnformationString =
Encoding.UTF8.GetString(patientPersonalInformationBytes);
StreamWriter fileplaintext = new
StreamWriter(xmlDocumentPlainTextFilename);
fileplaintext.Write(patientPersonallnformationString);
fileplaintext.Close();
Рис. 8.8. Расшифрование XML документа:VB.NET
Public Function decryptDocument(ByVal xmlDocumentCipherTextFilename,
ByVal xmlDocumentPlainTextFilename)
' Get the XML document from file
Dim xmlDoc As XmlDocument = New XmlDocument
xmlDoc.Load(xmlDocumentCipherTextFilename)
' Retrieve the element to be decrypted
Dim patientPersonallnformationEncrypted = _
xmlDoc.SelectSingleNode( _
"medicalRecord/EncryptedData")
Dim xmlCipherValue = _

> Глава 8 • Безопасность в XML
patientPersonallnformationEncrypted.SelectSingleNode( _
"CipherData/CipherValue")
Dim patientPersonallnformationEncryptedBytes As Byte()
patientPersonallnformationEncryptedBytes = _
Convert.FromBase64String(xmlCipherValue.InnerText)
' Set up the CryptoStream for decryption
Dim memoryStream = _
New MemoryStream(patientPersonallnformationEncryptedBytes)
Dim cipherStream = New CryptoStream(memoryStream, _
tripleDES.CreateDecryptor(), CryptoStreamMode.Read)
' Perform decryption
Dim patientPersonallnformationBytes = _
New Byte( _
patientPersonallnformationEncryptedBytes.Length - 1) {}
cipherStream.Read(patientPersonallnformationBytes, 0, _
patientPersonallnformationBytes.Length)
cipherStream.Close()
memoryStream.Close()
' Write the decrypted information to disk
Dim patientPersonallnformationString = _
Encoding.UTF8.GetString(patientPersonallnformationBytes)
Dim fileplaintext = _
New StreamWriter(xmlDocumentPlainTextFilename, False)
fileplaintext.Write(patientPersonallnformationString)
fileplaintext.Close ()
End Function
Способы защиты
■ Используйте надежные шифры для обеспечения секретности данных.
■ Зашифровывайте только уязвимые данные в XML-документе.
■ Удаляйте уязвимые данные, не нужные получателю, вместо того, чтобы
зашифровывать их.

Безопасность в XML • Глава 8 3
Применение цифровых подписей XML
Не смотря на то, что шифрование является важным шагом в обеспечении
безопасности ваших XML, связанных с Интернетом, иногда вам необходимо
убедиться, что вы получаете информацию именно от того человека, от которого
думаете. WSC также участвует в процессе планирования спецификации для обработки
цифровых подписей.
Цифровые подписи XML подписывают элемент или, что чаще всего, весь
документ XML. Цифровое подписание - это процесс создания хэша или отпечатка
документа с последующим шифрованием этого хэша ключом секретности. Этот
процесс защищает изменение документа кем-либо без обнаружения; он также
подтверждает идентичность отправителя документа. Технология и алгоритмы
создания хэша, а также обсуждение ассиметричного шифрования (использование
общего ключа и частного ключей), представлены в Главе 4.
Подпись данных XML
Исходное положение: Цифровые подписи XML целесообразны для
проверки целостности данных и подлинности
отправителя.
Угроза: Нарушение целостности данных, атаки человек-
в-середине, атаки грубого подбора.
Документы XML с цифровой подписью обладают следующими преимуществами:
■ Целостность Документ остается именно таким, каким он был при
подписании. После подписания документ не может быть изменен никаким
способом, без объявления подписи недействительной.
■ Аутентификация Документ поступает только от подписывающего и ни от
кого более.
■ Невозможность отрицания Подписчик документа не может отрицать
свою подпись.
Документ, подписанный цифровой подписью, не скрыт. Если
конфиденциальность важна, нужно применить шифрование XML. Цифровой подписи подлежат
такие документы, как контракты и соглашения, для которых важно, чтобы условия
контракты не изменялись, и отправитель не мог отрицать факта подписания им
Данного документа.

3 Глава 8 * Безопасность в XML
Спецификация цифровых подписей XML
Спецификация цифровой подписи XML - это достаточно стабильный
рабочий план. Он охватывает методы описания цифровой подписи при помощи
XML и пространство имен XML-подписей. Код должен выработать подпись
из хэша над канонической формой манифеста, который может ссылаться
на множественные документы XML. Принести что-либо в каноническую форму,
значит привести в стандартный формат общего использования. Поскольку
подпись зависит от содержания подписываемого документа, подпись,
произведенная из неканонизированного документа, может отличаться от подписи,
произведенной канонизированным документом. Помните, что эта спецификация
относится к определению цифровых подписей вообще, а не только в случаях
с XML документами - манифест может также содержать ссылки на любой
цифровой документ, даже на часть XML-документа.
Знание методов работы цифровых подписей помогает лучше понимать
эту спецификацию. Цифровое подписание документа требует создание
отправителем хэша самого сообщения, а затем зашифровать значение этого
хэша его собственным ключом секретности. Только отправитель,
обладающий этим ключом, может зашифровать хэш, так что он может быть
расшифрован при помощи его общего ключа. Получатель, принимающий как
сообщение, так и зашифрованное значение хэша, может расшифровать
значение хэша, зная общий ключ отправителя. Получатель также должен
попытаться создать значение хэша и сравнить вновь созданное значение со
значением незашифрованного значения хэша, полученного от отправителя.
Если значения идентичны, это доказывает, что именно этот отправитель
отправил сообщение, потому что только отправитель может правильно
зашифровать значение хэша. Спецификация цифровой подписи XML отвечает
за точное определение информации, вовлеченной в подтверждение
цифровых сертификатов.
Цифровые подписи XML представлены элементом Signature,имеющим
следующую структуру: обозначает ноль или одно событие, + обозначает одно и более
событий, и * обозначает ноль или более событий.
Спецификация XML находится в рекомендованной стадии и готова для
утверждения. Для получения более подробной информации, можно просмотреть
на официальной спецификации W3C Синтаксис и Использование Подписи
на www.w3.org/TR/xnldsig-core. Рис. 8.9. демонстрирует синтаксис спецификации
цифровой подписи XML.

Безопасность в XML • Глава 8 •
Рис. 8.9. Структура цифровой подписи XML
<Signature>
<SignedInfo>
(CanonicalizationMethod)
(SignatureMethod)
(<Reference (URI=)? >
(Transforms)?
(DigestMethod)
(DigestValue)
</Reference>)+
</SignedInfo>
(SignatureValue)
(Keylnfo)?
(Object)*</Signature>
Ниже приведены наиболее значимые элементы спецификации:
■ Подпись Исходная конструкция подписи XML. Это самый важный
элемент, на котором держатся все остальные элементы подписи.
■ Подписанная Информация Порождающий элемент, содержащий в себе
элементы алгоритма канонизации и подписи.
■ Метод канонизации Элемент, описывающий алгоритм,
подготавливающий данные для подписи. Канонизация - это необходимая и важная
трансформация, использующаяся для преобразования данных в стандартный
формат, который будут вырабатывать те же результаты хэша, независимо
от вычислительной среды. Например, среда Windows и Unix используют
разные ключевые коды для представления возврата каретки. Канонизация
стандартизует эти ключевые коды.
■ Метод подписи Алгоритм, используемый для подписания данных. Это
может быть комбинация дайджест алгоритмов, алгоритм шифрования или
алгоритм заполнения.
■ Значение подписи Действительная цифровая подпись, base-64 encoded.
■ Метод дайджест Алгоритм, поименный к файлам после применения
любых определенных трансформаций для образования Значения Дайджест.

Глава 8 * Безопасность в XML
Подписание Значения Дайджеста связывает источник содержания с
ключом подписывающего.
■ Значение дайджеста Значение, образованное применением Метода
Дайджест к объекту данных для подписи.
■ Информация ключа Порождающий элемент, содержащий подробную
информацию о ключе, используемом для подтверждения правильности подписи.
Таким образом, все, что вам надо сделать - подтвердить достоверность
подписи. Для этого нужно комбинировать объект данных отосланного при помощи
сравнительного Метода дайджест. Ссылка действительна, если комбинированное
значение соответствует Методу Дайджесту. Затем для подтверждения достоверности
подписи, соберите ключевую информацию из Значения подписи и подтвердите её
достоверность через элемент Подписанная информация.
Пример цифровой подписи XML
Представим, например, что мы являемся представителями агентства по
продаже автомобилей. Нам нужно поместить подробную информацию о наших
машинах и цены на них в поисковой службе Интернет. Поисковая служба требует наши
данные в XML так, чтобы она могла отобразить информацию в различных
форматах и областях просмотра. Однако мы хотим защитить наши данные от изменения
как при передачи в поисковую службу Интернета, так и в самой поисковой службе.
Являясь агентством по продаже автомобилей, мы не беспокоимся о том
возможном просмотре наших данных при пересылке их в поисковую службу; на самом
деле, чем больше людей их увидят, тем лучше! Мы решили использовать цифровую
подпись XML для защиты от изменений информации по нашим автомобилям. Рис.
8.10. демонстрирует пример документа, готового для цифровой подписи.
Рис. 8.10. Документ ХМL для цифровой подписи
<?xml version="l.0"?>
<acmeCars>
<carDetails>
<make>Honda</make>
<model>Accord</model>
<year>2004</year>
<price>23000</price>
</carDetails>
<carDetails>

Безопасность в XML • Глава 8
<make>Ford</make>
<model>Probe</model>
<year>1990</year>
<price>530</price>
</carDetails>
<carDetails>
<make>Ferrari</make>
<model>Enzos</model>
<year>2003</year>
<price>643330</price>
</carDetails>
</acmeCars>
Пример кода на рис. 8.11. и 8.12. демонстрируют метод прочтения документа
XML и динамичного создания цифровой подписи. Для простоты, код
вырабатывает ключ шифрования. Обычно код читает ключ из безопасного местонахождения.
Рис. 8.11. Создание цифровой подписи XML: С#
void signDocument(string xmlDocumentUnsignedFilename, string
xmlDocumentSignedFilename)
{
// Load the document to be signed, and key to use
XmlDocument xmlDoc = new XmlDocument() ;
xmlDoc.Load(xmlDocumentUnsignedFilename);
SignedXml signedXml = new SignedXml();
signedXml.SigningKey = rsaKey;
// Set up data object to contain the data the will be signed
DataObject dataObject = new DataObject();
dataObject.Data = xmlDoc.ChildNodes;
dataObject.Id = "SignedObject";
signedXml.AddObject(dataObject);
Reference reference = new Reference();
reference.Uri = "#SignedObject";
signedXml.AddReference(reference);
// Create signature

Глава 8 * Безопасность в XML
Keylnfo keylnfo = new KeylnfoO;
keylnfo.AddClause(new RSAKeyValue(rsaKey));
signedXml.Keylnfo = keylnfo;
signedXml.ComputeSignature();
// Write signature to file
XmlElement xmlSignature = signedXml.GetXml();
xmlDoc = new XmlDocument();
XmlNode xmlNode = xmlDoc.ImportNode(xmlSignature, true);
xmlDoc.AppendChild(xmlNode);
xmlDoc.Save(xmlDocumentSignedFilename);
Рис. 8.12. Создание цифровой подписи XML: VB.NET
Public Function signDocument(ByVal xmlDocumentUnsignedFilename, ByVal
xmlDocumentSignedFilename)
' Create key
Dim rsaKey = RSA.Create()
' Load the document to be signed, and key to use
Dim xmlDoc = New XmlDocument
xmlDoc.Load(xmlDocumentUnsignedFilename)
Dim signedXml = New SignedXml
signedXml.SigningKey = rsaKey
' Set up data object to contain the data the will be signed
Dim dataObject As DataObject = New DataObject
dataObject.Data = xmlDoc.ChildNodes
dataObject.Id = "SignedObject"
signedXml.AddObj ect(dataObj ect)
Dim reference As Reference = New Reference
reference.Uri = "#SignedObject"
signedXml.AddReference(reference)
' Create signature
Dim keylnfo As Keylnfo = New Keylnfo
keylnfo.AddClause(New RSAKeyValue(rsaKey) )

Безопасность в XML • Глава 8 3
signedXml.Keylnfo = keylnfo
signedXml.ComputeSignature()
' Write signature to file
Dim xmlSignature As XmlElement = signedXml.GetXml()
xmlDoc = New XmlDocument
Dim xmlNode As XmlNode = xmlDoc.ImportNode(xmlSignature, True)
xmlDoc.AppendChild(xmlNode)
xmlDoc.Save(xmlDocumentSignedFilename)
End Function
На рис. 8.13. изображен пример документа XML после цифрового подписания
Рис. 8.13. Документ ХМL после цифрового подписания
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-
cl4n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-
shal" />
<Reference URI="#SignedObject">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#shal" />
<DigestValue>sPpOt0ysPVG7iPkC9/avA/4bjhM=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>VwiNfYfXdY7bPAk4nULVUdlbIs572RMEWeElk68jIzWojA+3WnmwU/
jJU5KYc8/DvwXlgnW/kI/hIpPswcpURS085nNTKIKwYHX/eS7f8h5JcSlCUlEUdnpxoHEw
tbsEu80uVYUR4AiBgnFlQPVeJldiKHjRdol4j+hkZSM8p6o=</SignatureValue>
<KeyInfo>
<KeyValue xmlns="http://www.w3.org/2000/09/xmldsig#">
<RSAKeyValue>
<Modulus>wRMK+SKiDIRBHRYlNUc6SpTt+3iPcMGFwdg27MgsU2ydaCJyTZMCsFfDewZ6j
K+cJvLLi3+b4 6YwEYJ/GyPvdXSOGPHTNaDFTi7AsKAGu4eXkFhSExnDPUJlnOiToG0eMYX
Wj/DRvK8adMahoeqIkysmkUKq4Y090vqMkwMyJ3M=</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>

I Глава 8 * Безопасность в XML
</KeyInfo>
<Object Id="SignedObject">
<acmeCars xmlns="">
<carDetails>
<make>Honda</make>
<model>Accord</model>
<year>2004</year>
<price>23000</price>
</carDetails>
<carDetails>
<make>Ford</make>
<model>Probe</model>
<year>1990</year>
<price>530</price>
</carDetails>
<carDetails>
<make>Ferrari</make>
<model>Enzos</model>
<year>2003</year>
<price>64 3330</price>
</carDetails>
</acmeCars>
</Object>
</Signature>
Создание XML документа с цифровой подписью - это только половина дела.
Теперь получатель документа должен удостовериться в действительности подписи
и в том, что документ не был изменен.
Продолжая наш пример с агентством по продаже автомобилей, поисковая
служба Интернет, на которую мы поместили наш подписанный документ, теперь
должна проверить достоверность подписи. Если подпись документа
действительна, поисковая служба может гарантировать, что документ не был изменен. На рис
8.14. и 8.15. приведен пример кода для проверки достоверности подписанного
документа XML.

Безопасность в XML • Глава 8 3
Рис. 8.14. Проверка достоверности цифровой подписи XML: С#
bool verifySignature(string xmlDocumentSignedFilename)
{
// Load signed XML document
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.PreserveWhitespace = true;
xmlDoc.Load(xmlDocumentSignedFilename);
SignedXml signedXml = new SignedXml(xmlDoc);
// Get the signature element
XmlNodeList nodeList = xmlDoc.GetElementsByTagName(
"Signature", "http://www.w3.Org/2000/09/xmldsig#");
signedXml.LoadXml((XmlElement)nodeList[0]);
// Validiate signature
if (signedXml.CheckSignature())
return true; // signature valid - document unmodified
else
return false; // signature invalid- document modified
Рис. 8.15. Проверка достоверности цифровой подписи VB.NET
Public Function verifySignature(ByVal xmlDocumentSignedFilename) As
Boolean
' Load signed XML document
Dim xmlDoc As XmlDocument = New XmlDocument
xmlDoc.Load(xmlDocumentSignedFilename)
Dim signedXml As SignedXml = New SignedXml(xmlDoc)
' Get the signature element
Dim nodeList = xmlDoc.GetElementsByTagName( _
"Signature", "http://www.w3.Org/2000/09/xmldsig#")
signedXml.LoadXml(CType(nodeList(0) , XmlElement))
' Validiate signature
If signedXml.CheckSignature() Then

> Глава 8 * Безопасность в XML
Return True f signature valid - document unmodified
Else
Return False ' signature invalid- document modified
End If
End Function
Вы, возможно, заметите увеличение в использовании шифрования и
цифровых подписей, когда группа W3C подведет итоги спецификаций XML-шифрования
и цифровой подписи. Обе спецификации предлагают хорошо структурированный
способ обеспечения взаимодействия их соответствующих процессов, и, как
обычно бывает при простоте в использовании, находят применение. Шифрование
гарантирует, что конфиденциальная информация останется конфиденциальной на
протяжении рискованного путешествия по Интернету. Цифровые подписи гаран-
тир} ют, что вы общаетесь с тем, с кем вы хотите, это делать. Не смотря на это,
обе эти спецификации еще нуждаются в развитии, особенно когда они
используются одновременно. В настоящее время не существует способа определения, был
ли подписанный и зашифрованный документ подписан, используя
зашифрованную или не зашифрованную версию документа. Как правило, эти небольшие
столкновения находят способ сглаживаться со временем.
Способы защиты
■ Используйте надежные ассиметричные алгоритмы для гарантирования
секретности данных.
■ Проверяйте достоверность подписи подписанных документов.
■ Используйте шифрование для отправки секретных данных. Цифровые
подписи не делают документ секретным; они только подтверждают
достоверность целостности источника.

Безопасность в XML • Глава 8
Краткая справка по стандартам кодирования
Применение шифрования XML
Шифрование данных XML
• Используйте надежные шифры для обеспечения секретности данных.
• Для эффективности достижения целей, зашифровывайте уязвимые
данные только в XML-документе.
• Вместо шифрования удаляйте уязвимые данные, не нужные получателю.
Применение цифровых подписей XML
Подписание обозначений данных XML
• Используйте надежные ассиметричные алгоритмы для гарантирования
секретности данных.
• Проверяйте достоверность подписи подписанных документов.
• Используйте шифрование для отправки секретных данных. Цифровые
подписи не делают документы секретными; они только проверяют
достоверность целостности документа.
Краткая справка проверки кода
Применение шифрования XML
Шифрование данных XML
• Зашифровывает ли приложение документ, используя только хорошо
установленные алгоритмы шифрования, избегая слабых методов шифрования
и способов кодирования
• Все ли уязвимые данные зашифрованы?
• Содержатся ли ключи для шифрования в безопасности?
© Если код не включает в себя элементы Метод шифрования и
Зашифрованный Ключ, была ли стратегия установлена таким образом, что получатель
знает эту информацию?
• Действительно ли надо получателю зашифрованных данных получать
доступ к ним?

Глава 8 * Безопасность в XML
Применение цифровых подписей XML
Подписание обозначения данных XML
• Подписывает ли приложение документ, используя только хорошо
образованные алгоритмы шифрования, избегая слабых методов шифрования
или способов кодирования?
• Содержатся ли ключи для подписания в безопасности?
• Если шифрование и подписание использовались вместе, пришли
ли стороны к соглашению, когда применять шифрование - до или после
подписания.
FAQ
Вопросы (В) и ответы (О)
В: Должен ли я когда-нибудь применять шифрование XML и цифровые подписи
XML вместе?
Ol Зашифрованныеданмьш не могут быть изменены без обнаружения, поэтому
шифрование XML также обеспечивает преимущество целостности данных
цифровой подписи. Шифрование XML, однако, не требует использования ас-
симетричного шифрования (вдюч секретности или общий ключ). Ассимет-
ричное шифрование - это мет?>д, предлагающий преимущество
аутентификации и не отрицания. £сли ваш необходимы секретность, целостность,
аутентификация и невозможность отрицания, ишюльзуй^е оба этих метода.
Bl Если я решу использовать шифрование XML и цифровые подписи XML
вместе, должен ли я сначала подписать документ Д затем применить шифрование,
или сначала зашифровать, а затем подписать ет®?
Ol Порядок выполнения не имеет значения, т.к. в настйшцее время не
существует стандарта, определяющего, что должно быть раньше. Тем не менее, очень
важно, чтобы получатель знал порядок, в котором проводилось шифрование
и подписание; в противном случае, он не сможет образовать правильный хэш
документа.
В: Если мне нужно зашифровать весь документ, и я не хочу его архивизироватъ,
не будет ли лучше, если я отправлю его через SSL?
Ol Да, если вас устраивает алгоритм SSL и размер ключа. В этом случае, преимУ"
щество использования шифрования XML в том, что это позволяет вам опре"
делить ваш собственный алгоритм и размер ключа.

Безопасность в XML • Глава 8
В: Какие алгоритмы и размер ключа вы рекомендуете для шифрования XML
и цифровых подписей XML?
Ol См. Главу 4, в которой обсуждалась надежность различных алгоритмов и
рекомендованных размеров для каждого.

Приложение А
^ftcHOs»-i% онят ищ-нш
В Приложении рассмотрены:
а Риск, связанный с использованием XML
в .NET Framework
О Внутренняя защита .NET как приемлемая
*' альтернатива ?;' •,-''''*£»**"
; Концепции безс^™^йй^ти^^
Д Настройка системы безопасности и ее
функций в соответствии с конкретными
особенностями задачи пользователя
О Методы защиты
3 Криптография
□ Инструменты обеспечения
конфиденциальности
13 Краткая справка по безопасности
361

Приложение А • Основные понятия .NET Security
Введение
Обеспечение безопасности в .NET Framework и Общая система отслежив
времени выполнения (Common Language Runtime - CLR) работают намного
дежнее, чем принято думать. Однако усовершенствование систем защиты полп
AjJcl3y-
мевает появление новых концепций. Разработчики должны освоить новые под
ды. Иногда эти концепции могут быть камнем преткновения для написания ко
безопасности. Но, преодолев трудности, вы поймете, что методы обеспечения б
зопасности .NET упрощают методы защиты ASP.NET.
Перечислим некоторые из инновационных опций концепции безопасности
.NET Framework:
■ Защита доступа к коду
■ Настройка системы безопасности под задачи конкретной компании
■ Методика защиты
Важно понимать, что безопасность должна быть основополагающей частью
вашей концепции в период ее разработки и внедрения. Первостепенной задачей
является защита вашей системы от злонамеренного взлома и недопущение
неправильного пользования кодами с меньшими правами. Например, вы внедряете
комплект, который содержит функции, модифицирующие установки директории.
Поскольку эти функции могут быть задействованы с помощью других,
неизвестных кодов, они могут стать инструментом для злонамеренных действий, если вы
не рассматриваете безопасность .NET Framework как часть вашего кода.
Вам необходимо понять концепции, положенные в ее основу .NET Security.
Полномочия
В обычной жизни полномочия означают власть, данную кому-либо для выдач
формального разрешения на выполнение некого задания, которое обычно рассч!
тано на определенную группу людей. Полномочия имеют тоже значения и в .
Security Framework: получение права доступа к ресурсам или операциям, недос ,
ным для неавторизованных пользователей или программ. Примером зашише
го ресурса может служить каталог, а защищенной операцией — обращение к ко
ненту СОМ+, который рассматривается как неуправляемый код, и, следовател
менее безопасен. .NET Framework проверяет следующие полномочия:
■ Полномочия доступа к коду. Защищает систему от разрушения с помо
взламывающего или нестабильного кода.

Основные понятия .NET Security • Приложение А 36
щ ролевые полномочия безопасности. Ограничивает задания, которые мо
жет выполнять обладатель логина, основываясь на ролях, которые
обозначены через статус пользователя или в его идентификационной
информации.
■ Запросы. Система кодирования может запрашивать у CLR конкретные
полномочия, в соответствии с которыми этот запрос авторизуется, только
если набор данных, содержащий код, обладает достаточным уровнем
доверия. Уровень доверия связан с методикой защиты, который присваивается
данным файлам. Код никогда не может запрашивать больше полномочий,
чем ему отводит методика безопасности. CLR будет всегда отрицать такие
запросы.
■ Разрешения. CLR может давать разрешения, основываясь на методике
защиты и уровне доверия, присвоенного коду.
■ Требования. Концепция предполагает, что запрашивающий заранее
получает определенные полномочия для выполнения задания. Вы
ответственны за эту часть безопасности.
Механизм Principal
Principal доказывает идентичность пользователя, осуществляющего запрос.
При вызове кода, либо напрямую пользователем, либо из другого кода, этот код
активизируется в контексте уровня доступа вызывающего. NET Framework
ссылается на три типа principals:
■ Пользовательский аккаунт Windows. Состоит из имени и домена в
формате user@domain или domain\user
* Generic principal Идентифицирует пользователя и роль пользователя, не
имеющую отношение к Windows. Приложение ответственно за создание
этого типа principal. Имперсонизация не проводится, но, так как код
может модифицировать principal, он может принять идентификацию другого
пользователя или роли.
' Собственный principal. Можно построить его самостоятельно для
придания дополнительных характеристик, которые более подходят к вашему
приложению. Нельзя раскрывать свои механизмы, чтобы не обозначать
уязвимые места программы.

'fl. Приложение А - Основные понятия .NET Security
i
Опознавание
Опознавание — это подтверждение идентичности пользователя — логин
зователя, который он вводит. Поскольку механизм проверяет идентичность в
ваемой программы в .NET Framework, код сначала должен установить идент
ность. Так как ваш код может обеспечить доступ к закрытой информации, он
жет потребовать прохождения дополнительных идентификационных тестов Н
самом деле, поскольку вы создали собственный механизм, можно контролироват
и процесс аутентификации. .NET Framework поддерживает не только наиболее
популярные методы аутентификации с доменом Windows 200 — NTLM и Kerberos
версии 5.0 — но и другие формы аутентификации, например Microsoft Passport. .NET
Framework использует ролевую защиту для определения, имеет ли пользователь
право на доступ к коду.
Авторизация
Авторизация следует после аутентификации. Она основана на определении
идентичности. Авторизация пользователя — это процесс подтверждения прав
пользователя на получение доступа к источнику. Можно ссылаться на
информацию о пользователе и важности авторизации его, о разрешении доступа к
источникам системы или для выполнения закрытой операции. Полномочия субъекта,
основанные на его идентичности, определяют, обладает ли он доступом к
специфическим защищенным источникам.
Способы защиты
Для управления безопасностью в CLR администратор может создавать новые или
модифицировать существующие методы защиты. До того как CLR загрузится, он
проверяет его логины. Это основание — часть программы. CLR определяет методы
защиты в зависимости от предоставленного уровня доступа. Администратор системы
контролирует методику защиты для предотвращения злонамеренного входа. Не д
« /э Чем
вайте полномочий субъекту, идентичность которого вы установить не можете.
строже вы определяете методику защиты, тем более безопасно будет работать С
Безопасный тип
.NET Framework помечает код как безопасный типу если только он получае
туп к ресурсам памяти, которые не принадлежат присвоенной ему памяти. 11°д .
рждение достоверности безопасности типа происходит во время этапа JH с
lation и предотвращает активацию незащищенного кода. Блокировка подтвер
ния достоверности безопасности типа может привести к непредсказуемым р

Основные понятия .NET Security • Приложение А 36
таМ. Лучшим примером служит то, что код может установить неограниченные
брашения к автономной системе кодировки, и если у ее автора враждебные наме-
ния, это может привести к плачевным последствиям.
Заирпа кода доступа (Code ^Security-GAS)
.NET Framework основана на концепции распределенных приложений, в
которой приложение может контролироваться несколькими людьми. Для решения
проблемы, какой части приложения доверять, существует CAS. Это достаточно
надежный способ защиты вашей системы от предумышленной или просто
нестабильной кодировки. Помните, что он всегда работает, даже если вы не
используете его в своей системе. Данная концепция помогает вам в решении следующих
задач:
■ Ограничение полномочий доступа с применением методик защиты.
■ Защита системы от нелегального увеличения полномочий.
■ Управление и конфигурирование наборами полномочий в методиках
безопасности для отражения специфических потребностей безопасности.
■ Присвоение субъектам специфических полномочий.
■ Активирование прав доступа в зависимости от полномочий конкретного
пользователя или программы.
■ Использование идентичности вызывающей программы и логинов для
получения доступа к защищенным источникам и кодам.
-NET Code Access Security Mode
Эта система основана на ряде свойств:
* Нестрогая очередность
■ Идентичность кода
■ Группы кода
' Декларативная и императивная безопасность

6 Приложение А * Основные понятия .NET Security
■ Запрашивание полномочий
■ Требование полномочий
■ Отмена проверок безопасности
■ Индивидуальные полномочия
В дальнейшем, мы подробнее рассмотрим общие методы работы CAS, а такж
применительно к вашей разработке и внедрению приложений .NET.
Нестрогая очередность (Stack Walking)
Это, вероятно, самый важный механизм в CAS, используемый для того чтобы
пользователи не получали доступ к защищенным источникам и системе во время
работы с web-сайтом. Как уже было отмечено ранее, один из первоначальных
шагов при загрузке клиента — это определение уровня доверия и соответствующего
ему набора полномочий. Итоговый пакет настроек — это максимальное число
полномочий, которые может получить субъект.
Поскольку система кодирования может вызывать метод другого комплекта
и так далее, образуется цепочка вызовов (см. Рис. АЛ), в которой каждый
комплект имеет свой набор полномочий. Предположим, ассемблирование требует,
чтобы вызывающая его программа обладала специфическими
полномочиями UlPermission на рис. АЛ) для того, чтобы иметь возможность выполнять этот
метод. Теперь в работу вступает Stack Walking. CLR начинает проверку очередности,
где каждый элемент в вызывающей цепочке имеет свой собственный сегмент
данных. Возвращаясь в очередь, CLR проверяет на наличие требуемых полномочии —
в нашем случае, UlPermission. Если все комплекты обладают этими полномочиями,
система будет работать. Если, однако, в каком-либо месте цепочки элемент не
обладает этими полномочиями (в нашем случае, это в Assembly i), CLR создает, запре
щает выполнение операции.

Основные понятия .NET Security * Приложение А
рис. А-1- Применение нестрогой очередности для защиты от
неавторизованного доступа
Неудачно
Успешно
1 Method la
Assembly 1
Предоставленные 1
полномочия:
FilelOPermission
Успешно
Method 2a
Assembly 2
Предоставленные
полномочия:
FilelOPermission
UlPermission
Успешно
Method За
Assembly 3
Предоставленные
полномочия:
FilelOPermission
UlPermission
Успешно
Method 4a
Assembly 4
Предоставленные
полномочия:
FilelOPermission
UlPermission
Method 5a
Assembly 5
Предоставленные
полномочия:
FilelOPermission
UlPermission
UlPermission
(SecurityAction.Demand)
Method 6a
Assembly 6
Предоставленные
полномочия:
FilelOPermission
UlPermission
|
з
04
О
3
о
о
х
го
го
о
го
S
Нестрогая очередность защищает систему от неавторизованного проникнове-
ния к защищенным источникам и коду. Можно включить его в любое место
цепочки вызовов. Эффективный набор полномочий равен совокупности наборов
полномочий вовлеченных элементов (субъектов и объектов).
Даже если в вашей системе не предусмотрено требование полномочий, нестро-
зя очередность все равно будет выполняться, поскольку она обязательна для всех
Пассов библиотек CLR. Единственным недостатком нестрогой очередности явля-
Ся то, что она серьезно влияет на производительность, особенно, если цепочка
*зовов длинная. Если цепочка состоит из восьми элементов, и первый из них де-
ает запрос, требующий специфических полномочий. Этот цикл производится 200
№&j столько же раз его проверяет система безопасности. Поскольку при каждом
Р°хождении цикла выполняется восемь проверок, общее число их равно 1600.

Приложение А * Основные понятия .NET Security
Идентичность кода
Общие принципы системы .NET Framework полностью основаны на иде
ности кода, или на том, какому уровню надежности соответствует часть сист
CLR устанавливает идентичность кода исходя из представленных признаков
оснований. Основание формируется из двух источников:
■ Основание, которое включено в состав объекта во время программипст
ния и последовательного компилирования кода или, которое может быт
добавлено в него позже.
■ Основание, предоставленное хостом, на котором находится объект. CLR
контролирует принятие хостом признака через полномочия безопасности
ControlEvidence, которые нужно предоставлять только проверенным хостам.
В Таблице АЛ. приведен перечень оснований по умолчанию, которые могут
быть использованы для определения принадлежности кода к той или иной группе.
Так как вы не можете контролировать идентичность субъекта, невозможно дать
гарантию, что это основание надежно, за исключением предоставленных
подписей.
Таблица А.1. Типы доступных оснований по умолчанию
Основание Описание
Каталог Каталог, в котором установлено
приложение — а, следовательно, и
элемент.
Хэш Криптографичекий хэш кода MD5 или
SHA-1 (см. раздел «Криптография»
Издатель Подпись владельца комплекта на форме
сертификата Х.5096 устанавливается
через код аутентификации.
Сайт Название web-сайта, из которого
исходил вызов — например, www.com-
pany.com (префиксы и суффиксы не
принимаются во внимание).
Системное имя Состоит из имени комплекта (данное
имя), общего ключа (издателя), номер
версии и особых отметок.

Основные понятия .NET Security * Приложение А 369
Полный URL (также называемый
основание кода), включает в себя
префиксы и суффиксы:
https://www.company.com:4330/*.
Место происхождения комплекта. Зоны
по умолчанию: Интернет, локальный
интранет, Мой компьютер, web-сайты с
высоким и низким уровнем доступа.
Чем больше данных о части приложения, осуществляющей доступ, вы
соберете, тем проще будет определить корректный уровень полномочий.
Системное имя играет очень большую роль. Серьезные разработчики
приложений должны обязательно использовать специальные наименования элементов,
чтобы предотвратить хакерские атаки. К сожалению, система, через которую
осуществляется взлом, может также иметь строгое имя, поэтому, лучшее основание —
это сертификат и подпись, которые должны быть представлены вместе с
приложением. После настройки уровня безопасности комплекта, основанной на всех
основаниях, представленных вам, вы сможете определить соответствующий набор
полномочий. Именно с этого этапа начинается сфера контроля — построение
соответствующих групп кода.
Группы кода
Группа кода — это группа приложений, имеющих одно общее значение, и
только одну часть основания, называемую условие членства. Исходя из этого основания,
приложению присваивается набор полномочий, присоединяется к
определенному блоку. Поскольку группа кодов является частью иерархии группы кода (см. рис.
А-2.), этот блок может быть частью большего числа групп кода. Эффективный
набор полномочий блока — это объединение наборов полномочий групп кода, к
которому он принадлежит.

Приложение А • Основные понятия .NET Security
Рис. А.2. Графическое представление иерархии группы кода
Все_коды
Набор полномочий:
Ничего
Сайг
Набор полномочий: 1
Ничего J J
mednjonamicrosoftoom |
Издатель:
1 msdn.ona
Набор полномочий: 1
Локальный Интранег|
rnicrosoftoorn
Зона:
Интернет
Набор полномочий: 1
Интернет |
Набор полномочий:
Полное доверие
Строгое
имя: MyOwnOompany
Когда блок готов к загрузке, собираются все характеристики и
проверяется иерархия группы. Когда CLR согласовывает блок с системой,
проверяются дочерние коды элементов блока. Это подразумевает, что построение
иерархии очень важно и должно начинаться с основных моментов,
например с зоны, и далее к более специфичным вопросам, таким как издатель.
Осложняющим фактором здесь является наличие трех уровней защиты
(Enterprise — Корпорация, Machine — Компьютер и User — Пользователь),
каждый из которых обладает собственной иерархией группы кода. CLR
оценивает все три уровня, получая три различных набора полномочий, которые
пересекаются для установки эффективного набора полномочий.
Создание иерархий групп системы кодировки, которые могут быть
быстро просмотрены, и укрепление высокого уровня защиты зависит от админи
стратора. Для этого нужно:
Ограничить количество уровней.
На первом уровне использовать условия членства, которые обеспечива
отличия, не требующие проверки больших частей системы.
Корень иерархии, All Code, не должен обладать присвоенными полн
чиями. Таким образом, не разрешается использование кода, который н
держит какого-то минимального количества признаков.

Основные понятия .NET Security * Приложение А
Чем выше в иерархии располагаются основания — например, сертификат
издателя — тем больше полномочий может быть предоставлено.
■ Не делайте исключений, выдавая больше полномочий, чем
подтверждают основания. Предположите, что у вас запущено специальное
приложение в интранет-зоне, которое требует полного доверия для работы. Так
как это ваше собственное приложение, вы безоговорочно доверяете ему
Однако в описываемом случае это может обернуться против вас.
Таблица А.2. приводит перечень доступных по умолчанию условий членства.
Можно создать индивидуальные параметры, но обсуждение методов создания
условий не входит в рамки этого приложения. Боле подробно мы остановимся на
рассмотрении условий членства позже, в приложении.
Таблица А.2. Условия членства для групп кода, установленные по
умолчанию
Условие членства
Описание
Все коды
Каталог приложения
Хэш
Издатель
Сайт
Проверка игнорирования
безопасности,
низких
Утверждения права
Применяется к каждому загруженному
блоку
Применяется ко всем блокам,
находящимся на том же дереве
каталогов, что и текущее приложение;
следовательно, прикладной области
Применяется ко всем блокам,
содержащим заданный алгоритм
хэширования и значение хэша
Применятся ко всем блокам, которые
содержат заданный сертификат
издателя
Применяется ко всем пакетам,
полученным с того же web-сайта
Применяется ко всем блокам, которые
запрашивают полномочия проверки
игнорирования. Внимание: Эти
полномочия позволяют обходить
систему обеспечения
Используйте их только на
уровнях, после
доступа.

Приложение А * Основные понятия .NET Security
Строгое имя Применяется ко всем блокам, имеющим
заданное системное имя
URL Применяется ко всем блокам,
возникшим из обозначенного URL,
включая префикс, суффикс, путь и
конечный трафаретный символ
Зона Применяется ко всем блокам,
находящимся в заданной зоне
Индивидуальный Создается исходя из конкретных
условий, созданных по заказу, обычно
напрямую зависящим от специальных
приложений
Декларативная и императивная безопасность
Можно повысить безопасность вашей системы кодирования двумя
способами: запрашивая у вызывающих программ специальные полномочия или
требуя их от CLR.
Первый метод — это декларативная безопасность, которая может быть
установлена на уровне блока, класса и/или элемента множества, поэтому вы
сможете предоставить неодинаковые полномочия в различных частях
комплекта. VB.NET синтаксис декларативного кода таков:
<[assembly:] Permission (SecurityAction.Member, State)>
Например,
<assembly: FileOPermission (SecurityAction.Demand, Unrestricted : =True)>
<FileOPermission(SecurityAction.Request, Unrestricted := True)>
Первый пример безопасности действителен для всего блока; следовательн ,
каждое обращение в этом блоке должно иметь FileOPermission. Можно использова
второй пример для класса или одиночного метода. Только ссылка на частично ил
полностью реализованный абстрактный тип данных или элемент определен
класса запросят CLR для FileOPermission.
Как и предполагает синтаксис, использование о заставляет систему воспр
нимать код иначе. На самом деле, в то время когда вы помещаете код в блок, к
пилятор извлекает эти ссылки и размещает их в части метаданных блока. CLK пр
веряет эти метаданные в различных точках прохождения цикла, например, в

Основные понятия .NET Security * Приложение А 37
мент загрузки блока или в момент активизации элемента определения класса.
Используя декларативную безопасность, можно требовать, запрашивать или даже
удалять полномочия, даже перед выполнением операции. Это дает вам мощный
инструмент защиты в период разработки системы и блока. Однако это также
означает, что вы должны быть осторожны в выборе типа полномочий, которые вы
будете запрашивать и/или требовать для входа на ваш ресурс.
Второй метод — императивная безопасность, которая становится частью
вашей системы кодирования и может требовать или удалять полномочия.
Невозможно запрашивать полномочия, используя императивную безопасность, потому, что
остается не ясным, в какой момент системе нужны особые полномочия. Поэтому
запросы полномочий относятся к опознаваемым элементам кода. Можно
использовать императивную безопасность, чтобы проверить, обладает ли объект,
совершающий вызов, особыми полномочиями для части программы. Например, перед
тем как условный пользователь (это может быть инициировано даже ролевой
безопасностью) захочет получить доступ к файлу или регистрационному ключу,
можно проверить, обладает ли вызывающая программа FilMOPermission или
RegistryPermisssion. Синтаксис императивной безопасности в коде для С#
представлен на рис. А.З; безопасность в коде для VB.NET показана на рис. А.4.
Рис. А.З. Безопасность в коде:С#
Permission permissionObject = new Permission ();
PermissionObject.Demand ();
FilelOPermission checkPermission = new FilelOPermission ();
checkPermission.Demand ();
Рис. АА Безопасность в кодеЛ/В.ЫЕТ
Dim PermissionObject as New Permission ()
PermissionObject.Demand ()
Пример:
Dim CheckPermission as New filelOPermission ()
CheckPermission.Demand ()

Приложение А * Основные понятия .NET Security
Объект permission действителен только для области действия, на котооо°
объявлен; CRL автоматически отбросит объект, вышедший за пределы текуи °
процедуры. В пределах этой области требования и игнорирования императивы °
безопасности аннулируют полномочия, требуемые в утверждении декларативн °
безопасности.
Теперь, когда мы обсудили декларативную и императивную безопасность
мое время посмотреть, как можно использовать эту информацию для
запрашивания, требования и отмены полномочий.
Запрашивание полномочий
Запрашивание полномочий — это лучший способ создания безопасного
приложения и защиты от возможного неправильного использования вашей системы
кодирования. Как мы уже упоминали выше, основываясь на определенных
признаках, блок передает на CLR, который затем определяет полномочия, учитывая
актуальные методы защиты. Конечно, если вы полностью доверяете комплекту, можно
предоставить ему все запрашиваемые полномочия. CLR может предоставить
комплекту больше полномочий, чем он на самом деле нуждается, но комплект может
эксплицитно запрашивать только те специальные полномочия, в которых он
испытывает необходимость. Это создаёт один из двух сценариев:
■ Комплект запрашивает больше полномочий, чем выделяет методика
безопасности, в этом случае CLR не будет выполнять код и создаст
исключительную ситуацию.
■ Комплект специально запрашивает незначительное количество
полномочий и защищает себя от потенциального неправильного использования
неиспользованных полномочий.
Запрашивание полномочий — это хороший метод обеспечения
безопасности, но требует полного понимания разработчиком методов
использования полномочий в коде. Существует три типа запросов полномочий:
■ Минимальный запрос. Определяет полномочия, необходимые коду ДлЯ
пуска. Если полномочия Минимальный запрос не является частью устан
ленного набора полномочий, CLR не позволит провести запуск на выпол
ние кода.
■ Выборочный запрос. Определяет полномочия, которые не являются
обходимостью для запуска, но могут понадобиться при определенны ;
ловиях.

Основные понятия .NET Security * Приложение А 3
Если Оптимальный запрос не является частью установленного набора
полномочий, CLR позволит провести запуск на выполнение кода.
■ Отказ запроса. Определяет полномочия, которые ни при каких
обстоятельствах, не нужны коду, и которые не должны быть предоставлены комплекту.
Воздерживаясь от использования определенных полномочий, вы
ограждаете себя от опасностей предумышленного или ошибочного кода.
После того как кодирование завершено и вы компилировали комплекты,
ознакомьтесь с методами минимального, выборочного доступа или отказа на
каждый запрос полномочий (как перечислено в таб. А.З.), принимая за
основу необходимые коды полномочий. Можно сделать его более
конкретизированным для классов или членов. Вы можете создать безопасные комплекты.
Таблица А.З. Классы полномочий, установленные по умолчанию,
извлеченные из класса CodeAccessPermission.
Класс полномочий
Тип полномочий
Описание
DirectorySrvicesPermissio Источник
DnsPermission Источник
EnvironmentPermission Источник
EventLogPermission Источник
RieDialogPermission Источник
FileOPermission Источник
kolatedStorageFilePermission Источник
Контролирует доступ
к классу
System.DerectoryServices
Контролирует доступ к DNS
серверам сети
Контролирует доступ
к переменным среды
пользователя.
Контролирует доступ
службы журнала событий
Контролирует доступ к
файлам, выбранным через
Open File диалог.
Контролирует доступ
к файлам и каталогам
Контролирует доступ к
частным виртуальным
системам файла,
имеющим отношение к
идентичности приложения
или компонента
Продолжение на следующей странице

Приложение А * Основные понятия .NET Security
Таблица А.З. Классы полномочий, установленные по умолчанию
извлеченные из класса CodeAccessPermission.
Класс полномочии
Тип полномочий
MessageQueuePermission Источник
OleDbPermission Источ ник
PerformanceCountePermission Источник
PrintingPermission
ReflectionPermission
RegistryPermission
SecurityPermission
Источник
Источник
Источник
Источник
ServiceControllerPermission Источник
SocketPermission
SqICIientPermission
UlPermission
WebPermission
Источник
Источник
Источник
Источник
PublisherldentityPermission И дентич ность
Описание
Контролирует доступ
к службам MSMQ
Контролирует доступ к OLE
DB поставщика данных
и источников данных,
связанных с ним
Контролирует доступ к
счетчикам исполнения
Windows 2000 (или NT)
Контролирует доступ
к принтерам
Контролирует доступ
к типам метаданных
Контролирует доступ
к регистру
Контролирует доступ
к SecurityPermission, таким
как Assert, skip Verification,
и CallUnmanaged Code
Контролирует доступ
к сервисам системы
Контролирует доступ
к разъемам, необходимым
для установки и принятия
сетевых соединений
Контролирует доступ
к базе данных SQL сервера
Контролирует доступ к UI
функциональности, такой
как Clipboard
Контролирует доступ
к межсетевым ресурсам
Полномочия установлены,
если вызывающая
программа легальна^^^^
Продолжение на следующей стран

Основные понятия .NET Security • Приложение А
Таблица А.З. Классы полномочий, установленные по умолчанию,
извлеченные из класса CodeAccessPermission.
Класс полномочии
1йп полномочий
Описание
SiteldentityPermission
Идентичность
StrongNameldentityPermission Идентичность
URLIdentityPermission
ZoneldentityPermission
Идентичность
Идентичность
Полномочия установлены,
если вызывающая
программа предоставляет
основания web-сайта
Полномочия установлены,
если вызывающая
программа предоставляет
основания строгого имени
Полномочия установлены,
если вызывающая
программа предоставляет
основания URL
Полномочия установлены,
если вызывающая
программа предоставляет
основания зоны
Требование полномочий
Требуя полномочия, вы заставляете вызывающую программу получать
специальные полномочия от URL. Как мы уже обсуждали ранее, полномочия требуют
инициирования безопасности стека обхода. Даже если вы сами не выполняете эти
требования, класса .NET Framework будут выполнять их от вашего имени. Это
означает, что вам не нужно требовать полномочий, связанных с этими классами, так как
°ни сами могут о себе позаботиться. Если вы требуете полномочий, они будут
излишними и только добавят издержки выполнения. Это не означает, что нужно
игнорировать эту функцию. Наоборот, следите за тем, какой вызов инициирует стек
°бхода, и убедитесь, что код не выполняет излишних стеков обхода. Однако при
построении вашего собственного класса, имеющего доступ к защищенным
источникам, используйте декларативный или императивный синтаксис безопасности.
Использование декларативного синтаксиса при построении требований полно-
мочий, более предпочтительно, чем использование императивного синтаксиса,
Поскольку последний может привести к большему числу стеков обхода. Разумеется,
в некоторых случаях, лучше использовать императивные требования полномочий.

I Приложение А * Основные понятия .NET Security
Например, если регистрационный ключ должен быть переслан при определены
условиях, нужно выполнить императивное требование RegistryDemand перед тем
код будет действительно вызван. Это также предполагает, что вызывающая прогп
ма может и не содержать данного полномочия, что приведет к исключению, и коду
нужно будет его обработать. Ещё один пример, когда лучше использовать
императивное требование — это когда информация не известна во время компиляции
Простым примером этому может служить FiklOPermission в наборе файлов, имена
которых не известны на этапе компиляции.
CRL обрабатывает два типа требований не так, как было описано ранее. Во-
первых, можно использовать link demand только декларативно, на уровне класса
или метода. CLR выполняет ссылку требования только во время фазы JIT
компиляции, в котором он проверяет, имеет ли вызывающий код достаточно
полномочий для ссылки на ваш код. CLR не выполняет безопасный стек обход, потому что
связь существует только между вызывающей программой и вызываемым кодом.
Использование ссылки требований может быть полезным для методов, доступных
через отражение. Ссылка требования будет не только выполнять проверку
безопасности на коде, содержащим объект Methodlnfo — а, следовательно,
выполнение отражения — но и та же проверка будет проведена и на коде, который
действительно делает вызов на метод. Рис. А.5 и А.6 демонстрируют ссылку требования на
уровне класса и метода.
Рис. А.5. Ссылка требования на уровне класса и метода: С#
[SecurityPermissionAttribute (SecurityAction.LinkDemand,
Unrestricted = true)]
public classAct
{
[SecurityPermissionAttribute (SecurityAction.LinkDemand) ]
public int
Actl ()
{
//body of method
return 1;

Основные понятия .NET Security • Приложение А
рис. А.6. Ссылка требования на уровне класса и метода: VB.NET
<SecurityPermissionAttribute (SecurityAction.LinkDemand, _
Unrestricted :+ True)> Pubic Cless ClassAct
public Shared Function _
<SecurityPermissionAttribute (SecurityAction.LinkDemand)> Actl ()
As Integer
1 body of the function
Ens Function
Второй тип требования — требование наследования, который можно
использовать как на уровне класса, так и на уровне метода. Размещение требования
наследования на классе, может защитить другие классы от его наследования, пока они
обладают этим особым полномочием. Хотя вы можете использовать полномочия по
умолчанию, целесообразно, создать собственные полномочия для присваивания
наследуемому классу, для предоставления возможности наследовать из класса с
требованием наследования. Например, скажем, вы создали класс ClassAct, который
является наследственным, но также содержит набор наследственных требований. Вы
определили ваше собственное полномочие наследования InheritAct. Другой класс,
под именем ClassActing, хочет унаследовать что-либо из вашего класса, но поскольку
это защищено требованием наследования, он должен сначала получить полномочия
InheritAct на наследование. Предположим, что он получил такое полномочие.
Теперь другой класс, под названием ClassReacting, хочет унаследовать из класса
ClassActing. Чтобы унаследовать что-либо из класса CalssActing, класс ClassReacting,
также должен сначала получить полномочия InheritAct. Запрос наследования будет
выглядеть, как показано на рис. А.7. и А.8.
Рис. А.7. Запрос наследования: С#
<InheritActAttribute(SecurityAction.InheritanceDemand)> public Class
ClassAct
Рис. А.8. Запрос наследования: VB.NET
<InheritActAttribute (SecurityAction.InheritanceDemand)> Public Class
Class Act

Приложение А * Основные понятия .NET Security
Запрос наследования на уровне метода отражен на рис. А.9. и АЛО.
Рис. А.9. Запрос наследования на уровне метода: С#
[SecurityPermissionAttribute (SecurityAction.InheritanceDemand)] publi
virtual int Actl ()
{
//body of method
return 1;
Рис. А.10. Запрос наследования на уровне метода: VB.NET
Public Overridable Function _
<SecurityPermissionAttribute (SecurityAction.InheritanceDemand) >
Actl ( ) as Integer
1 Body of the function
End Function
Отмена проверок безопасности
Поскольку стек, делая обход, может вызвать серьёзные издержки и, таким
образом, приводить к снижению эффективности, вам необходимо контролировать
стеки обхода. Это особенно верно, если они не являются непосредственной частью
безопасности, например, когда часть выполнения может иметь место только в
полностью достоверном коде. С другой стороны, ваш код обладает полномочиями
права доступа к специальным защищенным источникам, но вы не хотите, чтобы
вызываемый вами код, получал доступ к этим ресурсам — поэтому вам необходимо найти
способ предотвратить это. В обоих случаях, вам нужно контролировать полномочия
проверок безопасности, следовательно, отмены проверок безопасности. Можно
сделать это, используя такие действия безопасности как Утверждать, Отрицать^
Разрешить Только (в значение «отрицать все, кроме»).
После того, как код устанавливает отмену, он может сделать отмену команды»
вызвав соответсвующий метод Возврата: Возврат Утверждения, Возврат Отрицав
Возврат Разрешить Только. В первый раз вызовите метод Возврата, перед тем как у
тановить отмену, поскольку выполнение Возврата не существующей отмены не эф"
фективно.

Основные понятия .NET Security • Приложение А 3
^Внимание
: ;:■ Можно разместить более одной отмены одного типа — например, Отрицать — на
!# одном участке кода. Однако это не допустимо для CLR. Если во время обхода
; стека CLR обнаруживает более одной отмены, он образует исключение, потому
у что не знает, какая отмена достоверна. Если вы разместили более одной отмены
* на одном участке кода, убедитесь, что сделали возврат одной отмены перед тем,
как установить другую.
Отмена Утверждения
Устанавливая отмену Утверждения на специальные полномочия, вы
провоцируете остановку проверки системы.
Внимание
Используя Утверждение, вы предотвращаете завершение проверок
безопасности в CLR, и это может представлять угрозу. Вы должны быть уверены, что
поступая таким образом, вы не подвергаете опасности вашу систему. Лучше не
отменять Утверждение.
Использование Утверждения целесообразно в следующих ситуациях:
■ Вы закодировали часть приложения. Ваш код не нуждается в доступе к
защищенным источникам, таким как системы файлов и/или регистрационные
ключи, но поскольку вызывающие программы никогда не узнают, что вы
использовали эти защищенные источники, разумно установить Утверждения
для защиты от проведения полной проверки безопасности. Вы не
заботитесь о том, есть у вызывающей вас программы такие полномочия или нет.
■ Вашей системе необходимо сделать одно или более обращений на
неуправляемый код, но поскольку вызывающий оператор получает доступ через ваш
web-сайт, он не получит полномочий на обращение к неуправляемому коду. Но
было бы разумно утвердить полномочия на доступ к неуправляемым кодам.
■ Вы знаете, что где-то в вашей системе нужно выполнить поиск, используя
структуру Do...Loop, которая в определенной точке должна получить доступ к
защищенным источникам. Следовательно, вы решаете поставить
утверждение перед обращением к защищенному источнику для защиты от избытка
стеков обхода. В случае если определённая часть кода, которая обращается
к защищенному источнику, может быть вызвана другим кодом, нужно
продвинуть утверждение на код, который может быть вызван только из вне.

2 Приложение А * Основные понятия .NET Security
Теперь мы создадим исключительную ситуацию и посмотрим, что произой
(см. Рис. А. П.). Утверждение установлено в Комплекте 4 иг. UlPermission. В ситуапи
отсутствием Утверждения, стек обхода потерпел неудачу, потому, что Комплект 1 н
обладает таким полномочием. Теперь стек обхода применяется на Комплекте 6 в
полняя требование на UlPermission, и проходя свой путь, как обычно. Стек обхо
достигает Комплекта 4 и распознает Утверждение на проверяемых им полномочиях
Стек обхода возвращается с положительным результатом. Поскольку стек обхола
был обрезан, CRL не мог узнать, что Комплект 1 не обладал этим полномочием.
Рис. А.11. Стек обхода замкнут Утверждением
о g о
= fi
?1|
•- 5 и
ill
V) О.
2.
(О О
Ф .2
■о р
^ S
II
о S
II
Успешно
Успешно
UlPermission
(SMssert)
UlPermission
(SecurityAction.Demand)
Method la
Assembly 1
Method 2a
Assembly 2
■o*
Предоставленные 1
полномочия:
FilelOPermission
L
Предоставленные 1
полномочия:
FilelOPermission
UlPermission
Method 3a
Assembly 3
Предоставленные
полномочия:
FilelOPermission
UlPermission
Method 4a
Assembly 4
Предоставленные
полномочия:
FilelOPermission
UlPermission
Method 5a
Assembly 5
Предоставленные
полномочия:
FilelOPermission
UlPermission
Method 6a
Assembly 6
Предоставленные
полномочия:
FilelOPermission
UlPermission
i
5"
OQL
О
3"
Ш
5"
Q
О
7Г
a
о
00
Z
ы
о
s
Утверждение может использоваться как с декларативным, так и с императивнь
синтаксисом. В первом примере, использовалась декларативная функция. Утверж
ние установлено на FilelOPermission. Write полномочия для файлов на C:\Test directo
на рис. А.12 и А.13.

Основные понятия .NET Security • Приложение А
Рис. А.12. Установка Утверждения: С#
[FilelOPermission (SecurityAction.Assert, Write=@"C:\Test\.cfg")]
public int Actl ()
{
return 1;
}
int Act 1 ()
{
FilelOPermission ActFilePerm = new
FilelOPermission (FilelOPermissionAccess.Write, @"C:\Test\.cfg");
ActFileperm.Assert ();
return 1;
}
Рис. А.13. Установка Утверждения: VB.NET
Public Function _
<FileIOPermission (SecurityAction.Assert, Write := «C:\Test\*.cfg")>'
Act 1 () As Integer
1 body of the function
End Function
Императивный синтаксис в установке того же типа Утверждения:
Public Function Act 1 () As Integer
Dim ActFilePerm As New _
FilelOPermission (FilelOPermissionAccess.Write, «C:\ Test\*.cfg")
ActFilePerm.Assert
1 rest of body
End Function
Отмена Отказа
Отказ позволяет стеку обхода не достигнуть успеха для полномочий, на которых
Установлен Отказ. Если среди прочих полномочий, которыми обладает ваш код,
есть Reistry Permission, то теперь он должен отправить вызов на метод, достоверность

% Приложение А • Основные понятия .NET Security
которого не подтверждена. Чтобы предотвратить использование этим кодом пре1
мущества Registry Permission, ваш код может установить Отмену. Теперь вы уверен
что он не передает полномочия высокого доверия.
Поскольку излишние отклонение Отрицания может нарушать нормальную раб<
ту проверок безопасности (так как они всегда будут терпеть неудачу на Отрицании
нужно вернуть Отрицание после окончания соответствующего запроса.
Мы использовали ту же ситуацию, что и на рис. А. 11., но вместо Утверждения щ
пользовали Отрицание (см. рис. А. 14.). И опять стек обхода инициируется дд
UlPermission полномочий в комплекте 6. Когда стек обхода достигает Комплекта 4 о
опознает Отрицание на UlPermission и заканчивается сбоем. В нашем примере, прс
верка безопасности потерпела неудачу в Комплекте 7, но если бы этому комплект
было дано UlPermission, стек обхода прошел бы успешно, если не для Отрицания. Эт
означает, что Комплект 4 отменил UlPermission для Комплекта 5 и Комплекта 6.
Рис. А.14. Стек обхода замкнут (укорочен, упрощен) Отрицанием
s2
а |
go
il
II
|5
s
о
ё
Неудачно
[Method la
Assembly 1
Предоставленные 1
полномочия:
FilelOPermission
Method 2a
Assembly 2
Предоставленные
полномочия:
FilelOPermission
UlPermission
Method 3a
Assembly 3
Предоставленные
полномочия:
FilelOPermission
UlPermission
► J
UlPermission
(8А,0епу)
Успешно 1
1 Method 4a
Assembly 4
^>-
Предоставленные 1
полномочия:
FilelOPermission
UlPermission 1
Method 5a
Assembly 5
Предоставленные
полномочия:
FilelOPermission
UlPermission
UlPermission
(SecurityAction.Demand)
Method 6a
Assembly 6
Предоставленные
полномочия:
FilelOPermission
UlPermission
g
о
о
7Г
О
3
о
00
Е
ы
о
00
о

Основные понятия .NET Security * Приложение А
Можно установить Отрицание, используя как декларативный, так и
императивный синтаксис. В первом примере использовался декларативный синтаксис.
Отрицаниеустановлено на FilelOPermission для всех файлов на C:\Winnt\System32 каталога
на рис. А. 15 и А. 16.
рис. А.15. Установка Отрицания: С#
[FilelOPermission (SecurityAction.Deny, All = @ «C:\Winnt\ System32\. «) ]
public in Act 1 ()
{
return 1;
}
int Actl ()
{
FilelOPermission ActFileOerm = new
FilelOPermission (FilelOPermissionAccess, @ «C: \Winnt\
System32\.");
ActFilePerm.Deny ();
return 1;
}
Рис. А.16. Установка Отрицания: VB.NET
Public Function _
<FileIOPermission (SecurityAction.Deny, All := «C:\Winnt\Sysytem32\
* *"\ >
Actl () As Integer
1 body of the function
End Function
Второй пример использует императивный синтаксис, устанавливая тот же
самый тип Утверждения:
Public Function Actl ( ) As Integer
Dim ActFilePerm As new
FilelOPermissionAccess.AllAccess, _
«C: \Winnt\System32\*. * ")
ActFilePerm.Deny
'rest of the body
End Function

Приложение А • Основные понятия .NET Security
Отмена Разрешить Только
Отмена Разрешить Только похожа на отрицание Отрицания, отклоняя все
полномочия, кроме одного заданного. Разрешить Только используется по тем же
причинам, что и Отрицание, но Разрешить Только более точное. Например, если вы
допускаете только полномочия UlPermission, все стеки обхода потерпят неудачу, кроме
одного, проверяющего UlPermission.
Например, на рис. А 14. замените Отрицание на Разрешить Только. Если в
Комплекте 6 инициирована проверка безопасности на UlPermission, стек обхода пройдет
Комплект 4 успешно, но, в конечном итоге, потерпит неудачу в Комплекте 1. Если
инициирована какая-либо другая проверка безопасности, она потерпит неудачу в
Комплекте. В результате, Комплект 5 и Комплект 6 отклонили любой доступ к
защищенным источникам, которые взаимодействуют с запросом Требования, потому
что все проверки безопасности потерпят неудачу.
Как можно видеть, Разрешить Только — это очень эффективный способ
избавления от любых стремлений вызванного кода получить доступ к защищенным
источникам и используется так же как Отрицание и Утверждение.
Собственные полномочия
.NET Framework позволяет вам писать ваш собственный код полномочий
доступа, даже, не смотря на то, что инфраструктура обеспечена большим количеством
классов полномочий доступа. Поскольку эти классы подразумевают защиту
источников и кода, которые раскрываются инфраструктурой, может возникнуть случай,
когда приложение, которое вы разрабатываете, имеет определенные источники,
не защищенные полномочиями инфраструктуры, или можно захотеть
использовать полномочия, более приближенные к потребностям вашего приложения.
Вы обладаете полной свободой в замене существующих классов полномочии,
хотя, чтобы сделать это нужно иметь достаточно знаний и опыта. В случае если вы
просто добавляете новый класс полномочий к уже существующим, вы должны
быть особенно внимательны, чтобы не допустить накладывания полномочий одно
на другое. Если один и тот же источник или операцию защищают более одного
полномочия, администратор должен иметь это в виду, если ему приходится
изменять права доступа к этим источникам.
Примечание
Вопрос накладывания полномочий поднимает новую тему. Не смотря на то, чт
обсуждение полномочий доступа к коду полностью рассматривалось с точки
зрения CLR или .NET инфраструктуры, в конечном итоге, CLR должен давать прав
доступа к источникам в интересах пользователей или приложения. Даже если к
ду были предоставлены особые полномочия доступа к защищенным источника *

Основные понятия .NET Security • Приложение А
это вовсе не означает, что ему разрешено получать доступ к источнику этой
системы. Рассмотрите пример метода, обладающего FilelOermissions полномочиями
в каталоге C:\Winnt\Sysytem32. Если идентичности принципала Windows не
было дано прав доступа к этой части файловой системы, получение доступа к файлу
этого каталога будет неудачным в любом случае. Это означает, что
администратор должен не только установить полномочия в методике защиты, но также
настроить платформу Windows 2000 на отражение этих полномочий доступа.
Построение ваших собственных полномочий не только предполагает
возникновения некоторых вопросов развития, но даже более того, должна быть
обсуждена целостность всей системы безопасности. Вам нужно принимать во внимание,
что вы добавляете полномочия к жестко заданной системе безопасности, которая
во многом полагается на доверие и полномочия. Если по разработке и/или
внедрению полномочия возникает ошибка, вы рискуете создать бреши в безопасности,
которые могут стать мишенью для атак или позволить приложению дать право
доступа к защищенным источникам, тем, кто не авторизован на получение этого
доступа. Обсуждение процесса разработки ваших собственных полномочий не
входит в рамки данного приложения. Однако следующие шаги помогут вам понять
процесс создания собственных полномочий:
1. Разработайте класс полномочий.
2. Определите границы IPermission и IUnstrictedPermission.
3. В случае необходимости поддержки специальных типов данных, нужно раз
работать интерфейс ISerializdble.
4. Нужно реализовать Securing XML и расшифровывание.
5. Нужно реализовать поддержку для декларативной безопасности.
6. Добавить вызовы Требования для собственных полномочий в вашем коде.
7. Обновите методику обеспечения безопасности так, чтобы собственные
полномочия могли быть добавлены к набору полномочий.
Ролевая безопасность
Ролевая безопасность не является новинкой для .NET Framework. Если у вас уже
есть опыт разработки компонентов СОМ+, вы наверняка, уже сталкивались с роле-

Приложение А * Основные понятия .NET Security
вым доступом безопасности. Концепция ролевой безопасности для приложени"
СОМ+ та же самая, что и для .NET Framework. Разница заключается в способе
внедрения безопасности.
Говоря о ролевой безопасности, мы повторно используем тот же пример. Это
происходит не, потому что мы не может создать свой собственный пример, а
потому что он объясняет ролевую безопасность общедоступным методом. Вот этот
пример: Вы создали финансовое приложение, которое может обрабатывать
депозитные транзакции. По правилам большинства банков, банковский автомат
авторизован на выполнение транзакций до определенной суммы — скажем, $5,000. Если
транзакция превышает этот предел, управляющий банковским автоматом должен сам
выполнить её. Но так как управляющий банковским автоматом авторизован,
проводить транзакции максимум с $10,000, для проведения транзакций с большей суммой,
должен быть вызван управляющий филиалом.
Следовательно, проведя аналогию, ролевая безопасность имеет дело с
ограничением заданий, которые может выполнить пользователь, основываясь на роли (или
ролях), которые играет пользователь и его идентичности. В .NET Framework все это
сводится к принципалу, который вмещает в себя идентичность и роль (и)
вызывающей программы. Как уже обсуждалось ранее в данной главе, каждая цепочка
выполняемых задач обеспечена основным объектом. Чтобы .NET Framework
обрабатывала неролевую безопасность так же, как это делает код безопасности доступа, мы
установили класс полномочий PrincipalPermission.Bo избежание недоразумений, надо
сказать, что PrincipalPermission не является извлеченным из CodeAccessPermisssion
классом. Фактически, PrincipalPermission содержит в себе только три свойства:
Пользователь, Роль и рулевое выражение Аутентифицирован.
Principal
Давайте вернемся к тому, с чего все началось: к основам. С момента
инициализации домена приложения, был создан контекст вызова по умолчанию, в котором
будет обнаружен принципал. Если будет активирована новая цепочка операций,
контекст вызова и принципал перекодируются из порождающей цепочки
выполняемых задач в новую. Вместе с объектом Principal, также перекодируется и объект
Identity. Если CLR не может определить принципала цепочки выполняемых ко
манд, по умолчанию создаются объекты Principal и Idenity так, что цепочка
выполняемых команд может выполняться, по крайней мере, в безопасном контексте с
минимумом прав. Существуют три типа принципалов: Windows Principal»
GenericPrincipal (Общий) и CustomPrincipal (Собственный). Последний не входит
в рамки этого приложения, и мы не будем рассматривать его. Остановимся более
подробно на первых двух.

Основные понятия .NET Security • Приложение А
Windows Principal
Поскольку WindowsPrincipal, который ссылается на Windowsldentuty, имеет
непосредственное отношение к пользователю Windows, этот тип идентификации может
считаться очень надежным, из-за независимого источника аутентификации
пользователя.
Чтобы выполнять ролевую проверку достоверности, нужно создать объект
WindowsPrincipal В случае Windows Principal, этот процесс достаточно прямой, и в
действительности, существует два способа его внедрения. Выбор способа будет
зависеть от того, хотите ли вы провести однократную проверку достоверности
пользователя и роли (или ролей), или вы будете проводить её регулярно. Рассмотрим
сначала метод для однократной проверки достоверности:
1. Инициализируйте копию объекта Windowsldentity при помощи этого кода:
С#: Windowsldentity Winldent = Windowsldentity.GetCurrent ( );
VB.NET: Dim Winldent as Windowsldentity =
Windowsldentity.GetCurrent ( )
2. Создайте копию объекта ШпаЪтРппсгрЫи привяжите к нему Windowsldentity.
С#: WindowsPrincipal WinPrinc = new WindowsPrincipal (Winldent);
VB.NET: Dim WinPrinc as New WindowsPrincipal (Winldent)
3. Теперь можно получить доступ к свойствам объектов Windowsldentity и
WindowsPrincipal:
С#: string PrincName = winPrinc.Identity.Name;
C#: string Odentname = Winldent.Name; //this is the same as the
previous line
C#: string Identtype = Winldent.Authenticationtype;
VB.NET: Dim princName As String = WinPrinc.Identity.name
VB.NET: Dim Identname As String = Winldent.Name 'this is the dame
as
VB.NET: the previous line
VB.NET: Dim IdentType As String = Winldent.AuthenticationType
Если нужно проводить проверку достоверности регулярно, привязка
WindowsPrincipal к цепочки выполняемых операций более эффективна, так что
Информация легко доступна. В предыдущем примере, вы не привязывали
WindowsPrincipal к цепочке выполняемых операций, потому что предполагалось

Приложение А * Основные понятия .NET Security
использовать его только один раз. Однако имеет смысл всегда проводить при
вязку.
WindowsPrincipal к цепочке выполняемых операций; в этом случае, при создали
новой цепочки, принципал также копируется в неё:
1. Создайте методику принципала, основываясь на Windows Principal и привя
жите её к текущей цепочки выполняемых операций. Это инициализирует
копию объекта Windowsldentity, создаст копию объекта WindowsPrincipal, при
вяжет к нему Windows Identity, а затем привяжет WindowsPrincipal к текущей це
почки выполняемых операций. Это все выражается в одном утверждении:
С#:
AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.WindowsPr
incipal);
VB.NET: AppDomain.CurrentDomain.SetPrincipalpolicy (PribcipalPolicy.
WindowsPrincipal)
2. Получите копию объекта WindowsPrincipal, привязанного к цепочке
выполняемых операций:
С#: Windowsprincipal WinPrinc = (WindowsPrincipal)
Thread.CurrentPrincipla;
VB.NET: Dim WinPrinc As WindowsPrincipal =
Ctype (Thread.CurrentPrincipal, _
WindowsPrincipal)
В первом методе создания, возможно, привязать WindowsPrincipal к цепочке
выполняемых операций. Однако, для этого, ваш код должен получить полномочия
SecurityPermission. При наличии таких полномочий, вы привязываете принципал к
цепочке последовательных операций следующим образом:
С#: Thread.CurrentPrincipal = WinPrinc;
VB.NET: Thread.CurrentPrincipal = WinPrinc
GenericPrincipal
В случаях, когда вы не хотите полагаться на Windows аутентификацию, но хот
те, чтобы приложение взяло это на себя, можно использовать GenericPnncipaL

Основные понятия .NET Security • Приложение А
примечание
Всегда используйте метод аутентификации, перед тем как предоставить
пользователю право доступа к вашему приложению. Аутентификация, в любой её
форме, единственный способ установки идентичности. Не применяя её, вы не
сможете реализовать ролевую безопасность.
Предположим ваше приложение запрашивает от пользователя имя и пароль,
проверяет их в базе данных аутентификации приложения и устанавливает
идентичность пользователя. Затем вам необходимо создать GenericPrincipal для проведения
ролевых проверок в вашем приложении:
1. Создайте объект Genericldentity для Пользователя 1> которого вы только, что ау
тентифицировали;
С#: Genericldentity Genldent = new Genericldentity ("Userl");
VB.NET: Dim Genldent As New Genericldentity ("Userl")
2. Создайте объект Genericprincipal, привяжите к нему Genericldentity и добавьте
роли к generic Principal:
С#: string [ ] UserRoles = {"Rolel", «Role2", «Role5"};
C#: GenericPrincipal GenPrinc = new GenericPrincipal (Genldent,
UserRoles);
VB.NET: Dim UserRoles as String ( ) ={"Rolel", «Role2", «Role5"}
VB.NET: Dim GenPrinc As New GenericPrinipal (Genldent, UserRoles)
3. Привяжите GenericPrincipal к цепочке выполняемых операций. И снова,
вам понадобится SecurityPermission:
С#: Thread.CurrentPrincipal = genPrinc;
VB.NET: Thread.CurrentPrincipal = GenPrinc
Манипулирование идентичностью
Можно манипулировать идентичностью, содержащейся в объекте принципал,
Двумя способами. Первый — это замещение принципала; второй — при помощи им-
Персонизации идентичности.
Замещение основного объекта в цепочке выполняемых операций — типичное
Действие, которое вы выполняете в приложениях, имеющих собственные методы

Приложение А - Основные понятия .NET Security
аутентификации. Для того чтобы заменить принципал, ваш код должен получить
SecuntyPermission или, чтобы быть более точным, свойство SecurityPermission
ControlPrincipal Это позволит вашему коду передавать PrincipalObject другим кодам
Это свойство дает вам полномочия манипулировать принципалом, таким образом
CLR позволяет вам передавать принципал. Можно заменить объект Principal,
выполнив следующие два шага:
1. Создайте новую идентичность и объект Principal и инициализируйте его с со
ответствующими значениями.
2. Привяжите новый принципал к цепочке выполняемых действий:
С#: Thread.CurrentPrincipal = NewPrincipalObgect;
VB.NET: Thread.CurrentPrincipal = NewPrincipalObject
Имперсонизация также является способом манипулирования принципалом, с
намерением приобретения других пользовательских идентичностей пользователя
для выполнения некоторых действий от имени пользователя. Можно
идентифицировать два варианта:
■ Код должен имперсонизировать WindowsPrincipal, приложенный к цепочке
выполняемых операций. Это может показаться несколько странным, но
нужно помнить, что ваш код является частью прикладной области, которая
выполняется в процессе. Пользователь — будь то система аккаунта, сервис
аккаунта или даже интерактивный пользователь — начинает этот процесс
на платформе Windows. Хотя принципал может использоваться для
выполнения ролевого контроля в коде, получение доступа к защищенным
источникам все равно происходит с идентичностью пользователя, до тех пор,
пока вы активно используете пользовательский аккаунта принципала через
имперсонизацию.
■ Код должен проводить имперсонизацию пользователя, который не
прикреплен к текущей цепочке выполняемых операций. Первое, что нужно
сделать, — это получить маркер Windows пользователя, которого вы
хотите имперсонизировать. Это должно быть сделано с неуправляемым ко
дом LogonUser. Полученный маркер должен быть передан на объек
Windowldentity. Теперь вы должны вызвать метод Impersonate в Windowsldennn-
Старая идентичность — следовательно, и маркер — должны быть сохранен
в новой копии WindowsImpersonationContext.

Основные понятия .NET Security • Приложение А
В конце процесса имперсонизации нужно вернуться к аккаунту оригинального
пользователя, вызвав метод Undo в WindoxvsImpersonationContext
Помните, что объект Principal не изменен; наоборот, маркер Windowsldentuty,
представляющий аккаунт Windows, переключен текущим маркером. В конце
имперсонизации маркеры переключаются обратно, как показано ниже:
1. Вызовите метод LogonUser, находящийся в библиотеке неуправляемого кода
advapi32.dll. Вы передаете логин, домен, пароль, тип регистрации и провайдера
регистрации на этот метод, который вернет обработку маркеру. На нашем примере,
мы можем назвать его МтрТокеп.
2. Создайте новый объект Windowsldentity и передайте его на дескриптор маркера:
С#: Windowsldentity Impersldent = new windowsldentity (hlmpToken);
VB.NET: Dim Impersldent As New Windowsldentity (hlmpToken)
3. Создайте объект WindowsImpersoniationContext и вызовите метод Impersonate из
Imperslndent
С#: WindowsImpersonationContext WinlmpersCtxt =
Imperslndent.Impersonate ();
VB.NET: Dim WinlmpersCtxt As WindowsImpersonationContext =
ImpersIdent.Impersonate ()
4. В конце вызова, оригинальный маркер Windows должен быть возвращен в
объект Identity:
С#: WinlmpersCtxt.Undo ();
VB.NET: WinlmpersCtxt.Undo ()
Пункты 2 и 3 можно выполнить в одном утверждении, которое будет выглядеть
следующим образом:
Dim WinlmpersCtct As WindowsImpersonationContext = _
Windowsldentity.Impersonate (hlmptoken)
Помните, что вы не можете проводить имперсонанизацию при использовании
GenericPrincipaly потому что он не ссылается на идентичность Windows. Для общих
принципалов вам необходимо заменить принципал на тот, который имеет новую
Идентичность.

[ Приложение А * Основные понятия .NET Security
Ролевая проверка безопасности
Теперь, когда мы обсудили методы создания и манипулирования PrincipalObject
самое время взглянуть на то, как это может помочь вам в ролевой проверке
безопасности. Именно здесь начинается применение, упомянутого в начале раздела
«Ролевая безопасность», PrincipalPermission. Используя PnncipalPermission, можно проводить
проверки активного объекта Principal, Windows Principal ли это или GenericPrincipal
Активный объект Principal может быть тем, что вы создали для однократной проверки
или принципалом, который вы привязали к цепочки выполняемых действий. Также
как полномочия доступа к коду, PrincipalPermission может использоваться
декларативным и императивным методом.
Для использования PrincipalPermission декларативным способом, вам необходимо
использовать объект PrintipaWermissionAttribute, как показано на рис. А. 17. и А. 18.
Рис. А.17. Использование PrincipalPermissionAttribute: C#
[PrincipalPermissionAttribute (securityAction.Demand, Name = «Userl", Role =
"Role")]
public int Act2 ()
{
return 1;
}
[assembly:PrincipalPermissionAttribute (SecurityAction.Demand, Role =
"Administrator") ]
Рис. А.18. Использование PrincipalPermissionAttribute: VB.NET
Public Shared Function _
PrincipalPermissionAttribute (SecurityAction.Demand, _
Name := «Userl", Role := «Rolel") > Act 2 () As Integer
' body of the function
End Function
<assembly: PrincipalPermissionAttribute (securityAction.Demand, Role :-
1 Administrator ' )>
Для использования императивного метода можно выполнять проверку
PnncipalPermision, как показано на рис. А. 19. и А.20.

Основные понятия .NET Security • Приложение А
Рис. А.19. Использование PrincipalPermission: C#
Principalpermission Princperm = new PrincipalPermission ("Userl", «Rolel");
PrincPerm.Demand ();
Рис. А.20. Использование PrincipalPermission: VB.NET
Dim PrincPerm As New PrincipalPermission ("Userl", «Rolel")
PrincPerm.Demand ()
Также возможно использовать императив для установки объекта PrincipalPermission
двумя разными способами, как показано на рис. А.21. и А.22.
Рис. А.21. С#
PrincipalPermission PrincPerm = new
Principalpermission (PermissionState.Unrestricted);
Рис. А.22. VB.NET
Dim PrincState As PermissionState = Unrestricted
Dim PrincPerm As New PrincipalPermission (PrincState)
Состояние полномочий (PrincState) может быть None или Unrestricted
(Неограниченное), где None означает, что принципал не аутентифицирован. Следовательно,
логин будет Nothing (Ничего), роль Nothing, и Аутентифицирован — ложным.
Unrestricted подходят ко всем другим принципалам.
Рис. А.23. С#
bool PrincAuthenticated = true;
PrincipalPermission PrincPerm = new PrincipalPermision ("Userl", «Rolel",
PrincAuthenticated);

Приложение А • Основные понятия .NET Security
Рис. А.24. VB.NET
Dim PrincAuthenticated As Boolean — True
Dim PrincPerm As New PrincipalPermission ("Userl", «Rolel",
PrincAuthenticated)
Поле IsAuthenticated (Аутентифицирован) может быть истинным или ложным.
В ситуациях, когда вы хотите позволить PrincipalPermission.demand () более
чем одну комбинацию пользователь/роль, можно объединить два объекта
PrincipalPermission. Таким образом, если один объект PrincipalPermission имеет набор
пользователь/роль, а другой объект использует Permission State (Состояние
полномочий), CLR создает исключительную ситуацию. Это объединение выглядит, как
показано на рис. А.25. и А.26.
Рис. А.25. С#
PrincipalPermission PrincPerml = new PrincipalPermission ("Userl", «Rolel");
PrincipalPermission PrincPerm2 = new PrincipalPermission ("User2"/ «Role2");
PrincPerm. Union (PrincPerm2) . Demand ();
Рис. A.26. VB.NET
Dim PrincPerml As New PrincipalPermission ("Userl", «Rolel")
DimPrincPerm2 As New Principal Permission ("User2"# «Role2")
PrincPerml.Union (PrincPerm2).Demand ()
Требование будет успешным, если основной объект имеет пользователя
Пользователь 1 в роли Роль 1 и Пользователя 2 в роли Роль 2. Все остальные комбинации будут
неудачными.
Как мы уже упоминали, можно напрямую получить доступ к объектам Principal и
Identity, и таким образом, позволяя вам выполнять ваши собственные проверки
безопасности без использования PrincipalPermission. Кроме того, что вы сможете
проверять немного больше информации, это решение также предотвратит вас от
обработки возможных исключений, используя PrincipalPermission. Вы можете запросить
WindoxvsPrincipal тем же способом, как это делает PrincipalPermission:
■ Логин, проверяя значение
WindowsPrincipal.Identity.Name.

Основные понятия .NET Security * Приложение А
[
С#: if (WinPrinc.Identity.Name = = «Userl" ||
C#: WinPrinc. Identity.Name.Equals ("DOMAINlWYserl") )
C#: {
C# }
VB.NET: If (WinPrinc.Identity.Name = «Userl") or _
VB.NET: WinPrinc.Identity.Name.Equals ("DOMAINl\Userl") Then
VB.NET: End if
■ Доступную роль, вызывая метод IdlnRole.
С#: if (WinPrinc.IsInRole ("Rolel"))
C#: {
C#: }
VB.NET: If (WinPrinc.IsInRole ("Rolel")) Then
VB.NET End if
■ Определение, авторизован ли принципал, проверяя значение
WindowsPrincipaLIdentityJsAuthenticated:
С#: if (WinPrinc.Identity.IsAuthenticated)
C#: {
C#: }
VB.NET: If (WinPrinc.Identity.IsAuthenticated) Then
VB.NET: End If
Можно проверить следующие свойства Windowsldentity:
■ Тип Аутентификации Определяет тип используемой аутентификации.
Наиболее распространенные значения NTML и Kerberos.
■ IsAnonymous (Анонимный) Определяет, идентифицирован ли пользователь
системой как анонимный аккаунт.
■ IsGuest (Гость) Определяет, идентифицирован ли пользователь системой
как гостевой аккаунт.
■ IsSystem Определяет, идентифицирован ли пользователь как обладатель ак-
каунта в системе.
■ Маркер Возвращает Windows маркер аккаунта пользователя.

Приложение А • Основные понятия .NET Security
Способы защиты
Этот раздел представляет более близкое рассмотрение методов построения
защиты, а также способов управления ими. Чтобы создать и модифицировать методы
защиты, .NET Framework предлагает два инструмента: интерфейс командной
строки (CLI), вызванный caspol.exe (см. Раздел «Инструменты безопасности»), и
Операторский пульт управления Microsoft snap-in, mcscorcfg.msc (см. Рис. 27). Последний
мы используем для демонстрации, поскольку он более наглядный и понятный.
Рис. А.27. Net конфигурация Snap-in
&h4L >
The wizards and task links below will help you
set and distnbute security policy. For
complete control of secunty policy use the
tree views under this node
Console 1 (Console Hoot\ NE1 Configuialion\My Computet \Runt Security Pobcy| О
*Ь ' № 0 m я ! *
Console Root
NET Configuration
Щ My Computer
A**«nbfc< Cache
j£ G**gued Assemble*
gwp Remobng Service*
Enterprise
с Code Groups
^ AI_Code
3} PemwsionSets
Poicy Assemble*
(^ Млспив
t Code Groups
Реотпвгюп Sets
Poky Assembles
Ёг-ff U
+_ -^ Code Group*
Permission Sets
.$jj Pokey Assemble*
^ AppScabore
Use the Trust an Application or Assembly wizard
to Increase the level of (rust granted to a
particular assembly This wizard modifies
security policy based on information about the
evidence of the assembly selected
Adjust Zone Security
Use «he Security Adjustment Wizard to modify
the level of trust granted to all assemblies
coming from a particular zone such as Internet,
Local Intranet or My Computer.
EtfatUfltB Assembly
Use the Evaluate an Assembly wizard to
evaluate what permissions or code groups apply
to a particular assembly This в useful n
щее:
Как можно видеть на рис. А.27., методика безопасности включает в себя следую-
Уровни защиты безопасности
■ Корпорация Действительна для управляемых кодов, используемых в
организации (корпорации); следовательно, она «по природе» будет
иметь ограниченную стратегию, потому что относится к большой груп
пе кода.
Компьютер Действителен для всех управляемых кодов на этом
определенном компьютере. Поскольку это уже ограничивает количество ко
дов, можно быть более точными с обработкой наших разрешений.

Основные понятия .NET Security * Приложение А
■ Пользователь Действителен для всех управляемых кодов, которые вы
полняются под этим пользователем Windows. Это обычно будет аккаун
том, который начинает процесс, в котором выполняются CLR и
управляемый код. Так как идентичность пользователя очень
специфична, присвоенные полномочия также могут быть очень
специфическими, и, таким образом, менее ограниченными.
■ Иерархия кода групп, которая существует для каждого из трех уровней
метода. Мы остановимся на рассмотрении метода добавления кода групп в
структуру по умолчанию, которая уже существует для пользователя и
компьютера.
■ (Именованные) наборы полномочий. По умолчанию .NET Framework
устанавливается с семью наборами полномочий:
■ Полное доверие неограниченный доступ ко всем защищенным источни
кам и операциям.
■ Все Устанавливает все полномочия .NET Framework, за исключением
полномочий безопасности SkipVerification (Проверка обхода).
■ Локальный интранет Права по умолчанию, данные приложению в ло
кальном интранете.
■ Интернет Права, данные приложению по умолчанию в Интернете.
■ Выполнение Обладает только полномочием безопасности EnableAssem
blyExecution.
■ Проверка обхода Обладает только полномочием безопасности SkipVenJwatixm.
■ Ничего Отклоняет все попытки доступа ко всем защищенным источни
кам и операциям.
■ Основание, которое является атрибутом, который код передает CLR и по
которому он определяет эффективный набор полномочий. Основание
используется в построении кода групп.
■ Методика ассемблирования, которая составляет перечень достоверных
компоновочных узлов, используемых по время оценки методики. Нужно
добавить свои компоновочные узлы в перечень, который устанавливает

Приложение А • Основные понятия .NET Security
собственные полномочия. Если вы опустите этот этап, компоновочные
узлы не будут полностью достоверными и не смогут использоваться во время
оценки метода защиты.
Нужно понимать, что процесс оценки метода защиты будет влиять на
эффективный набор полномочий для специального компоновочного узла. Для всех трех
уровней метода, группы кода оцениваются против основания, представленного
компоновочным узлом. Все группы кода, которые встречают основание,
доставляют набор полномочий. Объединение этих наборов, определяет эффективность
набора полномочий для этого конкретного уровня метода защиты. После
проведения этой оценки на всех трех уровнях, три индивидуальных набора полномочий
пересекаются, образуя эффективный набор полномочий для компоновочного
узла. Это означает, что группы кодов трех уровней защиты, не могут
образовываться независимо, потому что это может привести к ситуации, в которой
компоновочному узлу будет дан ограниченный набор полномочий, который будет слишком
ограниченным для выполнения. Просмотрев набор полномочий для AlljCode
методики безопасности корпорации, вы заметите, что она относится к группе Полное
доверие. Просмотрев то же самое для All_Code методики защиты пользователя, вы
увидите Ничего.
Поскольку древовидная схема кода группы корпорации пуста, она не может
принимать решения основания; следовательно, не может принимать участия в
определении эффективного набора полномочий для компоновочного узла.
Установив его на Полное Доверие, вы утверждаете, что установка эффективного набора
полномочий зависит от методов защиты компьютера и пользователей.
Поскольку код группы уже имеет ограниченную древовидную схему, участие
корня в определении набора полномочий не обязательно. Установив его на
Ничего, принятие решения по эффективности полномочий группы для метода защиты
пользователя, зависит от кода остальных групп.
Можно определить набор полномочий кода группы, выполнив следующее:
1. Запустить Консоль Управления Microsoft, выбрав Start | Run и набрав
mmc.
2. Открыть snap-in Управления .NET, через Консоль | Добавить/удалить.
3. Расширить корень Консоля| Конфигурация .NET| Мой компьютер.
4. Расширить Методы безопасности Корпорация | Код групп.
5. Выбрать код группы All_Codeni
6. Щелкнуть правой кнопкой мыши на All_Code и выбрать Properties.
7. Выбрать ярлык Permission Set.
8. Поле Permission Set вносит в список текущее значение.

Основные понятия .NET Security • Приложение А
Создание нового набора полномочий
Предположим, что вы решили ни один из предложенных семи встроенных
наборов полномочий не отвечает вашим потребностям для установки полномочий.
Следовательно, вы хотите создать именной набор полномочий, который вас
устроит. У вас есть выбор:
■ Создать полномочия из начальной позиции
■ Создать новый набор полномочий, основываясь на уже существующем
■ Создать новый набор закодированных полномочий XML
Чтобы дать вам лучшее понимание работы методов безопасности и некоторых
практических навыков применения инструментов, мы обсудим различные
проблемы методов защиты в следующих упражнениях.
Мы воспользуемся вторым вариантом выбора и положим в основу нашего
нового набора инструментов Локальной интранет для уровня метода защиты
пользователя:
1. Расширим методы защиты Пользователя и Набор полномочий (см. Рис А.28.).
Рис. А.28. Наборы полномочий пользователя и код групп
im Consolel - [Console Root\ NET Conhgurahon\My Computei\Runt me Security Policy\U i 'KPerrmssi
gj £orrtefe Window ЛФ
&*** W&# £evoate* Ф» © Ш
(favorites |
- ff Usei"
В Code Groups
^ Al.Code
E ^ Wcard_Mad*ne_Poicy
Й ^ My_Computer_Zone
<> NetCodeGroup.O
<> FieCodeGroupJ)
E Ч> Localntranet_Zone
Гф ф lntemet_Zone
^ Trusted_Zone
^ Restncted__Zone
£ Permission Sets
FuFrust
^ SkpVerificabon
j%\ Execution
^J Internet
jm Eveiythng
^jf) Copy of LocaHntranet
^ Pokey Assembles
0
^ - Ш g
p
j^ Environment Variables
Й Fie Dialog
;§ Isolated Storage Fie
^Reflection
M Security
2) User Interface
i|DNS
JjPririting
j?) Event Log

Приложение А * Основные понятия .NET Security
2. Щелкнем правой кнопкой мыши на набор полномочий Локальная интпа
нет и выберем Дублировать; набор полномочий под названием Copy of
Locallntranet добавляется в список.
3. Выберем набор полномочий Копия локального интранета и переимену
ем в Личные Полномочия. Затем щелкнем правой кнопкой мыши и
изменим соответствующее описание набора полномочий.
4. Изменим полномочия на наборе полномочий: щелкнем правой кнопкой
мыши на Личные Полномочия в наборе полномочий и выберем
Изменить Полномочия.
5. Появится диалоговое окно Создать Набор Полномочий (см. рис. А.29.).
Вы увидите два списка полномочий: слева неприсвоенные Доступные
Полномочия, а справа перечень с присвоенными полномочиями.
Рис. А.29. Изменение набора полномочий при помощи
диалогового окна Создания Набора Полномочий
Create Permission Set
Assign Individual Permissions to Permission Set
Each permission set is a cotection of many different permissions to va юи$
resources on the computer Select the permissions that you would fkc to
have in this mission set
Directory Services
ptelO
essage Queue
L£DB
rformance Counter
try
vice Controller
icket Access
3L Client
eb Access
fjropertifts
Г ivtronment Variables
Dialog
Isolated Storage File
I election
curfty
i Interface
I *JS
I ntmg
I entLog
IfSpOrt
..I
Cancel
Между двумя списками находятся четыре кнопки. Кнопки Добавить и Удалит!
позволяют перемещать индивидуальные полномочия между списками. Заметьте
чтобы защититься от ошибок, нельзя выбрать более одной кнопки одновременно
Вы лучше поймете данные полномочия, если выберете это полномочие в списка
Присвоенных Полномочий и нажмете кнопку Свойства. Можно использовать чет
вертую кнопку (Import) для загрузки XML-закодированного набора полномочий-

Основные понятия .NET Security • Приложение А 4
Теперь проведем некоторые изменения в наборе полномочий, так как именно
для этого мы делали дубликат набора полномочий:
■ Добавьте FilelOPermission в список Присвоенных Полномочий.
■ Добавьте RegistryPermission в список Присвоенных Полномочий.
■ Модифицируйте свойства SecurityPermission.
Для этого:
1. Выберите FilelO в списке Доступных Полномочий. (Заметьте, что если вы
выбрали полномочие в списке Присвоенных полномочий, это
полномочие остается выбранным).
2. Щелкните на Добавить. Появится Диалоговое Окно Установки
Полномочий для FilelO (см. Рис. А.30.). (Можно также дважды щелкнуть на
полномочие, чтобы добавить его в список Присвоенных Полномочий). Однако не
щелкните, случайно, дважды на присвоенном полномочии - это удалит
полномочие из списка присвоенных полномочий.
Рис. А.30. Изменение установки FilelO при помощи Диалогового
Окна Установки Полномочий
Permission Settings
'*? Btm "шттгШ$ access to the fobwmg Шт Ш dsectone
*jpafc
//hosn/c/Test/"cfg
Read *
F
г
file
F
г
Append
p
г
PathOi^
•■ F
f
Srant assemble- $#*е?*нс ed «ccs* the Ш v <1wn
Ok | £«*cef

Приложение А • Основные понятия .NET Security
3. Как вы уже видели ранее в этом приложении, этот процесс напоминает
способ использования FilelOPermission и FiklOPermissionAttribute для требования
и запроса права доступа к специальным файлам в специальном каталоге.
Продолжайте и заполните C:\Test\*.cfg. Удивлены получением сообщения об
ошибке? Дело в том, что поле требует, чтобы вы использовали УСИ
(Универсальное соглашение об именовании) имена. Преимущество этого в том, что
можно ссылаться на файлы, находящиеся на других серверах в домене. Однако
диалоговое окно проверяет существование пути при нажатии вами ОК,
поэтому убедитесь, что УСИ путь существует.
4. Заполните Путь Файла действительным УСИ компьютера, на котором вы
работаете, и, так как мы хотим предоставить полный доступ, можно выбрать
все четыре блока. Примечание: Если вы не проверяете хотя бы один их этих
блоков, он будет принят, потому что вы заполнили в Пути Файла. Однако если
вы проверяете свойства FilelO как присвоенного полномочия, вы заметите,
что строка исчезла — следовательно, это бета ошибка!
5. Щелкните на ОК, и вы добавите полномочие в список Присвоенных
Полномочий. Теперь вы готовы к следующему полномочию.
6. Дважды щелкните на Registry полномочии, и появится диалоговое окно
Установки Полномочий, которое выглядит так же как то, что вы видели с
FilelO. Сохраняйте опцию Выдать право доступа компоновочным узлам для
следующих регистрационных ключей.
7. Заполните поле Ключ действительным значением HKEY, таким как
HKEY_LOCAL_MACHINE, и проверьте блок Читать так, чтобы мы могли дать
полномочия чтения специализированному дереву каталога.
8. Щелкните ОК, и вы добавите ваше второе полномочие к набору полномочий.
9. Последнее задание - это модифицировать полномочия безопасности.
Следовательно, выберите полномочия Безопасности в списке Присвоенных
Полномочий (не щелкните на нем дважды, постольку это вызовет удаление
полномочия из списка) и щелкните на Свойства.
10. Появится диалоговое окно Установки Полномочий (см. рис. А.31). Вы
видите, что выбрана опция Предоставление компоновочным узлам
следующих полномочий безопасности, а также её свойства. Разрешение
выполнения ассемблирования, Утвердить все предоставленные полномочия, и
Разрешить Удаленную конфигурацию.

Основные понятия .NET Security • Приложение А 4
Рис. А.31. Изменение Установок Безопасности, используя
Диалоговое окно Установок Полномочий
Permission Settings
F
sk
' г
г
ft
г .
Г1 '
'(?■£
w ca8s to urwnw^jed «$$ш*Ы(е$
arw &шяшэг* that has Ыт parted
^sihoateMt
#*#Мсо*Ш
p#jj»tos#^
ifpfB&R pcfey CCf&fil
fjgmapalcofl ol
$©&&йй*ог> loteatter
evidence contrd
J& tatctut
й#по&1§ cc^igiu^toti
OK ] gancdi [
11. Мы также хотим предоставить нашему методу безопасности свойства
полномочий безопасности. Проверьте Разрешить вызовы на неуправляемые
компоновочные узлы, поскольку мы хотим делать вызовы на неуправляемый код.
Также проверьте Разрешить основной контроль, поскольку мы хотим
модифицировать основные установки. Щелкните на ОК. На этом вы закончили
модификацию вашей первой установки полномочий.
12. Щелкните Закончить. Возможно, вы получите предупреждающее
сообщение о том, что вы произвели изменения и должны сохранить их. До тех пор,
пока вы не сохранили стратегию, звездочка (*) будет отмечать стратегию
пользователя.
13. Можно сохранить стратегию, щелкнув правой кнопкой мыши на стратегии
защиты Пользователя и выбрав Сохранить.
Если вы хотите, чтобы это установленное положение стало также частью
набора полномочий компьютера и/или корпорации, можно просто копировать и
вставить его.
Вы также заметите еще две опции: методы Сброс и Восстановление. Первый,
Сброс, возвращает метод обратно к установкам метода по умолчанию. Вы можете
попробовать воспользоваться им, но он сотрет все сделанные вами изменения.

Приложение А • Основные понятия .NET Security
Второй метод, Восстановление, дает возможность вернуться к предыдущим
сохранениям. Это становится возможным, потому что для каждого метода
безопасности, установки сохранены в XML-закодированном файле, который становится
текущим. Перед восстановлением система изменяет имена старых файлов, добавляя к
ним расширение .old. (старый). Метод по умолчанию расширений не имеет. Для
методов защиты пользователя, у вас есть следующие файлы:
■ security.config Безопасность по умолчанию используется Сбросом.
■ security.config.cch Текущий/активный метод.
■ security.config.old Последняя сохраненная версия метода используется ме
тодом Восстановление
Безопасность корпорации использует название enterprisesec.config, а компьютера
используют название security.config. Это возможно, поскольку метод защиты
пользователей сохранен на древовидной схеме каталога пользователей в следующей
папке: Document and Settings\User_Name\Application Data\Microsoft\CLR
Security config\vl.0.xxxx.
Методы защиты корпорации и компьютеров сохранены в следующем каталоге:
WINNT\Microsoft.NET\Framework\v.l.x.xxxx\CONFIG. CLR размещает этот
каталог через HiveKey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Catalog42\NetFrameworkvl\
MachinwConfigdirectory
Поскольку файлы конфигурации XML-закодированы, можно открыть и
проверить их web-обозревателем Интернет. Это даст вам дополнительное понимание
методов установки наборов полномочий.
Модификация структуры кода группы
Теперь, когда мы создали набор полномочий безопасности, целесообразно
начать его использование. Мы можем сделать это, прикрепив его к коду группы. Мы
модифицируем структуру кода группы метода защиты пользователя. По
умолчанию пользователь уже имеет основную структуру (см. Рис. А.32.)

Приложение А • Основные понятия .NET Security
рис. А.32. Структура кода группы, установленного по умолчанию
для методов защиты пользователя
Console I [Console RootA NET ConfiguidtionWy Computei\Runtune Secunly PohcyMJseiVCi • Giou.
H D В *Ш
" t *- m
Ш w4 Mechln „Sslicy Coil© Group
Description:
This code group was copied from the
J computer's machine policy level by a j
1 wizard. Please do not rename or 1
1 modify j
I Assembly evidence must match this j
j membership condition to belong to I
j the code group: All code j
j Assemblies matching the membership I
J condition are granted this permission
j set at the current policy level:
j Nothing.
1 Permission Set Description:
;| Denies all resources, including the
1 nght to execute
j Tasks
Несколько моментов могут, на первый взгляд, поразить вас:
■ Существует код группы под названием Wizard__Machine_Policy. Описание этой
группы говорит вам, что модуль оперативной помощи, называемый
Настройка модуля оперативной помощи безопасности, копирует эту группу из
стратегии компьютерного уровня и, что вы не должны модифицировать
его. Это не совсем так. На самом деле, если вы остановитесь на более
близком рассмотрении этих групп, вы увидите, что все группы,
заканчивающиеся на Zone, имеют полномочие, установленное на Ничего. Это означает, что
вы, пользователь, не можете использовать набор полномочий компьютера,
основанного на основании зоны. Однако если вы обладаете большими
полномочиями, основанными на основании зоны, это будет понижаться
(смягчаться) полномочиями компьютерной стратегии, основанной на зоне.
Пользователь может иметь полномочия, основанные на зонном
основании, которые равны или меньше чем основания, разрешенные
компьютером. Однако вы видите код групп, основанный на зоне на том же уровне,
что и Wizard_Machine_Policy1 потому что это коды групп, перекопированных
из компьютерной стратегии.
■ Код групп, основанный на зоне, содержит NetCodeGroup и FileCodeGroup. Как
утверждает описание, они образованны Инструментом Конфигурации
.NET; следовательно, инструментом, с которым мы работаем в настоящий
1* 1
User
Й ~' Code Group*
- <*> Al Cod*
-0- MiacKoft_Seong_Nam<
ECMA.StronfiLName
4> My_Computer_Zone
^ Localntranet_Zone
^ lnternet_Zone
^ Re*tncted_Zone
^ Tru*ted_Zone
- ф Localntranet_Zone
О NetCodeGroupJ
<> FileCodeGroupJ
б -0> lnternet_Zone
<> NetCodeGroupJ?
<► TrustecLZone
О NetCodeGroup_3
: ф RettnctedZone
ф My_Computer_Zone
-O NetCodeGroupJ)
-^ FleCodeGroupJ)

Приложение А - Основные понятия .NET Security
момент. Код группы, сделанный по заказу, основан на файлах XML-кода и
следовательно, инструмент не может редактировать их. Однако для этого
можно использовать инструмент caspol.exe. Не вдаваясь в подробности
относительно того, что влекут за собой эти группы, достаточно сказать, что
они необходимы вам для использования инструмента конфигурации .NET
Если вы не удалили или не модифицировали их, нужно оградить себя от
использования этого инструмента.
Давайте создадим небольшую структуру кода группы, которая будет состоять
из кода двух групп, непосредственно под группой All_Code и применим наш набор
полномочий, сделанный на заказ, PrivatePermissions к группе LocallntranetJLone.
1. Если у вас нет ММС с открытым snap-in .NET Management, откройте его
сейчас.
2. Расширьте дерево .NET Configuration! My Computer | Runtime Security
Policy | User.
3. Теперь расширьте Code Groups | All_Code.
4. Щелкните правой кнопкой мыши на All_Code и выберите New; появится
диалоговое окно создания кода группы.
5. У вас есть выбор: Создать новый код группы и импортировать код
группы из файла XML. Выберите первый вариант. {Примечание: для
NetCodeGroup и FileCodeGroup, используйте второй вариант).
6. Вы должны ввести что-нибудь в поле Имя. Для нашего примера, мы
выбрали ввод PrivateGroup_l. Теперь, щелкните Next.
7. Диалоговое окно покажет вам вторую страницу, называемую Choose a
condition Туре и имеющее только одно поле под названием Choose the
condition type fro this code group. Поле имеет спускающееся меню, содержащее
значения, из которых можно выбрать. Все они, за исключением первого и
последнего зависят от основания, (см. Рис. А.ЗЗ.).

Приложение А • Основные понятия .NET Security 4
Рис. А.ЗЗ. Выберите один из доступных типов условия для кода
группы
Cieate Code Gfoup
Choose a condition type
The membership condition determines whether or not an assembly meets
specific requirements to get the permissions associated with a code group.
Choose the condfeon for this code group
Site
Application Directory
Hash
Skip Verif ication
Strong Name
URL
Zone
<1 k fjext > С '/■;
8. Выберите Site из раскрывающегося меню. Появится новое поле под
названием Имя web-сайта и связанное с условием web-сайта. Продолжая наш пример,
мы выберем загрузку web-сайта MSDN Subscribers, поэтому введем значение
msdn.one.Microsoft.com в поле web-сайта.
9. Щелкните Next, и появится третья страница, под названием Присвоение
набора полномочий коду группы.
10. Можно выбрать между опциями Использовать существующий набор
полномочий и Создать новый набор полномочий. Поскольку web-сайт получен и
Интернета этот набор полномочий будет установлен.
11. Выберите значение Nothing из раскрывающегося меню (Примечание:
Набор полномочий, только что созданный нами, также является частью списка), и
щелкните на Next.
12. Щелкните на Finish, и создание вашего первого кода группы будет
завершено. Давайте попробуем создать второй код группы, который будет порожденным
кодом созданного нами кода группы.

Приложение А * Основные понятия .NET Security
13. Щелкните правой кнопкой мыши на код группы PrivateGroup_l и
выберите New.
14. Создайте новый код группы под названием PrivateGroup_2 и щелкните
Next.
15. Выберите пункт Publisher в меню, которое затем откроется. Ниже поля
появится новая таблица под названием Publisher Certificate Details. Ее следует
заполнить, импортировав сертификат. Это можно сделать, прочтение из
подписанной трансляции с языка ассемблера, используя пункт Import from
Signed File. (Обратите внимание, должна содержаться формулировка Import
from Signed Assembly). Эта операция очень проста.
16. Для решения задач, поставленных в данном примере, мы возьмем
сертификат с сайта msdn.one.microsoft.com (В этом случае, если вы забыли, как
это делается, посетите закрытый сайт, используя SSL следующим образом.
Кликните на иконку, показывающую, что этот сайт защищен, и сертификат
откроется. Зайдите в таблицу Details и нажмите кнопку Copy to File).
17. Нажмите кнопку Import from Certificate File, найдите файл сертификата
(файл с расширением хег) и откройте его. Вы увидите, что поля в сертификате
уже заполнены данными (см. Рис. А.34.).
Рис. А-34. Импортирование сертификата для Publisher Condition
в группе кода
Li ate Code Group
Choose a condition type
The membership condition determines whether or riot an assembly meets
spectfc relements to get the permissions associated with a code group.
aw .. .this
Publisher
Th*Pufeteherю *foe« andtt» и&тжь мш *so1g*
»gr^ ^ha certify* that rt^c^^ At«*№ble £bat
rseettb&iw lfeersNp v&he anted the решйзйи»
es^oqatedwi&t&saade oup*
Pubfeher certftc d*tals
Propert Value
erne C-US, S-Washington, L-Redmon
suer Name C-US, 0-"RSA Data Security, Inc.
Hash A61486B150270364D6537ADS315
Import! raSjgnedft . j SryortгггуяC, a&-. j
■*&** (" Efotf> ~~| Cancel

Приложение А • Основные понятия .NET Security
18. Нажмите Next.
19. Выберите существующее разрешение файлов типа Local Intranet. Мы
можем выбрать большее количество расширений, потому что теперь мы знаем,
что можно предоставить большие полномочия, если подписанный элемент
действительно взят с Microsoft MSDN, но его также можно взять и с подобного
web-сайта.
20. Нажмите Next, затем Finish.
Перед тем, как завершить выполнение нашего последнего задания, давайте
оглянемся и вспомним, что именно мы сделали. Мы описывали формирование
настройки доступа для подписанного элемента, взятого с ресурса msdn.one.microsoft.com.
Давайте рассмотрим случай, если бы ассемблирование было взято с этого web-сайта,
но оно было бы нелегальным, т.е. незарегистрированным? В такой ситуации в
действие вступает совокупность настроек PrivateGroup_l, куда попадут настройки
доступа этой группы кода. Так как был выбран пункт Nothing, это означает, что эти
элементы предоставлены без официального разрешения. Как бы то ни было, по
причине того, что сайт msdn.one. microsoft.com находится в Internet Zone, в действие
вступают настройки для группы кода Intemet_Zone, которые разрешают запуск любых
элементов, полученных из этой зоны. Более того, так как данный блок данных взят из
всех предоставленных настроек для разрешения доступа, данные элементы можно
будет запустить.
Почему не прописать для PrivateGroup_2 в качестве источника Internet_Zone, ведь
неподписанные элементы, взятые с msdn.one.inicrosoft.com, в любом случае
допускаются к работе с помощью Internet настроек? Причина проста: мы хотим только
дать подписанным ассемблированиям с msdn.one.Microsoft.com дополнительное
разрешение в случае, если они взяты с соответствующих web-сайтов. Если подобное
подписанное ассемблирование было скопировано с другого web-сайта, оно будет
рассматриваться в таком же режиме, как и любой иной элемент из зоны Internet.
Установка PnvateGroup l «нулевой» Nothing настройки доступа базируется на том, что
только в подобном случае элементы подпадают под действие обоих условий, и
PnvateGroupJLявляется лишь переходным этапом для выполнения нужных действий.
Обязательно учитывайте, что мы только обсуждали, как с помощью текущей
настройки определять политику уровня безопасности по отношению к
конкретному пользователю. Ваши настройки могут частично пересечься с параметрами,
которые будут установлены автоматически, на системном уровне. Более того, так как на
системном уровне ассемблированию будут даны только настройки как Internet
разрешению, наше подписанное ассемблирование будет совмещено с эффективными
настройками доступа Internet. В нормальной ситуации текущие настройки
совокупности инициатив также вступают в пересечение с другими параметрами, но так как

Приложение А • Основные понятия .NET Security
в структуре группы кода есть только одна группа, которой предоставлено полное
доверие — это AU_Code группа, этот факт не будет играть никакой роли в наложении
настроек различных уровней друг на друга в этом примере.
Наша последняя задача, замещение настроек разрешения, нуждается в
немедленном уточнении:
1.Выберите параметр LocalIntranet_Zone и далее — Properties. Появится
диалоговое окно LocalIntranet_Zone Properties (Рис. А.35.).
Рис. А-35- Настройка атрибутов в Главной таблице Группа кода
Разрешение Dialog Box
Local! nttanet_Zone Properties
^ j I фтт&с№&\
rjewe*
LocalIntranet_Zone
С group ^ряофЬэп; у„ ...., .::„
This code group grants the LocaHntranet permission set to assembles
from the LocaJlntranet^Zone. Default rights given to applications on
your local intranet This code group has been modfied by the Adjust
Security Wizard.
poky fevel Ш $nty hev« th» 0«rm»««» fam tfcr
&^£еЫ:§& feyS^notfce. ev «3
Cancel
2. Выберите таблицу Permission Set.
3. Откройте выскочившее меню с доступными параметрами для настройки и
выберите PrivatePermissions. Вы увидите, что в этом списковом окне отразятся
настройки, которые завершат формирование параметра PrivatPermission.
4. Нажмите Apply to и вернитесь в таблицу General.
В этой таблице содержится рамка под названием If the membership condition is
met, с помощью которой регулируются два параметра:
■ Эта политика уровней будет разрешать только настройки доступа,
совместимые с этой группой кода. Это связано с атрибутом группы кода Exclusive-

Приложение А • Основные понятия .NET Security
■ Уровень ниже данного не задействуется. Этот пункт соотносится с
атрибутом группы кода атрибут LevelFinal.
Обе опции требуют разъяснения, поэтому давайте вернемся к примеру с
msdn.one.rnicrosoft.com. Представьте, что вы открыли диалоговое окно Properties,
принадлежащее к группе кода Internet_Zone и проверили пункт Exclusive (конечно,
вы должны сохранить эти настройки в первую очередь, чтобы активизировать эту
функцию). Мы получили подписанное ассемблирование с msdn.one.microsoft.com.
Наши параметры настроены таким образом, что этому элементу будет дано
разрешение LocalIntranet_ZoneB рамках политики разных уровней доступа для различных
пользователей. Но теперь в игру вступает параметр Exclusive. Так как наше
подписанное ассемблирование также сталкивается с условиями Iniernet_Zone, Интернет-
настройки доступа работают.
Исключение настройки для the Internet Zone группа кода заставляет систему
игнорировать и другие действующие настройки разрешения, не принимая
объединения данных настроек. Взамен параметры настроек доступа с ограничивающим
атрибутом назначаются в соответствии с текущими настройками с индивидуальной
по отношению к каждому пользователю политикой. Так как возникнет
пересечение полномочий с другими уровнями системы безопасности, это также
определяет максимальные полномочия, которые будут предоставлены подписанному
ассемблированию.
Используйте этот атрибут аккуратно, так как из всей группы кода, членом
которой является элемент ассемблирования, следовательно, сталкивается с
условием, только одно может иметь атрибут Exclusive. CLR определяет, тот ли это случай.
Когда CLR определяет, что ассемблирование натыкается на определенные
предустановки более одной группы кода с атрибутом Exclusive, оно отбросит исключения
и не сможет определить действующие настройки доступа и ассемблированию не
будет разрешено действовать.
Способ действия LevelEinal более прост. Понимая, что, устанавливая
действующие настройки доступа для ассемблирования, CLR оценивает политику системы
безопасности, начиная с высшего уровня (инициатива, за которой следят как
пользователь, так и компьютер). Снова вернемся к нашему MSDN-примеру. Мы
настраивали параметр LeveWinal в PnvateGroup_2 группе кода и взяли атрибут Exclusive из
Internet_Zone. Когда действующие настройки доступа для подписанного
ассемблирования с msdn.one.microsoft.com были настроены, CLR начал выяснять текущие
параметры доступа политики уровней. Именно для AH_Code Full Trust эта
политика выравнивается из-за перекрещивания текущих настроек доступа. Теперь
политика на уровне пользователя начинает действовать в соответствии с
установленными текущими настройками. Как вы теперь знаете, этот параметр теперь
аналогичен LocaUntranet_Zone. Как бы то ни было, CLR также натолкнулся на атрибут
LeveWinal. Он остался из настройки текущих параметров машинной политики

Приложение А * Основные понятия .NET Security
уровней и его полномочия перекрещиваются с текущими настройками уровня,
установленного вами для пользователя. Текущие настройки будут аналогичны
LocallntmnetJZom.
Так как автоматическая политика уровней не определена, текущие настройки
будут в этом случае установлены на большее разрешение доступа, чем в ситуации,
если бы атрибут LeveWinal был бы не настроен.
Удаленная безопасность
Обмен опытом между разными системами безопасности всегда приносит
новые открытия. Удаленная безопасность — не исключение. Давайте начнем с
взаимодействия между системами. Если вы используете Http-канал, можно увидеть SSL-
шифрование. Ftp-канал не зашифрован, но если оба сервера поддерживают IPSec,
вы сможете создать безопасный канал, по которому два ресурса Ftp-канал могут
обмениваться данными. Все серверы Microsoft системы выше NT, в том числе 2000,
ХР и 2003 имеют порты для быстрой установки приложения IPSec.
Следующий тезис таков: выясните, до какой степени вы доверяете другим
системам. Даже имея безопасный канал, как вы узнаете, что другие системы не были
скомпрометированы? Нужен как минимум устойчивый механизм
аутентификации, а также необходимо запретить доступ анонимным пользователям, хотя это не
всегда возможно. Попробуйте использовать хотя бы NTLM или Kerberos для
аутентификации. Последний является совершенным посредником для обеспечения
выдачи себя за других персон между разнородными системами. Если нужно
использовать анонимных пользователей, можно применить IIS. Можно также использовать
полномочия, чтобы запретить пользователю напрямую задействовать ваш IIS.
Пакеты, которыми обменивается система, всегда должны быть подписаны,
чтобы вы могли проверить отправителя и/или источник. Даже когда вы уверены,
что сообщение поступило по безопасному каналу, никогда нельзя предугадать, с
какой целью оно было отправлено, возможно, оно обрушит вашу систему, поэтому
будьте бдительны в любом случае.
В этом разделе мы рассмотрели, в чем польза от применения зашифрованного
доступа и системы безопасности, основанной на ролях. Чем более тщательно вы
используете данный рабочий цикл системы безопасности, тем лучше
контролируется удаленная система безопасности.
Криптография
Без сомнения, во всех системах безопасности хотя бы в какой-то степени
используется криптография или кодирование. Хотя без криптографии не обойтись
при создании безопасной обстановки, это не «святыня» системы безопасности-

Приложение А • Основные понятия .NET Security
Данный раздел освещает основные черты криптографии, которые связаны с .NET
Framework. Если вы уже работали с Windows 2000 Cryptographic Service Providers
(CSPs) и/или используете Crypto API, вы знаете почти все, что можно знать о
криптографии в .NET Framework.
Самый важный вывод таков: простота в использовании криптографически
зашифрованных функций очень увеличилась с тех пор, как мы имели в
распоряжении только CryptoAPI, работающий только на C/C++. Важным добавлением в
концепцию модели криптографического пространства имен (в C++ — именованная
область видимости) стал Crypto Streams, сделавший возможным связать в единую
цепь любые криптографические объекты, которые используют Crypto Streams.
Это означает, что вывод из одного криптографического объекта может быть
напрямую введен в другие криптографические объекты, без необходимости
сохранять результаты в неком переходном объекте. Эта опция может существенно
упростить и ускорить выполнение работы, особенно если большие объемы данных
нужно кодировать или хэшировать. Другим повышением функциональности стала
возможность подписать XML-код, code, несмотря на то, что он может
использоваться только внутри системы безопасности .NET Framework. До какой степени
эти методы совместимы с предложенными образцами RFC 3075, неясно.
Внутри .NET Framework три пространства имен содержат криптографические
данные:
■ System. Security. Cryptography Самый важный элемент, сходный по
возможностям с CryptoAPI.
■ System. Security. Cryptography -X509 certificates Совместим только с Х509 v3
сертификатом и используется с Authenticode.
■ System. Security. Cryptography.Xml Для использования исключительно внутри
системы безопасности .NET Framework.
Криптографические пространства имен поддерживают следующие CSP-клас-
сы, которые будут работать с Windows 2000 CSP на CLR. Если CSP доступен внутри
. NET Framework, это не будет автоматически означать, что на соответствующем
Windows 2000 CSP система CLR запущена:
■ DESCryptoServiceProvider Обеспечивает выполнение функций
симметричного ключа алгоритма Data Encryption Standard.
■ DSACryptoServiceProvider Обеспечивает выполнение функций
асимметричного ключа алгоритма Data Signature Algorythm.

Приложение А • Основные понятия .NET Security
■ MDSCryptoSenriceProvtder Обеспечивает выполнение функций хэширующего
алгоритма Message Digest 5.
■ RC2CryptoServiceProvider Обеспечивает выполнение функций
асимметричного ключа алгоритма RC 2 (названного в честь изобретателя Ривеста Чи-
фера Второго).
■ KNGCryptoServiceProvider Обеспечивает выполнение функций Random
Number Generator.
■ RSACryptoServiceProzrider Обеспечивает выполнение функций
асимметричного алгоритма RSA (названного в честь изобретателей — Ривеста, Шамира и
Адлемана).
■ SHA1 CryptoServiceProwder Обеспечивает выполнение функций алгоритма
хэширования Secure Hash Algorythm 1.
■ THpleDESCryptoSerzncePropider Обеспечивает выполнение функций
симметричного ключа алгоритма 3DES.
Чтобы подвести итог, мы дадим краткое описание симметричного ключа
алгоритма, асимметричного ключа алгоритма и алгоритма хэширования.
Симметричный ключ алгоритма лишает вас возможности шифровать и расшифровывать
данные, которые пересылаются между вами и другими частями системы. Тот же ключ
используется для кодирования и раскрытия данных. Поэтому он называется
симметричным. Этот алгоритм заставляет вас обмениваться ключом с другой
стороной, но обмен должен быть произведен таким образом, чтобы другие участники не
смогли перехватить код. Так как алгоритмы с симметричным ключом часто
используется для коротких обменов данными, они также применяются в качестве
алгоритмов ключа сессии. Для обмена такими ключами стороны задействуют
алгоритм асимметричного ключа.
Асимметричный ключ алгоритма использует парный ключ. Один ключ закрыт и
доступен только владельцу, другие публичны и могут быть переданы всем. Так как
алгоритм использует два схожих, но разных ключа для кодирования и
расшифровки, он называется асимметричный алгоритм, но также задействован и алгоритм
публичного ключа. Публичный код входит в сертификат, который имеет «доказанную
аутентификацию» и который предоставлен организацией, которой доверяют
участвующие стороны. Этой структурой запущена авторизация сертификата
(certificate authority, CA), самой известной из которых является VeriSign.
Итак, попробуем использовать алгоритм асимметричного ключа для обмена
симметричными кодами. Лучший пример — два сервера Windows 2000, между кото-

Приложение А • Основные понятия .NET Security
рыми нужно регулярно настраивать соединение в интересах их пользователей.
Каждое соединение, или сессия, должны быть безопасными и нужно использовать
уникальный ключ сессии, сходный с другими защищенными сессиями. Серверы
заменяют ключ сессии для каждого соединения. Оба сервера имеют пару
асимметричных ключей и обмениваются публичным ключом в сертификате.
Следовательно, если один сервер хочет отправить ключ сессии другому серверу, он использует
публичный код, чтобы зашифровать ключ сессии перед отправкой. Этот сервер
знает, что только другой сервер может раскодировать этот ключ сессии, так как тот
сервер обладает частным ключом, необходимым для расшифровки кода сессии.
Алгоритм хэширования также рассматривается в качестве алгоритма
одностороннего хэширования, может трансформировать любой фрагмент данных во фрагмент
данных с фиксированной длиной, под названием хэшили дайджест сообщения,
который почти всегда значительно короче, например 160 бит для SHA-1. Термин
односторонний означает, что вы не сможете извлечь исходные данные путем анализа
только дайджеста.
Другой важной чертой алгоритма хэширования является то, что для каждого
фрагмента данных создается уникальный хэш, даже если изменен всего один бит
данных. Вы увидите хэш каждого минимального изменения фрагмента данных.
Например, вы отправляете кому-либо сообщение по электронной почте в
формате «простой текст». Как вы и адресат узнаете, что сообщение не было
перехвачено и изменено по дороге? Для установления этого факта используется дайджест
сообщения. Перед тем, как отправить сообщение по электронной почте, примените
алгоритм хэширования по отношению к этому сообщению. Отправьте сообщение
и его дайджест адресату. Получатель может выполнить те же операции
хэширования, и если сообщение и его дайджест совпадут, адресат поймет, что сообщение
пришло в исходном виде. Конечно, если кто-то вмешается в процесс пересылки
вашего сообщения, он может также создать и новый дайджест и скрыть это
действие, но и это мы предусмотрели. При отправке дайджеста вы шифруете его с
помощью вашего частного кода, адресат знает публичную часть ключа. Это
решение не только уменьшает вероятность вмешательства в сообщение без ведома
вашего и адресата, но также доказывает получателю, что сообщение пришло именно
от вас. Как?
Итак, давайте представим, что кто-то перехватил сообщение и хочет изменить
его. У злоумышленника есть ваш публичный код, поэтому он может расшифровать
каталог вашего сообщения. Как бы то ни было, не обладая вашим личным кодом,
он не сможет раскодировать недавно созданный каталог. Следовательно, он не
сможет пойти дальше и в соответствии со своим планом незаметно изменить
послание, переданное по электронной почте. В конце концов, послание по
электронной почте попадает в почтовый ящик адресата. Система
расшифровывает каталог закрытых данных, используя ваш публичный код. Если это удается,
теперь она знает, что именно вы отправили это сообщение, так как только вы име-

Приложение А * Основные понятия .NET Security
ете доступ к частному коду. Система считывает хэш сообщения и сравнивает
каталоги. Если они совпадают, система определяет, что это сообщение не только не
было изменено, но и что оно пришло именно от вас, так как каждое сообщение
имеет уникальный хэш.
Инструменты безопасности
.NET Framework содержит 10 инструментов, запускаемых через командную
строку (см. Таблица А.4.), с помощью которых вы сможете решить задачи
обеспечения безопасности. Для получения более подробного описания этих
инструментов изучите документацию .NET Framework.
Таблица А.4. Командная строка инструментов системы
безопасности
Название Инструмента
Название Операции Описание
Code Access Security
Policy Utility
Caspol.exe
Certificate Verification Utility Chktrust.exe
Certificate Creation Utility Makecert.exe
Этот инструмент позволяет
осуществить любую
операцию по
совместимости с системой
доступа, принятой в
соответствии с политикой
вашей системы
безопасности. Так как этот
инструмент обладает
большими возможностями
за пределами .NET
Configuration Tool, важно,
чтобы вы полностью
освоили данный метод
самостоятельно.
С помощью этого
инструмента можно
проверить файл, который
был подписан с помощью
электронной подписи.
Создает сертификат Х.509
для проверочных целей.
Опция, которую вы можете

Приложение А * Основные понятия .NET Security
для
возможностей.
Certificate Manager Utility
обладаете
правами)
вашего компьютера
Software Publisher
Certificate Test Utility
Permissions View
PE Verify Utility
Secutil Utility
(например,
разрешение).
File Signing Utility
установить, чтобы инсталлировать
Certificates Services на Windows
2000, с помощью которой
значительно упрощается создание
и поддержка сертификатов
развития и проверки
Certmgr.exe Эта утилита управляет вашим
сертификатом, уровнем его
доверия и т.д. Установка Microsoft
Management Console лишает вас
возможности обслуживать не
только собственных сертификатов,
но также (если вы
соответствующими
сертификаты
и аккаунты серверов.
Cert2spc.exe Этот инструмент создает
издательский сертификат
минимум для одного сертификата
Х.509.
Permview.exe Этот инструмент лишает вас
возможности просматривать
запрошенные разрешения на
ассемблирование.
Peverify.exe Этот инструмент лишает вас
возможности подтверждать
типовую безопасность
выполняемых файлов.
Secutil.exe Этот инструмент извлекает
неизменяемое имя или
публичный ключ информации из
ассемблирования и
конвертирует так, чтобы его
можно было увидеть прямо в
вашей системе
запрос на
Signcode.exe Этот инструмент лишает вас
возможности подписывать файл
РЕ file с помощью электронной

Приложение А * Основные понятия .NET Security
Strong Name Utility
Set Registry Utility
использовать
криптографические
настроите эту
работать на
параметров.
Isolated Storage Utility
Sn.exe
Setreg.exe
подписи. Если эта утилита
запущена с помощью командной
строки, запускается Digital
Signature Wizard.
Этот инструмент лишает вас
возможности подписывать
элементы с неизменяемыми
именами.
Этот инструмент лишает вас
возможности настраивать ключи
каталогов, чтобы
открытые
коды. Если вы не
утилиту, она будет
основе встроенных
Storeadm.exe Этот инструмент лишает вас
возможности управлять
изолированным хранилищем для
пользователя, который
подключен в данный
момент.

Приложение А • Основные понятия .NET Security
Итог
Позиционируя .NET Framework в качестве дистрибутива организации
приложений, специалисты компании Microsoft были хорошо осведомлены, что сложно
уделить внимание тому, как обезопасить приложение, учитывая какие пробелы
содержит предлагаемая система безопасности. Вот почему компания представила
расширяемую, кроме прав и управления разрешениями, систему безопасности,
масштабируемую, так как вы можете создать и собственные неподписанные и
промышленные разрешения и жесткие, даже если приложение не зависит от
настройки разрешений. Вдобавок, CLR проверит систему на типовую безопасность (будет
проверено, пыталась ли система проникнуть в места, которые не относятся к ней
напрямую) во время составления JIT.
.NET Common Language Runtime (CLR) будет всегда выполнять проверку
системы безопасности под названием система безопасного доступа для ассемблирования,
если оно запрашивает доступ к защищенному ресурсу или операции. Чтобы
предотвратить недостоверное ассемблирование, которое запускается с помощью
ограничения разрешения через вызов других ассемблирований, CLR запускает
прохождение системой безопасности цикла. При этом проверяется каждое
ассемблирование в цепи вызова ассемблирований, чтобы обнаружить, все ли из них имеют
необходимый уровень доступа. Если это не так, ассемблирование не допускается к
этому защищенному ресурсу или операции.
Что дает разрешение на ассемблирование? Запросы на разрешение
ассемблирования контролируются двумя путями. Первый — проверка с помощью группы
кодов, которая предоставила разрешения на ассемблирование, основываясь на
доказательствах достоверности, предоставленных CLR. Ассемблирование само по себе
проверяется позже. Безопасное ассемблирование всегда запрашивает именно тот
уровень доступа, который необходим, даже если CLR готов предоставить и
большие полномочия. Таким образом, ассемблирование само себя страхует от того,
чтобы его использовали другие коды, которые хотят получить доступ к системе
настройки разрешений. Иерархия группы кода должна быть соответствующим
образом настроена администратором, чтобы в системе содержались разные уровни
для обеспечения политики безопасности: администратор, пользователь и машина.
Чтобы определить действующие настройки уровней доступа, CLR использует
прямолинейные и трудоемкие методы. Выявляются все действительные
настройки разрешений, основанные на важности ассемблирования в системной политике
безопасности, и эти настройки объединяются в систему, чтобы между ними не
было противоречий. CLR запускает эту операцию по отношению ко всем уровням и
пересекает текущие настройки, чтобы определить действующие настройки
доступа к ассемблированию.
Вдобавок к закрытой и безопасной системе доступа, CLR также поддерживает
ролевую систему безопасности, хотя ее осуществление достаточно отличается от

Приложение А • Основные понятия .NET Security
того, к чему вы привыкли в СОМ. Каждый выполняемый трэд имеет контекст в
системе безопасности, который называется принципалом. Он определяет
идентичность пользователя. Принципал также используется для выдачи себя за другого
пользователя. Принципал принимает новые формы: основываясь на системе
пользователей Windows и их аутентификации; родовой, контролируемый с помощью
встроенных служб аутентификации; и базовая форма, которая лишает вас
возможности создавать собственный принципал и идентичность. Система может
затребовать тестирование принципала, если пользователю присвоена специфическая
роль.
Все еще самой важной чертой является политика системы безопасности,
разрешающая вам создание группы кодов и установку собственных параметров
доступа, чтобы обогащать встроенные разрешения. Собственные свойства могут быть
добавлены в .NET Framework без вскрытия системы безопасности,
соответственно вы не сможете нарушить ее работу.
Что вы можете ожидать от любой инфраструктуры, которая зависит от
системы безопасности, .NET Framework содержит полный комплект
криптографических опций аналогично CryptoAPI, только пользоваться .NET Framework гораздо
удобнее; кроме того, она не зависит от C/C++. Чтобы управлять
криптографическими возможностями, такими как сертификаты,.NET Framework обладает
утилитами для настройки системы безопасности, которые запрещают вам
контролировать и поддерживать систему безопасности вашего приложения во время
процессов его развития и развертывания.
Система безопасности Fast Track
.NET Security
• Разрешения для контроля над доступом к защищенным ресурсам и
операциям.
• Принципал — это среда системы безопасности, которая присоединена к
каждому выполняемому трэду в CLR. Он также поддерживает систему
идентификации пользователя, такой как Windows account information, и
пользовательских ролей. Он также содействует на способность системы
выдавать одного пользователя за другого.
• Аутентификация и авторизация могут быть проконтролированы с
помощью самого приложения или NTLM и Kerberos. Если Windows однажды
авторизовала пользователя на выполнение кода, основанного на CLR, код
будет контролировать авторизации, которые базируются на
идентификации пользователя и информации, которая поступает с ассемблированием,
которая называется утверждением.

Приложение А • Основные понятия .NET Security
• Политика безопасности контролирует всю CLR. Систему, при которой
администратор может предоставлять разрешение ассемблированию для
доступа к защищенным ресурсам и операциям. Это предоставленное
разрешение базируется на утверждение, которое ассемблирование передает CLR.
Если политика безопасности хорошо продумана, CLR получает санкции на
постоянное обеспечение безопасной обстановки.
• Типовая безопасность тесно связана с предотвращением попадания кода
ассемблирования в каждый архив других приложений. Во время
компиляции JIT типовая безопасность всегда тестируется, и, следовательно, перед
тем, как система будет загружена в текущей обстановке. Только код,
предоставленный через разрешение Skip Verification, может обойти типовую
безопасность, до тех пор, пока оно не выключит все вместе.
Система безопасного кода доступа
• Кодовый доступ к системе безопасности базируется на предоставлении
ассемблированию разрешения и установки параметров, чтобы оно никогда
не запрашивало больше полномочий, чем нужно. Это принуждение
основано на системе безопасного прохождения цикла. Когда делается запрос
на защищенный ресурс или операцию, ассемблирование, к которому
обращается CLR, получает особое разрешение. Как бы то ни было, взамен
проверки только ассемблирования, которое сделало запрос, CLR тестирует
каждое ассемблирование, которое является частью цепи вызова. Если все
эти элементы обладают особым разрешением, доступ к защищенному
ресурсу или операции разрешен.
• Вы можете разыскать абонента, который имеет специфическое
разрешение, используя декларативный и императивный синтаксис. Запрашивание
разрешений может быть выполнено только в декларативном порядке.
Декларативный означает, что это не часть имеющегося кода, но присоединена
к ассемблированию, классу или методу с использованием особого
синтаксиса, вложенного в о. Когда код компилируется как переходный язык
(intermediate language; IL) или портативно осуществляемый, происходит
требование или запрос, которые раскрывают код и помещают
ассемблирование в метаданные. CLR читает и интерпретирует эти метаданные перед
тем, как ассемблирование загружено. Императивный способ запрашивает
часть кода. Это может быть заметно, если требования условны. Так как
запрос может всегда провалиться и проявиться в CLR, код должен
обладать соответствующими свойствами для решения вопросов в этих
исключительных случаях.

Приложение А * Основные понятия .NET Security
• Чтобы быть в состоянии написать безопасный код, возможно, стоит
сдерживать разрешения, которые предоставлены этому коду. Это делается
через запрашивание необходимых разрешений для запуска
ассемблирования, посредством чего CLR дает ассемблированию только те разрешения,
под обязательство, что запрошенные разрешения являются частью
настройки доступа, по которой CLR предоставил бы ассемблированию
полномочия в любом случае. С помощью выполнения вашего запроса на
ассемблирование с ограниченными параметрами разрешения, вы можете
предотвратить злоупотребление правами со стороны других систем. Как бы то
ни было, можно также сделать факультативные запросы, которые
определят, какие коды имеют право доступа, даже если это превосходит
предоставленные параметры доступа. Система должна уметь обработать
возможные исключительные случаи.
• Система может контролировать тот способ, с помощью которого
осуществляется прохождение цикла системы безопасности. Через Assert, Deny или
PermitOnly, которые можно настраивать как и с помощью декларативного,
так и императивного синтаксиса, прохождение цикла заканчивается перед
тем, как полный цикл пройден. Когда CLR достигает Assert во время
прохождения цикла, он заканчивается Succeed. Если система наталкивается на
Deny, процесс завершается на Fail. С PermitOnly завершить процесс удастся,
только если проверенное checked разрешение совпадает или подпадает
под запрещенные разрешения, связанные с PermitOnly. Каждый следующий
запрос завершится на PermitOnly.
• Индивидуальные разрешения могут быть созданы и добавлены к
имеющейся системе.
Ролевая безопасность
• Каждый выполняемый трэд в работающей системе .NET
идентифицирован как часть среды системы безопасности под названием принципал
• Основываясь на принципале, проверки, базирующиеся на ролевой
политике, могут быть выполнены.
• Такие проверки могут быть выполнены декларативным, императивным и
директивным способом. Последний требует доступа к принципалу и/или
идентифицированному объекту запрашивания значения полей.
Политика системы безопасности
• Политика безопасности состоит из разных уровней: администратор,
пользователь, компьютер и приложение домена. Последний используют не
всегда.

Приложение А • Основные понятия .NET Security
• Политика безопасности имеет встроенные параметры настройки
разрешения, например FullTrust или Internet. Настройки доступа — это набор
разрешений. Группируя разрешения, вы легко сможете их предоставить,
используя только название комплекта.
• Важная часть политики — это правила безопасности, которые называются
группами кодов; эти группы составляют иерархию.
• Группа кода проверяет ассемблирование в соответствии с его уровнем
доверия. Если уровень доверия ассемблирования сталкивается с настройками,
ассемблирование принимается в качестве члена данной группы кода и ему
присваивается соответствующий уровень доступа. Когда все группы кодов
проверены, настраивается разрешение для всех групп кодов, содержащих
ассемблирование, и параметры объединяются с текущими настройками
доступа для ассемблирования на данном уровне системы безопасности.
• CLR выполняет проверку данной группы кода на всех уровнях системы
безопасности, в результате выявляя три или четыре текущих настройки
разрешений. Их пересечение приводит к тому, что таковые настройки
присваиваются ассемблированию.
• Удаленные пределы протяженности, по отношению к которым политика
безопасности может быть применена. Чтобы обеспечить безопасную
обстановку, нужно обозначить пределы таким образом, чтобы CLR полностью
контролировал доступ к вашей закрытой среде.
Криптография
• .NET Framework содержит криптографические пространства имен,
которые охватывают все необходимые криптографически выполняемые
функции, так же как до сих пор употребляемый CryptoAPI.
• Использование классов криптографии значительно проще, чем
применение CryptoAPI.
Инструменты безопасности
• .NET Framework содержит комплект инструментов системы безопасности.
Инструменты, которые запрещают поддерживать сертификаты,
подписывать коды, создавать и поддерживать политику системы безопасности и
контролировать систему безопасности ассемблирования.
• Два инструмента запрещают обслуживать код доступа системы
безопасности. Caspol.exe (Code Access Security Policy Utility) загружается с помощью
интерфейса командной строки. .NET Configuration Tool является
интегрированным приложением для ММС, поэтому, оно предпочтительнее, чем
caspol.exe.

Приложение А • Основные понятия .NET Security
FAQ
Ответы авторов данной книги на следующие вопросы рассчитаны как на ваше
понимание концепций, представленных в этой главе, так и на помощь в претворении
данных концепций в реальную жизнь. Для того чтобы получить ответы на ваши
собственные вопросы по этой главе, зайдите на www.syngress.com/solutions и
нажмите на форму «Спросить у Автора». Вы также получите доступ к тысячам
других FAQ на ITFAQnet.com.
Вопросы (В) и ответы (О)
В: Я хотел бы предотвратить перегрузку стека системы безопасности. Как я могу
проконтролировать этот момент?
О: Эта проблема может стать ключевой, если она коснется кодов доступа
значительного количества защищенных ресурсов и/или операций, особенно если
они попадают в длинную последовательность вызовов. Единственный способ
предотвращения подобного варианта развития событий — выбор пункта
Secure Action. Assert как раз перед тем, как будет запущена защищенная операция
или пойдет запрос на закрытый ресурс. Это предполагает, что нужно
доскональное понимание тасзд когда стек или запрос запущены, и на чем основано
разрешение для выполнения этой операции. Если вы выберете только Assert,
то создадите неконтролируемую системой безопасности дырку.
Последствия ваших действий могут проявиться в ситуации, когда вы делаете
запрос на защищенный ресурс но делаете его внутри структуры цикла. Также
вы можете использовать это т шшуации, когда запускаете метод, который вы
полняет определенное количество запросов на различные защищенные
ресурсы или операции, чх^швляетсд «шусковым крючком для поддержки того
же типа разрешения.
Единственный способ уменьшения количества циклов — это помещение
императивного утверждения на разрешение, которое будет запрошено. Теперь
вы знаете, как остановить цикл. Чтобы закрыть пр«$&е»ину в системе
безопасности, которую вы только что обнаружили, поместите императивный запрос
для разрешения, который вы обнаружили перед утверждением. Если запрос
выполнен успешно, вы обнаружите другие звенья цепи вызова, значит, все в
порядке и можно признать это разрешение. Более того, так как ничего не
изменится, если вы проверите дважды или трижды, то застрахуетесь от
лишнего прохождения цикла. Представьте себе, что дверь открывается и
закрывается 1000 раз. А вы только что обнаружили, что ваша система выполняет 999
лишних циклических прохода.

Приложение А • Основные понятия .NET Security
В каких случаях лучше использовать императивный синтаксис, а когда боль
ше подойдет декларативный синтаксис?
Во-первых, убедитесь, что вы хорошо поняли разницу между влиянием на систему,
которое оказывает каждый из них. Императивный синтаксис делает запрос, или для
этой цели подавляет часть вашей системы кодирования. Это важно, когда он
затрагивает поток системы или задерживает запрос во время работы. Декларативный
синтаксис привносит эти требования и попирает права ассемблирования на
метаданные. Во время фазы загрузки ассемблирования метаданные раскрываются и
интерпретируются, это означает, что CLR уже начал работать с этой информацией. Если
стек имеет место, CLR может провести аннулирование значительно быстрее, чем,
если это происходит во время выполнения работ. Как бы то ни было, запросы
нужно подавать только в тот момент, когда они действительно необходимы. В
большинстве случаев запросы необязательны. Подумайте, что если запрос базируется на
проверке ролевой системы безопасности. Если вы делаете декларативный запрос для
класса или метода, каждый раз буцет запускаться цикл, к которому относится данный
класс или метод, даже если запрос выключен или не нужен. Для восстановления:
сделайте аннулирование декларативным и расположите их в заголовке метода, пока все
методы в классе не потребуют утверждения, затем расположите их в декларации
класса. Всегда помните, что ассемблирование не может содержать более одного
активного доминирующего типа. Если вы не можете обеспечить данный пункт, в
любом случае нужно использовать декларативный синтаксис как основу. Обязательно
сделайте запросы перед тем, как вы проникните в защищенный ресурс или
операцию.
Как следует выстраивать иерархию группы кода?
Нужно помнить о четырех важнейших моментах, когда работаете над
структурой иерархии группы кода:
■ Ассемблирование не может быть членом группы кодов, которые имеют
противоречащие друг другу настройки доступа, например, один с
неограниченным FUelOPermission и другой, с более низким уровнем FilelOPermission.
■ Чем больше иерархия группы кода, тем сложнее ее поддерживать.
■ Чем больше количество настроек уровня доступа, тем сложнее следить за
ними.
■ Чем труднее обслуживать группу кодов и параметры разрешения, тем
больше вероятность, что возникнет дыра в системе безопасности.

Приложение А • Основные понятия .NET Security
Лучше всего выбрать самый большой общий знаменатель. Система
безопасности по возможности должна работать максимально просто и надежно, с
несколькими исключениями. Перед тем, как вы начали создавать индивидуальные
параметры настройки, убедитесь, что это абсолютно необходимо. В девяти из
десяти случаев встроенных настроек разрешения достаточно. То же самое можно
сказать и о группах кодов — подавляющее большинство элементов будут удачно
встроены в группу кода, которая базируется на их зоне идентификации. Если вы
сделаете вывод, что этот код не сработает, добавьте только более специфическую
группу кодов, например группу publisher, но прежде проверьте более крупный
блок элементов. Используйте более одного уровня в иерархии группы кода,
только если это абсолютно необходимо протестировать более одного атрибута
членства условий или идентичности. Добавьте настройки доступа только на нижнюю
ступень и обратитесь к параметру Nothing настройки доступа корневой группы
кодов.
Примите во внимание, что CLR протестирует все уровни защиты, поэтому
проверьте, нужно ли вам модифицировать иерархию группы кода только одного
уровня защиты или большего количества уровней. Помните, что CLR перекроет
текущие настройки полномочий на всех уровнях.

Приложение В
Phishing — вид атаки «человек-в-середине», когда хакер обманным путем заставляет
легитимного пользователя ввести пароль в фальшивую web-форму или сообщение электронной
почты, которые внешне очень похожи на сообщения, пришедшие с легального web-сайта.
Sniffing — использование утилиты мониторинга сети для перехвата паролей или иной
важной информации с целью нарушения работы системы.
Аннулирование (Repudiation) — возможность запретить выполнение определенного
действия.
Атака «обмана» (Luring Attack) — принуждение «жертвы» на выполнение я^йсшшй в иние*
ресах взломщика.
Атака грубого подбора (Jlrute Force Attack) — процесс раскрытие шт*$МЩЩ&№^ш#Ш1я с
помощью ввода различных комбинаций символов. П^щ^шре'^ршш^Щ'р:нашшаться с
ввода словарных словам, распространенных п^рол^Шш^^Щ^Ш0Щ^ШтЫт^щш
символов.
Атака с пульта упрявлешЩ^01(0Н^ф№щ^ — атака, начатая с системного пульта
управления. "':*%0*t ' * "*
Атаки с «черного» входа (Backdoor Attack^— тлом плохо установленных механизмов
защиты, получение аутентификации или прямого доступа к содержанию обманным путем.
Внедрение в SQL (SQL injection) — манипуляции с вводом данных с целью нарушить
целостность SQL-записей, которые осуществляют поддержку сервера базы данных.
Внедрение команды (Command Injection) — внедрение специальных метасимволов
оболочки или манипулирование вводимыми данными каким-либо другим способом, чтобы
спровоцировать сервер запускать команды по выбору хакера.
Дежурный маркер (Token keep-alive) — процесс периодической подачи web-запросов
для предотвращения затухания маркеров сессии, часто с использованием атаки
фиксации сессии.
Злоупотребление полномочиями (Privilege escalation) — получение хакером доступа
полномочий более высокого уровня.
429

Приложение В • Глоссарий
Лобовая атака на маркер (Token brute force attacks) — обнаружение действительных
маркеров сессии с помощью подстановки различных комбинаций символов внутри
пространства маркера.
Манипуляции с маркерами (Token manipulation) — модифицирование маркеров на URL
или в cookie для получения несанкционированного доступа к приложению.
Манипуляции с файлами cookie (Cookie Manipulation) — модифицирование файлов
cookie, чтобы воспользоваться возникшими «дырами» в системе безопасности.
Межсайтинговый скриптинг (Cross-site scriping, XSS) — атака, которая включает в себя
внедрение HTML или программы на макроязыке в легальное приложение с целью
похищения файлов cookie легального пользователя, маркеров сессии или идентификационных
данных.
Метод «социальной инженерии» (Social engineering) — использование хакером навыков
социального прогнозирования для выяснения информации о сотрудниках или иных
доверенных лицах той организации, на которую планируется провести атаку.
Несанкционированный доступ (Unauthorized access) — получение доступа к закрытой
части системы или данным без разрешения владельца этих данных.
Отказ в обслуживании (Denial of Service, DoS) — ситуация, в которой приложение
внезапно уничтожает ресурсы системы или просто перестает функционировать.
Перезагрузка буфера (Buffer Overrun) — см. Переполнение буфера.
Переполнение буфера (Buffer Overlow) — перегрузка буфера в результате отправки на
него большего количества данных, чем он может обработать, что приводит к сбою в работе
приложения и выполнения задания по выбору хакера.
Подача ложных запросов между сайтами (Cross-Site Request Forgery) — эксплуатация
репутации легального пользователя, чтобы провести транзакции в хакерских целях. Обычно
перед этим пользователя обманным путем убеждают пройти по ссылке или внедрить
ссылку в тэг HTML IMG.
Получение доступа к серверной программе (Server-side code access) — раскрытие
содержание серверной программы или конфигурации файлов, с помощью манипуляции через
ввод, чтобы замаскироваться под легальную файловую систему.
Получение доступа к файловой системе (File system access) — манипуляция с вводом
данных для чтения, написания или удаления защищенных файлов, находящихся на диске.
Получение доступа путем обмана (Content Spoofing) — ситуация, когда пользователь
пытается соединиться с сервером Internet, proxy-сервером или брандмауэром, используя
ложный IP-адрес.
Похищение аккаунта (Account Hijacking) — использование аккаунта законного
пользователя, возможно, с блокированием легального доступа к данному аккаунту.
Похищение заголовков (Banner Grabbing) — процесс соединения с TCP-портами и
прочтение возвращенного заголовка для определения типа сервиса или платформы
прикладных программ.
Похищение маркеров (Token hijacking) — получение доступа к маркеру другого
пользователя и возможности доступа к ему аккаунта.

Приложение В • Глоссарии
Похищение файлов cookie (Cookie Hijacking) — похищение аутентификационных фай
лов cookie легального пользователя, чтобы выдать себя за этого пользователя.
Приложение В
Прослеживание структуры каталогов (Directory Traversal) — получение доступа к фай
лам извне web-приложения путем манипуляции с вводом «опасных» символов. Другое наз
вание — double dot attack.
Скачкообразная перестройка частоты аккаунта (Account Hopping) — манипулирование
существующим аутентификационным маркером для получения доступа к аккаунту другогс
пользователя.
Угадывание маркеров (Token prediction) — обнаружение действительных маркеров сес
сии за счет того, что в схеме маркера использованы последовательные или предсказуемые
шаблоны.
Утечка информации (Information leakage) — провал в системе безопасности, позволяю
щий хакеру получить доступ к информации, с помощью которой он может нанести ущер(
приложению.
Фиксация сессии (Session fixation) — обеспечение другого пользователя известным фик
сированным маркером для аутентификации и последующего доступа к сессии доступа ле
гального пользователя.
«Человек-в-середине» (Man-in-the-middle, MITM) — ситуация, когда хакер проникает i
web-трафик таким образом, чтобы читать и изменять данные, пересылаемые между двум*
системами.

Предметный указатель
А Н
«About me», 6
Access, программа 270, 296, 299
ACL, 193
Akamai, 78
Application_OnAuthenticateRequest, 107
ASP.NET Service Status, 119-121, 123
ASRNET, 54, 56, 58, 61-63, 65, 72, 86-88,
90-91, 93, 95, 98, 102, 153-157,
160-163, 170, 181, 194, 198, 200
С
Cain & Abel, 61-62
CAPTCHA, 83, 86, 103, 105
CBC, 157, 172
CFB, 157, 172
Citibank, 75-77
COM,2, 9, 11, 13, 14, 16, 20, 39, 40-51
Command Injection, 207
Common Language Runtime (CLR)^ 562,
421
Cookie, 110-116, 118-119, 124-131, 134,
136-138, 208, 217, g»231, 258
CSS-атака, 55, 56, 57, 102; Щ, 128, 133
D
DHTML, 312, 326, 329
Dictionary access control, DAC, 88
DPAPI, 170, 191, 193-194, 199.201
E
eBay, 75, 76
F
Filterlnput, 209, 213-214
FromsAuthenticationTicket, 129
G
Group Policy, 91
HMACSHAL 181. 182
Hotmail.com, 75
HtmlEncode, 210, 233-234, 252, 255
HTTP cookies, 124
HTTP POST с web-формой, 56
HTTP, 160, 163, 194-197, 199, 201-202
HttpMethodNotAllowedHandler, 96. 98-99
HttpRequest, 208
HTTP-модуль, 70, 72
НТТР-ошибка, 107
I
ID
аккаунта,46
пользователя, 115
сеанса, 114, 128, 134, 137-138
IDS, 242
Ildenity, 87
IIS 65-69, 91, 210, 226-227,256-237,249,
259, 269,297*208, S02, $04-305,
файл ^т^с^ршшЛ^
Intffprf'Explorer 3MH., 69
Internet Explorer 6 Microsoft* 118
IPrincipal, 87, 101
IPSec, 114Д24, 145
IP-адрес 31, 33, 47, 52, 210, 214-216
клиента, 269
ISAM, 269, 270
IsPersistent, 129
J
JavaScript, 312
Jet, 266, 269, 270, 305
К
Kerberos, 69

Предметный указатель
L
LDAP, 63
м
MAC, 134-139, 142, 146
MACTripleDES, 181
Mailing list, 206
McAfee, 75
MD5, 56, 58-61, 102
Microsoft Passport Service, 80
MSN.com, 75
myApplication, 263-264
N
.NET Framework, 87, 88, 100-101, 316
.NET Passport, 75-77, 89
Netscape, 186
NT LAN Manager (NTLAN), 69
NTFS, 278, 298-299, 302, 304, 307
NTFS-разрешения, 92, 103, 107
О
On Error, 311, 314, 323, 325-327
P
Passport service, 75-77, 80, 89
Pennywize, 82
PGP, 35-36, 47
Phishing, 43
PIN-код, 11
POST, 56-57, 94-95, 102, 104
Principal, 363, 388-396,
R
RC2, 156, 157, 164-168, 171, 176
Replay-атака, 67
Request, 208-209, 213-214, 217, 251, 254
Rijndael, 157, 163-168, 173-176, 187-188,
198
Role-based access control, RBAC, 88
s
S/MIME (Безопасный протокол передачи
электронной почты),35,47
Sandbox, 270, 305
Service Administrative tool, 120
SHA-1, 58, 61-62, 102
SqlParameter, 287-289, 293-295
SQL-запрос, 55, 56, 102
SSL, 114, 116-119, 127, 131, 136, 145-148,
150, 153, 177, 185-186, 195-199,
201,272,303,305
SSL-запрос, 65
SSL-соединения, 57, 70
т
TCP/IP порты, 244, 272, 273
и
UPN-отображение, 69
URLEncode, 233, 234, 252, 255
URL-авторизации, 94, 104
V
VB.NET, 209, 212-213,215, 217, 224, 228,
233, 238, 251, 254
ViewState, 119, 133
ViewStateKeyUser, 134
w
web.config, 58, 61-66, 92, 94, 96, 98, 102,
104,311,314,323,325-327
Web-сайт электронной коммерции, 242
Web-сайты для взрослых, 78, 82
Windows 2000, 69, 226
Windows Server 2003, 120
X
XML, 331-334, 338-359, 347
Y
Yahoo!, 310

Предметный указатель
А
Авторизация, 275, 279
URL-установок, 93
URL, 90, 92-93
пользователя, 86
сертификата, 416
файлов, 90-91
Алгоритм одностороннего хэширования,
417
Алгоритм хэширования, 156, 198, 417
Алгоритм смены пароля, 31
Анонимный доступ, 66
Ассиметричный алгоритм, 156
Атака SQL-запросов, 295
DoS, 296
грубого подбора, 155
Аутентификация, 2, 20, 24-26, 32
SQL, 276
Windows, 275, 276
Б
База данных SQL, 63
Базовое опознавание, 67, 72, 74, 105
Безопасное программирование, 189
Бесплатный сервер, 55
Блокирование
IP-адреса, 82
аккаунта, 79, 80, 105
неопознанных пользователей, 94
операций http, 94
Брандмауэр, 244
В
Валидатор контроля, 220, 222, 251
Восстановление пароля, 29
Временный пароль, 36-38, 46, 50, 52
Встроенный способ авторизации, 86
Вторжение SQL, 206, 212
Второе декодирование, 237
Выборочный запрос, 374
Вычисление маркера, 112
Г
Генератор псевдослучайных чисел
(ГПСЧ), 155
Генератор случайных чисел, 114, 116,
136, 141, 145-147, 149
Гипертекст, 154, 157-158, 169, 172, 189
Группа кода, 369, 412-413, 425
д
Двойное декодирование, 237-238
Декларативная авторизация, 99
Драйвер базы данных, 265
3
«Забыл Пароль», 36
Запрашивание полномочий, 366, 374
Зашифрованные данные, 33, 338-339,
344, 358
Зашифрованный ключ, 338
Защита
SQL-приложений, 291
секретных данных, 156, 189
Защищенное содержимое web-сайта, 93
Зеркальный аккаунт, 276
Значение подписи, 349
И
Идентификация, 3,30, 32, 35-36, 38, 40
Идентичность кода, 368
иерархия группы, 370, 421, 427
Изменение
пароля, 22, 26, 47, 49
IP-адреса, 272
Императивная авторизация, 99
Индексно-последовательный Метод
Доступа (ИПМД), 266
Инкапсуляция, 219, 234, 252, 255
Интегрированная аутентификация
Windows, 66, 68
Интегрированное опознавание Windows,
69, 70, 75

Предметный указатель
Интерактивное преступление, 42
Исключение OutOfMemory, 321
Исключение Overflow, 321
Исключение Основа класса для
исключений, 321
Использование IP-адреса клиента, 140
История пароля, 23
Классы WMI, 248
Ключ, 154-166, 169, 176-177, 181-191, 193,
Ключевое пространство, 155
Компоненты СОМ, 248
Компрометация
базы данных, 262
данных, 262
Консорциум всемирной сети (W3C), 332
Конструкция Try-Catch-Finally, 319
Криптоанализ, 155
Криптография, 153-156, 161, 163, 169,
176, 177, 185, 200
секретного ключа, 157
Личная информация, 325
Лобовая атака, 73
на маркеры, 112
Легко угадываемый пароль, 10
Логическая ошибка, 317
м
Манипуляция с маркерами, 112, 126
Маркер, 110-118, 123, 125, 129, 130, 136,
139-143, 147
Маркер сессий, 110-111
Межсайтинговый скриптинг, 207, 229-
230,310-311
Метод
канонизации, 349
подписи. 349
шифрования, 338, 340, 357
глубокого подбора, 267, 273
создания пароля, 4
«социальной инженерии», 3, 13, 15,
26, 35, 42, 44, 52, 310
Механизм мульти-регистрации, 324
Минимальный запрос, 374
Мошенническое электронное послание,
44
Мульти-шаговая транзакция, 314, 326
н
Национальный центр защиты
инфраструктуры США (НЦЗИ)
Федерального Бюро Расследований, 2
Неавторизованный доступ, 54
Недействительный сертификат, 197
Незащищенное соединение, 55
Незащищенный код, 206
Неиспользуемый аккаунт, 3, 16-18, 48
О
Обработка исключений, 219, 240, 253,
253, 256
Обратимое шифрование,20, 35
Общие ошибки, 322
Общие административные имена
аккаунта, 11
Обычный текст, 154
Окно web-регистрации, 55
Он-лайн-демонстрация, 246
«Опасные» знаки, 285
Опознавание, 55, 62, 67-70, 72, 74-75, 87,
103, 105, 275
Отказ запроса, 375
Открытый Интерфейс Взаимодействия
с Базами Данных (ОИВБД), 265-266
Отправка электронной почты, 324
Отрицание, 310, 313
Официальный стандарт криптографии,
159
Ошибки компиляции, 317
п
Параметризация, 219, 235-236, 252, 255
Пассивное прослушивания сети, 55, 118

Предметный указатель
Первое декодирование, 237
Переменная REMOTE_ADDR, 215
Переполнение буфера, 133, 207, 249, 262,
264
Пересечение директории, 206
Перехват аккаунта, 54
Плохое внедрение, 156
Подбора пароля методом лобовой атаки,
5, 14, 20
Подделка межсайтингового запроса
(CSRF), 310
Поддержание существования маркера,
112
Подписанная информация, 349-350
Подпись, 347-350, 354
Подтверждение целостности, 177, 178,
180, 185, 198
Полномочие, 362-367, 370-381, 390, 399,
400-404,411
Пользовательское предпочтение, 131
Потеря пароля, 28, 47
Похищение аккаунта, 55, 58, 65, 75
Похищение маркера, 111
Привилегированных пользователей, 75,
102
Принципал, 388, 390-395, 397, 422, 424
Пробел в приложениях SQL, 281
Проверка синтаксиса, 219, 239, 252, 256
Программный интерфейс защиты
данных приложения (DPAPI),
277
Протокол SSL, 177
Процесса установки идентичности
ASP.NET, 275
Р
Расширение привилегий, 55, 86, 262
Расшифровывание, 155
Регистрация
событий, 323
файла пользователя, 323
Регулярная смена пароля, 25
Режим
обратной связи шифра (ОСШ), 158
просмотра, 131-135
сцепления блоков шифра (СБШ),
158
электронного кодировочного листа
(ЭКЛ), 158
Ривест, Рональд, 164
с
Секретный вопрос, 30-34, 40-41, 50
Симметричный алгоритм, 156, 157, 172
Синтаксис SQL, 239
Синтаксическая ошибка, 317
Система аутентификации Windows, 66
Событие интерфейса WMI, 324
Сообщение об ошибке, 56
Сохраненные процедуры, 273, 279, 292,
306
Спаминг, 3
Спецификация цифровой подписи XML,
348
Справочная аутентификация, 66-68
Стандарт шифрования данных, 159
Строка запроса URL,46
Структура сеанса, 120, 144
Счетчик посещений, 144, 147, 149
т
Тайм-аут неиспользуемых сеансов, 143
Текстовый файл, 270, 278
у
Условие членства, 369, 371
Утечка информации, 54, 55, 58, 65, 112-
113, 117, 119, 124, 131, 157, 176,
178, 185, 187, 189, 195, 207, 262,
271, 274. 280, 291, 310, 315, 318,
Утечка через канал, 155
Уязвимость пользователя, 155

438 Предметный указатель
Ф
Физическая атака, 155
Фиксация сеанса, 112-113, 117, 124, 126,
131, 136
Форма регистрации, 57, 104
х
Хранение
паролей,19
состояния сеанса на сервере, 119
Хэш, 20, 21, 51, 170, 178, 180-185, 198,
202
для инкапсуляции данных, 235, 252,
255
Хэш-функция, 21
ц
Целостность данных, 154, 156, 200
Централизация кода, 213
Централизованная база данных, 324
Цифровая подпись, 115, 332, 347-352,
355-356, 358
ч
«Человек-в-середине», 54, 65, 112, 118,
139, 157, 176, 178, 185, 189, 195
ш
Шифр данных, 338
Шифр, 155, 157, 159, 163, 164, 177
Шифрование HTML, 232
Шифрование, 153-160, 163-165, 170, 176-
178, 186, 189, 219, 227, 229, 232,
252, 255-256
э
Эксплицитная авторизация, 99
Электронная почта, 34, 35
Энтропия, 186

За последние несколько лет Syngress опубликовал огромное
количество бестселлеров, среди которых такие книги,
как «Настройка ISA Сервера 2000» Тома Шиндера («Configuring
ISA Server 2000», Tom Shinder), «Сетевая система 2.0. Система
обнаружения вторжении» Бранена Касвелла и
Джей Бил («Snort 2.0 Intrusion Detection», Brian Caswell and Jay Beak)) и
«Разборщик эфирных пакетов» Анжелы Орбах и Гилберта Римиреза
(«Ethereal Packet Sniffing», Angela Orebaugh and Gilbert Ramirez)...
Действительно ли защищены
Ваши web-приложения?
Данное издание уникально. В нем описаны разнообразные виды атак, угрожающих web-приложениям. Эти угрозы
связаны с ошибками при предоставлении полномочий пользователей и авторизации их; при шифровании
конфиденциальных данных; при установке индивидуальных уровней доступа; при обеспечении безопасности с
помощью XML Для каждого вида атаки даны несколько вариантов решений и настроек системы.
Авторы привели примеры конкретных записей для программистов, а также подробности настройки системы для каждой
из описанных угроз
Понимание опасностей, которые грозят вашим
приложениям:
■ Узнайте о том, как вести продуманную политику
распределения паролей и управления пользователями
■ Внедрите безопасные процедуры восстановления
паролей, а также узнайте подробности о том, как
правильно использовать систему секретных вопросов
во время этой процедуры.
■ Создайте систему надежной аутентификации и
авторизации пользователей, используя преимущества
продвинутых опций ASP.NET.
■ Ограничьте возможности для сбора
идентификационной информации и атак, основанных
на подборе пароля.
■ Аккуратно управляйте сессиями и научитесь создавать
надежные маркеры для аутентификации
пользователей.
■ Освойте принципы шифрования ASP NET и применяйте
симметричное и асимметричное кодирование для
особо важных данных.
■ Аккуратно зашифровывайте и сохраняйте секретные
данные в каталоге, файле или особом участке
приложения.
■ Поставьте фильтр на "опасные" символы, которые
могут быть введены злоумышленниками. Этот метод
поможет предотвратить вмешательство в коды SQL,
прослеживание связей между частями системы,
межсайтинговый скриптинг и другие атаки на
приложение.
■ Изучите особые приемы, например метод
информационного поиска и предварительного
преобразования данных, чтобы контролировать
попытки ввода "опасных" данных перед проведением
атаки.
Прочитав эту книгу, вы сможете
использовать онлайн-ресурсы:
■ Обширную web-страницу FAQ, в которой
собраны ключевые вопросы, рассматриваемые в этой
книге.
■ Форум "Спросите у автора", где авторы
книги выкладывают обновленные ссылки
на web-сайты по данной теме
■ Доступные для загрузки в режиме онлайн
электронные буклеты:
Stealing The Network: How to Own a
Continent: Product of Fate: The Evolution of
a Hacker
Special Ops. Host and Network Security for
Microsoft, Unix, and Oracle: Hacking
Custom Web Applications
CYA:Secu ng US: Configuring Advanced
Web Server Security
IT Ethics Handbook: Programmers and
Analysis
www.nph.ru www.syngress.com
S Y N R E S S®
The Definition of а
Serioifs Security Library1'
NEW
PUBLISHING
HOUSE
9»7 8 5 9 6 4 "З О О 6 9 4