TCP 소켓 연결을 통한 모든 통신은 현재 인증되지 않고 암호화되지 않아 잠재적인 손상에 노출되어 있습니다. 이러한 위험은 장치가 안전하지 않은 공공 무선 네트워크에 연결되는 경우가 많은 모바일 환경에서 특히 심각합니다. 이러한 취약점을 완화하려면 SSL/TLS와 같은 보안 프로토콜을 구현하여 데이터 기밀성과 무결성을 보장하십시오.

예제 1: 다음 코드 조각은 SSL/TLS와 같은 보안 프로토콜을 사용하는 대신 인증되지 않고 암호화되지 않은 TCP 소켓 연결을 통한 데이터 전송을 보여줍니다.

...
FINAL(client) = cl_apc_tcp_client_manager=>create(
      i_host   = ip_adress
      i_port  = port
      i_frame = VALUE apc_tcp_frame(
        frame_type =
          if_apc_tcp_frame_types=>co_frame_type_terminator
        terminator =
          terminator )
      i_event_handler = event_handler ).
...

client 개체와 원격 서버 간 통신은 암호화되지 않고 인증되지 않은 채널을 통해 전송되므로 손상될 위험이 있습니다.

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 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 MiTM(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 프로토콜을 사용하여 웹 서버를 설정합니다.

	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)

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

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

    ...
    using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions { 
        Credentials = ChannelCredentials.Insecure
    });
    ...
    

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

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

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

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

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

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

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

HTTP Strict Transport Security(HSTS)는 브라우저가 항상 HSTS 헤더를 헤더 자체에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 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 = @"응용 프로그램에서 매우 쉽게 전자 메일을 전송할 수 있습니다.";
  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 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 메시지 MiTM(Man-in-the-Middle) 공격에 취약할 수 있으며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 이 Node.js 조각은 보안 연결이 있는 서버를 생성하려고 합니다.

...
var options = {
  port: 443,
  path: '/',
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  ...
}
https.createServer(options);
...

Node.js는 secureProtocol의 기본값을 SSLv23_method로 설정하므로 서버는 secureProtocol이 특별히 오버라이드되지 않으면 본질적으로 안전하지 않습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결합니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호의 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

안전하지 않은 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 다음 예제에서는 기본 SSL 버전(SSL v3.0)을 사용합니다.

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
[configuration setTLSMinimumSupportedProtocol = kSSLProtocol3];
NSURLSession *mySession = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:operationQueue];

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 다음 예제에서는 SSL v3.0을 사용하도록 세션을 구성합니다.

let configuration : NSURLSessionConfiguration = NSURLSessionConfiguration.defaultSessionConfiguration()
let mySession = NSURLSession(configuration: configuration, delegate: self, delegateQueue: operationQueue)