Escrito por: Prakash Sharma

Com o aumento das ameaças à segurança cibernética, tornou-se cada vez mais necessário atualizar os padrões de segurança de suas aplicações para a web. Você precisa se certificar de que as contas de seus usuários estejam seguras.

Hoje em dia, muitas aplicações da web on-line estão pedindo aos usuários para adicionar uma camada extra de segurança à sua conta. Elas fazem isso habilitando a autenticação de 2 fatores. Existem vários métodos de implementação da autenticação de 2 fatores – a autenticação TOTP (o algoritmo de senha única dependente do tempo – do inglês, Time-based One Time Password) é um deles.

Este artigo explica o que é, como e por que usar esse algoritmo. Antes de entender isso, no entanto, vamos dar uma breve olhada no que significa autenticação de dois fatores.

O que é a autenticação de dois fatores?

A autenticação de 2 fatores (ou autenticação de multifator) é apenas uma camada extra de segurança para a conta de um usuário. Isso significa que, depois de habilitar a autenticação de dois fatores, o usuário precisa passar por mais uma etapa para fazer login com êxito. Por exemplo, as etapas usuais para se fazer login em uma conta são:

Ao habilitar a autenticação de dois fatores, os passos agora passam a ser:

Portanto, isso adiciona mais uma etapa ao processo de login. Esse método é mais seguro, porque um criminoso não pode acessar a conta do usuário, a menos que tenha acesso à senha normal do usuário e à senha única.

Atualmente, existem dois métodos amplamente utilizados para obter essa senha única:

1. Com base em um SMS: nesse método, toda vez que o usuário faz login, ele recebe uma mensagem de texto para seu número de telefone registrado, que contém uma senha única.
2. Com base na senha única dependente do tempo: nesse método, ao habilitar a autenticação de dois fatores, solicita-se ao usuário que faça o escaneamento de uma imagem com código QR usando uma aplicação específica no smartphone. A aplicação gera continuamente senhas de uso único dependentes do tempo para o usuário.

O método baseado em SMS não precisa de muita explicação. É fácil, mas tem seus problemas, como esperar pelo SMS em cada tentativa de login, problemas de segurança e assim por diante. O método baseado nas senhas de uso único dependentes do tempo está se tornando popular por causa de suas vantagens sobre o método baseado em SMS. Então, vamos entender como funciona o método das senhas de uso único dependentes do tempo.

Como o método das senhas de uso único dependentes do tempo funcionam

Antes de entender isso, vamos primeiro discutir quais problemas esse método resolverá para nós.

Ao usarmos esse método, estamos criando uma senha única no lado do usuário (em vez de no lado do servidor) através de uma aplicação para smartphone.

Isso significa que os usuários sempre têm acesso à sua senha única. Assim, isso impede que o servidor envie uma mensagem de texto toda vez que o usuário tenta fazer login.

Além disso, a senha gerada muda após um determinado intervalo de tempo, para que se comporte como uma senha única.

Agora, vamos entender o funcionamento do método e tentar implementar a solução acima nós mesmos. Nossos requisitos aqui são criar uma senha no lado do usuário e que essa senha deve continuar mudando.

A seguir, veremos um modo de implementar essa solução:

Quando o usuário habilita a autenticação de dois fatores:

1. O servidor de back-end cria uma chave secreta para aquele usuário específico.
2. O servidor, então, compartilha aquela chave secreta com a aplicação do trelefone do usuário
3. A aplicação do telefone inicia um contador.
4. A aplicação do telefone gera uma senha de uso único com aquela chave secreta e com o contador.
5. A aplicação do telefone muda o contador após determinado intervalo e gera novamente uma senha de uso único, o que a torna dinâmica.

Isso deve funcionar, mas há três problemas principais com isso:

1. Como a aplicação gerará uma senha de uso único com a chave secreta e com o contador?
2. Como o contador será atualizado? Como o servidor da web vai acompanhar o contador?
3. Como o servidor compartilhará a chave secreta com a aplicação do telefone?

A solução do primeiro problema é definida pelo uso do algoritmo HOTP.

Entendendo o HOTP:

HOTP é a sigla em inglês para "HMAC-Based One-Time Password" (em português, senha de uso único com base em HMAC). Esse algoritmo foi publicado inicialmente como RFC4226 pela Internet Engineering Task Force (IETF). O HOTP define um algoritmo para criar uma senha de uso único a partir de uma chave secreta e de um contador.

É possível usar esse algoritmo em duas etapas:

1. A primeira etapa é criar um hash HMAC a partir da chave secreta e do contador.

// Obtenha o hash HMAC (usando o algoritmo de criação de hash SHA-1) a partir da chave secreta e do contador
hmacHash = HMAC-SHA-1(chaveSecreta, contador);

2. O resultado desse código seria uma string de 20 bytes. Essa string longa não é adequada como uma senha de uso único. Então, precisamos de uma maneira de reduzi-la. O HOTP define uma maneira de fazer isso deixando-a no comprimento desejado.

// hmacHash[19] representa o 19º byte da string.
offset = hmacHash[19] & 0xf;
hashReduzido = (hmacHash[offset++] & 0x7f) << 24 | (hmacHash[offset++] & 0xff) << 16 | (hmacHash[offset++] & 0xff) << 8 | (hmacHashh[offset++] & 0xff);
finalOTP = (hashReduzido % (10 ^ numeroDeDigitosExigidosNaSenha));

Pode parecer assustador, mas não é. Nesse algoritmo, primeiramente, obtemos o offset, que são os últimos 4 bits de hmacHash[19]. Depois disso, concatenamos os bytes de hmacHash[offset] em hmacHash[offset+3] e armazenamos os últimos 31 bits de hashReduzido. Por fim, usando uma operação simples de módulo (%), obtemos a senha de uso único do tamanho desejado.

Isso, praticamente, define o algoritmo do HOTP. O documento RFA4226 explica por que essa é a maneira mais segura de se obter uma senha única desses dois valores.

Então, encontramos uma maneira de obter uma senha única usando uma chave secreta e um contador. O segundo problema é: como acompanhar o contador?

A solução para o segundo problema é encontrada na TOTP (abreviação para Time-Based One-Time Password, em inglês).

Entendendo a TOTP:

TOTP é a abreviação de "Time-Based One-Time Password". Ela foi publicada na RFC6238 pela IETF.

Uma TOTP usa o algoritmo do HOTP para obter a senha de uso único. A única diferença é que ele usa "tempo" no lugar do "contador", o que nos dá a solução para o nosso segundo problema.

Isso significa que, em vez de inicializar o contador e mantê-lo controlado, podemos usar o tempo como um contador no algoritmo do HOTP para obter a senha de uso único. Como um servidor e um telefone têm acesso ao tempo, nenhum deles precisa acompanhar o contador.

Além disso, para evitar o problema de fusos horários diferentes do servidor e do telefone, podemos usar um carimbo de data/hora Unix, que é independente dos fusos horários.

No entanto, o tempo Unix é definido em segundos e, por isso, muda a cada segundo. Isso significa que a senha gerada mudará a cada segundo, o que não é bom. Em vez disso, precisamos adicionar um intervalo significativo antes de alterar a senha. Por exemplo, a aplicação do Google Authenticator altera o código a cada 30 segundos.

contador = currentUnixTime / 30

Resolvemos, assim, o problema do contador. Agora, precisamos resolver nosso terceiro problema: compartilhar a chave secreta com a aplicação do telefone. Aqui, um código QR pode nos ajudar.

Usando um QR code

Embora possamos pedir aos usuários que digitem a chave secreta em sua aplicação de telefone diretamente, queremos tornar as chaves secretas bastante longas por razões de segurança. Pedir ao usuário para digitar uma string tão longa não seria uma experiência amigável.

Como a maioria dos smartphones é equipada com uma câmera, podemos usá-la e pedir ao usuário que escaneie um QR code para obter a chave secreta dele. Então, tudo o que precisamos fazer é converter a chave secreta no QR code e mostrá-la ao usuário.

Resolvemos os três problemas! Agora, você já sabe como funciona a TOTP. Vamos ver como implementá-la em uma aplicação.

Como implementar a TOTP

Existem algumas aplicações de telefone gratuitas disponíveis (como o Google Authenticator, Authy e outras) que podem gerar uma senha de uso único para o usuário. Portanto, na maioria dos casos, não é necessário criar sua própria aplicação de telefone.

Os pseudocódigos a seguir explicam uma maneira de implementar a autenticação de 2 fatores baseada em tempo em uma aplicação para a web.

Quando o usuário solicita habilitar a autenticação de dois fatores

// Gere uma chave secreta de comprimento 20.
secretKey = generateSecretKey(20);
// Salve a chave secreta no banco de dados para esse usuário específico.
saveUserSecretKey(userId, secretKey);
// converta a chave secreta em uma imagem de QR code.
qrCode = convertToQrCode(secretKey);
// envie a imagem de QR code como resposta 
response(qrCode);

É solicitado ao usuário que escaneie esse QR code. Quando a aplicação do telefone escaneia o QR code, ela recebe a chave secreta do usuário. Usando essa chave secreta, a hora atual do Unix e o algoritmo do HOTP, a aplicação de telefone gerará e exibirá a senha.

Pedimos ao usuário que digite o código gerado após escanear o QR code. Isso é necessário, porque queremos ter certeza de que o usuário escaneou com êxito a imagem e que a aplicação do telefone gerou o código com êxito.

O usuário digita o código exibido na aplicação.

// Obter a chave secreta do banco de dados.
secretKey = getSecretKeyOfUser(userId);
if (codeTypedByUser == getHOTP(secretKey, currentUnixTime / 30)) {
	enableTwoFactorAuthentication(userId);
}

Aqui, usamos o algoritmo DO HOTP no lado do servidor para obter a autenticação baseada na senha de uso único, na chave secreta e no tempo atual Unix. Se essa senha de uso único for a mesma digitada pelo usuário, podemos habilitar a autenticação de dois fatores para esse usuário.

Após cada operação de login, precisamos verificar se esse usuário específico tem a autenticação de 2 fatores habilitada. Se estiver habilitada, pedimos a senha única exibida na aplicação do telefone. Somente se esse código digitado estiver correto, o usuário será autenticado.

O usuário digita o código exibido na aplicação do telefone para fazer o login

// Obtém a chave secreta no banco de dados.
secretKey = getSecretKeyOfUser(userId);
if (codeTypedByUser == getHOTP(secretKey, currentUnixTime)) {
	signIn(userId);
}

O que acontece se o usuário perder o código?

Há algumas maneiras de ajudar o usuário a recuperar o código. Normalmente, quando eles ativam a autenticação de 2 fatores, podemos mostrar a chave secreta para eles junto com o QR code e pedir que salvem esse código em algum lugar com segurança.

Aplicações como o Google Authenticator permitem que você gere a senha inserindo diretamente a chave secreta. Se o usuário perder o código, ele pode inserir essa chave secreta salva com segurança na aplicação do telefone para gerar a senha de uso único novamente.

Conclusão

A autenticação de dois fatores está ganhando popularidade. Muitas aplicações da web já estão implementando-a para ter mais segurança.

Ao contrário do método baseado em SMS, o método da TOTP também não requer muito esforço extra. Portanto, vale a pena implementar esse recurso para qualquer aplicação.

Escrito por: Ayo Isaiah

Em 2018, o Google anunciou que o Chrome passaria a marcar todas as páginas HTTP como "Não seguras" em sua versão 68.

Nota da tradução: A versão mais recente do Chrome no momento desta tradução é a versão 114.

Este foi o empurrão mais forte para direcionar a web para a criptografia por padrão e foi esperado há muito tempo.

Embora haja muitas evidências que mostram por que todos deveriam entrar na tendência do HTTPS, muitas pessoas ainda não enxergam o valor em oferecer seus sites de maneira segura.

"Por que eu preciso disso para um blog?"

Já escrevi sobre o valor do HTTPS anteriormente (texto em inglês), mas apenas para reiterar:

• O HTTPS protege os usuários contra ataques Man-In-the-Middle (texto em inglês).
• O HTTPS é necessário para aproveitar muitos novos recursos dos navegadores (texto em inglês), como os "Service Workers"
• HTTPS afeta o SEO (texto em inglês)

Se você não estiver convencido, leia o DoMysiteneedhttps.com (texto em inglês) para obter a visão completa do porquê todo site da web deve ter segurança.

Se você ainda não se convenceu, saiba a vida está prestes a se tornar muito mais difícil para você.

Em um esforço para afastar os usuários de sites inseguros, os navegadores desencorajam sites inseguros em certos contextos.

O Chrome 56 iniciou essa tendência ao marcar as páginas com campos sensíveis de login como "Não seguro", enquanto o Chrome 62 estendeu esse aviso a todas as páginas HTTP que continham qualquer tipo de campo de entrada. Além disso, o aviso é exibido em todas as páginas HTTP no modo de navegação anônima, independentemente de conterem um campo de entrada ou não.

O Firefox também alerta os usuários quando tentam preencher um formulário de login inseguro.

O Chrome decidiu, a partir de 2018, colocar esse aviso em todas as páginas HTTP daqui para frente. O ícone ao lado do rótulo "Não seguro" mudou e o texto passou a ficar em vermelho para enfatizar ainda mais que as páginas HTTP não são confiáveis.

Para evitar que os usuários vejam este aviso em seu site, tudo o que você precisa é obter um certificado SSL válido. A boa notícia é que fazer isso não é tão difícil ou caro como costumava ser. Na verdade, vou mostrar como implantar HTTPS em seu site gratuitamente usando o Cloudflare. Não vai demorar muito.

Por que usar o Cloudflare?

O CloudFlare pode ajudá-lo a proteger um certificado SSL gratuitamente, independentemente da infraestrutura do lado do servidor que você possui. Ele também funciona para sites hospedados em plataformas que não fornecem acesso ao servidor, como GitHub Pages, Ghost e similares.

Você não precisa instalar nada nem escrever código. Isso o torna uma ótima opção para implantar HTTPS em seu site e o tempo de configuração não deve levar mais de 10 minutos.

Ele também fornece uma infinidade de outros benefícios em segurança e desempenho do seu site que não abordarei aqui. Falarei um pouco, no entanto, a respeito de como tudo funciona para que você tenha uma boa ideia de como ele é capaz de fazer todas essas coisas.

Como funciona o Cloudflare

O Cloudflare fica bem no meio do tráfego entre os visitantes do seu site e seu servidor. Os visitantes podem ser humanos comuns, rastreadores e bots (como bots de mecanismos de pesquisa) ou hackers. Ao agir como um intermediário entre seu servidor da web e os visitantes de seu site, o Cloudflare ajuda a filtrar todo o tráfego ilegítimo para que apenas as coisas boas passem.

Agora você deve estar se perguntando se tudo isso pode ter um efeito adverso na velocidade do seu site, mas é exatamente o contrário. O Cloudflare tem centros de dados em todo o mundo. Portanto, usará apenas o endpoint mais próximo do visitante, o que deve tornar seu site muito mais rápido do que antes.

Agora que sabemos como o Cloudflare funciona, vamos dar uma olhada em como configurar um site em sua infraestrutura e como acessar o HTTPS gratuitamente. O foco, aqui, será nos recursos que o Cloudflare fornece gratuitamente, mas observe que os planos pagos também estão disponíveis com vários recursos extras.

Configurando um novo site

Depois de se cadastrar no Cloudflare, a primeira coisa a fazer é adicionar um domínio e escanear [scan] os registros DNS. [disponível em português]

Depois que a verificação for concluída, todos os registros DNS no domínio serão exibidos. Você pode escolher os subdomínios nos quais deseja habilitar o Cloudflare e fazer as modificações desejadas. Quando estiver pronto, clique em Continue para ir para a próxima etapa.

Selecione o plano gratuito (Free Website) e clique em Continue.

Em seguida, você precisará alterar os Nameservers em seu provedor de registro de domínio para os fornecidos pelo Cloudflare. O processo para fazer isso em cada provedor de registro de domínio é um pouco diferente. Portanto, verifique com o seu provedor.

Veja como fica no provedor Namecheap:

Agora, você deve esperar que as alterações do nameserver terminem de se propagar. Clique em Recheck Nameservers depois de um tempo para ver se seu site agora está ativo no Cloudflare. Essa é a parte mais demorada da configuração e pode levar até 24 horas, mas, na minha experiência, levou menos de 5 minutos.

Depois que as atualizações do nameserver forem validadas pela Cloudflare, seu site se tornará ativo no serviço.

Se você quiser ter certeza absoluta de que suas configurações de DNS se propagaram em todos os lugares, o What's My DNS fornece uma maneira de verificar qual endereço IP seu domínio resolve em locais diferentes.

Você também pode usar dig ou nslookup na linha de comando para verificar a configuração de DNS do seu domínio.

Assim, você pode ter certeza de que todo o tráfego que vai para o seu domínio agora está sendo roteado pelo Cloudflare.

Antes de começar a configurar o Cloudflare, certifique-se de que seu navegador não esteja usando os registros DNS antigos de seu cache. No Chrome e no Firefox, você pode fazer isso limpando o histórico do navegador.

Obtendo SSL gratuitamente

O SSL ainda é um serviço premium e muitas Autoridades Certificadoras cobram quantias significativas antes de emitir um certificado SSL. Não é algo que você possa obter de graça em algum lugar, mas isso está mudando rapidamente na indústria.

Agora que você tem o Cloudflare no meio do tráfego da web, você deve obter o SSL em seu domínio automaticamente. Pode levar até 24 horas para que o certificado fique ativo, mas, pela minha experiência, não demora muito.

Depois que o certificado se tornar ativo, carregue seu site em um navegador. Você deve ver o site servido por HTTPS e um belo cadeado verde na barra de endereços.

Se você visualizar mais informações sobre o certificado, verá a autoridade de certificação que o emitiu (a Comodo, no meu caso) e a data de validade. Uma das grandes vantagens do Cloudflare é que a renovação do certificado é feita automaticamente para você. Assim, não é preciso se preocupar.

Diferença entre SSLs Flexible, Full e Full (Strict)

O Cloudflare torna muito fácil obter o SSL em seu site gratuitamente sem configurar nada, mas nem sempre é o mesmo que servir seu site por SSL diretamente da origem.

Existem três implementações do SSL do Cloudflare. O primeiro, que você obtém por padrão, é o SSL Flexible. Nesse caso, o tráfego é criptografado entre os usuários do seu site e o Cloudflare, mas essa criptografia não chega até o servidor de origem. O Cloudflare ainda se comunica com seu servidor por HTTP simples.

Isso significa que qualquer "Man-In-The-Middle" (como provedores de rede) entre o Cloudflare e seu servidor pode ver o tráfego. Se você coletar informações confidenciais em seu site, evite usar essa opção.

Para ter criptografia até o servidor de origem, você precisa usar a implementação Full ou Full (Strict). O primeiro exige que você instale um certificado válido em seu servidor, mas a autenticidade do certificado não será verificada para que você possa obter um certificado autoassinado. Por outro lado, a implementação Full (Strict) requer que você instale um certificado SSL válido que tenha sido assinado por uma Autoridade de Certificação confiável.

Se você não deseja comprar SSL de empresas como a Comodo, pode obter certificados Origin CA gratuitos do Cloudflare, que podem ser usados com as opções Full ou Full(Strict), pois são confiáveis para o Cloudflare. Lembre-se, porém, de que esses certificados são confiáveis apenas para o Cloudflare. Deste modo, eles pararão de funcionar se você decidir retirar seu site da infraestrutura do Cloudflare.

Se você não controlar seu ambiente de servidor (por exemplo, se seu site estiver hospedado no GitHub Pages ou plataformas semelhantes), não poderá usar as implementações Full ou Full (Strict), o que significa que, mesmo que seus usuários vejam HTTPS na barra de endereço, o tráfego não será criptografado até o servidor de origem.

É, contudo, uma grande melhoria em comparação a ter nenhum HTTPS, porque protegerá seus usuários contra "Man-In-The-Middle" no lado do client.

Fortalecer a implementação de SSL

Não importa por qual implementação SSL você opte, existem maneiras de fortalecê-la para garantir que os usuários nunca acessem seu site por HTTP inseguro. O Qualys SSL Labs é uma ferramenta que ajuda você a executar um teste em sua configuração SSL para ver se há espaço para melhorias.

Mesmo que eu tenha uma nota A em meu domínio, se você detalhar os resultados, verá que definitivamente há espaço para melhorias nos lados da Key Exchange (Troca de Chave) e da Cipher Strength (Força do Ciframento).

Vamos dar uma olhada em algumas coisas que podemos fazer no Cloudflare para fortalecer nosso SSL e obter classificações ainda mais altas.

Forçar HTTPS em todos os lugares

Depois de usar o HTTPS, você definitivamente desejará impedir que os usuários acessem seu site por meio de uma conexão insegura. Isso pode ser feito no Cloudflare redirecionando todo o tráfego HTTP para HTTPS com um redirecionamento 301.

Nas configurações de criptografia, encontre a opção Always use HTTPS (sempre usa HTTPS) e ative-a.

Habilitar a segurança estrita de transporte HTTP (HSTS)

No passado, escrevi sobre como o HSTS fortalece o SSL do seu site (texto em inglês), mas vamos revisar brevemente.

O problema ao redirecionar o tráfego HTTP para HTTPS usando apenas um redirecionamento 301 é que a solicitação inicial insegura ainda é enviada pela rede, o que significa que pode ser lida por qualquer pessoa com acesso ao tráfego.

O HSTS é um cabeçalho de resposta que resolve esse problema, informando ao navegador que ele não pode fazer uma solicitação insegura a um site por um período de tempo especificado.

Esta é a aparência do cabeçalho:

strict-transport-security: max-age=31536000

Assim que o navegador receber esse cabeçalho, ele não fará uma solicitação insegura ao seu site pelos próximos 31.536.000 segundos (equivalente a um ano). Em vez disso, todas as solicitações HTTP serão atualizadas internamente para HTTPS antes de serem enviadas pela rede.

Se você deseja impedir que todos os subdomínios sejam acessados por HTTP, precisará usar a diretiva includeSubdomains. Você também pode adicionar a diretiva preload para permitir que os fabricantes de navegadores incluam seu site diretamente no navegador como sendo apenas HTTPS.

strict-transport-security: max-age=31536000; includeSubdomains; preload

Uma vez que você tenha ativado o HSTS em seu domínio, pode ter certeza de que, uma vez que alguém tenha carregado seu site via HTTPS, eles só poderão acessá-lo através do esquema seguro dali em diante.

Portanto, antes de habilitar o HSTS em seu site, certifique-se de ter confiança de que todo o seu tráfego será servido via HTTPS. Caso contrário, você enfrentará problemas.

Para habilitar isso no Cloudflare, vá para as configurações de Crypto e role para baixo até a seção HTTP Strict Transport Security (HSTS). Clique em Change HSTS Settings [Alterar configurações de HSTS], habilite todas as opções relevantes e clique em Save.

Caso esteja se perguntando, o suporte dos navegadores para o HSTS é bastante bom.

Corrigir referências ao esquema inseguro

Se você incorporar um recurso passivo (como uma imagem) de maneira insegura em uma página segura, o navegador ainda vai carregá-lo normalmente. A única diferença é que o cadeado verde é removido da barra de endereços. Você pode ver um exemplo desse erro aqui.

Se você verificar o console do navegador, verá algumas mensagens de aviso ou erros que apontam para o recurso que foi incorporado de maneira insegura. Nesse caso, é:

<img class="mixed" src="http://mixed.badssl.com/image.jpg" alt="HTTP image">

Para corrigir isso, basta alterar o esquema para HTTPS e tudo ficará bem novamente.

<img class="mixed" src="https://mixed.badssl.com/image.jpg" alt="HTTP image">

Se você tem muito conteúdo em seu site incorporado de modo inseguro, encontrar e corrigir cada um pode ser bastante tedioso. O Cloudflare pode ajudar novamente aqui com o recurso Automatic HTTPS Rewrites.

Para ter uma certeza absoluta de que nenhum conteúdo do seu site será servido de modo inseguro, considere implementar uma Política de Segurança de Conteúdo (Content Security Policy, CSP – texto em inglês) em seu site.

Agora, vamos ver como as alterações acima afetaram nosso relatório do SSL Labs. Rodei o teste novamente em meu domínio e agora obtemos uma classificação A+.

Se você verificar as classificações individuais no gráfico, nada mudou, mas ainda assim obtemos uma implementação de SSL muito segura gratuitamente e em apenas alguns minutos.

Alternativas ao Cloudflare para SSL gratuito

Se você preferir não usar o Cloudflare por algum motivo, existem outras maneiras de tornar o seu site acessível via HTTPS de maneira gratuita. Aqui estão duas opções que você pode experimentar:

Let’s Encrypt

Se você tiver controle sobre o seu servidor, pode implantar rapidamente o HTTPS no seu site usando o Let's Encrypt. Eles oferecem certificados SSL gratuitos com validade de três meses e que podem ser renovados automaticamente.

Mesmo se você não tiver acesso ao servidor, verifique com o seu provedor de hospedagem. Alguns hosts permitem o uso do Let's Encrypt SSL sem fornecer acesso ao shell (linha de comando).

Gerenciador de Certificados Amazon AWS

A Amazon também emite e renova automaticamente certificados SSL para clientes em sua infraestrutura da Amazon Web Services (AWS). Desse modo, você pode configurar e esquecer o HTTPS em seu site se estiver usando recursos da AWS, como o Cloudfront.

Independentemente de como você implementa o HTTPS em seu site, o mais importante é garantir que você o configure o mais rápido possível para que seus usuários obtenham os benefícios de segurança que ele oferece e para não perder várias funcionalidades interessantes nos navegadores que ajudam a criar experiências melhores na web.

Se você gostou deste artigo, compartilhe com outras pessoas que possam se beneficiar da leitura. A propósito, confira o blog do autor em freshman.tech para ver mais artigos sobre desenvolvimento para a web. Obrigado pela leitura.

É o trabalho dos desenvolvedores de software trabalhando em software proprietário criar programas que forneçam as funcionalidades de que nossos clientes precisam. Além disso, também é nosso trabalho criar esses programas de maneira que sejam fáceis de usar, manter e atualizar.

Desenvolvedores de software proprietário, contudo, possuem outra responsabilidade muito mais importante. Temos que criar um software que seja seguro e não coloque em risco os dados do usuário ou os sistemas de nossos clientes.

A chave para fazer isso é fortalecer nosso código-fonte e reforçar os processos de desenvolvimento para evitar que agentes mal-intencionados injetem qualquer coisa prejudicial enquanto trabalhamos.

Esses tipos de esforços são cruciais, pois o código-fonte é o componente básico de um programa de computador. Por isso, precisamos protegê-lo de quaisquer alterações não autorizadas.

Este artigo explicará o motivo de a proteção do código-fonte ser tão importante para projetos de software proprietário. Ele também dará aos programadores algumas dicas sobre como proteger seu código-fonte, bem como algumas orientações sobre como protegê-lo de alterações externas durante o processo de desenvolvimento.

Por que é importante proteger seu código-fonte?

O uso de código aberto no desenvolvimento de software proprietário cresce cada dia mais. Na última contagem, estima-se que até 96% dos softwares proprietários (texto em inglês) contenham algum código-fonte aberto. Os desenvolvedores usam esse tipo de código para acelerar o processo de desenvolvimento e evitar trabalho desnecessário. Do ponto de vista da segurança, isso é uma coisa boa.

De acordo com a maioria dos especialistas em segurança, é mais provável que um código aberto seja seguro e permaneça seguro devido ao grande número de olhos que o revisam ao longo do tempo (texto em inglês).

Quando, no entanto, um desenvolvedor começa a juntar código-fonte aberto e a adicionar suas próprias personalizações para criar algo proprietário, toda essa segurança se encerra. A partir desse ponto, cabe ao desenvolvedor evitar adicionar quaisquer vulnerabilidades que possam levar a uma violação de dados ou a um golpe.

Dependendo da natureza do software em questão, há uma variedade de dados que podem estar em risco no seu software quando estiver concluído, incluindo:

• Senhas
• Chaves de criptografia
• Endereços IP
• Tokens de autenticação e muito mais.

Isso torna o vazamento de código-fonte uma das principais ameaças para qualquer desenvolvedor de software proprietário. Essa ameaça não é apenas teórica. Houve vários casos de vazamentos de código proprietário (texto em inglês) nos últimos anos. Em muitos desses casos, as consequências finais ainda estão longe de serem claras.

Em um dos casos, porém – o vazamento de todo o repositório do código-fonte do Twitch – as consequências foram muito graves. De acordo com uma análise dos dados, os hackers obtiveram acesso a quase 7.000 segredos (texto em inglês). Esses segredos, que consistem nos tipos de dados listados acima, podem dar aos invasores acesso catastrófico à plataforma.

As principais ameaças à segurança do código-fonte

Existem duas categorias principais de ameaças à segurança de um código-fonte:

Ameaças internas

O código-fonte fica à mercê dos desenvolvedores e de qualquer pessoa que tenha acesso a ele. Isso significa que limitar o acesso ao seu código-fonte e estabelecer diretrizes de segurança para aqueles que têm acesso é vital para aumentar a segurança.

Também é importante perceber que os agentes de ameaças internas nem sempre são mal-intencionados. Muitas vezes, as ameaças internas vêm de erros ou descuidos dos próprios funcionários.

Para exemplificar, um programador pode compartilhar partes do código-fonte em um fórum on-line procurando uma resposta que possa resolver um problema – fazendo com que o código acabe caindo em mãos erradas.

Ameaças externas

As ameaças externas vêm de fora de sua equipe de desenvolvimento. Elas podem vir de concorrentes que desejam usar o código para melhorar seu próprio código. Também podem vir de hackers, que tentarão vender seu código-fonte ou que o vasculharão em busca de vulnerabilidades.

O ponto é que, não importando se um vazamento vem de ameaças internas ou externas, ele pode ter consequências terríveis. Vazamentos de código-fonte podem levar a ataques adicionais, expondo grandes quantidades de dados confidenciais.

Vazamentos de código-fonte também podem levar a perdas financeiras, dando vantagem aos concorrentes. Seus clientes pensarão duas vezes antes de negociar com um desenvolvedor que expôs dados valiosos de clientes no passado.

As regulamentações em torno da segurança também estão se tornando mais rígidas. Seus clientes podem enfrentar multas pesadas se não protegerem esses dados - e responsabilizarão você por isso.

Como proteger seu código-fonte

Agora que você sabe a importância de proteger o código-fonte, vejamos algumas formas de reforçar sua segurança:

Implementar práticas de desenvolvimento seguro

A segurança do seu código-fonte começa já no início do ciclo de desenvolvimento. Quanto mais cedo você detectar falhas de segurança no código, melhor.

Você deve definir um conjunto claro de práticas de programação, regras e procedimentos logo no início de cada processo. Isso inclui treinar sua equipe de desenvolvimento nas melhores práticas de segurança e fornecer a documentação dos padrões de segurança que eles precisam seguir durante o projeto.

O Open Web Application Security Project (OWASP) oferece um guia de referência abrangente (texto em inglês), sendo um ótimo ponto de partida. Embora seja adaptado para aplicações para a web, seus conceitos são amplamente aplicáveis ​​a todos os tipos de trabalho em desenvolvimento de software.

Seus pontos mais importantes incluem:

• Conduzir toda a validação e codificação de dados em um único sistema confiável
• Exigir autenticação padronizada e testada para acesso aos recursos do projeto
• Tomar medidas para reduzir a complexidade do código sempre que for possível, para facilitar a auditoria de segurança
• Projetar e criptografar os repositórios de código relacionados ao projeto
• Tornar protegida e segura a construção das etapas de desenvolvimento.

Ao manter seu código e processo de desenvolvimento alinhados com as melhores práticas de segurança estabelecidas no mercado, como as descritas acima, você pode reduzir drasticamente as chances de seu código ser comprometido ainda durante o desenvolvimento ou depois que estiver publicado. Como dizem, é melhor prevenir do que remediar.

Tão logo o código esteja escrito, você também deve usar ferramentas de análise de segurança (texto em inglês) a fim de identificar falhas de segurança e outros riscos. Essas ferramentas de análise de código também farão varreduras para garantir a conformidade com as melhores práticas de segurança e padrões de escrita de código. Essas ferramentas ajudarão você a identificar riscos e corrigir problemas básicos antes que seja tarde demais.

Algumas das ferramentas mais usadas para isso são:

• Appsonar – automatiza o teste de práticas recomendadas em mais de 15 idiomas e verifica vulnerabilidades de código conhecidas
• Codiga – verifica as melhores práticas, segurança, proteção e problemas de design em 18 linguagens e frameworks
• Mend SAST – fornece verificação automatizada de vulnerabilidades e a correção automática de vulnerabilidades conhecidas

Criptografar e monitorar dados em trânsito

A criptografia de dados é crucial para a proteção do seu código-fonte. Dados em trânsito são particularmente vulneráveis. Por isso, é uma boa ideia encontrar formas de manter seu código seguro à medida que ele passa entre os membros da equipe de desenvolvimento.

Um bom lugar para começar é usar uma plataforma de compartilhamento de código ou colaboração que inclua criptografia de ponta a ponta.

Há uma variedade de soluções destinadas a desenvolvedores de software que incluem criptografia. Algumas das opções mais usadas são CryptPad, CodeTogether e Visual Studio Live Share. Dependendo da natureza do projeto, um deles certamente será uma adição valiosa ao toolkit (kit de ferramentas, em português) de sua equipe.

Se uma plataforma de compartilhamento de código for um exagero naquilo que você está trabalhando, você pode usar uma plataforma de compartilhamento de arquivos criptografados (texto em inglês) e usá-la para trocar trechos de código. E se você estiver trabalhando com uma equipe que não está toda em um único escritório, é uma boa ideia investir em uma VPN. A VPN vai mascarar seu endereço IP e criptografar todas as transferências de dados entre suas redes.

Saiba, porém, que as VPNs geralmente diminuem a velocidade da sua internet. Portanto, você deve fazer sua pesquisa antes de comprar uma para você e sua equipe. Algumas VPNs são muito mais rápidas (texto em inglês) do que outras e só perdem sua velocidade de forma incremental. Então, escolha com sabedoria ou você pode prejudicar a produtividade de sua equipe.

Controle de acesso

As únicas pessoas que devem ter acesso aos repositórios de código-fonte são os desenvolvedores e a equipe de controle de qualidade. Não há razão para dar acesso a qualquer pessoa que não esteja envolvida na prática com a escrita de código.

Ao limitar o número de pessoas com acesso, você pode diminuir significativamente o risco de ameaças internas. Proteja seu código com autenticação e controle de acesso de autorizações.

Realizar revisões de segurança do código

As revisões de segurança do código são uma parte crítica do SDLC (Software Development Lifecycle) – texto em inglês. Essas revisões são particularmente importantes para a segurança, pois permitem que os membros da equipe identifiquem e resolvam quaisquer vulnerabilidades de segurança em potencial antes que o código seja publicado. Em muitos setores com os quais você pode vir a trabalhar, elas são obrigatórias para a conformidade regulatória.

É importante, entretanto, diferenciar revisão do código de revisão de segurança do código. Esta última deve se concentrar estritamente em "proteger" o código em termos de segurança. Revisões de código se concentram principalmente na correção de possíveis bugs ou falhas. Isso acontece com mais frequência enquanto sua base de código está em desenvolvimento pesado. Já as revisões de segurança do código devem acontecer principalmente quando seu código estiver próximo de um lançamento.

Nesse estágio, é uma boa ideia aplicar algumas técnicas abrangentes de proteção para dificultar o acesso de hackers ao software por meio de análise ou em tempo de execução.

Algumas técnicas incluem (textos em inglês):

• Ofuscação de código
• Criptografia de string
• Detecção e resposta de adulterações em tempo de execução
• Medidas antidepuração

Dependendo da sensibilidade dos dados com os quais seu software está lidando, pode ser necessário ir muito além das técnicas que compartilhei acima. Acima de tudo, você deve sempre atender às necessidades de segurança do cliente – mesmo que eles peçam para você fortalecer seu código além do que você acredita ser necessário.

Considerações finais

Os desenvolvedores de software proprietário precisam prestar muita atenção à segurança do código-fonte. Eles não devem expor a si mesmos nem aos seus clientes a grandes riscos que são facilmente evitáveis.

Portanto, durante todo o processo de desenvolvimento, você precisa se proteger contra ameaças internas e externas. Não fazer isso pode colocar dados confidenciais em perigo, levando, potencialmente, a danos financeiros e de reputação significativos — a todos os envolvidos.

Imagem produzida por Gorodenkoff e licenciada por meio da Adobe Stock Photos