RESTful безопасность приложений - PullRequest
Новая
       10

RESTful безопасность приложений

4 голосов
/ 25 августа 2011

Я написал фреймворк для C ++, который взаимодействует с серверным приложением, используя RESTful API.Данные, передаваемые между клиентом и сервером, в настоящее время используют простой (длиной 32 бита) простой пароль, который известен (жестко задан) как на сервере, так и на клиенте.

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

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

Может ли кто-нибудь изложить стратегию / методологию (или передовой опыт?)) реализовать такую ​​безопасность - в том числе, если мне нужно что-то еще, чтобы использовать HTTPS вместо HTTP - случайно (может показаться глупым вопросом), но какую дополнительную безопасность HTTPS предлагает по HTTP в такой схеме, как у меня?описанный выше?

Меня особенно интересует:

  1. RESTful аутентификация / авторизация
  2. Безопасное взаимодействие с каждым клиентом - чтобы сервер мог идентифицировать попытки мошеннических клиентовпытаясь «притвориться» другим клиентом.Например, instanceA дочернего приложения НЕ ДОЛЖЕН иметь возможность маскироваться под instanceB, например.

Ответы [ 2 ]

2 голосов
/ 25 августа 2011

Сосредоточьтесь в первую очередь на разумных мерах безопасностидля предотвращения атак «человек посередине» У всех пользователей (или приложений в вашем случае) есть имя пользователя и пароль, которые используются для проверки личности - проверка выполняется по HTTPS Проверенные пользователи получают ограниченный по времени ключ сеанса, который вызывает повторную проверку по истечении срока действия Администратор sys может отозвать любой сеанс в любое время Все недействительные входы в систему отслеживаются и оповещения отправляются администратору системы, чтобы мы могли видеть атаку в процессе.
Restful Authentication

Наше приложение имеет API в стиле REST, который удаленный пользовательский интерфейс использует, как и сторонние (SAP / Excel ...).Аспект REST в значительной степени ортогональн, но мы используем модуль аутентификации Ruby RESTful.Ключевым моментом является то, что сеансы - это ресурсы, которые могут быть созданы и уничтожены с помощью действия с набором / сессий ресурсов.Сеанс сопоставляет клиента (пользователя или приложение) с аутентифицированным сеансом.

Хорошую статью о фоновой аутентификации RESTful можно найти здесь .Мне особенно нравится этот экстракт ...

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

В Stackoverflow уже есть несколько хороших ресурсов.Взгляните здесь например


Реализация HTTPS

Вы, вероятно, в значительной степени знаете, что вам нужно для HTTPS

  • Сертификат - мы используем GoDaddy - ужасный веб-сайт, но довольно дешевый и надежный.Мы используем глобальный сертификат для покрытия всего нашего домена

  • Веб-сервер, который может обрабатывать HTTPS - все они в наши дни мы используем NGINX, потому что он быстрый, надежный и простой в настройке

  • Соответствующая клиентская библиотека, которая может обрабатывать HTTPS-соединения

0 голосов
/ 26 августа 2011

У вас все есть подробный, но общий ответ, позвольте мне уточнить ваши особенности:

  • Вам не нужны сертификаты от третьих лиц, вы можете выдать их самостоятельно.
  • Пока вы работаете, сделайте сертификат для сервера, а также для проверки клиентами. Это здорово против человека в середине атаки.
  • Одним из преимуществ SSL (S в HTTPS) являются установленные инструменты для управления ключами, вам не придется заново изобретать колесо. (где вы сейчас храните пароль на клиенте?)
  • С уникальным сертификатом для каждого развертывания клиента вы можете отказаться от дальнейшей аутентификации.
  • Если вы хотите добавить еще один фактор (а также honeypot для того, кто в конечной точке пытается войти с чужим паролем), вы можете добавить HTTP Basic, это совершенно безопасно в HTTPS.
  • Сервер, завершающий SSL-соединение, имеет доступ к учетным данным сертификата. Если вы используете для этого выделенный прокси-сервер, он должен добавить соответствующую информацию в запрос в качестве заголовка.
...