포괄적 용어 “입력 처리”는 입력 데이터의 확인, 정화, 필터링 및 인코딩/디코딩과 같은 기능을 설명합니다. Cross-Site Scripting, SQL injection 및 process control 취약점은 모두 입력 처리가 잘못되거나 없는 것에서 기인합니다. 수용 가능한 형태로 입력 변환을 수반하는 입력 정화는 일반적으로 입력 확인에 추가하여 구현됩니다. HTML 정화는 안전한 태그, 속성 및 요소만 허용하도록 사용자 입력을 정화하고 정리하는 것을 나타냅니다.
완벽한 HTML 정화 정책 구현은 어렵습니다. 성공적인 구현의 핵심은 데이터가 사용될 컨텍스트를 이해하는 것입니다. 각 컨텍스트에는 고유의 취약점이 있으며 하나의 크기가 모두에 맞지는 않습니다. HTML sanitizer(예: OWASP HTML sanitizer)를 사용하여 웹 응용 프로그램의 XSS 취약점을 방지하는 것이 현명하며 부적절한 구현은 보안에 대한 잘못된 인식으로 이어질 수 있습니다.
예제 1: 다음 Java 코드는 HTML sanitizer 정책 구축에서 사용자 제어 입력 변수 elements를 사용합니다.

...
String elements = prop.getProperty("AllowedElements");
...
public static final PolicyFactory POLICY_DEFINITION = new HtmlPolicyBuilder()
															.allowElements(elements)
															.toFactory();

....

악의적인 사용자는 elements를 공급하여 <script> 등의 위험한 요소를 HTML sanitizer 정책에서 수용하도록 할 수 있습니다.

SSL 표준은 클라이언트 측에서 SSL 확인 검사를 수행하는 방법에 대한 지침을 제공합니다. 그러나 이러한 구현은 표준에 포함되어 있지 않습니다. 따라서 확인 로직의 구현은 응용 프로그램 개발자의 몫입니다.

조사에 따르면 SSL 표준 사양의 복잡성과 개방성은 결점 없는 사용자 지정 SSL 구현을 어렵게 만드는 몇 가지 문제를 야기합니다. 사용자 지정 SSL 구현을 사용하는 대부분의 Android 응용 프로그램은 보안 통신 채널을 제공하지 못하는 결점이 있으며 이로 인해 응용 프로그램이 MITM(Man-In-The-Middle) 공격에 취약해집니다.

InetAddress를 함수 매개 변수로 받아들이는 createSocket()에 대한 호출은 호스트 이름 확인을 수행하지 않습니다.

마찬가지로, getInsecure()에 대한 호출은 모든 SSL 검사가 비활성화된 SSL 소켓 팩토리를 반환합니다.

둘 다 모두 응용 프로그램을 MITM(Man-In-The-Middle) 공격에 취약하게 만듭니다.

예를 들어 응용 프로그램은 https://safesecureserver.banking.com 연결을 시도할 때 https://hackedserver.banking.com에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

응용 프로그램은 서버의 최종-엔터티 인증서와 시스템에서 신뢰하는 CA(인증 기관) 인증서 간의 올바른 신뢰 경로의 일부가 아닌 항목을 제거하지 않고 서버에서 반환하는 전체 인증서 목록을 반환하는 메서드를 호출합니다.

공격자가 손상된 CA의 개인 키에 대한 액세스를 소유한 경우 SSL/TLS 연결을 가로채고 서버에서 제공한 인증서를 수정할 수 있습니다. 이 시나리오에서는 공격자가 서버의 최종-엔터티 인증서에서 손상된 루트 CA로의 올바른 신뢰 경로를 생성하여 클라이언트가 인증서를 신뢰하고 서버에서 제공한 나머지 원래 인증서를 추가하게 만들 수 있습니다.

클라이언트가 인증서 고정을 사용하는 경우 "고정된" 인증서가 서버에서 제공한 항목 중 하나임을 확인하게 됩니다. 클라이언트가 올바른 신뢰 경로의 일부가 아닌 항목을 제거하지 않고 서버에서 제공한 모든 인증서를 반환하는 메서드를 사용하는 경우 유효한 손상된 개인 키를 가진 공격자가 웹 서버가 제공한 원래 인증서와 해당 손상된 CA에 대한 유효한 신뢰 경로를 제공할 수 있습니다. 해당 시나리오에서는 공격자가 인증서 고정 확인을 우회할 수 있습니다.

PKI(공용 키 인프라)는 신뢰할 수 있는 CA(인증 기관)를 기반으로 하지만 손상된 인증 기관 증가는 해당 루트 인증서를 더 이상 신뢰할 수 없으며 그렇기 때문에 이 CA에서 서명한 인증서도 신뢰할 수 없음을 의미합니다. 이러한 손상된 인증서를 소유한 공격자는 이러한 CA를 신뢰하는 모든 SSL/TLS 트래픽을 가로챌 수 있습니다.

인증 기관 서명은 임의의 네트워크 끝점에 연결하며 이러한 끝점에 대한 SSL/TLS 인증서를 서명하는 CA에 대한 고급 지식이 없는 브라우저와 같은 범용 네트워크 통신 도구에 필요합니다. 제한된 수의 백엔드 서버에 연결하는 모바일 응용 프로그램은 이러한 서버가 해당 인증서 서명에 사용하고 응용 프로그램에서 이러한 인증서/공용 키를 "고정"하여 응용 프로그램이 예상하는 인증서로 신뢰 수준을 줄일 수 있는 신뢰할 수 있는 CA 최종 후보 목록 인지를 활용할 수 있습니다.

예제 1: 다음 예제는 기본 사전 로드된 시스템 CA를 사용하여 SSL/TLS 연결을 설정합니다.

URL url = new URL("https://myserver.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();

URLConnection에 사용되는 기본 SSLSocketFactory는 변경되지 않았기 때문에 Android 기본 키 저장소에 있는 모든 CA를 신뢰하는 기본 항목을 사용합니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서가 기본적으로 확인되지 않습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 응용 프로그램은 서버 인증서를 명시적으로 확인하지 않습니다.

  ...
  Email email = new SimpleEmail();
  email.setHostName("smtp.servermail.com");
  email.setSmtpPort(465);
  email.setAuthenticator(new DefaultAuthenticator(username, password));
  email.setSSLOnConnect(true);
  email.setFrom("user@gmail.com");
  email.setSubject("TestMail");
  email.setMsg("This is a test mail ... :-)");
  email.addTo("foo@bar.com");
  email.send();
  ...
  

이 응용 프로그램은 smtp.mailserver.com:465 연결을 시도할 때 "hackedserver.com"에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

Android의 백업 서비스를 사용하면 응용 프로그램이 원격 클라우드 스토리지에 영구 데이터를 저장하여 향후에 응용 프로그램 데이터의 복원 지점을 제공할 수 있습니다.

Android 응용 프로그램을 이 백업 서비스로 구성하려면 allowBackup 속성을 true(기본값)로 설정하고 <application> 태그에서 backupAgent 속성을 정의하면 됩니다.

그러나 Android에서는 클라우드 스토리지 및 전송이 장치마다 다르기 때문에 백업을 사용하는 동안 데이터 보안이 보장되지 않습니다.

외부 저장소에 저장한 파일은 누구나 읽을 수 있으며 USB 대용량 저장소로 컴퓨터의 파일을 전송할 때 사용자가 수정할 수 있습니다. 또한, 외부 저장소 카드에 있는 파일은 파일을 작성한 응용 프로그램을 제거한 후에도 그대로 유지됩니다. 이러한 제약으로 인해 저장소에 작성된 민감한 정보가 손상되거나 공격자가 프로그램이 의존하는 외부 파일을 수정하여 악성 데이터를 프로그램에 삽입할 수도 있습니다.

예제 1: 다음 코드에서, Environment.getExternalStorageDirectory()는 Android 장치의 외부 저장소에 대한 참조를 반환합니다.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

MODE_WORLD_READBLE 또는 MODE_WORLD_WRITEABLE을 사용하여 Android 내부 저장소에 저장된 데이터를 장치의 모든 응용 프로그램에서 액세스할 수 있습니다. 이로 인해 데이터가 손상되지 않도록 보호되지 않을 뿐 아니라 민감한 정보의 경우 사용자 개인 정보 유지 및 보안 문제를 위반합니다.

HTTP(S) 응답에 세션 쿠키 및 API 토큰과 같은 민감한 데이터가 포함될 수 있습니다. URL 로딩 시스템은 성능상의 이유로 모든 HTTP(S) 응답을 캐시하고 암호화하지 않은 상태로 안전하지 않은 공유 저장소에 저장합니다.

예제 1: 다음 코드는 공유 저장소 공간에 HTTP(S) 응답 캐시를 설치합니다.

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

응용 프로그램 파일은 루팅된 장치의 다른 응용 프로그램이나 암호화되지 않은 백업에서 액세스할 수 있습니다. 사용자가 자신의 장치를 탈옥하거나 암호화되지 않은 백업을 수행하기로 결정할 수 있기 때문에, 민감한 데이터가 포함된 데이터베이스는 암호화하는 것이 좋습니다.

예제 1: 다음 코드는 암호화되지 않은 Realm 데이터베이스에 대한 연결을 설정합니다.

    Realm realm = Realm.getDefaultInstance();

버킷이나 개체에 대한 전체 익명 액세스 권한을 부여하면 공격자가 콘텐트를 읽거나 악성 콘텐트로 바꿀 수 있습니다.

예제 1: 다음 코드는 foo 버킷에 대한 전체 익명 액세스 권한을 부여하는 Access Control Policy를 설정합니다.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("FullControl");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

버킷이나 개체의 ACP(액세스 제어 정책)를 읽을 수 있는 익명 권한을 부여하면 공격자는 검색하거나 덮어쓸 수 있는 개체를 찾을 수 있습니다.

예제 1: 다음 코드는 foo 버킷에 대한 익명 ACP 읽기 권한을 부여하는 Access Control Policy를 설정합니다.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("READ_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

버킷이나 개체에 대한 익명 읽기 권한을 부여하면 공격자가 콘텐트를 읽을 수 있습니다.

예제 1: 다음 코드는 foo 버킷에 대한 익명 읽기 권한을 부여하는 Access Control Policy를 설정합니다.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Read");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

버킷이나 개체의 ACP(액세스 제어 정책)를 쓸 수 있는 익명 권한을 부여하면 공격자는 해당 버킷에 원하는 콘텐트를 쓰거나 읽을 수 있습니다.

예제 1: 다음 코드는 foo 버킷에 대한 익명 ACP 쓰기 권한을 부여하는 Access Control Policy를 설정합니다.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("WRITE_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

버킷이나 개체에 대한 익명 쓰기 권한을 부여하면 공격자가 콘텐트를 바꾸거나 악성 콘텐트를 업로드할 수 있습니다.

예제 1: 다음 코드는 foo 버킷에 대한 익명 쓰기 권한을 부여하는 Access Control Policy를 설정합니다.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Write");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 침해가 발생하기 쉽습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 데이터를 읽습니다.

   URL url = new URL("http://www.android.com/");
   HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
   try {
     InputStream in = new BufferedInputStream(urlConnection.getInputStream());
     readStream(in);
     ...
   }

수신 스트림 instream은 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

암호화되지 않은 것으로 지정되거나 인증을 지원하지 않거나 연결 ID의 용량이 포함되지 않은 Google Remote Procedure Call(gRPC) 채널 보안 설정을 사용하는 경우 채널이 다양한 형태의 공격에 노출될 수 있습니다. 이러한 비보안 채널을 통해 전송하는 데이터는 신뢰할 수 없습니다.

예제 1: 다음 코드는 비보안 채널 자격 증명을 사용하는 gRPC 채널 설정을 보여줍니다.

...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...

암호화되지 않은 것으로 지정되거나 연결 ID의 용량이 포함되지 않은 Google Remote Procedure Call(gRPC) 서버 보안 설정을 사용하는 경우 서버가 다양한 형태의 공격에 노출될 수 있습니다. 이러한 비보안 서버와 주고받는 데이터는 신뢰할 수 없습니다.

예제 1: 다음 코드는 비보안 서버 자격 증명을 사용하는 gRPC 서버 설정을 보여줍니다.

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

HTTPS 스트리핑 공격은 MITM(Man-In-The-Middle) 공격의 한 유형으로, 이를 통해 공격자는 모든 HTTP 트래픽에서 위치 헤더를 확인한 후 참조하는 HTTPS를 연결하고 이를 HTTP 버전으로 바꿉니다. 공격자는 피해자가 HTTPS 요청을 서버에 다시 보낼 수 있도록 생성된 모든 HTTP 대체 항목을 목록으로 유지합니다. 스트리핑된 모든 HTTP 연결은 프록시를 사용하여 HTTPS를 통해 서버로 전송됩니다. 피해자와 공격자 간의 모든 트래픽은 HTTP를 통해 전송되어 사용자 이름, 암호 및 기타 민감한 정보가 공개되지만 서버는 여전히 공격자로부터 예상되는 HTTPS 트래픽을 수신하므로 아무것도 잘못된 것처럼 보이지 않습니다.

HSTS(HTTP Strict Transport Security)는 브라우저가 항상 HSTS 헤더를 헤더 내에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 http://를 입력하더라도 HTTPS 연결로 자동으로 바뀝니다.

예제 1: 다음 코드는 하위 도메인에 대해 HSTS를 사용하지 않도록 Spring Security로 보호된 응용 프로그램을 구성합니다.

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts include-sub-domains="false" />
        </headers>
	</http>