Запретить человеку посередине (например, прокси) сервер притворяться что-то не

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

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

Возможно, нужна некоторая криптография?

источник

2012-03-05 paulius_l

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

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

Хорошо настроенные прокси-серверы позволят туннелировать трафик HTTPS. Это не должно быть проблемой.

источник

2012-03-05 09:32:48

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

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

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

Мне кажется, что вы пытаетесь разрешить только одному приложению доступ к вашему веб-сервису. Один из способов сделать это - TLS с аутентификацией клиента. Для этого клиент (ваше приложение) должен иметь свою собственную пару сертификатов частного ключа, и сервер будет разрешать доступ только в том случае, если доказана право собственности на закрытый ключ. Он использует ту же самую PKI, что и проверка сервера по умолчанию, только наоборот.

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

Большинство серверов приложений должны иметь возможность обрабатывать аутентификацию клиента. Дополнительная информация here в разделе «Клиентское удостоверение подлинности TLS».

источник

2012-03-07 16:40:38

Запретить человеку посередине (например, прокси) сервер притворяться что-то не

ответ

Смежные вопросы