包括的用語である「入力処理」は入力データのエンコーディングやデコーディング、検証、サニタイズ、フィルタリングのような機能を示します。Cross-Site Scripting、SQL Injection、Process Control の脆弱性は、いずれも入力処理が正しくなかったり、行われなかったりしたことが原因となっています。(入力を許容可能なフォームに変換することが必要な) 入力のサニタイズは、通常、入力検証に加えて実施されます。HTML サニタイズとは、ユーザー入力をクレンジングおよび消去し、安全と見なされるタグ、属性、要素のみを許容することを示します。
HTML サニタイズ ポリシーの実施は難しいです。実施を成功させる鍵はデータが使用されるコンテキストを理解することです。各コンテキストにはそれぞれの脆弱性があり、1 つのサイズがすべてに適合するわけではありません。Web アプリケーションで XSS の脆弱性から保護するために HTML サニタイザー (たとえば OWASP HTML サニタイザー) を使用することは賢明ですが、不適切な実施はセキュリティ上のエラーを引き起こす可能性があります。
例 1: 次の Java コードはユーザー制御入力変数 elements を HTML サニタイザー ポリシーの構築に使用します。

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

....

悪意あるユーザーは elements に <script> のような危険な要素を入力して HTML サニタイザー ポリシーがそのような危険な要素を受け入れるようにする可能性があります。

SSL 標準では、SSL 検証チェックをクライアント側で行う方法についてのガイドラインが用意されています。ただし、ガイドラインは標準の一部ではありません。つまり、検証ロジックの実装はアプリケーション開発者に委ねられています。

調査によれば、SSL 標準仕様の複雑さとオープンな性質によって、欠陥のないカスタム SSL 実装を行うことを難しくしている陥穽がいくつか存在します。カスタム SSL 実装を使用する Android アプリケーションの大部分は、安全な通信チャネルを提供するのには不十分であり、アプリケーションは中間者 (Man-in-the-Middle) 攻撃に対して脆弱なままになります。

InetAddress を関数パラメーターとする createSocket() 呼び出しでは、ホスト名検証は行われません。

同様に、getInsecure() 呼び出しは、すべての SSL チェックを無効にしたSSL ソケットファクトリを返します。

これら両方により、アプリケーションは中間者 (Man-in-the-Middle) 攻撃を受けやすくなります。

たとえば、https://safesecureserver.banking.com に接続しようとするアプリケーションは、https://hackedserver.banking.com に発行された証明書を容易に受け入れます。これによりアプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、機密性の高いユーザー情報をリークさせる可能性があります。

アプリケーションがコールしているメソッドは、サーバーのエンドエンティティ証明書とシステムで信頼されている証明機関 (CA) 証明書の間の有効な信頼パスに含まれない証明書を削除せずに、サーバーから返された全証明書のリストを返します。

攻撃者が侵害された CA の非公開鍵にアクセスできる場合、SSL/TLS 接続を傍受してサーバーから提示された証明書を改変できます。この場合、攻撃者は、サーバーのエンドエンティティ証明書から侵害されたルート CA までの有効な信頼パスを作成し、サーバーから提示された元の証明書の残りを追加できます。

クライアントが証明書のピン留めを使用している場合、クライアントは「ピン留め」された証明書がサーバーから提示された証明書の中に含まれていることを検証します。クライアントが使用するメソッドが、有効なパスに含まれていない証明書を削除せずにサーバーから提示されたすべての証明書を返す場合、攻撃者が有効な侵害された非公開鍵を使用して、侵害された CA と、Web サーバーから提示される元の証明書への有効な信頼パスを提示できるようになる可能性があります。その場合、攻撃者は証明書のピン留め検証を回避できます。

公開鍵基盤 (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) レスポンスには、セッション cookie や 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();

バケットまたはオブジェクトの Access Control Policy (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();

バケットまたはオブジェクトの Access Control Policy (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 ストリッピング攻撃は中間者攻撃の一種であり、攻撃者はすべての HTTP トラフィックを監視し、HTTPS を参照する位置ヘッダーおよびリンクを見つけて HTTP のそれに置換します。攻撃者は HTTPS リクエストをサーバーに戻せるように、すべての HTTP 代用の一覧を作成します。見つけ出された HTTP 接続はすべて HTTPS 経由でサーバーにプロキシされます。攻撃対象者と攻撃者の間のトラフィックはすべて HTTP で送信され、ユーザー名、パスワード、その他の個人情報が開示されますが、サーバーは要求通り HTTPS トラフィックを攻撃者から受け取るため、何も問題ないように見えます。

HTTP Strict Transport Security (HSTS) は、ヘッダー内に指定されている期間中は SSL/TLS で HSTS ヘッダーを返すサイトへ常に接続するようブラウザーに指示するセキュリティ ヘッダーです。ユーザーがブラウザーの URL バーに「http://」と入力しても、HTTP によるサーバーへの接続は自動的に HTTPS 接続に置換されます。

例 1: 次のコードでは、Spring Security で保護されるアプリケーションで HSTS ヘッダーの下位ドメインを無効化するよう設定します。

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