취약한 인증 메커니즘을 사용하는 조직은 무단 액세스 위험에 노출됩니다.

인증 메커니즘은 다음과 같은 다양한 이유로 실패할 수 있습니다.
- 취약한 비밀번호
- 부적절한 유효성 검사
- 취약한 자격 증명 관리 기능

취약한 인증 메커니즘을 사용하는 조직은 무단 액세스 위험에 노출됩니다.

인증 메커니즘은 다음과 같은 다양한 이유로 실패할 수 있습니다.
- 취약한 비밀번호
- 부적절한 유효성 검사
- 취약한 자격 증명 관리 기능

취약한 인증 메커니즘을 사용하는 조직은 무단 액세스 위험에 노출됩니다.

인증 메커니즘은 다음과 같은 다양한 이유로 실패할 수 있습니다.
- 취약한 비밀번호
- 부적절한 유효성 검사
- 취약한 자격 증명 관리 기능

취약한 인증 메커니즘을 사용하는 조직은 무단 액세스 위험에 노출됩니다.

인증 메커니즘은 다음과 같은 다양한 이유로 실패할 수 있습니다.
- 취약한 비밀번호
- 부적절한 유효성 검사
- 취약한 자격 증명 관리 기능

Bean을 채우기 전에 Bean 속성 이름과 값을 확인해야 합니다. Bean 채우기 기능을 통해 개발자가 Bean 속성 또는 Nested 속성을 설정할 수 있습니다. 공격자는 이 기능을 활용하여 시스템 속성을 오버라이드하고 임의의 코드를 실행할 수 있는 특수 Bean 속성(예: class.classLoader)에 액세스할 수 있게 됩니다.

예제 1: 다음 코드는 속성 이름이나 값에 대한 적합한 확인 없이 사용자 제어 Bean 속성을 설정합니다.

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

터치 ID 기반 인증은 LocalAuthentication 프레임워크를 사용하거나 키 집합 서비스의 터치 ID 기반 액세스 제어를 사용하는 두 가지 방법으로 구현할 수 있습니다.

두 방법 모두 대부분의 응용 프로그램에 대해 충분히 강력하지만 LocalAuthentication 방법은 뱅킹, 의료 및 보험과 같은 고위험 응용 프로그램에는 적합성이 떨어지는 몇 가지 특성을 갖고 있습니다.

- LocalAuthentication은 장치의 Secure Enclave 외부에서 정의되며 이는 해당 API가 탈옥된 장치에서 후크 또는 수정될 수 있음을 의미합니다.
- LocalAuthentication은 true 또는 false로만 평가될 수 있는 컨텍스트 정책을 평가하여 사용자를 인증합니다. 이 부울 평가는 응용 프로그램이 실제 인증되는 사람이 누군인지 알 수 없고 장치에 등록된 지문이 사용되었는지 여부만 안다는 것을 의미합니다. 또한 향후에 등록될 수 있는 지문도 true로 평가됩니다.


예제 1: 다음 코드에서는 LocalAuthentication 프레임워크를 사용하여 사용자 인증을 수행합니다.

    ...
    LAContext *context = [[LAContext alloc] init];  
    NSError *error = nil;  
    NSString *reason = @"Please authenticate using the Touch ID sensor.";
    
    if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {  
        [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
            localizedReason:reason
                reply:^(BOOL success, NSError *error) {
                    if (success) {
                        // Fingerprint was authenticated
                    } else {
                        // Fingerprint could not be authenticated
                    }
            }
        ];
    ...

터치 ID 기반 인증은 키 집합에 항목을 저장하고 사용자가 나중에 항목을 검색할 때 자신의 지문을 사용해야 하도록 설정함으로써 키 집합 서비스를 사용하여 구현할 수 있습니다. 다음 정책을 사용하여 사용자가 자신의 지문을 사용하여 인증하는 방법을 정의할 수 있습니다.

- kSecAccessControlUserPresence: 터치 ID 또는 암호를 사용한 액세스로 제한합니다. 터치 ID가 사용 가능하거나 등록될 필요가 없습니다. 지문이 추가되거나 제거되더라도 터치 ID로 항목에 액세스할 수 있습니다.
- kSecAccessControlTouchIDAny: 터치 ID를 사용한 액세스를 등록된 모든 지문으로 제한합니다. 지문이 추가되거나 제거될 때 항목이 무효화되지 않습니다.
- kSecAccessControlTouchIDCurrentSet: 터치 ID를 사용한 액세스를 현재 등록된 모든 지문으로 제한합니다. 지문이 추가되거나 제거될 때 항목이 무효화됩니다.

터치 ID를 사용할 때는 kSecAccessControlTouchIDCurrentSet 특성을 사용하여 향후 지문 추가 또는 제거로부터 보호해야 합니다.

예제 1: 다음 코드에서는 향후 등록되는 모든 지문이 키 집합 항목을 잠금 해제할 수 있도록 허용하는 kSecAccessControlTouchIDAny 제약 조건을 사용합니다.

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

Apple의 정책에 따르면 응용 프로그램은 항상 지문이 필요한 이유를 사용자에게 설명해야 합니다. 이렇게 하지 않으면 사용자에게 혼동이 발생하거나 응용 프로그램이 AppStore에서 거부될 수도 있습니다.

예제 1: 다음 코드에서는 터치 ID를 사용하여 사용자를 인증하지만 인증이 필요한 이유를 설명하는 지역화된 설명을 제공하지 못합니다.

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

Buffer overflow의 취약점은 일반적으로 다음 코드에 나타납니다.

- 외부 데이터를 사용하여 동작을 제어하는 코드.

- 코드 범위 밖에서 이행되는 데이터의 속성에 의존하는 코드.

- 너무 복잡해서 프로그래머가 정확하게 동작을 예측할 수 없는 코드.



다음 예제는 세 가지 시나리오를 모두 보여줍니다.

예제 1.a: 다음 샘플 코드는 코드가 외부 데이터를 사용하여 동작을 제어하는 첫 번째 시나리오에서 자주 발생하는 간단한 buffer overflow를 보여줍니다. 코드는 gets() 함수를 사용하여 임의의 양의 데이터를 스택 버퍼에 읽어들입니다. 이 함수가 읽는 데이터의 양을 제한할 방법이 없기 때문에 코드의 안전성은 사용자가 BUFSIZE 문자보다 적은 문자를 입력하는 것에 의존할 수 밖에 없습니다.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

예제 1.b: 이 예제는 >> 연산자를 사용하여 입력을 char[] 문자열에 읽어들임으로써 C++의 gets() 함수의 안전하지 않은 동작을 쉽게 모방할 수 있다는 것을 보여줍니다.

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

예제 2: 또한 이 예제의 코드는 사용자 입력에 의존하여 동작을 제어하지만 범위 지정 메모리 복사 함수 memcpy()를 사용하여 간접 참조를 추가합니다. 이 함수는 대상 버퍼, 소스 버퍼 및 복사할 바이트 수를 받습니다. 입력 버퍼는 범위 지정 read() 호출로 채워지지만 사용자는 memcpy()가 복사하는 바이트 수를 지정합니다.

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

참조: 이런 유형의 buffer overflow 취약점(프로그램이 데이터를 읽고 나머지 데이터에 대한 이후의 메모리 작업에서 이 데이터의 값을 신뢰하는 경우)은 이미지, 오디오 및 기타 파일 처리 라이브러리에 자주 발생합니다.

예제 3: 다음은 코드가 로컬로 확인되지 않는 데이터의 속성에 의존하는 두 번째 시나리오의 예제입니다. 이 예제에서 lccopy()라는 함수는 문자열을 인수로 받아 모든 대문자를 소문자로 변환한 문자열의 힙 할당 복사본을 반환합니다. 이 함수는 str이 항상 BUFSIZE보다 작다고 예상하기 때문에 해당 입력에 대한 범위 검사를 수행하지 않습니다. 공격자가 lccopy()를 호출하는 코드의 검사를 우회하거나 해당 코드를 변경하여 str의 크기에 대한 가정을 참이 아닌 값으로 만드는 경우, lccopy()는 strcpy()를 범위 지정 없이 호출하여 buf 오버플로를 일으킵니다.

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

예제 4: 세 번째 시나리오(코드가 너무 복잡하여 동작을 쉽게 예측할 수 없음)에 해당하는 코드가 아래에 나와 있습니다. 이 코드는 다양한 응용 프로그램에서 널리 사용되는 libPNG 이미지 디코더에서 발췌한 것입니다.

코드는 변수 길이를 검사하기 때문에 범위 검사를 안전하게 수행하는 것처럼 보입니다. 코드는 나중에 이 변수 길이를 사용하여 png_crc_read()가 복사하는 데이터 양을 제어합니다. 하지만 길이를 테스트하기 직전에 코드는 png_ptr->mode에 대한 검사를 수행하고 이 검사가 실패하면 경고를 표시하고 처리를 계속합니다. length는 else if 블록에서 테스트되므로 첫 번째 검사가 실패하면 length가 테스트되지 않고 png_crc_read() 호출에 무조건 사용되어 스택 Buffer Overflow를 허용할 수 있습니다.

이 예제의 코드가 이제까지 본 코드 중에 가장 복잡한 것은 아니지만 메모리 작업을 수행하는 코드에서 복잡성을 최소화해야 하는 이유를 잘 보여줍니다.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

예제 5: 이 예제는 프로그램의 복잡성 때문에 buffer overflow에 노출되는 세 번째 시나리오도 보여줍니다. 이 경우, 노출은 코드의 구조 때문이 아니라 함수의 모호한 인터페이스 때문입니다(이전 예제의 경우와 마찬가지).

getUserInfo() 함수는 지정한 사용자 이름을 멀티바이트 문자열 및 사용자 정보의 구조체에 대한 포인터로 받아 사용자에 대한 정보로 구조체를 채웁니다. Windows authentication이 사용자 이름에 유니코드를 사용하기 때문에 우선 username 인수를 멀티바이트 문자열에서 유니코드 문자열로 변환합니다. 그런 다음 이 함수는 unicodeUser의 크기를 문자 수가 아닌 바이트 수로 잘못 전달합니다. 따라서 MultiByteToWideChar() 호출은 (UNLEN+1)*sizeof(WCHAR) 길이의 문자 또는
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR)바이트까지 (UNLEN+1)*sizeof(WCHAR)바이트만 할당된 unicodeUser 배열에 쓸 수 있습니다. username 문자열에 UNLEN 문자 넘게 포함되면 MultiByteToWideChar() 호출은 버퍼 unicodeUser 오버플로를 일으킵니다.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

이 경우 부적절하게 생성된 format string으로 인해 프로그램이 할당된 메모리 경계를 넘어서 쓸 수 있습니다.

예제 1: 다음 코드는 c에 할당된 공간보다 double 유형에 더 많은 공간이 필요하므로 c 오버플로를 일으킵니다.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

이 경우 부적절하게 생성된 format string으로 인해 프로그램이 할당된 메모리 경계를 넘어서 쓸 수 있습니다.

예제 1: 다음 코드는 f 크기에 따라 형식 문자열 지정자 "%d %.1f ... "가 할당된 메모리의 양을 초과할 수 있으므로 buf 오버플로를 일으킵니다.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 off-by-one 오류가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 스택 및 힙 buffer overflow를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

예제 1: 다음 코드에는 off-by-one buffer overflow가 있습니다. 이는 recv가 읽은 최대 허용되는 sizeof(buf) 바이트를 반환할 때 발생합니다. 이 경우, 이후의 buf[nbytes] 역참조는 할당된 메모리 블록의 경계 외부에서 null 바이트를 씁니다.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

예제 1: 다음 코드는 getInputLength()에서 읽은 신뢰할 수 없는 값이 대상 버퍼 output의 크기보다 작은지 확인하여 off-by-one buffer overflow를 막습니다. 그러나 len과 MAX의 비교에 부호가 있으므로 len이 음수인 경우 부호 없는 인수가 memcpy()로 변환되면 매우 큰 양수가 됩니다.

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

Apache Ivy 자동 dependency 관리 시스템을 사용하면 dependency에 대해 특정 dependency를 나열하는 것 대신 동적 수정 버전이라고도 하는 버전 상태를 지정할 수 있습니다. 공격자가 dependency 리포지토리를 손상시키거나 build system을 속여 공격자의 제어 하에 리포지토리에서 dependency를 다운로드하도록 할 수 있는 경우, build system이 손상된 dependency를 자동으로 다운로드하고 실행하는 데에는 동적 수정 버전 지정자만 있으면 됩니다. 동적 수정 버전에는 보안 위험 외에도 code quality 면에서 다음과 같은 위험 요소도 있습니다. 동적 수정 버전은 소프트웨어에 사용되는 dependency를 개발하고 출시한 타사의 제어를 받아 소프트웨어의 보안성 및 안정성을 부여합니다.

빌드 시 Ivy는 리포지토리에 연결하고 나열된 상태와 일치하는 dependency를 검색하려고 합니다.

Ivy는 다음 동적 수정 버전 지정자를 받아 들입니다.

- latest.integration: dependency 모듈의 최신 수정 버전을 선택합니다.
- latest.[any status]: 최소한의 지정된 상태에서 dependency 모듈의 최신 수정 버전을 선택합니다. 예를 들어 latest.milestone은 중요 시점 또는 릴리스인 최신 버전을 선택하고 latest.release는 최신 릴리스만 선택합니다.
- +로 끝나는 모든 수정 버전: dependency 모듈의 최신 하위 수정 버전을 선택합니다. 예를 들어 수정 버전 1.0.3, 1.0.7 및 1.1.2에 dependency가 있는 경우 1.0.+로 지정된 수정 버전은 수정 버전 1.0.7을 선택합니다.
- 버전 범위: < 및 >와 같은 범위에 대한 수학적 표기법을 사용하여 버전 범위를 일치할 수 있습니다.

예제 1: 다음 구성 항목은 Ivy에 clover 구성 요소의 최신 릴리스 버전을 검색하도록 지시합니다.

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

리포지토리가 손상되면 공격자는 Ivy에 악의적인 버전의 dependency를 다운로드할 수 있는 동적 조건을 충족시키는 버전을 그대로 업로드할 수 있습니다.

Dependency 관리를 지원하는 Java 개발 환경에는 다음과 같은 몇 가지 도구가 있습니다. Apache Ant 및 Apache Maven build system에는 종속성을 관리하는 데 도움을 주도록 특별히 설계된 기능이 포함되어 있으며, Apache Ivy는 dependency 관리자로서 개발되었습니다. 이러한 도구들은 동작에는 차이점이 있지만 빌드 시 빌드 프로세스에 지정된 외부의 종속성을 자동으로 다운로드하는 일반적인 기능은 공통적으로 가지고 있습니다. 따라서 개발자 B가 개발자 A와 동일한 방법으로 소프트웨어를 쉽게 빌드할 수 있습니다. 개발자들은 dependency 정보를 빌드 파일에 저장합니다. 즉, 각 개발자 및 빌드 엔지니어가 수동 dependency 관리 시 일어나는 dependency 관리 문제 없이 종속성을 얻고 코드를 컴파일하고 배치하는 일관된 방법을 가진다는 것을 의미합니다. 다음 예제는 Ivy, Ant 및 Maven이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

개발자는 해당 URL에 의해 지정된 dependency를 검색하는 <get> 작업을 사용하여 Ant 대상의 외부 종속성을 지정합니다. 이 방법은 개발자가 각 외부 dependency를 소프트웨어 프로젝트에 포함된 아티팩트로 문서화하는 경우와 기능적으로는 동일하지만, 빌드가 수행되면 종속성의 검색 및 결합이 자동화되므로 더욱 바람직합니다.

예제 1: Ant build.xml 구성 파일에서 발췌한 다음 내용은 외부 dependency에 대한 일반적인 참조를 보여 줍니다.

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 dependency를 호스팅하는 서버를 손상시키거나, dependency를 호스팅하는 서버의 호스트 이름에 대한 요청을 공격자에 의해 제어되는 시스템으로 리디렉션하도록 build system이사용하는 DNS 서버를 손상시킬 수 있습니다. 두 경우 모두, 공격자는 악의적인 버전의 dependency를 손상되지 않은 시스템에서 실행 중인 빌드에 삽입할 수 있는 능력을 얻게 됩니다.

Trojan dependency를 전달하는 데 사용되는 공격에 관계없이 이러한 경우에는 build system에서 악성 바이너리를 무조건 받고 빌드에 포함시킨다는 점이 공통 사항입니다. Build system은 일반적으로 외부 종속성이 아닌 내부적으로 개발된 코드에 초점을 맞춘 코드 검사 등의 악성 바이너리 및 기존 보안 메커니즘을 거부할 방법이 없으므로 이런 유형의 공격은 개발 환경 및 제품에 잠재적으로 퍼져 있는 것처럼 눈에 띄지 않게 진행될 가능성이 큽니다.

수동 빌드 프로세스에 손상된 dependency가 발생할 위험이 일부 있지만, 매번 외부 소스에서 dependency를 검색하는 자동화된 build system의 경향으로 인해 build system은 공격자에게 기회의 창이 크게 증가된 새로운 환경에서 실행됩니다. 공격자가 빌드를 실행 중인 시스템을 손상시키는 데에는 dependency를 검색하는 여러 번 중 한 번만 dependency 서버 또는 DNS 서버만 손상시키기만 하면 됩니다.

Dependency 관리를 지원하는 Java 개발 환경에는 다음과 같은 몇 가지 도구가 있습니다. Apache Ant 및 Apache Maven build system에는 종속성을 관리하는 데 도움을 주도록 특별히 설계된 기능이 포함되어 있으며, Apache Ivy는 dependency 관리자로서 개발되었습니다. 이러한 도구들은 동작에는 차이점이 있지만 빌드 시 빌드 프로세스에 지정된 외부의 종속성을 자동으로 다운로드하는 일반적인 기능은 공통적으로 가지고 있습니다. 따라서 개발자 B가 개발자 A와 동일한 방법으로 소프트웨어를 쉽게 빌드할 수 있습니다. 개발자들은 dependency 정보를 빌드 파일에 저장합니다. 즉, 각 개발자 및 빌드 엔지니어가 수동 dependency 관리 시 일어나는 dependency 관리 문제 없이 종속성을 얻고 코드를 컴파일하고 배치하는 일관된 방법을 가진다는 것을 의미합니다. 다음 예제는 Ivy, Ant 및 Maven이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

Ivy의 경우, 개발자는 종속성을 검색할 명시적인 URL을 나열하는 대신 dependency 이름과 버전을 지정하고 Ivy는 자체의 기본적인 구성에 의존하여 종속성을 검색하는 서버를 식별합니다. 따라서 일반적으로 사용되는 구성 요소의 경우에는 개발자가 dependency 위치를 확인하지 않아도 됩니다.

예제 1: Ivy ivy.xml 파일에서 발췌한 다음 내용은 개발자가 이름과 버전을 사용하여 여러 외부 종속성을 지정하는 방법을 보여 줍니다.

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 dependency를 호스팅하는 서버를 손상시키거나, dependency를 호스팅하는 서버의 호스트 이름에 대한 요청을 공격자에 의해 제어되는 시스템으로 리디렉션하도록 build system이사용하는 DNS 서버를 손상시킬 수 있습니다. 두 경우 모두, 공격자는 악의적인 버전의 dependency를 손상되지 않은 시스템에서 실행 중인 빌드에 삽입할 수 있는 능력을 얻게 됩니다.

Trojan dependency를 전달하는 데 사용되는 공격에 관계없이 이러한 경우에는 build system에서 악성 바이너리를 무조건 받고 빌드에 포함시킨다는 점이 공통 사항입니다. Build system은 일반적으로 외부 종속성이 아닌 내부적으로 개발된 코드에 초점을 맞춘 코드 검사 등의 악성 바이너리 및 기존 보안 메커니즘을 거부할 방법이 없으므로 이런 유형의 공격은 개발 환경 및 제품에 잠재적으로 퍼져 있는 것처럼 눈에 띄지 않게 진행될 가능성이 큽니다.

수동 빌드 프로세스에 손상된 dependency가 발생할 위험이 일부 있지만, 매번 외부 소스에서 dependency를 검색하는 자동화된 build system의 경향으로 인해 build system은 공격자에게 기회의 창이 증가된 새로운 환경에서 실행됩니다. 공격자가 빌드를 실행 중인 시스템을 손상시키는 데에는 dependency를 검색하는 여러 번 중 한 번만 dependency 서버 또는 DNS 서버만 손상시키기만 하면 됩니다.

Dependency 관리를 지원하는 Java 개발 환경에는 다음과 같은 몇 가지 도구가 있습니다. Apache Ant 및 Apache Maven build system에는 종속성을 관리하는 데 도움을 주도록 특별히 설계된 기능이 포함되어 있으며, Apache Ivy는 dependency 관리자로서 개발되었습니다. 이러한 도구들은 동작에는 차이점이 있지만 빌드 시 빌드 프로세스에 지정된 외부의 종속성을 자동으로 다운로드하는 일반적인 기능은 공통적으로 가지고 있습니다. 따라서 개발자 B가 개발자 A와 동일한 방법으로 소프트웨어를 쉽게 빌드할 수 있습니다. 개발자들은 dependency 정보를 빌드 파일에 저장합니다. 즉, 각 개발자 및 빌드 엔지니어가 수동 dependency 관리 시 일어나는 dependency 관리 문제 없이 종속성을 얻고 코드를 컴파일하고 배치하는 일관된 방법을 가진다는 것을 의미합니다. 다음 예제는 Ivy, Ant 및 Maven이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

Maven의 경우, 개발자는 종속성을 검색할 명시적인 URL을 나열하는 대신 dependency 이름과 버전을 지정하고 Maven은 자체의 기본적인 구성에 의존하여 종속성을 검색하는 서버를 식별합니다. 따라서 일반적으로 사용되는 구성 요소의 경우에는 개발자가 dependency 위치를 확인하지 않아도 됩니다.

예제 1: Maven pom.xml 파일에서 발췌한 다음 내용은 개발자가 이름과 버전을 사용하여 여러 외부 종속성을 지정하는 방법을 보여줍니다.

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 dependency를 호스팅하는 서버를 손상시키거나, dependency를 호스팅하는 서버의 호스트 이름에 대한 요청을 공격자에 의해 제어되는 시스템으로 리디렉션하도록 build system이사용하는 DNS 서버를 손상시킬 수 있습니다. 두 경우 모두, 공격자는 악의적인 버전의 dependency를 손상되지 않은 시스템에서 실행 중인 빌드에 삽입할 수 있는 능력을 얻게 됩니다.

Trojan dependency를 전달하는 데 사용되는 공격에 관계없이 이러한 경우에는 build system에서 악성 바이너리를 무조건 받고 빌드에 포함시킨다는 점이 공통 사항입니다. Build system은 일반적으로 외부 종속성이 아닌 내부적으로 개발된 코드에 초점을 맞춘 코드 검사 등의 악성 바이너리 및 기존 보안 메커니즘을 거부할 방법이 없으므로 이런 유형의 공격은 개발 환경 및 제품에 잠재적으로 퍼져 있는 것처럼 눈에 띄지 않게 진행될 가능성이 큽니다.

수동 빌드 프로세스에 손상된 dependency가 발생할 위험이 일부 있지만, 매번 외부 소스에서 dependency를 검색하는 자동화된 build system의 경향으로 인해 build system은 공격자에게 기회의 창이 크게 증가된 새로운 환경에서 실행됩니다. 공격자가 빌드를 실행 중인 시스템을 손상시키는 데에는 dependency를 검색하는 여러 번 중 한 번만 dependency 서버 또는 DNS 서버만 손상시키기만 하면 됩니다.

CakePHP는 오류, 경고, SQL 문 및 스택 추적을 포함하는 디버깅 정보를 노출하도록 구성할 수 있습니다. Debug information은 운영 환경에서 사용되지 말아야 합니다.

예제 1:

    Configure::write('debug', 3);

Configure::write() 메서드에 대한 두 번째 매개 변수는 디버그 레벨을 나타냅니다. 숫자가 높을수록 로그 메시지가 더 자세히 표시됩니다.

세션을 더 오래 열어둘수록, 공격자가 사용자 계정을 손상시킬 수 있는 기회는 더 커집니다. 세션이 활성화 상태라면 공격자는 사용자의 암호를 무차별 대입하거나 사용자의 무선 암호화 키를 불법으로 복제하거나 열려 있는 브라우저에서 세션을 제멋대로 쓸 수도 있습니다. 또한 세션 초과 시간이 더 길어지면 메모리가 해제되지 못하도록 하여 결국 충분히 많은 세션이 만들어지는 경우 denial of service가 발생됩니다.

예제 1: 다음 예제는 low 세션 보안으로 구성된 CakePHP를 보여줍니다.

    Configure::write('Security.level', 'low');

Session.timeout 설정과 함께 Security.level 설정은 세션의 유효 기간을 정의합니다. 실제 세션 시간 초과 값은 Session.timeout에 다음 곱셈 중 하나를 곱한 값과 같습니다.

'high' = x 10
'medium' = x 100
'low' = x 300

castor가 개체에 대한 잠금을 만든다 해도 개체를 읽거나 개체에 쓰지 못하도록 다른 스레드를 보호하지 못합니다. 또한 읽기 전용 쿼리는 기본 공유 모드와 비교하여 약 7배 더 빠릅니다.

예제 1: 다음 예는 쿼리 모드를 읽기 및 쓰기 접근 모두를 허용하는 SHARED로 지정합니다.

results = query.execute(Database.SHARED);