File Permission Manipulation のエラーが発生するのは、次の条件のいずれかに一致した場合です。

1.攻撃者が、ファイル システム上でのアクセス許可を変更する操作で使用されるパスを指定する可能性がある場合。

2.攻撃者が、ファイル システム上での操作によって割り当てられるアクセス許可を指定する可能性がある場合。

例 1: 次のコードは、システム環境変数からの入力を使用して、ファイル権限を設定します。攻撃者がシステム環境変数を変更できる場合、プログラムを使用することによって、プログラムで操作されるファイルにアクセスする可能性があります。プログラムに Path Manipulation の脆弱性も存在している場合、攻撃者はこの脆弱性を利用してシステム上の任意のファイルにアクセスする可能性があります。

    permissions := strconv.Atoi(os.Getenv("filePermissions"));
    fMode := os.FileMode(permissions)
    os.chmod(filePath, fMode);
    ...

ファイル権限操作のエラーが発生するのは、次の条件のいずれかに一致した場合です。

1. 攻撃者が、アクセス許可を変更する操作で使用されたパスをファイル システムで指定できる場合。

2. 攻撃者が、操作によって割り当てられたアクセス許可をファイル システムで指定できる場合。

例: 次のコードの目的は、FTP 経由で Web ページをアップロードするユーザーに対して適切なファイル権限を設定することです。このコードでは、外部ユーザーに対してファイルを表示可能にするために、HTTP リクエストの入力を使用しています。

	$rName = $_GET['publicReport'];
	chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...

しかし、攻撃者が publicReport に悪意のある値 (../../localuser/public_html/.htpasswd など) を指定した場合、指定されたファイルは攻撃者から読み取り可能となります。

例 2: 次のコードでは、設定ファイルからの入力を使用してデフォルトの権限マスクを設定しています。攻撃者が設定ファイルを変更できる場合、プログラムを使用することによって、プログラムで操作されるファイルにアクセスすることが可能です。プログラムに Path Manipulation の脆弱性も存在している場合、攻撃者はこの脆弱性を利用してシステム上の任意のファイルにアクセスすることができます。

...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...

File Permission Manipulation のエラーが発生するのは、次の条件のいずれかに一致した場合です。

1. 攻撃者が、アクセス許可を変更する操作で使用されたパスをファイル システムで指定できる場合。

2. 攻撃者が、操作によって割り当てられたアクセス許可をファイル システムで指定できる場合。

例 1: 次のコードは、システム環境変数からの入力を使用して、ファイル権限を設定します。攻撃者がシステム環境変数を変更できる場合、プログラムを使用することによって、プログラムで操作されるファイルにアクセスすることが可能です。プログラムに Path Manipulation の脆弱性も存在している場合、攻撃者はこの脆弱性を利用してシステム上の任意のファイルにアクセスすることができます。

    permissions = os.getenv("filePermissions");
    os.chmod(filePath, permissions);
    ...

ファイル権限操作のエラーが発生するのは、次の条件のいずれかに一致した場合です。

1. 攻撃者が、アクセス許可を変更する操作で使用されたパスをファイル システムで指定できる場合。

2. 攻撃者が、操作によって割り当てられたアクセス許可をファイル システムで指定できる場合。

例: 次のコードの目的は、FTP 経由で Web ページをアップロードするユーザーに対して適切なファイル権限を設定することです。このコードでは、外部ユーザーに対してファイルを表示可能にするために、HTTP リクエストの入力を使用しています。

...
  rName = req['publicReport']
  File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...

しかし、攻撃者が publicReport に悪意のある値 (../../localuser/public_html/.htpasswd など) を指定した場合、指定されたファイルは攻撃者から読み取り可能となります。

例 2: 次のコードでは、設定ファイルからの入力を使用してデフォルトの権限マスクを設定しています。攻撃者が設定ファイルを変更できる場合、プログラムを使用することによって、プログラムで操作されるファイルにアクセスすることが可能です。プログラムに Path Manipulation の脆弱性も存在している場合、攻撃者はこの脆弱性を利用してシステム上の任意のファイルにアクセスすることができます。

...
mask = config_params['perms']
File.chmod(filename, mask)
...

HPP (HTTP Parameter Pollution) 攻撃は、エンコードしたクエリ文字列区切り記号を既存のパラメーターに挿入することで構成されます。Web アプリケーションがユーザー入力の不要部分を適切に削除しない場合、悪意のあるユーザーがアプリケーションのロジックを悪用して、クライアント側またはサーバー側の攻撃を行う可能性があります。Web アプリケーションに追加のパラメーターを発行し、これらのパラメーターが既存のパラメーターと同じ名前を持っている場合、Web アプリケーションは以下のいずれかで反応します。

最初のパラメーターのデータのみ取得する
最後のパラメーターのデータのみ取得する
すべてのパラメーターからデータを取得し、それらを連結する


例：
- ASP.NET/IIS は、出現するすべてのパラメーターを使用します
- Apache Tomcat は、最初に出現したもののみを使用し、それ以外は無視します
- mod_perl/Apache は、値を値の配列に変換します

例 1: アプリケーション サーバーとアプリケーション自体のロジックに応じて、以下のリクエストが認証システムを混乱させ、攻撃者に他のユーザーの偽装を許す可能性があります。
http://www.server.com/login.aspx?name=alice&name=hacker

例 2: 次のコードは HTTP リクエストからの入力を使用して 2 つのハイパーリンクをレンダリングしています。

    ...
    String lang = Request.Form["lang"];
    WebClient client = new WebClient();
    client.BaseAddress = url;
    NameValueCollection myQueryStringCollection = new NameValueCollection();
    myQueryStringCollection.Add("q", lang);
    client.QueryString = myQueryStringCollection;
    Stream data = client.OpenRead(url);
    ...

URL: http://www.host.com/election.aspx?poll_id=4567
リンク 1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">英語<a>
リンク 2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">スペイン語<a>

プログラマは攻撃者が en&poll_id=1 のような lang を指定できる可能性を考慮しておらず、攻撃者が思いのままに poll_id を変更できます。

HPP (HTTP Parameter Pollution) 攻撃は、エンコードしたクエリ文字列区切り記号を既存のパラメーターに挿入することで構成されます。Web アプリケーションがユーザー入力の不要部分を適切に削除しない場合、悪意のあるユーザーがアプリケーションのロジックを悪用して、クライアント側またはサーバー側の攻撃を行う可能性があります。Web アプリケーションに追加のパラメーターを発行し、これらのパラメーターが既存のパラメーターと同じ名前を持っている場合、Web アプリケーションは以下のいずれかで反応します。

最初のパラメーターのデータのみ取得する
最後のパラメーターのデータのみ取得する
すべてのパラメーターからデータを取得し、それらを連結する


例：
- ASP.NET/IIS は、出現するすべてのパラメーターを使用します
- Apache Tomcat は、最初に出現したもののみを使用し、それ以外は無視します
- mod_perl/Apache は、値を値の配列に変換します

例 1: アプリケーションサーバーとアプリケーション自体のロジックに応じて、以下のリクエストが認証システムを混乱させ、攻撃者に他のユーザーの偽装を許す可能性があります。
http://www.server.com/login.php?name=alice&name=hacker

例 2: 次のコードは HTTP リクエストからの入力を使用して 2 つのハイパーリンクをレンダリングしています。

    <%
        ...
        $id = $_GET["id"];
        header("Location: http://www.host.com/election.php?poll_id=" . $id);
        ...
    %>

URL: http://www.host.com/election.php?poll_id=4567
リンク 1: <a href="vote.php?poll_id=4567&candidate=white">Mr. White に投票<a>
リンク 2: <a href="vote.php?poll_id=4567&candidate=green">Mrs. Green に投票<a>

プログラマは、攻撃者が「4567&candidate=green」のような poll_id を指定し、結果としてのページに以下の挿入リンクを含めるようにする可能性を考慮していなかったため、最初のパラメーターを採用するように細工されたアプリケーション サーバーでは、常に Mrs. Green が票を獲得することになりました。
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Mr. White に投票<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Mrs. Green に投票<a>

HPP (HTTP Parameter Pollution) 攻撃は、エンコードしたクエリ文字列区切り記号を既存のパラメーターに挿入することで構成されます。Web アプリケーションがユーザー入力の不要部分を適切に削除しない場合、悪意のあるユーザーがアプリケーションのロジックを悪用して、クライアント側またはサーバー側の攻撃を行う可能性があります。Web アプリケーションに追加のパラメーターを発行し、これらのパラメーターが既存のパラメーターと同じ名前を持っている場合、Web アプリケーションは以下のいずれかで反応します。

最初のパラメーターのデータのみ取得する。
最後のパラメーターのデータのみ取得する。
すべてのパラメーターからデータを取得し、それらを連結する。


例：
- ASP.NET/IIS は、出現するすべてのパラメーターを使用します
- Apache Tomcat は、最初に出現したもののみを使用し、それ以外は無視します
- mod_perl/Apache は、値を値の配列に変換します

例 1: アプリケーションサーバーとアプリケーション自体のロジックに応じて、以下のリクエストが認証システムを混乱させ、攻撃者に他のユーザーの偽装を許す可能性があります。
http://www.server.com/login.php?name=alice&name=hacker

上記のように、攻撃者はすでに name=alice を指定していますが、さらに name=alice& を追加しています。これが最初に出現するサーバーで使用されると、alice になりすましてそのアカウントに関する情報をさらに取得します。

キーボード拡張では、ユーザーが入力したすべてのキーボード操作を読み取ることができます。サードパーティのキーボードは通常、テキスト入力を容易にするため、または絵文字を追加するために使用され、ユーザーが入力した内容または処理のためにリモート サーバーに送信した内容を記録できます。キーロガーとして使用するために悪意のあるキーボードを配布し、ユーザーが入力したすべてのキーを読み取って、認証情報やクレジット カード番号などの機密データを盗むこともできます。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。このような場合は、暗号化された (安全な) プロトコルを使用する必要があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが送信されます。

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

受信する HttpResponse オブジェクトである res は、暗号化も認証もされていないチャネルを介して送信されるため、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、デバイスが WiFi 接続を経由して安全ではない公共のワイヤレス ネットワークに接続されることの多い場合、中間者 (Man-in-the-Middle) 攻撃にさらされる可能性があります。

例 1: 次のコードでは、(HTTPS プロトコルではなく) 安全でない HTTP プロトコルを使用しています。

    var account = new CloudStorageAccount(storageCredentials, false);

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

入力レスポンス response は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用して Web サーバーがセットアップされます。

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

入力 http.IncomingMessage オブジェクトの res は、暗号化されていない未認証のチャネルを介して配信されるので危険にさらされています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、ソケットの暗号化を無効にします。

...
stream_socket_enable_crypto($fp, false);
...

安全でない、暗号化されていない、または平文のプロトコルで送信されるすべての通信は、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、悪用される対象となります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

入力ストリーム in は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

   val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
   val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))

入力レスポンス responseFutureは、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

アプリケーションは、暗号化されていないチャネルを介してデータベース サーバーと通信するため、会社とアプリケーション ユーザーに重大なセキュリティ リスクをもたらす可能性があります。この場合、攻撃者はユーザーが入力したデータを変更したり、データベース サーバーに対して任意の SQL コマンドを実行したりする可能性があります。

例 1: 次のコードにより、アプリケーションは、暗号化されていないチャネルを介してデータベース サーバーと通信します。

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

未指定の Google Remote Procedure Call (gRPC) チャネル資格情報設定を使用すると、セキュリティ設定が、安全でないデフォルト値である None に設定されます。安全でないチャネル資格情報設定で送信されたデータは信頼できません。

例 1: 次のコードは、デフォルトのすべてのパラメーターを使用して作成された gRPC チャネル資格情報オブジェクトを示しています。これにより、すべてのチャネル資格情報のセキュリティ設定は、安全でないデフォルト値に設定されます。このインスタンスでは、root_certificates パラメーターの値が None に設定され、private_key パラメーターの値が None に設定され、certificate_chain パラメーターの値が None に設定されます。

...
channel_creds = grpc.ssl_channel_credentials()
...

未指定の Google Remote Procedure Call (gRPC) サーバー資格情報設定を使用すると、セキュリティ設定が、安全でないデフォルト値である None または False に設定されます。安全でないサーバー資格情報設定を使用したサーバーとの間で送受信されるデータは信頼できません。

例 1: 次のコードは、デフォルトのパラメーターを使用して作成された gRPC サーバー資格情報オブジェクトを示しています。これにより、クライアント認証が無効になります。

...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...

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

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

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

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

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

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

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

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

暗号化されずにネットワークで送信される機密データは、ネットワーク トラフィックを傍受できる攻撃者によって読み取られたり、改変されたりする可能性があります。

例 1: 次の SmtpClient は SMTP サーバーと通信するために SSL/TLS を使用しておらず、設定が正しくありません。

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
  message.Body = @"You can send an email message from an application very easily.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

暗号化されずにネットワークで送信される機密データは、ネットワーク トラフィックを傍受できる攻撃者によって読み取られたり、改変されたりする可能性があります。

例 1: 次の SMTP クライアントは、SMTP サーバーと通信するために SSL/TLS を使用しておらず、設定が正しくありません。

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱である可能性があり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。