스티키 브로드캐스트는 권한을 사용하여 보안이 유지될 수 없어 임의의 수신자에 접근할 수 있습니다. 이러한 브로드캐스트가 민감한 데이터를 포함하거나 악성 수신자에 도달하는 경우, 응용 프로그램에 위험을 끼칠 수 있습니다.

예제 1: 다음 코드는 스티키 브로드캐스트(sticky broadcast)를 보냅니다.

...
context.sendStickyBroadcast(intent);
...

android.permission 네임스페이스에 새 권한을 정의하면 OS가 업데이트될 때 예기치 않은 결과가 발생할 수 있습니다. 최신 버전의 OS가 정확히 동일한 권한을 정의하는 경우 Android PMS(패키지 관리 서비스)는 사용자에게 묻지 않고 앱에 자동으로 권한을 부여하여 권한 에스컬레이션 공격을 허용합니다.

이 구성 요소는 다른 구성 요소가 아닌 시스템에서만 브로드캐스트 메시지를 수신해야 하므로 다른 구성 요소에서 접근하지 못하도록 비공개가 되어야 합니다.

쿠키는 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();
  }
  ...
}

하드웨어 및 장치 관련 ID는 데이터를 지우고 공장 기본값으로 재설정한 후에도 유지됩니다. 따라서 이러한 ID에 의존하여 사용자에게 권한을 부여하거나 사용자를 인증하는 데 사용되는 고유 ID를 생성하지 않아야 합니다.

또한 개인 정보와 관련될 수 있는 UUID(Universally Unique Identifier)의 누출은 사용자 개인 정보 및 보안에 위협이 됩니다.

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

AngularJS와 같은 특정 프레임워크는 다른 사이트 및 이미지의 링크에 대해 설정되었을 수 있는 프로토콜을 제한합니다. 이는 주로 인라인 JavaScript 실행을 방지하기 위해서입니다. 인라인 JavaScript가 실행되면 응용 프로그램 내에서 Cross-Site Scripting 취약점이 추가로 발생할 수 있습니다.

예제 1: 다음은 AngularJS에서 프로토콜의 기본 허용 목록을 변경하여 이미지 HTML 요소에서도 인라인 JavaScript를 허용하도록 합니다.

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

SCE(Strict Contextual Escaping)는 공격자로부터 응용 프로그램을 보호하는 데 도움이 되는 AngularJS 응용 프로그램의 메커니즘입니다. 이렇게 하면 다양한 유형의 취약성에서 많은 공격 벡터를 방지할 수 있습니다. 가장 두드러진 기능은 특정 유형의 Cross-Site Scripting 공격으로부터 보호하는 것입니다. 이 응용 프로그램에서는 이 보호 메커니즘이 비활성화되어 있습니다.

예제 1: 이 예제에서는 모듈의 SCE를 비활성화합니다.

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

응용 프로그램은 암호화된 연결을 통한 압축을 허용하는 permessage-deflate WebSocket 확장을 활성화하는 코드를 사용합니다. 이러한 유형의 압축을 활성화하면 응용 프로그램이 CRIME 및 BREACH 유형의 공격을 받을 수 있습니다.

예제 1: 다음 코드는 'per-message-deflate'확장을 활성화하기 위해 DangerousEnableCompression을 true로 설정합니다.

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

예제 2: 다음 코드는 'per-message-deflate' 확장 옵션을 설정하기 위해 DangerousDeflateOptions를 사용합니다.

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

기본적으로 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를 사용하여 모델 검증의 통과 여부를 확인합니다.

Microsoft ASP.NET 응용 프로그램은 권한 있는 작업을 실행하기 위해서 현재 사용자의 보안 컨텍스트 또는 호출된 프로세스를 가장할 수 있습니다. 반드시 수행해야 하는 authentication의 전체 수를 줄이는 것과 같이 가장 컨텍스트를 유용한 목적으로 다양하게 사용할 수 있지만 높은 권한을 유지하는 프로그램은 방대한 보안 시스템에 대한 위험성을 불필요하게 부과하게 됩니다. 다른 보안 컨텍스트에서 프로그램을 실행하는 동안 프로그램에서 공격자가 다른 취약점을 익스플로이트하는 경우 공격자가 수행하는 모든 권한 없는 작업이 해당 권한으로 실행됩니다.

예제 1: 다음 코드 예제는 WindowsIdentity.Impersonate() 메서드를 사용하는 가장 자격 증명에 대한 전형적인 사용 패턴을 보여줍니다.

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

Example 1의 코드는 현재 사용자의 보안 컨텍스트를 가장하여 권한이 있는 작업을 수행합니다. DoSecuritySensitiveTasks()를 호출한 후 코드가 원래의 보안 컨텍스트를 복원하려 하지만 DoSecuritySensitiveTasks()가 예외를 일으키는 경우, Undo() 메서드는 호출되지 않으며 프로그램은 가장된 보안 컨텍스트를 계속 사용합니다.

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