Insecure SSL: Server Identity Verification Disabled

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。その他のインスタンスでは、故意かどうかにかかわらず、これを明示的に無効化できます。

例 1: このアプリケーションは常に証明書チェーンが正しいことを検証するため、すべての証明書を信頼します。

...
private bool CertificateCheck(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
  ...
  return true; 
}
...
  HttpWebRequest webRequest = (HttpWebRequest) WebRequest.Create("https://www.myTrustedSite.com");
  webRequest.ServerCertificateValidationCallback = CertificateCheck;
  WebResponse response = webRequest.GetResponse();
...

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

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは証明書の検証を明示的に無効にします。

...
  SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_callback);
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続時、サーバー ID 検証は無効になっています。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは、サーバー証明書を明示的に検証しません。

    ...
    config := &tls.Config{
        // Set InsecureSkipVerify to skip the default validation
        InsecureSkipVerify: true,
        ...
    }

    conn, err := tls.Dial("tcp", "example.com:443", conf)
    ..
    

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

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続を使用するライブラリによっては、サーバー証明書はデフォルトで検証されません。これはすべての証明書を信頼することと同じです。

例 1: このサーバーは、クライアント接続を不正に検証しようとします。

...
var options = {
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  requestCert: true,
  ...
}
https.createServer(options);
...

この https.Server オブジェクトが作成されるとき、設定 requestCert は true に指定されますが rejectUnauthorized は指定されずにデフォルトの false になります。つまり、サーバーは SSL を介してクライアントを検証するように作成されましたが、証明書が提供されている CA のリストで承認されていない場合にも接続が受け入れられます。

例 2: 次のアプリケーションは、SSL を介してサーバーに接続しようとします。

var tls = require('tls');
...
tls.connect({
  host: 'https://www.hackersite.com',
  port: '443',
  ...
  rejectUnauthorized: false,
  ...
});

この例では、rejectUnauthorized が False に設定されたので、権限のない証明書が受け入れられ、未確認のサーバーとのセキュアな接続が引き続き作成されることを意味します。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続が行われる一部のライブラリでは、既定でサーバー証明書を検証しません (またはそのように明示的に設定されています)。これはすべての証明書を信頼することと同じです。

例 1: このコードは、HTTPS 証明書を受け取るように NSURLConnectionDelegate を設定します。

implementation NSURLRequest (IgnoreSSL)

+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
  return YES;
}

@end

Example 1 の NSURLRequest の実装を使用して SSL によりセキュリティ保護されるサーバーに接続するとき、リクエストされたサーバーの証明書が自己署名されている (これにより検証されない) 場合は警告やエラーが発生しません。これにより、アプリケーションはユーザーの機密情報を不正な SSL 接続によって漏洩する可能性があります。

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは、既定ではサーバー証明書を検証しません。

...
import ssl
ssl_sock = ssl.wrap_socket(s)
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続を使用する一部のライブラリでは、サーバー証明書の検証を無効にすることができます。これはすべての証明書を信頼することと同じです。

例 1: このアプリケーションは証明書の検証を明示的に無効にします。

require 'openssl'
...
ctx = OpenSSL::SSL::SSLContext.new
ctx.verify_mode=OpenSSL::SSL::VERIFY_NONE
...

有効なホストへの接続を試みると、このアプリケーションは "hackedserver.com" に対して発行された証明書を即座に受け入れます。アプリケーションは、ハッキングされているサーバーへの不正な SSL 接続によって、ユーザー機密情報をリークさせる可能性があります。

SSL 接続時、サーバー アイデンティティ検証は無効になっています。

SSL 接続が行われる一部のライブラリでは、既定でサーバー証明書を検証しません (またはそのように明示的に設定されています)。これはすべての証明書を信頼することと同じです。

例 1: このコードは、HTTPS 証明書を受け取るように NSURLConnectionDelegate を設定します。

class Delegate: NSObject, NSURLConnectionDelegate {
    
    ...

    func connection(connection: NSURLConnection, canAuthenticateAgainstProtectionSpace protectionSpace: NSURLProtectionSpace?) -> Bool {
        return protectionSpace?.authenticationMethod == NSURLAuthenticationMethodServerTrust
    }

    func connection(connection: NSURLConnection, willSendRequestForAuthenticationChallenge challenge: NSURLAuthenticationChallenge) {
        challenge.sender?.useCredential(NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!), forAuthenticationChallenge: challenge)
        challenge.sender?.continueWithoutCredentialForAuthenticationChallenge(challenge)
    }
}

Example 1 の NSURLConnectionDelegate の実装を使用して SSL によりセキュリティ保護されるサーバーに接続するとき、リクエストされたサーバーの証明書が自己署名されている (これにより検証されない) 場合は警告やエラーが発生しません。これにより、アプリケーションはユーザーの機密情報を不正な SSL 接続によって漏洩する可能性があります。

例 2:NSURLSession クラスでは、SSL/TLS チェーンの検証はアプリケーションの認証委任メソッドによって処理されます。ただし、認証情報を提供してサーバーに対してユーザー (またはアプリケーション) を認証するのではなく、SSL/TLS ハンドシェイク時にサーバーが提供する認証情報をアプリケーションが確認して、URL ローディング システムにそれらの認証情報を許可すべきか拒否すべきかを通知します。次のコードは、サーバー検証を事実上回避し、セッションの認証情報として受け取ったチャレンジの proposedCredential を渡すだけの NSURLSessionDelgate を示しています。

class MySessionDelegate : NSObject, NSURLSessionDelegate {
    ...
    func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
        ...
        completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, challenge.proposedCredential)
        ...
    }
    ...
}