如何在NestJS的LoginGuard与AzureAdStrategy中添加授权绕过后门

直接修改全局LoginGuard（最简洁可行的方案） #

这是最直接的实现方式，无需额外新增策略，仅在现有LoginGuard的canActivate方法中加入绕过逻辑即可。核心逻辑是：先检查请求是否携带合法的绕过标识，满足条件则直接放行，否则走原有的Azure AD验证流程。

代码示例：

import { Injectable, ExecutionContext } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class LoginGuard extends AuthGuard('azure-ad') {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    
    // 检查请求头，这里用x-bypass-auth作为标识，且值必须匹配预设的秘密密钥
    const bypassAuthHeader = request.headers['x-bypass-auth'];
    if (bypassAuthHeader === process.env.BYPASS_AUTH_SECRET) {
      // 可选：模拟用户对象挂载到request，方便后续业务逻辑使用
      request.user = {
        id: 'bypass-user',
        username: 'bypass-admin',
        roles: ['admin']
      };
      return true;
    }

    // 不满足绕过条件，执行原Azure AD验证逻辑
    return super.canActivate(context) as Promise<boolean>;
  }
}

关键注意点：

• 绝对不能仅通过「请求头是否存在」判断，必须校验头的具体值，且该值需通过环境变量存储，禁止硬编码在代码中
• 开发环境可适当放宽限制，但生产环境建议仅允许特定IP段使用，或直接禁用该逻辑
• 务必记录所有绕过验证的请求日志，便于后续审计排查

替代方案：自定义Bypass策略+守卫组合 #

如果需要模拟更真实的用户身份（比如测试不同角色权限），可以新增BypassStrategy，然后在守卫中根据请求头切换验证策略。

1. 自定义Bypass策略：

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Strategy } from 'passport-custom';

@Injectable()
export class BypassStrategy extends PassportStrategy(Strategy, 'bypass') {
  async validate(request: any): Promise<any> {
    // 可根据请求头额外信息返回不同角色的用户
    const role = request.headers['x-bypass-role'] || 'user';
    return {
      id: `bypass-${role}`,
      username: `bypass-${role}`,
      roles: [role]
    };
  }
}

2. 修改LoginGuard支持多策略切换：

import { Injectable, ExecutionContext } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class LoginGuard extends AuthGuard(['azure-ad', 'bypass']) {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const bypassAuthHeader = request.headers['x-bypass-auth'];
    
    // 根据请求头指定使用的验证策略
    request.authStrategy = bypassAuthHeader === process.env.BYPASS_AUTH_SECRET 
      ? 'bypass' 
      : 'azure-ad';

    return super.canActivate(context) as Promise<boolean>;
  }

  // 覆盖方法，指定当前请求使用的策略
  getAuthenticateOptions(context: ExecutionContext) {
    const request = context.switchToHttp().getRequest();
    return { strategy: request.authStrategy };
  }
}

是否可行？其他后门逻辑建议 #

上述两种方案均可行，但核心要优先保障安全性：

• 生产环境不要随意启用简单请求头绕过，避免被恶意利用
• 如果生产环境需临时调试，建议采用「IP白名单+JWT令牌」的组合，比单纯请求头更安全可控
• 另一种思路是新增专属调试路由，仅允许内部IP访问，通过该路由生成临时调试令牌，用令牌实现绕过，比请求头更易管控

内容的提问来源于stack exchange，提问作者For fun programmer