安裝sonar并配置

docker安裝sonarqube，sonarQube靜態(tài)代碼掃描 - Joson6350 - 博客園 (cnblogs.com)

對webgoat進(jìn)行sonar掃描

掃描結(jié)果?

bugs?

Change this condition so that it does not always evaluate to "false"

意思是這里的else if語句不會執(zhí)行，因為ipAddressKnow為true，所以if 和else if的條件結(jié)果是一樣的。

?Use try-with-resources or close this "PreparedStatement" in a "finally" clause.

提示資源沒有關(guān)閉，需要在finally中進(jìn)行資源關(guān)閉，但是把資源關(guān)閉放到finally中由提示這樣寫不規(guī)范有異味。所以它推薦的寫法是將創(chuàng)建資源流的代碼放在try()中，這樣系統(tǒng)會自動的關(guān)閉資源，不需要我們寫.close()方法

try-with-resources

Java 異常處理 | 菜鳥教程 (runoob.com)

JDK7 之后，Java 新增的?try-with-resource?語法糖來打開資源，并且可以在語句執(zhí)行完畢后確保每個資源都被自動關(guān)閉 。

try-with-resources 是一種異常處理機(jī)制，它可以簡化資源管理代碼的編寫。

JDK7 之前所有被打開的系統(tǒng)資源，比如流、文件或者 Socket 連接等，都需要被開發(fā)者手動關(guān)閉，否則將會造成資源泄露。

try (resource declaration) {
  // 使用的資源
} catch (ExceptionType e1) {
  // 異常塊
}

以上的語法中 try 用于聲明和實例化資源，catch 用于處理關(guān)閉資源時可能引發(fā)的所有異常。

注意：try-with-resources 語句關(guān)閉所有實現(xiàn) AutoCloseable 接口的資源。

參考：Java 異常處理 | 菜鳥教程 (runoob.com)

【轉(zhuǎn)】Sonar掃描bug修復(fù) - 登風(fēng)360 - 博客園 (cnblogs.com)

合規(guī)方案 在try語句進(jìn)行實例定義，以防失敗。

private void readTheFile(String fileName) throws IOException {
    Path path = Paths.get(fileName);
    try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
      reader.readLine();
      // ...
    }
    // ..
    try (Stream<String> input = Files.lines("input.txt"))  {
      input.forEach(System.out::println);
    }
}

private void doSomething() {
  OutputStream stream = null;
  try {
    stream = new FileOutputStream("myfile.txt");
    for (String property : propertyList) {
      // ...
    }
  } catch (Exception e) {
    // ...
  } finally {
    stream.close();
  }
}

修復(fù)

 try (var connection = dataSource.getConnection()) {
      try(PreparedStatement statement =
                  connection.prepareStatement(
                          "select password from challenge_users where userid = '"
                                  + username_login
                                  + "' and password = '"
                                  + password_login
                                  + "'")) {
          ResultSet resultSet = statement.executeQuery();


          if (resultSet.next()) {
              return success(this).feedback("challenge.solved").feedbackArgs(flags.getFlag(5)).build();
          } else {
              return failed(this).feedback("challenge.close").build();
          }
      }
    }

?"Random" objects should be reused

問題：在類的多個方法中使用了Random random = new Random();不應(yīng)該在方法內(nèi)創(chuàng)建random實例，而應(yīng)該把random實例創(chuàng)建為類的屬性，可以在多個地方調(diào)用，而且建議用?SecureRandom is preferred to Random。

解決：隨機(jī)數(shù)實例定義為一個屬性，然后在下面的方法里面生成隨機(jī)值

private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Random

public void doSomethingCommon() {
  int rValue = this.rand.nextInt();
  //...

?Use the "equals" method if value comparison was intended.

這個誤報了，因為這里!=是用來判斷不為null，跟值比較用的是equals方法

合規(guī)的方案也是這樣寫的。

String firstName = getFirstName();
String lastName = getLastName();

if (firstName != null && firstName.equals(lastName)) { ... };

?Do something with the "boolean" value returned by "createNewFile"

意思是這個方法可能失敗，但是并沒有失敗處理。

Compliant Solution
public void doSomething(File file, Lock lock) {
  if (!lock.tryLock()) {
    // lock failed; take appropriate action
  }
  if (!file.delete()) {
    // file delete failed; take appropriate action
  }
}

?Null pointers should not be dereferenced

代碼中存在空指針解引用的問題?？罩羔樈庖弥傅氖钱?dāng)一個對象為空(null)時，嘗試訪問它的方法或?qū)傩浴?/p>

為了修復(fù)這個問題，你需要確保在訪問對象的方法或?qū)傩灾?，先進(jìn)行空指針檢查

A "Map<WebGoatUser, Comments>" cannot contain a "String" in a "WebGoatUser" type.

?

vulnerability

Don't use the default "PasswordEncoder" relying on plain-text.

不要用純文本或者快速hash算法存儲password?，應(yīng)該使用安全的算法產(chǎn)生hash。原因

1、預(yù)防暴力破解攻擊

2、預(yù)防撞庫攻擊

3、密碼應(yīng)該加salt來降低彩虹表攻擊的風(fēng)險。

?

The JWT signature (JWS) should be verified before using this token?

JWT應(yīng)該使用強(qiáng)加密算法簽名和驗證

1、不要使用none算法簽名或驗證token的有效性

2、不要在沒有驗證簽名之前試用token。

這里就是在沒有驗證之前，就對token進(jìn)行解析，如果攻擊者將算法設(shè)置為none后加密，也可以通過。

Disable access to external entities in XML parsing?

禁止在XML解析中訪問外部實體?

XML解析可能導(dǎo)致XXE攻擊

Security Hotspots?

Security-sensitive code that requires manual review to assess whether or not a vulnerability exists.安全敏感代碼需要人工審查來判斷是否存在漏洞。

可以看到檢測出好幾類問題，包括認(rèn)證，CSSRF，SQL注入，DOS，弱加密，不安全配置和其他。

authentication 認(rèn)證

'PASSWORD' detected in this expression, review this potentially hard-coded credential.

問題：這里把密碼硬編碼在文件中。

由于很容易從應(yīng)用程序源代碼或二進(jìn)制文件中提取字符串，因此不應(yīng)對憑據(jù)進(jìn)行硬編碼。尤其如此 適用于分布式或開源應(yīng)用程序。

建議方案

1、憑據(jù)存放在配置文件中

2、憑據(jù)存放在數(shù)據(jù)庫中

3、如果密碼通過源代碼泄露，則修改密碼。

CSRF 跨站點請求偽造

Make sure allowing safe and unsafe HTTP methods is safe here.

問題：對于同一個url，同時使用了get和post方法

HTTP 方法在用于執(zhí)行只讀操作（如檢索信息）時是安全的。相反，不安全的 HTTP 方法用于 更改應(yīng)用程序的狀態(tài)，例如在 Web 應(yīng)用程序上更新用戶的配置文件。

常見的安全 HTTP 方法有 GET、HEAD 或 OPTIONS。

常見的不安全 HTTP 方法有 POST、PUT 和 DELETE。

允許安全和不安全的 HTTP 方法對 Web 應(yīng)用程序執(zhí)行特定操作可能會影響其安全性，例如 CSRF 大多數(shù)情況下，保護(hù)僅保護(hù)由不安全的 HTTP 方法執(zhí)行的操作。

敏感代碼示例

@RequestMapping("/delete_user")  // Sensitive: by default all HTTP methods are allowed
public String delete1(String username) {
// state of the application will be changed here
}

@RequestMapping(path = "/delete_user", method = {RequestMethod.GET, RequestMethod.POST}) // Sensitive: both safe and unsafe methods are allowed
String delete2(@RequestParam("id") String id) {
// state of the application will be changed here
}

推薦的安全編碼實踐

對于應(yīng)用程序的所有路由/控制器，應(yīng)顯式定義授權(quán)的 HTTP 方法，并且僅應(yīng)定義安全的 HTTP 方法 用于執(zhí)行只讀操作。

合規(guī)解決方案

@RequestMapping("/delete_user", method = RequestMethod.POST)  // Compliant
public String delete1(String username) {
// state of the application will be changed here
}

@RequestMapping(path = "/delete_user", method = RequestMethod.POST) // Compliant
String delete2(@RequestParam("id") String id) {
// state of the application will be changed here
}

有問題代碼

這里沒指定請求方法

?Make sure disabling Spring Security's CSRF protection is safe here.

當(dāng)攻擊者可以強(qiáng)制 Web 應(yīng)用程序的受信任用戶執(zhí)行敏感操作時，就會發(fā)生跨站點請求偽造 （CSRF） 攻擊 他不打算執(zhí)行的操作，例如更新他的個人資料或發(fā)送消息，更一般地說，任何可以改變狀態(tài)的行為。 應(yīng)用。

攻擊者可以誘騙用戶/受害者單擊與特權(quán)操作相對應(yīng)的鏈接，或訪問嵌入 隱藏的 Web 請求，并且由于 Web 瀏覽器自動包含 cookie，因此可以對操作進(jìn)行身份驗證和敏感操作。

是否有風(fēng)險？

問問自己是否

• Web 應(yīng)用程序使用 Cookie 對用戶進(jìn)行身份驗證。
• Web 應(yīng)用程序中存在敏感操作，可以在對用戶進(jìn)行身份驗證時執(zhí)行這些操作。
• 例如，可以通過執(zhí)行HTTP POST或HTTP DELETE請求來修改Web應(yīng)用程序的狀態(tài)/資源。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

默認(rèn)情況下，Spring Security?提供了一個 防止 CSRF 攻擊，可以禁用：

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable(); // Sensitive: csrf protection is entirely disabled
   // or
    http.csrf().ignoringAntMatchers("/route/"); // Sensitive: csrf protection is disabled for specific routes
  }
}

推薦的安全編碼實踐

• 強(qiáng)烈建議對 CSRF 攻擊進(jìn)行防護(hù)：
  • 默認(rèn)情況下，為所有不安全的 HTTP 激活 方法。
  • 例如，使用不可猜測的 CSRF 令牌實現(xiàn)
• 當(dāng)然，所有敏感操作都不應(yīng)該使用安全的HTTP方法執(zhí)行，例如設(shè)計為 僅用于信息檢索。GET

合規(guī)解決方案

Spring SecurityCSRF 保護(hù)是 默認(rèn)啟用，請勿禁用：

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    // http.csrf().disable(); // Compliant
  }
}

SQL注入

Make sure using a dynamically formatted SQL query is safe here.

確保使用動態(tài)的格式化SQL語句是安全的

格式化的 SQL 查詢可能難以維護(hù)和調(diào)試，并且將不受信任的值連接到 查詢?

問問自己是否

• 查詢的某些部分來自不受信任的值（如用戶輸入）。
• 查詢在代碼的其他部分重復(fù)/重復(fù)。
• 應(yīng)用程序必須支持不同類型的關(guān)系數(shù)據(jù)庫。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例 因為用戶輸入被直接拼接至SQL，會存在SQL注入問題。

public User getUser(Connection con, String user) throws SQLException {

  Statement stmt1 = null;
  Statement stmt2 = null;
  PreparedStatement pstmt;
  try {
    stmt1 = con.createStatement();
    ResultSet rs1 = stmt1.executeQuery("GETDATE()"); // No issue; hardcoded query

    stmt2 = con.createStatement();
    ResultSet rs2 = stmt2.executeQuery("select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=" + user);  // Sensitive

    pstmt = con.prepareStatement("select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=" + user);  // Sensitive
    ResultSet rs3 = pstmt.executeQuery();

    //...
}

public User getUserHibernate(org.hibernate.Session session, String data) {

  org.hibernate.Query query = session.createQuery(
            "FROM students where fname = " + data);  // Sensitive
  // ...
}

推薦的安全編碼實踐

• 使用參數(shù)化查詢、預(yù)準(zhǔn)備語句或存儲 過程并將變量綁定到 SQL 查詢參數(shù)。
• 如果需要一個抽象層來訪問數(shù)據(jù)，請考慮使用 ORM 框架。

合規(guī)解決方案 采用預(yù)編譯語句

public User getUser(Connection con, String user) throws SQLException {

  Statement stmt1 = null;
  PreparedStatement pstmt = null;
  String query = "select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=?"
  try {
    stmt1 = con.createStatement();
    ResultSet rs1 = stmt1.executeQuery("GETDATE()");

    pstmt = con.prepareStatement(query);
    pstmt.setString(1, user);  // Good; PreparedStatements escape their inputs.
    ResultSet rs2 = pstmt.executeQuery();

    //...
  }
}

public User getUserHibernate(org.hibernate.Session session, String data) {

  org.hibernate.Query query =  session.createQuery("FROM students where fname = ?");
  query = query.setParameter(0,data);  // Good; Parameter binding escapes all input

  org.hibernate.Query query2 =  session.createQuery("FROM students where fname = " + data); // Sensitive
  // ...

• OWASP Top 10 2017 Category A1?- Injection
• MITRE, CWE-89?- Improper Neutralization of Special Elements used in an SQL Command
• MITRE, CWE-564?- SQL Injection: Hibernate
• MITRE, CWE-20?- Improper Input Validation
• MITRE, CWE-943?- Improper Neutralization of Special Elements in Data Query Logic
• CERT, IDS00-J.?- Prevent SQL injection
• SANS Top 25?- Insecure Interaction Between Components
• Derived from FindSecBugs rules?Potential SQL/JPQL Injection (JPA),?Potential SQL/JDOQL Injection (JDO),?Potential SQL/HQL Injection (Hibernate)

?

Denial of Service(DOS) 拒絕服務(wù)攻擊

Make sure the regex used here, which is vulnerable to polynomial runtime due to backtracking, cannot lead to denial of service.?

需要審查是否由于使用了正則導(dǎo)致DOS

問問自己是否

• 輸入由用戶控制。
• 輸入大小不限于少量字符。
• 沒有超時來限制正則表達(dá)式評估時間。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

?Weak Cryptography 弱加密

Make sure this weak hash algorithm is not used in a sensitive context here.

請確保此處的敏感上下文中未使用此弱哈希算法。

passwordEncoder()方法返回一個NoOpPasswordEncoder實例，這是一個實現(xiàn)了PasswordEncoder接口但并沒有實際操作的類，它通常用于開發(fā)過程中，在不處理密碼的情況下進(jìn)行測試或開發(fā)。

這段代碼的具體含義是：創(chuàng)建一個不執(zhí)行任何操作的密碼編碼器實例，以供Spring容器管理。這種實例通常在開發(fā)或測試階段使用，而在生產(chǎn)環(huán)境中，你可能需要使用更安全的密碼編碼器來保護(hù)你的用戶密碼。

危險：

?MD2、MD4、MD5、MD6、HAVAL-128、HMAC-MD5、DSA、SHA-1、RIPEMD、RIPEMD-128、RIPEMD-160、HMACRIPEMD160、SHA-1、collisions

如圖顯示的這些加密算法不安全，不建議使用，因為可能由于不同的輸入產(chǎn)生same hash

問問自己是否

哈希值用于安全上下文，例如：

• 用戶密碼存儲。
• 生成安全令牌（用于在網(wǎng)站上注冊時確認(rèn)電子郵件、重置密碼等）。
• 計算一些消息完整性。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

MessageDigest md1 = MessageDigest.getInstance("SHA");  // Sensitive:  SHA is not a standard name, for most security providers it's an alias of SHA-1
MessageDigest md2 = MessageDigest.getInstance("SHA1");  // Sensitive

推薦的安全編碼實踐

建議使用更安全的替代方案，例如 、 ，對于密碼哈希，它甚至 最好使用計算速度不太“快”的算法，例如 、 ，或者因為它會變慢。SHA-256?SHA-512?SHA-3?bcrypt?scrypt?argon2?pbkdf2

合規(guī)解決方案

MessageDigest md1 = MessageDigest.getInstance("SHA-512"); // Compliant

Make sure that using this pseudorandom number generator is safe here.

確保在這里使用偽隨機(jī)數(shù)生成器是安全的

?

問題：這里用了Random類生成隨機(jī)數(shù)，這個類被認(rèn)為是偽隨機(jī)生成器，不推薦用這個類，推薦用 secureRandom類

使用偽隨機(jī)數(shù)生成器 （PRNG） 是安全敏感的。例如，它過去曾導(dǎo)致以下漏洞：

• CVE-2013-6386 漏洞CVE-<>-<>
• CVE-2006-3419 漏洞CVE-<>-<>
• CVE-2008-4102 漏洞CVE-<>-<>

當(dāng)軟件在需要不可預(yù)測性的上下文中生成可預(yù)測值時，攻擊者可能會猜測下一個值 將生成，并使用此猜測來冒充其他用戶或訪問敏感信息。

由于該類依賴于偽隨機(jī)數(shù)生成器，因此此類和相關(guān)方法不應(yīng)用于安全關(guān)鍵型應(yīng)用程序或保護(hù)敏感數(shù)據(jù)。在這種情況下，應(yīng)使用依賴于加密強(qiáng)隨機(jī)數(shù)生成器 （RNG）

問問自己是否

• 使用生成值的代碼要求它是不可預(yù)測的。所有加密機(jī)制都是這種情況，或者當(dāng)一個秘密值時，例如 作為密碼，經(jīng)過哈希處理。
• 您使用的函數(shù)生成一個可以預(yù)測的值（偽隨機(jī)）。
• 生成的值被多次使用。
• 攻擊者可以訪問生成的值。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

Random random = new Random(); // Sensitive use of Random
byte bytes[] = new byte[20];
random.nextBytes(bytes); // Check if bytes is used for hashing, encryption, etc...

推薦的安全編碼實踐

• 使用加密性強(qiáng)隨機(jī)數(shù)生成器 （RNG），如“java.security.SecureRandom”來代替此 PRNG。
• 生成的隨機(jī)值僅使用一次。
• 不應(yīng)公開生成的隨機(jī)值。如果必須存儲它，請確保數(shù)據(jù)庫或文件是安全的。

合規(guī)解決方案

SecureRandom random = new SecureRandom(); // Compliant for security-sensitive use cases
byte bytes[] = new byte[20];
random.nextBytes(bytes);

SecureRandom類和Random類都是Java中用于生成隨機(jī)數(shù)的類，但它們之間有一些重要的區(qū)別。

Random類生成的是偽隨機(jī)數(shù)，這意味著它基于一個種子值生成數(shù)字，如果知道種子值，就可以預(yù)測生成的隨機(jī)數(shù)序列。這對于一些簡單的隨機(jī)數(shù)生成需求來說是足夠的，但對于需要高度安全性的應(yīng)用，如密碼生成或加密，這種可預(yù)測性就不夠了。

SecureRandom類是專門為需要高度安全性的隨機(jī)數(shù)生成需求設(shè)計的。它生成的是真正的隨機(jī)數(shù)，來源于系統(tǒng)提供的隨機(jī)性源，如操作系統(tǒng)的熵池（entropy pool）。這意味著即使知道當(dāng)前的隨機(jī)數(shù)生成位置，也無法預(yù)測下一個生成的隨機(jī)數(shù)。這種真正的隨機(jī)性對于密碼學(xué)和加密學(xué)非常重要，因為它們需要無法預(yù)測的隨機(jī)數(shù)來保證安全性。

總的來說，SecureRandom類比Random類生成的數(shù)更隨機(jī)，因為它提供了真正的隨機(jī)性，而不是偽隨機(jī)性。這對于需要高度安全性的應(yīng)用來說是至關(guān)重要的。

Insecure configuration不安全配置

Make sure this debug feature is deactivated before delivering the code in production.

問題：這里用了printStackTrace方法來調(diào)用堆棧。?

問問自己是否

• 啟用應(yīng)用程序調(diào)試功能的代碼或配置部署在生產(chǎn)服務(wù)器上。
• 默認(rèn)情況下，應(yīng)用程序在激活調(diào)試功能的情況下運行。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

Throwable.printStackTrace(...)將 Throwable 及其堆棧跟蹤打印到（默認(rèn)情況下），這并不容易 可解析，并可能暴露敏感信息：System.Err

try {
  /* ... */
} catch(Exception e) {
  e.printStackTrace();        // Sensitive
}

SpringFramework 的 EnableWebSecurity?注解，用于啟用調(diào)試支持：debugtrue

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;

@Configuration
@EnableWebSecurity(debug = true) // Sensitive
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
  // ...
}

推薦的安全編碼實踐

不要在生產(chǎn)服務(wù)器上啟用調(diào)試功能。

合規(guī)解決方案

應(yīng)使用記錄器（而不是 ）來打印投擲物：printStackTrace

try {
  /* ... */
} catch(Exception e) {
  LOGGER.log("context", e); // Compliant
}

SpringFramework 的 EnableWebSecurity?注解，用于禁用調(diào)試支持：debugfalse

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;

@Configuration
@EnableWebSecurity(debug = false) // Compliant
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
  // ...
}

其他

Make sure publicly writable directories are used safely here.

確保在此處安全地使用可公開寫入的目錄。

問題：這里用了?createTempDirectory方法創(chuàng)建文件，可能導(dǎo)致文件被創(chuàng)建至臨時文件夾

操作系統(tǒng)具有全局目錄，任何用戶都具有寫入訪問權(quán)限。這些文件夾主要用作臨時存儲區(qū)域，就像在基于 Linux 的系統(tǒng)中一樣。操作這些文件夾中的文件的應(yīng)用程序會暴露在文件名的爭用條件下：惡意 用戶可以嘗試在應(yīng)用程序之前創(chuàng)建具有可預(yù)測名稱的文件。成功的攻擊可導(dǎo)致其他文件被訪問， 已修改、損壞或刪除。如果應(yīng)用程序使用提升的權(quán)限運行，則此風(fēng)險甚至更高。/tmp

過去，它導(dǎo)致了以下漏洞：

• CVE-2012-2451 漏洞CVE-<>-<>
• CVE-2015-1838 漏洞CVE-<>-<>

每當(dāng)此規(guī)則檢測到指向可公開寫入目錄的硬編碼路徑時，都會引發(fā)問題，例如（請參閱下面的示例）。它 還檢測對指向可公開寫入目錄的環(huán)境變量的訪問，例如 和 ./tmpTMPTMPDIR

• /tmp
• /var/tmp
• /usr/tmp
• /dev/shm
• /dev/mqueue
• /run/lock
• /var/run/lock
• /Library/Caches
• /Users/Shared
• /private/tmp
• /private/var/tmp
• \Windows\Temp
• \Temp
• \TMP

?問問自己是否

• 從可公開寫入的文件夾中讀取文件或?qū)⑽募懭朐撐募A
• 應(yīng)用程序?qū)⒕哂锌深A(yù)測名稱的文件創(chuàng)建到可公開寫入的文件夾中

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

new File("/tmp/myfile.txt"); // Sensitive
Paths.get("/tmp/myfile.txt"); // Sensitive

java.io.File.createTempFile("prefix", "suffix"); // Sensitive, will be in the default temporary-file directory.
java.nio.file.Files.createTempDirectory("prefix"); // Sensitive, will be in the default temporary-file directory.
Map<String, String> env = System.getenv();
env.get("TMP"); // Sensitive

推薦的安全編碼實踐

• 使用具有嚴(yán)格控制權(quán)限的專用子文件夾
• 使用設(shè)計安全的 API 創(chuàng)建臨時文件。此類 API 將確保：
  • 生成的文件名是不可預(yù)測的
  • 該文件只能由創(chuàng)建用戶 ID 讀取和寫入
  • 文件描述符不由子進(jìn)程繼承
  • 文件將在關(guān)閉后立即銷毀

合規(guī)解決方案

new File("/myDirectory/myfile.txt");

File.createTempFile("prefix", "suffix", new File("/mySecureDirectory"));

FileAttribute<Set<PosixFilePermission>> attr = PosixFilePermissions.asFileAttribute(PosixFilePermissions.fromString("w+"));
Files.createTempFile("prefix", "suffix", attr); // Compliant, created with explicit attributes.

Make sure that expanding this archive file is safe here.

當(dāng)應(yīng)用程序在不控制擴(kuò)展數(shù)據(jù)大小的情況下擴(kuò)展不受信任的存檔文件時，就會發(fā)生成功的 Zip Bomb 攻擊，這可能會 導(dǎo)致拒絕服務(wù)。Zip 炸彈通常是幾千字節(jié)壓縮數(shù)據(jù)的惡意存檔文件，但變成了千兆字節(jié)的 未壓縮的數(shù)據(jù)。為了達(dá)到這種極端的壓縮率，攻擊者將 壓縮不相關(guān)的數(shù)據(jù)（例如：一長串重復(fù)字節(jié)）。?

問問自己是否

要擴(kuò)展的存檔不受信任，并且：

• 沒有對存檔中的條目數(shù)進(jìn)行驗證。
• 沒有對未壓縮數(shù)據(jù)的總大小進(jìn)行驗證。
• 沒有驗證壓縮和未壓縮存檔條目之間的比率。

如果您對這些問題中的任何一個回答是肯定的，則存在風(fēng)險。

敏感代碼示例

File f = new File("ZipBomb.zip");
ZipFile zipFile = new ZipFile(f);
Enumeration<? extends ZipEntry> entries = zipFile.entries(); // Sensitive

while(entries.hasMoreElements()) {
  ZipEntry ze = entries.nextElement();
  File out = new File("./output_onlyfortesting.txt");
  Files.copy(zipFile.getInputStream(ze), out.toPath(), StandardCopyOption.REPLACE_EXISTING);
}

推薦的安全編碼實踐

• 定義和控制壓縮數(shù)據(jù)與未壓縮數(shù)據(jù)之間的比例，一般來說，大多數(shù)合法檔案的數(shù)據(jù)壓縮比例是 1 到 3。
• 定義和控制未壓縮數(shù)據(jù)的最大總大小的閾值。
• 計算從存檔中提取的文件條目數(shù)，如果其數(shù)量大于預(yù)定義的閾值，則中止提取，在 特別是，不建議以遞歸方式擴(kuò)展存檔（存檔的條目也可以是存檔）。

合規(guī)解決方案

不要依賴?getsize?來檢索 未壓縮的條目，因為此方法返回存檔標(biāo)頭中定義的內(nèi)容，攻擊者可以偽造這些內(nèi)容，而不是計算實際 解壓時的條目尺寸文章來源地址http://www.zghlxwxcb.cn/news/detail-762305.html

到了這里，關(guān)于sonar靜態(tài)掃描安全靶場webgoat的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！