Безопасность сетей

  0f1a9e67   

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


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

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

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

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

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

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

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


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

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

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


Содержание раздела