我的网站有页眉,页脚和主要内容.如果用户未登录,则可以显示登录表单而不是实际内容.
在该登录表单上,我在会话变量$_SESSION [‘redirect’]中写入$_SERVER [‘REQUEST_URI’].
我的登录表单posthandler,将用户登录,将通过标题成功登录此链接后发送给用户(‘location：http：//myserver.com’.$_SESSION [‘redirect’]);
因此,如果我访问myserver.com/somesite.PHP?somevar=10,如果您已登录,它将显示正确的站点.否则它将显示登录表单,但浏览器地址栏中的URL仍然显示myserver. COM / somesite.PHP？somevar = 10
然后输入您的凭据,您将被重定向到myserver.com/somesite.PHP?somevar=10,这将是 – 因为您现在已登录 – 完全显示.
我不将REQUEST_URI值用于表单操作或链接href.
另外,我使用的任何$_GET变量我首先检查它们是否与正则表达式匹配(通常变量将是sha1字符串或者只是随机生成的数字和字母字符串,没有特殊字符),并且我总是使用预处理语句get变量用于db查询.
我的问题是,是否有任何安全问题？有任何方法可以利用它,在网址中输入恶意内容,然后将其发送给其他用户,例如……？我是否应该在某个过程中以某种方式逃避某些事情？
解决方法:
关键规则是你总是检查你的输入/输出,看看你能控制什么,不能控制什么(因此,用户可以控制什么).在此基础上,您应用安全/消毒措施.
如果我正确理解您的场景,则显示该页面,除非用户未登录.在这种情况下,您显示一个登录框,并在成功登录后将用户发送回他尝试使用$_SERVER访问的页面[‘request_uri’](存储在会话中).
因此用户显然可以控制此变量,他可以使用一些尴尬的字符浏览到您的页面.因此,你需要消毒它.正如@Wayne在评论中提到的那样,用户可以遍历您的目录树.
因此,与$_GET变量一样,您还需要清理$_SERVER [‘request_uri’].
有很多方法可以做到这一点.在使用html_entities()或类似的东西进行消毒之后,最安全的可能是检查request_uri是否是现有页面.请注意,特殊目录遍历方法(如../,//和./)可能会忽略传统的清理方法,例如前面提到的html_entities()
并且从字面上回答：我是否应该在某个过程中以某种方式逃避某些事情？
– 是的,一切,在每个过程的开始.
——编辑@ 12-12-2013 —–
(评论的答案太长了,所以我将在这里说明用户可能使用目录遍历的方式,包括潜在的危险情况)
来自PHP手册：
$_SERVER['REQUEST_URI']: The URI which was given in order to access this page;
for instance, '/index.html'.
所以,说我想去你的网站http://www.post/post.PHP?../../../ssh你的webapp会注意到我没有登录,存储post.PHP？../ .. /../ssh在会话和进程登录中,之后它将我发送回url.由于../../../ssh部分,我不会发送到post.PHP,而是发送到服务器上名为ssh的目录,该目录位于webroot下面.为方便起见,您已将SSH密钥存储在那里.这似乎是安全的,因为它不属于webroot,没有webuser应该能够访问它.
然而,我可以因为我的巧妙添加你的网址.
虽然这有点牵强,正确配置的http服务器,chrooting环境等将阻止这一点,这个例子确实告诉你,如果你允许添加这些字符,它们可能会让用户访问他们不应该访问的位置.
根据您的实现,盲目地添加$_SERVER [‘request_uri’]也可能意味着不需要的东西被添加到会话中,如果您将该会话存储在数据库中,它也将被添加到数据库中.我不是最新的安全PHP的最新版本,但我可以想象这可以打破会话变量并可能将内容注入数据库.
虽然并非一切皆有可能,并且这个例子可能不太可能,但是防止这种行为更好并且并不难.
– 小想法：也许是标题(‘位置’……东西是不安全的,但是这个：Is this PHP redirect insecure?显示它不是真的.但是,就像那里的评论者说：输入urlencode()并不困难
