$_SERVER['REQUEST_URI'] 和 header('location: ...') 的任何安全问题； [英] any security concerns with $_SERVER['REQUEST_URI'] and header('location: ...');

问题描述

我的网站有页眉、页脚和主要内容.如果用户未登录，对于主要内容，可能会显示登录表单而不是实际内容.

My website has a header, footer, and main content. If the user is not logged in, for the main content a login form may be displayed instead of the actual content.

在那个登录表单上，我将 $_SERVER['REQUEST_URI'] 写入会话变量 $_SESSION['redirect'].

On that login form I write the $_SERVER['REQUEST_URI'] in the session variable $_SESSION['redirect'].

我的登录表单后处理程序，它将用户登录，成功登录后将通过 header('location: http://myserver.com'.$_SESSION['redirect']);

My login form posthandler, which will log the user in, will send the user after successfully loggin in to this link via header('location: http://myserver.com'.$_SESSION['redirect']);

因此，如果我转到 myserver.com/somesite.php?somevar=10 它将显示正确的站点(如果您已登录).否则它将显示登录表单，但是浏览器中的地址栏仍然显示 myserver.com/somesite.php?somevar=10然后您输入您的凭据，您将被重定向到 myserver.com/somesite.php?somevar=10，然后 - 因为您现在已登录 - 完全显示.

So if I go to myserver.com/somesite.php?somevar=10 it will show the proper site if you are logged in. Otherwise it will show the login form, however the URL in the address bar in the browser still says myserver.com/somesite.php?somevar=10 Then you enter your credentials and you are redirected to myserver.com/somesite.php?somevar=10, which will then - since you're now logged in - fully display.

我不将 REQUEST_URI 值用于表单操作或作为链接 href.

I do not use the REQUEST_URI value for a form action or as a link href.

此外，我使用的任何 $_GET 变量我首先检查它们是否匹配正则表达式(通常该变量将是一个 sha1 字符串或其他随机生成的字符串只有数字和字母，没有特殊字符)，如果在 db 查询中使用 get 变量，我总是使用准备好的语句.

Also, any $_GET variables I use I first check if they match a regular expression (usually the variable will be a sha1 string or a otherwise randomly generated string of numbers and letters only, no special chars), and I always use prepared statements if the get variable is used in a db query.

我的问题是是否存在任何安全问题?有什么方法可以利用它，在 url 中输入一些恶意内容，然后将其发送给另一个用户，例如......?我应该在这个过程中以某种方式逃避某些事情吗?

My question is if there are any security concerns with that? Any ways to exploit this, enter something malicious into the url and then send it to another user for example...? Should I escape something somehow somewhere along the process?

推荐答案

关键规则是你总是检查你的输入/输出，看看你能控制和不能控制的(以及用户可以控制的).在此基础上，您应用安全/消毒措施.

The key-rule is that you always check your input/outputs and see what you can and cannot control (and thus, what can be controlled by a user). On the basis of that, you apply security/sanitization measures.

如果我正确理解您的情况，您会显示该页面，除非用户未登录.在这种情况下，您会显示一个登录框，并在成功登录后将用户发送回他试图访问的页面$_SERVER['request_uri'](存储在会话中).

If I understand your scenario correctly, you display the page, unless a user is not logged in. In that case you show a login box, and after succesful login you send the user back to the page he was trying to visit using the $_SERVER['request_uri'] (stored in a session).

所以用户显然可以控制这个变量，他可以用一些尴尬的字符浏览到你的页面.因此，您需要对其进行消毒.正如@Wayne 在评论中提到的，例如，用户可以遍历您的目录树.

So the user obviously can control this variable, he can browse to your page with some awkward characters. Thus you need to sanitize that. As @Wayne mentions in the comments, users can traverse your directory tree for instance.

因此，就像您的 $_GET 变量一样，您也需要清理 $_SERVER['request_uri'].有很多方法可以做到这一点.最安全的方法可以说是在使用 html_entities() 或类似的东西清理之后检查 request_uri 是否是现有页面.请注意，特殊的目录遍历方法，例如 ../、// 和 ./ 可能会绕过传统的清理方法，例如前面提到的 html_entities()

Thus, like your $_GET variables, you will need to sanitize the $_SERVER['request_uri'] as well. There are many ways to do this. The most secure is arguably to check if the request_uri is an existing page, after sanitizing with html_entities() or something like that. Note that special directory traversal methods such as ../, // and ./ might slip through conventional sanization methods such as the aforementioned html_entities()

从字面上回答:我应该在过程中以某种方式逃避某些事情吗?- 是的，一切都在每个流程的开始.

And to answer literally: Should I escape something somehow somewhere along the process? - Yes, everything, at the beginning of each process.

------ 编辑@ 12-12-2013 -----

(评论的答案太长，所以我将在这里解释用户如何使用目录遍历，包括潜在的危险情况)

(too long an answer for a comment, so I'll expain here how potentially a user can use directory traversal, incl. potential dangerous situations)

来自 PHP 手册:

$_SERVER['REQUEST_URI']: The URI which was given in order to access this page;
                         for instance, '/index.html'.

所以，假设我想去 yourdomain.com/posts/post.php?../../../ssh 你的 web 应用程序会注意到我没有登录，在会话中存储 post.php?../../../ssh 并处理登录，之后它将我发送回 url.由于 ../../../ssh 部分，我不会被发送到 post.php，而是发送到您服务器上名为 ssh 的目录位于您的 webroot 之下.为方便起见，您已将 SSH 密钥存储在那里.这看起来很安全，因为它在 webroot 之外，没有 webuser 应该能够访问它.但是，我可以，因为我巧妙地添加了您的网址.

So, say I want to go to yourdomain.com/posts/post.php?../../../ssh your webapp will notice that i'm not logged in, store post.php?../../../ssh in a session and process logging in, after which it sends me back to the url. Because of the ../../../ssh part, I won't be send to post.php, but to a directory on your server named ssh which is below your webroot. For your convenience you've stored your SSH keys there. This seems safe, because it's out of the webroot no webuser should be able to access it. Yet, I can because of my ingenious addition to your url.

虽然这有点牵强，但正确配置的 http-server、chrooting 环境等会阻止这种情况发生，这个示例确实向您表明，如果您允许添加这些字符，它们可能会使用户访问他们所在的位置不应该.

Although this is a little far-fetched, a properly configured http-server, chrooting environment etc. will prevent this, this example does show you that if you allow these characters to be added, they might make users access locations they are not supposed to.

根据您的实现，盲目添加 $_SERVER['request_uri'] 也可能意味着不需要的东西被添加到会话中，如果您将该会话存储在数据库中，它也会被添加到数据库.我不太了解 PHP 的(不)安全性如何，但我可以想象这允许突破会话变量并可能将内容注入您的数据库.

Depending on your implementation, blindly adding $_SERVER['request_uri'] might also mean unwanted stuff gets added to a session, and if you store that session in a database, it will also get added to the database. I'm not really up-to-date how (in)secure PHP is, but I can imagine this allows for breaking out of session variables and potentially injecting stuff into your database.

尽管并非一切皆有可能，而且该示例也可能不太可能，但最好还是避免这种行为.

Although not everything might be possible, and the example might not be really possible, it's better and not that hard to prevent this behaviour.

-- 事后想想:也许 header('location'... 的东西是不安全的，但是这个:这个 PHP 重定向不安全吗? 显示它不是真的.然而，就像那里的评论者所说:输入 urlencode()

-- Small after thought: maybe the header('location'... stuff is insecure, but this: Is this PHP redirect insecure? shows its not really. Yet, like a commenter states over there: it's not that difficult to type urlencode()

这篇关于$_SERVER['REQUEST_URI'] 和 header('location: ...') 的任何安全问题；的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！