Tag Archive: Segurança no Desenvolvimento de Aplicações


Spring-Security-logo

… surge mais um “bug-manhoso“! – categoria de bugs em que incluo também os famigerados ponto e vírgulas e outros elementos “insignificantes” que dão-nos algumas dores de cabeça quando esquecidos algures no emaranhado de códigos.

Neste cenário, o nosso “bug-manhoso” é alimentado pelo Mau Mapeamento das Portas no ficheiro de configuração do applicationContext.xml, impossibilitando o correcto funcionamento da framework de segurança Spring Security 3.1.4 em uso numa aplicação web Java.

Este problema é impulsionado pelo facto de que com alguma frequência  nos  desleixamos e confiamos nas configurações default que acompanham muitos dos  recursos usados nos nossos ambientes.

Server Tree

A configuração em questão é a do servidor de aplicação Glassfish que corre por default nas portas 8080 e 8181 (http e https, respectivamente). Quando os condicionalismos obrigam, o funcionamento em simultâneo de vários servidores só é possível efectuando a alteração das portas default, usando por exemplo as portas 14798 e 14799.

Caso esta alteração não seja acompanhada das devidas alterações subsequentes, poderá provocar um mau funcionamento do Spring Security.

Em dias de sorte, esta falha é alertada pela exibição da mensagem no browser: “Está página Web tem um ciclo de redireccionamento“, com o código de erro: ERR_TOO_MANY_REDIRECTS.

1

Podendo também ser menos explícita tal como apresentado no screenshot abaixo, lançando a excepção com.sun.faces.context.FacesFileNotFoundException e duplicando o nome do sistema na URL.

main

Como Resolução, deve-se alterar as definições de mapeamento de portas no ficheiro applicationContext.xml actualizando para os novos valores dos atributos http e https da tag port-mapping.

applicationContext

portas

24

E foi com este tema que marquei ontem a minha estreia, em modo Speedy Gonzalez :D, nas sessões de apresentações do CAST – Comunidade Angolana de Segurança e Tecnologia.

Com casa cheia, foi bastante gratificante podermos observar o intercâmbio de conhecimento e experiências entre os profissionais da área e os estudantes universitários que pela primeira vez fizeram-se representar em bom número, o que com certeza deixou satisfeito os que têm acompanhado de perto a caminhada da comunidade.

O pontapé de saída foi dado por Sérgio Cruz que dissertou sobre “Sistemas Integrados de Gestão Empresarial“, cobrindo os pontos anunciados por altura do lançamento do evento, tais como a importância, factores de decisão técnica e as razões técnicas em que baseou a sua opção. Em jeito de conselho, foi passando informações que considera cruciais para que um processo de adopção de um ERP finalize com sucesso.

Na sequência, coloquei as vestes de evangelizador de segurança, convidando os participantes a uma viagem ao passado, levando-os a compreender a presente necessidade de consciencialização para a adopção de práticas seguras de Engenharia de Software e de Gestão de Projectos de Software nos processos de desenvolvimento e/ou aquisição de soluções. Com certeza, a ocasião proporcionou também a oportunidade para dar a conhecer conceitos pouco disseminados como Software Assurance, ciclo de vida de desenvolvimento de software seguropráticas de segurança, entre outros, relacionados à Segurança em TI.

Para obter mais informações como as apresentações deste e outros eventos passados, é só visitar a página do CAST em www.cast.co.ao e, aproveitando a visitinha, cadastrar-se, abraçando assim a causa. 😉

24

Será amanhã, quinta-feira 30 de Maio, a partir das 18h30, que decorrerá mais um Encontro CAST onde profissionais e entusiastas das Tecnologias de Informação partilham seus conhecimentos e experiências, com ênfase para os assuntos relacionados à Segurança.

Desta vez estarei na linha da frente com a apresentação intitulada “Segurança de SoftwareUm olhar para além das linhas de código!”, que terá na sua essência a consciencialização sobre a necessidade da adopção de práticas seguras de Engenharia de Software e de Gestão de Projectos de Software nos processos de desenvolvimento e/ou aquisição de soluções.

Comigo também estará Sérgio Cruz, Gestor de Projectos ERP, Consultor/Programador Sénior PHC Enterprise e SQL Server Database Administrator, dissertando sobre “Sistemas Integrados de Gestão Empresarial“, com tópicos que evidenciarão a sua Importância, factores de decisão técnica, razões técnicas que baseiam a sua opção, entre outros.

Local: Integrated Solutions, Bairro Azul. Clique para conhecer o local

Caso ainda não saiba, recomendo: 5 razões para estar presente num encontro do CAST

A PARTICIPAÇÃO É TOTALMENTE GRÁTIS!

P.S: Coffee Break por conta da casa, uma oferta da Integrated Solutions!

Em finais de Agosto foram anunciadas vulnerabilidades no Java SE (CVE-2012-4681) que podem afectar os utilizadores via navegadores de Internet (web browsers), permitindo a terceiros com intenções maliciosas de executar código arbitrário no sistema do utilizador, sem a necessidade de autenticação (um nome de utilizador e/ou senha).

Estas vulnerabilidades são exploradas com êxito, quando um utilizador desavisado, executando em um navegador uma versão Java afectada, visita uma página web maliciosa que aproveita estas vulnerabilidades. Um ataque bem sucedido pode afectar a disponibilidade, integridade e confidencialidade do sistema do utilizador.

Versões afectadas

JDK e JRE 7 Update 6 e anteriores
JDK e JRE 6 Update 34 e anteriores

A Actualização

Em resposta, a Oracle disponibilizou no dia 30 de Agosto as actualizações que corrigem as vulnerabilidades anunciadas.

Aos utilizadores comum que executam o Java SE com um navegador, aconselha-se a efectuarem o download das actualizações do JRE 7 em http://java.com/ e, a posterior, prosseguirem com o processo de instalação.

Para os utilizadores avançados e desenvolvedores, inicialmente, se necessário, poderão verificar a versão do Java instalado nos seus computadores visitando a página http://www.java.com/en/download/installed.jsp.

De seguida, poderão efectuar o download do Java SE 7 update 7 ou 6 update 35, escolhendo os links para os respectivos JDK e JRE em http://www.oracle.com/technetwork/java/javaso/downloads/index.html.

.

FacesMessage facesMsg = new FacesMessage(FacesMessage.SEVERITY_INFO, “Faça Antes de” +”Codificar!”, “Pois Queremos Alicerces Seguros Nos Nossos Sistemas!!!”);

Na primeira parte desta matéria procuro dar a conhecer toda a envolvente teórica, retirada e adaptada do material disponibilizado pela SAFECode, sobre um dos temas que é transversal a qualquer metodologia que possa ser adoptada pela sua equipa para garantir a Segurança no Desenvolvimento de Software.

No percurso para o desenvolvimento de um software que cumpra com os critérios fundamentais para ser considerado resultado de um Ciclo de Desenvolvimento de Software Seguro, encontramos a  Modelação de Ameaça, considerada como a principal actividade de segurança na fase de design do software.

Modelo de Ameaças - Diagrama de Contexto

O Conceito

Basicamente, a Modelação de Ameaça (Threat Modeling)  é um exercício conceitual feito no período de design do software, onde o fluxo de dados de um sistema é analisado para encontrar vulnerabilidades de segurança e identificar as formas que as mesmas possam ser exploradas.

Com a adopção deste procedimento, agrega-se valor ao produto final pois garante-se a prevenção de potenciais problemas de design, na  lógica de negócio ou fluxos de trabalho inseguros, que não são normalmente encontrados usando outras técnicas, como revisões e análise estática do código fonte. Em essência, a modelação de ameaça identifica problemas antes do código ser escrito, para que eles possam ser evitados ou mitigados tão cedo quanto possível no ciclo de desenvolvimento do software.

Ao contrário das Ferramentas de Análise de Vulnerabilidades que só permitem a identificação de vulnerabilidades após o código ser implementado, a actividade de modelação de ameaça permite uma identificação ainda em tempo de design. Com esta abordagem é possível traçar estratégias de desenvolvimento que permitam controlar os riscos numa fase prematura do desenvolvimento.

Pela sua natureza, as correcções de ordem arquitectónicas são mais dispendiosas quando realizadas nos estágios mais avançados de desenvolvimento. Assim, a modelação de ameaça pode ser considerada uma actividade que privilegia a contenção de despesas pois a resolução de problemas logo no início do processo pode ser tão fácil como a simples tarefa de alterar um diagrama para ilustrar uma solução ainda a ser codificada.

Contudo, tentar identificar todas as ameaças possíveis e procurar mitigá-las logo no início do processo de desenvolvimento pode ser difícil de alcançar, então o foco deve ser sobre as questões de alto risco que podem ser identificados em tempo de design.

A Actividade

A modelação de ameaça pode ser feita a qualquer momento no ciclo de vida de desenvolvimento do sistema, mas para maximizar a eficácia esta actividade deve ser realizada o mais cedo possível.

Esta actividade começa com a identificação das ameaças possíveis e mais recorrentes. Nesta ordem, são usadas diferentes estratégias:

• “STRIDE” – esta metodologia classifica as ameaças em 6 grupos: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service e Elevation of Privilege. A Modelação de ameaça é executada, olhando para cada componente do sistema e determinando se existem algumas ameaças, pertencente a uma das categorias, que recaia sobre o componente e/ou à sua relação com o resto do sistema.

STRIDE
• “Caso de uso incorrecto” – o emprego de caso de uso incorrecto ajuda a clarificar como um atacante pode comprometer o sistema. Estes casos devem ser criados a partir dos requisitos funcionais do sistema, e ilustram como as medidas de protecção podem ser contornada e as áreas onde não existem nenhuma.
• “Brainstorming” – se uma organização não tem experiência na construção de modelos de ameaça, uma discussão orientada à segurança onde os arquitectos avaliam o sistema ajuda a colmatar esta deficiência. Tal “brainstorming” não devem ser considerados uma solução completa, e só devem servir como um trampolim para um exercício de modelação mais robusto.
• “Biblioteca de ameaças” – é um meio que torna o processo de identificação de ameaças mais acessível para os profissionais não especializados em segurança. Como bibliotecas públicas temos: CWE (Common Weakness Enumeration – um dicionário de tipos vulnerabilidades comuns em softwares), OWASP Top Ten e CAPEC (Common Attack Pattern Enumeration and Classification – que descreve métodos comuns de ataques).

Uma vez identificados, cada ameaça deve ser avaliada e mitigada de acordo com o risco associado, os recursos disponíveis, o caso de negócio e os requisitos do sistema. Isto irá ajudar a priorizar a ordem em que as ameaças devem ser abordadas durante o desenvolvimento, bem como os custos envolvidos na mitigação. Às vezes, isso irá conduzir à mudanças no design para permitir mitigações menos dispendiosas.

O Resultado

De uma actividade de Modelação de Ameaça certamente resulta o  Modelo de Ameaças do sistema a ser implementado, com o seu conjunto de diagramas, bem como uma Lista das Ameaças Associadas, mitigadas ou não.

Tem sido observado que a modelação de ameaça como parte das actividades recorrentes no ciclo de vida de desenvolvimento do software ajuda a enraizar uma cultura que aceita a segurança como um aspecto integral do design de software.

Para a segunda parte desta matéria está reservada uma simulação de um processo de Modelação de Ameaças, onde procurarei espelhar toda a dinâmica da sua opção num processo de desenvolvimento Ágil,  aplicando os conceitos aqui descritos e citando ferramentas que suportam a actividade com a análise automatizada de projectos e sugestões para possíveis mitigações e acompanhamento de questões de integração e comunicação relacionadas com o processo.

%d bloggers like this: