Credential Management: Hardcoded Username

ABSTRACT

hardcoded username? 會削弱系統安全性，一旦出現安全問題將無法輕易修正。

EXPLANATION

采用硬編碼處理用戶名絕非一個好方法。這不僅是因為采用硬編碼方式處理用戶名能被項目的所有開發者使用，而且使問題變得極其難以解決。一旦代碼被使用，除非為軟件打補丁，否則用戶名將再也不能更改。如果帳戶中的用戶名保護被減弱，系統的所有者將不得不在安全性和可用性之間做出選擇。

示例：以下代碼使用 hardcoded username 來連接數據庫：

...
<cfquery name = "GetSSNs" dataSource = "users"
username = "scott" password = "tiger">
SELECT   SSN
FROM     Users
</cfquery>
...

此代碼將運行正常，但是任何有代碼權限的人都能得到該用戶名。一旦程序發布，將無法變更數據庫用戶 "scott" 和密碼 "tiger",除非是要修補該程序。心懷不軌的雇員可以利用他們對這一信息的訪問權限來破壞系統。

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A7 Insecure Cryptographic Storage

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A8 Insecure Cryptographic Storage

[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A8 Insecure Storage

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3210.1 CAT II

[5] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3210.1 CAT II

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 255

[7] Standards Mapping - FIPS200 - (FISMA) MP

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 3.4, Requirement 6.5.3

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 3.4, Requirement 6.5.8

97av