Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

SUMÁRIO

1. Objetivo...........................................................................................................................................................2
2. Público-alvo.....................................................................................................................................................2
3. Responsabilidades ..........................................................................................................................................2
4. Regras..............................................................................................................................................................2
4.1. Regras Gerais...........................................................................................................................................2
4.2. Certificados .............................................................................................................................................3
4.3. Plug-in......................................................................................................................................................3
4.4. Codificação ..............................................................................................................................................4
4.5. Autenticação e gerenciamento de sessão..............................................................................................5
4.6. Upload de arquivos.................................................................................................................................5
4.7. Configuração de parâmetro de segurança.............................................................................................5
4.8. Métodos HTTP.........................................................................................................................................6
4.9. Configuração de respostas dos servidores:............................................................................................7
4.10. Infraestrutura......................................................................................................................................7
4.11. Aplicação .............................................................................................................................................7
4.12. Referência a objetos (arquivos)..........................................................................................................8
5. Documentos Relacionados .............................................................................................................................8
6. Penalidades.....................................................................................................................................................8
7. Glossário..........................................................................................................................................................8
1
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

1. Objetivo

Estabelecer diretrizes de segurança a serem seguidas em todos os processos de desenvolvimento

da Dock.

2. Público-alvo
 As diretrizes desta política se aplicam a todos os desenvolvedores que atuam no processo de
desenvolvimento e manutenção das aplicações da Dock, sejam estes colaboradores, terceiros ou
fornecedores.

3. Responsabilidades

• Segurança da Informação: Comunicar aos Desenvolvedores a respeito de novas

diretrizes necessárias para garantir o desenvolvimento seguro.
• Desenvolvedor: Garantir que as práticas descritas nesta política sejam implantadas e cumpridas.

4. Regras

Abaixo serão descritas as recomendações de segurança, visando o desenvolvimento seguro das

aplicações da Dock.
As recomendações serão divididas por temas, visando facilitar o entendimento e busca de

informações. 4.1. Regras Gerais

• Toda documentação deve ser feita à parte do código fonte.

• Deve-se documentar as aplicações desenvolvidas, bem como as manutenções feitas,
visando manter um controle das alterações feitas;
• A documentação da aplicação deve conter: nome da aplicação, data de criação, tecnologias
utilizadas para o desenvolvimento (incluindo as versões), arquitetura ou desenho da solução
proposta para a criação da aplicação, nome do responsável pela criação de cada
classe/método/trecho de código e breve explicação da ação realizada por cada
classe/método/trecho de código;
• Deve ser feito o registro das alterações da documentação da aplicação, contendo: versão do
arquivo, item alterado, data de alteração, responsável pela alteração, motivo da alteração; • Não
informar no código fonte o nome ou contato da pessoa responsável por aquele trecho da
codificação. Esta informação deve estar contida na documentação da aplicação, externa ao
código fonte;
• Não manter massa de dados de nenhum tipo no código fonte, para evitar que um atacante
possa entender o que a aplicação espera receber naquele trecho de código;
• As contas de desenvolvimento e homologação devem ser removidas antes da aplicação se tornar
produtiva (entrar em ambiente de Produção);

2
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

• O código fonte deve ser revisado por outro colaborador ou terceiro que possua conhecimento
nas técnicas de desenvolvimento seguro aqui descritas antes de se tornar produtivo (entrar em
 ambiente de Produção);
• As correções devem ser implantadas antes que a aplicação se torne produtiva (entrar em
ambiente de Produção);
• Devem existir dois ambientes segregados, um para Desenvolvimento/Homologação e outro para
Produção;
• Devem existir duas equipes diferentes, uma para atuar em Desenvolvimento/Homologação
e outra para atuar em Produção;
• Os ambientes de Desenvolvimento/Homologação não devem se comunicar com o ambiente de
Produção;
• Dados produtivos não podem ser utilizados como massa de testes, sejam os testes feitos em
ambiente de Desenvolvimento ou em ambiente de Homologação;
• Os responsáveis pelo desenvolvimento da aplicação não podem homologar a mesma,
devendo ser feita por outros colaboradores ou terceiros.

4.2. Certificados

• Os certificados digitais das aplicações que forem expostas à Internet devem possuir um
Emissor reconhecido (Ex.: VeriSign, CertiSign e etc.);
• Os certificados digitais devem ser válidos, sendo atualizados periodicamente para que não
haja problemas na conexão do Cliente;
• Os certificados digitais devem possuir o correto nome de domínio para que não haja
problemas na conexão do Cliente;
• Utilizar certificados internos apenas para aplicações de uso interno que tenham como
usuários apenas os funcionários da Dock;
• Caso seja utilizada uma CA interna, é necessário exportar e instalar no browser do usuário
a árvore toda do certificado digital, para que não haja problemas na conexão do Cliente.

4.3. Plug-in

• Utilizar ofuscadores de código para evitar que pessoas mal-intencionadas possam realizar
a engenharia reversa e ter acesso ao código fonte;
• Não utilizar comentários no código fonte para explicar o funcionamento do mesmo ou da
aplicação. Esta informação deve estar contida na documentação da aplicação, externa ao
código fonte;
• Adotar o uso de plataformas para inspeção contínua da qualidade do código (por exemplo,
SonarQube), para executar revisões automáticas com análise estática do código para detectar
bugs e vulnerabilidades de segurança em diversas linguagens de programação.
• Para a publicação do aplicativo em produção garantir que todas as configurações de debug foram
removidas (por exemplo, mensagens de erros, logs e etc).

3
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

4.4. Codificação

• Não utilizar comentários no código fonte para explicar o funcionamento do mesmo ou da

aplicação. Esta informação deve estar contida na documentação da aplicação, externa ao
código fonte;
• Não fixar no código parâmetros e/ou informações (hard coded) devendo buscar as
informações da base de dados;
• Recomenda-se a utilização de JSON/GSON para a criptografia do tráfego das informações
entre cliente e servidor, no nível de aplicação;
• Utilizar criptografia adicional ao SSL para dados considerados sensíveis, dentre os quais, mas não
se limitando a:
o Dados pessoais do Cliente (Nome completo, RG, CPF, endereço e etc.);
o Dados do cartão (Nome do titular, Número do cartão, CVV e etc.);
o Dados de transação (Cedente, CNPJ, Valor, Datas, Número de parcelas e etc.);
• O aplicativo não deve depender de criptografias simétricas com chaves codificadas como único
método de criptografia, não utilizar criptografias ou algoritmos que são considerados
depreciados para fins de segurança, não reutilizar a mesma chave criptográfica para vários fins,
os valores aleatórios são gerados usando um gerador de números aleatórios suficientemente
seguro.
• Mascarar o número do PAN todas as vezes que o mesmo for exibido ou trafegado; • Os dados
de transações não devem ser armazenados de nenhuma forma, após terem sido executados;
• Fazer o tratamento dos erros apresentados pela aplicação para que não apresentem stack traces
ou erros padrões aos usuários, pois estes podem conter informações sensíveis; • Não manter
arquivos de páginas antigas nos Web Servers e/ou manter no código funções que não são mais
utilizadas;
• Não utilizar bibliotecas de outras fontes a menos que estas sejam consideradas seguras, como os
grandes players do mercado (Ex.: Google);
• Fazer o tratamento dos dados inseridos pelo usuário, removendo caracteres especiais, dentre os
quais, mas não se limitando a: maior (<), menor (>), parênteses (“(“ e “)”), aspas simples (‘),
aspas duplas (“), igual (=), exclamação (!), ponto e vírgula (;), interrogação (?);
• Restringir o uso palavras que podem ser utilizadas para inserir codificação nas requisições e/ou
campos de inserção, dentre os quais, mas não se limitando a: “script”, “alert”, “php”, “insert”,
“delete”, “update”, “select” e etc.
• Configurar a aplicação para tratar todos os dados/informações recebidas do usuário como String,
evitando a execução de código malicioso;
• Utilizar um token único em transações da aplicação para evitar ataques do tipo cross-site request
forgery, onde um atacante consegue forjar/executar uma transação sem que o usuário tenha
conhecimento.
• Não armazenar informações de identificação pessoal (PII), credenciais de usuários e chaves
criptográficas fora do contêiner do aplicativo ou das instalações de armazenamento de
credenciais em logs, em cache do teclado, interface do usuário, e incluído nos backups gerados
pelo sistema operacional móvel.
• As diferentes combinações refletem diferentes graus de segurança e resiliência, com o objetivo
de permitir flexibilidade: por exemplo, um jogo móvel pode não garantir a adição de controles

4
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

 Área: Segurança da Informação Versão:3

de segurança MASVS-L2, como autenticação de dois fatores, por motivos de usabilidade, mas
tem uma forte necessidade comercial de prevenção de adulteração.
• Utilizar metodologias de testagem de segurança das aplicações (SAST e DAST), para identificar de
forma ágil e eficiente vulnerabilidades que podem tornar uma aplicação suscetível a ataques.

4.5. Autenticação e gerenciamento de sessão

• Interfaces administrativas não devem estar expostas à Internet, caso seja necessário,
estas devem ter seu acesso restrito;
• Não utilizar usuários que remetam ao nome da Dock e suas afiliadas, pois estes serão
inseridos em dicionários de logins privativos para invasão dos sistemas;
• O uso de contas de serviço para acessos da aplicação na busca de informações é permitido, desde
que respeite o processo de dupla custódia informado na Política de Identidade e Gestão de
Acessos;
• A aplicação deve retornar a mesma resposta tanto para quando o usuário é válido e a senha foi
inserida incorretamente, quanto para quando o usuário é inexistente, para evitar a
enumeração de usuários;
• As informações de autenticação devem utilizar criptografia adicional ao SSL;
• Definir o parâmetro “autocomplete=off” nos formulários e campos de login e senha, para
evitar que o browser salve as informações de autenticação do usuário;
• Caso a funcionalidade de recuperação de senha utilize perguntas secretas, estas devem ser
definidas para que apenas o usuário saiba a resposta, não sendo de fácil adivinhação ou
descoberta através de pesquisa sobre o usuário;
• Caso a funcionalidade de recuperação de senha envie um e-mail ao usuário com um link para a
troca da senha, este link deve possuir um token que o torne válido uma única vez. • Implementar
rotinas de gerenciamento de sessão por inatividade, garantir que as sessões são invalidadas no
back-end após um período mínimo de inatividade.

4.6. Upload de arquivos

• Deve-se restringir o upload de arquivos apenas à extensão necessária para a aplicação, sendo
exibida uma mensagem de erro caso o usuário tente realizar o upload de arquivos com
extensões não permitidas;
• A requisição de upload de arquivo deve ser única, para que não possa ser reaproveitada para
envio de arquivos em massa por um atacante, causando um DoS (Denial of Service).

4.7. Configuração de parâmetro de segurança

• Os seguintes parâmetros de segurança devem ser configurados em todos cabeçalhos de resposta

da aplicação:
o X-XSS-Protection: 1; mode=block;
o X-Frame-Options: [OPÇÃO]
o SAMEORIGIN – permite que a aplicação seja carregada dentro de frames, desde que
estejam dentro da mesma origem/domínio;

5
 Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

o allow-from: [DOMAIN] – permite que o domínio especificado carregue a aplicação como um

frame dentro de sua página;
o deny - bloqueia a possibilidade de carregamento da aplicação dentro de
frames; o X-Content-Type-Options: nosniff;
o Content-Type: text/html; charset=utf-8;
o Strict-Transport-Security: max-age=XXXXX (Ex.: max-age=31536000);
o Cache-Control: no-cache, no-store;
o Expires: 0;
o Pragma: no-cache;

• Os seguintes cabeçalhos de resposta devem ser removidos para não serem enviados ao cliente: o
Server;
o X-Powered-By;
o E-Tag;
o X-AspNet-Version (no caso de ASP.NET);
o X-AspNetMvc-Version (no caso de ASP.NET);
• Os seguintes parâmetros de segurança devem ser configurados em todos “set-Cookie”: o
Secure;
o HttpOnly;
o path=/.

4.8. Métodos HTTP

• Os seguintes métodos HTTP devem ser desabilitados dos Web Servers, não permitindo
que sejam utilizados por usuários mal-intencionados:
o OPTIONS;
o TRACE;
o PUT;
o DELETE;
o CONNECT (caso aplicável);
o PARCH (caso aplicável);
• Caso haja a necessidade de utilização dos métodos PUT/DELETE, deve-se aplicar controles
para restringir apenas aos usuários que necessitam tal permissão;
• Deve-se utilizar o método POST para requisições que trafeguem informações
consideradas sensíveis, devido ao fato do método GET gerar cache e histórico.
 6
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

4.9. Configuração de respostas dos servidores:

• Para evitar o ataque chamado directory listing (listagem de diretórios), onde o atacante mapeia
toda a aplicação, identificando os diretórios existentes, é necessário configurar a resposta que
os servidores retornarão ao cliente;
• Quando um usuário tentar acessar um diretório ao qual ele não possui permissão, a aplicação
deve responder com um “404 Not Found” ao invés de “403 Forbidden”, impedindo, assim, que
um atacante possa diferenciar os diretórios existentes dos não existentes.

4.10. Infraestrutura

• Restringir o acesso a portas administrativas, dentre os quais, mas não se limitando a: Telnet/SSH,
FTP/TFTP e etc.;
• Não utilizar protocolos de comunicação considerados inseguros, dentre os quais, mas não se
limitando a: FTP, Telnet e etc.;
• No caso de servidores Linux/Unix, os arquivos “shadow” e “passwd” devem estar inacessíveis
a partir da rede externa;
• Restringir por usuário ou grupo de usuários os locais de onde os arquivos podem
ser obtidos/salvos para evitar ataques do tipo path traversal;
• Desabilitar o uso de cifras consideradas fracas, como CBC/CBC3, SHA1, DES, RC4; • Utilizar
TLSv1.2 (preferencialmente) para estabelecimento do canal de comunicação SSL; • Quando ocorrer
alguma falha nas conexões TLS, a aplicação não deve fornecer uma conexão insegura. • Utilizar um
firewall de aplicativo da web (WAF) para filtrar, monitorar e bloquear tráfego indesejado.

4.11. Aplicação

• Aplicar política de cross-domain para definir entre quais domínios os dados internos da aplicação
podem ser trafegados;
• Definir adequadamente os perfis de acesso de cada usuário na aplicação, provendo
acesso somente às funcionalidades necessárias;
• Uma vez que o usuário acesse outro site ou efetue o logout do sistema, a sessão deve
ser encerrada, impedindo o reaproveitamento da mesma;
 • A sessão do usuário deve estar vinculada a seu IP de origem e, opcionalmente, ao seu user
agent, para evitar ataques do tipo session puzzling (embaralhamento de sessão) ou session
hijacking (roubo de sessão);
• Se a aplicação for acessada por mais de um canal diferente (PC, Mobile e etc.) deve-se
garantir que a autenticação terá o mesmo nível de segurança em todos os canais;
• Os usuários não devem conseguir acessar conteúdo ao qual seu perfil não fornece acesso,
devendo ser retornada uma mensagem de erro personalizada ou redirecionando-o para a
página inicial da aplicação;
• O tempo recomendado de timeout de sessão é de quinze minutos, podendo ser acrescido
mediante aceite de risco;

7
Política de Desenvolvimento Seguro

Documento: SI-POL-003 Classificação: Interna

Área: Segurança da Informação Versão:3

• A aplicação não deve ter variáveis de sessão expostas, o controle de sessão deve ser feito
via Cookie de sessão;
• Caso haja necessidade de manter requisições que contenham variáveis de sessão, por exemplo
ID de usuário, estas informações devem ser criptografadas.
• O aplicativo deverá remover dados confidenciais das visualizações quando movidos para o
segundo plano, não deve manter dados confidenciais na memória por mais tempo do que o
necessário, limpar a memória explicitamente após o uso, impor uma política mínima de
segurança de acesso ao dispositivo (por exemplo: exigir que o usuário defina uma senha de
dispositivo), educar o usuário sobre os tipos de informações de identificação pessoal
processadas, bem como as melhores práticas de segurança que o usuário deve seguir ao usar o
aplicativo.
• Para aplicativos que utilizem o WebView apenas renderizar JavaScript contido no pacote do
aplicativo.

4.12. Referência a objetos (arquivos)

• Os objetos da aplicação que serão disponibilizados aos usuários devem ser classificados
entre restritos e públicos.
• Os objetos restritos devem ter seu acesso controlado e estar em um diretório separado, com
acesso exclusivo aos usuários do grupo do cliente;
• Deve ser gerado um link único para acesso a estes objetos restritos, devendo ser renovado
a cada requisição para evitar ataques de referência insegura a objetos.

5. Documentos Relacionados

• Política de Segurança da Informação;

• Política de Identidade e Gestão de Acessos.

6. Penalidades
As violações a esta política estão sujeitas a sanções disciplinares de acordo com as políticas da Dock e
 Legislação Vigente. Distorções estão sujeitas a sanções disciplinares.

7. Glossário

• Massa de dados: Dados ou Informações utilizadas para testar o funcionamento do código

da aplicação.
• EICAR: Arquivo legítimo com a assinatura de um vírus, comumente utilizado para validar
o funcionamento e efetividade de antivírus.
• PAN: Número do cartão.
• Desenvolvedor: Colaborador/Terceiro/Fornecedor que atua na criação e/ou manutenção
das aplicações da Dock.
• Colaborador: Funcionário contratado no regime CLT.
• Terceiro/Fornecedor: Qualquer pessoa no regime PJ que presta serviço à Dock e afiliadas.
• MAVSV: Padrão de verificação de segurança de aplicativos móveis (MASVS).