Spring依赖注入

简介

在Spring框架中，为了确保组件之间的依赖关系得到正确管理和维护，建议使用依赖注入（Dependency Injection, DI）。依赖注入是一种设计模式，允许程序在运行时自动为类的成员变量赋值，而不是由程序员直接在代码中硬编码这些依赖关系。

使用Spring的依赖注入有以下好处：

1. **松耦合**：依赖注入可以使各个组件之间保持较低的耦合度，因为组件不再负责创建或查找依赖对象。这样有利于模块化开发和单元测试。

2. **可扩展性**：由于组件之间解耦，添加新功能或替换现有组件变得更加容易。

3. **易于管理**：Spring容器可以集中管理所有的组件实例和它们之间的依赖关系，从而简化应用程序的配置和管理。

在Spring中，可以通过以下几种方式进行依赖注入：

1. **构造器注入**：通过构造函数传递依赖对象的实例。

@Service
public class MyService {
    private final MyRepository repository;

    @Autowired
    public MyService(MyRepository repository) {
        this.repository = repository;
    }
}

2. **setter 注入**：通过设置方法注入依赖对象的实例。

@Service
public class MyService {
    private MyRepository repository;

    @Autowired
    public void setRepository(MyRepository repository) {
        this.repository = repository;
    }
}

3. **字段注入**：直接在类的字段上使用 `@Autowired` 注解。

@Service
public class MyService {
    @Autowired
    private MyRepository repository;
}

风险

在Spring框架中，单例(Singleton）作用域意味着在整个应用程序中，只会创建一个实例。对于上文所述的依赖注入中标记有@Component、@controller、@service、或@Repository注解的类，默认情况下都是单例的。这些类通常会包含一些静态成员(例如日志记录器），但是所有非静态成员都应当由Spring容器管理，以便它们能够正确地参与依赖注入。

如果在这些单例类中存在非静态成员，而这些成员井没有通过@Autowired、 aValue、@Inject、或

@Resource注解来注入，那么就可能存在一种漏洞，因为这样的成员变量可能会被错误地用作状态管理。

在多用户并发环境中，单例bean的状态管理（如果不当）可能会导致以下安全隐患或问题：

1. 线程安全问题：如果多个请求同时访问这个单例实例，并且同时修改其状态(非静态成员变

2. 量），那么就可能出现线程安全问题。由于Spring的单例Bean默认不是线程安全的，所以这可能会导致数据的不一致性或竞争条件。

3. 数据泄露风险：如你所述，如果一个用户的会话数据被错误地存储在单例Bean的成员变量中，那么其他用户可能会意外地访问到这些数据。这会造成重大的隐私问题和数据泄露。

4. 不正确的业务迅镇：业务迅辑可能会因为错误地假设每个用户都有自己的实例而出错，从而导致不可预测的行为和潜在的错误。

在sonar的扫描规则中，就有一条涉及Spring依赖注入

规则：java:S3749   

等级：严重漏洞   

规则名：Members of Spring components should be injected

解决方案：Annotate this member with "@Autowired", "@Resource", "@Inject", or "@Value", or remove it

漏洞描述：Spring @Component、@Controller、@Service 和 @Repository 类默认都是单例，这意味着应用程序中只会实例化该类的一个实例。通常，这样的类可能有一些静态成员，例如记录器，但所有非静态成员都应该由 Spring 管理。也就是说，它们应该具有以下注释之一：@Resource、@Inject、@Autowired 或@Value。

在这些类之一中拥有非注入成员可能表明尝试管理状态。因为它们是单例，所以这样的尝试几乎可以保证最终将 User1 会话中的数据暴露给 User2。

当未使用 @ConfigurationProperties 注释的单例 @Component、@Controller、@Service 或 @Repository 具有未使用以下之一注释的非静态成员时，都可能引发该问题。

以一段风险代码为例：

@Controller
public class HelloWorld {

  private String name = null;

  @RequestMapping("/greet", method = GET)
  public String greet(String greetee) {

    if (greetee != null) {
      this.name = greetee;
    }

    return "Hello " + this.name;  // if greetee is null, you see the previous user's data
  }
}

这段代码中存在一个问题，即当你访问 `/greet` 路径时，每次请求之间不会清除 `name` 字段的值。这意味着如果你先访问 `/greet?greetee=John`，然后又访问 `/greet?greetee=Doe`，第二次请求将会显示 John 的数据，而不是 Doe 的数据。

为了解决这个问题，你应该在每次请求之前初始化 `name` 字段。你可以使用 Java 的 `@PostConstruct` 注解在一个非静态初始化方法上来执行此操作。这是修改后的代码：

@Controller
public class HelloWorld {

  private String name;

  @PostConstruct
  private void init() {
    this.name = null;
  }

  @RequestMapping("/greet", method = GET)
  public String greet(@RequestParam("greetee") String greetee) {

    if (greetee != null) {
      this.name = greetee;
    }

    return "Hello " + this.name;
  }
}

在这个版本中，我们在类中定义了一个名为 `init` 的私有方法，并使用了 `@PostConstruct` 注解。Spring 将会在实例化该控制器时自动调用这个方法，确保每次请求时 `name` 都会被正确地初始化为 `null`。此外，我们还使用了 `@RequestParam` 来明确表示从 URL 查询参数中获取 `greetee` 值。这样就能确保每次请求之间的 `name` 字段都被正确地清除了。

代码最佳实践

事实上在实际的企业代码实践中，要解决这样一类风险依赖于良好的代码规范，需要重构老的代码是很困难的。在该规则的检测中，有一个修复的讨巧方法是将字段初始化为 null ，例如：

private Environment env = null;
private YYYAdaptor yyyAdaptor = null;
private JAXBContext jaxbContext = null;

当然将字段声明为final一样可以解决问题

private final Environment env;
private final YYYAdaptor yyyAdaptor;
private final JAXBContext jaxbContext;

当然即使是如上文风险代码的写法，也未必一定导致真实的安全问题。实际上有相当多避免线程安全问题的方法，例如：

1. **双检锁/双重校验锁（Double-Check Locking）**: 这是一种常见的线程安全实现方式。它利用同步块，在类初始化时只进行一次实例化操作。这种方式提高了性能，同时也保证了线程安全。

public class Singleton {
    private volatile static Singleton instance;
    
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

2. **静态内部类**：这种实现方式巧妙地利用了 Java 类加载机制。当且仅当类被加载时，才会执行单例对象的创建，因此它是线程安全的。

public class Singleton {
    private Singleton() {}

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

3. **枚举**：使用枚举类型创建单例也是线程安全的，因为枚举类型的实例在编译期间就已经确定，并且不允许有多个实例存在。

public enum Singleton {
    INSTANCE;

    public void doSomething() {
        // ...
    }
}

// 使用
Singleton.INSTANCE.doSomething();

因此对于依赖注入可能存在的安全问题，只检测变量是否被Spring托管的逻辑是过于简单粗暴的，对于有开放式解决方案的问题，安全从业者在进行白盒规则的制定时应该采取更谨慎的态度。