在PHP中从XMLHttpRequest获取请求URL

时间：2013-11-13 12:41:29

标签： javascript php ajax

我遇到了一些困境，我正在编写一个JavaScript，将我的一个论坛的数据发布到运行PHP的服务器，然后决定输出一些不同的JS，具体取决于请求的URL从

我一直在为JavaScript的XHR添加一个GET参数，但是这个参数可能是伪造的，并且无法提供我正在寻找的安全性。

我正在寻找一个包含请求URL的超全局PHP变量（我查阅了手册，但我很难理解解释的含义）或任何其他方法来检测URL。

提前致谢...

3 个答案:

答案 0 :(得分：0)

您可能正在寻找$_SERVER['HTTP_REFERRER']

http://php.net/manual/en/reserved.variables.server.php

请注意，因为这不是确定请求有效性的安全方法，但可以完成工作。

答案 1 :(得分：0)

您应该使用超全局$ _SERVER变量。它包含您需要的一切。

以下是您需要的示例：http://webcheatsheet.com/php/get_current_page_url.php

答案 2 :(得分：0)

您在寻找什么样的安全措施？阻止用户伪造请求？他们可以通过伪造请求实现什么？例如

  1. 他们可以为自己弄乱网站布局吗？
  2. 他们可以访问不应该被允许的数据吗？
  3. 他们可以写出不应该被允许的数据吗？

    4. 如果答案是第一个，请不要理会。无论如何，他们几乎可以在客户端做任何事情。如果您为伪造的请求提供不正确的数据，但允许他们以除损害之外的其他方式获取该数据？

    您可以做的最好的事情是为您需要的对象创建restful api，实现安全的用户处理，并在每次请求时检查对象的正确用户授权。它那样清洁，你不会搞砸它。

    如果答案是第二个或第三个，那么问题就比你有问题了。一个简单的超全局变量是不够的。如果您实施某种身份验证（例如like this）和用户处理，您将拥有全局变量，因此您自己的变量将是冗余的（并且不太复杂）。如果您有安全问题，我假设您已经以某种方式验证了用户身份。您可以检查用户是否在XHR中经过身份验证（并且有权访问内容），就像您在＆＃34; full＆＃34;中检查一样。请求。

    同样从全局变量中猜测用户状态会损害应用程序的可用性。考虑一下。

    1. 用户同时打开两个类似页面，同时使用此脚本。 （标签A和标签B）。
    2. 这两个请求都将给定的超全局设置为不同的值，因此仅应用第二个值。 （让我们说选项卡A将值设置为A，然后选项卡B将值设置为B）。
    3. 第一个标签中的脚本生成XHR。这不是它所期望的。这是不好的。 （由于超全局已经是B，它返回用于选项卡B的内容。）

      4. 你能看到问题吗？

      编辑：看到您的评论，我还不确定您的具体情况和需求是什么。我能够扣除一些东西：

      我们假设您的域名为good.com，还有其他域bad.com

      您的方案：

      1. 您通过JavaScript发送POST（不是GET（？））请求（到good.com/posthere）
      2. 返回一些JavaScript
      3. 我不确定返回的JavaScript会发生什么，也许会以某种方式执行，但我不知道如何。

        4. 您想要阻止：

        1. 毫无戒心的受害者在bad.com上打开一个页面
        2. bad.com上的页面向您的网址（good.com/posthere）
          3. 发出POST请求
        3. 发回与发送回同源请求相同的JavaScript
        4. 浏览器在bad.com
          5. 页面上执行该javascript
        5. 这会诱使用户认为他/她正在使用good.com，因为他/她可以与good.com
          6. 的用户聊天

          我是对的吗？我错了什么？我错过了什么吗？

          向您的网站发送请求的恶意用户与欺骗毫无戒心的用户向您的网站发送请求的恶意网站之间存在很大差异。

          例如，如果网站是恶意网站，则浏览器中会内置某些安全措施，例如Same-origin policy。如果用户是恶意的，他可以做任何他想要客户端的事情，绕过浏览器提供的任何保护。他甚至不需要浏览器。他可以使用cURL并向任何地方创建任何请求。

          我会假设您有毫无意识的用户意外访问bad.com而不是good.com。

          那该怎么办？

          您可以做一些事情，我会列出一些可能适用于您的情况。您可以将它们组合使用以获得更多保护层。

          1。不要通过电汇发送JavaScript！

          实际上很诱人，发送可嵌入资源是内置于每个现代（不太现代）浏览器中的Same-origin policy的例外，一个毫无戒心的用户可能正在使用它。阅读我已经链接过的文章，阅读整篇文章并仔细阅读：它解释了非常重要的事情。

            

          同源政策限制从一个来源加载的文档或脚本如何与来自另一个来源的资源进行交互

          这意味着它可以阻止在bad.com网站上执行的JavaScript访问good.com中的内容。正是你想要的。

          然而，有一些例外。任何可嵌入的东西都可以嵌入，而不是以不同的方式访问。例如，可以使用<script src="good.com/js">请求并执行JavaScript（！）。此标记可以由JavaScript创建。

          当然这只是一个GET请求，而不是POST，但我不确定POST请求是否有解决方法。

          发送JSON

          发送safe JSON，使用JavaScript解析它并根据JSON执行客户端内容是一种很好的方法。

          例如：

          var json = '{"isWordfiltered":true,"otherProperty":5}', // this is the response from the server
    obj = JSON.parse(json);

if (obj.isWordfiltered) {
    alert("You wanted to send some bad words. Nobody likes bad words, and therefore nobody likes you!");
}

          这需要您修改JavaScript代码。如果您不是程序员和/或不了解JavaScript，这可能是不可取的。

          2。检查HTTP Referer

            

          HTTP referer（最初是引用者的拼写错误）是HTTP头   标识网页地址的字段（即URI或IRI）   链接到所请求的资源。通过检查引用者，   新网页可以查看请求的来源。

          嘿，这听起来也像你想要的东西！您可以检查请求是否来自您的网页或其网页。 referer不是来自你的domain =被拒绝的请求。很简单。

          您可以通过访问$_SERVER['HTTP_REFERER']。

          在PHP中执行此操作

          参与者可以伪造，但这需要一定程度的用户同意（E.G.安装一些扩展名），这意味着用户不会给予。当然，他可以积极参与攻击并做任何事情，但我认为这不是你想要准备的情况。

          在某些浏览器中可以禁用引用者。在您的情况下，这是一个更大的问题。大多数用户都会启用引用，但是每隔一段时间您就会遇到一个用户因为安全原因而禁用了该用户，或者默认情况下禁用了引用的浏览器（尽管这种情况非常罕见） ）。可能以某种方式警告用户（我不建议使用alert()方法，因为它是丑陋和侵扰性的）是一个好主意，他需要启用引用者。

          所以

          • 如果引荐来自您的域名，请接受请求。
          • 如果引用者是空的。告诉用户他应该启用referer。
          • 如果引荐者不是来自您的域名，请拒绝该请求。

          告诉您想要查看引用者的一个缺点是您告诉您检查它，因此攻击者可能能够利用此信息对他有利。所以你可能想要这样做（更简单）：

          • 如果引荐来自您的域名，请接受请求。
          • 否则请求

          3。 （不要）使用CSRF令牌来防止伪造的帖子

          你可以implement a CSRF token来防止一些伪造，但在你的情况下，这是不够的，也不容易正确实施（在每个后续帖子上更改令牌等），所以我不建议这只是你阅读它的解决方案。

          4。 （不要）使用会话令牌或cookie来查看用户是否访问过您的网站

          请注意，如果您只检查用户已访问过您网站并在那里有活动会话的令牌，您可以在$_SESSION或{{3}中设置一个标志（布尔值）短期到期。如果用户最近尚未访问过您的网站，您可以拒绝该javascript的请求。

          虽然这看起来不错，但它很容易解决。例如，通过不可见的<iframe>。

          请记住，在实施第一个和/或第二个解决方案之后，您可能会放弃并认为您赢了，现在您的聊天是安全的。

          事实并非如此。总有新的攻击，不同类型的攻击等。

          例如，如果攻击者是Linux术士，他可以在他自己的网络服务器上召唤一个来自地狱的黑暗代理，并使用它来伪造HTTP请求中的所有内容。像这样：

          1. 他将javascript更改为发布到bad.com/proxiedposthere。
          2. 服务器端的php（或其他任何内容）以修改请求的HTTP标头（包括REFERER）的方式编写，并将其转发到good.com/posthere。
          3. 您的服务器发现它是有效请求，并向其服务器返回有效回复。
          4. 然后他修改了对他的品味的反应（例如，将响应中的所有URL-s切换到发布到他们的服务器而不是你的服务器等）。
          5. 他将回复返回给客户的浏览器。

            6. 你不能完全阻止这一点。您可以禁用代理服务器的IP，但攻击者可以再次将其代理隐藏在其他代理之后。无限。

            一个例子是笑话网站$_COOKIE。它充当代理，并在网站的文本中用淫秽的东西切换很多东西。它还会将链接切换为指向pornolize.com。它只是一个幼稚的笑话网站，但它是操纵响应的一个很好的例子。

            所谓的网络代理以同样的方式工作。他们（希望）不会以有害的方式操纵请求和响应，但他们也会切换链接。

相关问题
最新问题