Возможна или целесообразна трехуровневая архитектура с REST-подобной бизнес-логикой для безопасных веб-приложений? - PullRequest
0 голосов
/ 28 марта 2011

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

  • Уровень сохраняемости : Стандартная база данных (сейчас MySQL)
  • Уровень бизнес-логики : REST-подобная структура (PHP, сервлеты Java и т. Д.)
  • Уровень представления : веб-браузер, устройства Android (приложение, а не браузер) и другие

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

Задача 1:

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

Задача 2:

Если REST-процедуры выполняются в SSL, браузер должен использовать SSL для всего, что, на мой взгляд, может быть медленным и громоздким, когда в нем нет необходимости. Кроме того, SOP делает невозможным использование ajax-вызовов SSL для процедур REST из незащищенного браузера. HTTP и HTTPS считаются разными источниками, даже если это один и тот же источник, разные протоколы.

Является ли это решение жизнеспособным? Как бы я решил эти две проблемы? Или, возможно (возможно), есть ли лучшая архитектура, которую я должен изучить для моего веб-приложения. Заранее благодарим за все предложения.

Ответы [ 2 ]

0 голосов
/ 03 апреля 2011

Как оказалось, на самом деле не существует отличного решения для этого ответа. Вы можете либо защитить все с помощью SSL, либо разработать собственную систему аутентификации домашнего приготовления. Распространенным методом является отправка пользователю уникального HASH, сохранение HASH в базе данных и в файле cookie на компьютере клиента. Тогда только этот IP-адрес пользователя, User-Agent и т. Д. Будет аутентифицирован в этом cookie.

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

0 голосов
/ 28 марта 2011

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

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