.NET에서는 BinaryFormatter 클래스를 사용하여 개체를 개체 자체와 역직렬화 중 이를 재구성하는 데 필요한 메타데이터를 모두 포함하는 바이너리 스트림으로 변환할 수 있습니다.

BinaryFormatter 클래스를 사용하면 공격자가 임의의 코드를 실행하고 응용 프로그램 논리를 남용하거나 서비스 거부(DoS) 조건을 트리거할 수 있는 안전하지 않은 역직렬화 시나리오로 이어질 수 있습니다.

BinaryFormatter 유형 사용은 위험하며 안전하게 보호할 수 없으므로 데이터 처리에 사용하지 않는 것이 좋습니다.

예제 1: 이 응용 프로그램은 runtimeConfig.json 파일의 config 속성 EnableUnsafeBinaryFormatterSerialization을 true로 설정하여 안전하지 않은 BinaryFormatter 클래스의 사용을 활성화합니다.

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

프로그래머는 AccessibleObject API를 사용하여 Java 액세스 지정자가 제공하는 access control 검사를 회피할 수 있습니다. 특히 프로그래머는 reflected 개체가 Java 액세스 제어를 무시하도록 허용하고 개인 필드의 값을 변경하거나 private 메서드를 호출할 수 있지만, 이러한 동작은 일반적으로 허용되지 않습니다.

정규 JSF 응용 프로그램에서는 지정한 변환기 및 유효성 검사기를 사용하여 UI 구성 요소가 값을 변환하고 확인합니다. 변환 및 검증은 페이지가 제출될 때 발생합니다. Fusion 응용 프로그램에서 책갈피 지정 가능한 보기는 페이지 제출로 연결되지 않으므로 기본적으로 유사한 변환 또는 검증이 수행되지 않습니다.

예제 1: 다음 구성 파일 조각은 paramName URL 매개 변수의 변환 또는 검증을 수행하지 않도록 구성된 책갈피 지정 가능한 보기의 샘플을 보여줍니다.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

개발자는 문서화되지 않았거나 숨겨진 API를 사용하여 응용 프로그램을 작성하지 않는 것이 좋습니다. 장래에 Google이 이러한 API를 제거하거나 변경하지 않는다는 보장이 없으므로 이러한 메서드나 필드를 사용하면 응용 프로그램이 손상될 위험이 크기 때문에 사용을 지양해야 합니다.

코드는 미리 릴리스한 후 Camera 개체를 사용하려 합니다. 리소스를 다시 획득하지 않은 Camera 개체에 대한 자세한 참조는 예외를 발생시키며 예외가 발생하지 않은 경우, 응용 프로그램 손상을 일으킬 수 있습니다.

예제 1: 다음 코드는 토글 버튼을 사용하여 카메라 미리보기를 토글 설정하거나 해제합니다. 사용자가 버튼을 한 번 누르고 나면 카메라 미리보기가 중단되고 카메라 리소스가 릴리스됩니다. 그러나 버튼을 다시 누르면 startPreview()가 미리 릴리스한 Camera 개체에서 호출됩니다.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

코드는 미리 릴리스한 후 미디어 개체를 사용하려 합니다. 리소스를 다시 획득하지 않고 미디어 개체에 대한 자세한 참조는 예외를 발생시키며 예외가 발생하지 않은 경우, 응용 프로그램 손상을 일으킬 수 있습니다.

예제 1: 다음 코드는 일시 중지 버튼을 사용하여 미디어 재생을 토글합니다. 사용자가 버튼을 한 번 누르고 나면 현재 노래나 비디오가 일시 중지되고 카메라 리소스가 릴리스됩니다. 그러나 버튼을 다시 누르면 start()가 미리 릴리스한 미디어 리소스에서 호출됩니다.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

코드는 미리 닫고 난 후 Android SQLite 데이터베이스 처리기를 사용하려고 합니다. 데이터베이스 연결을 다시 설정하지 않은 처리기에 대한 자세한 참조는 예외를 발생시키며, 예외가 발생하지 않은 경우 응용 프로그램 손상을 일으킬 수 있습니다.

예제 1: 다음 코드는 메모리의 사용자 값을 일시적으로 캐시하는 프로그램에서 나올 수 있지만 flushUpdates()를 호출하여 디스크에 대한 변경 내용을 커밋할 수 있습니다. 메서드는 데이터베이스에 업데이트를 작성한 후 데이터베이스 처리기를 올바르게 닫습니다. 그러나 flushUpdates() 가 다시 호출될 경우 재초기화 전에 데이터베이스 개체를 다시 참조합니다.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android 클래스 로드 하이재킹 취약점은 다음 두 가지 형태로 나타납니다.

- 프로그램이 클래스를 로드하기 위해 검색하는 디렉터리의 이름을 공격자가 변경하여 자신이 제어권을 가진 디렉터리를 가리키도록 할 수 있습니다. 즉, 클래스를 검색할 경로를 공격자가 명시적으로 제어합니다.

- 클래스가 로드되는 환경을 공격자가 변경할 수 있습니다. 즉, 공격자가 암시적으로 경로 이름의 의미를 제어합니다.

이 경우에는 공격자가 로드할 클래스를 검색하는 디렉터리를 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이러한 유형의 Android 클래스 로드 하이재킹 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.



2. 데이터는 로드할 클래스를 찾을 라이브러리 디렉터리를 나타내는 문자열 또는 문자열의 일부로 사용됩니다.



3. 응용 프로그램은 라이브러리 경로의 코드를 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 사용자가 변경 가능한 userClassPath를 사용하여 로드할 클래스를 검색할 디렉터리를 결정합니다.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

이 코드를 통해 공격자는 userClassPath의 결과를 자신이 제어하는 다른 경로를 가리키도록 수정할 수 있기 때문에 공격자가 라이브러리를 로드하고 응용 프로그램의 높은 권한으로 임의 코드를 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에 공격자가 userClassPath의 값을 제어할 수 있으면, 공격자가 제어하는 디렉터리를 가리키도록 응용 프로그램을 속일 수 있고 이에 따라 공격자가 정의한 클래스를 원래 응용 프로그램과 동일한 권한으로 로드할 수 있습니다.

예제 2: 다음 코드는 사용자가 변경 가능한 userOutput를 사용하여 로드할 클래스를 검색할 디렉터리를 결정합니다.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

이 코드에서는 공격자가 ODEX(Optimized DEX) 파일의 출력 디렉터리를 지정하는 것이 가능합니다. 그러면 악의적인 사용자가 userOutput의 값을 외부 저장소와 같은 자신이 제어하는 디렉터리로 변경할 수 있습니다. 이렇게 되면 출력된 ODEX 파일을 악의적 ODEX 파일로 바꾸기만 하면 원래 응용 프로그램과 동일한 권한으로 실행됩니다.

Zip Path Traversal 취약점은 악의적 작업자가 지정된 Zip 파일에서 Zip 파일 항목 이름을 지정할 때 발생합니다. Zip 파일 항목 이름이 악의적으로 지정되면 공격자는 해당 Zip 파일이 확장될 때 주요 시스템 파일의 내용을 덮어쓸 수 있습니다. 공격자는 ../ 및 / 같은 Path Traversal 표현을 사용하여 프로그램 범위를 벗어나 시스템 파일에 액세스할 수 있습니다. Android 14 이상을 대상으로 하는 Android 응용 프로그램은 Zip 파일 추출 도중 ../ 및 / 같은 표현이 감지될 때 기본적으로 예외를 발생시킬 수 있습니다. 이 보안 기능은 재정의되거나 완전히 비활성화될 수 있습니다.

예제 1: 다음 코드는 Zip Entry Overwrite 보호를 비활성화합니다.

...
dalvik.system.ZipPathValidator.clearCallback();
...

축소는 파일 크기를 줄여 JavaScript 파일을 포함하고 있는 응용 프로그램의 페이지 로드 시간을 개선합니다. 축소는 불필요한 공백, 주석, 세미콜론, 괄호의 제거, 로컬 변수의 이름 축소 및 연결할 수 없는 코드 제거의 과정을 말합니다.

예제 1: 다음 ASPX 코드는 Microsoft의 jQuery 라이브러리의 축소되지 않은 버전을 포함하고 있습니다.

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

확인되지 않은 입력은 ASP.NET Web API 서비스 취약점의 주된 원인 중 하나입니다. 확인되지 않은 입력은 Cross-Site Scripting, Process Control, Access Control 및 SQL Injection 등 수많은 취약점을 야기할 수 있습니다. ASP.NET Web API 서비스는 보통 메모리 손상 공격에는 취약하지 않지만 ASP.NET Web API 서비스가 배열 범위 검사를 수행하지 않는 네이티브 코드를 호출하는 경우, 공격자가 ASP.NET Web API 서비스의 입력값 검증 약점를 이용하여 Buffer Overflow 공격을 가할 수 있습니다.

이러한 공격을 차단하려면 다음을 수행합니다.
1. 검증 속성을 사용하여 모델 바인딩 개체 매개 변수의 매개 변수 또는 멤버에 대한 검증 확인을 ASP.NET Web API 서비스 작업에 프로그래밍 방식으로 주석 추가합니다.
2. ModelState.IsValid를 사용하여 모델 검증의 통과 여부를 확인합니다.

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);

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);
   }
   ...
}

템플릿 엔진은 동적 데이터를 사용하여 콘텐트를 렌더링하는 데 사용됩니다. 이 컨텍스트 데이터는 일반적으로 사용자에 의해 제어되고 웹 페이지, 전자 메일 등을 생성하는 템플릿을 통해 서식이 지정됩니다. 템플릿 엔진을 사용하면 조건절, 루프 등과 같은 코드 생성과 함께 컨텍스트 데이터를 처리함으로써 템플릿에 강력한 언어 식을 사용하여 동적 컨텐츠를 렌더링할 수 있습니다. 공격자가 렌더링될 템플릿을 제어할 수 있는 경우 컨텍스트 데이터를 노출하는 식을 삽입하거나 브라우저에서 악성 코드를 실행할 수도 있습니다.

예제 1: 다음 예제는 템플릿이 URL에서 검색되고 AngularJS로 정보를 렌더링하는 데 사용되는 방법을 보여줍니다.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

이 경우 $stateParams.expression은 잠재적으로 사용자 제어 데이터를 사용하고, 이를 지정된 컨텍스트에서 사용될 템플릿으로 평가합니다. 이로 인해 악의적인 사용자가 브라우저 내에서 원하는 코드를 임의로 실행하여 실행 대상 컨텍스트에 대한 정보를 검색하거나, 응용 프로그램이 생성되는 방법에 대한 추가 정보를 찾거나, 이를 완전한 XSS 공격으로 변환할 수 있습니다.

예상치 못한 작동을 일으킬 수 있으므로 정수 계열 값을 사용하는 경우와 동일하게 부울 값에 대해 산술 연산자가 작동하지 않습니다.

바이트 배열의 데이터를 String으로 변환할 때 해당되는 문자 집합 외부의 데이터가 어떻게 변환되는지는 지정되지 않습니다. 따라서 데이터가 손실되거나, 적절한 보안 대책을 따르기 위해 이진 데이터가 필요할 때 보안 수준이 낮아질 수 있습니다.

예제 1: 다음 코드는 해시를 만들기 위해 데이터를 String으로 변환합니다.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

파일 크기가 BUFSIZE보다 작다고 가정할 때 myFile의 정보를 기본 문자 집합과 같이 인코딩하면 이 코드는 문제 없이 작동합니다. 그러나 이 파일이 다른 인코딩을 사용하거나 이진 파일인 경우에는 정보가 손실됩니다. 그러면 결과로 생성되는 SHA 해시의 안정성이 떨어질 수 있으며, 충돌이 발생하기가 훨씬 쉬워집니다. 특히 기본 문자 집합 외부의 모든 데이터가 물음표 등의 같은 값으로 표현되는 경우에는 더욱 그러합니다.