443与444端口CSRF Token处理机制及Nginx配置问题咨询

问题描述 #

将Nginx配置分为443和444两个SSL端口，二者路由不同但配置逻辑一致。初始状态下：

• 443端口可正常访问web1
• 444端口访问web2时出现403错误（提示CSRF验证失败）

调换两个端口的配置后：

• 444端口访问web1同样报错
• 443端口则可正常访问web2

将444端口配置中的proxy_set_header host值从$host修改为$http_host后，该端口恢复正常运行。现咨询：

1. 是否因443为HTTPS标准端口，才能正常传递CSRF Token？
2. 443与444端口下CSRF Token的具体处理机制是怎样的？

初始Nginx配置示例 #

server {
    listen 443 ssl;
    ...
    location / {
        ...
        root /usr/share/nginx/web1;
        index index.html index.htm;
        ...
    }
}

server {
    listen 444 ssl;
    ...
    location / {
        ...
        root /usr/share/nginx/web2;
        index index.html index.htm;
        ...
    }
}

1. 并非443端口本身的特殊性导致 #

443作为HTTPS标准端口只是浏览器默认会隐式省略该端口，本质问题和端口是否为标准端口无关，核心在于Nginx传递的Host头是否包含正确的端口信息，影响了后端服务的CSRF验证逻辑。

2. 两个端口下CSRF Token的处理差异根源 #

后端服务的CSRF验证逻辑通常会对比三类关键信息：

• 前端页面生成CSRF Token时关联的Origin/Referer头中的域名+端口
• Cookie中存储的CSRF Token绑定的域名+端口
• 请求时后端接收到的Host头信息

$host与$http_host的核心区别 #

• $host：优先取请求头里的Host值，无值则取server块配置的server_name，会自动剔除端口号（即使请求携带端口）。
• $http_host：完全保留客户端请求头里的Host值，包含端口号。

故障具体原因 #

非标准端口444的异常场景

• 客户端请求的Host头为yourdomain.com:444
• 用$host传递Host头时，后端收到的是不带端口的yourdomain.com
• 前端生成CSRF Token时，基于当前页面的完整域名+端口（yourdomain.com:444）
• 后端验证时发现Host头信息与Token关联的端口不匹配，判定为CSRF攻击，返回403

标准端口443的正常场景

• 客户端请求时，浏览器默认不在Host头中携带:443，直接传递yourdomain.com
• 无论用$host还是$http_host，后端收到的Host都是不带端口的yourdomain.com
• 前端生成Token时，因是默认端口，同样使用不带端口的域名，与后端接收的Host信息匹配，验证通过

调换端口配置后，web1在444端口下会因相同逻辑报错；web2在443端口下因Host与Token的端口信息一致，验证通过。修改为$http_host后，后端能收到带:444的完整Host头，与前端Token关联的端口匹配，CSRF验证通过。

内容的提问来源于stack exchange，提问作者SungHun Jung