Você está na página 1de 46
C-XPTO-01-2015-004 Análise de Segurança do Sistema XPTO DOCUMENTO RESTRITO – Este documento não pode ser
C-XPTO-01-2015-004 Análise de Segurança do Sistema XPTO DOCUMENTO RESTRITO – Este documento não pode ser
C-XPTO-01-2015-004 Análise de Segurança do Sistema XPTO DOCUMENTO RESTRITO – Este documento não pode ser

C-XPTO-01-2015-004

Análise de Segurança do Sistema XPTO

DOCUMENTO RESTRITO – Este documento não pode ser divulgado, no todo ou em parte, para terceiros fora da empresa ou órgão cliente para o qual foi endereçado sem o prévio consentimento por escrito da Safeval (R Albuquerque Consultoria).

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Revisões

Este documento não pode ser divulgado, no todo ou em parte, para terceiros fora da empresa ou órgão cliente para o qual foi endereçado sem o prévio consentimento por escrito da Safeval (R Albuquerque Consultoria). A tabela abaixo aponta as revisões deste documento.

Revisões deste documento

Revisão

Data

Observações

001

03/07/2012

Versão inicial

002

05/07/2012

Inclusão de porcentagens no gráfico

003

09/07/2012

Inclusão da análise do WebService

004

16/07/2012

Alteração dos nomes de categorias de risco

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Introdução

O objetivo deste documento é apresentar a metodologia, atividades realizadas, resultados obtidos e recomendações para a análise de segurança com inspeção de código realizada sobre o sistema XPTO para a empresa XPTO.

O sistema XPTO web é um sistema web, desenvolvido em Java com a funcionalidade

principal de permitir o envio de XXXXX de diversas origens para a XXXXX no

XXXXXX.

Além do mero envio de XXXXX, o sistema executa diversas funções, por exemplo, o cadastro de clientes, o cálculo do valor a ser pago pelo cliente pela XXXXX, emissão

de boletos, pagamento por cartão de crédito e controle de créditos sobre os serviços do

site.

A autenticação do sistema é feita por login e senha e o envio de informações para a

publicação conjuga isso com a assinatura dos dados por certificados digital. O sistema inclui um Web Service SOAP, sobre HTTPS, para o envio de XXXXX de forma automatizada, com funcionalidades similares ao sistema principal.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

 

Índice

Revisões

2

Introdução

3

Índice

4

1. Metodologia

5

2. Levantamento dos Objetivos de Segurança

6

3. Avaliação Funcional de Segurança

8

3.1. Autenticação do usuário

8

3.2. Garantia de confidencialidade e integridade

9

3.3. Autenticidade de origem

10

3.4. Não repúdio de origem

11

3.5. Canais seguros para pagamento

12

3.6. Rastreabilidade

12

3.7. Disponibilidade

12

4. Inspeção de Código

14

5. Consolidação dos Resultados

30

6. Considerações Finais

45

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

1. Metodologia

A análise foi realizada com base na norma internacional ISO/IEC 15408 – Evaluation

Criteria for IT Security, em conformidade ainda com o nível três (Manual Design

Review) do padrão OWASP ASVS. A metodologia utilizada, aqui sumarizada, encontra-se descrita em detalhes no livro R. Albuquerque e B. Ribeiro em “Segurança

no Desenvolvimento de Software”, Ed. Campus, 2002.

Conforme preconiza a norma ISO 15408, os controles de segurança de uma aplicação devem ser projetados e avaliados conforme as ameaças existentes a esta aplicação.

Assim sendo, após esta parte introdutória, o capítulo 2 descreve os objetivos de segurança de uma aplicação, ou seja, contra quais ameaças esta aplicação deve resistir

e quais os requisitos legais a aplicação está sujeita. Neste capítulo identificamos, portanto qual a necessidade de segurança da aplicação.

No capítulo 3 elaboramos a análise funcional de segurança, ou seja, verificamos se os controles de segurança da aplicação atendem aos objetivos de segurança. Estes controles foram levantados em entrevistas com os desenvolvedores, avaliação da documentação e verificados em inspeção de código do sistema por amostragem, bem como na execução de algumas funcionalidades desta. Os registros detalhados da inspeção de código encontram-se no capítulo 4, com a indicação das vulnerabilidades,

os

diretórios e os arquivos onde foram identificadas.

O

capítulo 5 consolida as vulnerabilidades identificadas, o grau de criticidade

designado pelo analista e indica recomendações de alterações para eliminação ou mitigação destas vulnerabilidades. Finalmente, o capítulo 6 indica as considerações finais do analista.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

2. Levantamento dos Objetivos de Segurança

O objetivo do sistema é permitir o envio de informações de negócio para a XXXXX

no XXXXX. As informações têm requisitos fortes de integridade e autenticidade de

origem, visto que a XXXXXXXX é ato previsto em diversas cláusulas contratuais. Evidentemente a XXXXX de XXXXXX com conteúdo errado ou XXXXX cujo usuário que enviou não tenha autorização XXXXXXX geram repercussões legais danosas.

Ainda existe requisito de confidencialidade, pois embora as XXXX sejam destinadas a XXXXXX, existem situações em que a XXXXX não pode ser XXXX antes da data

de XXXXXX por motivos legais.

Os requisitos de autenticidade trazem consigo naturalmente a necessidade de cadastro de usuários, autorizações de acesso, autenticação de usuário e controle de acesso. Adicionalmente, sendo um XXXXXX, aplica-se a necessidade de identificação e responsabilização dos usuários do sistema.

O aplicativo também é responsável por calcular o valor a pagar de cada XXXXX e

gerir o pagamento da mesma, seja através de uma contracorrente de crédito, emissão

de boleto ou pagamento via cartão de crédito.

Essas funcionalidades estão disponíveis tanto no aplicativo interativo, na página do sistema (https://xpto.com.br/) quanto através de chamada ao Web Service

(https://xpto.com.br/services/servicoxxx).

Podemos definir, portanto, como objetivos de segurança do sistema:

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Autenticação do usuário – Garantir que quem está acessando é um usuário legítimo associado a uma pessoa física e regularmente autorizado a utilizar o sistema por um dos clientes cadastrados. No caso do Web Service, deve haver possibilidade do sistema chamador identificar o usuário último que comanda a transação.

Garantia de confidencialidade e integridade – Garantir que o usuário só terá acesso de visualização de informações do cliente que representa e também só poderá alterar informações deste, sendo negado acesso a quaisquer outros dados;

Autenticidade de origem – As informações enviadas para publicação devem ser ligadas ao usuário e origem que a enviou;

Não repúdio de origem – O sistema deve permitir a confrontação legal da origem dos dados provando de forma inequívoca sua origem e integridade;

Canais seguros para pagamento – A emissão de guias de pagamentos envolvendo meios de pagamento deve ser feita com a garantia para o usuário cliente que não há perda de informações sensíveis no processo;

Rastreabilidade – Qualquer ação de usuário deve ser registrada de forma a permitir a identificação e responsabilização de usuário que eventualmente cometa ação não permitida;

Disponibilidade – O sistema é central no ciclo de negócio da empresa e, portanto, precisa estar disponível em janelas de tempo específicas.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

3. Avaliação Funcional de Segurança

Nesta análise partimos dos requisitos de segurança desejáveis para o sistema em análise e verificamos se os mesmos estão atendidos pelo sistema.

3.1. Autenticação do usuário

A autenticação do usuário é realizada por login e senha, em mecanismo de

autenticação proprietário. A senha é transportada via POST sob HTTPS e verificada

no servidor contra registro em banco de dados do MD5 de (login + senha), sem

SALT. A função de hash usada é a implementação do banco ORACLE. Embora a falta do SALT na criptografia seja problema menor, entendemos válida observação

nesse ponto.

V01) Implementação do registro da senha no banco de dados com hash sem SALT

O ciclo de vida do usuário nasce com seu cadastro no sistema por um gerente. O gerente é um usuário com perfil específico, tipicamente o primeiro usuário de um cliente, que se torna então responsável por cadastrar os demais usuários do sistema. O processo de cadastro do usuário, portanto é delegado ao gerente do cliente que, por sua vez, assina termo de uso com o sistema, fechando o ciclo de credenciamento.

Não identificamos também mecanismo para troca de senha por iniciativa do usuário, o que poderia ser feito apenas pelo esqueci minha senha.

V02) Ausência de mecanismo de troca da senha por iniciativa do usuário

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

O mecanismo do esqueci minha senha também apresenta implementação pouco

comum, com a separação de parte da nova senha, 4 caracteres mostrados na tela e 4 caracteres enviados por email. Entendemos frágil tal procedimento, pois dá margem a um atacante a tentar a quebra da senha por tentativa e erro sobre apenas 4 caracteres

V03) Mecanismo de esqueci minha senha sujeito a quebra de confidencialidade da senha

A

senha tem requisitos de métrica relativamente simples, com comprimento máximo

de

6 caracteres. Esse tipo de métrica torna a quebra por sistemas tipo rainbow tables

muito simples e automática.

V04) Métrica da senha insuficiente para garantia de segurança da mesma

A falta de mecanismo de bloqueio da conta por tentativas erradas também reforça essa

fragilidade, pois permitiria ataque de força bruta mesmo a usuários totalmente externos.

V05) Ausência de mecanismo de bloqueio da conta por tentativas erradas

A autenticação no Web Service, com autenticação por login e senha a cada chamada é

adequada, com um usuário e senha da aplicação para acesso ao Web Service e a identificação do usuário pelo CPF. As vulnerabilidades apontadas acima, porém, se aplicam também ao WS.

3.2. Garantia de confidencialidade e integridade

A garantia de confidencialidade e integridade dos dados é realizada pelo controle em

código do acesso a partir de cookies de sessão java mantidos pelos applets. As páginas

verificam o id do usuário logado e, eventualmente, verificam um cookie próprio para definição do gerente. A validação de direitos de acesso é deficiente, havendo páginas

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

em que não é feita e, sendo, portanto susceptível a ataques de hot spot tipo 3, ou seja, não checa o direito de acesso do usuário ao registro apresentado.

V06) Direito de acesso verificado manualmente em cada action dos servlets apresenta falha de validação em alguns deles

V07) Validação de direitos de acesso não verifica, na maioria dos actions, se o usuário tem acesso ao registro apresentado

Além dos pontos indicados acima, detectamos diversas falhas de código que podem gerar falha no controle de acesso. Tais falhas de código estão apontadas no capítulo 4.

No WebService, por outro lado, não foram identificadas as fragilidades apontadas acima, sendo feita a validação tanto do direito de acesso a função quanto do acesso ao registro específico.

Deve-se ressaltar ainda que a parte administrativa do sistema, que não é objeto dessa análise, o XPTO2, é um aplicativo cliente servidor, portanto padece do problema intrínseco a essa arquitetura de sistemas que é a possibilidade de contorno do controle de acesso. Qualquer usuário interno da XPTO que tenha acesso ao sistema XPTO2 pode acessar também o banco de dados diretamente pela interceptação das credenciais de acesso do sistema.

V08) Módulo administrativo do sistema permite contorno do controle de acesso para usuários internos

3.3. Autenticidade de origem

A garantia de autenticidade das informações enviadas é feita pelo registro do usuário e cliente que enviou a informação no momento do upload desta. Embora o sistema utilize certificados digitais do usuário, os mesmos não são usados para a assinatura digital da informação, mas tão somente para a abertura do canal de comunicação SSL

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

entre o Applet cliente e o servidor de recebimento, via um Socket SSL ou na abertura do canal HTTPS entre o sistema de envio e o WebService.

Embora tal mecanismo seja uma forma de autenticação da origem, não fornece garantias para a integridade do texto, ou seja, não garante que aquele texto foi gerado pelo usuário que fez a conexão.

V09) Ausência de mecanismo de assinatura digital no envio de documentos

Deve-se considerar ainda que os certificados digitais utilizados padecem de outros problemas como será apontado no próximo item.

3.4. Não repúdio de origem

O não repúdio de origem não é garantido pelo sistema, visto que os certificados não são aptos a garantir a origem da informação enviada. Existem diversos aspectos que previnem essa adequação:

1) Os certificados não são gerados e entregues ao usuário de forma correta, sendo gerados por CA interna e disponibilizados por download. Esse procedimento não garante a confidencialidade da chave privada.

V10) Ausência de garantia de confidencialidade da chave privada dos certificados digitais

2)

Os

reconhecida.

cerificados

gerados

não

possuem

estrutura

de

PKI

com

CA

raiz

V11) Cerificados digitais não possuem cadeia de certificação com certificado raiz reconhecido

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Além disso, cabe aqui também o fato de que a mera criptografia em túnel SSL não é suficiente para garantir o não repúdio de autoria

3.5. Canais seguros para pagamento

O sistema registra pagamentos por cartão de crédito e pela emissão de boletos.

Entendemos que a emissão de boletos, sendo feita via PDF, torna bastante improvável

a adulteração destes e a captação de pagamentos do usuário. Identificamos códigos para geração de boletos em HTML, porém, conforme informação dos desenvolvedores, os mesmos não são mais usados.

Deve-se notar, porém, que como o pagamento pode ser feito por mecanismo de créditos no sistema, todas as vulnerabilidades referentes a autenticação do usuário e

ao controle de acesso cabem aqui.

3.6. Rastreabilidade

Não identificamos mecanismos formais de registro de log ou trilha de auditoria, no nível de aplicação. Apenas algumas funções esparsas de registro e depuração foram observadas. Não estudamos o banco de dados, onde podem haver também mecanismos de registro de auditoria por trigger, porém, dado que o sistema utiliza usuário único para conexão com o banco de dados, qualquer mecanismo realizado lá, será ineficaz em fazer a ligação do evento registrado com o usuário logado.

V12) Ausência de mecanismo de registro de trilha de auditoria

3.7. Disponibilidade

O sistema web é hospedado em servidores múltiplos com balanceamento de carga e tratamento de falhas. Não elaboramos uma avaliação formal de disponibilidade, mas a configuração dos servidores nos parece adequada.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

O uso de Applet, porém, traz riscos para a arquitetura do sistema, visto que as versões

mais recentes do Java e do HTML não mais dão suporte a esta arquitetura, marcando-

o como “deprecated”. Isso não significa que deixarão de funcionar imediatamente,

porém vários navegadores têm suprimido o suporte e a recomendação é de não usar mais essa plataforma. Em uma futura atualização do java ou dos navegadores clientes, pode ocorrer a inoperabilidade definitiva do sistema.

V13) Uso de plataforma deprecada

Tal problema é sério, visto que, caso isso ocorra, pode haver uma solução de continuidade na operação do sistema por tempo significativo ou a necessidade dos clientes de usar versões antigas e inseguras de seus navegadores.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

4. Inspeção de Código

A inspeção de código foi realizada de forma automatizada pela ferramenta Safeval em

sua versão 2.9, em máquina com o código fonte disponibilizada em 22 de julho de 2012 para o sistema web e no dia 6 de agosto de 2012 para o WebSerivce. O código fonte é mantido em sistema SVN, e houve baseline “INSPEÇÃO” da versão do código avaliada. Após a inspeção automatizada, foi realizada também uma inspeção manual do código, incluindo 25% do código do sistema, verificando os pontos centrais para a segurança, bem como avaliando eventuais falsos-positivos apontados pelo sistema automatizado.

A tabela a seguir apresenta o resultado da inspeção de código. Não são apresentados

todos os arquivos inspecionados, mas apenas aqueles com observações relevantes. A primeira coluna indica a vulnerabilidade identificada, descreve a vulnerabilidade, a segunda aponta em que arquivos tal vulnerabilidade foi identificada e a linha. No próximo capítulo, apresentamos a consolidação de todas as vulnerabilidades identificadas e recomendações de correção

Tabela 4.1 – Resultado da inspeção de código

Vulnerabilidade

Arquivo e Linha

V14) Código suscetível a SQL Injection

\xptowebjavaprod\src\xpto \web\actions\atvclienteaction.java: 79 \xptowebjavaprod\src\xpto \web\actions\cadclienteaction.java: 123, 125, 127, 130, 131, 132, 133, 134, 136, 137 \xptowebjavaprod\src\xpto

Strings recebidas de entradas de dados do usuário são utilizadas na montagem de queries SQL, sem escape do plic ou uso de parâmetros. Trata-se de falha

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

 

Arquivo e Linha

extremamente grave, visto que o ataque SQL Injection é bastante conhecido e simples de ser executado.

\web\actions\editclienteaction.java: 146, 149, 151, 155, 158, 159, 160, 161, 163, 164 \xptowebjavaprod\src\xpto \web\actions\gravaconfigaction.java: 105 \xptowebjavaprod\src\xpto \web\db\dbutil.java: 2844, 2847 \xptowebjavaprod\src\xpto \web\tags\fillcombotag.java: 83, 92 \xptowebservicemarca\src\xpto \web\db\dbutil.java: 2702, 2705 \xptowebservicemarca\src\xpto \ws\xfire\xptowebservice.java: 2945

V15)

Montagem

de

query

SQL

com

\xptowebjavaprod\src\xpto

concatenação de parâmetros

 

\web\actions\atualizarorigemaction.java:

Strings recebidas de entradas de dados do usuário são utilizadas na montagem de queries SQL, porém utilizando função para escape de plic. Estes pontos não estão, a princípio, vulneráveis a SQL Injection, porém não utilizam o procedimento padrão para prevenção de SQL Injection que é o uso do plic. Trata-se de vulnerabilidade de baixo potencial.

92, 93, 94, 95, 96, 98, 140, 141, 142, 143 \xptowebjavaprod\src\xpto \web\actions\boletoaction.java: 123, 124, 125, 126, 135, 138, 141, 144 \xptowebjavaprod\src\xpto \web\actions\cadastrarorigemaction.java:

208, 288, 312, 516, 517, 518, 519, 520, 523, 689, 691, 693, 698, 701, 702, 703, 704, 707, 708 \xptowebjavaprod\src\xpto \web\actions\reqcertaction.java: 246 \xptowebjavaprod\src\xpto \web\actions\sendoficioxmlaction.java:

 

1121

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

 

Arquivo e Linha

 

\xptowebjavaprod\src\xpto

\web\actions\updatecadorigemaction.java:

107, 109, 110, 112, 115, 170, 172, 173, 174 \xptowebjavaprod\src\xpto \web\actions\updatepasswordaction.java:

84, 115 \xptowebjavaprod\src\xpto web\db\dbutil.java: 1244, 1265, 1267, 1293 \xptowebservicemarca\src\xpto \web\db\dbutil.java: 1202, 1251 \xptowebservicemarca\src\xpto \ws\xfire\xptowebservice.java: 1405, 1412, 1418, 1475, 1489

V16)

Montagem

de

query

SQL

com

\xptowebjavaprod\src\xpto \web\actions\recuperasenhaaction.java: 271

concatenação

de

valores

obtidos

do

banco

de

dados

pode

levar

a

SQL

 

Injection refletido

 

O código identificado pega valores de uma string guardada em banco de dados e monta uma query diretamente. O SQL injection é um ataque de execução difícil, ainda assim, um risco significativo.

V17) Montagem de código HTML diretamente do request leva a ataque de XSS direto

\xptowebjavaprod\webcontent

\lstmateria.jsp: 82, 83, 84, 85, 86, 87, 88,

89

 

\xptowebjavaprod\webcontent

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

Arquivo e Linha

A

montagem de código HTML a partir

\lstoficio.jsp: 77, 78, 79, 80, 81, 82, 83, 84,

de informações recebidas do request permite a criação de ataque de XSS direto que é uma etapa de diversos ataques de engenharia social.

85

\xptowebjavaprod\src\xpto

\web\actions\imprimeoficiopdfaction.java

V18) Montagem de código HTML sem escape apropriado

\xptowebjavaprod\src\xpto

\web\actions\boletocreditoaction.java:

1579, 1603 \xptowebjavaprod\src\xpto \web\actions\detmateriaaction.java: 392 \xptowebjavaprod\src\xpto \web\actions\endauteleaction.java: 181, 182, 218, 219 \xptowebjavaprod\src\xpto \web\db\dbutil.java: 1763, 1766, 1772, 1802, 1808, 1814 \xptowebjavaprod\webcontent \boleto\boleto.jsp: 72, 73, 74, 75 \xptowebjavaprod\webcontent \abertura.jsp: 525, 667 \xptowebjavaprod\webcontent \acordoautele.jsp: 114 \xptowebjavaprod\webcontent \detoficio.jsp: 70 \xptowebjavaprod\webcontent \lstautele.jsp: 139 \xptowebjavaprod\webcontent \modcliente.jsp: 110

A

montagem de código HTML a partir

de

informações armazenadas no banco

de

dados permite ataques do tipo XSS.

Identificamos que a maior parte do código usa um encoding simples, tipo XML encoding. Porém o mesmo encoding é usado para atributos. O encoding HTML deve ser sensível ao contexto. O uso de encoding tipo XML em atributos permite ataque XSS pelo uso malicioso do caractere de escape apsas “.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

 

Arquivo e Linha

 

\xptowebjavaprod\webcontent \updatecadorigem.jsp: 307, 449 \xptowebjavaprod\src\xpto \web\tags\fillcombotag.java: 107, 109 \xptowebjavaprod\src\xpto \web\tags\writeembedparamstag.java: 45 \xptowebjavaprod\src\xpto

\web\tags\writeobjectparamstag.java: 64 \xptowebjavaprod\src\xpto \web\util\appletslib.java: 187, 197 \xptowebservicemarca\src\xpto \web\db\dbutil.java: 1721, 1730, 1760,

1772

V19) Montagem de código PDF sem escape apropriado

\xptowebjavaprod\src\xpto \web\actions\boletoaction.java: 775, 842,

845

Código do banco de dados é usado para

\xptowebjavaprod\src\xpto

a

montagem do arquivo PDF por

\web\actions\imprimeoficiopdfaction.java:

concatenação, portanto sem a previsão

56, 59

de

eventual injeção de código. Trata-se

de

ataque pouco conhecido e de difícil

realização, porém possível.

 

V20)

Valores

fixos

hard

coded

sem

\xptowebjavaprod\src\xpto \web\actions\boletocreditoaction.java: 1539 \xptowebjavaprod\src\xpto \web\actions\cadastrarorigemaction.java:

286, 336, 350, 350, 409, 423 \xptowebjavaprod\src\xpto

especificação explicita

 

O uso de valores fixos em comparações e atribuições, valores cujo significado não seja óbvio, pode indicar a existência

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

Arquivo e Linha

de

back door ou regras de negócio não

\web\actions\configaction.java: 159 \xptowebjavaprod\src\xpto \web\actions\getchildaction.java: 485 \xptowebjavaprod\src\xpto \web\actions\jornalaction.java: 132 \xptowebjavaprod\src\xpto \web\actions\pagamentoaction.java: 114 \xptowebjavaprod\src\xpto \web\actions\reqcertaction.java: 207 \xptowebjavaprod\src\xpto \web\tags\fillcombotag.java: 228 \xptoappletprod\src\xpto \applet\iapplet.java: 654 \xptowebservicemarca\src\xpto \ws\xfire\xptowebservice.java: 2776, 3180

auditáveis, típicos ataques do desenvolvedor ao código. Nos casos verificados, não nos parece ser o caso de ataque do desenvolvedor, mas mera falta de documentação. Ainda assim é uma falha de segurança pois afeta diretamente a capacidade de manutenção do código, podendo gerar falhas no futuro.

V21) Uso de dados de entrada para montagem de header HTTP permite ataque de HTTP Splitting

\xptowebjavaprod\src\xpto \web\actions\downloadfilesaction.java: 116

O

ataque de HTTP Splitting é de difícil

execução, porém, se executado, é dos ataques mais danosos. Dados de entrada devem ser adequadamente validados.

V22) Código de teste e desenvolvimento misturado ao código de produção

\xptowebjavaprod\src\xpto \web\util\stringutils.java: 758 (*) \xptowebjavaprod\webcontent \calendar\index.html: 218 (**) \xptoappletprod\src\xpto

Os códigos apontados são inofensivos, porém indicam que há mistura de

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

 

Arquivo e Linha

 

\applet\guiwindowframe.java: 57, 58, 59,

código de teste com produção, que pode gerar falhas em manutenção futura.

(*) A mera presença de email de desenvolvedor, conforme recomendação das normas usadas, deve ser classificada como back door, porém verificamos que trata-se de mero teste.

61, 62, 63, 66, 67 \xptoappletprod\src\xpto \applet\jcomboboxextended.java: 176 \xptoappletprod\src\xpto \applet\guiwindowframe.java: 51 \xptoappletprod\src\xpto \applet\utils.java:

132

\xptoappletprod\src\xpto

(**) Embora o código não gere exposição de dados sensíveis, pode ser de alta gravidade. Vide Observação 2 no final deste capítulo.

\applet\EPSFileReaderTest.java

\xptowebjavaprod\src\xpto

\web\actions\cadastrarorigemaction.java:

278

V23)

Apresentação

de

informações

\xptowebjavaprod\src\xpto

sensíveis em mensagens de erro

\web\actions\cadastrarorigemaction.java:

823

Mensagens de erro mostrando o stack trace ou informações de exceções podem expor detalhes interno de funcionamento do sistema. Não é um ataque em si, mas ajuda na execução de outros ataques.

\xptowebjavaprod\src\xpto

\web\actions\updatecadorigemaction.java:

237

\xptowebjavaprod\src\xpto \web\db\dynamic\dynamicselect.java: 160, 201, 214, 270 \xptowebjavaprod\src\xpto

 

\web\db\dynamic\dynamicupdate.java: 95 \xptoappletprod\src\xpto \applet\iappletauteledocument.java: 85 \xptoappletprod\src\xpto \applet\iappletcanceldocument.java: 86

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

Arquivo e Linha

 

\xptoappletprod\src\xpto

\applet\iappletdisabletext.java: 85 \xptoappletprod\src\xpto \applet\iappletrebatebilldocument.java: 92 \xptoappletprod\src\xpto \applet\sendtask.java: 211, 217, 491, 496, 539, 544, 589, 594, 647, 652 \xptoappletprod\src\xpto \applet\sslclientconnection.java: 75, 95,

130

\xptoappletprod\src\xpto \applet\transmissiondialog.java: 479

V24) Retorno de informações sensíveis em Web Service SOAP

\xptowebjavaprod\src\xpto \web\actions \salvapermissaoclienteaction.java: 290

O código em questão retorna uma query do banco de dados. Queries possuem informações como nomes de tabela, coluna, etc que são extremamente uteis a um atacante.

Note que, embora refira-se a WS, não se trata do Web Service em si, mas de um Web Service presente no sistema interativo.

V25)

Internacionalização

inadequada

\xptowebjavaprod\src\xpto \web\actions\faixaprecoaction.java: 69 \xptowebjavaprod\src\xpto

pode levar a falhas inesperadas

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

 

Arquivo e Linha

A

conversão de valores assumindo o

\web\actions\lstmateriaaction.java: 162 \xptowebjavaprod\src\xpto \web\actions\lstoficioaction.java: 164

ponto ou a virgula explicitamente como separadores decimais pode gerar erros inesperados conforme a configuração do servidor. Os valores podem ser multiplicados por 100.

V26)

Uso

de

randômico

insuficiente

\xptowebjavaprod\src\xpto \web\util\stringutils.java: 659

para função de segurança

Randômicos para geração de senha, chaves de criptografia, vetores IV de criptografia e quaisquer propósitos de

 

segurança não podem ter semente óbvia.

O

randômico é usado com a semente

default, equivalente ao milissegundo da geração da senha. Isso permite um

ataque de força bruta extremamente eficiente.

V27) Uso do console para informações de depuração no cliente

\xptoappletprod\src\xpto \applet\preview\fonttable.java: 80 \xptoappletprod\src\xpto \applet\preview\fopdialog.java: 462, 515, 516, 518, 520, 522, 524, 525, 529, 533, 543, 546, 548 \xptoappletprod\src\xpto \applet\preview\fopdocumentvalidator.java:

145, 152, 159, 166, 181

O

console de um applet java é visível

para um eventual atacante, que pode usar as mensagens de depuração para

guiar seu ataque.

 
 
C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

Vulnerabilidade

Arquivo e Linha

 

\xptoappletprod\src\xpto \applet\preview\previewwriter.java: 135, 431, 442, 1018, 1075, 1078, 1079, 1080,

1119, 1124, 1125, 1233, 1234, 1293, 1357,

1377

\xptoappletprod\src\xpto \applet\preview\rtffieldinstruction.java: 209 \xptoappletprod\src\xpto \applet\preview\rtffile.java: 572, 574, 576,

578

\xptoappletprod\src\xpto \applet\preview\rtflogic.java: 286 \xptoappletprod\src\xpto

\applet\preview\rtftablereader.java: 189, 355, 400, 426, 429, 436, 449 \xptoappletprod\src\xpto \applet\preview\styletable.java: 58, 154,

164

\xptoappletprod\src\xpto \applet\preview\symboltranslation.java: 47 \xptoappletprod\src\xpto

\applet\thread\listthread.java: 36, 96 \xptoappletprod\src\xpto

\applet\util\pdf\pdfhexstringelement.java:

74

\xptoappletprod\src\xpto

\applet\util\pdf\pdfnameobjectelement.java:

80

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

Vulnerabilidade

Arquivo e Linha

 

\xptoappletprod\src\xpto \applet\util\pdfparser.java: 124, 298, 312, 774, 804, 882, 949, 1007, 1013, 1082, 1093, 1096, 1107, 1132, 1140, 1144 \xptoappletprod\src\xpto

\applet\util\serialversionuidgenerator.java:

46

\xptoappletprod\src\xpto \applet\util\stringutils.java: 383, 384, 385,

587

\xptoappletprod\src\xpto \applet\choosecreditsdialog.java: 55, 56 \xptoappletprod\src\xpto

\applet\epsfilereadertest.java: 7, 8, 9, 12 \xptoappletprod\src\xpto \applet\guiwindowframe.java: 35 \xptoappletprod\src\xpto \applet\iapplet.java: 260, 421, 444, 446, 449, 500, 522, 526, 528, 546, 576, 580, 582, 585, 588, 591, 1202, 1384, 1859, 1873, 1956, 1989, 2001, 2798, 2950, 2958, 2979, 3026, 3036 \xptoappletprod\src\xpto \applet\iappletauteledocument.java: 109,

112

\xptoappletprod\src\xpto \applet\iappletcanceldocument.java: 101,

116

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

Vulnerabilidade

Arquivo e Linha

 

\xptoappletprod\src\xpto \applet\iappletdisabletext.java: 100, 115 \xptoappletprod\src\xpto

\applet\iappletpreviewonly.java: 296, 302,

425

\xptoappletprod\src\xpto

\applet\iappletrebatebilldocument.java:

107, 123, 126 \xptoappletprod\src\xpto \applet\iapplettableselectionmodel.java: 59 \xptoappletprod\src\xpto \applet\jcomboboxextended.java: 68, 112,

124

\xptoappletprod\src\xpto \applet\jornalitemcombo.java: 57 \xptoappletprod\src\xpto \applet\motivosisencaoform.java: 177, 179 \xptoappletprod\src\xpto \applet\motivosisencaoitem.java: 24 \xptoappletprod\src\xpto \applet\motivosisencaoitemcombo.java: 18 \xptoappletprod\src\xpto \applet\orgobjectid.java: 206 \xptoappletprod\src\xpto \applet\pagamentoitemcombo.java: 18 \xptoappletprod\src\xpto \applet\sendtask.java: 202, 412 \xptoappletprod\src\xpto

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

Vulnerabilidade

Arquivo e Linha

 

\applet\sslfileserver.java: 52, 56, 60, 66, 74, 77, 91 \xptoappletprod\src\xpto \applet\tipoitemcombo.java: 22 \xptoappletprod\src\xpto \applet\transmissiondialog.java: 84, 302, 319, 353, 371, 382, 427, 445 \xptoappletprod\src\xpto \applet\treeframe.java: 642 \xptoappletprod\src\xpto \applet\treenodeextended.java: 51, 72 \xptoappletprod\src\xpto \applet\utils.java:

141, 142, 144, 149, 158, 166

V28) Back door no código

 

O código em questão recebe uma variável “debug” e não verifica todas as regras de negócio nesse caso. Não é possível determinar se o back door é malicioso (colocado propositalmente para atacar o sistema) ou meramente teste dos desenvolvedores. Em qualquer caso, se descoberto por um atacante, irá gerar danos consideráveis.

\xptowebjavaprod\src\xpto \web\actions\cadorigemaction.java: 50

V29) Código permite o download de arquivos aleatórios

\xptowebjavaprod\src\xpto

\web\actions\downloadfileaction.java

O código em questão recebe o nome do

\xptowebjavaprod\src\xpto

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 4.1 – Resultado da inspeção de código

 

Vulnerabilidade

Arquivo e Linha

arquivo para download nos parâmetros,

\web\actions\downloadpdfaction.java (*)

existe verificação, mas não impede o

uso de

\

no nome do arquivo.

Qualquer arquivo pode ser baixado por

um

atacante.

(*) o segundo caso também permite o

download de qualquer arquivo, porém

não está mapeado a evento, portanto

trata-se de código não usado

V30) Troca de senha permite ataque

\xptowebjavaprod\src\xpto

CSRF

 

\web\actions\updatepassword.java: 74, 100

O

código para troca de senha não

verifica a validade da senha anterior,

portanto permite ataque tipo cross site

request forgery, CSRF.

De

inspecionado.

forma

geral,

podemos

tecer

alguns

comentários

adicionais

sobre

o

código

Observação 1: Não há uma padronização na validação de dados de entrada. A mesma

não é feita, na maior parte das vezes, nas vezes em que é feita, usa várias funções

diferentes, sem padronização. Isso indica uma falha da arquitetura do sistema.

V31) Ausência de padrão de validação de dados de entrada

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

A validação de dados de entrada é função crucial para a segurança e estabilidade do sistema, sendo muito importante que seja planejada de acordo para garantir a segurança ao longo do ciclo de vida da aplicação.

Embora o struts tenha alguns tipos de validação, deve-se lembrar que não é validação de segurança, portanto inadequada.

Observação 2: Os códigos de teste e desenvolvimento incluem páginas fixas de componentes usados (não está claro se ainda são usados), mas observa-se que estão visíveis no site da XPTO no momento, com teste simples:

visíveis no site da XPTO no momento, com teste simples: Esse tipo de problema não leva

Esse tipo de problema não leva a falha ou a roubo de informação, mas pode facilmente ser usado para denegrir a imagem da empresa.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Observação 3: A estrutura do sistema não apresenta definição perceptível, havendo código de persistência e regras de negócio em conjunto, bem como código de apresentação que incorpora regras de negócio. Embora isso não seja, por si, uma falha de segurança, em um sistema desse porte, inexoravelmente leva a falhas constantes, problemas de qualidade e de segurança ao longo da vida útil do mesmo.

V32) Arquitetura do sistema não apresenta segregação entre camadas

Observação 4: Existem diversos códigos repetidos ao longo de toda a aplicação. Isso indica falta de planejamento da orientação a objetos. Entendemos que isso é reflexo da observação 3.

Observação 5: São usados componentes distintos para a criação de PDF, o CYaHPConverter, itextpdf e o JasperPDF, isso gera dificuldade de manutenção, aumenta o risco de uma falha de componente externo, sem apresentar ganho adicional.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

5. Consolidação dos Resultados

A tabela abaixo consolida as vulnerabilidades identificadas, sua criticidade e

recomendação de correção. Foram identificados um total de 32 vulnerabilidades. O

gráfico abaixo apresenta a porcentagem de vulnerabilidades em cada categoria de criticidade. A tabela 5.1 apresenta cada vulnerabilidade identificada e uma recomendação de correção.

identificada e uma recomendação de correção. Figura 5.1 – Vulnerabilidades por criticidade A primeira

Figura 5.1 – Vulnerabilidades por criticidade

A primeira coluna da tabela indica a vulnerabilidade, a segunda coluna a classificação

de criticidade da mesma e a última coluna a recomendação de correção pontual da

vulnerabilidade.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

V01) Implementação do registro da senha no banco de dados com hash sem SALT

1

Recomendamos implementar o HASH com o SALT individual para cada registro. O SALT deve ser um número aleatório, com, no mínimo, 256 bits, armazenado em outra coluna da mesma tabela.

O Hash MD5 também é considerado ultrapassado, embora não represente diretamente uma falha de segurança em aplicações desse tipo. De qualquer forma, sendo alterado o SALT é uma boa oportunidade para alterar o processo de hash para algoritmo mais moderno como o SHA-2 512.

V02) Ausência de mecanismo de troca da senha por iniciativa do usuário

2

Entendemos que a implementação de tal função é importante para o caso do usuário saber que sua senha foi comprometida. Recomendamos a implementação.

V03) Mecanismo de esqueci minha senha sujeito a quebra de confidencialidade da senha

4

Recomendamos que a senha temporária seja, toda ela, enviada por email para o usuário. Adicionalmente, a métrica da senha temporária deve ser equivalente a senha, conforme a recomendação da vulnerabilidade V04.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

V04) Métrica da senha insuficiente para garantia de segurança da mesma

3

Recomendamos que seja adotada a métrica mínima de 8 caracteres, com pelo menos uma letra maiúscula, uma minúscula, um número e um sinal.

V05) Ausência de mecanismo de bloqueio da conta por tentativas erradas

4

Em caso de três falhas no login, o usuário deve ser bloqueado e será desbloqueado apenas com o uso da função “esqueci minha senha”. Isso impede ataques de força bruta externa.

V06) Direito de acesso verificado manualmente em cada action dos servlets apresenta falha de validação em alguns deles

5

Deve ser criada uma classe abstrata para action que incorpore o controle de acesso, o controle de acesso deve sempre verificar, em cada sessão, quem é o usuário logado, verificar o

V07) Validação de direitos de acesso não verifica, na maioria dos actions, se o usuário tem acesso ao registro apresentado

4

perfil desse usuário, verificar se ele tem acesso a função chamada e verificar se ele tem acesso ao registro indicado.

Todos os actions devem derivar dessa classe abstrata e chamar a função de controle de acesso para garantir uniformidade na validação.

Alternativamente, pode ser feita por um interceptador apropriado, para verificação do usuário logado.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

V08) Módulo administrativo do sistema permite contorno do controle de acesso para usuários internos

3

Recomendamos que toda a administração do sistema seja feita por aplicativo em mais de uma camada física, portanto aplicativo web ou com object broker. Não deve ser usada a arquitetura cliente- servidor, visto esta possuir fragilidades inerentes.

V09) Ausência de mecanismo de assinatura digital no envio de documentos

4

A

assinatura digital é a forma

adequada para garantir a responsabilização e o não repúdio

 

no envio de informações sensíveis.

V10) Ausência de garantia de confidencialidade da chave privada dos certificados digitais

4

O

estabelecimento de SSL com

certificado ponto a ponto não garante a autoria da informação transmitida. Recomendamos que os

V11) Cerificados digitais não possuem cadeia de certificação com certificado raiz reconhecido

3

arquivos RTF sejam assinados digitalmente para envio, por certificado digital dentro da arquitetura do ICP-Brasil que podem ser gerados por qualquer AC do mercado ou até por AC da XPTO, porém com certificação

adequada no padrão ICP-Brasil, ou seja, com raiz na AC-ICP-Brasil.

O

sistema deve verificar a assinatura

digital no recebimento, verifica que

se

trata de assinatura válida, de

certificado dentro da validade, não

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

presente na lista de revogação, e o cliente indicado no sujeito do certificado corresponde ao usuário autenticado no sistema.

V12) Ausência de mecanismo de registro de trilha de auditoria

3

Recomendamos que seja

implementado mecanismo de auditoria onde fossem registrados, para cada evento:

 

• Nome do usuário

• IP da máquina de acesso

• Nome da máquina de acesso

• Data e hora

• Tipo de evento

Outras informações conforme o tipo

Tal mecanismo deve registrar, no mínimo as seguintes ações:

Criação, alteração e remoção de

clientes

Criação, alteração e remoção de

usuários

Bloqueio e desbloqueio de

usuários

• Alteração de senhas

• Logins com falha e com sucesso

• Criação, alteração e remoção de

informações e dados

Alterações de direitos de acesso de

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

usuários

Alterações na gestão de objetos

Exceções e erros inesperados de qualquer natureza

V13) Uso de plataforma deprecada

5

Entendemos que a arquitetura com base em Applet deve ser abandonada. A interface do sistema deve ser reescrita com uso de HTML5 puro ou outro framework para apresentação sem componentes locais (não usar ActiveX, XBAP, Silverligh, Pepper e equivalentes).

V14) Código suscetível a SQL Injection

5

Toda query SQL deve ser feita com parâmetros. Não deve ser usada concatenação com dados de entrada

V15) Montagem de query SQL com concatenação de parâmetros

2

ou dados do banco de dados em nenhuma situação.

V16) Montagem de query SQL com concatenação de valores obtidos do banco de dados pode levar a SQL Injection refletido

3

Ao invés de concatenação:

Statement stmt = conn.createStatement("INSERT INTO students VALUES('" + user + "')"); stmt.execute();

 

Usar sempre parâmetros:

Statement stmt = conn.prepareStatement("INSERT INTO student VALUES(?)"); stmt.setString(1, user); stmt.execute();

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

Essa é a forma recomendada porque delega ao driver do banco de dados a forma correta de fazer o escape de cada caractere especial possível.

Adicionalmente, os dados de entrada devem ser validados de forma estrita, conforme V31.

V17) Montagem de código HTML diretamente do request leva a ataque de XSS Reflected

4

Toda informação usada na montagem de código HTML deve passar por escape antes de ser usado. Isso vale mesmo para código

V18) Montagem de código HTML sem escape apropriado pode levar a XSS Sotred

4

inserido via os tags <%=, #(, $( ou <app:write no JSP. No caso dessa última é possível usar o parâmetro filter=true para fazer o encoding correto.

Existem bibliotecas adequadas para esse tipo de função, por exemplo a JSTL, mas funções próprias também podem ser usadas.

Importante notar que a função de encoding tem que ser sensível ao contexo. Tipicamente são 3 situações com encodings diferentes:

1)

Código JavaScript

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

São variáveis que serão renderizadas entre um <script> e </script>. Neste caso, para strings, tem que ser feito o escape de caracteres “ para \” e ‘ para \’, além da sanitização para suprimir < e >. Note que, se o código será usado em um innerHTML também tem que ter todo o escape da parte 2, se tornando bem mais complexo.

2)

Código HTML puro

Deve-se fazer o encoding similar ao XML, ou seja, todos os caracteres padrão podem ser mantidos, caracteres especiais devem passar para &#nnn; onde nnn é o código ascii do caractere.

3)

Atributo de TAG HTML

O atributo é referenciado entre aspas (“), entre plic (‘) ou sem delimitação. Deve-se, portanto, cuidar de escapar todas as situações acima.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

   

Adicionalmente, os dados de entrada devem ser validados de forma estrita, conforme V31.

V19) Montagem de código PDF sem escape apropriado

2

Tipicamente informações de comando são passadas pela ferramenta usada para gerar o PDF, mas, se o texto do usuário contiver strings de comando, as mesmas podem confundir e incluir comandos e até código javascript dentro do PDF.

Recomendamos que todas as informações usadas para gerar o PDF passem por sanitização que elimine qualquer caractere que não seja letra, número, espaço em branco ou sinal de pontuação básico, como ponto, virgula e hífen.

Adicionalmente, os dados de entrada devem ser validados de forma estrita, conforme V31.

V20) Valores fixos hard coded sem especificação explicita

2

Os valores devem ser definidos em uma classe de constantes fixas e referenciados por labels explicativos. Caso isso não seja possível, incluir comentário explicando o porque do valor fixo

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

   

no código.

V21) Uso de dados de entrada para montagem de header HTTP permite ataque de HTTP Splitting

3

Os dados para headers HTTP, cookies, etc, devem passar por encoding de forma a evitar ataques de injeção contra o protocolo HTTP. Particularmente deve ser impedidos os caracteres \x0d e \x0a (enter e return carriage).

Adicionalmente, os dados de entrada devem ser validados de forma estrita, conforme V31.

V22) Código de teste e desenvolvimento misturado ao código de produção

3

Todo código de teste deve ficar em um diretório próprio \teste que não deve ser compilado e montado junto com o restante do sistema quando esse for para produção.

Alternativamente, o código de teste pode ser apenas removido.

Recomenda-se cuidado particular em classes que realizem alguma função e em html estáticos como o mostrado na observação 2.

V23) Apresentação de informações sensíveis em mensagens de erro

2

Mensagens de erro não devem nunca refletir informações da exception nem o stack trace. Essas

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

   

informações, por serem necessárias a depuração, devem ser registradas no log de auditoria.

Para o usuário deve ser apresentada mensagem user-friendly, com informações genéricas sobre o problema e aconselhando-o a procurar o suporte em caso de dúvidas.

V24) Retorno de informações sensíveis em web servisse SOAP

4

Não ficou claro para o analista a necessidade deste web service. Acreditamos ter por motivação o teste de algumas queries específicas. Se for esse o caso, recomendamos sua eliminação.

Se, porém, existe alguma utilidade que não teste ou depuração, deve-se proceder a verificação do usuário autenticado, garantindo-se ser um usuário administrador ou interno antes de retornar dados sensíveis.

V25) Internacionalização inadequada pode levar a falhas inesperadas

1

Recomenda-se a identificação da cultura do servidor antes de proceder a troca de ponto para virgula, ou o uso de funções independentes da cultura para tratamento de informações com

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

ponto decimal.

 

V26) Uso de randômico insuficiente para função de segurança

3

Deve-se usar a classe SecureRandom disponível no java 1.7 ou outra classe em biblioteca de segurança confiável.

V27) Uso do console para informações de depuração no cliente

1

Toda depuração deve ser removida antes da colocação do sistema em produção.

Recomendamos o uso de função específica para depuração que resolva para system.out.println no ambiente de desenvolvimento e para nada no ambiente de produção.

V28) Back door no código

4

O

código em questão, com variável

debug e todas as suas ações associadas deve ser removido. Depuração em ambiente de produção pode ser feita pelo mecanismo de auditoria do sistema

apenas.

 

V29) Código permite o download de arquivos aleatórios

5

A

validação do nome do arquivo

deve ser feita para impedir a

 
 

presença de ponto-ponto

,

barra /,

contra-barra \, pipe |, maior > e

menor < para evitar alterações indevidas.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

O

código que permite download

com qualquer extensão e não está

mais sendo usado, deve ser removido.

V30) Troca de senha permite ataque CSRF

4

O

sistema precisa validar a senha

atual do usuário antes de proceder a

 

troca da senha. A validação da senha atual deve obedecer a todas as funções indicadas no login, inclusive o bloqueio por tentativas erradas.

V31) Ausência de padrão de validação de dados de entrada

4

Todos os dados de entrada devem passar por validação antes do uso em outros componentes ou funções internas do sistema. Tal validação deve ser feita sempre no servidor, independente de haver ou não validação em JavaScript ou em outra camada do sistema.

A

validação no servidor de

aplicação, assim que recebido o valor de Request, garante que é mínima a possibilidade de alguma informação com código de ataque seja passada para função do sistema ou dos demais sistemas associados.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

Recomendação

   

Embora a validação por eliminação de caracteres danosos funcione de forma adequada, recomenda-se, por segurança, que seja utilizada a validação estrita de dados. Ao invés de procurar e remover determinados caracteres, deve-se definir o conjunto de caracteres que é permitido, checar cada caractere da string e, caso tal caractere não corresponda a um dos caracteres permitidos, o mesmo é eliminado ou uma mensagem de erro é gerada.

Tal mecanismo de validação garante o processo contra outros caracteres inválidos e não esperados e também garante que o sistema permanecerá seguro caso um novo ataque, baseado em outro caractere inválido seja descoberto no futuro. Deve-se levar em conta que tal validação estrita é de implementação ligeiramente mais custosa e o tempo de execução é proporcional ao número de caracteres permitidos.

Esta validação deve ser feita também em todos os webservices do

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Tabela 5.1 – Consolidação das vulnerabilidades

Vulnerabilidade

Crit.

 

Recomendação

   

sistema, sendo validados principalmente os campos string.

V32) Arquitetura do sistema não apresenta segregação entre camadas

5

O

sistema deve ser feito com

camadas claras de persistência, regras de negócio e apresentação. Uma classe de persistência não pode

 

conter regras de negócio, assim como uma classe de apresentação não pode fazer persistência. Uma classe de regra de negócio não pode fazer acessos ao banco de dados, nem montar strings para apresentação e assim por diante.

A

separação em camadas garante

maior robustez ao código, evitando que manutenção posterior acabe por contornar os mecanismos de segurança.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

6. Considerações Finais

O sistema avaliado apresenta grande número e complexidade de regras de negócio e funcionalidades de suporte, o que aponta para a necessidade de uso de uma plataforma com muita flexibilidade e capacidade de componentização. Apesar da plataforma base ser adequada, vemos que o sistema não foi construído desta forma, sendo muitos dos acessos a bancos de dados feitos diretamente da camada de negócios, uso precário e não uniforme de camada de persistência e grande número de replicação de código. Como esperado em sistemas de grande porte sem a segregação de camadas apropriada, o sistema mostra diversas falhas decorrentes de manutenções evolutivas, incluindo aqui as falhas no controle de acesso e prevenção de SQL Injection apontadas. O WebService apresenta código melhor organizado, porém ainda apresenta várias das falhas identificadas no sistema interativo.

Além disso, destaca-se negativamente a arquitetura adotada no sistema web, de uso do Applet. Entendemos que se trata de uma decisão realizada no início da codificação, quando tal plataforma ainda era uma solução comum. Hoje, porém, com a popularização do HTML 5 e o virtual abandono do Applet, é um enorme risco manter uma aplicação com esse tipo de arquitetura, não apenas pelo risco de se tornar inoperante num futuro próximo, como pelo fato de, devido ao pouco uso, essa arquitetura não ter recebido melhorias de segurança e atualizações.

Finalmente, nos parece muito insegura a forma de tratamento e uso de certificação digital. O uso de certificados pode dar uma falsa impressão de segurança que, por si só, é um grande risco. São várias falhas conceituais desde a emissão do certificado até a forma de uso do mesmo, apontadas ao longo do relatório.

C-XPTO-01-2012-004 Análise de Segurança do Sistema XPTO Documento Restrito

C-XPTO-01-2012-004

Análise de Segurança do Sistema XPTO

Documento Restrito

Em virtude do apontado, do grande número de problemas estruturais de segurança, é a recomendação do analista o abandono da solução Applet em nome de controles em HTML5 e alteração do processo de certificação digital desde o início, com a geração do certificado na máquina do cliente e uso de uma CA certificada. Especial cuidado deve ser tomado com a validação de dados de entrada e validação de direitos de acesso. Além disso, conforme apontamos no capítulo 5, recomendamos as correções para cada vulnerabilidade apontada.