URL에 GET 변수가 포함 된 서버 요청을 보내는 모바일 앱 (iOS)이 있습니다.SSL을 통해 GET 변수 전달 = 보안?
이제 모든 요청은 SSL 보안이 적용됩니다. 즉, 모든 요청에 대해서만 HTTPS를 사용합니다.
이제는 브라우저에 없으므로 기록이없고 아무도 실제로 URL을 볼 수 없으며 서버의 서버 로그에 대한 모든 액세스를 비활성화합니다 (이 두 가지 사실은 다른 유사한 질문과 다릅니다) .
그렇다면 GET 변수가 전달되고 'Man in the Middle'공격으로 해킹 당할 수 없다고 가정하는 것이 안전할까요?
엄밀히 말하면 "중간에 사람"공격이 여전히 실행될 수 있습니다. 가장 큰 문제는 그것이 최종 사용자에게 투명 할 것인지 아닌지 여부입니다.
중간에있는 사람이 여전히 초기 SSL 핸드 셰이크를 가로 채고 자체 SSL 인증서를 반환 할 수 있습니다. 인증서는 올바른 도메인 이름 등일 수 있지만 식별 기능은 신뢰할 수있는 출처, 즉 CA (Certificate Authority)에서 서명하지 않는 것이 좋습니다. 애플리케이션이이를 인식하고 통신을 중지하면 문제가되지 않습니다. 반면에 응용 프로그램이 신뢰할 수있는 CA의 진위 여부를 확인하지 않으면 해커와 세션을 협상하여 트래픽을 확인하고 검사 한 다음 실제 서버로 보내 처리 할 수 있습니다. 실제 서버의 모든 응답은 해커에게도 표시됩니다.
해커가 신뢰할 수있는 CA의 키로 사기성 인증서에 서명 할 수있는 경우 해커가 멈추지 않습니다. 드문 경우이지만 CA가 손상 될 수 있습니다.
웹 브라우저의 경우 이러한 공격은 사용자에게 "멈추다, 뭔가 생기다"라는 메시지를 표시합니다.이 메시지는 이후 버전의 브라우저에서 훨씬 더 명확하게 나타납니다. 그래도 최종 사용자는 신뢰할 수없는 인증서를 받아 들여 사실상 해커의 도청을 허용 할 수 있습니다. 애플리케이션 (또는 iOS 자체)에서 허용하는 경우 사용자를 가능한 많이 교육하는 것 외에도 할 수있는 일은 거의 없습니다.
요약하면 응용 프로그램이 대상 서버와 SSL 채널을 협상하고 반환 된 인증서가 신뢰할 수있는 기관 (사용자에게 묻지 않음)에 의해 서명되었는지 확인하는 경우 확인해야합니다. GET/POST 동사와 그 이후의 헤더를 포함한 모든 HTTP 트래픽은 암호화됩니다. 경고의 단어가 두 가지 더 있습니다.
귀하의 요청이 프록시를 통과하고 메시지를 기록 할 수도 있음을 잊지 마십시오.
SSL은 여행 요청에 대한 암호화 된 채널을 제공하지만 요청이 목적지에 도달하면 일반 텍스트 변수가 액세스 로그에 기록됩니다.
보내시는 정보가 어떤 식 으로든 중요하다면 POST를 사용해야합니다. 이렇게하면 웹 서버에서 변수가 기록되지 않습니다.또한 보안 문제가 다른 도메인 (동일한 출처 정책)에서 호출되는 것을 막을 것입니다.
흥미로운 대답이지만 2014 년 11 월로 RC4를 더 이상 사용하지 않아야합니다. – Corni