can see an IF condition which checks $_SERVER['REMOTE_ADDR'] (ie, the client’s IP address) against the value of 127.0.0.1 (localhost), and should this match, then the boolean $t_boolNeedCheck is set to false and the rest of the redirect logic is bypassed.
Conditional authentication at its finest.
public function dispatchRequest()
{
$t_objController = $this->getControllerInstance();
if($t_objController) {
//是否需要判断跨站攻击，一般登录页面不需要判断跨站攻击
if ($_SERVER['REMOTE_ADDR'] === '127.0.0.1')
$t_boolNeedCheck = false;
else
$t_boolNeedCheck = true;
if(isset($t_objController->m_boolNeedCheck))
$t_boolNeedCheck = $t_objController->m_boolNeedCheck;
//防止跨站攻击
if($this->isAuthUser() && strcmp($_SERVER['REMOTE_ADDR'],"127.0.0.2") != 0 && !isset($_REQUEST['scinfo']) && !isset($_REQUEST['sd_t']) && (!isset($_GET['sid']) || $_GET['sid'] != session_id()) && $t_boolNeedCheck)
{
//要设置t_boolNeedCheck = false，要不会有重定向死循环
CMiscFunc::locationHref('/Redirect.php?url=/LogInOut.php');
exit(0);
}
$t_fStartTime = $this->costMicroTime();
$t_strResult = $t_objController->action($this->m_objConf, $this->m_arrReturn);
$t_fEndTime = $this->costMicroTime();
$t_fTotal = $t_fEndTime - $t_fStartTime;
CMiscFunc::printMsg($t_fTotal);
return true;
}
CMiscFunc::locationHref('/Redirect.php?url=/LogInOut.php');
return false;
}
Can we, as external attackers, control the IP address that PHP sees, or are there opportunities for SSRF-type vulnerabilities that we can use to bypass this bastion-of-strength security control?
Well, in the real world, there are a few headers that might facilitate this - such as X-Forwarded-For and X-Real-Ip HTTP request headers, but experimentation proved these to have no effect.
Once again, referring back to the httpd.conf, we can see an unusual but suspicious directive - RPAFheader Y-Forwarded-For. This directive, which is loaded from the module mod_rpaf, allows clients to set their ‘remote’ IP address… useful. Probably intended functionality, we thought to ourselves.
A quick test of a request involving Y-Forwarded-For: 127.0.0.1 shows that we are no longer redirected to the login page when making an unauthenticated request.
Shazam! Our first stage in a potential vulnerability chain is hit, as this opens up a “whole new world” of application attack surface for us - all of the Alias’s defined within the Apache config.
For example, the previously-inaccessible /vmp_getinfo becomes within our grasp:
curl --insecure https://<host>:85/vmp_getinfo -H "Y-Forwarded-For: 127.0.0.1"