.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 코드처럼 동일한 쿠키가 로컬에 설치됩니까?

개발자는 문서화되지 않았거나 숨겨진 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 파일로 바꾸기만 하면 원래 응용 프로그램과 동일한 권한으로 실행됩니다.

디버그 바이너리를 생성하도록 Android 응용 프로그램을 구성할 수 있습니다. 이러한 바이너리는 자세한 디버깅 메시지를 제공하므로 운영 환경에서 사용해서는 안 됩니다. <application> 태그의 debuggable 속성은 컴파일된 바이너리에 디버깅 정보를 포함할지 여부를 정의합니다.

디버그 바이너리를 사용하면 응용 프로그램이 사용자에게 가능한 한 많은 정보를 제공하게 됩니다. 디버그 바이너리는 개발 또는 테스트 환경에서 사용하기 위한 것이며 운영 환경에 배포할 경우 보안 위험을 초래할 수 있습니다. 공격자는 디버깅 출력에서 얻은 자세한 정보를 이용하여 응용 프로그램이 사용하는 프레임워크, 데이터베이스 또는 기타 리소스를 공격할 수 있습니다.

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

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

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

기본적으로 ASP.NET 서버는 HttpSessionState 개체, 해당 속성 및 메모리에서 참조하는 모든 개체를 저장합니다. 이 모델은 단일 시스템의 시스템 메모리가 수용할 수 있는 상태로 활성 세션 상태를 제한합니다. 이 제약의 범위를 넘어 용량을 확장하려면 전체적인 성능을 개선하기 위해 용량을 확장하고 여러 시스템 간의 복제를 허용하는 세션 상태 정보를 지속하도록 서버를 자주 구성해야 합니다. 해당 세션 상태를 유지하려면 저장된 모든 개체가 serializable 상태인 HttpSessionState를 서버가 직렬화해야 합니다.

세션을 올바로 직렬화하려면 응용 프로그램이 세션 속성으로 저장하는 모든 개체에 대해 [Serializable] 속성을 선언해야 합니다. 또한, 개체가 사용자 지정 serialization 메서드를 사용해야 하는 경우 ISerializable 인터페이스도 구현해야 합니다.

예제 1: 다음 클래스는 자신을 세션에 추가하지만 serializable 상태가 아니므로 세션을 올바로 직렬화할 수 없습니다.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

축소는 파일 크기를 줄여 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를 사용하여 모델 검증의 통과 여부를 확인합니다.

미들웨어 파이프라인에 올바른 순서로 추가되지 않은 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();
...

인증서 확인 모드를 None으로 설정하면 전체 인증 확인 프로세스가 비활성화되므로 응용 프로그램이 MiTM(Man-in-The-Middle: 메시지 가로채기) 공격에 노출됩니다. 운영 환경에서는 이 모드를 사용하면 안 됩니다.

쿠키는 주로 개인 정보, 인증 토큰 및 활동 기록과 같은 사용자에 대한 중요한 정보를 저장하는 데 사용됩니다. 이 정보가 일반 텍스트로 저장되면 응용 프로그램과 상호 작용하는 데 사용되는 시스템에 액세스할 수 있는 모든 사람이 쿠키에 저장된 정보에 액세스할 수 있습니다. 설상가상으로 공격자가 쿠키에 저장된 데이터를 임의로 수정할 수 있는 경우 응용 프로그램에 제공된 정보를 왜곡하고 공격자에게 유리하도록 동작을 수정할 수 있습니다.

대부분의 경우, 응용 프로그램이 사용된 컨텍스트에 따라 프로그래밍 방식으로 쿠키에서 입력을 확인할 수 있지만 ASP.NET 검증 프레임워크는 쿠키의 내용을 보호하고 쿠키가 예상치 않게 수정되었음을 확인할 수 있는 탁월한 방법을 제공합니다. 이 방법이 아니면 모든 입력을 확인했다는 확신을 얻기가 어렵거나 때로는 불가능합니다.