界: API Abuse
API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如，如果程式在呼叫 chroot() 後無法呼叫 chdir()，即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下，呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如，如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值，則違反了規定。
SQL Bad Practices: Direct Update
Abstract
Direct Open SQL 寫入操作是不良的作法，應予以避免。
Explanation
一般而言，Direct Open SQL 寫入操作 (插入/更新/修改/刪除) 是不良的作法，應予以避免。這些更新會破壞系統的完整性與安全性，因此應禁止。
Direct Open SQL 寫入操作還容易發生錯誤，可能導致非預期的系統行為。在 SAP 中，需要小心的一些問題包括：
- SAP 建議使用「更新統合」技術確保 SAP LUW (工作的邏輯單元) 中可能跨多個資料庫 LUW 的資料完整性。直接修改表格項目而不更新統合可能使 SAP 交易處於不一致的狀態。
- Direct Open SQL 寫入操作只設定資料庫級別的鎖定，而略過 SAP 應用程式鎖定。這可能導致鎖死和資料損壞。
- Direct Open SQL 寫入操作略過應用程式內的 SAP 授權檢查。
- 在使用標準機制寫入表格項目、編輯檢查、稽核路徑時，相依的更新 (例如變更文件) 全部會正確執行。而使用 Direct Open SQL 寫入操作時不是這樣。
Direct Open SQL 寫入操作還容易發生錯誤，可能導致非預期的系統行為。在 SAP 中，需要小心的一些問題包括：
- SAP 建議使用「更新統合」技術確保 SAP LUW (工作的邏輯單元) 中可能跨多個資料庫 LUW 的資料完整性。直接修改表格項目而不更新統合可能使 SAP 交易處於不一致的狀態。
- Direct Open SQL 寫入操作只設定資料庫級別的鎖定，而略過 SAP 應用程式鎖定。這可能導致鎖死和資料損壞。
- Direct Open SQL 寫入操作略過應用程式內的 SAP 授權檢查。
- 在使用標準機制寫入表格項目、編輯檢查、稽核路徑時，相依的更新 (例如變更文件) 全部會正確執行。而使用 Direct Open SQL 寫入操作時不是這樣。
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 662
[2] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[3] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002235
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege
[8] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000500 CAT II
desc.structural.abap.sql_bad_practices_direct_update