Электронная коммерция: требования к безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

• Контроль за санкционированными изменениями.
• Обнаружение несанкционированных изменений.

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

Примечание

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

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