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"