계: Code Quality

코드 품질이 낮으면 예측할 수 없는 동작이 발생합니다. 사용자 입장에서는 사용 편의성이 떨어지는 것으로 나타나는 경우가 많습니다. 공격자에게는 예상치 못한 방법으로 시스템에 부담을 줄 수 있는 기회가 됩니다.

93 개 항목 찾음
취약점
Abstract
로케일이 지정되지 않은 경우 예기치 않은 이식성 문제가 발생할 수 있습니다.
Explanation
로케일에 따라 달라질 수 있는 데이터를 비교할 때는 적절한 로케일을 지정해야 합니다.

예제 1: 다음 예제에서는 검증 수행을 시도하여 사용자 입력에 <script> 태그가 포함되어 있는지 확인합니다.

...
public String tagProcessor(String tag){
if (tag.toUpperCase().equals("SCRIPT")){
return null;
}
//does not contain SCRIPT tag, keep processing input
...
}
...
Example 1의 문제는 java.lang.String.toUpperCase()를 로케일 없이 사용하는 경우 기본 로케일의 규칙이 사용된다는 점입니다. 터키어 로케일 "title".toUpperCase()를 사용하는 경우 “T\u0130TLE”가 반환되며, 여기서 “\u0130”은 “위에 점이 있는 라틴어 대문자” 문자입니다. 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 예를 들어 Example 1에서는 이 코드를 사용하면 “script” 단어가 이 검증에서 catch되지 않아 Cross-Site Scripting 취약점이 발생할 수 있습니다.
References
[1] STR02-J. Specify an appropriate locale when comparing locale-dependent data CERT
[2] String (JavaDoc) Oracle
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 474
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002520 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002520 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002520 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002520 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002520 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002520 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002520 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002520 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002520 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002520 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002520 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002520 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002520 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002520 CAT II
desc.controlflow.java.portability_flaw_locale_dependent_comparison
Abstract
네이티브 SQL을 사용하는 경우 이식성 문제가 발생합니다.
Explanation
SAP 시스템은 플랫폼 독립적으로 사용 가능하도록 설계되었습니다. SAP의 이식 가능한 SQL 언어인 Open SQL을 사용하면 특정 데이터베이스 공급업체의 JDBC 드라이버에 관계없이 응용 프로그램을 사용할 수 있습니다. Open SQL을 사용하는 경우 복잡한 기본 데이터베이스를 추상화할 수 있으며 모든 데이터베이스 작업에 사용 가능한 응용 프로그램용 공통 인터페이스가 제공됩니다. 그러나 네이티브 SQL은 기본 데이터베이스에만 사용할 수 있으므로 다른 플랫폼에서 사용하는 경우 응용 프로그램 로직이 잘못 실행될 수 있으며 서비스가 거부될 수도 있습니다.
예제 1: 다음 코드에서는 네이티브 SQL을 사용합니다.


...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
PreparedStatement ps =
NativeSQLAccess.prepareNativeStatement(
conn, mssOnlyStmt);
. . .
// variant 2
Statement stmt =
NativeSQLAccess.createNativeStatement(conn);
int result = stmt.execute(mssOnlyStmt);
. . .
// variant 3
CallableStatement cs =
NativeSQLAccess.prepareNativeCall(
conn, mssOnlyStmt);
. . .
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 474
desc.structural.java.portability_flaw_native_sql
Abstract
새 개체에 정적 필드를 할당하면 다른 변수 초기화를 사용하더라도 생성자가 호출되므로 개체가 잘못 초기화될 수 있습니다.
Explanation
Java 클래스는 초기화될 때 클래스 생성자를 호출하기 전에 클래스에 선언된 정적 필드에 대한 이니셜라이저를 호출합니다. 따라서 이 클래스에 할당된 생성자가 다른 코드보다 먼저 호출됩니다. 그 후에 이 생성자가 초기화 중인 다른 필드나 변수를 사용하는 경우에는 개체가 부분적으로만 초기화되거나 잘못된 값으로 초기화될 수 있습니다.

예제 1: 다음 클래스는 정적 필드를 선언한 다음 새 개체에 할당합니다.


...
public class Box{
public int area;
public static final int width = 10;
public static final Box box = new Box();
public static final int height = (int) (Math.random() * 100);

public Box(){
area = width * height;
}
...
}
...


개발자는 Example 1에서 width가 10이므로 box.area는 10의 배수인 임의의 정수라고 예상할 수 있습니다. 그러나 실제로 해당 값은 항상 하드코드된 0 값입니다. 컴파일 시 상수를 사용하여 선언된 정적 final 필드가 먼저 초기화된 다음 각 필드가 순서대로 실행됩니다. 즉, height는 컴파일 시 상수가 아니므로 box가 선언된 후에 선언되기 때문에 height 필드가 초기화되기 전에 생성자가 호출됩니다.

예제 2: 다음 클래스는 각각 상대 필드를 사용하는 정적 필드를 선언합니다.


...
class Foo{
public static final int f = Bar.b - 1;
...
}
...
class Bar{
public static final int b = Foo.f + 1;
...
}

This example is perhaps easier to identify, but would be dependent on which class is loaded first by the JVM. In this example Foo.f could be either -1 or 0, and Bar.b could be either 0 or 1.
References
[1] DCL00-J. Prevent class initialization cycles CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 362, CWE ID 367
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-003178
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.11.2 Business Logic Architectural Requirements (L2 L3), 1.11.3 Business Logic Architectural Requirements (L3), 11.1.6 Business Logic Security Requirements (L2 L3)
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[23] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 362
[24] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 362
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3630.1 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3630.1 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3630.1 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3630.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3630.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3630.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3630.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001995 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001995 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001995 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001995 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001995 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001995 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001995 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001995 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001995 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001995 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001995 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001995 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001995 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001995 CAT II
desc.structural.java.race_condition_class_initialization_cycle
Abstract
프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 조각화 오류가 발생합니다.
Explanation
Null 포인터 예외는 일반적으로 하나 이상의 프로그래머 가정을 위반했을 때 발생합니다. 이 문제는 최소한 역참조 후 검사(check-after-dereference), 검사 후 역참조(dereference-after-check) 및 저장 후 역참조(dereference-after-store)라는 세 가지 문제를 유발합니다. 역참조 후 검사(check-after-dereference) 오류는 포인터가 null인지 검사하기 전에 null이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null인지 여부를 명시적으로 검사하지만, null인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null로 초기화하여 발생하는 경우가 많습니다.

대부분의 null 포인터 문제는 일반적인 소프트웨어 신뢰도 문제를 야기하지만 공격자가 의도적으로 null 포인터 역참조를 실행할 수 있는 경우 그 결과 발생하는 예외 사항을 활용함으로써 보안 로직을 무시하여 Denial Of Service 공격을 가하거나 차후의 공격을 계획하는 데 유용한 디버깅 정보를 응용 프로그램이 노출하도록 할 수 있습니다.

예제 1: 다음 코드에서 프로그래머는 개체 foonull임을 확인한 다음 잘못 역참조합니다. if문에서 검사할 때 foonull이면 null dereference가 발생하여 null 포인터 예외가 일어납니다.


if (foo is null) {
foo.SetBar(val);
...
}
예제 2: 다음 코드에서 프로그래머는 변수 foonull이 아닌 것으로 가정한 다음 개체를 역참조하여 이 가정을 확인합니다. 그러나 프로그래머는 나중에 foonull에 대해 검사함으로써 가정을 반박합니다. if문에서 검사할 때 foonull이 되면 역참조될 때도 null이 되어 null 포인터 예외가 발생할 수 있습니다. 역참조가 안전하지 않거나 이후의 검사가 필요하지 않게 됩니다.


foo.SetBar(val);
...
if (foo is not null) {
...
}
예제 3: 다음 코드에서 프로그래머는 명시적으로 변수 foonull로 설정합니다. 나중에 프로그래머는 개체의 null 값을 검사하기 전에 foo를 역참조합니다.


Foo foo = null;
...
foo.SetBar(val);
...
}
desc.controlflow.dotnet.redundant_null_check
Abstract
프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 조각화 오류가 발생합니다.
Explanation
Null 포인터 예외는 일반적으로 하나 이상의 프로그래머 가정을 위반했을 때 발생합니다. 이 문제는 최소한 역참조 후 검사(check-after-dereference), 검사 후 역참조(dereference-after-check) 및 저장 후 역참조(dereference-after-store)라는 세 가지 문제를 유발합니다. 역참조 후 검사(check-after-dereference) 오류는 포인터가 null인지 검사하기 전에 null이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null인지 여부를 명시적으로 검사하지만, null인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null로 초기화하여 발생하는 경우가 많습니다.

대부분의 null 포인터 문제는 일반적인 소프트웨어 신뢰도 문제를 야기하지만 공격자가 의도적으로 null 포인터 역참조를 실행할 수 있는 경우 그 결과 발생하는 예외 사항을 활용함으로써 보안 로직을 무시하여 Denial Of Service(DoS) 공격을 가하거나 차후의 공격을 계획하는 데 유용한 디버깅 정보를 응용 프로그램이 노출하도록 할 수 있습니다.

예제 1: 다음 코드에서 프로그래머는 변수 ptrNULL이 아닌 것으로 가정합니다. 이 가정은 프로그래머가 포인터를 역참조하면 명시적인 것이 됩니다. 프로그래머가 NULL에 대해 ptr을 검사하면 이 가정이 반박됩니다. if문에서 검사할 때 ptrNULL이 되면 역참조될 때도 NULL이 되어 조각화 오류가 발생할 수 있습니다.


ptr->field = val;
...
if (ptr != NULL) {
...
}
예제 2: 다음 코드에서 프로그래머는 변수 ptrNULL임을 확인한 다음 실수로 역참조합니다. if문에서 검사할 때 ptrNULL이면 null dereference가 발생하여 조각화 오류가 일어납니다.


if (ptr == null) {
ptr->field = val;
...
}
예제 3: 다음 코드에서 프로그래머는 '\0' 문자열이 실제로 0 또는 NULL인 것을 잊고 null 포인터를 역참조하여 조각화 오류가 일어납니다.


if (ptr == '\0') {
*ptr = val;
...
}
예제 4: 다음 코드에서 프로그래머는 명시적으로 변수 ptrNULL로 설정합니다. 나중에 프로그래머는 개체의 null 값을 검사하기 전에 ptr를 역참조합니다.


*ptr = NULL;
...
ptr->field = val;
...
}
desc.controlflow.cpp.redundant_null_check
Abstract
프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 null 포인터 예외가 발생합니다.
Explanation
Null 포인터 예외는 일반적으로 하나 이상의 프로그래머 가정을 위반했을 때 발생합니다. 특히 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null인지 여부를 명시적으로 검사하지만, null인 것으로 알려진 개체를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다.

대부분의 null 포인터 이슈는 소프트웨어 전반의 안정성 문제를 야기하지만 공격자가 의도적으로 null 포인터 역참조를 유발하는 경우, 그 결과 발생하는 예외 사항을 사용하여 Denial Of Service(DoS) 공격을 가하거나 차후의 공격을 계획하는 데 유용한 디버깅 정보를 응용 프로그램이 노출하도록 할 수 있습니다.

예제 1: 다음 코드에서 프로그래머는 변수 foonull임을 확인한 다음 실수로 역참조합니다. if문에서 검사할 때 foonull이면 null dereference가 발생하여 null 포인터 예외가 일어납니다.


if (foo == null) {
foo.setBar(val);
...
}
desc.internal.java.null_dereference_dereference_after_check
Abstract
함수가 명시적인 액세스 한정자를 지정하지 않습니다.
Explanation
개발자는 Solidity 스마트 계약 개발 시 함수의 액세스 한정자를 설정하여 해당 함수를 호출할 수 있는 사용자를 제어할 수 있습니다. 개발자가 액세스 한정자를 지정하지 않으면 함수는 기본적으로 공개로 설정되므로 악의적 작업자가 인증 없이 함수를 호출할 수 있습니다.

예제 1: 다음 코드는 두 함수에서 모두 액세스 한정자를 설정하지 못하므로 누구나 이 두 함수를 호출할 수 있습니다. 따라서 사용자가 require 호출을 우회할 수 있습니다.


function withdrawWinnings() {
require(uint32(msg.sender) == 0);
_sendWinnings();
}

function _sendWinnings() {
msg.sender.transfer(this.balance);
}
References
[1] Enterprise Ethereum Alliance Code Linting
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 710
[7] Standards Mapping - Smart Contract Weakness Classification SWC-100
desc.structural.solidity.swc100
Abstract
함수가 특정 Ether 값과 계약 잔액을 비교합니다.
Explanation
계약의 Ether 잔액을 특정 금액으로 가정하면 부적절하거나 예기치 않은 동작이 발생할 수 있습니다. 계약으로 Ether를 전송하는 등의 방식을 통해 계약 잔액을 강제로 변경할 수 있기 때문입니다.

예제 1: 다음 코드는 assert를 사용하여 Lock 계약 인스턴스의 잔액이 특정 값(msg.value)임을 확인합니다.


contract Lock {
constructor (address owner, uint256 unlockTime) public payable {
...
}
}

contract Lockdrop {
...
function lock(...) {
uint256 eth = msg.value;
address owner = msg.sender;
uint256 unlockTime = unlockTimeForTerm(term);

Lock lockAddr = (new Lock).value(eth)(owner, unlockTime);

assert(address(lockAddr).balance == msg.value);
}
}
References
[1] Enterprise Ethereum Alliance No Exact Balance Check
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 710
[7] Standards Mapping - Smart Contract Weakness Classification SWC-132
desc.structural.solidity.swc132
Abstract
계약이 고정된 양의 가스를 정의하거나 고정된 양의 가스가 설정된 함수를 호출합니다.
Explanation
가스 기준 트랜잭션 비용은 현재 네트워크 상태에 따라 달라질 수 있습니다. 가령 하드 포크 중에는 EVM(Ethereum Virtual Machine) 명령의 가스 비용이 큰 영향을 받을 수 있습니다. 그러므로 고정된 양의 가스를 사용하는 기존 기능 실행이 중단될 수도 있고, 고정된 양의 가스(2300)를 사용하는 transfer()send()와 같은 값 전송에 사용되는 트랜잭션에 영향을 줄 수도 있습니다.

예제 1: 다음 코드는 고정된 양의 가스를 지정하여 호출을 수행합니다.


interface ICallable {
function callMe() external;
}

contract HardcodedNotGood {
function callWithArgs() public {
callable.callMe{gas: 10000}();
}
}
References
[1] Enterprise Ethereum Alliance Gas and Gas Prices
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 665
[7] Standards Mapping - Smart Contract Weakness Classification SWC-134
desc.structural.solidity.swc134