No artigo: SAAM: A Method for Analyzing the Properties of Software Architectures é apresentado um método (SAAM) para avaliar arquitetura de softwares. Abaixo segue o resumo (tradução minha) artigo que se esta disponível em: http://www.sei.cmu.edu/library/assets/ICSE16.pdf
Enquanto a arquitetura de software tem se o tornado um importante tópico de pesquisa nos ultimo anos, pouca atenção tem sida dada aos métodos de avaliação para essas arquiteturas. Avaliar arquiteturas é difícil por duas razões. Primeiro não existe uma linguagem comum para descrever diferentes arquiteturas. Segundo não existe uma forma clara de entender como é o ciclo de vida do software nas organizações, ou seja, como funcionam as preocupações com qualidade tais como manutenção, portabilidade, modularidade, reutilização, e assim por diante. O artigo aborda essas deficiências por descrevendo três perspectivas pelas quais é possível compreender a descrição de uma arquitetura de software e, em seguida, propondo um método de cinco passos para a análise de arquiteturas de software chamado SAAM (Software Architecture Analysis Method). O método é analisado através de três arquiteturas em relação à qualidade das manutenções.
Em seu artigo Bryan Sullivan “Top 10 Application Security Vulnerabilities in Web.Config Files” lista dez vulnerabilidades que ocorrem no arquivo de configuração web.config. A maior parte das ameaças a rede de computadores das organizações vem do web site ou de aplicações baseadas na web. As aplicações internas podem ser isoladas do mundo exterior através de um firewall enquanto os web sites são acessíveis de qualquer lugar ou por qualquer pessoa o que exige mais da segurança dos aplicativos e pode se tornar um problema para a organização. Como as redes estão se tornando mais seguras as vulnerabilidades em sites estão atraindo mais criminosos virtuais com o objetivo de explorar de alguma forma essas falhas. De acordo com Bryan Sullivan os ataques a aplicações web têm sido mais freqüentes do que os ataques as redes.
Segundo o autor, os arquitetos e desenvolvedores estão dando agora mais importância a segurança das aplicações na hora de projetar e desenvolver. Porém mesmo assim a aplicação pode esta vulnerável a ataque se não houver atenção necessária nos arquivos de configuração (Web.config). Se ele estiver configurado incorretamente pode trazer grandes ameaças como um código mal feito. O que torna mais grave esta situação é que as configurações padrão deste arquivo possuem valores que tornam o ambiente inserguro.
O autor na parte um do artigo lista cinco configurações que permitem que criminosos virtuais explorem as aplicações baseadas na web e usam a tecnologia ASP .NET.
1 - Custom Errors Disabled
Quando esta configuração está com o valor desabilitado (off) os erros que ocorrem na aplicação é exibido detalhadamente para o cliente em seu browser. O nome dos métodos, nome de variáveis e descrição do que casou o erro.
Configuração vulnerável:
<configuration>
<system.web>
Configuração segura:
<configuration>
<system.web>
Saber o local em que o erro foi originado parece não ser um risco para a segurança, mas quanto mais informações um hacker conseguir de um site mais fácil será atacá-lo. Por exemplo, através de uma exceção poder ser obter a versão do servidor IIS e do SGBD SQL Server que a aplicação esta sendo usada. Com esta informações em mãos basta procurar ou desenvolver exploits que exploram vulnerabilidades do servidor, caso elas existam.
De acordo com Bryan Sullivan, para impedir que os detalhes dos erros sejam exibidos no browser do cliente modificando o atributo mode do elemento <customErros> para remoteOnly. Desta forma um mensagem de erro genérica é exibida para o usuário. Outra forma de aumentar o nível de segurança é redirecionar o cliente para uma pagina de erro padrão. Isto pode ser feito definindo o atributo defaultRedirect do elemento <customErros>. Esta abordagem ainda é melhor que a anterior, porque não revela o servidor a versão do servidor ASP .NET que a aplicação esta executando.
No próximo post continuarei a lista as ameaças que acontecem devido a uma confiugração mal feita no arquivo Web.config.
