界: API Abuse

API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如，如果程式在呼叫 chroot() 後無法呼叫 chdir()，即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下，呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如，如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值，則違反了規定。

Code Correctness: Negative Content-Length

Java/JSP
JavaScript/TypeScript

Abstract

Content-Length 表頭設為負數。

Explanation

在多數狀況下，設定要求的 Content-Length 表頭即表示開發人員想要
溝通傳送到伺服器的 POST 資料長度。但是，此表頭應為 0 或者
正整數。

範例 1：下列程式碼將設定不正確的 Content-Length。


  URL url = 新 URL(「http://www.example.com」)；
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0

[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0

[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3

[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal

[5] Standards Mapping - Common Weakness Enumeration CWE ID 398

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6

desc.structural.java.api_abuse_code_correctness_negative_content_length

Abstract

Content-Length 表頭設為負數。

Explanation

在多數狀況下，設定要求的 Content-Length 表頭即表示開發人員想要
溝通傳送到伺服器的 POST 資料長度。但是，此表頭應為 0 或者
正整數。

範例 1：下列程式碼將 Content-Length 表頭錯設為負數：


  xhr.setRequestHeader("Content-Length", "-1000");