柚子快報激活碼778899分享：Spring依賴注入
簡介
在Spring框架中，為了確保組件之間的依賴關系得到正確管理和維護，建議使用依賴注入（Dependency?Injection,?DI）。依賴注入是一種設計模式，允許程序在運行時自動為類的成員變量賦值，而不是由程序員直接在代碼中硬編碼這些依賴關系。
使用Spring的依賴注入有以下好處：
1.?**松耦合**：依賴注入可以使各個組件之間保持較低的耦合度，因為組件不再負責創(chuàng)建或查找依賴對象。這樣有利于模塊化開發(fā)和單元測試。
2.?**可擴展性**：由于組件之間解耦，添加新功能或替換現(xiàn)有組件變得更加容易。
3.?**易于管理**：Spring容器可以集中管理所有的組件實例和它們之間的依賴關系，從而簡化應用程序的配置和管理。
在Spring中，可以通過以下幾種方式進行依賴注入：
1.?**構造器注入**：通過構造函數(shù)傳遞依賴對象的實例。
@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）作用域意味著在整個應用程序中，只會創(chuàng)建一個實例。對于上文所述的依賴注入中標記有@Component、@controller、@service、或@Repository注解的類，默認情況下都是單例的。這些類通常會包含一些靜態(tài)成員(例如日志記錄器），但是所有非靜態(tài)成員都應當由Spring容器管理，以便它們能夠正確地參與依賴注入。
如果在這些單例類中存在非靜態(tài)成員，而這些成員井沒有通過@Autowired、?aValue、@Inject、或
@Resource注解來注入，那么就可能存在一種漏洞，因為這樣的成員變量可能會被錯誤地用作狀態(tài)管理。
在多用戶并發(fā)環(huán)境中，單例bean的狀態(tài)管理（如果不當）可能會導致以下安全隱患或問題：
??線程安全問題：如果多個請求同時訪問這個單例實例，并且同時修改其狀態(tài)(非靜態(tài)成員變 量），那么就可能出現(xiàn)線程安全問題。由于Spring的單例Bean默認不是線程安全的，所以這可能會導致數(shù)據(jù)的不一致性或競爭條件。 ??數(shù)據(jù)泄露風險：如你所述，如果一個用戶的會話數(shù)據(jù)被錯誤地存儲在單例Bean的成員變量中，那么其他用戶可能會意外地訪問到這些數(shù)據(jù)。這會造成重大的隱私問題和數(shù)據(jù)泄露。 ??不正確的業(yè)務迅鎮(zhèn)：業(yè)務迅輯可能會因為錯誤地假設每個用戶都有自己的實例而出錯，從而導致不可預測的行為和潛在的錯誤。
在sonar的掃描規(guī)則中，就有一條涉及Spring依賴注入
規(guī)則：java:S3749???
等級：嚴重漏洞???
規(guī)則名：Members?of?Spring?components?should?be?injected
解決方案：Annotate?this?member?with?"@Autowired",?"@Resource",?"@Inject",?or?"@Value",?or?remove?it
漏洞描述：Spring?@Component、@Controller、@Service?和?@Repository?類默認都是單例，這意味著應用程序中只會實例化該類的一個實例。通常，這樣的類可能有一些靜態(tài)成員，例如記錄器，但所有非靜態(tài)成員都應該由?Spring?管理。也就是說，它們應該具有以下注釋之一：@Resource、@Inject、@Autowired?或@Value。
在這些類之一中擁有非注入成員可能表明嘗試管理狀態(tài)。因為它們是單例，所以這樣的嘗試幾乎可以保證最終將?User1?會話中的數(shù)據(jù)暴露給?User2。
當未使用?@ConfigurationProperties?注釋的單例?@Component、@Controller、@Service?或?@Repository?具有未使用以下之一注釋的非靜態(tài)成員時，都可能引發(fā)該問題。
以一段風險代碼為例：
@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?的數(shù)據(jù)，而不是?Doe?的數(shù)據(jù)。
為了解決這個問題，你應該在每次請求之前初始化?`name`?字段。你可以使用?Java?的?`@PostConstruct`?注解在一個非靜態(tài)初始化方法上來執(zhí)行此操作。這是修改后的代碼：
@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?查詢參數(shù)中獲取?`greetee`?值。這樣就能確保每次請求之間的?`name`?字段都被正確地清除了。
代碼最佳實踐
事實上在實際的企業(yè)代碼實踐中，要解決這樣一類風險依賴于良好的代碼規(guī)范，需要重構老的代碼是很困難的。在該規(guī)則的檢測中，有一個修復的討巧方法是將字段初始化為?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）**:?這是一種常見的線程安全實現(xiàn)方式。它利用同步塊，在類初始化時只進行一次實例化操作。這種方式提高了性能，同時也保證了線程安全。
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.?**靜態(tài)內部類**：這種實現(xiàn)方式巧妙地利用了?Java?類加載機制。當且僅當類被加載時，才會執(zhí)行單例對象的創(chuàng)建，因此它是線程安全的。
public class Singleton {
private Singleton() {}
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
3.?**枚舉**：使用枚舉類型創(chuàng)建單例也是線程安全的，因為枚舉類型的實例在編譯期間就已經(jīng)確定，并且不允許有多個實例存在。
public enum Singleton {
INSTANCE;
public void doSomething() {
// ...
}
}
// 使用
Singleton.INSTANCE.doSomething();
因此對于依賴注入可能存在的安全問題，只檢測變量是否被Spring托管的邏輯是過于簡單粗暴的，對于有開放式解決方案的問題，安全從業(yè)者在進行白盒規(guī)則的制定時應該采取更謹慎的態(tài)度。
柚子快報激活碼778899分享：Spring依賴注入
本文內容根據(jù)網(wǎng)絡資料整理，出于傳遞更多信息之目的，不代表金鑰匙跨境贊同其觀點和立場。
轉載請注明，如有侵權，聯(lián)系刪除。
速賣通商品
