계: Encapsulation

캡슐화는 강력한 경계를 그리는 것입니다. 웹 브라우저에서는 사용자의 모바일 코드가 다른 모바일 코드에 의해 오용되지 않도록 하는 것을 의미합니다. 서버에서는 검증된 데이터와 검증되지 않은 데이터, 한 사용자의 데이터와 다른 사용자의 데이터, 데이터 사용자가 볼 수 있는 데이터와 볼 수 없는 데이터 간의 차별화를 의미할 수 있습니다.

104 개 항목 찾음
취약점
Abstract
Kubelet 구성에서 익명 요청이 활성화되어 있습니다.
Explanation
익명 요청에 대한 Kubelet의 처리를 허용하는 구성이 있습니다. 구성된 인증 방법에 의해 익명 요청이 거부되지 않습니다. Kubelet은 작업자 시스템 워크로드를 관리하는 Kubernetes 주요 에이전트이기 때문에 공격자는 익명 요청을 사용하여 충분히 보호되지 않고 보안에 민감한 서비스 API에 액세스할 수 있습니다.

예제 1: 다음 구성 파일은 Kubelet에서 익명 요청을 처리하는 것을 허용합니다. anonymous 필드가 enabled:true로 설정되어 있기 때문입니다.

...
kind: KubeletConfiguration
...
authentication:
anonymous:
enabled: true
...
References
[1] Set Kubelet parameters via a config file The Kubernetes Authors
[2] Kubelet The Kubernetes Authors
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 284
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [18] CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [18] CWE ID 862
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [16] CWE ID 862
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-001084, CCI-002165
[15] Standards Mapping - FIPS200 AC
[16] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[19] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[20] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[21] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 285
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 285
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_kubelet_anonymous_access
Abstract
민감한 필드는 모델 바인더에 노출됩니다.
Explanation
쉬운 개발과 생산성 증가를 위해 개발자는 현대적인 프레임워크를 통해 요청 쿼리와 본문 모두에서 모델 개체로 HTTP 요청 매개 변수를 자동으로 바인딩할 수 있습니다. HTTP 요청 매개 변수가 모델 속성에 바인딩되는 것을 제어하도록 바인더가 올바르게 구성되어 있지 않은 경우 공격자는 모델 바인딩 절차를 남용하고 사용자 제어에 노출되면 안 되는 다른 속성을 설정할 수도 있습니다. 이 바인딩은 모델 속성이 웹 형식 또는 API 계약에 표시되어 있지 않더라도 가능합니다.

예제 1: 다음 ASP.NET MVC 컨트롤러 메서드(Register)는 이름 및 암호를 제공하여 계정을 등록하도록 사용자에게 묻는 웹 폼에서 액세스됩니다.


public ActionResult Register(RegisterModel model)
{
if (ModelState.IsValid)
{
try
{
return RedirectToAction("Index", "Home");
}
catch (MembershipCreateUserException e)
{
ModelState.AddModelError("", "");
}
}
return View(model);
}
RegisterModel 클래스는 다음과 같이 정의됩니다.


public class RegisterModel
{
[BindRequired]
[Display(Name = "User name")]
public string UserName { get; set; }

[BindRequired]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }

[DataType(DataType.Password)]
[Display(Name = "Confirm password")]
public string ConfirmPassword { get; set; }

public Details Details { get; set; }

public RegisterModel()
{
Details = new Details();
}
}
Details 클래스는 다음과 같이 정의됩니다.


public class Details
{
public bool IsAdmin { get; set; }
...
}
Example 1에 제공된 시나리오와 같이 공격자는 응용 프로그램을 탐색하고 RegisterModel 모델에 Details 속성이 있는지 발견할 수 있습니다. 이러한 경우 공격자는 속성에 할당된 현재 값을 덮어쓰려 할 수도 있습니다.
공격자가 이러한 내부 속성을 발견하고 이러한 속성의 바인딩을 허용하지 않도록 프레임워크 바인더가 올바르게 구성되어 있지 않은 경우 공격자는 다음 요청을 보내 관리자 계정을 등록할 수 있습니다.


name=John&password=****&details.is_admin=true
References
[1] OWASP Mass assignment
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 915
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[18] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.structural.dotnet.mass_assignment_sensitive_field_exposure
Abstract
민감한 필드가 모델 바인더에 노출됩니다.
Explanation
최신 프레임워크를 사용하면 요청 쿼리와 본문의 HTTP 요청 매개 변수를 모델 개체로 자동으로 바인딩하여 개발 작업을 용이하게 하고 생산성을 개선할 수 있습니다. HTTP 요청 매개 변수가 모델 속성에 바인딩되는 것을 제어하도록 바인더가 올바르게 구성되어 있지 않은 경우 공격자는 모델 바인딩 절차를 남용하고 사용자 제어에 노출되면 안 되는 다른 속성을 설정할 수도 있습니다. 이 바인딩은 모델 속성이 웹 형식 또는 API 계약에 표시되어 있지 않더라도 가능합니다.

예제 1: 다음 Struts 1 DynaActionForm은 사용자 요청에 바인딩되는 ActionForm을 동적으로 정의합니다. 이 경우 이 양식은 계정 유형과 사용자 세부 정보를 제공하여 계정을 등록하는 데 사용됩니다.


<struts-config>
<form-beans>
<form-bean name="dynaUserForm"
type="org.apache.struts.action.DynaActionForm" >
<form-property name="type" type="java.lang.String" />
<form-property name="user" type="com.acme.common.User" />
</form-bean>
...



등록에 성공하면 사용자 데이터가 데이터베이스에 유지됩니다. User 클래스는 다음으로 정의됩니다.


public class User {
private String name;
private String lastname;
private int age;
private Details details;

// Public Getters and Setters
...
}
Details 클래스는 다음으로 정의됩니다.


public class Details {
private boolean is_admin;
private int id;
private Date login_date;

// Public Getters and Setters
...
}
Example 1에 제공된 시나리오와 같이 공격자는 응용 프로그램을 탐색하고 User 모델에 details 속성이 있는지 발견할 수 있습니다. 이러한 경우 공격자는 속성에 할당된 현재 값을 덮어쓰려 할 수도 있습니다.
공격자가 이러한 내부 속성을 찾을 수 있고 이러한 속성의 바인딩을 허용하지 않도록 프레임워크 바인더가 올바르게 구성되지 않은 경우 공격자는 다음 요청을 전송하여 관리자 계정을 등록할 수 있습니다.


type=free&user.name=John&user.lastname=Smith&age=22&details.is_admin=true
References
[1] OWASP Mass assignment
[2] Spring Spring MVC Known Vulnerabilities and Issues
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 915
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[16] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[20] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.config.java.mass_assignment_sensitive_field_exposure
Abstract
로거는 static 및 final로 선언하십시오.
Explanation
단일 로거 개체를 특정 클래스의 모든 개체 사이에 공유하고 프로그램 기간 중 같은 로거를 사용하는 것이 좋은 프로그래밍 습관입니다.

예제 1: 다음 문은 static이 아닌 로거를 선언하는 오류를 범합니다.


private final Logger logger =
Logger.getLogger(MyClass.class);
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
desc.structural.java.poor_logging_practice_logger_is_not_declared_static_final
Abstract
한 클래스에 multiple loggers 대신 로깅 수준(logging level)을 사용합니다.
Explanation
좋은 로깅 습관은 각 클래스마다 하나의 로거를 사용하는 것입니다.

예제 1: 다음 코드는 multiple loggers를 선언하는 오류를 범합니다.


public class MyClass {
private final static Logger good =
Logger.getLogger(MyClass.class);
private final static Logger bad =
Logger.getLogger(MyClass.class);
private final static Logger ugly =
Logger.getLogger(MyClass.class);
...
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001130 CAT II
desc.structural.java.poor_logging_practice_multiple_loggers
Abstract
전용 로깅 기능 대신 Console.Out 또는 Console.Error를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 개발자가 배우는 과정에서 작성하는 첫 .NET 프로그램은 다음과 같습니다.


public class MyClass {
...
Console.WriteLine("hello world");
...
}


대부분의 프로그래머가 .NET의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 Console.WriteLine()을 사용하여 표준 출력에 대한 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, Console.WriteLine 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.dotnet.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 os.Stdout 또는 os.Stderr를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 일반적으로 개발자가 배우는 과정에서 작성하는 첫 Go 프로그램은 다음과 같습니다.


...

func foo(){
fmt.Println("Hello World")
}


대부분의 개발자가 Go의 수많은 노하우와 세부 사항을 배우게 되지만 일부는 fmt.Println()을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 식별자, 타임스탬프 및 로그 메시지를 올바른 위치로 보내는 기능과 같은 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

구조화된 로깅은 널리 사용되지만 여전히 시스템 출력 스트림을 "프로덕션 전" 개발에 사용하는 개발자가 많습니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, os.Stdout 또는 os.Stderr 로깅은 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.semantic.golang.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 System.out 또는 System.err를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 개발자가 배우는 과정에서 작성하는 첫 Java 프로그램은 다음과 같습니다.


public class MyClass
...
System.out.println("hello world");
...
}


대부분의 프로그래머가 Java의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 System.out.println()을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, System.out 또는 System.err 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 process.stdout 또는 process.stderr를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 초기 Node.js 개발자가 stdin에서 읽고 다시 stdout에 쓰기 위해 작성할 수 있는 간단한 프로그램은 다음과 같습니다.


process.stdin.on('readable', function(){
var s = process.stdin.read();
if (s != null){
process.stdout.write(s);
}
});


대부분의 프로그래머가 특히 JavaScript 및 Node.js의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 process.stdout.write()를 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, process.stdout 또는 process.stderr 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.javascript.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 print 또는 println를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 개발자가 배우는 과정에서 작성하는 첫 Kotlin 프로그램은 다음과 같습니다.


class MyClass {
...
println("hello world")
...
}
}


대부분의 프로그래머가 Kotlin의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 print 또는 println를 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 식별자, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운영 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, 표준 출력 또는 오류 스트림 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.kotlin.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 표준 출력 또는 표준 오류 방식을 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 개발자가 배우는 과정에서 작성하는 첫 Python 프로그램은 다음과 비슷합니다.


sys.stdout.write("hello world")


대부분의 프로그래머가 Python의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지, 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, sys.stdout 또는 sys.stderr 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.python.poor_logging_practice_use_of_a_system_output_stream
Abstract
전용 로깅 기능 대신 Kernel.puts,Kernel.warn 또는 Kernel.printf를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.
Explanation
예제 1: 개발자가 배우는 과정에서 작성하는 첫 Ruby 프로그램에는 흔히 다음과 같은 기능이 포함됩니다.


...
puts "hello world"
...


대부분의 프로그래머가 Ruby의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 Kernel.puts을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, Kernel.puts,Kernel.warn 또는 Kernel.printf 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
회사의 정책에 따라 이러한 API를 사용할 수 없는 경우에는 로깅 시스템을 통해 정보를 시스템 출력 스트림으로 인쇄하는 방식으로 이를 여전히 해결할 수 있습니다.

예제 2: 다음 코드에서는 Logger 클래스를 사용하지만 시스템 출력 스트림에 정보를 기록합니다.


require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.ruby.poor_logging_practice_use_of_a_system_output_stream
Abstract
비 final public static 필드는 외부 클래스에 의해 변경될 수 있습니다.
Explanation
일반적으로, public 필드가 임의의 외부 클래스에 의해 변경될 수 있으므로 개체의 멤버 필드에 외부 클래스의 직접 접근을 제공하려고 하지 않습니다. 지향적으로 설계된 좋은 개체는 encapsulation을 사용하여 멤버 필드와 같은 구현 세부 정보가 다른 클래스에 노출되는 것을 막습니다. 또한 시스템에서 이 필드를 변경할 수 없다고 보는 경우, 악성 코드는 시스템 동작을 불리하게 변경할 수도 있습니다.

예제 1: 다음 코드에서 ERROR_CODE 필드가 final이 아니라 public 및 static으로 선언되었습니다.


public class MyClass
{
public static int ERROR_CODE = 100;
//...
}


이 경우, 악성 코드는 이 오류 코드를 변경하고 프로그램을 예기치 않은 방식으로 동작하게 만들 수도 있습니다.
References
[1] Sun Microsystems, Inc. Secure Coding Guidelines for the Java Programming Language, version 2.0
[2] OBJ10-J. Do not use public static nonfinal fields CERT
[3] MUTABLE-9: Make public static fields final Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 493
desc.structural.java.poor_style_non-final_public_static_field
Abstract
디버그 코드는 배포된 웹 응용 프로그램에 예기치 않은 진입점을 만들 수 있습니다.
Explanation
디버깅 또는 테스트 목적을 위한 변수 값을 배포된 응용 프로그램에 제공되거나 활성 상태로 유지되지 않는 코드와 함께 출력하는 것은 일반적인 관행입니다. 이러한 유형의 디버그 코드가 실수로 응용 프로그램에 남아 있게 되면 해당 응용 프로그램은 예기치 않은 방식으로 공격자에게 정보를 제공할 수 있습니다. 모든 디버그 문이 민감한 정보 또는 개인 정보를 누출하는 것은 아닙니다. 하지만 디버그 문이 있으면 주변의 코드가 무시되어 복구할 수 없는 상태가 되는 경우가 많습니다.

References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 489
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[8] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.semantic.python.python_bad_practices_leftover_debug_code