Один iPhone-клиент, много IP-адресов?

Question

Приложение для моего iPhone получает доступ к серверу через API REST-ish. Я использую сеансы, которые связаны с IP-адресом клиента, чтобы предотвратить перехват сеансов. Но я заметил некоторые странные последовательности запросов в журналах моего сервера с определенных клиентских устройств. Что происходит, так это то, что один и тот же клиент запрашивает разные URL на моем сервере с разных IP-адресов. Типичная последовательность выглядит примерно так:

ipaddr1: POST /users/foo/login -- grants a session linked to ipaddr1
ipaddr2: GET /users/foo/resource -- 401 Not Authorized (IP address mismatch in session)
ipaddr1: POST /users/foo/login -- grants a session linked to ipaddr1
ipaddr2: GET /users/foo/resource -- 401 Not Authorized (IP address mismatch in session)
ipaddr1: POST /users/foo/login -- grants a session linked to ipaddr1
ipaddr2: GET /users/foo/resource -- 401 Not Authorized (IP address mismatch in session)
...

и т. Д., Где эти запросы приходят примерно через 3 секунды. Иногда в игре одновременно может быть до 4 IP-адресов!

На стороне клиента я просто использую NSURLConnection для запроса каждого ресурса, поэтому я не думаю, что это что-то, что я делаю в своем коде.

Кто-нибудь видел что-нибудь подобное раньше? Может быть, это какая-то странная прокси-штука?

Answer 1

У меня сложилось впечатление, что в большинстве сетей используется простой NAT; проксирование вышло из моды, так как большая часть данных больше не может быть кэширована (наш университет находится в процессе отключения своего прокси-сервера; в последний раз я проверял, что они отключили кэширование, потому что большая часть пропускной способности для таких вещей, как YouTube, в любом случае).

С другой стороны, пару лет назад для мобильных сетей все еще было довольно распространенным использование прокси-серверов "транскодирования" (см. "Управление кэшем: без преобразования"). Это существует исключительно для увеличения использования мобильного интернета на устройствах с дерьмовыми браузерами, которые иначе не могли бы отображать «популярные» сайты. Некоторое время назад я протестировал HTTPS на различных операторах и нашел тот, где HTTP CONNECT настроил какой-то NAT (предположительно, чтобы уменьшить издержки на проксирование), но сделал это неработающим способом, так что соединение не было установлено. Отключение прокси заставляет вещи работать.

Возможно, это прокси, который использует один блок для GET и другой для POST? Или он хэширует запрос / конечные точки соединения / и т.д., чтобы узнать, с какого IP-адреса его отправлять?

Если вы хотите узнать, что происходит, попробуйте связаться с вовлеченными пользователями или выполнить whois поиск соответствующих IP-адресов.

<ч />

В общем случае нежелательно привязывать сеансы к IP-адресам. Я знаю несколько сайтов (токены Atlassian Crowd "SSO" предположительно привязаны к IP-адресам); лучшие из них делают выбор (на ум приходит Livejournal). Лучшие из них используют HTTPS.

HTTPS дополнительно останавливает злоумышленников от кражи паролей пользователей (и пользователи будут повторно использовать пароли, поэтому даже если ваш сайт не критичен для безопасности, вы никогда не должны передавать пароли в незашифрованном виде.

Я бы просто полностью переключился на HTTPS; это не сложно, и SSL-сертификаты не дорогие (для ваших целей может быть достаточно бесплатных сертификатов StartCom "StartSSL").

Если HTTPS действительно слишком сложная работа, при условии, что вы используете собственный код управления сеансом, нетрудно вернуть случайный ключ MAC при входе в систему и подписать будущие запросы, используя ключ (и порядковый номер, чтобы предотвратить повторы) , Все еще есть перехват в реальном времени и MITM-атаки.

Если вы используете HTTPS для входа в систему, но не для других запросов, проблема, вероятно, заключается в том, что HTTP проксируется, а HTTPS - нет (поскольку проксирование вообще не приносит пользы HTTPS).

Answer 2

Вы не можете ожидать поступления запросов с одного и того же IP-адреса.IPhone может циклически пересылать запросы через ряд сетей WiFi, 3G, EDGE и GPRS.Если существует проблема с хай-джекджем сеанса, используйте SSL.

^{При этом поведение, которое вы видите, не является типичным;iPhone должен отключить WiFi на 3G только в том случае, если сеть WiFi выходит из строя (и то же самое для 3G против EDGE и EDGE против GPRS)}