4-1 Електрона комерція / e-com

Ответ. В лекции 12 приводится детальное обсуждение алгоритмов шифрования и длины ключей. Ключ SSL может иметь длину 40 или 128 бит. Длина ключа непосредственно влияет на время и усилия, необходимые для проведения атаки с применением грубой силы против зашифрованного трафика и получения доступа к информации. Принимая во внимание риски, связанные с отправкой секретных данных через интернет, настоятельно рекомендуется использовать шифрование. Тем не мене, если информация не является особо важной, нет существенной разницы между использованием 40-битного и 128-битного шифрования. Для получения доступа к информации злоумышленнику потребуется перехватить весь трафик соединения и использовать мощную вычислительную технику, чтобы попытаться использовать все возможные ключи шифрования за относительно небольшой промежуток времени (данный процесс не будет эффективным, если выполняется год). Злоумышленник, обладающий необходимыми ресурсами, скорее всего, атакует самую слабую точку, такую как хранилище ненужной информации (корзина) на рабочем месте жертвы или бумажник жертвы, если искомой информацией является номер кредитной карты.

Cookie - это небольшой фрагмент информации, сохраняемый на клиентской системе веб-сервером. К этой информации может обращаться только тот веб-сервер, который разместил элемент cookie на данном компьютере; кроме того, срок действия элемента cokie должен истекать по прошествии определенного времени (как правило, меньше года). Элементы cookie могут храниться в открытом либо зашифрованном виде. Эти элементы могут быть постоянными (не удаляться, после того как клиент закрывает обозреватель) или временными (элементы cookie не записываются на диск, но остаются в памяти, пока браузер открыт).

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

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

Совет

При размещении заказа необходимо проверять цены, если они хранятся в элементе cookie.

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

Отказ от выполненной операции

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

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

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

Вопросы для самопроверки

Два основных различия между службами электронной коммерции и обычными службами интернета заключаются в необходимости _______________ и _______________.

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

Реализация безопасности серверной части

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

С безопасностью сервера связаны два вопроса.

Безопасность информации, хранимой на сервере.

Защита самого сервера от вторжения злоумышленников.

Информация, хранимая на сервере

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

Если информация должна храниться на сервере электронной коммерции, ее необходимо защищать от несанкционированного доступа. Это можно реализовать посредством использования элементов управления доступом к файлам. Кроме того, если секретные файлы не хранятся в структуре каталогов на веб-сервере или FTP-сервере, то доступ к ним через браузер или FTP-клиент осуществить намного сложнее.

Защита сервера от атак

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

Расположение сервера.

Конфигурация операционной системы.

Конфигурация веб-сервера.

Давайте более детально рассмотрим каждый из этих аспектов.

Расположение сервера

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

Примечание

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

Сетевое расположение сервера также необходимо принимать в расчет. На рисунке 17.2 показано расположение сервера в демилитаризованной зоне (DMZ). Межсетевой экран следует настроить на разрешение доступа к серверу электронной коммерции только через порт 80 (для HTTP) и 443 (для HTTPS). Для открытого доступа к серверу электронной коммерции не нужны дополнительные службы и, следовательно, их необходимо блокировать на межсетевом экране.

Если производительность сервера электронной коммерции является жизненно важным фактором, и ожидаемый трафик сервера очень велик, полезно реализовать двойное базирование сервера (см. рис. 17.3). В этом случае один сетевой интерфейс поддерживает входящий трафик и передает ответные пакеты клиенту. Данный интерфейс располагается в демилитаризованной зоне. Второй сетевой интерфейс предназначен для передачи запросов приложений либо на сервер приложений (предпочтительно), либо напрямую в базу данных. Этот интерфейс располагается во второй DMZ или в сети сервера приложений. Данная сеть отделяется от внутренней сети организации межсетевым экраном. Ни в коем случае не следует использовать один интерфейс для интернета и для внутренней сети.

Рис. 17.2. Правильное сетевое расположение сервера электронной коммерции

Конфигурация операционной системы

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

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

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

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

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

Совет

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

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

Конфигурация веб-сервера

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

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

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

Рис. 17.4. Корректная структура корневого каталога веб-сервера

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

Сценарии CGI не должны быть видны обычным пользователям, то есть веб-сервер нужно настроить на скрытие списков каталогов, если в браузере не указан файл. Если в браузере указан сценарий CGI или Perl, сервер нужно настроить на выполнение сценария, а не на отображение кода. Обычно данный аспект настраивается в файле httpd.conf в следующих строках:

AddType application/x-httpd-cgi .cgi

AddType application/x-httpd-cgi .pl

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

Реализация безопасности приложений

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

Правила разработки приложения

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

определение требований;

системное проектирование;

разработка;

тестирование;

реализация

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

Требования безопасности следует включить в этап определения требований проекта. Эти требования включают в себя следующее:

определение секретной информации;

защита требований для секретной информации;

требования аутентификации для доступа или выполнения операций;

требования к аудиту;

требования доступности.

Если эти требования определены, то при проектировании системы можно будет выявить потенциальные проблемы. Вся секретная информация должна определенным образом защищаться. Это обуславливает наличие компонентов приложения, требующих HTTPS вместо HTTP. Для секретной информации требуется не только шифрования при передаче. Некоторые данные, например частные сведения о клиенте, требуют защиты при записи на компьютер клиента в элементах сookie. При проектировании необходимо принимать это в расчет, и в данном случае использовать шифрование элементов cookie.

Необходимо также упомянуть еще один вопрос, связанный с секретной информацией. Информация может стать секретной из-за метода, посредством которого она используется в приложении. Например, некоторые приложения передают информацию между программами с использованием URL (универсального указателя ресурсов, представляющего собой адрес веб-сайта в адресной строке браузера). Если отображается длинный URL со знаком вопроса "?", отделяющим различные значения, то приложение передает параметры другим сценариям или программам. Клиент может поменять эти параметры и изменить функционирование программ. Некоторые сайты электронной коммерции записывают выбранные покупателями товары в адресах URL. Эта информация содержит код товара, количество и стоимость. Если бы в базе данных не осуществляется проверка данных, клиенты могут изменять цену товаров. Был случай, когда клиент заметно уменьшил цену, и организация фактически продала товар по очень низкой цене. Принимая во внимание этот пример, становится ясно, что стоимость товаров является очень важной информацией. Если для передачи этой информации между сценариями или программами используется URL, значения стоимости (по крайней мере) должны проверяться в базе данных перед обработкой заказа.

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

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

Правильные методы программирования

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

указание ограниченного размера вводимых пользователем данных;

передача непроверенных введенных пользователем данных командам оболочки.

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

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

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

Совет

Для более полной оценки уязвимостей, имеющихся на сайте, вместо применения одного только сканера уязвимостей следует использовать сканер приложений, а также осуществлять поиск уязвимостей. Одной из таких коммерческих утилит является WebInspect от SPI Dynamics (http://www.spidynamics.com/).

Общедоступность исходного кода

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

Одним из действий, которые может предпринять хакер, является проверка сценариев через веб-сайт. Правильная конфигурация веб-сервера должна ограничивать возможности хакера по выполнению этих действий, однако если на сайте есть сценарии, в конфигурации может быть допущена ошибка, которая позволит злоумышленнику просмотреть эти сценарии. Еще одним способом предотвращения просмотра сценариев является написание всего приложения на компилируемом языке (C или C++) вместо интерпретируемых языков (CGI и Perl).

Управление конфигурацией

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

Контроль за санкционированными изменениями.

Обнаружение несанкционированных изменений.

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

Примечание

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

Определение несанкционированных изменений должно проводиться для каждой системы, представляющей широкой общественности данные, связанные с организацией. Главным примером здесь, без сомнения, является сайт электронной коммерции. Каждый программный компонент (сценарий или скомпилированная программа) и каждая статическая веб-страница должна постоянно проверяться на наличие несанкционированных изменений. Чаще всего это реализуется посредством использования криптографической контрольной суммы (см. лекцию 12 для более подробной информации по этому вопросу). При размещении файла на рабочей системе для него необходимо сгенерировать контрольную сумму. Периодически следует повторно генерировать контрольную сумму и сопоставлять ее с оригиналом. Если контрольные суммы оказались различными, необходимо издать соответствующее уведомление и проверить систему на проникновение злоумышленника. В нештатных ситуациях программа, выполняющая проверку, может перезагружать копию исходного файла. Для предотвращения ложной тревоги необходимо осуществлять обновление контрольной сумы в рамках процедуры управления конфигурацией.

Реализация безопасности сервера базы данных

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