Redundant Null Check

프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 조각화 오류가 발생합니다.

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

if (foo is null) {
	foo.SetBar(val);
	...
}

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

foo.SetBar(val);
...
if (foo is not null) {
	...
}

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

Foo foo = null;
...
foo.SetBar(val);
...
}

프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 조각화 오류가 발생합니다.

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

ptr->field = val;
...
if (ptr != NULL) {
        ...
}

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

if (ptr == null) {
        ptr->field = val;
        ...
}

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

if (ptr == '\0') {
        *ptr = val;
        ...
}

예제 4: 다음 코드에서 프로그래머는 명시적으로 변수 ptr를 NULL로 설정합니다. 나중에 프로그래머는 개체의 null 값을 검사하기 전에 ptr를 역참조합니다.

*ptr = NULL;
...
ptr->field = val;
...
}