Один клиент 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).

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

Возможно, это прокси-сервер, который использует одну коробку для GET и другую для POST? Или он хэширует конечные точки запроса/подключения/etc, чтобы узнать, какой 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 может циклически отправлять запросы через несколько сетей Wi-Fi, 3G, EDGE и GPRS. Если сессия highjacking является проблемой, используйте SSL.

^{Это, как говорится, поведение, которое вы видите, не типично; iPhone должен отключить Wi-Fi до 3G, если сеть Wi-Fi снижается (и то же самое для 3G против EDGE и EDGE против GPRS)}