Question

在我的profile.php脚本中，我有一个标记函数，允许用户标记该用户。

如果他们标记用户，则会将数据（user_id，reason等）发送到名为flag.php的文件，该文件执行所有禁止和操作。数据通过

发送到flag.php

header("Location: flag.php?user_id=___&reason=___")

然后在flag.php中，在完成所有禁止后，它会通过另一个标头将用户重定向回配置文件。用户永远不会看到flag.php。

我的flag.php安全吗？因为他们从未看过剧本？

编辑你永远不应该认为它对GET来说是安全的......要么做一个banuser功能，要么通过会话发送它。

Answer 1

不。该URL将记录在浏览器历史记录中，您刚刚禁止的用户将因禁用user_id参数而禁止任何他们想要禁止的用户。我建议您改为创建一个函数ban_user($user_id,$reason)。

Answer 2

304-redirect必须通过客户端，因此用户可以监控HTTP消息并学习如何控制flag.php。

使用$_SESSION，如果它必须存在于新页面中呢？

Answer 3

这不安全。如果知道位置（通过使用工具检查标头/请求很容易），可以在URL中输入flag.php?user_id=1&reason=bye以禁止所需的用户。甚至可以编写一个脚本，在用户ID为1到100000的循环中执行此操作。

您需要在独立脚本中执行此操作，该脚本包含在主PHP脚本中，而不是HTTP请求中。确保用户身份验证也很健壮。

Answer 4

默默无闻的安全（如没有看到剧本）是一件坏事。如果它是一个受欢迎的页面，人们会寻找系统的方法，聪明的人会尝试搞乱输入！

如果他们决定通过输入“HACK ATTEMPT！＆amp; user_id = [root_id]”

来重写某些URL变量怎么办？

PHP可能只是采用它找到的第一个“user_id”，但你可以看到它的发展方向。

Answer 5

您的代码应检查是否：

是否有一些原因可以解释为什么你不能将数据发送到flag.php，而不使用重定向，然后将它们重定向回原来的位置（如果确实，它们在某个地方而不仅仅是滥用flag.php）？

如果您发现奇怪的行为，我还建议在过程中放置验证码。

无论如何，不，它不安全。它只是要求滥用。

Answer 6

完全不安全;任何用户都可以违背自己的意愿禁止任何其他用户。研究CSRF攻击和防御。放下重定向的东西，它完全没有意义。我甚至不确定你想用它实现什么。如果用户向标记链接指向的任何地方发送请求，而不是伪造直接请求，那么你还有什么好转的吗？我不这么认为。

Answer 7

没有。由于其他答案中提到的原因，您的脚本不安全。

虽然解决方案 - 我在某些案例中使用的解决方案 - 也需要一个唯一的ID作为参数。例如：

flag.php?user_id=_______&reason=______&special_id=36a678dabc6d78a6db

special_id仅对禁止ID为user_id的用户有效。

此ID仅对一次使用有效 - 并且只对指定的ID有效。

Answer 8

如果我在开头放置一个函数，确保登录的人是管理员，如果是，则会执行该脚本。但如果登录的人不是管理员，则会重定向到主页。

这样可以安全地使用GET吗？