Как убедиться, что HTTP_REQUEST исходит из правильного места?

Question

Я узнаю, что HTTP_REFERER или любой заголовок HTTP-запроса могут быть поддельными и ненадежными.

REMOTE_ADDR надежен, хотя.

Итак, как я могу убедиться, что входящий вызов HTTP_REQUEST поступает с веб-сайта, который я в белый список?

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

Answer 1

В общем случае вы просто не можете это сделать.Вы полностью во власти клиента.Вы можете сделать это сложнее, проверив реферера, но не невозможно.

Answer 2

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

См. Также этот вопрос по HTTP_REFERER

Answer 3

Я не использовал это на практике, поэтому могут быть проблемы с практичностью, на которые я не рассчитывал, но думал, что все равно внесу эту идею. Если я правильно интерпретирую, это похоже на (если не совпадает с) идею, опубликованную @Seldaek.

1. Ваш сервер генерирует уникальный идентификатор для каждой подачи страницы и встраивает идентификатор на страницу.
2. Сервер хранит идентификатор и IP-адрес Клиента.
3. js на клиенте помещает идентификатор в своем запросе на сервер и отправляет запрос.
4. Когда Сервер получает запрос js от Клиента, он отвечает только в том случае, если пара IP / ID совпадает с парой в файле (см. # 2).
5. Через некоторое указанное время (и / или после окончания сеанса браузера) срок действия записей идентификатора / IP-адреса истекает.

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

Могут также возникнуть проблемы, если по какой-то причине IP-адрес вашего посетителя изменится между тем, когда страница обслуживалась, и когда был отправлен запрос js.

По сути, ваш сервер говорит: «Я не буду обслуживать ваш запрос js, если вы не обладаете данными со страницы, которую я недавно обслуживал, и вы пришли (насколько мне известно) из того места, где я обслуживал эту страницу. "

Answer 4

так, как я могу обеспечить входящий HTTP_REQUEST вызов поступает от сайт, который я в белом списке?

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

Answer 5

Поскольку @Billy говорит, что это просто невозможно, вы думаете о механизме ответа на запрос в интернете неправильно.

Например, у меня есть код js, который будет отправлять с сайта клиентана сервер.(что-то вроде снайпера, кроссплатформенного).

Я предполагаю, что вы говорите, что у вас есть какой-то JavaScript-код, размещенный на каком-то сайте в вашем «белом списке», который перенаправляет пользователя на ваш сайт,На вашем веб-сайте вы хотите проверить, пришел ли пользователь с сайта, внесенного в «белый список»?

Помимо настройки файла cookie (может быть невозможным - для разных доменов), вам может показаться, что это сложно.Вы смотрели на OpenID ?Если вы можете опубликовать более подробную информацию, решение может быть более очевидным.

Answer 6

Все заголовки http могут быть подделаны.

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

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