http를 https로 리디렉션하는 것이 좋지 않습니까?
이 페이지를 읽고 있는데 사이트가 SSL이고 사용자가 일반 http를 통해 액세스를 시도하면 응용 프로그램이 사용자를 https로 리디렉션해서는 안된다고 말합니다. 그를 막아야 만합니다. 누군가 이것의 유효성을 확인할 수 있습니까? 좋은 생각이 아닌 것 같고 사용자를 https로 전달하는 것이 진짜 위험이 무엇인지 궁금합니다. 그 뒤에 기술적 인 이유가없는 것 같습니다. 단지 사용자를 교육하는 좋은 방법 일뿐입니다.
도메인에 대한 HTTP 액세스를 비활성화하고 SSL에 리디렉션하거나 링크하지 마십시오. 사용자에게이 웹 사이트는 HTTP를 통해 액세스 할 수 없으며 SSL을 통해 액세스해야한다고 알리십시오.
이것은 MITM 및 피싱 공격에 대한 모범 사례입니다. 이렇게하면 사용자는 HTTP를 통해 애플리케이션에 액세스 할 수 없다는 사실을 알게되고 피싱 또는 MITM 공격을 접하게되면 무언가 잘못되었음을 알게됩니다.
MITM 공격 및 피싱 공격으로부터 애플리케이션을 보호하는 가장 좋은 방법 중 하나는 사용자를 교육하는 것입니다.
세션 ID 쿠키를 포함하는 HTTP 요청은 세션 하이재킹 공격을받습니다. HTTP를 허용하고 HTTPS로 리디렉션하는 경우 해당 쿠키가 보안으로 표시되는 것이 중요합니다.
HTTP를 완전히 차단해야하는 기술적 이유도 알 수 없으며 많은 사이트에서 HTTP를 HTTPS로 전달합니다. 이렇게 할 때 브라우저가 HTTPS 연결 만 사용하도록 선언하는 웹 보안 메커니즘 인 HSTS (HTTP Strict Transport Security)를 구현하는 것이 좋습니다.
HSTS는와 같은 응답 헤더를 지정하여 구현됩니다 Strict-Transport-Security: max-age=31536000. 사용자 에이전트를 준수하면 안전하지 않은 링크가 자동으로 보안 링크로 전환되어 중간자 공격의 위험이 줄어 듭니다. 또한 인증서가 안전하지 않을 위험이있는 경우 (예 : 루트 기관이 인식되지 않음) 오류 메시지가 표시되고 응답이 표시되지 않습니다.
HTTP에서 HTTPS로 이동하는 것은 실제로별로 좋은 생각이 아닙니다. 예를 들어 공격자는 ssl strip 과 같은 도구를 사용하여 중간자 (man-in-the-middle) 공격을 수행 할 수 있습니다. 이 문제를 해결하려면 HSTS 프로토콜을 사용해야합니다 . 모든 주요 브라우저 (최신 채택자인 Internet Explorer는 IE12부터 지원)에서 지원되며 많은 상위 사이트 (예 : Paypal, Google)에서 사용 중입니다.
HTTP에서 HTTPS로 리디렉션 할 때 기술적 위험 (내 답변 끝에있는 업데이트의 위험 제외)이 표시되지 않습니다. 예를 들어 gmail과 yahoo 메일이이를 수행합니다. HTTP 디버깅 도구 (예 : Fiddler)를 사용하여 확인할 수 있습니다. 여기서 서버에서 반환 한 302 리디렉션 응답을 명확하게 확인할 수 있습니다.
사용성 관점에서 블로킹은 나쁜 생각이라고 생각합니다. 사용자가 HTTP 또는 HTTPS를 지정하지 않고 브라우저에 주소를 입력하는 경우가 많습니다. 예를 들어, "mail.google.com"을 입력하여 Gmail에 액세스합니다. 기본값은 "http://mail.google.com"이고 자동으로 "https://mail.google.com"으로 리디렉션됩니다. 자동 리디렉션이 없으면 항상 전체 주소를 입력해야합니다.
나는 HTTPS가 MITM 공격에 대한 최선의 방법이라는 인용 된 기사에 동의하지만 이것이 피싱에 대한 모범 사례라는 데 동의하지 않습니다. 사용자 교육은 실제로 피싱 공격에 대한 핵심 요소이지만 (사용자는 올바른 도메인에서 사이트에 액세스하고 있는지 확인해야 함) HTTPS 로의 HTTP 리디렉션을 차단하여 교육을 수행하지 않습니다.
@Pedro 및 @Spolto 업데이트 가 맞습니다. 민감한 쿠키 (예 : 세션 또는 인증 쿠키)와 관련하여 특별한주의를 기울여야합니다. 이러한 쿠키는 HTTPS를 통해서만 전송되도록 실제로 안전하다고 표시되어야합니다. 나는 그것을 놓쳤다. 둘 다 +1하세요.
방금이 질문에 주목했지만 비슷한 질문에 대한 몇 가지 답변을 작성했습니다.
HTTP에서 HTTPS로 리디렉션하는 것이 반드시 유해하다고 생각하지는 않지만 신중하게 수행해야합니다. 중요한 것은 개발 단계에서 이러한 자동 리디렉션에 의존해서는 안된다는 것입니다. 브라우저에 주소를 직접 입력하는 사용자에게만 사용해야합니다.
또한 HTTPS를 사용하고 있는지 (그리고 인증서가 경고없이 확인되었는지) 확인하는 것은 전적으로 사용자의 책임입니다.
HTTP에서 HTTPS로 전환 할 때의 실제 위험은 세션 유지를 선택하면 전환 전에 수행 된 작업을 안정적으로 신뢰할 수 있다는 것입니다. 웹 사이트의 흐름과 프로세스는이를 고려해야합니다.
예를 들어, 사용자가 쇼핑 사이트를 탐색하고 HTTP를 사용하여 장바구니에 다양한 항목을 추가하고 HTTPS를 사용하여 결제 세부 정보를 얻으려는 경우 사용자가 HTTPS를 사용하여 장바구니의 내용을 확인하도록해야합니다.
또한 HTTP에서 HTTPS로 전환 할 때 사용자를 다시 인증하고 일반 HTTP 세션 식별자 (있는 경우)를 삭제해야 할 수 있습니다. 그렇지 않으면 공격자가 해당 쿠키를 사용하여 사이트의 해당 HTTPS 섹션으로 이동하여 합법적 인 사용자를 가장 할 수 있습니다.
기술적 관점에서 IMO는 HTTPS가 취하는 것 외에는 부작용이 없습니다.
UX / UI 관점에서 리디렉션 자체가 MITM 공격을 받기 때문에 처음에 HTTPS URL을 입력하는 사람들에게 시각적 표시를 제공하는 클릭 스루 또는 지연된 리디렉션을 사용하는 것이 좋습니다. 그러나 많은 HTTPS 웹 사이트는 사람들에게 HTTPS 페이지의 브라우저에서 잠금 아이콘을 찾도록 요청하는 시각적 개체를 제공하기 때문에 이렇게합니다.
이것은 완벽하게 수용 가능한 "부트 스트랩"방법입니다. 301은 HTTP에서 HTTPS로 리디렉션 한 다음 HTTPS 측에서 Strict-Transport-Security 헤더를 반환하여 브라우저를 HTTPS로 잠급니다.
브라우저가 HSTS를 지원하고 브라우저 캐시 또는 사전로드 목록에서 HSTS 토큰이 발견되지 않는 한 프로토콜 지정자없이 URL을 입력하면 웹 브라우저가 HTTP 프로토콜을 시도하므로 HTTP를 완전히 차단하는 것은 주요 사용성 문제입니다. .
참조 URL : https://stackoverflow.com/questions/4365294/is-redirecting-http-to-https-a-bad-idea
'development' 카테고리의 다른 글
| Rails 3 session_store domain : all이 실제로하는 일은 무엇입니까? (0) | 2020.12.25 |
|---|---|
| NFS로 inotify (0) | 2020.12.25 |
| Eclipse 또는 Android Studio XML 편집기에 줄 번호가 없습니다. (0) | 2020.12.13 |
| Ubuntu 16.04에서 php-curl을 설치하는 방법 (0) | 2020.12.13 |
| Facebook 키 해시가 저장된 키 해시와 일치하지 않습니다. (0) | 2020.12.13 |