문제

나의 최근 프로젝트에는 제품/서비스를 판매하고 사용자가 신용 카드 정보 등을 입력하는 '결제' 프로세스가 필요한 웹 사이트가 포함되었습니다.분명히 우리는 보안과 고객에게 마음의 평화를 제공하기 위해 SSL 인증서를 받았습니다.그러나 나는 그것의 미묘함과 가장 중요한 것은 웹사이트의 어느 부분이 인증서를 '사용'해야 하는지에 대해 조금 알지 못합니다.

예를 들어, 홈페이지에 접속하자마자 https로 입력되는 웹사이트(주로 은행 사이트)를 가본 적이 있고, 마지막으로 체크아웃할 때만 https로 입력되는 웹사이트도 있습니다.은행 수준의 작업을 처리하지 않는 경우 전체 웹사이트를 https를 통해 실행하도록 하는 것은 과잉입니까?결제 페이지를 https로만 만들어야 하나요?전력을 다할 때 성능이 저하되는 것은 무엇입니까?

도움이 되었습니까?

해결책

나는 개인적으로 "SSL from go to woe"를 사용합니다.

사용자가 신용 카드 번호를 입력하지 않으면 SSL이 없습니다.

그러나 쿠키 재생에는 본질적으로 보안 누출이 있을 수 있습니다.

  1. 사용자가 사이트를 방문하고 쿠키가 할당됩니다.
  2. 사용자가 사이트를 탐색하고 장바구니에 데이터를 추가합니다(쿠키 사용).
  3. 이용자는 쿠키를 이용하여 결제페이지로 이동합니다.

여기에 문제가 있습니다. 특히 지불 협상을 직접 처리해야 하는 경우 더욱 그렇습니다.

보호가 보장되지 않는 상태에서 비보안 도메인에서 보안 도메인으로 정보를 전송하고 다시 그 반대로 전송해야 합니다.

보안과 동일한 쿠키를 비보안과 공유하는 것과 같은 어리석은 일을 한다면 일부 브라우저(올바로)가 떨어지다 보안을 위해 쿠키를 완전히(Safari) 사용합니다. 누군가가 공개적으로 해당 쿠키를 스니핑하면 이를 위조하여 보안 모드에서 사용할 수 있으므로 멋진 SSL 보안을 0으로 떨어뜨리고 카드 세부 정보를 얻을 수 있기 때문입니다. 세션에 일시적으로 저장되어 있어도 위험한 누출이 발생하기를 기다리고 있습니다.

귀하의 소프트웨어가 이러한 약점에 취약하지 않다는 것을 확신할 수 없다면 처음부터 SSL을 제안하여 초기 쿠키가 안전하게 전송되도록 하십시오.

다른 팁

사이트가 공개적으로 사용되는 경우 공개 부분을 HTTP에 배치해야 할 것입니다.이는 스파이더와 일반 사용자의 작업을 더 쉽고 효율적으로 만듭니다.HTTP 요청은 HTTPS보다 훨씬 빠르게 시작되며 이는 특히 이미지가 많은 사이트에서 매우 분명합니다.

브라우저에는 HTTP와 HTTPS에 대한 캐시 정책이 다른 경우도 있습니다.

하지만 로그온하자마자 또는 바로 직전에 HTTPS에 넣어도 괜찮습니다.사이트가 개인화되고 익명이 아닌 시점부터 HTTPS가 될 수 있습니다.

로그인 페이지 자체와 다른 양식에 HTTPS를 사용하는 것이 더 좋은 아이디어입니다. 정보를 입력하기 전에 자물쇠를 사용할 수 있어 기분이 좋아지기 때문입니다.

나는 항상 전체 웹사이트에서 이 작업을 수행해 왔습니다.

나 역시 HTTPS를 계속 사용할 것이다.이는 성능에 큰 영향을 미치지 않으며(브라우저가 첫 번째 연결 후 협상된 대칭 키를 캐시하므로) 스니핑을 방지합니다.

스니핑은 (허브를 사용하는 네트워크와 달리) 다른 사람의 트래픽을 캡처하기 위해 더 많은 노력을 기울여야 하는 완전히 전환된 유선 네트워크로 인해 한때 사라졌지만, 무선 네트워크로 인해 다시 돌아오고 있습니다. 방송 매체는 트래픽이 암호화되지 않는 한 다시 한 번 세션 하이재킹을 쉽게 만듭니다.

경험상 중요한 정보가 전송될 수 있는 모든 곳에 SSL을 강제하는 것이 좋은 방법이라고 생각합니다.예를 들어:저는 Wescom Credit Union의 회원입니다.첫 페이지에는 내 온라인 은행 계좌에 로그인할 수 있는 섹션이 있습니다.따라서 루트 페이지는 SSL을 강제합니다.

이렇게 생각해보세요:민감한 개인정보가 전송되나요?그렇다면 SSL을 활성화하십시오.그렇지 않으면 괜찮을 것입니다.

우리 조직에는 세 가지 애플리케이션 분류가 있습니다.

  • 낮은 비즈니스 영향 - PII 없음, 일반 텍스트 저장, 일반 텍스트 전송, 액세스 제한 없음.
  • 중견기업에 미치는 영향 - 비거래 PII(예:이메일 주소.일반 텍스트 스토리지, 데이터 센터에서 클라이언트로의 SSL, 데이터 센터의 일반 텍스트, 제한된 스토리지 액세스.
  • 높은 비즈니스 영향 - 거래 데이터(예:SSN, 신용카드 등데이터 센터 내부 및 외부의 SSL.암호화 및 감사된 스토리지.감사된 애플리케이션.

우리는 이러한 기준을 사용하여 데이터 분할과 SSL이 필요한 사이트 측면을 결정합니다.SSL 계산은 서버에서 수행되거나 Netscaler와 같은 가속기를 통해 수행됩니다.PII 수준이 높아질수록 감사 및 위협 모델링도 복잡해집니다.

상상할 수 있듯이 우리는 LBI 신청을 선호합니다.

켄트가 성공했습니다.간단히 말씀드리고 싶은 것은 아마존이 이 일을 잘한다고 생각합니다.대부분의 사이트는 http이지만 결제할 때는 다시 로그인해야 합니다(oneclick은 약간 다릅니다). 그 시점에는 아마도 다른 쿠키가 있을 것입니다.다른 댓글들도 같은 말인 것 같은데, 구체적인 예를 들어보고 싶었습니다.

일반적으로 민감한 데이터나 개인 데이터를 전송할 때마다 SSL을 사용해야 합니다.장바구니에 항목을 추가하는 데에는 SSL이 필요하지 않을 수 있습니다. 사용자 이름/비밀번호로 로그인하거나 CC 세부정보를 입력하는 것은 암호화되어야 합니다.

완전체에는 한 가지 큰 단점이 있습니다. https 사이트이고 속도가 아닙니다(괜찮습니다).

안전하지 않은 경고 없이 YouTube, '좋아요' 상자 등을 실행하는 것은 매우 어렵습니다.

우리는 현재 2년 동안 완전한 보안을 갖춘 웹사이트와 쇼핑을 운영하고 있는데 이것이 가장 큰 단점입니다.이제 YouTube를 작동시킬 수 있게 되었지만 "이 항목 추가"는 여전히 큰 과제입니다.그리고 그들이 프로토콜을 변경하면 모든 YouTube 영화가 공백이 될 수도 있습니다...

나는 사용자가 민감한 정보를 입력해야 하는 경우에만 내 사이트를 SSL로 리디렉션합니다.장바구니를 사용하여 개인 정보나 신용 카드 정보로 페이지를 작성하자마자 SSL 페이지로 리디렉션합니다.사이트의 나머지 부분에서는 아마도 필요하지 않을 것입니다. 단지 귀하의 상업 사이트에서 정보/제품을 보는 것이라면 말이죠.

SSL은 계산 집약적이므로 가능하면 대량의 데이터를 전송하는 데 사용해서는 안 됩니다.따라서 사용자가 민감한 정보를 전송하는 결제 단계에서 활성화하는 것이 더 좋습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top