如何确保 HTTP_REQUEST 来自正确的地方?

发布于 2024-10-09 23:20:03 字数 234 浏览 6 评论 0原文

我了解到 HTTP_REFERER 或任何 HTTP 请求标头都可能是假的且不可靠。

不过 REMOTE_ADDR 是可靠的。

那么,如何确保传入的 HTTP_REQUEST 调用来自我列入白名单的网站?

例如,我有一个将从客户端站点发送到服务器的 js 代码。 (类似于狙击手,跨平台)。但是,我只允许在几个网站上发生这种情况。不是其他人。因此,即使其他人复制代码并将其放到他们的网站上,它也不会起作用。

I learn that HTTP_REFERER or any HTTP request header can be fake and not reliable.

REMOTE_ADDR is reliable though.

so, how can I ensure the incoming HTTP_REQUEST call is coming from a website that I white-list?

For example, I have a js code that will send from client site to server. (something like a sniper, cross platform). however, I only allow this happen from several websites. Not others. so, even other people copy the code and put onto their website, it won't work.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

往日情怀 2024-10-16 23:20:03

一般情况下你根本做不到。你完全受客户摆布。您可以通过检查推荐人来使其变得更加困难,但并非不可能。

In the general case you simply can't do it. You are entirely at the mercy of the client. You can make it more difficult by checking the referrer, but not impossible.

望她远 2024-10-16 23:20:03

可靠地做到这一点的唯一方法是让所有这些几个网站为每个用户生成唯一的令牌,类似于如何保护自己免受CSRF 攻击。然后,令牌将与脚本的请求一起发送,并且您的服务器需要有一种方法来检查令牌的真实性与其他网站的真实性。不用说,除非您控制所有站点,否则这很可能是不可能的。

另请参阅有关 HTTP_REFERER 的问题

The only way to do this reliably is to have all those several websites generate unique tokens for every users, similarly as how you protect yourself from CSRF attacks. The tokens would then be sent along with the request by your script, and your server would need to have a way to check the token for authenticity against the other websites. Needless to say this is very likely impossible unless you control all sites.

See also this question on HTTP_REFERER

还如梦归 2024-10-16 23:20:03

还没有在实践中使用过这个,所以可能存在我没有指望的实用性问题,但我想无论如何我都会贡献这个想法。如果我解释正确,这与@Seldaek 发布的想法类似(如果不相同)。

  1. 您的服务器为每个页面服务生成一个唯一的 ID,并将该 ID 嵌入页面中。
  2. 服务器存储 ID 和客户端的 IP 地址。
  3. 客户端的js将请求中的ID放入到服务器并发送请求。
  4. 当服务器收到来自客户端的 js 请求时,仅当 IP/ID 对与文件中的匹配时才会响应(请参阅 #2)。
  5. 经过一段指定时间(和/或浏览器会话结束时),ID/IP 条目将过期。

如果共享访问者 IP 地址的人(可能两者都在同一个 NAT 框后面)实时劫持另一个访问者的会话,这可能是伪造的,但它至少会阻止某人创建另一个搭载您服务器服务的网页。

如果出于某种原因,访问者的 IP 地址在提供页面和发送 js 请求之间发生变化,也可能会出现问题。

基本上,你的服务器会说“除非你拥有我最近提供的页面中的数据,并且你来自(据我所知)我提供该页面的位置,否则我不会为你的 js 请求提供服务。”

Haven't used this in practice, so there might be practicality issues I wasn't counting on, but thought I'd contribute the idea anyway. If I interpret correctly, this is similar to (if not the same as) the idea @Seldaek posted.

  1. Your Server generates a unique ID for each page-serve and embeds the ID in the page.
  2. Server stores the ID and the Client's IP address.
  3. The js on the client places the ID in its request to the Server and sends the request.
  4. When the Server receives the js request from the Client, it only responds if the IP/ID pair matches one that is on-file (see #2).
  5. After some specified time (and/or when the browser session ends), the ID/IP entries expire.

This could perhaps be faked if a person sharing the visitor's IP address (perhaps both are behind the same NAT box) hijacks another visitor's session in real-time, but it will at least prevent someone from making another web page which piggybacks on your server's service.

There could also be issues if, for some reason, your visitor's IP address changes between when the page was served and when the js request was sent.

Basically, your server is saying "I will not service your js request unless you possess the data from a page I recently served and you are coming from (to the best of my knowledge) the place to which I served that page."

み青杉依旧 2024-10-16 23:20:03

所有 http 标头都可以伪造。

如果您只是接受来自远程服务器的通信(并且没有将客户端浏览器重定向到您的服务器),那么您可以在该远程服务器和您的服务器之间设置 VPN,或者您可以更改防火墙配置以仅允许来自远程服务器的通信。特定的 IP 地址集。然而,即使是后者也可能被愿意走那么远的人伪造。

如果客户端浏览器要么被重定向到您的服务器,要么从您的服务器加载文件,那么您绝对无能为力。

All http headers can be faked.

If you are just accepting communication from the remote server (and not having a client browser be redirected to your server) then you can either set up a VPN between that remote server and yours or you can change your firewall config to only allow communication from a specific set of IP addresses. However, even the later can be faked by people willing to go that far.

If the client browser is the one either being redirected to your server or loading the file(s) from your server then there is absolutely nothing you can do.

不醒的梦 2024-10-16 23:20:03

正如@Billy 所说,这根本不可能,您错误地考虑了互联网的请求响应机制。

例如,我有一段js代码
将从客户端发送到服务器。
(比如狙击手,十字
平台)。

我假设您所说的是您的“白名单”上的某个网站上提供了一些 javascript 代码,这些代码将用户重定向到您的网站。您想在您的网站上检查用户是否来自“白名单”网站?

除了设置 cookie(可能不可能 - 跨域)之外,您可能会发现这很困难。您看过 OpenID 吗?如果您可以发布更多详细信息,解决方案可能会更明显。

As @Billy says this simply isn't possible, you're thinking about the internets' request response mechanism incorrectly.

For example, I have a js code that
will send from client site to server.
(something like a sniper, cross
platform).

I assume what you're saying is that you have some javascript code served up on some website on your 'whitelist' which redirects the user to your website. Its on your website that you want to check that the user came from the 'whitelisted' site?

Aside from setting a cookie (might not be possible - cross domains) you might find it tough. Have you taken a look at OpenID? If you can post more details a solution may be more obvious.

扬花落满肩 2024-10-16 23:20:03

那么,如何保证传入
HTTP_REQUEST 调用来自
我将网站列入白名单?

我认为,如果您签署每个请求(来自白名单),则该请求仅(一次)有效。我认为使用 uniqid 是安全的(足够了吗?)。

so, how can I ensure the incoming
HTTP_REQUEST call is coming from a
website that I white-list?

I think if you sign every request(from whitelist) which is valid for that request only(once). I assume using uniqid for this is safe(enough?).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文