Pergunta

O meu último par de projectos têm sites envolvidos que vendem um produto / serviço e exigem um processo de 'check-out' em que os usuários colocar em suas informações de cartão de crédito e tal. Obviamente nós temos certificados SSL para a segurança de que além de dar paz de espírito para os clientes. Estou, no entanto, um pouco à nora quanto às sutilezas do mesmo, e mais importante a respeito de que partes do site deve 'utilização' do certificado.

Por exemplo, eu fui para sites onde no momento em que atingiram a homepage você é colocado em https - locais principalmente bancárias - e, em seguida, existem sites onde você só são colocados em https quando você está finalmente conferir. É um exagero para fazer toda a execução site através de https se não lidar com algo no nível da banca? Devo só fazer o checkout página https? Qual é o impacto na performance em ir tudo para fora?

Foi útil?

Solução

Eu, pessoalmente, ir com "SSL de ir para ai".

Se o usuário nunca entra um número de cartão de crédito, com certeza, não SSL.

Mas há um vazamento de segurança possível inerente da repetição cookie.

  1. local de visitas de usuários e é atribuído um cookie.
  2. usuário navega local e adiciona dados ao carrinho (usando cookie)
  3. usuário passa a página de pagamento usando cookie.

Aqui há um problema, especialmente se você tem que pega pagamento negociação si mesmo.

Você tem que informações de transmissão do domínio não seguro para o domínio seguro, e vice-versa, sem garantias de proteção.

Se você fizer algo estúpido como compartilhar o mesmo cookie com inseguro como você faz com seguro, você pode encontrar alguns navegadores (com razão) será apenas Queda o cookie completamente (Safari) em prol da segurança , porque se alguém cheira esse cookie em campo aberto, eles podem forjar-lo e usá-lo no modo seguro para, degradando a sua segurança SSL maravilhosa a 0, e se os detalhes do cartão nunca se ainda que temporariamente armazenado na sessão, você tem uma perigosa vazar esperando para acontecer.

Se você não pode estar certo de que o seu software não é propenso a estas deficiências, gostaria de sugerir SSL desde o início, assim que seu cookie inicial é transmitido no seguro.

Outras dicas

Se o site é para uso público, você provavelmente deve colocar as partes públicas em HTTP. Isso torna as coisas mais fáceis e mais eficiente para aranhas e usuários casuais. HTTP solicitações são muito mais rápidas para iniciar a HTTPS e isso é muito óbvio, especialmente em sites com muitas imagens.

Os navegadores também, por vezes, ter uma política de cache diferente para HTTPS de HTTP.

Mas tudo bem para colocá-los em HTTPS, assim que inicia sessão, ou um pouco antes. No ponto em que o site torna-se personalizado e não-anônimo, pode ser HTTPS a partir daí.

É uma idéia melhor para usar HTTPS para o log na página em si, bem como quaisquer outras formas, como se dá o uso do cadeado antes de entrarem no info, que os faz sentir melhor.

Eu sempre fiz isso em todo o site.

também eu usar HTTPS todo o caminho. Isto não tem um impacto grande desempenho (desde cache do navegador a chave simétrica negociado após a primeira conexão) e protege contra sniffing.

Sniffing foi uma vez em seu caminho para fora por causa de redes totalmente comutada com fio, onde você teria que trabalhar duro extra para capturar o tráfego de qualquer outra pessoa (em oposição a redes usando hubs), mas é no seu caminho de volta, porque de redes sem fio, que criam um meio de transmissão mais uma vez uma sessão de make seqüestro fácil, a menos que o tráfego é criptografado.

Eu acho que uma boa regra de ouro está forçando qualquer lugar SSL onde a informação sensível vai possivelmente ser transmitido. Por exemplo: Eu sou um membro da Wescom Credit Union. Há uma seção na primeira página que me permite fazer logon em minha conta bancária online. Portanto, as Forças página raiz SSL.

Pense nisso desta maneira: vai sensível, informação privada ser transmitida? Se sim, ativar o SSL. Caso contrário, você deve ser fino.

Em nossa organização, temos três classificações de aplicações -

  • Baixo Impacto nos Negócios -. Não PII, armazenamento de texto claro, transmissão de texto simples, sem restrições de acesso
  • Medium Business Impact - não transacional PII por exemplo endereço de e-mail. armazenamento de texto claro, SSL de datacenter para o cliente, texto claro no centro de dados, acesso de armazenamento limitado.
  • High Business Impact - transacional de dados exemplo SSN, Cartão de Crédito SSL etc. dentro e fora do datacenter. Criptografado e Auditadas armazenamento. aplicações auditadas.

Nós usamos estes critérios para determinar o particionamento de dados, e que aspectos do site exigem SSL. Cálculo de SSL ou é feito no servidor ou através de aceleradores tais como o NetScaler. Como nível de PII aumenta também a complexidade da modelagem de auditoria e ameaça.

Como você pode imaginar que preferem fazer aplicações LBI.

Kent acertou em cheio. Eu só quero fazer um comentário rápido - Amazon faz isso bem, eu acho. http durante a maior parte do site, mas quando chega a hora de check-out, você tem que logar novamente (oneclick é um pouco diferente), há provavelmente um cookie diferente nesse ponto. Acho que outros comentários estão dizendo a mesma coisa, mas eu só queria dar um exemplo concreto.

Geralmente quando você está transmitindo dados confidenciais ou pessoais você deve estar usando SSL - por exemplo, adicionar um item a uma cesta que provavelmente não precisa SSL, entrando com seu nome de usuário / senha ou digitar seus dados CC devem ser criptografados.

Há uma grande desvantagem para um site https cheia e não é a velocidade (que é ok).

Vai ser muito difícil de executar Youtube, "como" caixas etc, sem a advertência não seguro.

Estamos executando uma das forças completos website e loja garantidos por dois anos agora e esta é a maior desvantagem. Conseguimos obter Youtube ao trabalho agora, mas a "Adicionar" ainda é um grande desafio. E se eles mudam nada para o protocolo, então pode ser que todos os nossos filmes do YouTube estão em branco ...

Eu sempre apenas redirecionar meus sites para SSL quando se requer que o usuário insira informações confidenciais. Com um carrinho de compras, logo que eles têm que preencher uma página com suas informações pessoais ou detalhes do cartão de crédito I redirecioná-los para uma página de SSL. Para o resto do site é provavelmente não é necessário - se eles estão apenas a visualização de informações / produtos em seu site de comércio

.

SSL é bastante computacionalmente intensivas e não deve ser usado para transmitir grandes quantidades de dados, se possível. Therfore seria melhor para habilitá-lo na fase de checkout onde o usuário seria a transmissão de informações confidenciais.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top