- •Информационная безопасность.
- •Определение безопасности как процесса.
- •Категории атак.
- •Атаки хакеров.
- •Конфиденциальность.
- •Идентифицируемость.
- •Необходимость и важность политики.
- •Информационная политика.
- •Политика безопасности.
- •Процедуры управления пользователями.
- •Межсетевые экраны.
- •Межсетевые экраны прикладного уровня.
- •Межсетевые экраны с пакетной фильтрацией.
- •Гибридные межсетевые экраны.
- •Ответные действия ids (03.10.11)
- •Понятие трансляции сетевых адресов
- •Что такое трансляция сетевых адресов?
- •Примечание
- •Частные адреса
- •Примечание
- •Статическая nat
- •Динамическая nat
- •Трансляция сетевых адресов
- •Вопросы безопасности беспроводных соединений:
- •Какие службы следует предоставлять
- •Примечание
- •Шифрованная электронная почта
- •Примечание
- •Интернет
- •Внутренний доступ в интернет
- •Примечание
- •Внешний доступ к внутренним системам
- •Внимание!
- •Службы контроля
- •Примечание
- •Какие службы не следует предоставлять
- •Разработка архитектуры соединений
- •Доступ через один канал
- •Многоканальный доступ к одному провайдеру
- •Доступ с одной точкой присутствия
- •Доступ с несколькими точками присутствия
- •Вопрос к эксперту
- •Многоканальный доступ к нескольким провайдерам
- •Выбор провайдеров
- •Примечание
- •Адресация
- •Вопросы для самопроверки
- •Проектирование демилитаризованной зоны
- •Определение демилитаризованной зоны
- •Системы, размещаемые в dmz
- •Примечание
- •Примечание
- •Системы, доступные из внешней среды
- •Системы контроля
- •Подходящие архитектуры dmz
- •Примечание
- •Маршрутизатор и межсетевой экран
- •Один межсетевой экран
- •Два межсетевых экрана
- •Примечание
- •Разработка партнерских сетей
- •Работа с партнерскими сетями
- •Настройка
- •Службы электронной коммерции
- •Различия между службами электронной коммерции и обычными службами dmz
- •Примеры служб электронной коммерции
- •Продажа товаров
- •Предоставление конфиденциальной информации
- •Важность доступности
- •Вопросы взаимоотношений "компания-клиент"
- •"Компания-компания"
- •Примечание
- •Всемирное время
- •Удобство клиента
- •Убытки вследствие простоя
- •Решение проблемы доступности
- •Реализация безопасности клиентской стороны
- •Безопасность соединений
- •Хранение информации на компьютере клиента
- •Вопрос к эксперту
- •Отказ от выполненной операции
- •Вопросы для самопроверки
- •Реализация безопасности серверной части
- •Информация, хранимая на сервере
- •Защита сервера от атак
- •Расположение сервера
- •Примечание
- •Конфигурация операционной системы
- •Конфигурация веб-сервера
- •Реализация безопасности приложений
- •Правила разработки приложения
- •Правильные методы программирования
- •Общедоступность исходного кода
- •Управление конфигурацией
- •Примечание
- •Реализация безопасности сервера базы данных
- •Расположение базы данных
- •Примечание
- •Соединение с сервером электронной коммерции
- •Защита внутреннего доступа
- •Примечание
- •Разработка архитектуры электронной коммерции
- •Расположение сервера и соединения
- •Примечание
- •Сканирование уязвимостей
- •Данные аудита и обнаружение проблем
- •Разработка архитектуры сайта электронной коммерции
- •Практика
Правильные методы программирования
Любое приложение электронной коммерции требует некоторых усилий по работе с кодом сценариев или программ. Как правило, это особые программы, разработанные специально для конкретной среды и ситуации. Программы представляют собой основной источник системных уязвимостей, причинами которых являются ошибки, допущенные при программировании. Самой значительной ошибкой является переполнение буфера. Снизить риск проявления этой проблемы можно следующим образом:
указание ограниченного размера вводимых пользователем данных;
передача непроверенных введенных пользователем данных командам оболочки.
Если программист указывает ограничение размера данных, вводимых пользователем, то он, как правило, определяет конкретный размер переменных. Если злоумышленник об этом знает, то сможет ввести такие данные, которые вызовут переполнение буфера, с последующим получением доступа к файлам или операционной системе (в лекции 3 приведено более детальное обсуждение проблемы переполнения буфера).
Второй вопрос является частным случаем первой проблемы. Если программы вызывают команды оболочки, то вводимые пользователем данные не должны вслепую передаваться команде оболочки - они должны проверяться на соответствие данной команде.
Многие из этих ошибок можно устранить, перед тем как сайт будет введен в работу, если соответствующий код тщательно проверить. К сожалению, немногие программные проекты предусматривают достаточно времени для выполнения этого действия. По крайней мере, члены группы разработки должны быть проинструктированы по вопросам безопасности относительно этих типов ошибок перед началом программирования.
Совет
Для более полной оценки уязвимостей, имеющихся на сайте, вместо применения одного только сканера уязвимостей следует использовать сканер приложений, а также осуществлять поиск уязвимостей. Одной из таких коммерческих утилит является WebInspect от SPI Dynamics (http://www.spidynamics.com/).
Общедоступность исходного кода
Сканеры уязвимостей должны обнаружить проблемы, связанные с переполнением буфера, в широко известных программах и сценариях, перед тем как сайт будет введен в работу. Данный шаг является жизненно необходимым, так как данные уязвимости хорошо известны в сообществе хакеров и могут использоваться для проведения атак, направленных на сайт. Уязвимости к переполнению буфера в специально разработанном коде неизвестны злоумышленникам и не могут быть легко обнаруженными. Тем не менее, если атакующий сильно заинтересован в проникновении на сайт электронной коммерции, он будет использовать любую доступную информацию, чтобы найти уязвимость.
Одним из действий, которые может предпринять хакер, является проверка сценариев через веб-сайт. Правильная конфигурация веб-сервера должна ограничивать возможности хакера по выполнению этих действий, однако если на сайте есть сценарии, в конфигурации может быть допущена ошибка, которая позволит злоумышленнику просмотреть эти сценарии. Еще одним способом предотвращения просмотра сценариев является написание всего приложения на компилируемом языке (C или C++) вместо интерпретируемых языков (CGI и Perl).