在我的profile.php脚本中，我具有标志功能，该功能允许用户标记该用户。
如果他们标记用户，它将数据（ user_id ， reason等）发送到名为flag.php的文件，该文件将执行所有禁止和填充操作。 数据通过以下方式发送到flag.php
header("Location: flag.php?user_id=___&reason=___")
然后在flag.php ，在执行所有禁止之后，它通过另一个标头将用户重定向回配置文件。 用户永远不会看到flag.php 。
我的flag.php安全吗？ 因为他们从不看脚本？
编辑您永远不要以为它是安全的...去做一个banuser功能或通过会话发送它。
不。 该URL将记录在浏览器的历史记录中，并且由于user_id参数，刚被禁止的用户将能够禁止任何他们想要禁止的用户。 我建议您创建一个函数ban_user($user_id,$reason) 。
304-redirect必须通过客户端，因此用户可以监视HTTP消息并学习如何控制flag.php 。
如果必须在新页面中使用$_SESSION呢？
不安全 如果知道位置（通过使用工具检查标题/请求很容易），则只需在URL中输入flag.php?user_id=1&reason=bye即可禁止想要的用户。 甚至可以编写一个脚本，从用户ID 1到100000循环执行此操作。
您需要在独立的脚本中执行此操作，该脚本包含在主PHP脚本中，而不是通过HTTP请求。 确保用户身份验证也很可靠。
默默无闻的安全性（就像看不到脚本一样）是一件坏事。 如果这是一个受欢迎的页面，人们会在系统中寻找方法，聪明的人会尝试弄乱输入内容！
如果他们决定通过输入“ HACK ATTEMPT！＆user_id = [root_id]”来重写某些网址变量，该怎么办？
PHP可能只是使用找到的第一个“ user_id”，但是您可以看到它的运行方向。
您的代码应检查是否：
是否有某些原因导致您不能不使用重定向就将数据发布到flag.php，然后将其重定向回它们所在的位置（如果确实存在，那么它们不仅在滥用flag.php）？
如果您发现异常行为，我还建议您在此过程中输入验证码。
无论如何，不，它不安全。 它只是要求虐待。
这是完全不安全的。 可以使任何用户违背其意愿禁止任何其他用户。 研究CSRF的攻击和防御。 放掉重定向的东西，那是毫无意义的。 我什至不确定您要使用它实现什么。 如果用户将请求发送到标记链接指向的任何地方，而不是伪造直接请求，您的状况会更好吗？ 我不这么认为。
否。由于其他答案中提到的原因，您的脚本并不安全。
不过，一种解决方案-以及我在某些情况下使用的解决方案，也需要唯一ID作为参数。 例如：
flag.php?user_id=_______&reason=______&special_id=36a678dabc6d78a6db
special_id仅对禁止ID为user_id的用户有效。
该ID仅对一种用途有效-并且仅对指定的ID有效。
如果我在开头放置了一个函数，以确保登录的人是管理员，如果是，它将执行脚本。 但是，如果登录的人不是管理员，它将重定向到主页。
这样可以安全使用GET吗？
