.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>
...

Oracle ADF Faces 구성 요소의 속성 값은 대개 서버에서만 설정될 수 있습니다. 그러나 구성 요소가 많으면 개발자가 클라이언트에서 설정될 수 있는 속성의 목록을 정의할 수 있습니다. 이러한 구성 요소의 unsecure 속성은 그러한 목록을 지정할 수 있습니다.

현재 unsecure 속성 내에 나타날 수 있는 유일한 속성은 disabled이며, 이는 활성화되는 구성 요소와 그렇지 않은 구성 요소를 클라이언트가 정의하도록 허용합니다. 서버에서만 설정할 수 있는 속성의 값을 클라이언트가 제어하도록 하는 것은 좋은 방법이 아닙니다.

예제 1: 다음 코드는 사용자에게서 비밀번호 정보를 수집하고 unsecure 속성을 사용하는 inputText 구성 요소를 보여줍니다.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

쿠키는 RFC 2109에 따라 엄격하게 제한되는 HTTP 메커니즘입니다. file://을 비롯해, HTTP 이외의 프로토콜에서 작동한다고 기대할 합리적인 이유가 없습니다. 어떤 동작이 수행될지, 어떤 보안 분류 규칙이 적용될지가 분명하지 않습니다. 예를 들어 인터넷 공유에서 로컬 디스크로 HTML 파일을 다운로드해야 한다면 HTML 코드처럼 동일한 쿠키가 로컬에 설치됩니까?

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

확인되지 않은 입력은 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를 사용하여 모델 검증의 통과 여부를 확인합니다.

미들웨어 파이프라인에 올바른 순서로 추가되지 않은 ASP.NET Core 미들웨어는 의도한 대로 작동하지 않아 응용 프로그램이 다양한 보안 문제에 노출될 수 있습니다.

예제 1:UseCookiePolicy() 메서드는 쿠키 정책 미들웨어를 미들웨어 파이프라인에 추가하여 사용자 지정 쿠키 정책을 허용합니다. 표시된 대로 잘못된 순서로 지정하면 프로그래머가 지정한 모든 쿠키 정책이 무시됩니다.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

미들웨어 파이프라인에 올바른 순서로 추가되지 않은 ASP.NET Core 미들웨어는 의도한 대로 작동하지 않아 응용 프로그램이 다양한 보안 문제에 노출될 수 있습니다.

예제 1:UseHttpsRedirection() 메서드는 안전하지 않은 HTTP 요청을 안전한 HTTPS 요청으로 리디렉션할 수 있도록 미들웨어 파이프라인에 HTTPS 리디렉션 미들웨어를 추가합니다. 표시된 대로 잘못된 순서로 지정하면 리디렉션 전에 나열된 미들웨어를 통해 요청을 처리하기 전에 의미 있는 HTTPS 리디렉션이 발생하지 않습니다. 이렇게 하면 안전한 HTTPS 연결로 리디렉션되기 전에 응용 프로그램에서 HTTP 요청을 처리할 수 있습니다.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

미들웨어 파이프라인에 올바른 순서로 추가되지 않은 ASP.NET Core 미들웨어는 의도한 대로 작동하지 않아 응용 프로그램이 다양한 보안 문제에 노출될 수 있습니다.

예제 1:UseHttpLogging() 메서드는 미들웨어 구성 요소가 로깅할 수 있도록 미들웨어 파이프라인에 HTTP 로깅 미들웨어를 추가합니다. 표시된 대로 잘못된 순서로 지정하면 UseHttpLogging() 호출 전에 파이프라인에 추가된 미들웨어는 로깅되지 않습니다.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

예제 2:UseWC3Logging() 메서드는 미들웨어 구성 요소가 로깅할 수 있도록 미들웨어 파이프라인에 W3C 로깅 미들웨어를 추가합니다. 표시된 대로 잘못된 순서로 지정하면 UseWC3Logging() 호출 전에 파이프라인에 추가된 미들웨어는 로깅되지 않습니다.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

쓰기, 업데이트 또는 삭제를 통해 데이터를 수정하는 ASP.NET MVC 컨트롤러 작업은 다음 HTTP 동사 중 하나만 수락하도록 제한하는 것이 좋을 수 있습니다. Post, Put, Patch 또는 Delete. 이렇게 하면 실수로 링크를 클릭해도 작업이 실행되지 않으므로 교차 사이트 요청 위조가 어려워집니다.

다음 컨트롤러 작업은 기본적으로 모든 verb를 허용하므로 cross-site request forgery에 취약할 수 있습니다.

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

[Required] 속성으로 표시되는 필수 속성과 [Required] 속성으로 표시되지 않는 옵션 속성이 모두 포함된 모델 클래스를 사용하는 경우, 공격자가 필요한 것보다 많은 데이터가 포함된 요청을 전달하면 문제가 발생할 수 있습니다.

ASP.NET MVC 프레임워크는 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

모델에 바인딩할 매개 변수를 명시적으로 전달하지 않고 필수 속성과 비필수 속성을 혼합하여 포함하고 있으면 내부용 모델 속성을 공격자가 제어하게 될 수 있습니다.

다음 코드는 [Required]가 지정된 속성과 [Required]가 지정되지 않은 속성이 포함된 가능 모델 클래스를 정의합니다.

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

옵션 매개 변수를 사용하여 응용 프로그램 동작을 변경할 수 있는 경우 공격자가 요청에서 옵션 매개 변수를 전달하면 해당 동작을 실제로 변경할 수 있습니다.

null이 허용되지 않는 필수 속성([Required] 속성으로 표시됨)이 포함된 모델 클래스를 사용하는 경우, 공격자가 필요한 것보다 적은 데이터가 포함된 요청을 전달하면 문제가 발생할 수 있습니다.

ASP.NET MVC 프레임워크는 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

모델에 null이 허용되지 않는 필수 매개 변수가 포함되어 있는데 공격자가 요청 시 필수 매개 변수를 전달하지 않는 경우, 즉 공격자가 under-posting 공격을 사용하면 속성에 기본값(보통 0)이 지정되므로 [Required] 확인 속성이 충족됩니다. 따라서 응용 프로그램이 예기치 않게 동작할 수 있습니다.

다음 코드는 null이 허용되지 않는 필수 열거가 포함된 가능 모델 클래스를 정의합니다.

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

필수 속성을 포함하며 유형이 상위 모델 클래스의 옵션 멤버인 모델 클래스는 공격자가 필요한 것보다 적은 데이터가 포함된 요청을 전달하면 under-posting 공격에 취약해질 수 있습니다.

ASP.NET MVC 프레임워크는 하위 모델을 포함한 요청 매개 변수를 모델 속성에 바인딩하려고 합니다.

하위 모델이 옵션인 경우, 즉 상위 모델에 [Required] 속성이 없는 속성이 있는 경우에 공격자가 해당 하위 모델을 전달하지 않으면 상위 모델에는 null 값이 지정되고 하위 모델의 필수 필드가 모델 확인을 통해 어설션되지 않습니다. 이는 under-posting 공격의 한 형태입니다.

다음의 모델 클래스 정의를 살펴보십시오.

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

공격자가 ParentModel.Child 속성의 값을 전달하지 않으면 ChildModel.RequiredProperty 속성에 [Required]가 지정되며, 이 값은 어설션되지 않습니다. 따라서 예기치 않은 부적절한 결과가 발생할 수 있습니다.

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

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