应用架构漏洞

应用架构层面的安全问题往往影响更大。多层架构、API安全、微服务、前后端分离等，都可能带来新的攻击面。

多层架构安全

现代Web应用通常采用多层架构，将应用分为多个层次：表示层（前端）、业务逻辑层（后端）、数据访问层（数据库）。这种架构提高了系统的可维护性和可扩展性，但也带来了新的安全问题。

层间通信安全

在多层架构中，各层之间需要通信。如果层间通信不安全，就可能被攻击。

假设前端和后端之间使用HTTP通信，而没有使用HTTPS。攻击者可以通过中间人攻击，拦截和修改通信内容。即使使用HTTPS，如果证书配置不当，或者客户端不验证证书，也可能被中间人攻击。

后端和数据库之间的通信也可能存在问题。如果使用SQL查询，而没有使用参数化查询，就可能存在SQL注入漏洞。即使使用ORM框架，如果使用不当，也可能产生SQL注入。

负载均衡安全

负载均衡是提高系统可用性的重要组件，但如果配置不当，也可能带来安全问题。

假设系统使用Session粘性（Session Affinity）来保证用户请求总是路由到同一台服务器。如果攻击者能够固定Session ID，就可能进行Session固定攻击：攻击者先获取一个Session ID，然后诱导受害者使用这个Session ID登录，攻击者就可以使用这个Session ID访问受害者的账户。

健康检查接口也可能泄露信息。如果健康检查接口返回详细的系统信息（如服务器版本、运行状态等），攻击者就可以通过访问健康检查接口来收集信息。SSL终止的位置也很重要。如果SSL在负载均衡层终止，负载均衡和后端服务器之间的通信可能是明文的。如果攻击者能够访问内网，就可能窃听通信内容。

应用服务器安全

应用服务器（如Tomcat、Nginx）的配置也可能存在问题。

默认配置往往不安全。比如Tomcat的默认管理界面可能暴露，如果使用默认密码，就可能被攻击。Nginx的默认配置可能泄露版本信息，攻击者可以根据版本信息查找已知漏洞。 版本过旧也可能带来风险。如果应用服务器版本过旧，可能存在已知漏洞。攻击者可以利用这些漏洞攻击服务器。

配置泄露信息也很常见。比如错误页面可能泄露服务器版本、文件路径等信息。访问日志可能泄露敏感参数。配置文件可能暴露内部结构。

API安全测试

RESTful API安全

RESTful API是现代Web应用的重要组成部分，但如果安全措施不当，就可能被攻击。

假设一个API的Token验证不严格，可以伪造Token。如果Token的生成算法简单，或者密钥强度弱，攻击者就可能伪造Token。如果Token不过期，即使泄露了，攻击者也可以长期使用。

没有速率限制也可能导致问题。如果API没有速率限制，攻击者就可以进行暴力破解，尝试不同的用户名和密码组合，或者对某个接口进行DoS攻击。

错误信息泄露也很常见。如果API在错误时返回详细的错误信息，可能泄露数据库结构、文件路径、代码结构等信息。攻击者可以利用这些信息进行进一步攻击。

GraphQL安全

GraphQL是Facebook开发的查询语言，提供了更灵活的查询方式，但也带来了新的安全问题。

假设一个GraphQL API允许深度嵌套查询：

|
query {
  user(id: 1) {
    name
    posts {
      title
      comments {
        content
        author {
          name
          posts {
            title
            # 可以无限嵌套
          }
        }
      }
    }
  }
}

如果系统没有限制查询深度，攻击者就可以构造深度嵌套的查询，导致服务器资源耗尽。这种攻击被称为GraphQL深度查询攻击（GraphQL Depth Attack）。

另一个问题是信息泄露。GraphQL的错误信息可能泄露schema结构，攻击者可以利用这些信息构造更精确的查询。

认证问题也很常见。如果GraphQL API没有认证，或者认证不严格，攻击者就可以未授权访问数据。

微服务攻击面

微服务架构的安全问题

微服务架构将应用拆分为多个独立的服务，每个服务负责特定的功能。这种架构提高了系统的可扩展性，但也带来了新的安全问题。

服务间通信安全

在微服务架构中，服务之间需要通信。如果服务间通信不安全，就可能被攻击。

假设服务间通信没有认证，任何服务都可以调用其他服务。如果攻击者能够访问某个服务，就可以通过这个服务调用其他服务，扩大攻击面。

如果服务间通信没有加密，通信内容可能是明文的。如果攻击者能够访问内网，就可能窃听服务间通信。

即使有加密，如果证书配置不当，也可能被中间人攻击。

服务发现安全

服务发现机制也可能存在问题。如果服务注册信息泄露，攻击者就可以知道有哪些服务，以及服务的地址和端口。如果服务发现机制没有认证，攻击者就可能注册恶意服务，或者冒充其他服务。

API网关安全

API网关是微服务的入口，如果配置不当，就可能带来安全问题。

假设API网关的认证授权不严格，攻击者就可能绕过认证，直接访问内部服务。如果路由配置有问题，攻击者就可能访问不应该暴露的服务。

API网关也可能泄露内部服务信息。如果错误信息包含内部服务地址，或者响应头包含内部信息，攻击者就可以利用这些信息进行进一步攻击。

前后端分离风险

前后端分离的安全问题

前后端分离是现代Web应用的主流架构，前端和后端通过API通信。这种架构提高了开发效率，但也带来了新的安全问题。

JWT安全问题

前后端分离常用JWT（JSON Web Token）进行认证。JWT包含用户信息和签名，如果实现不当，就可能被攻击。

假设一个系统使用JWT，但JWT的算法设置为none：

|
// JWT Header
{
  "alg": "none",
  "typ": "JWT"
}
 
// JWT Payload
{
  "user_id": 1,
  "role": "admin"
}

如果系统接受none算法，就不需要验证签名。攻击者可以修改Payload，将role改为admin，然后发送给服务器。由于算法是none，服务器不会验证签名，会接受这个JWT，攻击者就获得了管理员权限。

即使不使用none算法，如果密钥强度弱，或者密钥泄露，攻击者也可能伪造JWT。

JWT不过期也可能导致问题。如果JWT没有过期时间，即使泄露了，攻击者也可以长期使用。

接口暴露

前后端分离后，API接口可能暴露。如果API没有认证，或者认证不严格，攻击者就可能未授权访问。

即使有认证，如果接口设计不当，也可能泄露敏感信息。比如，如果用户列表接口返回所有用户的详细信息，攻击者就可以获取所有用户的数据。

客户端安全

前端代码在客户端执行，可能存在问题。如果前端代码包含敏感信息（如API密钥、内部地址等），这些信息就会暴露给所有访问者。

前端代码也可能被逆向工程。即使代码被混淆，攻击者也可以通过分析代码来理解业务逻辑，发现潜在的漏洞。

前端代码也可能被篡改。如果攻击者能够修改前端代码（比如通过XSS，或者用户安装了恶意浏览器扩展），就可能注入恶意代码。

总结

本部分我们一起探讨了应用架构层面的安全。和单纯的代码漏洞不同，架构安全往往关乎“全局”，一旦出现问题，影响范围也会大得多。不管你负责哪一部分，理解整体架构是保障安全的前提。 多层架构之间的信息传递、负载均衡器是不是配置得当、应用服务器的权限和补丁，API 接口（不论是 RESTful 还是 GraphQL），微服务架构下的内部通信和服务治理，前后端分离带来的各种新风险（比如 JWT 实现、接口授权、前端信息泄露）……这些都值得我们警惕，而不是只盯着代码里的“洞”。

下一部分，我们要聊一聊加密与安全配置。不少看似安全的系统，就是因为加密用得不对、配置出错，结果被攻破。

最后再提醒一句：架构安全不是“架构师”一个人的事，每位开发、测试、安全同学都应该有整体安全意识，这样才能让系统更稳、更安全。